Re: [PATCH 11/40] Input: atmel_mxt_ts - Bootloader addresses for mXT1664/mXT1188S

[Benson Leung]

We've moved away from using platform data in our project because it's
clunky, and because we implemented the config loading that's similar
to what you submitted elsewhere in this series.

Furthermore, for our ARM projects specifically, we are using flattened
device trees to describe our board and instantiate devices. The upside
is that it means that we no longer have to modify the kernel to bring
up a new board with some varied hardware.

The downside is that it's impossible to setup platform data for i2c
devices from the device tree. drivers/of/of_i2c.c instantiates i2c
devices including the atmel touch device, and it doesn't and shouldn't
know about how atmel_mxt_ts's platform data is structured. All it does
is i2c_new_device on the right adapter, at the right address, and
optionally pass in an irq #.



On Fri, Feb 22, 2013 at 11:51 AM, Nick Dyer <nick.dyer@xxxxxxxxxxx> wrote:
> Benson Leung wrote:
>> This is disappointing that Atmel decided to change the bootloader
>> address scheme for the 1664S family. Unfortunately, this ifdef won't
>> work for situations where there are more than one Atmel device of a
>> different kind on a system using this same driver.
>>
>> For the Chromebook Pixel, we use the same atmel_mxt_ts driver for a
>> 1664S device and a 224SL.
>>
>> The 1664S has the pair 0x26 and 0x4a, while the 224SL has 0x25 and
>> 0x4b.
>
> If I put a bootloader address override in the platform data will that meet
> your requirements?



--
Benson Leung
Software Engineer, Chrom* OS
bleung@xxxxxxxxxxxx
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/