summaryrefslogtreecommitdiffstats
Commit message (Collapse)AuthorAgeFilesLines
* UBI: erase free PEB with bitflip in EC headerMatthieu CASTET2012-09-041-1/+1
| | | | | | | | | | Without this patch, these PEB are not scrubbed until we put data in them. Bitflip can accumulate latter and we can loose the EC header (but VID header should be intact and allow to recover data). Signed-off-by: Matthieu Castet <matthieu.castet@parrot.com> Cc: stable@vger.kernel.org Signed-off-by: Artem Bityutskiy <artem.bityutskiy@linux.intel.com>
* UBI: fix autoresize handling in R/O modeArtem Bityutskiy2012-09-041-0/+5
| | | | | | | | | | Currently UBI fails in autoresize when it is in R/O mode (e.g., because the underlying MTD device is R/O). This patch fixes the issue - we just skip autoresize and print a warning. Reported-by: Pali Rohár <pali.rohar@gmail.com> Cc: stable@vger.kernel.org Signed-off-by: Artem Bityutskiy <artem.bityutskiy@linux.intel.com>
* UBI: add max_beb_per1024 to attach ioctlRichard Genoud2012-09-043-3/+18
| | | | | | | | | This patch provides a possibility to set the "maximum expected number of bad blocks per 1024 blocks" (max_beb_per1024) for each mtd device using the UBI_IOCATT ioctl. Signed-off-by: Richard Genoud <richard.genoud@gmail.com> Signed-off-by: Artem Bityutskiy <artem.bityutskiy@linux.intel.com>
* UBI: allow specifying bad PEBs limit using module parameterRichard Genoud2012-09-042-15/+27
| | | | | | | | | | | | | This patch provides the possibility to adjust the "maximum expected number of bad blocks per 1024 blocks" (max_beb_per1024) for each mtd device. The majority of NAND devices have their max_beb_per1024 equal to 20, but sometimes it's more. Now, we can adjust that via a kernel parameter: ubi.mtd=<name|num|path>[,<vid_hdr_offs>[,max_beb_per1024]] Signed-off-by: Richard Genoud <richard.genoud@gmail.com> Signed-off-by: Artem Bityutskiy <artem.bityutskiy@linux.intel.com>
* UBI: check max_beb_per1024 value in ubi_attach_mtd_devRichard Genoud2012-09-041-0/+9
| | | | | | | | max_beb_per1024 shouldn't be negative, and a 0 value will be treated as the default value. For the upper bound, 768/1024 should be enough. Signed-off-by: Richard Genoud <richard.genoud@gmail.com> Signed-off-by: Artem Bityutskiy <artem.bityutskiy@linux.intel.com>
* UBI: prepare for max_beb_per1024 module parameter additionRichard Genoud2012-09-043-8/+12
| | | | | | | | | This patch prepare the way for the addition of max_beb_per1024 module parameter. There's no functional change. Signed-off-by: Richard Genoud <richard.genoud@gmail.com> Reviewed-by: Shmulik Ladkani <shmulik.ladkani@gmail.com> Signed-off-by: Artem Bityutskiy <artem.bityutskiy@linux.intel.com>
* UBI: introduce MTD_PARAM_MAX_COUNTRichard Genoud2012-09-041-2/+5
| | | | | Signed-off-by: Richard Genoud <richard.genoud@gmail.com> Signed-off-by: Artem Bityutskiy <artem.bityutskiy@linux.intel.com>
* UBI: separate bad_peb_limit in a functionRichard Genoud2012-09-041-23/+31
| | | | | | | No functional changes here, just to prepare for next patch. Signed-off-by: Richard Genoud <richard.genoud@gmail.com> Signed-off-by: Artem Bityutskiy <artem.bityutskiy@linux.intel.com>
* arm: sam9_l9260_defconfig: correct CONFIG_MTD_UBI_BEB_LIMITArtem Bityutskiy2012-09-041-1/+1
| | | | | | | | | | | | | | | | | | | UBI has changed the MTD_UBI_BEB_LIMIT semantics. It used to be a percent of total amount of eraseblock in the partition, and now it is the maximum amount of bad eraseblocks on the entire devise per 1024 eraseblocks. So not only the units changed, but also the meaning. Richard Genoud <richard.genoud@gmail.com> says: "I found the board: https://www.olimex.com/dev/sam9-L9260.html and the nand datasheet: http://www.rockbox.org/wiki/pub/Main/LyrePrototype/K9xxG08UXM.pdf page 11, we can see that the max_bad_bebper1024 is 25 (100 for 4096)" Thus, use "25" for sam9. Signed-off-by: Artem Bityutskiy <artem.bityutskiy@linux.intel.com>
* UBI: use the whole MTD device size to get bad_peb_limitRichard Genoud2012-09-042-9/+39
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | On NAND flash devices, UBI reserves some physical erase blocks (PEB) for bad block handling. Today, the number of reserved PEB can only be set as a percentage of the total number of PEB in each MTD partition. For example, for a NAND flash with 128KiB PEB, 2 MTD partition of 20MiB (mtd0) and 100MiB (mtd1) and 2% reserved PEB: - the UBI device on mtd0 will have 2 PEB reserved - the UBI device on mtd1 will have 16 PEB reserved The problem with this behaviour is that NAND flash manufacturers give a minimum number of valid block (NVB) during the endurance life of the device, e.g.: Parameter Symbol Min Max Unit Notes -------------------------------------------------------------- Valid block number NVB 1004 1024 Blocks 1 From this number we can deduce the maximum number of bad PEB that a device will contain during its endurance life: a 128MiB NAND flash (1024 PEB) will not have less than 20 bad blocks during the flash endurance life. But the manufacturer doesn't tell where those bad block will appear. He doesn't say either if they will be equally disposed on the whole device (and I'm pretty sure they won't). So, according to the datasheets, we should reserve the maximum number of bad PEB for each UBI device (worst case scenario: 20 bad blocks appears on the smallest MTD partition). So this patch make UBI use the whole MTD device size to calculate the maximum bad expected eraseblocks. The Kconfig option is in per1024 blocks, thus it can have a default value of 20 which is *very* common for NAND devices. Signed-off-by: Richard Genoud <richard.genoud@gmail.com> Signed-off-by: Artem Bityutskiy <artem.bityutskiy@linux.intel.com>
* mtd: mtdparts: introduce mtd_get_device_sizeRichard Genoud2012-09-042-0/+11
| | | | | | | | | | | 'mtd_get_device_size()' returns the size of the whole MTD device, that is the mtd_info master size. This will be used by UBI to calculate the maximum number of bad blocks (MBB) on a MTD device. Artem: amended the patch a bit. Signed-off-by: Richard Genoud <richard.genoud@gmail.com> Signed-off-by: Artem Bityutskiy <artem.bityutskiy@linux.intel.com>
* mtd: mark mtd_is_partition argument as constantRichard Genoud2012-09-042-2/+2
| | | | | | | | 'struct mtd_info' is not modified by 'mtd_is_partition()' so it can be marked as "const". Signed-off-by: Richard Genoud <richard.genoud@gmail.com> Signed-off-by: Artem Bityutskiy <artem.bityutskiy@linux.intel.com>
* arm: sam9_l9260_defconfig: remove non-existing config optionShmulik Ladkani2012-09-041-1/+0
| | | | | | | | CONFIG_MTD_UBI_BEB_RESERVE has been removed and now we use CONFIG_MTD_UBI_BEB_LIMIT instead. Signed-off-by: Shmulik Ladkani <shmulik.ladkani@gmail.com> Signed-off-by: Artem Bityutskiy <artem.bityutskiy@linux.intel.com>
* UBI: kill CONFIG_MTD_UBI_BEB_RESERVEShmulik Ladkani2012-09-042-19/+0
| | | | | | | | | | CONFIG_MTD_UBI_BEB_RESERVE and MIN_RESEVED_PEBS are no longer used, since the amount of reserved eraseblocks for bad PEB handling is now derived from 'ubi->bad_peb_limit' (ubi's maximum expected bad eraseblocks). Signed-off-by: Shmulik Ladkani <shmulik.ladkani@gmail.com> Signed-off-by: Artem Bityutskiy <Artem.Bityutskiy@linux.intel.com>
* UBI: limit amount of reserved eraseblocks for bad PEB handlingShmulik Ladkani2012-09-042-21/+41
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The existing mechanism of reserving PEBs for bad PEB handling has two flaws: - It is calculated as a percentage of good PEBs instead of total PEBs. - There's no limit on the amount of PEBs UBI reserves for future bad eraseblock handling. This patch changes the mechanism to overcome these flaws. The desired level of PEBs reserved for bad PEB handling (beb_rsvd_level) is set to the maximum expected bad eraseblocks (bad_peb_limit) minus the existing number of bad eraseblocks (bad_peb_count). The actual amount of PEBs reserved for bad PEB handling is usually set to the desired level (but in some circumstances may be lower than the desired level, e.g. when attaching to a device that has too few available PEBs to satisfy the desired level). In the case where the device has too many bad PEBs (above the expected limit), then the desired level, and the actual amount of PEBs reserved are set to zero. No PEBs will be set aside for future bad eraseblock handling - even if some PEBs are made available (e.g. by shrinking a volume). If another PEB goes bad, and there are available PEBs, then the eraseblock will be marked bad (consuming one available PEB). But if there are no available PEBs, ubi will go into readonly mode. Signed-off-by: Shmulik Ladkani <shmulik.ladkani@gmail.com>
* UBI: introduce new bad PEB limitShmulik Ladkani2012-09-043-8/+32
| | | | | | | | | | | | | | Introduce 'ubi->bad_peb_limit', which specifies an upper limit of PEBs UBI expects to go bad. Currently, it is initialized to a fixed percentage of total PEBs in the UBI device (configurable via CONFIG_MTD_UBI_BEB_LIMIT). The 'bad_peb_limit' is intended to be used for calculating the amount of PEBs UBI needs to reserve for bad eraseblock handling. Artem: minor amendments. Signed-off-by: Shmulik Ladkani <shmulik.ladkani@gmail.com> Signed-off-by: Artem Bityutskiy <Artem.Bityutskiy@linux.intel.com>
* arm: sam9_l9260_defconfig: prepare to UBI config changeShmulik Ladkani2012-09-041-0/+1
| | | | | | | | | | We are going to kill the CONFIG_MTD_UBI_BEB_RESERVE configuration option soon and use the CONFIG_MTD_UBI_BEB_LIMIT instead. In order to do this smoothly, we now introduce the new configuration option to sam9_l9260_defconfig, and will kill the old one after the corresponding UBI changes are done. Signed-off-by: Shmulik Ladkani <shmulik.ladkani@gmail.com> Signed-off-by: Artem Bityutskiy <artem.bityutskiy@linux.intel.com>
* UBI: print PID in debug messagesArtem Bityutskiy2012-09-041-1/+2
| | | | Signed-off-by: Artem Bityutskiy <artem.bityutskiy@linux.intel.com>
* UBI: print image sequence number as unsigned integerArtem Bityutskiy2012-09-041-1/+1
| | | | Signed-off-by: Artem Bityutskiy <artem.bityutskiy@linux.intel.com>
* Linux 3.6-rc4v3.6-rc4Linus Torvalds2012-09-011-1/+1
|
* time: Move ktime_t overflow checking into timespec_valid_strictJohn Stultz2012-09-012-5/+12
| | | | | | | | | | | | | | | | | | | | | | | Andreas Bombe reported that the added ktime_t overflow checking added to timespec_valid in commit 4e8b14526ca7 ("time: Improve sanity checking of timekeeping inputs") was causing problems with X.org because it caused timeouts larger then KTIME_T to be invalid. Previously, these large timeouts would be clamped to KTIME_MAX and would never expire, which is valid. This patch splits the ktime_t overflow checking into a new timespec_valid_strict function, and converts the timekeeping codes internal checking to use this more strict function. Reported-and-tested-by: Andreas Bombe <aeb@debian.org> Cc: Zhouping Liu <zliu@redhat.com> Cc: Ingo Molnar <mingo@kernel.org> Cc: Prarit Bhargava <prarit@redhat.com> Cc: Thomas Gleixner <tglx@linutronix.de> Cc: stable@vger.kernel.org Signed-off-by: John Stultz <john.stultz@linaro.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
* Merge git://git.kernel.org/pub/scm/virt/kvm/kvmLinus Torvalds2012-08-312-3/+7
|\ | | | | | | | | | | | | | | Pull KVM bugfixes from Marcelo Tosatti. * git://git.kernel.org/pub/scm/virt/kvm/kvm: KVM: x86: fix KVM_GET_MSR for PV EOI kvm: Fix nonsense handling of compat ioctl
| * KVM: x86: fix KVM_GET_MSR for PV EOIMichael S. Tsirkin2012-08-271-0/+3
| | | | | | | | | | | | | | | | KVM_GET_MSR was missing support for PV EOI, which is needed for migration. Signed-off-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Marcelo Tosatti <mtosatti@redhat.com>
| * kvm: Fix nonsense handling of compat ioctlAlan Cox2012-08-261-3/+4
| | | | | | | | | | | | | | | | | | | | | | KVM_SET_SIGNAL_MASK passed a NULL argument leaves the on stack signal sets uninitialized. It then passes them through to kvm_vcpu_ioctl_set_sigmask. We should be passing a NULL in this case not translated garbage. Signed-off-by: Alan Cox <alan@linux.intel.com> Signed-off-by: Marcelo Tosatti <mtosatti@redhat.com>
* | Merge tag 'parisc-fixes' of ↵Linus Torvalds2012-08-313-7/+7
|\ \ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | git://git.kernel.org/pub/scm/linux/kernel/git/jejb/parisc-2.6 Pull PARISC fixes from James Bottomley: "This is a set of two bug fixes. One is the ATOMIC problem which is now causing a compile failure in certain situations. The other is mishandling of PER_LINUX32 which may also cause user visible effects. Signed-off-by: James Bottomley <JBottomley@Parallels.com>" * tag 'parisc-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/jejb/parisc-2.6: [PARISC] fix personality flag check in copy_thread() [PARISC] Redefine ATOMIC_INIT and ATOMIC64_INIT to drop the casts
| * | [PARISC] fix personality flag check in copy_thread()Jiri Kosina2012-08-032-5/+5
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Directly comparing task_struct->personality against PER_* is not fully correct, as it doesn't take flags potentially stored in top three bytes into account. Analogically, directly forcefully setting personality to PER_LINUX32 or PER_LINUX discards any flags stored in the top three bytes. Signed-off-by: Jiri Kosina <jkosina@suse.cz> Signed-off-by: James Bottomley <JBottomley@Parallels.com>
| * | [PARISC] Redefine ATOMIC_INIT and ATOMIC64_INIT to drop the castsMel Gorman2012-07-251-2/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The following build error occured during a parisc build with swap-over-NFS patches applied. net/core/sock.c:274:36: error: initializer element is not constant net/core/sock.c:274:36: error: (near initialization for 'memalloc_socks') net/core/sock.c:274:36: error: initializer element is not constant Dave Anglin says: > Here is the line in sock.i: > > struct static_key memalloc_socks = ((struct static_key) { .enabled = > ((atomic_t) { (0) }) }); The above line contains two compound literals. It also uses a designated initializer to initialize the field enabled. A compound literal is not a constant expression. The location of the above statement isn't fully clear, but if a compound literal occurs outside the body of a function, the initializer list must consist of constant expressions. Reported-by: Fengguang Wu <fengguang.wu@intel.com> Signed-off-by: Mel Gorman <mgorman@suse.de> Cc: <stable@vger.kernel.org> Signed-off-by: James Bottomley <JBottomley@Parallels.com>
* | | Merge branch 'for-linus' of ↵Linus Torvalds2012-08-315-9/+7
|\ \ \ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | git://git.kernel.org/pub/scm/linux/kernel/git/s390/linux Pull s390 fixes from Martin Schwidefsky: "A couple of s390 bug fixes for 3.5-rc4" * 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/s390/linux: s390/32: Don't clobber personality flags on exec s390/smp: add missing smp_store_status() for !SMP s390/dasd: fix ioctl return value s390: Always use "long" for ssize_t to match size_t
| * | | s390/32: Don't clobber personality flags on execHeiko Carstens2012-08-301-1/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | In native 32 bit mode the personality flags were not correctly inherited. This is the s390 version of 59e4c3a2 "powerpc/32: Don't clobber personality flags on exec". Reported-by: Mike Frysinger <vapier@gentoo.org> Signed-off-by: Heiko Carstens <heiko.carstens@de.ibm.com> Signed-off-by: Martin Schwidefsky <schwidefsky@de.ibm.com>
| * | | s390/smp: add missing smp_store_status() for !SMPHeiko Carstens2012-08-281-0/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Fix this compile error: arch/s390/kernel/machine_kexec.c: In function ‘setup_regs’: arch/s390/kernel/machine_kexec.c:63:3: error: implicit declaration of function ‘smp_store_status’ [-Werror=implicit-function-declaration] Signed-off-by: Heiko Carstens <heiko.carstens@de.ibm.com> Signed-off-by: Martin Schwidefsky <schwidefsky@de.ibm.com>
| * | | s390/dasd: fix ioctl return valueHeiko Carstens2012-08-282-6/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | For unimplemented ioctls the dasd driver should return -ENOTTY. Reported-by: Wanlong Gao <gaowanlong@cn.fujitsu.com> Acked-by: Stefan Weinhuber <wein@de.ibm.com> Signed-off-by: Heiko Carstens <heiko.carstens@de.ibm.com> Signed-off-by: Martin Schwidefsky <schwidefsky@de.ibm.com>
| * | | s390: Always use "long" for ssize_t to match size_tGeert Uytterhoeven2012-08-211-2/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | On s390x-linux-gcc, __SIZE_TYPE__ expands to "long unsigned int" for both 32-bit s390 and 64-bit s390x, as gcc-4.6.3-nolibc/s390x-linux/lib/gcc/s390x-linux/4.6.3/plugin/include/config/s390/linux.h has #define SIZE_TYPE (TARGET_64BIT ? "long unsigned int" : "long unsigned int") To match this, __kernel_size_t is always set to "long unsigned int". But while __kernel_ssize_t is "long" on 64-bit s390x, it is "int" on 32-bit s390, causing compiler warnings like: fs/quota/quota_tree.c:372:4: warning: format '%zd' expects argument of type 'signed size_t', but argument 4 has type 'ssize_t' [-Wformat] To fix this, __kernel_ssize_t should be "long", irrespective of word size. Signed-off-by: Geert Uytterhoeven <geert@linux-m68k.org> Signed-off-by: Heiko Carstens <heiko.carstens@de.ibm.com> Signed-off-by: Martin Schwidefsky <schwidefsky@de.ibm.com>
* | | | Merge branch 'drm-fixes' of git://people.freedesktop.org/~airlied/linuxLinus Torvalds2012-08-3018-126/+174
|\ \ \ \ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Pull drm fixes from Dave Airlie: "A bunch of scattered fixes ati/intel/nouveau, couple of core ones, nothing too shocking or different." * 'drm-fixes' of git://people.freedesktop.org/~airlied/linux: drm: Add EDID_QUIRK_FORCE_REDUCED_BLANKING for ASUS VW222S gma500: Consider CRTC initially active. drm/radeon: fix dig encoder selection on DCE61 drm/radeon: fix double free in radeon_gpu_reset drm/radeon: force dma32 to fix regression rs4xx,rs6xx,rs740 drm/radeon: rework panel mode setup drm/radeon/atom: powergating fixes for DCE6 drm/radeon/atom: rework DIG modesetting on DCE3+ drm/radeon: don't disable plls that are in use by other crtcs drm/radeon: add proper checking of RESOLVE_BOX command for r600-r700 drm/radeon: initialize tracked CS state drm/radeon: fix reading CB_COLORn_MASK from the CS drm/nvc0/copy: check PUNITS to determine which copy engines are disabled i915: Quirk no_lvds on Gigabyte GA-D525TUD ITX motherboard drm/i915: Use the correct size of the GTT for placing the per-process entries drm: Check for invalid cursor flags drm: Initialize object type when using DRM_MODE() macro drm/i915: fix color order for BGR formats on IVB drm/i915: fix wrong order of parameters in port checking functions
| * | | | drm: Add EDID_QUIRK_FORCE_REDUCED_BLANKING for ASUS VW222SPaul Menzel2012-08-301-0/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Connecting an ASUS VW222S [1] over VGA a garbled screen is shown with vertical stripes in the top half. In commit bc42aabc [2] commit bc42aabc6a01b92b0f961d65671564e0e1cd7592 Author: Adam Jackson <ajax@redhat.com> Date: Wed May 23 16:26:54 2012 -0400 drm/edid/quirks: ViewSonic VA2026w Adam Jackson added the quirk `EDID_QUIRK_FORCE_REDUCED_BLANKING` which is also needed for this ASUS monitor. All log files and output from `xrandr` is included in the referenced Bugzilla report #17629. Please note that this monitor only has a VGA (D-Sub) connector [1]. [1] http://www.asus.com/Display/LCD_Monitors/VW222S/ [2] http://git.kernel.org/?p=linux/kernel/git/torvalds/linux.git;a=commit;h=bc42aabc6a01b92b0f961d65671564e0e1cd7592 Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=17629 Signed-off-by: Paul Menzel <paulepanter@users.sourceforge.net> Cc: <dri-devel@lists.freedesktop.org> Cc: Adam Jackson <ajax@redhat.com> Cc: Ian Pilcher <arequipeno@gmail.com> Cc: <stable@vger.kernel.org> Signed-off-by: Dave Airlie <airlied@redhat.com>
| * | | | Merge branch 'drm-fixes-3.6' of git://people.freedesktop.org/~agd5f/linux ↵Dave Airlie2012-08-308-111/+141
| |\ \ \ \ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | into drm-fixes Alex writes: Highlights: - fix a gart regression on older IGP chips - more MSAA fixes - fix a double free in gpu reset code - modesetting fixes - trinity dig encoder fix. * 'drm-fixes-3.6' of git://people.freedesktop.org/~agd5f/linux: drm/radeon: fix dig encoder selection on DCE61 drm/radeon: fix double free in radeon_gpu_reset drm/radeon: force dma32 to fix regression rs4xx,rs6xx,rs740 drm/radeon: rework panel mode setup drm/radeon/atom: powergating fixes for DCE6 drm/radeon/atom: rework DIG modesetting on DCE3+ drm/radeon: don't disable plls that are in use by other crtcs drm/radeon: add proper checking of RESOLVE_BOX command for r600-r700 drm/radeon: initialize tracked CS state drm/radeon: fix reading CB_COLORn_MASK from the CS
| | * | | | drm/radeon: fix dig encoder selection on DCE61Alex Deucher2012-08-291-5/+26
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Was using the DCE41 code which was wrong. Fixes blank displays on a number of Trinity systems. Signed-off-by: Alex Deucher <alexander.deucher@amd.com> Cc: stable@vger.kernel.org
| | * | | | drm/radeon: fix double free in radeon_gpu_resetChristian König2012-08-291-0/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | radeon_ring_restore is freeing the memory for the saved ring data. We need to remember that, otherwise we try to restore the ring data again on the next try. Additional to that it shouldn't try the reset infinitely if we have saved ring data. Signed-off-by: Christian König <deathsimple@vodafone.de> Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
| | * | | | drm/radeon: force dma32 to fix regression rs4xx,rs6xx,rs740Jerome Glisse2012-08-291-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | It seems some of those IGP dislike non dma32 page despite what documentation says. Fix regression since we allowed non dma32 pages. It seems it only affect some revision of those IGP chips as we don't know which one just force dma32 for all of them. https://bugzilla.redhat.com/show_bug.cgi?id=785375 Signed-off-by: Jerome Glisse <jglisse@redhat.com> Cc: <stable@vger.kernel.org> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
| | * | | | drm/radeon: rework panel mode setupAlex Deucher2012-08-291-17/+12
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Adjust the panel mode setup to match the behavior of the vbios. Rather than checking for specific bridge chip ids, just check the eDP configuration register. This saves extra aux transactions and works across DP bridge chips without requiring additional per chip id checking. Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
| | * | | | drm/radeon/atom: powergating fixes for DCE6Alex Deucher2012-08-291-20/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Power gating is per crtc pair, but the powergating registers should be called individually. The hw handles power up/down properly. The pair is powered up if either crtc in the pair is powered up and the pair is not powered down until both crtcs in the pair are powered down. This simplifies programming and should save additional power as the previous code never actually power gated the crtc pair. Signed-off-by: Alex Deucher <alexander.deucher@amd.com> Cc: stable@vger.kernel.org
| | * | | | drm/radeon/atom: rework DIG modesetting on DCE3+Alex Deucher2012-08-291-62/+47
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The ordering is important and the current drm code wasn't cutting it for modern DIG encoders. We need to have information about crtc before setting up the encoders so I've shifted the ordering a bit. Probably we'll need a full rework akin to danvet's recent intel patchs. This patch fixes numerous issues with DP bridge chips and makes link training much more reliable. Signed-off-by: Alex Deucher <alexander.deucher@amd.com> Cc: stable@vger.kernel.org
| | * | | | drm/radeon: don't disable plls that are in use by other crtcsAlex Deucher2012-08-291-0/+14
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Some plls are shared for DP. Signed-off-by: Alex Deucher <alexander.deucher@amd.com> Cc: stable@vger.kernel.org Reviewed-by: Michel Dänzer <michel.daenzer@amd.com>
| | * | | | drm/radeon: add proper checking of RESOLVE_BOX command for r600-r700Marek Olšák2012-08-294-4/+27
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Checking of the second colorbuffer was skipped on r700, because CB_TARGET_MASK was 0xf. With r600, CB_TARGET_MASK is changed to 0xff, so we must set the number of samples of the second colorbuffer to 1 in order to pass the CS checker. The DRM version is bumped, because RESOLVE_BOX is always rejected without this fix on r600. Signed-off-by: Marek Olšák <maraeo@gmail.com> Reviewed-by: Jerome Glisse <jglisse@redhat.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
| | * | | | drm/radeon: initialize tracked CS stateMarek Olšák2012-08-291-1/+8
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This should help catch uninitialized registers and reject commands because of that. Signed-off-by: Marek Olšák <maraeo@gmail.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
| | * | | | drm/radeon: fix reading CB_COLORn_MASK from the CSMarek Olšák2012-08-291-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Signed-off-by: Marek Olšák <maraeo@gmail.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
| * | | | | gma500: Consider CRTC initially active.Forest Bond2012-08-301-0/+3
| |/ / / / | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | [this one ideally should make 3.6 - it fixes the very annoying mode setting bug] This causes the pipe to be forced off prior to initial mode set, which roughly mirrors the behavior of the i915 driver. It fixes initial mode setting on my Intel DN2800MT (Cedarview) board. Without it, mode setting triggers an out-of-range error from the monitor for most modes, but only on initial configuration (i.e. they can be configured successfully from userspace after that). Signed-off-by: Forest Bond <forest.bond@rapidrollout.com> Signed-off-by: Alan Cox <alan@linux.intel.com> Cc: stable <stable@vger.kernel.org> Signed-off-by: Dave Airlie <airlied@redhat.com>
| * | | | Merge branch 'drm-intel-fixes' of ↵Dave Airlie2012-08-294-9/+17
| |\ \ \ \ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | git://people.freedesktop.org/~danvet/drm-intel into drm-fixes Daniel writes: "Just a few smaller things: - Fix up a pipe vs. plane confusion from a refactoring, fixes a regression from 3.1 (Anhua Xu). - Fix ivb sprite pixel formats (Vijay). - Fixup ppgtt pde placement for machines where the Bios artifically limits the availbale gtt space in the name of ... product differentiation (Chris). This fixes an oops. - Yet another no_lvds quirk entry." * 'drm-intel-fixes' of git://people.freedesktop.org/~danvet/drm-intel: i915: Quirk no_lvds on Gigabyte GA-D525TUD ITX motherboard drm/i915: Use the correct size of the GTT for placing the per-process entries drm/i915: fix color order for BGR formats on IVB drm/i915: fix wrong order of parameters in port checking functions
| | * | | | i915: Quirk no_lvds on Gigabyte GA-D525TUD ITX motherboardCalvin Walton2012-08-241-0/+8
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This board is incorrectly detected as having an LVDS connector, resulting in the VGA output (the only available output on the board) showing the console only in the top-left 1024x768 pixels, and an extra LVDS connector appearing in X. It's a desktop Mini-ITX board using an Atom D525 CPU with an NM10 chipset. I've had this board for about a year, but this is the first time I noticed the issue because I've been running it headless for most of its life. Signed-off-by: Calvin Walton <calvin.walton@kepstin.ca>
| | * | | | drm/i915: Use the correct size of the GTT for placing the per-process entriesChris Wilson2012-08-241-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The current layout is to place the per-process tables at the end of the GTT. However, this is currently using a hardcoded maximum size for the GTT and not taking in account limitations imposed by the BIOS. Use the value for the total number of entries allocated in the table as provided by the configuration registers. Reported-by: Matthew Garrett <mjg@redhat.com> Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Cc: Daniel Vetter <daniel.vetter@ffwll.ch> Cc: Ben Widawsky <ben@bwidawsk.net> Cc: Matthew Garret <mjg@redhat.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
| | * | | | drm/i915: fix color order for BGR formats on IVBVijay Purushothaman2012-08-231-2/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This is already fixed for ILK and SNB in the below commit but somehow IVB is missed. commit ab2f9df10dd955f1fc0a8650e377588c98f1c029 Author: Jesse Barnes <jbarnes@virtuousgeek.org> Date: Mon Feb 27 12:40:10 2012 -0800 drm/i915: fix color order for BGR formats on SNB Had the wrong bits and field definitions. Signed-off-by: Vijay Purushothaman <vijay.a.purushothaman@intel.com> Reviewed-by: Antti Koskipää <antti.koskipaa@linux.intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
OpenPOWER on IntegriCloud