Towertech tt3201 can cape #9

Since we currently can't export the IIO channels from the ADCs this patch exposes an sysfs entry to read a respective channel. Signed-off-by: Matt Ranostay <mranostay@gmail.com>

Added an example usage of the IIO exporter for an current sensor reading. Scale factor works with INA169 current sensor at 10k load. Signed-off-by: Matt Ranostay <mranostay@gmail.com>

Gave an example on using the kernel-command-line override slot options for capemanager. Signed-off-by: Matt Ranostay <mranostay@gmail.com>

Added a simple MODULE_PARM_DESC for the extra_override option Signed-off-by: Matt Ranostay <mranostay@gmail.com>

Add support for a DS1307 RTC prototype cape with level logic shifted output. Some applications need an early RTC value and this achieves this. Signed-off-by: Matt Ranostay <mranostay@gmail.com>

Catch corner case of division by zero when passing in vsense-scale property from the device tree. Signed-off-by: Matt Ranostay <mranostay@gmail.com>

Signed-off-by: Koen Kooi <koen@dominion.thruhere.net>

Allow multiple ADC entries. DT bindinds are extended so you can do: vsense-name = "AIN1", "AIN3"; vsense-scale = <100 100>; Signed-off-by: Pantelis Antoniou <panto@antoniou-consulting.com>

Signed-off-by: Pantelis Antoniou <panto@antoniou-consulting.com>

…king) modes the default

…th (maximum width in pixels) ti,max_pixelclock (maximum allowable pixel clock for the device) also added some extra debugging enabled with drm debug to help understand why modes are being selected or rejected.

Signed-off-by: Koen Kooi <koen@dominion.thruhere.net>

It's too difficult for now to see how to test those. Temporarily take it out.

Not working yet, since more changes needed, but it's a start.

…messages when deciding if a mode is supported or not

…ntroller, otherwise prune the mode. Also adjust the timing values to behave as the TRM indicates with 0 representing 1 in some cases.

Signed-off-by: Koen Kooi <koen@dominion.thruhere.net>

Support for the Signal 11 MRF24J40 BeagleBone Cape.

am335x-bone-common.dtsi has removed the pinmux settings for SPI1. Add them to the MRF24J40 cape dts fragment Signed-off-by: Alan Ott <alan@signal11.us>

Signed-off-by: Alan Ott <alan@signal11.us>

Signed-off-by: Koen Kooi <koen@dominion.thruhere.net>

Allow capes to be disabled on the kernel command line. Signed-off-by: Pantelis Antoniou <panto@antoniou-consulting.com>

Things like the boot switch are on the LCD data pins. Allows us to change pinmuxing on runtime.

Doesn't work ofcourse due to conflict with the HDMI. Conflicts: firmware/Makefile

Signed-off-by: Koen Kooi <koen@dominion.thruhere.net>

Disable pull up on the pinmux.

Clean up and DTify the pwm_test driver into something that's reasonably useful. Based on work done by Elias & Jack Mitchel. Signed-off-by: Pantelis Antoniou <panto@antoniou-consulting.com>

A simple example of a PWM test based cape. Signed-off-by: Pantelis Antoniou <panto@antoniou-consulting.com>

Signed-off-by: Koen Kooi <koen@dominion.thruhere.net>

Picture only, TS is broken Signed-off-by: Koen Kooi <koen@dominion.thruhere.net>

Add a depth option for device creation. Normally all nodes that represent devices are created, but some devices like gpmc for instance, perform their own device creation. Signed-off-by: Pantelis Antoniou <panto@antoniou-consulting.com>

Add a virtual cape for the GPEVT dma test driver. Signed-off-by: Pantelis Antoniou <panto@antoniou-consulting.com>

We need this exported for the manipulation of the clkout2 external clock. As part of clock rate selection, the parent must change. Signed-off-by: Pantelis Antoniou <panto@antoniou-consulting.com>

The way clkout2 work is no good for external devices needing the clock. A way to select rate, that translates to selecting a parent clock is required for drivers to work. Signed-off-by: Pantelis Antoniou <panto@antoniou-consulting.com>

Update EDMA bindings to work the same way as on the 3.2 kernel Signed-off-by: Pantelis Antoniou <panto@antoniou-consulting.com>

Added UART device tree object to setup UART3 and pinmux. This should work with the RS232 cape that currently exists. Signed-off-by: Matt Ranostay <mranostay@gmail.com>

Signed-off-by: Martin Gysel <me@bearsh.org>

