Re: [PATCH 2/2] i2c-designware-pci: Index Haswell ULT bus names from 0
From: Benson Leung
Date: Thu Jan 09 2014 - 19:12:23 EST
Hi Wolfram,
Thank you for the advice. Sorry for the delay in my response.
(sorry for the duplicated message. I neglected to set plain text in my
email editor).
On Fri, Jan 3, 2014 at 7:52 AM, Wolfram Sang <wsa@xxxxxxxxxxxxx> wrote:
> > I am not sure I get the problem. If you use i2c_register_board_info() to
> > register the known devices on the designware busses the dynamically
> > assigned numbers are guaranteed to be enumarated higer than the static
> > ones. Check drivers/i2c/i2c-boardinfo.c.
>
> Ping. Was this helpful or do you still have the issue?
Our devices and our platforms have some other requirements which
turned me away from using i2c_register_board_info.
i2c_register_board_info looks to create predeclarations for a specific
i2c bus... However, right now, the chromeos_laptop driver is
structured to do explicit declaration (using i2c_new_probed_device)
*after* the busses have come up.
Specifically, we have a class of atmel_mxt i2c touchpad/touchscreen
devices that may appear at different addresses depending on whether
the touch device is in bootloader mode or operational mode.
For that reason, the chromeos_laptop driver uses i2c_new_probed_device
with a list of possible addresses when dealing with the atmel touch
device.
You can see the driver here :
drivers/platform/chrome/chromeos_laptop.c
Is there some way of getting the "probe" behavior while using
i2c_register_board_info?
--
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/