3.8.13 bone69 bb view 7 #33

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 <[email protected]> Tested-by: Ezequiel Garcia <[email protected]>

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 <[email protected]> Signed-off-by: Jon Hunter <[email protected]> Tested-by: Ezequiel Garcia <[email protected]>

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 <[email protected]> Tested-by: Ezequiel Garcia <[email protected]>

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 <[email protected]> Tested-by: Ezequiel Garcia <[email protected]>

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 <[email protected]> Signed-off-by: Jon Hunter <[email protected]> Tested-by: Ezequiel Garcia <[email protected]>

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 <[email protected]> Signed-off-by: Jon Hunter <[email protected]>

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 <[email protected]> Signed-off-by: Jon Hunter <[email protected]>

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 <[email protected]> Acked-by: Grant Likely <[email protected]> Acked-by: Artem Bityutskiy <[email protected]> Signed-off-by: Tony Lindgren <[email protected]>

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 <[email protected]> Acked-by: Grant Likely <[email protected]> Signed-off-by: Tony Lindgren <[email protected]>

The am33xx is capable of handling bch error correction modes, so enable that feature in the driver. Signed-off-by: Daniel Mack <[email protected]> Acked-by: Grant Likely <[email protected]> Signed-off-by: Tony Lindgren <[email protected]>

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 <[email protected]> Acked-by: Grant Likely <[email protected]> Signed-off-by: Tony Lindgren <[email protected]>

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 <[email protected]> Signed-off-by: Tony Lindgren <[email protected]>

Signed-off-by: Pantelis Antoniou <[email protected]>

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 <[email protected]> Signed-off-by: Ezequiel Garcia <[email protected]> Signed-off-by: Tony Lindgren <[email protected]>

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 <[email protected]> Tested-by: Ezequiel Garcia <[email protected]> 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 <[email protected]>