Add ifdefery hacks to only use SRAM on Davinci. This needs to be cleaned up with a sane generic SRAM allocator (like the DT based driver available that can't be used on Davinci which is just starting DT conversion) before it can go upstream. Adds DT, pinctrl, and runtime PM support for use on AM33xx. Signed-off-by: Matt Porter <mporter@ti.com> Signed-off-by: Matt Ranostay <mranostay@gmail.com>

This optional binding extension allows specification of a hwmod and associate hardware reset line which should be deasserted for the device to be functional. The implementation works for reference as to the problem that exists for utilizing uio_pruss on AM33xx but is suboptimal. The problem is that this deassertion occurs before clocks are enabled and we are warned that the hard reset failed. Ideally the list of rst lines requested to be deasserted would be cached and used within the hwmod enable sequencing (instead of it just returning if any hardware reset line is asserted). Signed-off-by: Matt Porter <mporter@ti.com> Signed-off-by: Matt Ranostay <mranostay@gmail.com>

Adds a pruss node and an example of use on Beaglebone. Signed-off-by: Matt Porter <mporter@ti.com> Signed-off-by: Matt Ranostay <mranostay@gmail.com>

Signed-off-by: Elias Bakken <elias.bakken@gmail.com> Signed-off-by: Robert Nelson <robertcnelson@gmail.com>

Pruss shouldn't fail when no child nodes are present.

Simple cape definition for a cape that works on all beaglebones

Added a new driver for the usb part of control module. This has an API to power on the USB2 phy and an API to write to the mailbox depending on whether MUSB has to act in host mode or in device mode. Writing to control module registers for doing the above task which was previously done in omap glue and in omap-usb2 phy will be removed. Signed-off-by: Kishon Vijay Abraham I <kishon@ti.com>

Start using the control module driver for powering on the PHY and for writing to the mailbox instead of writing to the control module registers on their own. Signed-off-by: Kishon Vijay Abraham I <kishon@ti.com>

In order to support platforms which has multiple PHY's (of same type) and which has multiple USB controllers, a new design is adopted wherin the binding information (between the PHY and the USB controller) should be passed to the PHY library from platform specific file (board file). So added a new API to pass the binding information. Signed-off-by: Kishon Vijay Abraham I <kishon@ti.com>

…f same type In order to add support for multipe PHY's of the same type, new API's for adding PHY and getting PHY has been added. Now the binding information for the PHY and controller should be done in platform file using usb_bind_phy API. And for getting a PHY, the device pointer of the USB controller and an index should be passed. Based on the binding information that is added in the platform file, usb_get_phy_dev will return the appropriate PHY. Already existing API's to add and get phy by type is not removed. These API's are deprecated and will be removed once all the platforms start to use the new API. Signed-off-by: Kishon Vijay Abraham I <kishon@ti.com>

This is w.r.t the changes in PHY library to support adding and getting multiple PHYs of the same type. In the new design, the binding information between the PHY and the USB controller should be specified in the platform specific initialization code. So it's been done here for OMAP platforms. Signed-off-by: Kishon Vijay Abraham I <kishon@ti.com>

New PHY lib APIs like usb_add_phy_dev() and devm_usb_get_phy_dev() are used in MUSB (OMAP), in order to make use of the binding information provided in the board file (of OMAP platforms). All the platforms should be modified similar to this to add and get the PHY. Signed-off-by: Kishon Vijay Abraham I <kishon@ti.com>

Added an API devm_usb_get_phy_by_phandle(), to get usb phy by passing a device node phandle value. This function will return a pointer to the phy on success, -EPROBE_DEFER if there is a device_node for the phandle, but the phy has not been added, or a ERR_PTR() otherwise. Cc: Marc Kleine-Budde <mkl@pengutronix.de> Signed-off-by: Kishon Vijay Abraham I <kishon@ti.com>

The OMAP glue has been modified to get PHY by phandle for dt boot. Signed-off-by: Kishon Vijay Abraham I <kishon@ti.com>

It sort of works, but it doesn't handle hotplug. After removing the device, issue lsusb to cause it to scan the bus again. Crappy, I know, but at least works.

Signed-off-by: Vladimir Pantelic <vladoman@gmail.com>

Issue first noticed by: Randy Rodes <randyrodesnn@gmail.com> https://groups.google.com/d/msg/beagleboard/qzlwO9ldULE/kXzFAY9rv8cJ According to the docs, the power value is only 8 bits, to specify 500mA this needs to be set to a value of 250: value * 2 = XmA Documentation/devicetree/bindings/usb/omap-usb.txt Signed-off-by: Robert Nelson <robertcnelson@gmail.com>

Added has_mailbox to the musb platform data to specify that omap uses an external mailbox (in control module) to communicate with the musb core during device connect and disconnect. Signed-off-by: Kishon Vijay Abraham I <kishon@ti.com> Acked-by: Tony Lindgren <tony@atomide.com>

Signed-off-by: Koen Kooi <koen@dominion.thruhere.net>

Add restart hook so that DTS based AM33xx builds can restart the platform. Tested-by: Nishanth Menon <nm@ti.com> Signed-off-by: Jean-Sebastien A. Beaudry <jsabeaudry@handyem.com>

This patch add a generic library for STMicroelectronics 3-axis sensors. Signed-off-by: Denis Ciocca <denis.ciocca@st.com> Reviewed-by: Lars-Peter Clausen <lars@metafoo.de> Signed-off-by: Jonathan Cameron <jic23@kernel.org>

This patch adds a generic accelerometer driver for STMicroelectronics accelerometers, currently it supports: LSM303DLH, LSM303DLHC, LIS3DH, LSM330D, LSM330DL, LSM330DLC, LIS331DLH, LSM303DL, LSM303DLM, LSM330. Signed-off-by: Denis Ciocca <denis.ciocca@st.com> Reviewed-by: Lars-Peter Clausen <lars@metafoo.de> Signed-off-by: Jonathan Cameron <jic23@kernel.org>

This patch adds a generic gyroscope driver for STMicroelectronics gyroscopes, currently it supports: L3G4200D, LSM330DL, L3GD20, L3GD20H, LSM330DLC, L3G4IS, LSM330. Signed-off-by: Denis Ciocca <denis.ciocca@st.com> Reviewed-by: Lars-Peter Clausen <lars@metafoo.de> Signed-off-by: Jonathan Cameron <jic23@kernel.org>

This patch adds a generic magnetometer driver for STMicroelectronics magnetometers, currently it supports: LSM303DLHC, LSM303DLM, LIS3MDL. Signed-off-by: Denis Ciocca <denis.ciocca@st.com> Signed-off-by: Jonathan Cameron <jic23@kernel.org>

This patch add sensors_supported struct to st_magn_sensors. Without this the probe can't match the WhoAmI and sensor name.

…iver Signed-off-by: Koen Kooi <koen@dominion.thruhere.net>

Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>

This fixes the following warning: CC drivers/w1/masters/w1-gpio.o drivers/w1/masters/w1-gpio.c:50:28: warning: ‘w1_gpio_dt_ids’ defined but not used [-Wunused-variable] Also provide stub for w1_gpio_probe_dt() if device tree support is disabled. Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>

The platform data in the dveice structure does not belong to the driver and so it should not be trying to alter it, but instead use a local pointer and populate it with a local copy in case we are dealing with device tree setup. Also allow mixed setups where platform data coexists with device tree and prefer kernel-supplied data (it may be easier to fiddle in kernel structure before committing final result to device tree). Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>

This simplifies error unwinding and device teardown. Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>

When setting the GPMC device type, make sure any previous bits are cleared down, before applying the new setting. For OMAP4+ devices MUXADDDATA is a 2-bit field (bits 9:8) where as for OMAP2/3 devices it was only a one bit field (bit 9). For OMAP2/3 devices bit 8 is reserved and the OMAP documentation says to write a 0 to this bit. So clearing bit 8 on OMAP2/3 devices should not be a problem. Hence update the code to handle both bits 8 and 9 for all devices. Signed-off-by: Mark Jackson <mpfj@newflow.co.uk> [jon-hunter@ti.com: updated changelog] Signed-off-by: Jon Hunter <jon-hunter@ti.com>

This patch marks a bunch of functions that are local to gpmc.c file only as static. Signed-off-by: Ezequiel Garcia <ezequiel.garcia@free-electrons.com> Reviewed-by: Jon Hunter <jon-hunter@ti.com> Signed-off-by: Jon Hunter <jon-hunter@ti.com>

This function is not used anywhere, so it's safe to remove it. This means less code to maintain. Signed-off-by: Ezequiel Garcia <ezequiel.garcia@free-electrons.com> Reviewed-by: Jon Hunter <jon-hunter@ti.com> Signed-off-by: Jon Hunter <jon-hunter@ti.com>

Currently gpmc_cs_reserved() return value is somewhat inconsistent, returning a negative value on an error condition, a positive value if the chip select is reserved and zero if it's available. Fix this by returning a boolean value as the function name suggests: * true if the chip select is reserved, * false if it's available Suggested-by: Felipe Balbi <balbi@ti.com> Signed-off-by: Ezequiel Garcia <ezequiel.garcia@free-electrons.com> Reviewed-by: Jon Hunter <jon-hunter@ti.com> Signed-off-by: Jon Hunter <jon-hunter@ti.com>

If CS request fails the current error message is rather unhelpful. Fix it by printing the failing chip select and the error code. Signed-off-by: Ezequiel Garcia <ezequiel.garcia@free-electrons.com> Reviewed-by: Jon Hunter <jon-hunter@ti.com> Signed-off-by: Jon Hunter <jon-hunter@ti.com>

Do this becasue dev_err() is preferred over pr_err() and because it will match gpmc-nand, thus the code shows looks more consistent. Signed-off-by: Ezequiel Garcia <ezequiel.garcia@free-electrons.com> Reviewed-by: Jon Hunter <jon-hunter@ti.com> Signed-off-by: Jon Hunter <jon-hunter@ti.com>

Since the condition is not an error but a warning, replace printk KERN_ERR with dev_warn. Signed-off-by: Ezequiel Garcia <ezequiel.garcia@free-electrons.com> Reviewed-by: Jon Hunter <jon-hunter@ti.com> Signed-off-by: Jon Hunter <jon-hunter@ti.com>

This check is done before the call to gpmc_cs_reserved() and gpmc_cs_set_reserved() and it's redundant to do it again in each function. This simplifies the code a bit. Signed-off-by: Ezequiel Garcia <ezequiel.garcia@free-electrons.com> Reviewed-by: Jon Hunter <jon-hunter@ti.com> Signed-off-by: Jon Hunter <jon-hunter@ti.com>

The OMAP2+ code that configures the GPMC for ONENAND devices is copying structures between functions unnecessarily. Avoid this by passing pointers instead and simplify the code. A pointer to structure "omap_onenand_platform_data" is passed to the function omap2_onenand_calc_sync_timings(), but only the flags member of the structure is used. Simplify the code by only passing the flags member and not the entire structure. Signed-off-by: Jon Hunter <jon-hunter@ti.com> Tested-by: Ezequiel Garcia <ezequiel.garcia@free-electrons.com>

The GPMC has wait-pin signals that can be assigned to a chip-select to monitor the ready signal of an external device. Add a variable to indicate the total number of wait-pins for a given device. This will allow us to detect if the wait-pin being selected is valid or not. When booting with device-tree read the number of wait-pins from the device-tree blob. When device-tree is not used set the number of wait-pins to 4 which is valid for OMAP2-5 devices. Newer devices that have less wait-pins (such as AM335x) only support booting with device-tree and so hard-coding the wait-pin number when not using device-tree is fine. Signed-off-by: Jon Hunter <jon-hunter@ti.com> Tested-by: Ezequiel Garcia <ezequiel.garcia@free-electrons.com>

The GPMC has various different configuration options such as bus-width, synchronous or asychronous mode selection, burst mode options etc. Currently, there is no central structure for storing all these options when configuring the GPMC for a given device. Some of the options are stored in the GPMC timing structure and some are directly programmed into the GPMC configuration register. Add a new structure to store these options and convert code to use this structure. Adding this structure will allow us to create a common function for configuring these options. Signed-off-by: Jon Hunter <jon-hunter@ti.com> Tested-by: Ezequiel Garcia <ezequiel.garcia@free-electrons.com>

The GPMC has various different configuration options such as bus-width, synchronous or asychronous mode selection, burst mode options etc. Currently, there is no common function for configuring these options and various devices set these options by either programming the GPMC CONFIG1 register directly or by calling gpmc_cs_configure() to set some of the options. Add a new function for configuring all of the GPMC options. Having a common function for configuring this options will simplify code and ease the migration to device-tree. Also add a new capability flag to detect devices that support the address-address-data multiplexing mode. Signed-off-by: Jon Hunter <jon-hunter@ti.com> Tested-by: Ezequiel Garcia <ezequiel.garcia@free-electrons.com>

Convert the OMAP2+ ONENAND code to use the gpmc_cs_program_settings() function for configuring the various GPMC options instead of directly programming the CONFIG1 register. Signed-off-by: Jon Hunter <jon-hunter@ti.com> Tested-by: Ezequiel Garcia <ezequiel.garcia@free-electrons.com>

Convert the OMAP2+ NAND code to use the gpmc_cs_program_settings() function for configuring the various GPMC options instead of directly programming the CONFIG1 register. This moves the configuration of some GPMC options outside the nand_gpmc_retime() because these options should only need to be set once regardless of whether the gpmc timing is changing dynamically at runtime. The programming of where the wait-pin is also moved slightly, but this will not have any impact to existing devices as no boards are currently setting the dev_ready variable. Signed-off-by: Jon Hunter <jon-hunter@ti.com> Tested-by: Ezequiel Garcia <ezequiel.garcia@free-electrons.com>

Convert the OMAP2+ SMC91x code to use the gpmc_cs_program_settings() function for configuring the various GPMC options instead of directly programming the CONFIG1 register. Move configuration of the GPMC settings outside retime function and this does not need to be done if the timings are changed dynamically at runtime. Signed-off-by: Jon Hunter <jon-hunter@ti.com> Tested-by: Ezequiel Garcia <ezequiel.garcia@free-electrons.com>

Convert the OMAP2+ TUSB code to use the gpmc_cs_program_settings() function for configuring the various GPMC options instead of directly programming the CONFIG1 register. Signed-off-by: Jon Hunter <jon-hunter@ti.com> Tested-by: Ezequiel Garcia <ezequiel.garcia@free-electrons.com>

…ure() With the addition of the gpmc_cs_program_settings(), we no longer need or use gpmc_cs_configure() to configure some of the GPMC chip-select options. So rename the function to gpmc_configure() and remove code that modifies options in the CONFIG1 register. Signed-off-by: Jon Hunter <jon-hunter@ti.com> Tested-by: Ezequiel Garcia <ezequiel.garcia@free-electrons.com>

Adds a function to read the various GPMC chip-select settings from device-tree and store them in the gpmc_settings structure. Update the GPMC device-tree binding documentation to describe these options. Signed-off-by: Jon Hunter <jon-hunter@ti.com> Tested-by: Ezequiel Garcia <ezequiel.garcia@free-electrons.com>

Some of the GPMC timings parameters are currently missing from the GPMC device-tree binding. Add these parameters to the binding documentation as well as code to read them. Also add either "-ps" or "-ns" suffix to the GPMC timing properties to indicate whether the timing is in picoseconds or nanoseconds. The existing code in gpmc_read_timings_dt() is checking the value of of_property_read_u32() and only is successful storing the value read in the gpmc_timings structure. Checking the return value in this case is not necessary and we can simply read the value, if present, and store directly in the gpmc_timings structure. Therefore, simplify the code by removing these checks. The comment in the gpmc_read_timings_dt() function, "only for OMAP3430" is also incorrect as it is applicable to all OMAP3+ devices. So correct this too. Signed-off-by: Jon Hunter <jon-hunter@ti.com> Tested-by: Ezequiel Garcia <ezequiel.garcia@free-electrons.com>

NOR flash is not currently supported when booting with device-tree on OMAP2+ devices. Add support to detect and configure NOR devices when booting with device-tree. Add documentation for the TI GPMC NOR binding. Signed-off-by: Jon Hunter <jon-hunter@ti.com> Tested-by: Ezequiel Garcia <ezequiel.garcia@free-electrons.com>

When booting with device-tree, retrieve GPMC settings for NAND from the device-tree blob. This will allow us to remove all static settings stored in the gpmc-nand.c in the future once the migration to device-tree is complete. Signed-off-by: Jon Hunter <jon-hunter@ti.com> Tested-by: Ezequiel Garcia <ezequiel.garcia@free-electrons.com>

When booting with device-tree, retrieve GPMC settings for ONENAND from the device-tree blob. This will allow us to remove all static settings stored in the gpmc-nand.c in the future once the migration to device-tree is complete. The user must now specify the ONENAND device width in the device-tree binding so that the GPMC can be programmed correctly. Therefore, update the device-tree binding documentation for ONENAND devices connected to the GPMC to reflect this. Please note that this does not include GPMC timings for ONENAND. The timings are being calculated at runtime. There is some legacy code that only enables read wait monitoring for non-OMAP3 devices. There are no known OMAP3 device issues that prevent this feature being enabled and so when booting with device-tree use the wait-monitoring settings described in the device-tree blob. Signed-off-by: Jon Hunter <jon-hunter@ti.com> Tested-by: Ezequiel Garcia <ezequiel.garcia@free-electrons.com>

Each GPMC chip-select can be configured to map 16MB, 32MB, 64MB or 128MB of address space. The physical base address where a chip-select starts is also configurable and must be aligned on a boundary that is equal to or greater than the size of the address space mapped bt the chip-select. When enabling a GPMC chip-select, ensure that the base address is aligned to the appropriate boundary. Reported-by: Mark Jackson <mpfj-list@mimc.co.uk> Signed-off-by: Jon Hunter <jon-hunter@ti.com> Tested-by: Ezequiel Garcia <ezequiel.garcia@free-electrons.com>

With commit 21cc2bd (ARM: OMAP2+: Remove apollon board support) the variable "boot_rom_space" is now not needed and the code surrounding this variable can be cleaned up and simplified. Remove unnecessary definitions and clean-up the comment as well. Signed-off-by: Jon Hunter <jon-hunter@ti.com> Tested-by: Ezequiel Garcia <ezequiel.garcia@free-electrons.com>

When the GPMC driver is probed, we call gpmc_mem_init() to see which chip-selects have already been configured and enabled by the boot-loader and allocate space for them. If we fail to allocate space for one chip-select, then we return failure from the probe and the GPMC driver will not be available. Rather than render the GPMC useless for all GPMC devices, if we fail to allocate space for one chip-select print a warning and disable the chip-select. This way other GPMC clients can still be used. There is no downside to this approach, because all GPMC clients need to request a chip-select before they can use the GPMC and on requesting a chip-select, if memory has not already been reserved for the chip-select then it will be. Signed-off-by: Jon Hunter <jon-hunter@ti.com> Tested-by: Ezequiel Garcia <ezequiel.garcia@free-electrons.com>

gpmc_probe_nor_child() calls of_platform_device_create() to create a platform device for the NOR child. If this function fails the value of ret is returned to the caller but this value is zero since it was assigned the return of a previous call to gpmc_cs_program_settings() that had to succeed or otherwise gpmc_probe_nor_child() would have returned before. This means that if of_platform_device_create() fails, 0 will be returned to the caller instead of an appropriate error code. Signed-off-by: Javier Martinez Canillas <javier.martinez@collabora.co.uk> Signed-off-by: Jon Hunter <jon-hunter@ti.com> Tested-by: Ezequiel Garcia <ezequiel.garcia@free-electrons.com>

The gpmc_probe_nor_child() function is used in the GPMC driver to configure the GPMC for a NOR child device node. But this function is quite generic and all the NOR specific configuration is made by the driver of the actual NOR flash memory used. Other Pseudo-SRAM devices such as ethernet controllers need a similar setup so by making this function generic it can be used for those too. Signed-off-by: Javier Martinez Canillas <javier.martinez@collabora.co.uk> Signed-off-by: Jon Hunter <jon-hunter@ti.com>

Besides being used to interface with external memory devices, the General-Purpose Memory Controller can be used to connect Pseudo-SRAM devices such as ethernet controllers to OMAP2+ processors using the TI GPMC as a data bus. This patch allows an ethernet chip to be defined as an GPMC child device node. Signed-off-by: Javier Martinez Canillas <javier.martinez@collabora.co.uk> Signed-off-by: Jon Hunter <jon-hunter@ti.com>

Pass an optional device_node pointer in the platform data, which in turn will be put into a mtd_part_parser_data. This way, code that sets up the platform devices can pass along the node from DT so that the partitions can be parsed. For non-DT boards, this change has no effect. Signed-off-by: Daniel Mack <zonque@gmail.com> Acked-by: Grant Likely <grant.likely@secretlab.ca> Acked-by: Artem Bityutskiy <dedekind1@gmail.com> Signed-off-by: Tony Lindgren <tony@atomide.com>

gpmc_nand_init() will be called from another driver's probe() function, so the easiest way to prevent section mismatches is to drop the annotation here. Signed-off-by: Daniel Mack <zonque@gmail.com> Acked-by: Grant Likely <grant.likely@secretlab.ca> Signed-off-by: Tony Lindgren <tony@atomide.com>

The am33xx is capable of handling bch error correction modes, so enable that feature in the driver. Signed-off-by: Daniel Mack <zonque@gmail.com> Acked-by: Grant Likely <grant.likely@secretlab.ca> Signed-off-by: Tony Lindgren <tony@atomide.com>

On DT driven boards, the gpmc node will match the driver. Hence, there's no need to do that unconditionally from the initcall. Signed-off-by: Daniel Mack <zonque@gmail.com> Acked-by: Grant Likely <grant.likely@secretlab.ca> Signed-off-by: Tony Lindgren <tony@atomide.com>

gpmc_onenand_init() will be called from another driver's probe() function, so drop the __init annotation, in order to prevent section mismatches. Signed-off-by: Ezequiel Garcia <ezequiel.garcia@free-electrons.com> Signed-off-by: Tony Lindgren <tony@atomide.com>

Signed-off-by: Pantelis Antoniou <panto@antoniou-consulting.com>

Pass an optional device_node pointer in the platform data, which in turn will be put into a mtd_part_parser_data. This way, code that sets up the platform devices can pass along the node from DT so that the partitions can be parsed. For non-DT boards, this change has no effect. Acked-by: Artem Bityutskiy <artem.bityutskiy@linux.intel.com> Signed-off-by: Ezequiel Garcia <ezequiel.garcia@free-electrons.com> Signed-off-by: Tony Lindgren <tony@atomide.com>

Convert the OMAP2+ ONENAND code to use the gpmc_cs_program_settings() function for configuring the various GPMC options instead of directly programming the CONFIG1 register. Signed-off-by: Jon Hunter <jon-hunter@ti.com> Tested-by: Ezequiel Garcia <ezequiel.garcia@free-electrons.com> Conflicts: arch/arm/mach-omap2/gpmc-onenand.c

Various fixes: * clk_activation option added * pinctrl support add * Add camera device * Fix child node handling Signed-off-by: Pantelis Antoniou <panto@antoniou-consulting.com>

Add am33xx gpmc device. Signed-off-by: Pantelis Antoniou <panto@antoniou-consulting.com>

A recent patch refactored i2c error handling in the register read/write path. This adds similar handling to the other i2c paths used in fw_update and bootloader state detection. The generic i2c layer can return values indicating a partial transaction. From the atmel_mxt driver's perspective, this is an IO error, so we use some helper functions to convert these partial transfers to -EIO in a uniform way. Other error codes might still be useful, though, so we pass them up unmodified. Signed-off-by: Daniel Kurtz <djkurtz@chromium.org> Change-Id: I59eabbb80dea610a89c01a3be06f0d165f4b4431

As soon as the irq is request, input event interrupts could occur that the isr should handle. Similarly, if there are input events queued up in the device output buffer, it will send them immediately when we drain the message buffer with mxt_handle_messages. Therefore, register the input device before enabling the irq (or handling messages). Signed-off-by: Daniel Kurtz <djkurtz@chromium.org> BUG=chromium-os:27713 TEST=cat /sys/bus/i2c/drivers/atmel_mxt_ts/2-004b/object Change-Id: I16172901d963cd2e60533e12e455012cb62cdfe5 Reviewed-on: https://gerrit.chromium.org/gerrit/21061 Commit-Ready: Daniel Kurtz <djkurtz@chromium.org> Reviewed-by: Daniel Kurtz <djkurtz@chromium.org> Tested-by: Daniel Kurtz <djkurtz@chromium.org> [djkurtz: v3.8 rebase]

Move input device initialization to its own helper function. This is in preparation of a future patch that makes input device conditional on the device not being in its bootloader. Signed-off-by: Daniel Kurtz <djkurtz@chromium.org> BUG=chrome-os-partner:9103 TEST=builds clean; input device created as before. Change-Id: Ife128dc63a4c23c162ed116c21cc0dd3d076a559 Reviewed-on: https://gerrit.chromium.org/gerrit/20844 Commit-Ready: Daniel Kurtz <djkurtz@chromium.org> Reviewed-by: Daniel Kurtz <djkurtz@chromium.org> Tested-by: Daniel Kurtz <djkurtz@chromium.org> [djkurtz: v3.8-rc3 rebase]

In some cases it is possible for a device to be in its bootloader at driver probe time. This is detected by the driver when probe() is called with an i2c_client which has one of the Atmel Bootloader i2c addresses. In this case, we should load enough driver functionality to still loading new firmware using: echo 1 > update_fw However, we must be very careful not to follow any code paths that would try to access the as-yet uninitialized object table or input device. In particular: 1) mxt_remove calls input_unregister_device on input_dev. 2) mxt_suspend/resume reads and writes from the object table. 3) Spurious or bootloader induced interrupts Signed-off-by: Benson Leung <bleung@chromium.org> Signed-off-by: Daniel Kurtz <djkurtz@chromium.org> BUG=chrome-os-partner:8733, chrome-os-partner:16507 TEST=Interrupt a firmware update. Boot the system. Ensure that the atmel_mxt_ts driver brings up the device using one of the two MXT_BOOT i2c addresses. From there, it should be possible to echo 1 > update_fw and recover. TEST=First, get the touch device into a bad state by doing the following: 1. Modify chromeos/config/base.config and set CONFIG_TOUCHSCREEN_ATMEL_MXT=m 2. Build, boot this kernel, and make sure that the touch device works. 3. /opt/google/touch/firmware/chromeos-touch-firmwareupdate.sh \ -d atmel_mxt_ts -n maxtouch-ts.fw -f 4. Before it can finish, CTRL-C to interrupt the firmware update. This will ensure that the touch device is stuck in bootloader mode. TEST=No crash on mxt_remove: 1. rmmod atmel_mxt_ts 2. check that the system does not reboot. 3. modprobe chromeos_mxt_ts TEST=No crash on suspend/resume: 1. Close the lid to suspend the system. 2. Open the lid to suspend the system. 3. Check that the system did not reboot. Original-Change-Id: If86e6f0065bb24a5da340ac69adca4ac61d675c9 Reviewed-on: https://gerrit.chromium.org/gerrit/19637 Original-Change-Id: I83e517d21738cb75d0c2b0ab8bf16398044e52f3 Reviewed-on: https://gerrit.chromium.org/gerrit/39022 Reviewed-by: Yufeng Shen <miletus@chromium.org> Commit-Ready: Benson Leung <bleung@chromium.org> Tested-by: Benson Leung <bleung@chromium.org> v3.7 rebase: Signed-off-by: Daniel Kurtz <djkurtz@chromium.org> Change-Id: I2b65ec6cc3c9506372499785f4f8599faf4aa353

