summaryrefslogtreecommitdiffstats
Commit message (Collapse)AuthorAgeFilesLines
* ARM: OMAP2+: only search for GPMC DT child nodes on probeJavier Martinez Canillas2013-04-301-23/+10
| | | | | | | | | | | | | | | | | | | The GPMC DT probe function use for_each_node_by_name() to search child device nodes of the GPMC controller. But this function does not use the GPMC device node as the root of the search and instead search across the complete Device Tree. This means that any device node on the DT that is using any of the GPMC child nodes names searched for will be returned even if they are not connected to the GPMC, making the gpmc_probe_xxx_child() function to fail. Fix this by using the GPMC device node as the search root so the search will be restricted to its children. Reported-by: Lars Poeschel <poeschel@lemonage.de> Signed-off-by: Javier Martinez Canillas <javier.martinez@collabora.co.uk> Signed-off-by: Jon Hunter <jon-hunter@ti.com>
* Documentation: dt: update properties in TI GPMC NAND exampleJon Hunter2013-04-301-14/+14
| | | | | | | | | | The GPMC timing properties for device-tree have been updated by adding a "-ns" or "-ps" suffix to indicate the units of time the property represents. Therefore, update the timing property names for TI GPMC NAND example. Signed-off-by: Jon Hunter <jon-hunter@ti.com> Acked-by: Grant Likely <grant.likely@secretlab.ca>
* Documentation: dt: update TI GPMC ethernet binding propertiesJavier Martinez Canillas2013-04-301-28/+28
| | | | | | | | | | The GPMC timing properties for device-tree have been updated by adding a "-ns" or "-ps" suffix to indicate the units of time the property represents. Therefore, update the timing property names for TI GPMC ethernet binding. Signed-off-by: Javier Martinez Canillas <javier.martinez@collabora.co.uk> Signed-off-by: Jon Hunter <jon-hunter@ti.com>
* Merge branch 'omap-gpmc-for-v3.10-take2' of git://github.com/jonhunter/linux ↵Tony Lindgren2013-04-0410-309/+831
|\ | | | | | | into omap-for-v3.10/gpmc
| * ARM: OMAP2+: Add GPMC DT support for Ethernet child nodesJavier Martinez Canillas2013-04-042-0/+105
| | | | | | | | | | | | | | | | | | | | | | | | | | Besides being used to interface with external memory devices, the General-Purpose Memory Controller can be used to connect Pseudo-SRAM devices such as ethernet controllers to OMAP2+ processors using the TI GPMC as a data bus. This patch allows an ethernet chip to be defined as an GPMC child device node. Signed-off-by: Javier Martinez Canillas <javier.martinez@collabora.co.uk> Signed-off-by: Jon Hunter <jon-hunter@ti.com>
| * ARM: OMAP2+: rename gpmc_probe_nor_child() to gpmc_probe_generic_child()Javier Martinez Canillas2013-04-041-5/+5
| | | | | | | | | | | | | | | | | | | | | | | | | | | | The gpmc_probe_nor_child() function is used in the GPMC driver to configure the GPMC for a NOR child device node. But this function is quite generic and all the NOR specific configuration is made by the driver of the actual NOR flash memory used. Other Pseudo-SRAM devices such as ethernet controllers need a similar setup so by making this function generic it can be used for those too. Signed-off-by: Javier Martinez Canillas <javier.martinez@collabora.co.uk> Signed-off-by: Jon Hunter <jon-hunter@ti.com>
| * ARM: OMAP2+: return -ENODEV if GPMC child device creation failsJavier Martinez Canillas2013-04-041-0/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | gpmc_probe_nor_child() calls of_platform_device_create() to create a platform device for the NOR child. If this function fails the value of ret is returned to the caller but this value is zero since it was assigned the return of a previous call to gpmc_cs_program_settings() that had to succeed or otherwise gpmc_probe_nor_child() would have returned before. This means that if of_platform_device_create() fails, 0 will be returned to the caller instead of an appropriate error code. Signed-off-by: Javier Martinez Canillas <javier.martinez@collabora.co.uk> Signed-off-by: Jon Hunter <jon-hunter@ti.com> Tested-by: Ezequiel Garcia <ezequiel.garcia@free-electrons.com>
| * ARM: OMAP2+: Allow GPMC probe to complete even if CS mapping failsJon Hunter2013-04-041-17/+7
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | When the GPMC driver is probed, we call gpmc_mem_init() to see which chip-selects have already been configured and enabled by the boot-loader and allocate space for them. If we fail to allocate space for one chip-select, then we return failure from the probe and the GPMC driver will not be available. Rather than render the GPMC useless for all GPMC devices, if we fail to allocate space for one chip-select print a warning and disable the chip-select. This way other GPMC clients can still be used. There is no downside to this approach, because all GPMC clients need to request a chip-select before they can use the GPMC and on requesting a chip-select, if memory has not already been reserved for the chip-select then it will be. Signed-off-by: Jon Hunter <jon-hunter@ti.com> Tested-by: Ezequiel Garcia <ezequiel.garcia@free-electrons.com>
| * ARM: OMAP2+: Remove unnecesssary GPMC definitions and variableJon Hunter2013-04-041-7/+5
| | | | | | | | | | | | | | | | | | | | With commit 21cc2bd (ARM: OMAP2+: Remove apollon board support) the variable "boot_rom_space" is now not needed and the code surrounding this variable can be cleaned up and simplified. Remove unnecessary definitions and clean-up the comment as well. Signed-off-by: Jon Hunter <jon-hunter@ti.com> Tested-by: Ezequiel Garcia <ezequiel.garcia@free-electrons.com>
| * ARM: OMAP2+: Detect incorrectly aligned GPMC base addressJon Hunter2013-04-041-3/+19
| | | | | | | | | | | | | | | | | | | | | | | | | | Each GPMC chip-select can be configured to map 16MB, 32MB, 64MB or 128MB of address space. The physical base address where a chip-select starts is also configurable and must be aligned on a boundary that is equal to or greater than the size of the address space mapped bt the chip-select. When enabling a GPMC chip-select, ensure that the base address is aligned to the appropriate boundary. Reported-by: Mark Jackson <mpfj-list@mimc.co.uk> Signed-off-by: Jon Hunter <jon-hunter@ti.com> Tested-by: Ezequiel Garcia <ezequiel.garcia@free-electrons.com>
| * ARM: OMAP2+: Convert ONENAND to retrieve GPMC settings from DTJon Hunter2013-04-042-6/+18
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | When booting with device-tree, retrieve GPMC settings for ONENAND from the device-tree blob. This will allow us to remove all static settings stored in the gpmc-nand.c in the future once the migration to device-tree is complete. The user must now specify the ONENAND device width in the device-tree binding so that the GPMC can be programmed correctly. Therefore, update the device-tree binding documentation for ONENAND devices connected to the GPMC to reflect this. Please note that this does not include GPMC timings for ONENAND. The timings are being calculated at runtime. There is some legacy code that only enables read wait monitoring for non-OMAP3 devices. There are no known OMAP3 device issues that prevent this feature being enabled and so when booting with device-tree use the wait-monitoring settings described in the device-tree blob. Signed-off-by: Jon Hunter <jon-hunter@ti.com> Tested-by: Ezequiel Garcia <ezequiel.garcia@free-electrons.com>
| * ARM: OMAP2+: Convert NAND to retrieve GPMC settings from DTJon Hunter2013-04-041-6/+10
| | | | | | | | | | | | | | | | | | | | When booting with device-tree, retrieve GPMC settings for NAND from the device-tree blob. This will allow us to remove all static settings stored in the gpmc-nand.c in the future once the migration to device-tree is complete. Signed-off-by: Jon Hunter <jon-hunter@ti.com> Tested-by: Ezequiel Garcia <ezequiel.garcia@free-electrons.com>
| * ARM: OMAP2+: Add device-tree support for NOR flashJon Hunter2013-04-042-0/+213
| | | | | | | | | | | | | | | | | | | | | | NOR flash is not currently supported when booting with device-tree on OMAP2+ devices. Add support to detect and configure NOR devices when booting with device-tree. Add documentation for the TI GPMC NOR binding. Signed-off-by: Jon Hunter <jon-hunter@ti.com> Tested-by: Ezequiel Garcia <ezequiel.garcia@free-electrons.com>
| * ARM: OMAP2+: Add additional GPMC timing parametersJon Hunter2013-04-042-74/+98
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Some of the GPMC timings parameters are currently missing from the GPMC device-tree binding. Add these parameters to the binding documentation as well as code to read them. Also add either "-ps" or "-ns" suffix to the GPMC timing properties to indicate whether the timing is in picoseconds or nanoseconds. The existing code in gpmc_read_timings_dt() is checking the value of of_property_read_u32() and only is successful storing the value read in the gpmc_timings structure. Checking the return value in this case is not necessary and we can simply read the value, if present, and store directly in the gpmc_timings structure. Therefore, simplify the code by removing these checks. The comment in the gpmc_read_timings_dt() function, "only for OMAP3430" is also incorrect as it is applicable to all OMAP3+ devices. So correct this too. Signed-off-by: Jon Hunter <jon-hunter@ti.com> Tested-by: Ezequiel Garcia <ezequiel.garcia@free-electrons.com>
| * ARM: OMAP2+: Add function to read GPMC settings from device-treeJon Hunter2013-04-013-0/+65
| | | | | | | | | | | | | | | | | | | | | | Adds a function to read the various GPMC chip-select settings from device-tree and store them in the gpmc_settings structure. Update the GPMC device-tree binding documentation to describe these options. Signed-off-by: Jon Hunter <jon-hunter@ti.com> Tested-by: Ezequiel Garcia <ezequiel.garcia@free-electrons.com>
| * ARM: OMAP2+: Don't configure of chip-select options in gpmc_cs_configure()Jon Hunter2013-04-013-47/+9
| | | | | | | | | | | | | | | | | | | | With the addition of the gpmc_cs_program_settings(), we no longer need or use gpmc_cs_configure() to configure some of the GPMC chip-select options. So rename the function to gpmc_configure() and remove code that modifies options in the CONFIG1 register. Signed-off-by: Jon Hunter <jon-hunter@ti.com> Tested-by: Ezequiel Garcia <ezequiel.garcia@free-electrons.com>
| * ARM: OMAP2+: Convert TUSB to use gpmc_cs_program_settings()Jon Hunter2013-04-011-24/+19
| | | | | | | | | | | | | | | | | | Convert the OMAP2+ TUSB code to use the gpmc_cs_program_settings() function for configuring the various GPMC options instead of directly programming the CONFIG1 register. Signed-off-by: Jon Hunter <jon-hunter@ti.com> Tested-by: Ezequiel Garcia <ezequiel.garcia@free-electrons.com>
| * ARM: OMAP2+: Convert SMC91x to use gpmc_cs_program_settings()Jon Hunter2013-04-011-13/+17
| | | | | | | | | | | | | | | | | | | | | | | | | | Convert the OMAP2+ SMC91x code to use the gpmc_cs_program_settings() function for configuring the various GPMC options instead of directly programming the CONFIG1 register. Move configuration of the GPMC settings outside retime function and this does not need to be done if the timings are changed dynamically at runtime. Signed-off-by: Jon Hunter <jon-hunter@ti.com> Tested-by: Ezequiel Garcia <ezequiel.garcia@free-electrons.com>
| * ARM: OMAP2+: Convert NAND to use gpmc_cs_program_settings()Jon Hunter2013-04-011-12/+23
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Convert the OMAP2+ NAND code to use the gpmc_cs_program_settings() function for configuring the various GPMC options instead of directly programming the CONFIG1 register. This moves the configuration of some GPMC options outside the nand_gpmc_retime() because these options should only need to be set once regardless of whether the gpmc timing is changing dynamically at runtime. The programming of where the wait-pin is also moved slightly, but this will not have any impact to existing devices as no boards are currently setting the dev_ready variable. Signed-off-by: Jon Hunter <jon-hunter@ti.com> Tested-by: Ezequiel Garcia <ezequiel.garcia@free-electrons.com>
| * ARM: OMAP2+: Convert ONENAND to use gpmc_cs_program_settings()Jon Hunter2013-04-011-36/+25
| | | | | | | | | | | | | | | | | | Convert the OMAP2+ ONENAND code to use the gpmc_cs_program_settings() function for configuring the various GPMC options instead of directly programming the CONFIG1 register. Signed-off-by: Jon Hunter <jon-hunter@ti.com> Tested-by: Ezequiel Garcia <ezequiel.garcia@free-electrons.com>
| * ARM: OMAP2+: Add function for configuring GPMC settingsJon Hunter2013-04-012-0/+106
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The GPMC has various different configuration options such as bus-width, synchronous or asychronous mode selection, burst mode options etc. Currently, there is no common function for configuring these options and various devices set these options by either programming the GPMC CONFIG1 register directly or by calling gpmc_cs_configure() to set some of the options. Add a new function for configuring all of the GPMC options. Having a common function for configuring this options will simplify code and ease the migration to device-tree. Also add a new capability flag to detect devices that support the address-address-data multiplexing mode. Signed-off-by: Jon Hunter <jon-hunter@ti.com> Tested-by: Ezequiel Garcia <ezequiel.garcia@free-electrons.com>
| * ARM: OMAP2+: Add structure for storing GPMC settingsJon Hunter2013-04-015-40/+72
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The GPMC has various different configuration options such as bus-width, synchronous or asychronous mode selection, burst mode options etc. Currently, there is no central structure for storing all these options when configuring the GPMC for a given device. Some of the options are stored in the GPMC timing structure and some are directly programmed into the GPMC configuration register. Add a new structure to store these options and convert code to use this structure. Adding this structure will allow us to create a common function for configuring these options. Signed-off-by: Jon Hunter <jon-hunter@ti.com> Tested-by: Ezequiel Garcia <ezequiel.garcia@free-electrons.com>
| * ARM: OMAP2+: Add variable to store number of GPMC waitpinsJon Hunter2013-04-011-0/+13
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The GPMC has wait-pin signals that can be assigned to a chip-select to monitor the ready signal of an external device. Add a variable to indicate the total number of wait-pins for a given device. This will allow us to detect if the wait-pin being selected is valid or not. When booting with device-tree read the number of wait-pins from the device-tree blob. When device-tree is not used set the number of wait-pins to 4 which is valid for OMAP2-5 devices. Newer devices that have less wait-pins (such as AM335x) only support booting with device-tree and so hard-coding the wait-pin number when not using device-tree is fine. Signed-off-by: Jon Hunter <jon-hunter@ti.com> Tested-by: Ezequiel Garcia <ezequiel.garcia@free-electrons.com>
| * ARM: OMAP2+: Simplify code configuring ONENAND devicesJon Hunter2013-04-011-16/+10
| | | | | | | | | | | | | | | | | | | | | | | | | | | | The OMAP2+ code that configures the GPMC for ONENAND devices is copying structures between functions unnecessarily. Avoid this by passing pointers instead and simplify the code. A pointer to structure "omap_onenand_platform_data" is passed to the function omap2_onenand_calc_sync_timings(), but only the flags member of the structure is used. Simplify the code by only passing the flags member and not the entire structure. Signed-off-by: Jon Hunter <jon-hunter@ti.com> Tested-by: Ezequiel Garcia <ezequiel.garcia@free-electrons.com>
| * ARM: omap2: gpmc: Remove redundant chip select out of range checkEzequiel Garcia2013-04-011-9/+1
| | | | | | | | | | | | | | | | | | | | This check is done before the call to gpmc_cs_reserved() and gpmc_cs_set_reserved() and it's redundant to do it again in each function. This simplifies the code a bit. Signed-off-by: Ezequiel Garcia <ezequiel.garcia@free-electrons.com> Reviewed-by: Jon Hunter <jon-hunter@ti.com> Signed-off-by: Jon Hunter <jon-hunter@ti.com>
| * ARM: omap2: gpmc-onenand: Replace printk KERN_ERR with dev_warn()Ezequiel Garcia2013-04-011-1/+1
| | | | | | | | | | | | | | | | | | Since the condition is not an error but a warning, replace printk KERN_ERR with dev_warn. Signed-off-by: Ezequiel Garcia <ezequiel.garcia@free-electrons.com> Reviewed-by: Jon Hunter <jon-hunter@ti.com> Signed-off-by: Jon Hunter <jon-hunter@ti.com>
| * ARM: omap2: gpmc-onenand: Replace pr_err() with dev_err()Ezequiel Garcia2013-04-011-3/+4
| | | | | | | | | | | | | | | | | | Do this becasue dev_err() is preferred over pr_err() and because it will match gpmc-nand, thus the code shows looks more consistent. Signed-off-by: Ezequiel Garcia <ezequiel.garcia@free-electrons.com> Reviewed-by: Jon Hunter <jon-hunter@ti.com> Signed-off-by: Jon Hunter <jon-hunter@ti.com>
| * ARM: omap2: gpmc-onenand: Print something useful on CS request failureEzequiel Garcia2013-04-011-1/+2
| | | | | | | | | | | | | | | | | | If CS request fails the current error message is rather unhelpful. Fix it by printing the failing chip select and the error code. Signed-off-by: Ezequiel Garcia <ezequiel.garcia@free-electrons.com> Reviewed-by: Jon Hunter <jon-hunter@ti.com> Signed-off-by: Jon Hunter <jon-hunter@ti.com>
| * ARM: omap2: gpmc-nand: Print something useful on CS request failureEzequiel Garcia2013-04-011-1/+2
| | | | | | | | | | | | | | | | | | If CS request fails the current error message is rather unhelpful. Fix it by printing the failing chip select and the error code. Signed-off-by: Ezequiel Garcia <ezequiel.garcia@free-electrons.com> Reviewed-by: Jon Hunter <jon-hunter@ti.com> Signed-off-by: Jon Hunter <jon-hunter@ti.com>
| * ARM: omap2: gpmc: Fix gpmc_cs_reserved() return valueEzequiel Garcia2013-04-011-2/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Currently gpmc_cs_reserved() return value is somewhat inconsistent, returning a negative value on an error condition, a positive value if the chip select is reserved and zero if it's available. Fix this by returning a boolean value as the function name suggests: * true if the chip select is reserved, * false if it's available Suggested-by: Felipe Balbi <balbi@ti.com> Signed-off-by: Ezequiel Garcia <ezequiel.garcia@free-electrons.com> Reviewed-by: Jon Hunter <jon-hunter@ti.com> Signed-off-by: Jon Hunter <jon-hunter@ti.com>
| * ARM: omap2: gpmc: Remove unused gpmc_round_ns_to_ticks() functionEzequiel Garcia2013-04-011-7/+0
| | | | | | | | | | | | | | | | | | This function is not used anywhere, so it's safe to remove it. This means less code to maintain. Signed-off-by: Ezequiel Garcia <ezequiel.garcia@free-electrons.com> Reviewed-by: Jon Hunter <jon-hunter@ti.com> Signed-off-by: Jon Hunter <jon-hunter@ti.com>
| * ARM: omap2: gpmc: Mark local scoped functions staticEzequiel Garcia2013-04-012-14/+7
| | | | | | | | | | | | | | | | | | This patch marks a bunch of functions that are local to gpmc.c file only as static. Signed-off-by: Ezequiel Garcia <ezequiel.garcia@free-electrons.com> Reviewed-by: Jon Hunter <jon-hunter@ti.com> Signed-off-by: Jon Hunter <jon-hunter@ti.com>
| * ARM: OMAP: Clear GPMC bits when applying new setting.Mark Jackson2013-04-012-1/+8
|/ | | | | | | | | | | | | | | | | When setting the GPMC device type, make sure any previous bits are cleared down, before applying the new setting. For OMAP4+ devices MUXADDDATA is a 2-bit field (bits 9:8) where as for OMAP2/3 devices it was only a one bit field (bit 9). For OMAP2/3 devices bit 8 is reserved and the OMAP documentation says to write a 0 to this bit. So clearing bit 8 on OMAP2/3 devices should not be a problem. Hence update the code to handle both bits 8 and 9 for all devices. Signed-off-by: Mark Jackson <mpfj@newflow.co.uk> [jon-hunter@ti.com: updated changelog] Signed-off-by: Jon Hunter <jon-hunter@ti.com>
* Merge commit '31d9adca82ce65e5c99d045b5fd917c702b6fce3' into tmpJon Hunter2013-04-0110415-275128/+535997
|\ | | | | | | | | Conflicts: arch/arm/plat-omap/dmtimer.c
| * ARM: OMAP2+: Fix broken gpmc supportJon Hunter2013-03-041-3/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Commit 6797b4fe (ARM: OMAP2+: Prevent potential crash if GPMC probe fails) added code to ensure that GPMC chip-selects could not be requested until the device probe was successful. The chip-selects should have been unreserved at the end of the probe function, but the code to unreserve them appears to have ended up in the gpmc_calc_timings() function and hence, this is causing problems requesting chip-selects. Fix this merge error by unreserving the chip-selects at the end of the probe, but before we call the gpmc child probe functions (for device-tree) which request a chip-select. Signed-off-by: Jon Hunter <jon-hunter@ti.com> Tested-by: Ezequiel Garcia <ezequiel.garcia@free-electrons.com> Tested-by: Philip Avinash <avinashphilip@ti.com> Tested-by: Grazvydas Ignotas <notasas@gmail.com> [tony@atomide.com: updated description to add breaking commit id] Signed-off-by: Tony Lindgren <tony@atomide.com>
| * ARM: OMAP1: Fix build related to kgdb.h no longer including serial_8250.hTony Lindgren2013-03-043-0/+6
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Commit 16559ae4 (kgdb: remove #include <linux/serial_8250.h> from kgdb.h) had a side effect of breaking omap1_defconfig build as some headers were included indirectly: arch/arm/mach-omap1/board-h2.c:249: error: ‘INT_KEYBOARD’ undeclared here (not in a function) ... This worked earlier as linux/serial_8250.h included linux/serial_core.h, via linux/serial_8250.h from linux/kgdb.h. Fix this by including the necessary headers directly. Signed-off-by: Tony Lindgren <tony@atomide.com>
| * Linux 3.9-rc1v3.9-rc1Linus Torvalds2013-03-041-2/+2
| |
| * Merge tag 'disintegrate-fbdev-20121220' of ↵Linus Torvalds2013-03-038-254/+284
| |\ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | git://git.infradead.org/users/dhowells/linux-headers Pull fbdev UAPI disintegration from David Howells: "You'll be glad to here that the end is nigh for the UAPI patches. Only the fbdev/framebuffer piece remains now that the SCSI stuff has gone in. Here are the UAPI disintegration bits for the fbdev drivers. It appears that Florian hasn't had time to deal with my patch, but back in December he did say he didn't mind if I pushed it forward." Yay. No more uapi movement. And hopefully no more big header file cleanups coming up either, it just tends to be very painful. * tag 'disintegrate-fbdev-20121220' of git://git.infradead.org/users/dhowells/linux-headers: UAPI: (Scripted) Disintegrate include/video
| | * UAPI: (Scripted) Disintegrate include/videoDavid Howells2012-12-208-254/+284
| | | | | | | | | | | | | | | | | | | | | | | | | | | Signed-off-by: David Howells <dhowells@redhat.com> Acked-by: Arnd Bergmann <arnd@arndb.de> Acked-by: Thomas Gleixner <tglx@linutronix.de> Acked-by: Michael Kerrisk <mtk.manpages@gmail.com> Acked-by: Paul E. McKenney <paulmck@linux.vnet.ibm.com> Acked-by: Dave Jones <davej@redhat.com>
| * | Merge tag 'stable/for-linus-3.9-rc1-tag' of ↵Linus Torvalds2013-03-035-49/+57
| |\ \ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | git://git.kernel.org/pub/scm/linux/kernel/git/konrad/xen Pull Xen bug-fixes from Konrad Rzeszutek Wilk: - Update the Xen ACPI memory and CPU hotplug locking mechanism. - Fix PAT issues wherein various applications would not start - Fix handling of multiple MSI as AHCI now does it. - Fix ARM compile failures. * tag 'stable/for-linus-3.9-rc1-tag' of git://git.kernel.org/pub/scm/linux/kernel/git/konrad/xen: xenbus: fix compile failure on ARM with Xen enabled xen/pci: We don't do multiple MSI's. xen/pat: Disable PAT using pat_enabled value. xen/acpi: xen cpu hotplug minor updates xen/acpi: xen memory hotplug minor updates
| | * | xenbus: fix compile failure on ARM with Xen enabledSteven Noonan2013-03-011-0/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Adding an include of linux/mm.h resolves this: drivers/xen/xenbus/xenbus_client.c: In function ‘xenbus_map_ring_valloc_hvm’: drivers/xen/xenbus/xenbus_client.c:532:66: error: implicit declaration of function ‘page_to_section’ [-Werror=implicit-function-declaration] CC: stable@vger.kernel.org Signed-off-by: Steven Noonan <steven@uplinklabs.net> Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
| | * | xen/pci: We don't do multiple MSI's.Konrad Rzeszutek Wilk2013-03-011-0/+9
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | There is no hypercall to setup multiple MSI per PCI device. As such with these two new commits: - 08261d87f7d1b6253ab3223756625a5c74532293 PCI/MSI: Enable multiple MSIs with pci_enable_msi_block_auto() - 5ca72c4f7c412c2002363218901eba5516c476b1 AHCI: Support multiple MSIs we would call the PHYSDEVOP_map_pirq 'nvec' times with the same contents of the PCI device. Sander discovered that we would get the same PIRQ value 'nvec' times and return said values to the caller. That of course meant that the device was configured only with one MSI and AHCI would fail with: ahci 0000:00:11.0: version 3.0 xen: registering gsi 19 triggering 0 polarity 1 xen: --> pirq=19 -> irq=19 (gsi=19) (XEN) [2013-02-27 19:43:07] IOAPIC[0]: Set PCI routing entry (6-19 -> 0x99 -> IRQ 19 Mode:1 Active:1) ahci 0000:00:11.0: AHCI 0001.0200 32 slots 4 ports 6 Gbps 0xf impl SATA mode ahci 0000:00:11.0: flags: 64bit ncq sntf ilck pm led clo pmp pio slum part ahci: probe of 0000:00:11.0 failed with error -22 That is b/c in ahci_host_activate the second call to devm_request_threaded_irq would return -EINVAL as we passed in (on the second run) an IRQ that was never initialized. CC: stable@vger.kernel.org Reported-and-Tested-by: Sander Eikelenboom <linux@eikelenboom.it> Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
| | * | xen/pat: Disable PAT using pat_enabled value.Konrad Rzeszutek Wilk2013-02-281-1/+9
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The git commit 8eaffa67b43e99ae581622c5133e20b0f48bcef1 (xen/pat: Disable PAT support for now) explains in details why we want to disable PAT for right now. However that change was not enough and we should have also disabled the pat_enabled value. Otherwise we end up with: mmap-example:3481 map pfn expected mapping type write-back for [mem 0x00010000-0x00010fff], got uncached-minus ------------[ cut here ]------------ WARNING: at /build/buildd/linux-3.8.0/arch/x86/mm/pat.c:774 untrack_pfn+0xb8/0xd0() mem 0x00010000-0x00010fff], got uncached-minus ------------[ cut here ]------------ WARNING: at /build/buildd/linux-3.8.0/arch/x86/mm/pat.c:774 untrack_pfn+0xb8/0xd0() ... Pid: 3481, comm: mmap-example Tainted: GF 3.8.0-6-generic #13-Ubuntu Call Trace: [<ffffffff8105879f>] warn_slowpath_common+0x7f/0xc0 [<ffffffff810587fa>] warn_slowpath_null+0x1a/0x20 [<ffffffff8104bcc8>] untrack_pfn+0xb8/0xd0 [<ffffffff81156c1c>] unmap_single_vma+0xac/0x100 [<ffffffff81157459>] unmap_vmas+0x49/0x90 [<ffffffff8115f808>] exit_mmap+0x98/0x170 [<ffffffff810559a4>] mmput+0x64/0x100 [<ffffffff810560f5>] dup_mm+0x445/0x660 [<ffffffff81056d9f>] copy_process.part.22+0xa5f/0x1510 [<ffffffff81057931>] do_fork+0x91/0x350 [<ffffffff81057c76>] sys_clone+0x16/0x20 [<ffffffff816ccbf9>] stub_clone+0x69/0x90 [<ffffffff816cc89d>] ? system_call_fastpath+0x1a/0x1f ---[ end trace 4918cdd0a4c9fea4 ]--- (a similar message shows up if you end up launching 'mcelog') The call chain is (as analyzed by Liu, Jinsong): do_fork --> copy_process --> dup_mm --> dup_mmap --> copy_page_range --> track_pfn_copy --> reserve_pfn_range --> line 624: flags != want_flags It comes from different memory types of page table (_PAGE_CACHE_WB) and MTRR (_PAGE_CACHE_UC_MINUS). Stefan Bader dug in this deep and found out that: "That makes it clearer as this will do reserve_memtype(...) --> pat_x_mtrr_type --> mtrr_type_lookup --> __mtrr_type_lookup And that can return -1/0xff in case of MTRR not being enabled/initialized. Which is not the case (given there are no messages for it in dmesg). This is not equal to MTRR_TYPE_WRBACK and thus becomes _PAGE_CACHE_UC_MINUS. It looks like the problem starts early in reserve_memtype: if (!pat_enabled) { /* This is identical to page table setting without PAT */ if (new_type) { if (req_type == _PAGE_CACHE_WC) *new_type = _PAGE_CACHE_UC_MINUS; else *new_type = req_type & _PAGE_CACHE_MASK; } return 0; } This would be what we want, that is clearing the PWT and PCD flags from the supported flags - if pat_enabled is disabled." This patch does that - disabling PAT. CC: stable@vger.kernel.org # 3.3 and further Reported-by: Sander Eikelenboom <linux@eikelenboom.it> Reported-and-Tested-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com> Reported-and-Tested-by: Stefan Bader <stefan.bader@canonical.com> Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
| | * | xen/acpi: xen cpu hotplug minor updatesLiu Jinsong2013-02-251-22/+12
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Recently at native Rafael did some cleanup for acpi, say, drop acpi_bus_add, remove unnecessary argument of acpi_bus_scan, and run acpi_bus_scan under acpi_scan_lock. This patch does similar cleanup for xen cpu hotplug, removing redundant logic, and adding lock. Signed-off-by: Liu Jinsong <jinsong.liu@intel.com> Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
| | * | xen/acpi: xen memory hotplug minor updatesLiu Jinsong2013-02-251-26/+26
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Dan Carpenter found current xen memory hotplug logic has potential issue: at func acpi_memory_get_device() *mem_device = acpi_driver_data(device); while the device may be NULL and then dereference. At native side, Rafael recently updated acpi_memory_get_device(), dropping acpi_bus_add, adding lock, and avoiding above issue. This patch updates xen memory hotplug logic accordingly, removing redundant logic, adding lock, and avoiding dereference. Signed-off-by: Liu Jinsong <jinsong.liu@intel.com> Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
| * | | Merge branch 'for-linus' of ↵Linus Torvalds2013-03-0326-171/+108
| |\ \ \ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | git://git.kernel.org/pub/scm/linux/kernel/git/viro/vfs Pull more VFS bits from Al Viro: "Unfortunately, it looks like xattr series will have to wait until the next cycle ;-/ This pile contains 9p cleanups and fixes (races in v9fs_fid_add() etc), fixup for nommu breakage in shmem.c, several cleanups and a bit more file_inode() work" * 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/viro/vfs: constify path_get/path_put and fs_struct.c stuff fix nommu breakage in shmem.c cache the value of file_inode() in struct file 9p: if v9fs_fid_lookup() gets to asking server, it'd better have hashed dentry 9p: make sure ->lookup() adds fid to the right dentry 9p: untangle ->lookup() a bit 9p: double iput() in ->lookup() if d_materialise_unique() fails 9p: v9fs_fid_add() can't fail now v9fs: get rid of v9fs_dentry 9p: turn fid->dlist into hlist 9p: don't bother with private lock in ->d_fsdata; dentry->d_lock will do just fine more file_inode() open-coded instances selinux: opened file can't have NULL or negative ->f_path.dentry (In the meantime, the hlist traversal macros have changed, so this required a semantic conflict fixup for the newly hlistified fid->dlist)
| | * | | constify path_get/path_put and fs_struct.c stuffAl Viro2013-03-025-10/+10
| | | | | | | | | | | | | | | | | | | | Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
| | * | | fix nommu breakage in shmem.cAl Viro2013-03-021-3/+2
| | | | | | | | | | | | | | | | | | | | Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
| | * | | cache the value of file_inode() in struct fileAl Viro2013-03-023-2/+6
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Note that this thing does *not* contribute to inode refcount; it's pinned down by dentry. Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
| | * | | 9p: if v9fs_fid_lookup() gets to asking server, it'd better have hashed dentryAl Viro2013-02-281-3/+17
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | ... otherwise the path we'd built isn't worth much. Don't accept such fids obtained from paths unless dentry is still alived by the end of the work. Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
generated by cgit v1.2.3 (git 2.39.1) at 2025-01-24 06:31:42 +0100