Linux Kernel https://git.stealer.net/cgit.cgi/user/sven/linux.git/atom?h=v4.0.3 2015-01-30T04:57:43Z 2015-01-30T04:57:43Z Scott Wood scottwood@freescale.com 2014-12-11T00:56:22Z urn:sha1:c3e09b3a90850b299aa805c32945163e5101ddcd T1040 has a different version of corenet-cf, despite being incorrectly labelled with a fsl,corenet2-cf compatible. The t1040 version of corenet-cf has a version register that can be read to distinguish. The t4240/b4860 version officially does not, but testing shows that it does and has a different value, so use that. If somehow this ends up not being reliable and we treat a t4240/b4860 as a t1040 (the reverse should not happen, as t1040's version register is official), currently the worst that should happen is writing to reserved bits to enable events that don't exist. The changes to the t1040 version of corenet-cf that this driver cares about are the addition of two new error events. There are also changes to the format of cecar2, which is printed, but not interpreted, by this driver. Signed-off-by: Scott Wood <scottwood@freescale.com> 2014-12-17T17:59:26Z Linus Torvalds torvalds@linux-foundation.org 2014-12-17T17:59:26Z urn:sha1:d6666be6f0c43efb9475d1d35fbef9f8be61b7b1 Pull MTD updates from Brian Norris: "Summary: - Add device tree support for DoC3 - SPI NOR: Refactoring, for better layering between spi-nor.c and its driver users (e.g., m25p80.c) New flash device support Support 6-byte ID strings - NAND: New NAND driver for Allwinner SoC's (sunxi) GPMI NAND: add support for raw (no ECC) access, for testing purposes Add ATO manufacturer ID A few odd driver fixes - MTD tests: Allow testers to compensate for OOB bitflips in oobtest Fix a torturetest regression - nandsim: Support longer ID byte strings And more" * tag 'for-linus-20141215' of git://git.infradead.org/linux-mtd: (63 commits) mtd: tests: abort torturetest on erase errors mtd: physmap_of: fix potential NULL dereference mtd: spi-nor: allow NULL as chip name and try to auto detect it mtd: nand: gpmi: add raw oob access functions mtd: nand: gpmi: add proper raw access support mtd: nand: gpmi: add gpmi_copy_bits function mtd: spi-nor: factor out write_enable() for erase commands mtd: spi-nor: add support for s25fl128s mtd: spi-nor: remove the jedec_id/ext_id mtd: spi-nor: add id/id_len for flash_info{} mtd: nand: correct the comment of function nand_block_isreserved() jffs2: Drop bogus if in comment mtd: atmel_nand: replace memcpy32_toio/memcpy32_fromio with memcpy mtd: cafe_nand: drop duplicate .write_page implementation mtd: m25p80: Add support for serial flash Spansion S25FL132K MTD: m25p80: fix inconsistency in m25p_ids compared to spi_nor_ids mtd: spi-nor: improve wait-till-ready timeout loop mtd: delete unnecessary checks before two function calls mtd: nand: omap: Fix NAND enumeration on 3430 LDP mtd: nand: add ATO manufacturer info ... 2014-12-15T00:10:09Z Linus Torvalds torvalds@linux-foundation.org 2014-12-15T00:10:09Z urn:sha1:e6b5be2be4e30037eb551e0ed09dd97bd00d85d3 Pull driver core update from Greg KH: "Here's the set of driver core patches for 3.19-rc1. They are dominated by the removal of the .owner field in platform drivers. They touch a lot of files, but they are "simple" changes, just removing a line in a structure. Other than that, a few minor driver core and debugfs changes. There are some ath9k patches coming in through this tree that have been acked by the wireless maintainers as they relied on the debugfs changes. Everything has been in linux-next for a while" * tag 'driver-core-3.19-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/driver-core: (324 commits) Revert "ath: ath9k: use debugfs_create_devm_seqfile() helper for seq_file entries" fs: debugfs: add forward declaration for struct device type firmware class: Deletion of an unnecessary check before the function call "vunmap" firmware loader: fix hung task warning dump devcoredump: provide a one-way disable function device: Add dev_<level>_once variants ath: ath9k: use debugfs_create_devm_seqfile() helper for seq_file entries ath: use seq_file api for ath9k debugfs files debugfs: add helper function to create device related seq_file drivers/base: cacheinfo: remove noisy error boot message Revert "core: platform: add warning if driver has no owner" drivers: base: support cpu cache information interface to userspace via sysfs drivers: base: add cpu_device_create to support per-cpu devices topology: replace custom attribute macros with standard DEVICE_ATTR* cpumask: factor out show_cpumap into separate helper function driver core: Fix unbalanced device reference in drivers_probe driver core: fix race with userland in device_add() sysfs/kernfs: make read requests on pre-alloc files use the buffer. sysfs/kernfs: allow attributes to request write buffer be pre-allocated. fs: sysfs: return EGBIG on write if offset is larger than file size ... 2014-12-10T00:57:56Z Linus Torvalds torvalds@linux-foundation.org 2014-12-10T00:57:56Z urn:sha1:fe78c54b4788b69bb2a8f157b524c933ea0c66d5 Pull ARM SoC/OMAP GPMC driver cleanup and move from Arnd Bergmann: "The GPMC driver has traditionally been considered a part of the OMAP platform code and tightly interweaved with some of the boards. With this cleanup, it has finally come to the point where it makes sense to move it out of arch/arm into drivers/memory, where we already have other drivers for similar hardware. The cleanups are still ongoing, with the goal of eventually having a standalone driver that does not require an interface to architecture code. This is a separate branch because of dependencies on multiple other branches, and to keep the drivers changes separate from the normal cleanups" * tag 'omap-gpmc-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/arm/arm-soc: memory: gpmc: Move omap gpmc code to live under drivers ARM: OMAP2+: Move GPMC initcall to devices.c ARM: OMAP2+: Prepare to move GPMC to drivers by platform data header ARM: OMAP2+: Remove unnecesary include in GPMC driver ARM: OMAP2+: Drop board file for 3430sdp ARM: OMAP2+: Drop board file for ti8168evm ARM: OMAP2+: Drop legacy code for gpmc-smc91x.c ARM: OMAP2+: Require proper GPMC timings for devices ARM: OMAP2+: Show bootloader GPMC timings to allow configuring the .dts file ARM: OMAP2+: Fix support for multiple devices on a GPMC chip select ARM: OMAP2+: gpmc: Sanity check GPMC fck on probe ARM: OMAP2+: gpmc: Keep Chip Select disabled while configuring it ARM: OMAP2+: gpmc: Always enable A26-A11 for non NAND devices ARM: OMAP2+: gpmc: Error out if timings fail in gpmc_probe_generic_child() ARM: OMAP2+: gpmc: Print error message in set_gpmc_timing_reg() 2014-12-04T15:11:47Z Thierry Reding treding@nvidia.com 2014-04-16T07:24:44Z urn:sha1:8918465163171322c77a19d5258a95f56d89d2e4 The memory controller on NVIDIA Tegra exposes various knobs that can be used to tune the behaviour of the clients attached to it. Currently this driver sets up the latency allowance registers to the HW defaults. Eventually an API should be exported by this driver (via a custom API or a generic subsystem) to allow clients to register latency requirements. This driver also registers an IOMMU (SMMU) that's implemented by the memory controller. It is supported on Tegra30, Tegra114 and Tegra124 currently. Tegra20 has a GART instead. The Tegra SMMU operates on memory clients and SWGROUPs. A memory client is a unidirectional, special-purpose DMA master. A SWGROUP represents a set of memory clients that form a logical functional unit corresponding to a single device. Typically a device has two clients: one client for read transactions and one client for write transactions, but there are also devices that have only read clients, but many of them (such as the display controllers). Because there is no 1:1 relationship between memory clients and devices the driver keeps a table of memory clients and the SWGROUPs that they belong to per SoC. Note that this is an exception and due to the fact that the SMMU is tightly integrated with the rest of the Tegra SoC. The use of these tables is discouraged in drivers for generic IOMMU devices such as the ARM SMMU because the same IOMMU could be used in any number of SoCs and keeping such tables for each SoC would not scale. Acked-by: Joerg Roedel <jroedel@suse.de> Signed-off-by: Thierry Reding <treding@nvidia.com> 2014-11-28T20:54:39Z Tony Lindgren tony@atomide.com 2014-11-20T17:13:42Z urn:sha1:186401937927426f85a28bd798e82ca18e4e5549 Just move to drivers as further clean-up can now happen there finally. Let's also add Roger and me to the MAINTAINERS so we get notified for any patches related to GPMC. Cc: Arnd Bergmann <arnd@arndb.de> Acked-by: Roger Quadros <rogerq@ti.com> Signed-off-by: Tony Lindgren <tony@atomide.com> 2014-11-05T22:45:53Z Aaron Sierra asierra@xes-inc.com 2014-08-26T23:18:33Z urn:sha1:096916610f415e07cfe71d71a391011c617be5ed Freescale's QorIQ T Series processors support 8 IFC chip selects within a memory map backward compatible with previous P Series processors which supported only 4 chip selects. Signed-off-by: Aaron Sierra <asierra@xes-inc.com> Signed-off-by: Brian Norris <computersforpeace@gmail.com> 2014-10-20T14:20:52Z Wolfram Sang wsa@the-dreams.de 2014-10-20T14:20:52Z urn:sha1:0f0d7e7b022b2d3b03a613048954dffb4af9a9b8 A platform_driver does not need to set an owner, it will be populated by the driver core. Signed-off-by: Wolfram Sang <wsa@the-dreams.de> 2014-08-25T13:35:26Z Nicolas Ferre nicolas.ferre@atmel.com 2014-08-25T13:35:26Z urn:sha1:e657ce689a85ff1c887b8020282e5b2ab1411ded Pull AT91 reset, poweroff and ram drivers from Maxime Ripard: "This tag holds the various new drivers introduced to move code that used to be in mach-at91 over to the proper frameworks. These files are the reboot and poweroff code for all AT91 SoCs but the RM9200, and the ram controller driver is not doing much at the time, except for grabing the RAM clock in order to leave it always enabled." Conflicts: arch/arm/mach-at91/Kconfig 2014-07-30T00:26:30Z Scott Wood scottwood@freescale.com 2014-07-02T23:52:11Z urn:sha1:54afbec0d57f322127e3886b04fe4fd860519bfb The CoreNet Coherency Fabric is part of the memory subsystem on some Freescale QorIQ chips. It can report coherency violations (e.g. due to misusing memory that is mapped noncoherent) as well as transactions that do not hit any local access window, or which hit a local access window with an invalid target ID. Signed-off-by: Scott Wood <scottwood@freescale.com> Reviewed-by: Bharat Bhushan <bharat.bhushan@freescale.com>