If there are any (i2c) errors during fw update, abort the update, but leave the i2c address assigned to the bootloader address. Note that an error when trying to reset the device into the bootloader will leave the i2c address assigned to the application address. Signed-off-by: Benson Leung <bleung@chromium.org> Signed-off-by: Daniel Kurtz <djkurtz@chromium.org> Change-Id: I2933505115dd55aa4dcf07e333f0e1d56e9e246e

…store after After firmware update, the device may have a completely different object table which corresponds to an input device with different properties. So, destroy the old state before firmware update, and completely reinitialize the driver afterward. Two benefits of this: 1) Since there is no input device during fw update, no need to worry about device open/close events. 2) If firmware update fails, the device and driver will still be in bootloader mode and an improperly configured input device will not exist. Change-Id: I42e6b946e2206b4957c313be00b9b45b9dd02b60 Signed-off-by: Daniel Kurtz <djkurtz@chromium.org>

Refactor bootloading into a three parts: 1) bl enter that only happens when device is not yet in bl. bl enter frees old driver state and switches to BL i2c addr. 2) the actual fw_update 3) bl exit that only happens if fw update is successful. bl exit switches to APP i2c addr and reloads object table and creates a new input device. Signed-off-by: Benson Leung <bleung@chromium.org> Signed-off-by: Daniel Kurtz <djkurtz@chromium.org> Signed-off-by: Yufeng Shen <miletus@chromium.org> BUG=chrome-os-partner:8716,chrome-os-partner:9103,chrome-os-partner:10688 TEST=Place an firmware file at /lib/firmware/maxtouch.fw echo 1 > update_fw Ensure that a normal firmware update works. TEST=update the firmware and then check that the input device is still working, by using evtest/xinput. TEST=The following instructions will write the wrong firmware to the touchpad device. 1. cd /sys/bus/i2c/devices/1-004b 2. echo maxtouch-ts.fw > fw_file 3. echo 1 > update_fw 4. dmesg | tail This will result in a failed touchpad update. Check that dmesg shows: [ 158.495164] atmel_mxt_ts 1-004b: bootloader version: 32 [ 170.563491] atmel_mxt_ts 1-004b: mxt_read_reg: i2c read failed [ 170.563513] atmel_mxt_ts 1-004b: Failed to initialize on exit bl. error = -6 Check that the system does not panic in this situation. To recover from this state, simply shut the machine down completely using sudo shutdown -P now Original-Change-Id: I49bf582be90ffc8c4dd2696413ceff060fd8926e Reviewed-on: https://gerrit.chromium.org/gerrit/21831 Original-Change-Id: I2ec8b4c96954151495238c450301eddd48085e18 Reviewed-on: https://gerrit.chromium.org/gerrit/23256 Reviewed-by: Daniel Kurtz <djkurtz@chromium.org> Tested-by: Yufeng Shen <miletus@chromium.org> Commit-Ready: Yufeng Shen <miletus@chromium.org> Original-Change-Id: Ib773efd8b76aced9f5faab0b51745db7192e78f9 Reviewed-on: https://gerrit.chromium.org/gerrit/37860 v3.7 rebase: Signed-off-by: Daniel Kurtz <djkurtz@chromium.org>