Add am33xx gpmc device. Signed-off-by: Pantelis Antoniou <[email protected]>

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 <[email protected]> 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 <[email protected]> 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 <[email protected]> Reviewed-by: Daniel Kurtz <[email protected]> Tested-by: Daniel Kurtz <[email protected]> [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 <[email protected]> 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 <[email protected]> Reviewed-by: Daniel Kurtz <[email protected]> Tested-by: Daniel Kurtz <[email protected]> [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 <[email protected]> Signed-off-by: Daniel Kurtz <[email protected]> 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 <[email protected]> Commit-Ready: Benson Leung <[email protected]> Tested-by: Benson Leung <[email protected]> v3.7 rebase: Signed-off-by: Daniel Kurtz <[email protected]> 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 <[email protected]> Signed-off-by: Daniel Kurtz <[email protected]> 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 <[email protected]>

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 <[email protected]> Signed-off-by: Daniel Kurtz <[email protected]> Signed-off-by: Yufeng Shen <[email protected]> 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 <[email protected]> Tested-by: Yufeng Shen <[email protected]> Commit-Ready: Yufeng Shen <[email protected]> Original-Change-Id: Ib773efd8b76aced9f5faab0b51745db7192e78f9 Reviewed-on: https://gerrit.chromium.org/gerrit/37860 v3.7 rebase: Signed-off-by: Daniel Kurtz <[email protected]>

…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 <[email protected]> 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 <[email protected]>

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 <[email protected]> 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 <[email protected]>

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 <[email protected]> Reviewed-on: https://gerrit.chromium.org/gerrit/19639 Reviewed-by: Daniel Kurtz <[email protected]>

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 <[email protected]> Reviewed-on: https://gerrit.chromium.org/gerrit/19640 Reviewed-by: Daniel Kurtz <[email protected]>

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 <[email protected]> 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 <[email protected]> Tested-by: Daniel Kurtz <[email protected]> Commit-Ready: Daniel Kurtz <[email protected]> v3.7 rebase: Signed-off-by: Daniel Kurtz <[email protected]>

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 <[email protected]> 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 <[email protected]> Reviewed-by: Daniel Kurtz <[email protected]> Tested-by: Daniel Kurtz <[email protected]> Reviewed-by: Benson Leung <[email protected]> v3.7 rebase: Signed-off-by: Daniel Kurtz <[email protected]>

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 <[email protected]> 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 <[email protected]> Commit-Ready: Daniel Kurtz <[email protected]> Reviewed-by: Daniel Kurtz <[email protected]> Tested-by: Daniel Kurtz <[email protected]> v3.7 rebase: Signed-off-by: Daniel Kurtz <[email protected]>

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 <[email protected]> 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 <[email protected]> Reviewed-by: Daniel Kurtz <[email protected]> Tested-by: Daniel Kurtz <[email protected]> v3.7 rebase: Signed-off-by: Daniel Kurtz <[email protected]>

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 <[email protected]> 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 <[email protected]> Reviewed-by: Daniel Kurtz <[email protected]> Tested-by: Daniel Kurtz <[email protected]> v3.7 rebase: Signed-off-by: Daniel Kurtz <[email protected]>

…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 <[email protected]> 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 <[email protected]> Reviewed-by: Daniel Kurtz <[email protected]> Tested-by: Daniel Kurtz <[email protected]> v3.7 rebase: Signed-off-by: Daniel Kurtz <[email protected]>

This patch just creates a per-device debugfs root directory. Actual debugfs entries will be added in subsequent patches. Signed-off-by: Daniel Kurtz <[email protected]> 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 <[email protected]> Reviewed-by: Daniel Kurtz <[email protected]> Tested-by: Daniel Kurtz <[email protected]> v3.7 rebase: Signed-off-by: Daniel Kurtz <[email protected]>

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 <[email protected]> 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 <[email protected]> Reviewed-by: Daniel Kurtz <[email protected]> Tested-by: Daniel Kurtz <[email protected]> v3.7 rebase: Signed-off-by: Daniel Kurtz <[email protected]>

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 <[email protected]> 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 <[email protected]> Reviewed-by: Benson Leung <[email protected]> Tested-by: Benson Leung <[email protected]> v3.7 rebase: Signed-off-by: Daniel Kurtz <[email protected]>

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 <[email protected]> Reviewed-on: https://gerrit.chromium.org/gerrit/21544 Reviewed-by: Daniel Kurtz <[email protected]> v3.7 rebase: Signed-off-by: Daniel Kurtz <[email protected]>

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 <[email protected]> Signed-off-by: Daniel Kurtz <[email protected]> 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 <[email protected]> Reviewed-by: Yufeng Shen <[email protected]> Tested-by: Yufeng Shen <[email protected]> v3.7 rebase: Signed-off-by: Daniel Kurtz <[email protected]>

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 <[email protected]> Reviewed-on: https://gerrit.chromium.org/gerrit/19638 Reviewed-by: Daniel Kurtz <[email protected]> Reviewed-by: Vadim Bendebury <[email protected]>

…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 <[email protected]> Patch is in progress of being submitted at http://www.spinics.net/lists/linux-input/msg14593.html Signed-off-by: Jon Kliegman <[email protected]> [email protected], [email protected] 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 1ebffd5d7df2202b20eee3c906096ff7f1d6c56a) 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 <[email protected]>. Change-Id: I487c75fd05d5eb7b6223b5a3b79d34076d096726 Signed-off-by: Yufeng Shen <[email protected]> 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 <[email protected]> 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 <[email protected]> Reviewed-by: Daniel Kurtz <[email protected]> Tested-by: Daniel Kurtz <[email protected]> v3.7 rebase: Signed-off-by: Daniel Kurtz <[email protected]>

Objects in the object table can have multiple instances. Force writes to specify a particular instance. Signed-off-by: Daniel Kurtz <[email protected]> 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 <[email protected]> Reviewed-by: Daniel Kurtz <[email protected]> Tested-by: Daniel Kurtz <[email protected]> v3.7 rebase: Signed-off-by: Daniel Kurtz <[email protected]>

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 <[email protected]> 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 <[email protected]> Reviewed-by: Daniel Kurtz <[email protected]> Tested-by: Daniel Kurtz <[email protected]> v3.7 rebase: Signed-off-by: Daniel Kurtz <[email protected]>

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 <[email protected]> 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 <[email protected]> Reviewed-by: Daniel Kurtz <[email protected]> Tested-by: Daniel Kurtz <[email protected]> v3.7 rebase: Signed-off-by: Daniel Kurtz <[email protected]>

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 <[email protected]> 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 <[email protected]> Tested-by: Daniel Kurtz <[email protected]> Commit-Ready: Daniel Kurtz <[email protected]> v3.7 rebase: Signed-off-by: Daniel Kurtz <[email protected]>

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 <[email protected]> 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 <[email protected]> Reviewed-by: Daniel Kurtz <[email protected]> Tested-by: Daniel Kurtz <[email protected]> Reviewed-by: Benson Leung <[email protected]> v3.7 rebase: Signed-off-by: Daniel Kurtz <[email protected]>

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 <[email protected]> Reviewed-on: https://gerrit.chromium.org/gerrit/21547 v3.7 rebase: Signed-off-by: Daniel Kurtz <[email protected]>

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 <[email protected]> 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 <[email protected]> Reviewed-by: Daniel Kurtz <[email protected]> Tested-by: Daniel Kurtz <[email protected]> v3.7 rebase: Signed-off-by: Daniel Kurtz <[email protected]>

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 <[email protected]> Reviewed-on: https://gerrit.chromium.org/gerrit/21919 Reviewed-by: Benson Leung <[email protected]> v3.7 rebase: Signed-off-by: Daniel Kurtz <[email protected]>

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 <[email protected]> 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 <[email protected]> Reviewed-by: Yufeng Shen <[email protected]> Tested-by: Yufeng Shen <[email protected]> v3.7 rebase: Signed-off-by: Daniel Kurtz <[email protected]>

… 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 <[email protected]> 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 <[email protected]> Commit-Ready: Yufeng Shen <[email protected]> Tested-by: Yufeng Shen <[email protected]> v3.7 rebase: Signed-off-by: Daniel Kurtz <[email protected]>

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 <[email protected]> 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 <[email protected]> Reviewed-by: Yufeng Shen <[email protected]> Tested-by: Yufeng Shen <[email protected]>

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 <[email protected]> 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 <[email protected]> Reviewed-by: Vadim Bendebury <[email protected]> Tested-by: Yufeng Shen <[email protected]> Commit-Ready: Yufeng Shen <[email protected]> v3.7 rebase: Signed-off-by: Daniel Kurtz <[email protected]>

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 <[email protected]> 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 <[email protected]> Tested-by: Yufeng Shen <[email protected]> Commit-Ready: Yufeng Shen <[email protected]> v3.7 rebase: Signed-off-by: Daniel Kurtz <[email protected]>

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 <[email protected]> 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 <[email protected]> Commit-Ready: Yufeng Shen <[email protected]> Tested-by: Yufeng Shen <[email protected]> v3.7 rebase: Signed-off-by: Daniel Kurtz <[email protected]>

…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 <[email protected]> Signed-off-by: Yufeng Shen <[email protected]> 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 <[email protected]> Commit-Ready: Yufeng Shen <[email protected]> Tested-by: Yufeng Shen <[email protected]> Change-Id: If8f7ea2953f1a825cbcad4a548cf563345518c7d Reviewed-on: https://gerrit.chromium.org/gerrit/31638 v3.7 rebase: Signed-off-by: Daniel Kurtz <[email protected]>

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 <[email protected]> Original-Change-Id: If106af37a52a0fa874cdc8255c91fdde36776e1f Reviewed-on: https://gerrit.chromium.org/gerrit/36964 Reviewed-by: Benson Leung <[email protected]> Tested-by: Simon Que <[email protected]> Commit-Ready: Yufeng Shen <[email protected]> v3.7 rebase: Signed-off-by: Daniel Kurtz <[email protected]> [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 <[email protected]> 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 <[email protected]> Reviewed-by: Benson Leung <[email protected]> Tested-by: Benson Leung <[email protected]> v3.7 rebase: Signed-off-by: Daniel Kurtz <[email protected]>

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

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 <[email protected]> Reviewed-on: https://gerrit.chromium.org/gerrit/29951 v3.7 rebase: Signed-off-by: Daniel Kurtz <[email protected]>

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 <[email protected]> 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 <[email protected]> v3.7 rebase: Signed-off-by: Daniel Kurtz <[email protected]>

…sabled Signed-off-by: Benson Leung <[email protected]> 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 <[email protected]> Commit-Ready: Benson Leung <[email protected]> Tested-by: Benson Leung <[email protected]> v3.7 rebase: Signed-off-by: Daniel Kurtz <[email protected]>

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 <[email protected]> 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 <[email protected]> Reviewed-by: Benson Leung <[email protected]> Commit-Ready: Yufeng Shen <[email protected]> Tested-by: Yufeng Shen <[email protected]>

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 <[email protected]> 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 <[email protected]> Commit-Ready: Yufeng Shen <[email protected]> Tested-by: Yufeng Shen <[email protected]> v3.7 rebase: Signed-off-by: Daniel Kurtz <[email protected]>

…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 <[email protected]> Signed-off-by: Daniel Kurtz <[email protected]> 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 <[email protected]> Commit-Ready: Yufeng Shen <[email protected]> Tested-by: Yufeng Shen <[email protected]> v3.7 rebase: Signed-off-by: Daniel Kurtz <[email protected]>

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 <[email protected]> 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 <[email protected]> Commit-Ready: Yufeng Shen <[email protected]> Tested-by: Yufeng Shen <[email protected]> v3.7 rebase: Signed-off-by: Daniel Kurtz <[email protected]>

…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 <[email protected]> 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 <[email protected]> Commit-Queue: Yufeng Shen <[email protected]> Tested-by: Yufeng Shen <[email protected]> (cherry picked from commit 0a962d62165755547e4802da837ca9004f5d246b)

…ection Add T65 object to list of supported objects, and mark it readable and writable. Signed-off-by: Benson Leung <[email protected]> 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 <[email protected]> Commit-Queue: Benson Leung <[email protected]> Tested-by: Benson Leung <[email protected]> (cherry picked from commit 5fd7e4778bd22252de5611a894d061a3bb64c4a2)

…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 <[email protected]> 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 <[email protected]> Reviewed-by: Vincent Palatin <[email protected]> Commit-Queue: Benson Leung <[email protected]> Tested-by: Benson Leung <[email protected]> (cherry picked from commit 6988c8d813d863007df2ba3f418172d07b63ece6) [djkurtz: v3.6: merge]

Userspace will change it to enabled if needed. Signed-off-by: Benson Leung <[email protected]> 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 <[email protected]> Reviewed-by: Puneet Kumar <[email protected]> Commit-Queue: Benson Leung <[email protected]> Tested-by: Benson Leung <[email protected]> (cherry picked from commit 6625e780bacf270b6da346751819d2825f09c20a)

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 <[email protected]> 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 <[email protected]> Commit-Queue: Benson Leung <[email protected]> Tested-by: Benson Leung <[email protected]> (cherry picked from commit 5391ebafb8f9b72475795445ca71b02815a2a229)

Instead of using 0x81 to keep the object enabled, disable T9 on mxt_stop by writing 0x00 to it. Signed-off-by: Benson Leung <[email protected]> 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 <[email protected]> Commit-Queue: Benson Leung <[email protected]> Tested-by: Benson Leung <[email protected]> (cherry picked from commit 65caaf9e0697899cd5e21eb643e018298adc781a) [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 <[email protected]> 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 <[email protected]> Commit-Queue: Benson Leung <[email protected]> Tested-by: Benson Leung <[email protected]> (cherry picked from commit 4201ff9f7a9e114c453932662d49e34047dee59c)

Signed-off-by: Maxime Ripard <[email protected]>

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 <[email protected]>

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 <[email protected]>

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 <[email protected]>

Signed-off-by: Koen Kooi <[email protected]>

Add generic helpers to pack HDMI infoframes into binary buffers. Signed-off-by: Thierry Reding <[email protected]>

commit 5e166deffcfe438f57ec334e288e068e42fb05bb Author: Darren Etheridge <[email protected]> Date: Fri Apr 19 11:34:44 2013 -0500 tda998x - select the correct i2s format for BBB commit 27ce11f74e084c2d49bd9d50db7eaf8fe3386bf9 Author: Darren Etheridge <[email protected]> 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 <[email protected]> Date: Wed Apr 17 17:06:40 2013 -0500 TILCDC enable pulling in HDMI infoframe helper functions commit 90cd4a836a4d60232d70f84f56a854c794917422 Author: Darren Etheridge <[email protected]> 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 <[email protected]> Date: Wed Apr 17 13:52:29 2013 -0500 Remove debug, changing codec name to dedicated NXP commit 566687c6bb1c80a1d8e8cb66b469152bf69ae67b Author: Darren Etheridge <[email protected]> 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 <[email protected]> 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 <[email protected]> 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 <[email protected]> Date: Wed Apr 17 11:50:02 2013 -0500 Cleaning up for NXP codec support on BeagleBone Black commit bda7bcce6f54c8108bd8dc9efb5e0f4c375f112d Author: Darren Etheridge <[email protected]> Date: Wed Apr 17 11:48:44 2013 -0500 Added a new build target for NXP audio driver commit 38b5a020fa895a6da2b495a5b46b7f5e4cb5a0a4 Author: Darren Etheridge <[email protected]> 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 <[email protected]> Date: Wed Apr 17 11:46:15 2013 -0500 Initial version of dummy codec driver for NXP HDMI encoder commit e15d0879137b6cb15c1ff57d9f32d60f4ba9e232 Author: Darren Etheridge <[email protected]> Date: Fri Apr 12 16:45:43 2013 -0500 Fixing typo in Bone Cape DTS file commit 8a2693c254cc56227f9b8ae180df64963ec944dd Author: Darren Etheridge <[email protected]> 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 <[email protected]> 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 <[email protected]> Date: Fri Apr 5 13:07:51 2013 -0500 Set the right format for HDMI Codec commit 465924ca1fd1a27c252f47fe6f501444f624319d Author: Darren Etheridge <[email protected]> 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 <[email protected]>

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 <[email protected]>

The lower resolution modes do infact need more bandwidth. Signed-off-by: Pantelis Antoniou <[email protected]>

Apparently anything other fails to work (at least for me). Signed-off-by: Pantelis Antoniou <[email protected]>

TDA19988 devices need their RAM enabled in order to read EDID information. Add support for this. Signed-off-by: Russell King <[email protected]>

Allow non-audio modes on an audio capable monitor if we explicitly disable audio. Signed-off-by: Pantelis Antoniou <[email protected]>

When switching between various drivers for this device, it's possible that some critical registers are left containing values which affect the device operation. One such case encountered is the VIP output mux register. This defaults to 0x24 on powerup, but other drivers may set this to 0x12. This results in incorrect colours. Fix this by ensuring that the register is always set to the power on default setting. Signed-off-by: Russell King <[email protected]>

The npix/nline registers are supposed to be programmed with the total number of pixels/lines, not the displayed pixels/lines, and not minus one either. Signed-off-by: Russell King <[email protected]>

Bits weren't cleared so resolution changes didn't work. Signed-off-by: Pantelis Antoniou <[email protected]>

The RFC sent by Russell King was missing an include for tda998x. This is just a compatible clone to remember Russell to add that later. Signed-off-by: Sebastian Hesselbarth <[email protected]>

Signed-off-by: Russell King <[email protected]>

Video works, but no audio. RMK uses SPDIF so I2S is missing various bits. With the tilcdc driver the some non CEC modes are shifted too. Signed-off-by: Pantelis Antoniou <[email protected]>

Turns out that we really need those panel settings. Signed-off-by: Pantelis Antoniou <[email protected]>

Revert all the changes of the WIP so that audio continues to work. We do it with an explicit patch so that we can revisit at a later time when things settled down.

Allow audio modes more selectively. This should end up in DT instead but it will do for release.

In certain senarios drm will initialize before i2c this means that i2c slave devices like the nxp tda998x will fail to be probed. This patch detects this condition then defers the probe of the slave device and the tilcdc main driver. Created by: Darren Etheridge <[email protected]> This change was modified by Cody Lacey to work with the 3.8 kernel.

1680x1050 appears to also be within the bandwidth capabilities of the device and memory infrastructure. Created by: Darren Etheridge <[email protected]>

This fixes the wrong sync generation and sync calculation. It has only been tested for progressive and interlaced modes. Sync timings for a bunch of modes have also been verified with an oscilloscope near-end (TDA998x input) and far-end (DVI receiver output). Created by: Sebastian Hesselbarth <[email protected]> Also contains drm/i2c/tda998x prepare for tilcdc sync workaround Add necessary support for flipping the hsync signal and shifting the display to the right by a certain number of pixels. Changes only take effect if adjusted_mode is changed in fixup function. Created by: Darren Etheridge <[email protected]>

Add a fixup function that will flip the hsync priority and add a hskew value that is used to shift the tda998x to the right by a variable number of pixels depending on the mode. This works around an issue with the sync timings that tilcdc is outputing. Created by: Darren Etheridge <[email protected]>

This adds documentation for tilcdc devicetree bindings.

The tilcdc has a number of limitations for the allowed sizes of the various adjustable timing parameter. Some modes are outside of these timings. This commit will prune modes that report timings that will overflow the allowed sizes in the tilcdc. Created by: Darren Etheridge <[email protected]> Modified by Cody Lacey for the 3.8 kernel.

After adding the HDMI audio, the McASP driver was left in a mess, and broken when used with other capes. This patch puts things right, and moves the necessary config code into davinci-evm.c where it belongs. Signed-off-by: Darren Etheridge <[email protected]>

The AIC3x Codec needs a 12MHz clock source. If the codec MCLK is connected to McASP AHCLKX or AHCLKR then the 24MHz internal clock needs to be divided by 2.

If TX/RX CLK or High Frequency TX/RX CLK are set to output and they use the internally generated clock. Do not reset the tx/rx clock divider when receiving or sending data in case they supply the clock source for another device.

The MMC driver already has the right pinmuxing options, remove it from here. Signed-off-by: Pantelis Antoniou <[email protected]>

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 <[email protected]>

A reset control subsystem. Similar to pinctrl but for handling reset conditions. Signed-off-by: Pantelis Antoniou <[email protected]>

Use the rstctl resource if that's available. If not, don't probe the device. Signed-off-by: Pantelis Antoniou <[email protected]>

Add a reset control resource for the eMMC's reset GPIO. Signed-off-by: Pantelis Antoniou <[email protected]>

Add the references to the reset controller for the eMMC capes. Signed-off-by: Pantelis Antoniou <[email protected]>

Add a couple of reset control capes for testing rstctl Signed-off-by: Pantelis Antoniou <[email protected]>

Make sure that when a rstctl resource is requested, but unavailable to fail the device probe. Signed-off-by: Pantelis Antoniou <[email protected]>

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 <[email protected]>

Signed-off-by: Koen Kooi <[email protected]>

CONFIG_MMC_OMAP requires CONFIG_RSTCTL to compile and should be selected Signed-off-by: Matt Ranostay <[email protected]>

Driver for the Quicklogic camera cape. Signed-off-by: Pantelis Antoniou <[email protected]>

Add the cape definition for the CAM3 cape Signed-off-by: Pantelis Antoniou <[email protected]>

GPLv2 != GPL v2 for license reasons Signed-off-by: Pantelis Antoniou <[email protected]>

Signed-off-by: Koen Kooi <[email protected]>

Signed-off-by: Pantelis Antoniou <[email protected]>

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.

Add analogous option to disable_partno; this one doesn't require the presence of a base dts override. Signed-off-by: Pantelis Antoniou <[email protected]>

When a user cape hogs the audio, allow booting with a HDMI cape which only supports video.

Added a few modes that are known not to work on my end. Signed-off-by: Pantelis Antoniou <[email protected]>

LCD7 rev A3/A4 had some pins wrong

In the 3.2 kernel using the da8xx lcdc fb, the HSW, HFP, and HBP are written to the lcdc registers directly as entered. i.e. if HSW=47 , then 47 is written to the register and the value that is generated is the register value plus one (total of 48 clocks). with the 3.8 kernel using the DRM driver, the code subtracts one from the set value before writing it to the register, i.e. if HSW=47, then 46 is written to the register and the value that is generated is the register value plus one (total of 47 clocks). specifically with the LCD3 board, the lcd panel does not use data enable as a timing signal. it specifically counts the number of vertical clocks and horizontal clocks to determine data start points. the lcd panel expects for the sum of the HSW and HBP to be 70 pixel clocks. currently it is 68. this is the root cause of the color shift and poor image quality.... the HSW, HFP, and HBP for all three lcd panels needs to be incremented by one.

Signed-off-by: Bas Laarhoven <[email protected]>

Signed-off-by: Koen Kooi <[email protected]>

rename RTC protocape to a more consistent naming Signed-off-by: Matt Ranostay <[email protected]>

Added PPS input from SQW pin on the DS1307 Signed-off-by: Matt Ranostay <[email protected]>

Signed-off-by: Koen Kooi <[email protected]>

Signed-off-by: Jan Luebbe <[email protected]>

This enables the use of MMC cards even when no card was inserted at boot. Signed-off-by: Alexander Holler <[email protected]>

Adaption of the original patch by Andrew Bradford <[email protected]> Some minor devm_* changes and DT support. Signed-off-by: Pantelis Antoniou <[email protected]>

Add support for the PMIC interrupt, supports power-button presses. Signed-off-by: Pantelis Antoniou <[email protected]>

This removes some boilerplate code (no functional changes). Signed-off-by: Jan Luebbe <[email protected]> Acked-by: Rodolfo Giometti <[email protected]> Signed-off-by: Andrew Morton <[email protected]> Signed-off-by: Matt Ranostay <[email protected]>

Signed-off-by: Jan Luebbe <[email protected]> Acked-by: Rodolfo Giometti <[email protected]> Signed-off-by: Andrew Morton <[email protected]> Signed-off-by: Matt Ranostay <[email protected]>

Signed-off-by: Jan Luebbe <[email protected]> Acked-by: Rodolfo Giometti <[email protected]> Signed-off-by: Matt Ranostay <[email protected]>

Add pincontrol support to pps-gpio driver for selecting the repective GPIO muxing if applicable. Signed-off-by: Matt Ranostay <[email protected]> -

Update the driver to use the new API for requesting pwm so we can take advantage of the pwm_lookup table to find the correct pwm to be used for the LED functionality. Signed-off-by: Peter Ujfalusi <[email protected]> Signed-off-by: Bryan Wu <[email protected]>

In order to be able to add device tree support for leds-pwm driver we need to rearrange the data structures used by the drivers. Signed-off-by: Peter Ujfalusi <[email protected]> Signed-off-by: Bryan Wu <[email protected]>

The code looks more nicer if we use: while (i--) instead: if (i > 0) for (i = i - 1; i >= 0; i--) Signed-off-by: Peter Ujfalusi <[email protected]> Signed-off-by: Bryan Wu <[email protected]>

The DT binding for the pwm-leds devices are similar to the gpio-leds type. LEDs are represented as sub-nodes of the pwm-leds device. The code for handling the DT boot is based on the code found in the leds-gpio driver and adapted to use PWMs instead of GPIOs. To avoid having custom cleanup code in case of DT boot the newly created devm_of_pwm_get() API is used to get the correct PWM instance. For usage see: Documentation/devicetree/bindings/leds/leds-pwm.txt Signed-off-by: Peter Ujfalusi <[email protected]> Acked-by: Grant Likely <[email protected]> Signed-off-by: Bryan Wu <[email protected]>

Call to led_pwm_set() can happen inside atomic context, like triggers. If the PWM call can sleep, defer using a worker. Signed-off-by: Florian Vaussard <[email protected]> Reviewed-by: Peter Ujfalusi <[email protected]> Acked-by: Thierry Reding <[email protected]> Signed-off-by: Bryan Wu <[email protected]>

This is the full Linux driver enable bacon cape definition.

Signed-off-by: Koen Kooi <[email protected]>

Signed-off-by: Daniel Nilsson <[email protected]>

When booting from a device that's providing the rootfs via a cape fragment, you face the following problem as it appears on the beaglebone black. The priority of the emmc cape is low (positive number) so that any cape that is detected and uses the resources of the emmc interface can work (for example the camera cape). This means that we have to be booting from external sd card. However if there is no conflict, and the cape dtbo is not included in the kernel (via the firmware builtin configure option) the capemgr will attempt to load the cape too early, at a time that the rootfs cape hasn't been loaded yet. In order to fix that an optional third parameter is added to the specification of a cape in the eanble_partno option which allow you to specify the priority. so capemgr.enable_partno=[PART[:REV[:PRIO]]][,PART..] To load the cape fragment after all the builtin capes have loaded use a priority higher than 10; i.e. to load cape foo use: capemgr.enable_partno=foo:00A0:10 Signed-off-by: Pantelis Antoniou <[email protected]>

Add prototype GPS cape with UART and pps-gpio fragments Signed-off-by: Matt Ranostay <[email protected]>

Since beaglebone black requires the overlays to be compiled into the kernel due to eMMC dependency the SPI should be enabled in the most typical use case of SPIDEV. Signed-off-by: Matt Ranostay <[email protected]>

Signed-off-by: Bas Laarhoven <[email protected]>

… and device tree configuration. Signed-off-by: Bas Laarhoven <[email protected]>

…opr" board id. Signed-off-by: Bas Laarhoven <[email protected]>

Signed-off-by: Bas Laarhoven <[email protected]>

…Load with manual override after disabling HDMI,HDMIN,EMMC. Signed-off-by: Bas Laarhoven <[email protected]>

…"cape-bebopr-brdg" board id or via manual override. Signed-off-by: Bas Laarhoven <[email protected]>

Because sync generation was fixed whitelist and blacklist devicetree properties are no longer needed for HDMI.

Signed-off-by: Koen Kooi <[email protected]>

Signed-off-by: Dave Lambert <[email protected]> Signed-off-by: Robert Nelson <[email protected]>

Signed-off-by: vvdn <[email protected]>

Added main overaly for CBB-Serial BeagleBone cape, as well as separate overlays to mux the AM335x UART2 and UART4 RTS and CTS pins to the 3.8 branch. Signed-off-by: Alexander Hiam <[email protected]>

Signed-off-by: Hieu Duong <[email protected]>

…can be found at: https://github.com/cdsteinkuehler/beaglebone-universal-io Signed-off-by: Charles Steinkuehler <[email protected]>

Signed-off-by: Hieu Duong <[email protected]>

Signed-off-by: Robert Budde <[email protected]> Signed-off-by: Robert Nelson <[email protected]>

Signed-off-by: Josh Datko <[email protected]> Signed-off-by: Robert Nelson <[email protected]>

…SoCs Signed-off-by: Nathaniel Lewis <[email protected]>

…ee/master/encoders/dts Signed-off-by: Robert Nelson <[email protected]>

Added Device Tree overlay for the CBB-Relay cape and fixed a copy and paste error in a comment in /firmware/Makefile. signed-off-by: Alexander Hiam <[email protected]>

…s://bitbucket.org/intelligentagent/replicape Committed-by: Charles Steinkuehler <[email protected]>

…o_Cape_RevB Signed-off-by: Robert Nelson <[email protected]>

It looks like one of the entries was missed. Signed-off-by: Jason Kridner <[email protected]> Signed-off-by: Robert Nelson <[email protected]>

Signed-off-by: Dennie de Groot <[email protected]>

Signed-off-by: Tyler Baker <[email protected]>

Signed-off-by: Robert Nelson <[email protected]>

…e-use and pinmux portion of device tree overlay: gpio0_3 incorrectly listed gpio3_16 & gpio0_15 were missing Signed-off-by: Len Shelton <[email protected]> [[email protected]: whitespace cleanup] [[email protected]: remove PBX from compatible = ] Signed-off-by: Charles Steinkuehler <[email protected]>

Signed-off-by: Charles Steinkuehler <[email protected]>

http://elinux.org/CircuitCo:Basic_Proto_Cape load: echo "cape-bone-proto" > /sys/devices/bone_capemgr.*/slots Signed-off-by: Robert Nelson <[email protected]>

Signed-off-by: Jonathan Piat <[email protected]> Signed-off-by: Robert Nelson <[email protected]>

Signed-off-by: Kumar Abhishek <[email protected]>

BeagleLogic is implemented as a separate kernel module that binds and unbinds itself from pru_rproc at runtime. Signed-off-by: Kumar Abhishek <[email protected]>

Same as Revision 91b9d2b37292eb8cd5f862ad833687002677f95c in github.com/abhishek-kakkar/BeagleLogic/ Signed-off-by: Kumar Abhishek <[email protected]>

Signed-off-by: Kumar Abhishek <[email protected]>

When sync does it's WB_SYNC_ALL writeback, it issues data Io and then immediately waits for IO completion. This is done in the context of the flusher thread, and hence completely ties up the flusher thread for the backing device until all the dirty inodes have been synced. On filesystems that are dirtying inodes constantly and quickly, this means the flusher thread can be tied up for minutes per sync call and hence badly affect system level write IO performance as the page cache cannot be cleaned quickly. We already have a wait loop for IO completion for sync(2), so cut this out of the flusher thread and delegate it to wait_sb_inodes(). Hence we can do rapid IO submission, and then wait for it all to complete. Effect of sync on fsmark before the patch: FSUse% Count Size Files/sec App Overhead ..... 0 640000 4096 35154.6 1026984 0 720000 4096 36740.3 1023844 0 800000 4096 36184.6 916599 0 880000 4096 1282.7 1054367 0 960000 4096 3951.3 918773 0 1040000 4096 40646.2 996448 0 1120000 4096 43610.1 895647 0 1200000 4096 40333.1 921048 And a single sync pass took: real 0m52.407s user 0m0.000s sys 0m0.090s After the patch, there is no impact on fsmark results, and each individual sync(2) operation run concurrently with the same fsmark workload takes roughly 7s: real 0m6.930s user 0m0.000s sys 0m0.039s IOWs, sync is 7-8x faster on a busy filesystem and does not have an adverse impact on ongoing async data write operations. Signed-off-by: Dave Chinner <[email protected]> Reviewed-by: Jan Kara <[email protected]> Signed-off-by: Linus Torvalds <[email protected]>

The TLDR; version: We've assumed that when a device disconnects after a resume from device suspend, it was just a cheap, buggy device. It turns out that the USB core simply wasn't waiting long enough for the devices to transition from resume to U0, and it's actually been the USB core's fault all along... * * Please go test this patch with your "buggy" USB devices. * * Background ---------- The USB 2.0 specification, section 7.1.7.7, says that upon device remote wakeup signaling, the first active hub (which is often the roothub) must rebroadcast the resume signaling for at least 20 ms (TDRSMDN). After that's done, the hub's suspend status change bit will be set, and system software must not access the device for at least 10 ms (TRSMRCY). It turns out that TRSMRCY is a *minimum*, not a *maximum*, according to Table 7-14. That means the port can actually take longer than TRSMRCY to resume. Any attempt to communicate with the device, or reset the device, will result in a USB device disconnect. This discrepancy was found with the Intel xHCI host controller, because they handle USB 2.0 resume a little differently than EHCI. See the xHCI spec, Figure 34: USB2 Root Hub Port Enabled Substate Diagram for details. Under EHCI, the host controller driver receives an interrupt when the port suspend status change bit is set, and the USB core only has to time the 10ms TRSMRCY value. Under xHCI, the host receives an interrupt when the device remote wake is first signaled, and the port goes into the Resume state. The xHCI driver kicks khubd, but doesn't allow the suspend state change to be exposed until 20 ms (TDRSMDN) after the port status change event occurs. Then, when the USB core calls into get port status, it transitions the port from the Resume state to the RExit state by changing the port link state to U0. The xHCI driver will get a port status change event when that transition is complete, but that port status change event is currently ignored. What actually happens --------------------- By busy-waiting with xhci_handshake() after the Lynx Point LP host initiates the transition to U0, and printing out how long it took, it turns out that roughly 8% of the time, the host takes longer than 10 ms to transition from RExit to U0. Out of 227 remote wakeup events from a USB mouse and keyboard: - 163 transitions from RExit to U0 were immediate ( < 1 microsecond) - 47 transitions from RExit to U0 took under 10 ms - 17 transitions were over 10ms Those 17 transitions (in microseconds) took: 10140 10305 10650 10659 10677 10695 10819 10907 10998 11030 11234 11618 11656 11724 11898 12060 12162 12757 The end result of that is that on 8% of remote wake events, the USB core would attempt to communicate with the device before it was fully resumed, causing USB disconnects or transfer errors on the next control transfer to get the device status. This bug has been reproduced under ChromeOS, which is very aggressive about USB power management. It enables auto-suspend for all internal USB devices (wifi and bluetooth), and the disconnects wreck havoc on those devices, causing the ChromeOS GUIs to repeatedly flash the USB wifi setup screen on user login. ChromeOS sets the autosuspend_delay_ms to 100 milliseconds, and disables USB device persist. I can reproduce this bug with a vanilla 3.10.7 kernel under ChromeOS. Possible fixes -------------- The USB core obviously needs to be changed to check the port status after the TRSMRCY timeout, and continue to wait if the port is still in the resuming state. I will have to study the EHCI port status diagrams in detail to figure out how the USB core can do this. I can easily do this without the USB core being involved, by changing the xHCI driver to either: 1. Busy wait with xhci_handshake() in the xHCI get port status until the port is in U0. 2. Add a completion per xHCI port. In xHCI get port status, initiate U0 entry, and wait on the port's completion for up to 20 ms. In the port status change event code, complete that port's completion when the port is in U0 and the bus_state->resuming_ports bit is set. In the meantime, simply increasing TRSMRCY from 10 ms to 20 ms solves the resume issue on the Intel xHCI host. Please test this patch under other host controllers to see if it helps "fix" your buggy devices. Signed-off-by: Sarah Sharp <[email protected]> Cc: [email protected]

Signed-off-by: Koen Kooi <[email protected]>

Commit 1f6b9fa consolidated writes to the STAT register in one location, moving them from omap_hsmmc_do_irq() to omap_hsmmc_irq(). This move has the unwanted side effect that the controller status flags are potentially cleared after a new command has been started as a consequence of reading the previous status flags. This means that if the new command changes the status flags before the IRQ routine returns, those flags may be cleared without handling the event which asserted them, and thus missing the event. Move the writing of the STAT register back in omap_hsmmc_do_irq(), before handling the status flags which generated the interrupt. Signed-off-by: Francesco Lavra <[email protected]> Reviewed-and-Tested-by: Balaji T K <[email protected]> Signed-off-by: Chris Ball <[email protected]>

The pan/tilt absolute control value is signed value. If minimum value is minus, It will be changed to plus by clamp_t() as commit 64ae995. ([media] uvcvideo: Fix control value clamping for unsigned integer controls). It leads to wrong setting of the control values. For example, when min and max are -36000 and 36000, the setting value between of this range is always 36000. So, its data type should be changed to signed. Signed-off-by: Chanho Min <[email protected]> Signed-off-by: Laurent Pinchart <[email protected]> Signed-off-by: Mauro Carvalho Chehab <[email protected]>

Signed-off-by: Micka <[email protected]>

Signed-off-by: Michael Musset <[email protected]>

Signed-off-by: Robert Nelson <[email protected]>

Signed-off-by: anithamolbenny <[email protected]> Signed-off-by: Robert Nelson <[email protected]>

http://arduino.cc/en/Main/ArduinoBoardTre

Signed-off-by: Jason Kridner <[email protected]>

Borrowed heavily from BeagleLogic integration, this makes pru_speak use the same pru_rproc driver. This is a ugly hack that reflects I don't have much experience with this driver. Several obvious changes need to be made to expose the right interface to pru_rproc clients and extracting the features that have been thrown in the main driver that really belong in another layer. Based on https://github.com/deepakkarki/pruspeak commit 1498fb911581eb6c5817c1e7f6c6057195e37646

Hint from [email protected] who also informed me that Deepak Karki did start the work of doing the integration to the shared driver at https://github.com/deepakkarki/pruspeak/tree/pru_rproc_ps/src/driver.

Signed-off-by: Jason Kridner <[email protected]>

Signed-off-by: Robert Nelson <[email protected]>

Signed-off-by: Charles Steinkuehler <[email protected]>

…start

Identify AM335x chip versions, detect and enable chip-specific features such as the SGX GPU's presence and L2 cache. Signed-off-by: B. Scott Michel <[email protected]> Signed-off-by: Robert Nelson <[email protected]>

Signed-off-by: Robert Nelson <[email protected]>

http://beagleboard.org/Community/Forums?place=msg%2Fbeagleboard%2FU3-4wh9yook%2Fgfc81YXrH6kJ Signed-off-by: James Johnson <[email protected]> Signed-off-by: Robert Nelson <[email protected]>

Signed-off-by: Charles Steinkuehler <[email protected]>

Signed-off-by: Robert Nelson <[email protected]>

Software came from http://www.element14.com/community/docs/DOC-67958?ICID=BBB-feature-viewpanel Hints came from http://armsdr.blogspot.com/2014/01/element14-bb-view-and-debian-beta.html Testing on BB-VIEW 7" LCD display

Picking up some additional changes

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

3.8.13 bone69 bb view 7 #33

3.8.13 bone69 bb view 7 #33

Commits on Jan 1, 2015

Commits on Jan 15, 2015