…loader The driver should not immediately read bootloader status when in Application Update Mode. The CHG line will assert when the device has made a state transition and is ready to report a new status via i2c. This change adds a wait for completion in mxt_check_bootloader, and changes the mxt_interrupt handler to signal the completion. This will allow this commit in the intel_i2c driver to be reverted, as the time is no longer spent waiting for i2c read: 3414f39 CHROMIUM: drm/i915/intel_i2c: Increase bitbang fallback timeout for atmel_mx Signed-off-by: Benson Leung <bleung@chromium.org> BUG=chrome-os-partner:8730 TEST=(a) Verify when device not in BL (normal case), no functional change. TEST=(b) Verify fw update works, and device is initialized properly after. Change-Id: I5d20a9d63361fb91cb59aa7351e581f55422b924 Reviewed-on: https://gerrit.chromium.org/gerrit/21173 v3.7 rebase: Signed-off-by: Daniel Kurtz <djkurtz@chromium.org>

Rather than msleep for MXT_RESET_TIME and MXT_FWRESET_TIME during the transition to bootloader mode and the transition back from app, wait for the CHG assert to indicate that the transition is done. This change replaces the msleep with a wait for completion that the mxt_interrupt handler signals. This improves firmware update time at 300ms as we no longer wait longer than necessary for each reset. Signed-off-by: Benson Leung <bleung@chromium.org> BUG=chrome-os-partner:8716,chrome-os-partner:8732 TEST=Verify fw update works, and device is initialized properly after. Change-Id: Id8982144d3966ccd8227da2a2ea47f9e73115d8e Reviewed-on: https://gerrit.chromium.org/gerrit/21832 v3.7 rebase: Signed-off-by: Daniel Kurtz <djkurtz@chromium.org>

Changed to support address on new part. This is contrary to Atmel documentation, and we are still working with them to clear up this inconsistency. In the meantime, change it for now to allow existing systems to update. BUG=chrome-os-partner:8734 TEST=Firmware update works. Change-Id: Ib2db2a066126df291c7a85208743c80c5357d55d Signed-off-by: Benson Leung <bleung@chromium.org> Reviewed-on: https://gerrit.chromium.org/gerrit/19639 Reviewed-by: Daniel Kurtz <djkurtz@chromium.org>

175ms is not enough time to update the firmware. Set to 500ms. BUG=chrome-os-partner:8731 TEST=firmware update. ensure that transitions back to app mode at the end. Change-Id: Idaec72cb4f326a10d3513ffb82bf4b144c68b30c Signed-off-by: Benson Leung <bleung@chromium.org> Reviewed-on: https://gerrit.chromium.org/gerrit/19640 Reviewed-by: Daniel Kurtz <djkurtz@chromium.org>

In some situations, a touch surface may get out of calibration. It is useful to provide a means for userspace to trigger a recal, so add a calibrate sysfs entry. Signed-off-by: Daniel Kurtz <djkurtz@chromium.org> BUG=chrome-os-partner:9148 TEST=echo 1 > /sys/bus/i2c/drivers/atmel_mxt_ts/<dev>/calibrate Change-Id: Idbdd7bf4f412f03e36604a2a1fae162f059234d3 Reviewed-on: https://gerrit.chromium.org/gerrit/20812 Reviewed-by: Daniel Kurtz <djkurtz@chromium.org> Tested-by: Daniel Kurtz <djkurtz@chromium.org> Commit-Ready: Daniel Kurtz <djkurtz@chromium.org> v3.7 rebase: Signed-off-by: Daniel Kurtz <djkurtz@chromium.org>

Config checksum is returned in the T6 message at every boot, and when the config changes. Cache its value and add sysfs entry for userspace to read it. Signed-off-by: Daniel Kurtz <djkurtz@chromium.org> BUG=chrome-os-partner:9103 TEST=cat /sys/bus/i2c/drivers/atmel_mxt_ts/2-004b/config_csum Change-Id: Ic546d1671e9f6a3da598f06a31f76a6ca96ce235 Reviewed-on: https://gerrit.chromium.org/gerrit/20597 Commit-Ready: Daniel Kurtz <djkurtz@chromium.org> Reviewed-by: Daniel Kurtz <djkurtz@chromium.org> Tested-by: Daniel Kurtz <djkurtz@chromium.org> Reviewed-by: Benson Leung <bleung@chromium.org> v3.7 rebase: Signed-off-by: Daniel Kurtz <djkurtz@chromium.org>

The device stores the Information Block Checksum in the 3 bytes immediately following the Information Block. Read these three bytes, cache the value, and add a sysfs entry so userspace can read it. Signed-off-by: Daniel Kurtz <djkurtz@chromium.org> BUG=chrome-os-partner:9103 TEST=cat /sys/bus/i2c/drivers/atmel_mxt_ts/2-004b/info_csum Change-Id: I27512c624bad15674bc7c50c15717913595affe4 Reviewed-on: https://gerrit.chromium.org/gerrit/20599 Reviewed-by: Benson Leung <bleung@chromium.org> Commit-Ready: Daniel Kurtz <djkurtz@chromium.org> Reviewed-by: Daniel Kurtz <djkurtz@chromium.org> Tested-by: Daniel Kurtz <djkurtz@chromium.org> v3.7 rebase: Signed-off-by: Daniel Kurtz <djkurtz@chromium.org>

Compute 24 bit CRC over entire Information Block (ID info plus Object Table), and verify that it matches checksum read from the device. Signed-off-by: Daniel Kurtz <djkurtz@chromium.org> BUG=chrome-os-partner:9103 TEST=Verify atmel device is discovered and operates as before. Change-Id: Ic20f585abf6726e7ff5e2cc4afd7ae805180b81d Reviewed-on: https://gerrit.chromium.org/gerrit/20600 Commit-Ready: Daniel Kurtz <djkurtz@chromium.org> Reviewed-by: Daniel Kurtz <djkurtz@chromium.org> Tested-by: Daniel Kurtz <djkurtz@chromium.org> v3.7 rebase: Signed-off-by: Daniel Kurtz <djkurtz@chromium.org>

Returns the number of X and Y sense lines. This entry will be used by userspace for determining the dimensions of the T37 arrays that will be returned by deltas and refs debugfs entries. Signed-off-by: Daniel Kurtz <djkurtz@chromium.org> BUG=chromium-os:29899 TEST=cat /sys/bus/i2c/drivers/atmel_mxt_ts/<dev>/matrix_size Change-Id: I3f6414a1eaa09f51d345256e7f1bb90bdbbc528f Reviewed-on: https://gerrit.chromium.org/gerrit/21458 Commit-Ready: Daniel Kurtz <djkurtz@chromium.org> Reviewed-by: Daniel Kurtz <djkurtz@chromium.org> Tested-by: Daniel Kurtz <djkurtz@chromium.org> v3.7 rebase: Signed-off-by: Daniel Kurtz <djkurtz@chromium.org>

…instances These two object table entry fields are reported 1 less than their value. When used, however, we always want the actual size and instances. To keep the object size and instances 1-byte fields, and thus preserve the object-table struct's 6-byte packed alignment, add some convenient accessor functions that do the +1 every time these fields are accessed. Signed-off-by: Daniel Kurtz <djkurtz@chromium.org> BUG=chromium-os:27713 TEST=Confirm object table is read correctly: cat /sys/bus/i2c/devices/<dev>/object Change-Id: If303428b09e8ad5516bae8f2eccb3fd1c386192d Reviewed-on: https://gerrit.chromium.org/gerrit/17946 Commit-Ready: Daniel Kurtz <djkurtz@chromium.org> Reviewed-by: Daniel Kurtz <djkurtz@chromium.org> Tested-by: Daniel Kurtz <djkurtz@chromium.org> v3.7 rebase: Signed-off-by: Daniel Kurtz <djkurtz@chromium.org>

This patch just creates a per-device debugfs root directory. Actual debugfs entries will be added in subsequent patches. Signed-off-by: Daniel Kurtz <djkurtz@chromium.org> BUG=chromium-os:29899 TEST=ls /sys/kernel/debug/atmel_mxt_ts => Should show directories for each atmel_mxt_ts device on the system Change-Id: I82e5470f5d1658dae03ad8d66bf348cc4fb2edb2 Reviewed-on: https://gerrit.chromium.org/gerrit/21051 Commit-Ready: Daniel Kurtz <djkurtz@chromium.org> Reviewed-by: Daniel Kurtz <djkurtz@chromium.org> Tested-by: Daniel Kurtz <djkurtz@chromium.org> v3.7 rebase: Signed-off-by: Daniel Kurtz <djkurtz@chromium.org>

Reading these two debugfs entries returns a binary blob containing the contents of all pages of the T37 object when the DELTAS and REFERENCES commands are requested, respectively. The values are written to the file as they are arranged in the device's T37 object, that is, as a 2D array with matrix_ysize columns and matrix_xsize rows of 2-byte (little endian) values. It is left to userspace to parse the 2-byte values. * Deltas are signed 2's complement 2-byte little-endian values. s32 delta = (b[0] + (b[1] << 8)); * Refs are signed 'offset binary' 2-byte little-endian values, with offset 16384 (0x4000): s32 ref = (b[0] + (b[1] << 8)) - 16384; Userspace should use the 'matrix_size' sysfs entry to determine the dimensions of the returned arrays. Signed-off-by: Daniel Kurtz <djkurtz@chromium.org> BUG=chromium-os:29899 TEST=hexdump -e '52/2 "%6d" "\n"' /sys/kernel/debug/atmel_mxt_ts/<dev>/deltas => dumps 'delta' values in a 52-column wide grid TEST=hexdump -e '12/2 "%6d" "\n"' /sys/kernel/debug/atmel_mxt_ts/<dev>/deltas => dumps the 'ref' values in a 12-column wide grid Change-Id: I9deb64074dd9947739961aa4323573f4544e9dc1 Reviewed-on: https://gerrit.chromium.org/gerrit/21052 Commit-Ready: Daniel Kurtz <djkurtz@chromium.org> Reviewed-by: Daniel Kurtz <djkurtz@chromium.org> Tested-by: Daniel Kurtz <djkurtz@chromium.org> v3.7 rebase: Signed-off-by: Daniel Kurtz <djkurtz@chromium.org>

This same driver can be used by atmel based touchscreens and touchpads (buttonpads) by instantiating the i2c device as a "atmel_mxt_tp". This will cause the driver to perform some touchpad specific initializations, such as: * register input device name "Atmel maXTouch Touchpad" instead of Touchscreen. * register BTN_LEFT & BTN_TOOL_* event types. * register axis resolution (as a fixed constant, for now) * register BUTTONPAD property * process GPIO buttons using reportid T19 Signed-off-by: Daniel Kurtz <djkurtz@chromium.org> BUG=chromium-os:27714 TEST=builds clean; atmel tp works using ddc lines and cmt Change-Id: Ifb5cff5667156ca48c1ca90e5e8eea0c434480df Reviewed-on: https://gerrit.chromium.org/gerrit/17959 Commit-Ready: Benson Leung <bleung@chromium.org> Reviewed-by: Benson Leung <bleung@chromium.org> Tested-by: Benson Leung <bleung@chromium.org> v3.7 rebase: Signed-off-by: Daniel Kurtz <djkurtz@chromium.org>

Currently mxt_calc_resolution() computes device resolution from provided platform data. Since we are going to support loading configuration data from file instead of platform data, we rework mxt_calc_resolution() so it reads the actual resolution from the configured device memory. And also move mxt_calc_resolution() into mxt_initialize() after the device is configured. BUG=chrome-os-partner:9103 TEST=Use evtest to check that the range of ABS_X/Y and ABS_MT_POSITION_X/Y are correct. Change-Id: Ibf66af4c656b138b52ce5608d7357bf15ee423ac Signed-off-by: Yufeng Shen <miletus@chromium.org> Reviewed-on: https://gerrit.chromium.org/gerrit/21544 Reviewed-by: Daniel Kurtz <djkurtz@chromium.org> v3.7 rebase: Signed-off-by: Daniel Kurtz <djkurtz@chromium.org>

The TCHAREA field reported from the device is in terms of channels covered by the touch, while ABS_MT_TOUCH_MAJOR is expected to be in the units the same as the configured device resolution. So we approximate the touch contact as a circle, convert the touch area from channel numbers to pixel numbers, and compute the diameter of the circle touch as the value of ABS_MT_TOUCH_MAJOR. Signed-off-by: Yufeng Shen <miletus@chromium.org> Signed-off-by: Daniel Kurtz <djkurtz@chromium.org> BUG=chrome-os-partner:9968 TEST=using evtest to check the range of ABS_MT_TOUCH_MAJOR is now somewhat between 50 ~ 100, instead of 1 ~ 10 while making normal touching. Change-Id: I9972a4989a18b9fbe4fdf1edd70330a4e9df3f85 Reviewed-on: https://gerrit.chromium.org/gerrit/24530 Commit-Ready: Yufeng Shen <miletus@chromium.org> Reviewed-by: Yufeng Shen <miletus@chromium.org> Tested-by: Yufeng Shen <miletus@chromium.org> v3.7 rebase: Signed-off-by: Daniel Kurtz <djkurtz@chromium.org>

Add new object types to support newer mxt devices. BUG=chrome-os-partner:8732 TEST=None yet. Change-Id: I5b7c8987ec4d98fc678a939154b7a057338037bd Signed-off-by: Benson Leung <bleung@chromium.org> Reviewed-on: https://gerrit.chromium.org/gerrit/19638 Reviewed-by: Daniel Kurtz <djkurtz@chromium.org> Reviewed-by: Vadim Bendebury <vbendeb@chromium.org>

…d reset Increase the sleep times after backup and reset, so that we can be sure they have been completed even when the mXT cycle time is set to maximum value (254ms). Signed-off-by: Iiro Valkonen <iiro.valkonen@atmel.com> Patch is in progress of being submitted at http://www.spinics.net/lists/linux-input/msg14593.html Signed-off-by: Jon Kliegman <kliegs@chromium.org> R=olofj@chromium.org, msb@chromium.org BUG=chromium-os:13514 TEST=Built kernel Validated kernel boots fine Validated in conjunction with other CLs in bug that the driver works Cherrypicking forward to 3.0 branch from 2.6.38 (cherry picked from commit 1ebffd5) Cherrypicking forward to 2.6.38 branch from http://codereview.chromium.org/6711073 (cherry picked from commit 4dc5fe662e1352e12181ba4cfeb0f8333486c882) Review URL: http://codereview.chromium.org/6893098 Patch from Iiro Valkonen <iiro.valkonen@atmel.com>. Change-Id: I487c75fd05d5eb7b6223b5a3b79d34076d096726 Signed-off-by: Yufeng Shen <miletus@chromium.org> Reviewed-on: http://gerrit.chromium.org/gerrit/8773

For verbose on-the-wire debugging. Prints DUMP_LEN bytes (in hex) per line. Signed-off-by: Daniel Kurtz <djkurtz@chromium.org> BUG=chromium-os:27713 TEST=builds clean w/ & w/out DEBUG defined. If DEBUG defined, bytes read & written over i2c by atmel_mxt_ts should appear in /var/log/messages Change-Id: Ib1b8301a25bb915fea47e4dd62ff261ae5284c3c Reviewed-on: https://gerrit.chromium.org/gerrit/17943 Commit-Ready: Daniel Kurtz <djkurtz@chromium.org> Reviewed-by: Daniel Kurtz <djkurtz@chromium.org> Tested-by: Daniel Kurtz <djkurtz@chromium.org> v3.7 rebase: Signed-off-by: Daniel Kurtz <djkurtz@chromium.org>

Objects in the object table can have multiple instances. Force writes to specify a particular instance. Signed-off-by: Daniel Kurtz <djkurtz@chromium.org> BUG=chromium-os:27713 TEST=build clean; atmel touch device configured and enabled correctly. Change-Id: Ic7208b2b994b490528cce7b2d780bf5497e0d1db Reviewed-on: https://gerrit.chromium.org/gerrit/18432 Commit-Ready: Daniel Kurtz <djkurtz@chromium.org> Reviewed-by: Daniel Kurtz <djkurtz@chromium.org> Tested-by: Daniel Kurtz <djkurtz@chromium.org> v3.7 rebase: Signed-off-by: Daniel Kurtz <djkurtz@chromium.org>

Userspace can write a 32-bit value (encoded as a 8 character hex string) to the 'object' sysfs entry to modify a single byte of the object table. The hex string encodes 4 bytes, in the following format: TTIIFFVV Where: TT = object type (atmel 'T' number) II = object instance (0-indexes, so 0 is the first instance) FF = object offset VV = byte value The object table is modified in device ram, which means the change is volatile, and will be overwritten on the next device reset. To make changes permanent, the new settings should be persisted in the device's Non-Voltatile Memory using the updatenv sysfs entry. Also, since the device driver initializes itself by reading some values from the object table, the entire driver may need to be unloaded and reloaded after writing the values for the driver to stay in sync. Whether this is required depends on exactly which values were updated. Signed-off-by: Daniel Kurtz <djkurtz@chromium.org> BUG=chromium-os:27713 TEST=ls -l /sys/.../object --wr--r--r 1 root root 4096 Feb 14 20:54 update_fw (0) confirm current number of fingers (look for (Type 9, Offset 14)): $ cat /sys/.../object (1) Change number of reported fingers (Type: 0x09, Offset: 0x0e) to 7: $ echo -n "090e07" > /sys/.../object (2) confirm current number of fingers (look for (Type 9, Offset 14)): $ cat /sys/.../object (3) using mtplot, notice that there now up to 7 fingers are reported. (4) reboot, and verify that the old number of fingers is restored. TEST=Trying to write to a non-existant instance, or past the length of an object, should fail. For example: echo -n "070005ab" > /sys/bus/i2c/devices/<dev>/object => -bash: echo: write error: Invalid argument Change-Id: I8149770f762a84ef457c7bf4aefdb310d07c52c5 Reviewed-on: https://gerrit.chromium.org/gerrit/17944 Commit-Ready: Daniel Kurtz <djkurtz@chromium.org> Reviewed-by: Daniel Kurtz <djkurtz@chromium.org> Tested-by: Daniel Kurtz <djkurtz@chromium.org> v3.7 rebase: Signed-off-by: Daniel Kurtz <djkurtz@chromium.org>

Writing to the object sysfs entry permits individual object table entries to be modified in the device RAM at runtime. To permanently save the settings, they must be written to Non-Volatile memory (NVM). This patch adds a write-only sysfs entry to allow userspace to save current settings to NVM, but restricts access to root. Signed-off-by: Daniel Kurtz <djkurtz@chromium.org> BUG=chromium-os:27713 TEST=ls -al /sys/.../backupnv -> --w------- 1 root root 4096 Feb 14 20:54 backupnv Change-Id: Id767e0b7ef7f882d6a45ebfe7e96e02800ef2cb8 Reviewed-on: https://gerrit.chromium.org/gerrit/17945 Commit-Ready: Daniel Kurtz <djkurtz@chromium.org> Reviewed-by: Daniel Kurtz <djkurtz@chromium.org> Tested-by: Daniel Kurtz <djkurtz@chromium.org> v3.7 rebase: Signed-off-by: Daniel Kurtz <djkurtz@chromium.org>

Implement the MXT DMA method of reading messages. On an interrupt, the T44 report always contains the number of messages pending to be read. So, read 1 byte from T44 in 1 i2c transaction, then read the N pending messages in a second transaction. The end result is a much much faster read time for all pending messages. Using 400kHz i2c, it is possible to read 10 pending messages (e.g. for 10 moving contatcts) in less than 2.8ms, which is well less than the typical 10-15ms update rate. Note: There is a possible optimization here. The T44 byte is guaranteed to always be right before the T5 address. Thus, it should be possible to always fetch the T44 message count and the first message in a single transaction. This would eliminate the overhead of a second complete read transaction for the case where there is only a single pending message. (This is actually the most common case, for instance with just 1-contact on the device touch surface). This optimization, however, is not done in this patch. Signed-off-by: Daniel Kurtz <djkurtz@chromium.org> BUG=chromium-os:27713 TEST=builds clean; all pending messages are processed for each interrupt. Change-Id: I9aa4627d2afdc6da14b7495e78c429d1c4ded7ae Reviewed-on: https://gerrit.chromium.org/gerrit/17956 Reviewed-by: Daniel Kurtz <djkurtz@chromium.org> Tested-by: Daniel Kurtz <djkurtz@chromium.org> Commit-Ready: Daniel Kurtz <djkurtz@chromium.org> v3.7 rebase: Signed-off-by: Daniel Kurtz <djkurtz@chromium.org>

This function attempts to make the CHG pin high by reading a messages until the device queue is empty. Instead of throwing away the message contents, let's actually process them. Also, instead of stopping after a fixed (10) number of messages, keep reading until the device reports that it has no more valid messages - at that point, the CHG line should truly be high. Signed-off-by: Daniel Kurtz <djkurtz@chromium.org> BUG=chromium-os:27713 TEST=builds clean; messages after boot are processed; Config Checksum displayed in dmesg: $ grep "Config Checksum" /var/log/messages Change-Id: I3d1e266d1ac53f5640e65c5acc3fe6672a0c1451 Reviewed-on: https://gerrit.chromium.org/gerrit/17957 Commit-Ready: Daniel Kurtz <djkurtz@chromium.org> Reviewed-by: Daniel Kurtz <djkurtz@chromium.org> Tested-by: Daniel Kurtz <djkurtz@chromium.org> Reviewed-by: Benson Leung <bleung@chromium.org> v3.7 rebase: Signed-off-by: Daniel Kurtz <djkurtz@chromium.org>

The matrix x/y size in the Info Block represents the max x/y lines availble on the device and it will only be updated by the firmware but not the platform data configuration, which sets the x/y lines in T9 object. BUG=None TEST=None Change-Id: I18e4f9855fe2018c2b55256ce25821a6197b9f81 Signed-off-by: Yufeng Shen <miletus@chromium.org> Reviewed-on: https://gerrit.chromium.org/gerrit/21547 v3.7 rebase: Signed-off-by: Daniel Kurtz <djkurtz@chromium.org>

The atmel_mxt_ts T9 data contains information orientation in its 'vector' field. Parse and debug print its contents, although its value isn't actually used yet. Signed-off-by: Daniel Kurtz <djkurtz@chromium.org> BUG=chromium-os:27713 TEST=builds clean; vector values are reported when DEBUG is defined. Change-Id: Ida4d9aa167e5134c76d044599240a6c7e329a62c Reviewed-on: https://gerrit.chromium.org/gerrit/17951 Commit-Ready: Daniel Kurtz <djkurtz@chromium.org> Reviewed-by: Daniel Kurtz <djkurtz@chromium.org> Tested-by: Daniel Kurtz <djkurtz@chromium.org> v3.7 rebase: Signed-off-by: Daniel Kurtz <djkurtz@chromium.org>

Currently when system enters/leaves sleep mode, the driver dis/enables T9 object. It has the limitation that 1) it does not allow the device to wakeup the system 2) the device is not in it's best power saving mode when the system is sleeping. This patch adds the support to put the device into 1) Idle mode, when the need of wakeup from sleep is needed 2) Deepsleep mode when wakeup from sleep is not needed. To achieve this, when the system enters sleep mode, the current T7 Power Config value is first saved and then it is re-configured to be Idle mode (with largest Idle Acquisition Interval and largest Active Acquisition Interval) or Deepsleep mode. Also if wakeup from sleep is needed, the current T9 Ctrl field is saved and a resonable value 0x03 is used to enable T9 so that we can be sure touch contact will generate IRQ to wake the system up. When resume, before-suspend T7 and T9 values are restored accordingly. BUG=chrome-os-partner:9413 TEST=On system with atmel trackpad cd /sys/bus/i2c/drivers/atmel_mxt_ts/2-004b/power echo "enabled" > wakeup powerd_suspend touch trackpad should wakeup the system echo "disabled" > wakeup powerd_suspend touch trackpad should not wakeup the system Change-Id: I85896691ddd69d854a923f548edf8b7d6caa9f8e Signed-off-by: Yufeng Shen <miletus@chromium.org> Reviewed-on: https://gerrit.chromium.org/gerrit/21919 Reviewed-by: Benson Leung <bleung@chromium.org> v3.7 rebase: Signed-off-by: Daniel Kurtz <djkurtz@chromium.org>

The object sysfs entry is used to read the current register value of all the objects. Each read on the sysfs entry can only return up to PAGE_SIZE (usually 4k) bytes, which is not enough for showing all the object values for some atmel chips. This CL moves the sysfs entry to debugfs which does not have this PAGE_SIZE limit on read. Signed-off-by: Yufeng Shen <miletus@chromium.org> BUG=chrome-os-partner:9253 TEST=cd /sys/kernel/debug/atmel_mxt_ts/*DEVICE-I2C-ADDR*/ cat object it should show the register value for all the objects Change-Id: Ic2f0df0c17655b5208ef5746f602fdb8af1c3467 Reviewed-on: https://gerrit.chromium.org/gerrit/21812 Commit-Ready: Yufeng Shen <miletus@chromium.org> Reviewed-by: Yufeng Shen <miletus@chromium.org> Tested-by: Yufeng Shen <miletus@chromium.org> v3.7 rebase: Signed-off-by: Daniel Kurtz <djkurtz@chromium.org>

… pdata This is the preparation for supporting the code path when there is platform data provided and still boot the device into a sane state with backup NVRAM config. This CL makes the irqflags default to be IRQF_TRIGGER_FALLING if no platform data is provided. Signed-off-by: Yufeng Shen <miletus@chromium.org> BUG=chrome-os-partner:9103 TEST=The code path for no pdata is not supported yet, so no test can be done at this point. And no funtional change along the normal code path with platform data provided. Change-Id: Icea0fff544c77b38eb380851d7e7d8f857b76745 Reviewed-on: https://gerrit.chromium.org/gerrit/22417 Reviewed-by: Daniel Kurtz <djkurtz@chromium.org> Commit-Ready: Yufeng Shen <miletus@chromium.org> Tested-by: Yufeng Shen <miletus@chromium.org> v3.7 rebase: Signed-off-by: Daniel Kurtz <djkurtz@chromium.org>

Add the support that the device finishes initialization even when no platform data is provided. Most of the time the device needs configured only once and later on it can just use backed up config from NVRAM. So the code path with no platform saves on device initialization time. Rename mxt_check_reg_init() to be mxt_apply_pdata_config() and move it into mxt_handle_pdata() so that all the platform data processing is in one fucntion. Signed-off-by: Yufeng Shen <miletus@chromium.org> BUG=chrome-os-partner:9103 TEST=Rebuild the kernel with no platform data provided, boot the device with a previously working atmel chip, and make sure the atmel chip still works. Change-Id: I2440c58ab9b9baa1160406827ba9d08aee52a554 Reviewed-on: https://gerrit.chromium.org/gerrit/22587 Commit-Ready: Yufeng Shen <miletus@chromium.org> Reviewed-by: Yufeng Shen <miletus@chromium.org> Tested-by: Yufeng Shen <miletus@chromium.org>

If the atmel chip enters suspend mode and wants to be able to wakeup from suspend, T9 object has to be enabled during suspend. If T9 is enalbed from a disabled state, the chip will perform an auto calibration and send back the status of the calibration. We have to wait for these messages to be read before entering suspend, otherwise these message will wakeup the system automatically. Signed-off-by: Yufeng Shen <miletus@chromium.org> BUG=chrome-os-partner:8722 TEST=run powerd_suspend to put system into sleep and make sure it does not wakeup automatically. And touch the TS/TP to wake the system up Change-Id: Iaf8175c8e6d523edfd152172e1966303ac8fd65f Reviewed-on: https://gerrit.chromium.org/gerrit/22842 Reviewed-by: Benson Leung <bleung@chromium.org> Reviewed-by: Vadim Bendebury <vbendeb@chromium.org> Tested-by: Yufeng Shen <miletus@chromium.org> Commit-Ready: Yufeng Shen <miletus@chromium.org> v3.7 rebase: Signed-off-by: Daniel Kurtz <djkurtz@chromium.org>

On system with more than 1 Atmel chip, a fixed firmware file name "maxtouch.fw" does not work since different chips need different firmware files. This CL adds the sysfs entry that make it possible for userspace to specify the file name of the firmware to be loaded. If no file name is specified, the default "maxtouch.fw" is used for compatibility with existing code. Signed-off-by: Yufeng Shen <miletus@chromium.org> BUG=chrome-os-partner:9103 TEST=cat path-to-atmel-sysfs/fw_file and make sure "maxtouch.fw" is returned echo XXX > path-to-atmel-sysfs/fw_file cat path-to-atmel-sysfs/fw_file and make sure XXX is returned echo 1 > path-to-atmel-sysfs/update_fw and make sure the driver tries to load XXX if XXX exists in /lib/firmware, check that firmware update succeeds if XXX does not exist in /lib/firmware, check that firmware update fails Change-Id: Icdff2851866b36de08c6fd75c29947a8d27f7dfe Reviewed-on: https://gerrit.chromium.org/gerrit/22867 Reviewed-by: Benson Leung <bleung@chromium.org> Tested-by: Yufeng Shen <miletus@chromium.org> Commit-Ready: Yufeng Shen <miletus@chromium.org> v3.7 rebase: Signed-off-by: Daniel Kurtz <djkurtz@chromium.org>

In the preparation for adding support of loading atmel config data from file, this CL adds the sysfs entry config_file so that which config file to be used is configurable from userspace. The config file under /lib/firmware/ will be loaded through request_firmware() call. The default config file is "maxtouch.cfg". This support is necessary on system with more than 1 atmel chip and each needs a different configuration file. Signed-off-by: Yufeng Shen <miletus@chromium.org> BUG=chrome-os-partner:9103 TEST=cat path-to-atmel-sysfs/config_file and make sure "maxtouch.cfg" is returned echo XXX > path-to-atmel-sysfs/config_file cat path-to-atmel-sysfs/config_file and make sure XXX is returned Change-Id: If87a4956c46b4a27e40f689be6304691b79cbf00 Reviewed-on: https://gerrit.chromium.org/gerrit/21663 Reviewed-by: Benson Leung <bleung@chromium.org> Commit-Ready: Yufeng Shen <miletus@chromium.org> Tested-by: Yufeng Shen <miletus@chromium.org> v3.7 rebase: Signed-off-by: Daniel Kurtz <djkurtz@chromium.org>

…file Adding a sysfs entry for loading .raw Atmel config file and write it to the device memory. The format spec of .raw Atmel config file can be found at E-9078 Object-Based Chip Config File Format The input device is unregistered while the configuration data is written to ensure there are no open/close calls to the driver which may write extraneous values to the T9 control register. The input device is recreated once the device has been reset following the configuration update. Signed-off-by: Daniel Kurtz <djkurtz@chromium.org> Signed-off-by: Yufeng Shen <miletus@chromium.org> BUG=chrome-os-partner:9103,chromium-os:33981 TEST=Provide no platform to the atmel device cd path-to-atmel-sysfs 1. cat config_file make sure maxtouch.cfg is returned. echo 1 > update_config and check the error msg in dmesg for "Unable to open config file" 2. copy maxtouch.cfg over to /lib/firmware/ echo 1 > update_config check dmesg to see the device is reconfigured. Original-Change-Id: I439d86fcc0bf05b7922619e55af56ef79c1892ab Reviewed-on: https://gerrit.chromium.org/gerrit/24532 Reviewed-by: Daniel Kurtz <djkurtz@chromium.org> Commit-Ready: Yufeng Shen <miletus@chromium.org> Tested-by: Yufeng Shen <miletus@chromium.org> Change-Id: If8f7ea2953f1a825cbcad4a548cf563345518c7d Reviewed-on: https://gerrit.chromium.org/gerrit/31638 v3.7 rebase: Signed-off-by: Daniel Kurtz <djkurtz@chromium.org>

mxt_probe() calles mxt_initialize() to initialize the device, which includes a soft reset and then msleep for the reset to finish. This has big impact on the system boot time. This patch makes the mxt_initizlize() call async to reduce the system boot time. BUG=chrome-os-partner:15743 TEST=Boot the device and check the kernel timestamp in dmesg to see that the device initialization is parallelized. Signed-off-by: Yufeng Shen <miletus@chromium.org> Original-Change-Id: If106af37a52a0fa874cdc8255c91fdde36776e1f Reviewed-on: https://gerrit.chromium.org/gerrit/36964 Reviewed-by: Benson Leung <bleung@chromium.org> Tested-by: Simon Que <sque@chromium.org> Commit-Ready: Yufeng Shen <miletus@chromium.org> v3.7 rebase: Signed-off-by: Daniel Kurtz <djkurtz@chromium.org> [sonnyrao: removed __devinit for 3.8 rebase] Change-Id: I81785546c6a0ff87486e7ee92cb8bab8aefe2594

Now that we conditionally load configs from pdata only if pdata exists, we no longer need to backup_nv in mxt_initialize. Backup nv should only be done if config data was provided as a part of platform data. This will save 270ms for backup to nv wait. Signed-off-by: Benson Leung <bleung@chromium.org> BUG=chromium-os:33370 TEST=Boot on a system with a touch device instantiated without pdata. Ensure that device is still functional, but that 270ms has been saved until the input device is created. Change-Id: I44ecf9237db2f866787c72e03e8962ca285db865 Reviewed-on: https://gerrit.chromium.org/gerrit/29571 Commit-Ready: Benson Leung <bleung@chromium.org> Reviewed-by: Benson Leung <bleung@chromium.org> Tested-by: Benson Leung <bleung@chromium.org> v3.7 rebase: Signed-off-by: Daniel Kurtz <djkurtz@chromium.org>

Fix the use of magic numbers (such as 0x83) to write to T9 Touch Control. Signed-off-by: Benson Leung <bleung@chromium.org> BUG=chromium-os:33368 TEST=Builds clean. Change-Id: I28d650becaa103490541cd88b600fdb535b4196c Reviewed-on: https://gerrit.chromium.org/gerrit/29558 Commit-Ready: Benson Leung <bleung@chromium.org> Tested-by: Benson Leung <bleung@chromium.org> Reviewed-by: Benson Leung <bleung@chromium.org> v3.7 rebase: Signed-off-by: Daniel Kurtz <djkurtz@chromium.org>

Leave the touch device scanning and enabled, but disable reporting on mxt_stop. This will prevent a needless recalibration due to the T9_ctrl register being set to 0 (disabling the object) and then set back to 0x83. BUG=chrome-os-partner:12042,chrome-os-partner:9717 TEST=Log in to guest mode. Test the touch screen. Log out. Verify that in the next session (after X has restarted) touch performance is still good. Change-Id: If5556325d69390a329d1ed406b5bba9f0d494896 Signed-off-by: Benson Leung <bleung@chromium.org> Reviewed-on: https://gerrit.chromium.org/gerrit/29951 v3.7 rebase: Signed-off-by: Daniel Kurtz <djkurtz@chromium.org>

The position information at resume time while the system is in a low power state may be garbage, so do not actually report this information up to the input layer. Just perform the reads to clear out the status on the device side. Signed-off-by: Benson Leung <bleung@chromium.org> BUG=chrome-os-partner:12318 TEST=Suspend/resume using lid close. Check that on resume, the touch device doesn't show a bunch of garbage data from when the lid was just being opened. Change-Id: I4e60ab672d6191b9141e08e9b0bfdbf42649a95e Reviewed-on: https://gerrit.chromium.org/gerrit/31194 Reviewed-by: Yufeng Shen <miletus@chromium.org> v3.7 rebase: Signed-off-by: Daniel Kurtz <djkurtz@chromium.org>

…sabled Signed-off-by: Benson Leung <bleung@chromium.org> BUG=chrome-os-partner:12318 TEST=Close and open the lid to suspend and resume the system. Make sure that the touchscreen does not generate a lot of stray events on resume. Change-Id: I57b34aab52149cc78cd55a79640b496239bbfa5e Reviewed-on: https://gerrit.chromium.org/gerrit/31270 Reviewed-by: Yufeng Shen <miletus@chromium.org> Commit-Ready: Benson Leung <bleung@chromium.org> Tested-by: Benson Leung <bleung@chromium.org> v3.7 rebase: Signed-off-by: Daniel Kurtz <djkurtz@chromium.org>

Currently when going into suspend and if wakeup is enabled, the driver will check whether the T9_ctrl ENABLE bit is set and if not, it will toggle the bit so that T9 object is enabled to make wakeup possible during suspend. With recent change to T9_ctrl's default value to be 0x81, it is enabled (ENABLE bit set) but not reporting (RPTEN bit not set) which prevents touches reported back during suspend. To fix this, this patches adds checking that whether both ENABLE and RPTEN bits are set, and if not, set both of them. Signed-off-by: Yufeng Shen <miletus@chromium.org> BUG=chrome-os-partner:9192 TEST=Use powerd_suspend to supend the device and then make sure touching the touch device wakes up the system. Change-Id: I234531ae91627f7e1cccbef5810a18a5af6cbae9 Reviewed-on: https://gerrit.chromium.org/gerrit/33088 Reviewed-by: Vadim Bendebury <vbendeb@chromium.org> Reviewed-by: Benson Leung <bleung@chromium.org> Commit-Ready: Yufeng Shen <miletus@chromium.org> Tested-by: Yufeng Shen <miletus@chromium.org>

Currently lid close/open can generate noise touch events on system suspend and resume. One case is that touch down is generated before suspend, and touch liftoff is processed on resume. The driver will discard any pending messages on resume which might make the system enter ghost finger state (touch down without ever liftoff). To workaround the ghost finger case, this patch forces release of all possible fingers on resume. And to avoid the unwanted click resulted from the forced release, move these fingers first to (0,0) and assign them with maximal PRESSURE and TOUCH_MAJOR value so to make them look like palms. Signed-off-by: Yufeng Shen <miletus@chromium.org> BUG=chromium:154383 TEST=use evtest to monitor the touch device; put fingers on the touch device; close the lid; remove fingers after making sure the system enters suspend; Open the lid; Make sure to see finger move events with pressue and touch_major = 255 and the release events. Change-Id: Ic9f0659a2e731c2db03255eb2107be88b333541a Reviewed-on: https://gerrit.chromium.org/gerrit/35046 Reviewed-by: Daniel Kurtz <djkurtz@chromium.org> Commit-Ready: Yufeng Shen <miletus@chromium.org> Tested-by: Yufeng Shen <miletus@chromium.org> v3.7 rebase: Signed-off-by: Daniel Kurtz <djkurtz@chromium.org>

…al configurable Create sysfs for T7 IDLE/ACTV-ACQINT settings to have a configurable power acquisition setting during system suspend. Also change the default T7 IDLE/ACTV-ACQINT values during system suspend to be 32ms to have a sensitive wakeup-from-touch response. Signed-off-by: Yufeng Shen <miletus@chromium.org> Signed-off-by: Daniel Kurtz <djkurtz@chromium.org> BUG=chrome-os-partner:15968 TEST=1. go to touch device sysfs directory echo 254 > power/suspend_acq_interval_ms Try powerd_suspend and use very quick, gentle touch to wake up the system and notice that sometimes the system does not wake up from touch. 2. go to touch device sysfs directory echo 32 > power/suspend_acq_interval_ms Try powerd_suspend and use very quick, gentle touch to wake up the system and make sure the system always wakes up. Change-Id: Ib7ad7a6b81699b71bcb165df06f275e55a68e7c6 Reviewed-on: https://gerrit.chromium.org/gerrit/37836 Reviewed-by: Benson Leung <bleung@chromium.org> Commit-Ready: Yufeng Shen <miletus@chromium.org> Tested-by: Yufeng Shen <miletus@chromium.org> v3.7 rebase: Signed-off-by: Daniel Kurtz <djkurtz@chromium.org>

In the suspend path, if we don't allow device wakeup, we put the chip into deepsleep mode and the chip stops scanning during suspen. On resume if the environment changes, the calibrated baseline before suspend will no longer be valid. In this patch we force a recalibration on resume if device wakeup is disabled during suspend to handle the environment change. Signed-off-by: Yufeng Shen <miletus@chromium.org> BUG=chrome-os-partner:16171 TEST=I don't have a controlled environment to test this. So I only test normal suspend/resume to make sure no noise touches happen on resume and touch devices work as expected. 1. With lid open, using powerd_suspend to suspend the system. Wakeup the system and make sure the touch device still works. Run "demsg | grep atmel" to make sure no calibration message reported. 2. Use lid close to suspend the system. Wakeup the system and make sure touch device still works. Run "demsg | grep atmel" to make sure calibration message are reported. 3. Also notice the case of lid open caused system resume, if something is on the touch surface (like opening the lid and quickly put the palm on the touch surface for a while), the system will get calibrated into a wrong baseline and touch device then won't work. Change-Id: I62cb47fa1c97917a2c0f968e41ee4cd13f12187c Reviewed-on: https://gerrit.chromium.org/gerrit/38051 Reviewed-by: Benson Leung <bleung@chromium.org> Commit-Ready: Yufeng Shen <miletus@chromium.org> Tested-by: Yufeng Shen <miletus@chromium.org> v3.7 rebase: Signed-off-by: Daniel Kurtz <djkurtz@chromium.org>

…ease_all_fingers() We hard-coded the maximal touch_major value to be 255 in mxt_release_all_fingers(). Fixing this by using the queried actual maximal touch_major value. Signed-off-by: Yufeng Shen <miletus@chromium.org> BUG=chrome-os-partner:17176 TEST=1. Run evtest on the touch device 2. Keep touching the device while closing the lid. 3. Release the touch after the system suspends. 4. Open the lid to resume the system 5. Check evtest result and see that there is release events with correct touch major value. Change-Id: I4c3bbb37c25c0df67c752a8b6943f6c127f01aa7 Reviewed-on: https://gerrit.chromium.org/gerrit/41031 Reviewed-by: Benson Leung <bleung@chromium.org> Commit-Queue: Yufeng Shen <miletus@chromium.org> Tested-by: Yufeng Shen <miletus@chromium.org> (cherry picked from commit 0a962d6)

…ection Add T65 object to list of supported objects, and mark it readable and writable. Signed-off-by: Benson Leung <bleung@chromium.org> BUG=chrome-os-partner:17253 TEST=cat /sys/kernel/debug/atmel_mxt_ts/2-004a/object Check that the following object appears: Type: 65 [ 0]: 00 (0) [ 1]: 00 (0) [ 2]: 00 (0) [ 3]: 00 (0) [ 4]: 00 (0) [ 5]: 00 (0) [ 6]: 00 (0) [ 7]: 00 (0) [ 8]: 00 (0) [ 9]: 00 (0) [10]: 00 (0) [11]: 00 (0) [12]: 00 (0) [13]: 00 (0) [14]: 00 (0) [15]: 00 (0) [16]: 00 (0) Change-Id: I8400bd53d619ff0e4af4c4d5ae7f54bb5dc6e9b8 Reviewed-on: https://gerrit.chromium.org/gerrit/41310 Reviewed-by: Yufeng Shen <miletus@chromium.org> Commit-Queue: Benson Leung <bleung@chromium.org> Tested-by: Benson Leung <bleung@chromium.org> (cherry picked from commit 5fd7e47)

…suspend To work around an issue where an idle-suspended system may wake unnecessarily when the lid is closed because the B panel comes close to the trackpad, enable touch suppression (t42) when suspending. Also disable T19, for the button, to allow the button to be pressed if the case is flexed without the system waking. Signed-off-by: Benson Leung <bleung@chromium.org> BUG=chrome-os-partner:17336 TEST=1. Suspend the system with powerd_suspend with lid open. 2. Touch the touchpad. Make sure the system still wakes. 3. Suspend again with powerd_suspend 4. Close the lid. Ensure the system does not wake by observing the system status light. Change-Id: I858af27e65ce491c8eb99f5b8db13ea91f789f3e Reviewed-on: https://gerrit.chromium.org/gerrit/41678 Reviewed-by: Puneet Kumar <puneetster@chromium.org> Reviewed-by: Vincent Palatin <vpalatin@chromium.org> Commit-Queue: Benson Leung <bleung@chromium.org> Tested-by: Benson Leung <bleung@chromium.org> (cherry picked from commit 6988c8d) [djkurtz: v3.6: merge]

Userspace will change it to enabled if needed. Signed-off-by: Benson Leung <bleung@chromium.org> BUG=chrome-os-partner:17336 TEST=cat /sys/bus/i2c/devices/2-004a/power/wakeup Check that it returns "disabled" Suspend the system using powerd_suspend. Check that the touch device 2-004a does not wake the system. Change-Id: If5ac3b30c137d16e5592d4a2ee555fd2533b0caa Reviewed-on: https://gerrit.chromium.org/gerrit/41679 Reviewed-by: Vincent Palatin <vpalatin@chromium.org> Reviewed-by: Puneet Kumar <puneetster@chromium.org> Commit-Queue: Benson Leung <bleung@chromium.org> Tested-by: Benson Leung <bleung@chromium.org> (cherry picked from commit 6625e78)

This is an x86 specific change for the short term. When the lid is closed, issue an mxt_stop to turn off scanning to prevent the lid from affecting the touch device and causing stray touches. Signed-off-by: Benson Leung <bleung@chromium.org> BUG=chrome-os-partner:17465 TEST=From test mode, run evtest, and watch the atmel_mxt device. Close and open the lid. Make sure there are no touch data comes from the atmel driver when the lid is being closed. Change-Id: I2163384fc7cbd45c63d05983c50d2a869975a3c9 Reviewed-on: https://gerrit.chromium.org/gerrit/42080 Reviewed-by: Vincent Palatin <vpalatin@chromium.org> Commit-Queue: Benson Leung <bleung@chromium.org> Tested-by: Benson Leung <bleung@chromium.org> (cherry picked from commit 5391eba)

Instead of using 0x81 to keep the object enabled, disable T9 on mxt_stop by writing 0x00 to it. Signed-off-by: Benson Leung <bleung@chromium.org> BUG=chrome-os-partner:17465 TEST=stop powerd (on R25 also stop powerm) close the lid, or use a magnet to trigger the lid sensor. cat /sys/kernel/debug/atmel_mxt_ts/2-004a/object Look for Type: 9, byte 0. Check that this is 0x00 when lid is closed. When opened, this should return to 0x83. Change-Id: If794e121d1b61186fee9e5b9f97b922549d7beb8 Reviewed-on: https://gerrit.chromium.org/gerrit/42183 Reviewed-by: Puneet Kumar <puneetster@chromium.org> Commit-Queue: Benson Leung <bleung@chromium.org> Tested-by: Benson Leung <bleung@chromium.org> (cherry picked from commit 65caaf9) [djkurtz: v3.6 merge]

This is an x86 specific change for the short term. When the lid is closed on resume, make sure T9 is disabled. to prevent the lid from affecting the touch device and causing stray touches. If lid is open, restore operational settings for T9. Signed-off-by: Benson Leung <bleung@chromium.org> BUG=chrome-os-partner:17465 TEST=Close the lid to suspend in guest mode. Open the lid slowly, until you see the lights indicating resuming. Close the lid immediately upon seeing the system resume from the status light. The system should stay in S0. Check via ssh: cat /sys/kernel/debug/atmel_mxt_ts/2-004a/object Check that T9 is 0x00. On a normal suspend/resume, where the lid is opened, check that touch device is functional. Change-Id: Ibce1c8c000e4bd2a8f360bea2b116051eee35be7 Reviewed-on: https://gerrit.chromium.org/gerrit/42184 Reviewed-by: Puneet Kumar <puneetster@chromium.org> Commit-Queue: Benson Leung <bleung@chromium.org> Tested-by: Benson Leung <bleung@chromium.org> (cherry picked from commit 4201ff9)

Signed-off-by: Maxime Ripard <maxime.ripard@free-electrons.com>

To efficiently send a whole page to the display, we need to be able to manipulate more easily the data arrays that has to be sent to the OLED controller. As such, this patch introduces a ssd1307fb_array structure that handles both the small header to be sent over i2c, which contains the type of information sent, and the raw bytes after that. Signed-off-by: Maxime Ripard <maxime.ripard@free-electrons.com>

The code until now was sending only 1pixel-wide page segment at once, and started a new transfer every time. It has proven very inefficient, because for one byte to display on the screen, we had to actually send 3 bytes over I2C: the address, the type of data that was going to the controller, and then the actual data. This patches changes that by sending a whole page at once, avoiding most of this expensive overhead. Signed-off-by: Maxime Ripard <maxime.ripard@free-electrons.com>

By default, the ssd1307 controller uses an addressing mode called page addressing. This mode only increments the column cursor in memory when writing data but will not increments the page cursor when we are at the end of the page. However, the controller supports another addressing mode, called horizontal addressing, that will maintain both the page and column cursors when writing data to the controller. That means that we can just remove the code that increments the current page address and reset the column cursor when reaching the end of the line, allowing to have a lower data overhead, and a simpler driver. Signed-off-by: Maxime Ripard <maxime.ripard@free-electrons.com>

Signed-off-by: Koen Kooi <koen@dominion.thruhere.net>

…pipermail/linaro-dev/2011-August/006752.html Signed-off-by: Koen Kooi <koen@dominion.thruhere.net>

Make headers_install croaks when we're on a deep directory hierarchy Fix using intermediate file lists in /tmp + xargs (but crud is left in /tmp) Signed-off-by: Pantelis Antoniou <panto@antoniou-consulting.com>

Add generic helpers to pack HDMI infoframes into binary buffers. Signed-off-by: Thierry Reding <thierry.reding@avionic-design.de>

commit 5e166deffcfe438f57ec334e288e068e42fb05bb Author: Darren Etheridge <detheridge@ti.com> Date: Fri Apr 19 11:34:44 2013 -0500 tda998x - select the correct i2s format for BBB commit 27ce11f74e084c2d49bd9d50db7eaf8fe3386bf9 Author: Darren Etheridge <detheridge@ti.com> Date: Thu Apr 18 15:42:57 2013 -0500 TDA998x initial attempt at adding HDMI/audio This now supports HDMI with correct CEA timings and Audio output (fixed at 48KHz) commit a25d22ec97a60611ba8f3579a015fa05ee4f96fa Author: Darren Etheridge <detheridge@ti.com> Date: Wed Apr 17 17:06:40 2013 -0500 TILCDC enable pulling in HDMI infoframe helper functions commit 90cd4a836a4d60232d70f84f56a854c794917422 Author: Darren Etheridge <detheridge@ti.com> Date: Wed Apr 17 14:11:59 2013 -0500 Adding new audio driver-combined with DRM driver for NXP TDA 998x commit df7d51d3aebcb2222be60acfd3408e67d83d9383 Author: Darren Etheridge <detheridge@ti.com> Date: Wed Apr 17 13:52:29 2013 -0500 Remove debug, changing codec name to dedicated NXP commit 566687c6bb1c80a1d8e8cb66b469152bf69ae67b Author: Darren Etheridge <detheridge@ti.com> Date: Wed Apr 17 12:14:08 2013 -0500 Remove NXP supplied driver from the build Replace with custom DRM driver. commit c150fef5971088705fc155163a3a5a4f805b321e Author: Darren Etheridge <detheridge@ti.com> Date: Wed Apr 17 12:07:25 2013 -0500 AM335x audio back to original setup, with new NXP hdmi driver moved to DRM commit 19c2249b7e4ad600f28bfdb67106abe0c8509701 Author: Darren Etheridge <detheridge@ti.com> Date: Wed Apr 17 11:55:50 2013 -0500 Reverting file back to original form and replacing with custom NXP driver that will be part of the DRM driver. commit da88657d82d52ad212f34429b7b349dbea093bc0 Author: Darren Etheridge <detheridge@ti.com> Date: Wed Apr 17 11:50:02 2013 -0500 Cleaning up for NXP codec support on BeagleBone Black commit bda7bcce6f54c8108bd8dc9efb5e0f4c375f112d Author: Darren Etheridge <detheridge@ti.com> Date: Wed Apr 17 11:48:44 2013 -0500 Added a new build target for NXP audio driver commit 38b5a020fa895a6da2b495a5b46b7f5e4cb5a0a4 Author: Darren Etheridge <detheridge@ti.com> Date: Wed Apr 17 11:47:40 2013 -0500 Changing to put the NXP into HDMI mode by default Much more work is needed to make this into a real driver with audio support. commit 0bdff4a28649d1c17bff1d74ca41bf9ce28f7743 Author: Darren Etheridge <detheridge@ti.com> Date: Wed Apr 17 11:46:15 2013 -0500 Initial version of dummy codec driver for NXP HDMI encoder commit e15d0879137b6cb15c1ff57d9f32d60f4ba9e232 Author: Darren Etheridge <detheridge@ti.com> Date: Fri Apr 12 16:45:43 2013 -0500 Fixing typo in Bone Cape DTS file commit 8a2693c254cc56227f9b8ae180df64963ec944dd Author: Darren Etheridge <detheridge@ti.com> Date: Fri Apr 5 16:15:45 2013 -0500 Fixing the default audio format from the mcasp for nxp hdmi driver. commit 1e66174fbe31672e3fb8776fe6146d4445916021 Author: Darren Etheridge <detheridge@ti.com> Date: Fri Apr 5 13:09:24 2013 -0500 Create an hdmi device and fix setting in mcasp this is very much a temporary commit and needs to be cleaned up and done the right way before it is rolled out further. commit e48b28929abdfa635d69fca38009bea1422745e7 Author: Darren Etheridge <detheridge@ti.com> Date: Fri Apr 5 13:07:51 2013 -0500 Set the right format for HDMI Codec commit 465924ca1fd1a27c252f47fe6f501444f624319d Author: Darren Etheridge <detheridge@ti.com> Date: Fri Apr 5 10:44:03 2013 -0500 Add the necessary device tree nodes to enable HDMI audio. Add code to enable the McASP clock that is enabled by setting gpio1_27 high. Create a new machine in Davinci audio driver for BeagleBone Black.

If the connector supports audio, prune all the display modes that don't support it. Signed-off-by: Pantelis Antoniou <panto@antoniou-consulting.com>

Add extra mode that enables 1920x1080@24, this now works with 2048 lines vertical support and EMIF setting of INT_CONFIG optimized.

DBGs supply their own newlines, don't add them. Signed-off-by: Pantelis Antoniou <panto@antoniou-consulting.com>

The lower resolution modes do infact need more bandwidth. Signed-off-by: Pantelis Antoniou <panto@antoniou-consulting.com>

Apparently anything other fails to work (at least for me). Signed-off-by: Pantelis Antoniou <panto@antoniou-consulting.com>

The MMC driver already has the right pinmuxing options, remove it from here. Signed-off-by: Pantelis Antoniou <panto@antoniou-consulting.com>

Allow capes to define priorities, this is important when you need to load built-in capes last, only after all the add-on capes have loaded. Signed-off-by: Pantelis Antoniou <panto@antoniou-consulting.com>

A reset control subsystem. Similar to pinctrl but for handling reset conditions. Signed-off-by: Pantelis Antoniou <panto@antoniou-consulting.com>

Use the rstctl resource if that's available. If not, don't probe the device. Signed-off-by: Pantelis Antoniou <panto@antoniou-consulting.com>

Add a reset control resource for the eMMC's reset GPIO. Signed-off-by: Pantelis Antoniou <panto@antoniou-consulting.com>

Add the references to the reset controller for the eMMC capes. Signed-off-by: Pantelis Antoniou <panto@antoniou-consulting.com>

Add a couple of reset control capes for testing rstctl Signed-off-by: Pantelis Antoniou <panto@antoniou-consulting.com>

Make sure that when a rstctl resource is requested, but unavailable to fail the device probe. Signed-off-by: Pantelis Antoniou <panto@antoniou-consulting.com>

Place priority entries to built-in cape entries. That way we can make sure that the add one capes take precedence Signed-off-by: Pantelis Antoniou <panto@antoniou-consulting.com>

Signed-off-by: Koen Kooi <koen@dominion.thruhere.net>

Driver for the Quicklogic camera cape. Signed-off-by: Pantelis Antoniou <panto@antoniou-consulting.com>

Add the cape definition for the CAM3 cape Signed-off-by: Pantelis Antoniou <panto@antoniou-consulting.com>

GPLv2 != GPL v2 for license reasons Signed-off-by: Pantelis Antoniou <panto@antoniou-consulting.com>

Signed-off-by: Koen Kooi <koen@dominion.thruhere.net>

Signed-off-by: Pantelis Antoniou <panto@antoniou-consulting.com>

This should make it work reliably for resolutions up to 1024x768 1280x960 and higher hang, or crash..

Using the reset control framework, the camera works on the black. I love it when a plan comes together...

Now each cape can declare an exclusive-use property which is a string list of every resource it requires. Attempting to load a cape that uses the same resource will fail.

Start adding the resource list of each cape.

Updated all the standard capes with their resource definitions.

Signed-off-by: Koen Kooi <koen@dominion.thruhere.net>

… 01 and 02

…TT3201

Commits on Jun 17, 2013

fixed formatting

Alessandro Zummo committed Jun 17, 2013

Configuration menu

View commit details

Copy full SHA for 1932bd1

Browse repository at this point

Copy the full SHA

1932bd1 View commit details

Browse the repository at this point in the history

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Towertech tt3201 can cape #9

Towertech tt3201 can cape #9

Commits on May 24, 2013

Commits on May 25, 2013

Commits on May 27, 2013

Commits on May 28, 2013

Commits on Jun 17, 2013

Commits on Jun 27, 2013

Commits on Jun 28, 2013

Commits on Oct 4, 2013

Commits on Oct 7, 2013