- 05 11月, 2011 1 次提交
-
-
由 Matthew Wilcox 提交于
When Xen is enabled, using BIOVEC_PHYS_MERGEABLE in a module causes xen_biovec_phys_mergeable to be referenced, so it needs to be exported. Acked-by: NJens Axboe <axboe@kernel.dk> Signed-off-by: NMatthew Wilcox <matthew.r.wilcox@intel.com>
-
- 24 10月, 2011 1 次提交
-
-
由 Alasdair G Kergon 提交于
Fix memory leak introduced by commit a6e50b40 (dm snapshot: skip reading origin when overwriting complete chunk). When allocating a set of jobs from kc->job_pool, job->master_job must be set (to point to itself) so that the mempool item gets freed when the master_job completes. master_job was introduced by commit c6ea41fb (dm kcopyd: preallocate sub jobs to avoid deadlock) Reported-by: NMichael Leun <ml@newton.leun.net> Cc: Mikulas Patocka <mpatocka@redhat.com> Signed-off-by: NAlasdair G Kergon <agk@redhat.com>
-
- 20 10月, 2011 3 次提交
-
-
由 Jean Delvare 提交于
Since 8-bit temperature values are now handled in 16-bit struct members, values have to be cast to s8 for negative temperatures to be properly handled. This is broken since kernel version 2.6.39 (commit bce26c58.) Signed-off-by: NJean Delvare <khali@linux-fr.org> Cc: Guenter Roeck <guenter.roeck@ericsson.com> Cc: stable@kernel.org # 2.6.39+ Signed-off-by: NGuenter Roeck <guenter.roeck@ericsson.com>
-
由 hayeswang 提交于
Correct the wrong parameter for setting EEE for RTL8111E-VL. Signed-off-by: NHayes Wang <hayeswang@realtek.com> Signed-off-by: NDavid S. Miller <davem@davemloft.net>
-
由 françois romieu 提交于
Due to commit 92fc43b4 ("r8169: modify the flow of the hw reset."), rtl8169_hw_reset stomps during driver shutdown on RxConfig bits which are needed for WOL on some versions of the hardware. As these bits were formerly set from the r81{0x, 68}_pll_power_down methods, factor them out for use in the driver shutdown (rtl_shutdown) handler. I favored __rtl8169_get_wol() -hardware state indication- over RTL_FEATURE_WOL as the latter has become a good candidate for removal. Signed-off-by: NFrancois Romieu <romieu@fr.zoreil.com> Cc: Hayes <hayeswang@realtek.com> Tested-by: NMarc Ballarin <ballarin.marc@gmx.de> Signed-off-by: NDavid S. Miller <davem@davemloft.net>
-
- 19 10月, 2011 11 次提交
-
-
由 Antonio Ospite 提交于
The change in 8280b662 does not cover the case when v4l2_dev is already NULL, fix that. With a Kinect sensor, seen as an USB camera using GSPCA in this context, a NULL pointer dereference BUG can be triggered by just unplugging the device after the camera driver has been loaded. Signed-off-by: NAntonio Ospite <ospite@studenti.unina.it> Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>
-
由 Allen Kay 提交于
If target_level == 0, current code breaks out of the while-loop if SUPERPAGE bit is set. We should also break out if PTE is not present. If we don't do this, KVM calls to iommu_iova_to_phys() will cause pfn_to_dma_pte() to create mapping for 4KiB pages. Signed-off-by: NAllen Kay <allen.m.kay@intel.com> Signed-off-by: NDavid Woodhouse <David.Woodhouse@intel.com>
-
由 Allen Kay 提交于
set dmar->iommu_superpage field to the smallest common denominator of super page sizes supported by all active VT-d engines. Initialize this field in intel_iommu_domain_init() API so intel_iommu_map() API will be able to use iommu_superpage field to determine the appropriate super page size to use. Signed-off-by: NAllen Kay <allen.m.kay@intel.com> Signed-off-by: NDavid Woodhouse <David.Woodhouse@intel.com>
-
由 Allen Kay 提交于
iommu_unmap() API expects IOMMU drivers to return the actual page order of the address being unmapped. Previous code was just returning page order passed in from the caller. This patch fixes this problem. Signed-off-by: NAllen Kay <allen.m.kay@intel.com> Signed-off-by: NDavid Woodhouse <David.Woodhouse@intel.com>
-
由 Alex Deucher 提交于
FB scratch indices are dword indices, but we were treating them as byte indices. As such, we were getting the wrong FB scratch data for non-0 indices. Fix the indices and guard the indexing against indices larger than the scratch allocation. Fixes memory corruption on some boards if data was written past the end of the FB scratch array. Signed-off-by: NAlex Deucher <alexander.deucher@amd.com> Reported-by: NDave Airlie <airlied@redhat.com> Tested-by: NDave Airlie <airlied@redhat.com> Cc: stable@kernel.org Signed-off-by: NDave Airlie <airlied@redhat.com>
-
由 Eric Dumazet 提交于
e1000e uses paged frags, so any layer incorrectly pulling bytes from skb can trigger a BUG in skb_pull() [951.142737] [<ffffffff813d2f36>] skb_pull+0x15/0x17 [951.142737] [<ffffffffa0286824>] pptp_rcv_core+0x126/0x19a [pptp] [951.152725] [<ffffffff813d17c4>] sk_receive_skb+0x69/0x105 [951.163558] [<ffffffffa0286993>] pptp_rcv+0xc8/0xdc [pptp] [951.165092] [<ffffffffa02800a3>] gre_rcv+0x62/0x75 [gre] [951.165092] [<ffffffff81410784>] ip_local_deliver_finish+0x150/0x1c1 [951.177599] [<ffffffff81410634>] ? ip_local_deliver_finish+0x0/0x1c1 [951.177599] [<ffffffff81410846>] NF_HOOK.clone.7+0x51/0x58 [951.177599] [<ffffffff81410996>] ip_local_deliver+0x51/0x55 [951.177599] [<ffffffff814105b9>] ip_rcv_finish+0x31a/0x33e [951.177599] [<ffffffff8141029f>] ? ip_rcv_finish+0x0/0x33e [951.204898] [<ffffffff81410846>] NF_HOOK.clone.7+0x51/0x58 [951.214651] [<ffffffff81410bb5>] ip_rcv+0x21b/0x246 pptp_rcv_core() is a nice example of a function assuming everything it needs is available in skb head. Reported-by: NBradley Peterson <despite@gmail.com> Signed-off-by: NEric Dumazet <eric.dumazet@gmail.com> Signed-off-by: NDavid S. Miller <davem@davemloft.net>
-
由 Eric Dumazet 提交于
In case we cant transmit skb, we must free it Signed-off-by: NEric Dumazet <eric.dumazet@gmail.com> CC: Dmitry Kozlov <xeb@mail.ru> Signed-off-by: NDavid S. Miller <davem@davemloft.net>
-
由 Mitsuo Hayasaka 提交于
The bond->recv_probe is called in bond_handle_frame() when a packet is received, but bond_close() sets it to NULL. So, a panic occurs when both functions work in parallel. Why this happen: After null pointer check of bond->recv_probe, an sk_buff is duplicated and bond->recv_probe is called in bond_handle_frame. So, a panic occurs when bond_close() is called between the check and call of bond->recv_probe. Patch: This patch uses a local function pointer of bond->recv_probe in bond_handle_frame(). So, it can avoid the null pointer dereference. Signed-off-by: NMitsuo Hayasaka <mitsuo.hayasaka.hu@hitachi.com> Cc: Jay Vosburgh <fubar@us.ibm.com> Cc: Andy Gospodarek <andy@greyhouse.net> Cc: Eric Dumazet <eric.dumazet@gmail.com> Cc: WANG Cong <xiyou.wangcong@gmail.com> Acked-by: NEric Dumazet <eric.dumazet@gmail.com> Signed-off-by: NDavid S. Miller <davem@davemloft.net>
-
由 Phil Edworthy 提交于
LAN89218 is register compatible with LAN911x. Signed-off-by: NPhil Edworthy <phil.edworthy@renesas.com> Signed-off-by: NDavid S. Miller <davem@davemloft.net>
-
由 Jiri Pirko 提交于
USE_PHYLIB flag in tg3_remove_one() is being checked incorrectly. This results tg3_phy_fini->phy_disconnect is never called and when tg3 module is removed. In my case this resulted in panics in phy_state_machine calling function phydev->adjust_link. So correct this check. Signed-off-by: NJiri Pirko <jpirko@redhat.com> Acked-by: NMatt Carlson <mcarlson@broadcom.com> Signed-off-by: NDavid S. Miller <davem@davemloft.net>
-
由 Gao feng 提交于
There is no check if netconsole is enabled current. so when exec echo 1 > enabled; the reference of net_device will increment always. Signed-off-by: NGao feng <gaofeng@cn.fujitsu.com> Acked-by: NFlavio Leitner <fbl@redhat.com> Signed-off-by: NDavid S. Miller <davem@davemloft.net>
-
- 18 10月, 2011 4 次提交
-
-
由 Alex Deucher 提交于
Settings in this table reflect the physical panel/connector rather than the internal dig encoding. v2: fix typo for DRM_MODE_CONNECTOR_VGA case. Signed-off-by: NAlex Deucher <alexander.deucher@amd.com> Signed-off-by: NDave Airlie <airlied@redhat.com>
-
由 Alex Deucher 提交于
It's handled via external clock. It should already be protected by the external ss flag, but add an explicit check just in case. Signed-off-by: NAlex Deucher <alexander.deucher@amd.com> Signed-off-by: NDave Airlie <airlied@redhat.com>
-
由 Alex Deucher 提交于
llano has fully routeable dig encoders similar to DCE3.2 while ontario has a hardcoded mapping similar to DCE4.0. Signed-off-by: NAlex Deucher <alexander.deucher@amd.com> Signed-off-by: NDave Airlie <airlied@redhat.com>
-
由 Thomas Hellstrom 提交于
Pointed out by Michel Daenzer. Signed-off-by: NThomas Hellstrom <thellstrom@vmware.com> Signed-off-by: NDave Airlie <airlied@redhat.com>
-
- 15 10月, 2011 2 次提交
-
-
由 David Woodhouse 提交于
We really don't want this to work in the general case; device drivers *shouldn't* care whether they are behind an IOMMU or not. But the integrated graphics is a special case, because the IOMMU and the GTT are all kind of smashed into one and generally horrifically buggy, so it's reasonable for the graphics driver to want to know when the IOMMU is active for the graphics hardware. Signed-off-by: NDavid Woodhouse <David.Woodhouse@intel.com>
-
由 David Woodhouse 提交于
To work around a hardware issue, we have to submit IOTLB flushes while the graphics engine is idle. The graphics driver will (we hope) go to great lengths to ensure that it gets that right on the affected chipset(s)... so let's not screw it over by deferring the unmap and doing it later. That wouldn't be very helpful. Signed-off-by: NDavid Woodhouse <David.Woodhouse@intel.com>
-
- 14 10月, 2011 3 次提交
-
-
由 Jean Delvare 提交于
The w83627ehf driver is improperly reporting thermal diode sensors as type 2, instead of 3. This caused "sensors" and possibly other monitoring tools to report these sensors as "transistor" instead of "thermal diode". Furthermore, diode subtype selection (CPU vs. external) is only supported by the original W83627EHF/EHG. All later models only support CPU diode type, and some (NCT6776F) don't even have the register in question so we should avoid reading from it. Signed-off-by: NJean Delvare <khali@linux-fr.org> Cc: stable@kernel.org Signed-off-by: NGuenter Roeck <guenter.roeck@ericsson.com>
-
由 Hartmut Knaack 提交于
gpio_base was set to 0 if no system platform data or open firmware platform data was provided. This led to conflicts, if any other gpiochip with a gpiobase of 0 was instantiated already. Setting it to -1 will automatically use the first one available. Signed-off-by: NHartmut Knaack <knaack.h@gmx.de> Signed-off-by: NGrant Likely <grant.likely@secretlab.ca>
-
由 Janusz Krzysztofik 提交于
With commit f64ad1a0, "gpio/omap: cleanup _set_gpio_wakeup(), remove ifdefs", access to build time conditionally omitted 'suspend_wakeup' member of the 'gpio_bank' structure has been placed unconditionally in function _set_gpio_wakeup(), which is always built. This resulted in the driver compilation broken for certain OMAP1, i.e., non-OMAP16xx, configurations. Really required or not in previously excluded cases, define this structure member unconditionally as a fix. Tested with a custom OMAP1510 only configuration. Signed-off-by: NJanusz Krzysztofik <jkrzyszt@tis.icnet.pl> Acked-by: NKevin Hilman <khilman@ti.com> Tested-by: NAaro Koskinen <aaro.koskinen@iki.fi> Signed-off-by: NGrant Likely <grant.likely@secretlab.ca>
-
- 13 10月, 2011 1 次提交
-
-
由 Johann Felix Soden 提交于
Fix file references in drivers/ide/ There are a lot of file references to now moved or deleted files in the whole tree, especially in documentation and Kconfig files. This patch fixes the references in drivers/ide/. Signed-off-by: NJohann Felix Soden <johfel@users.sourceforge.net> Signed-off-by: NRandy Dunlap <rdunlap@xenotime.net> Acked-by: NDavid S. Miller <davem@davemloft.net> Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
-
- 11 10月, 2011 4 次提交
-
-
由 Roland Dreier 提交于
When unbinding a device so that I could pass it through to a KVM VM, I got the lockdep report below. It looks like a legitimate lock ordering problem: - domain_context_mapping_one() takes iommu->lock and calls iommu_support_dev_iotlb(), which takes device_domain_lock (inside iommu->lock). - domain_remove_one_dev_info() starts by taking device_domain_lock then takes iommu->lock inside it (near the end of the function). So this is the classic AB-BA deadlock. It looks like a safe fix is to simply release device_domain_lock a bit earlier, since as far as I can tell, it doesn't protect any of the stuff accessed at the end of domain_remove_one_dev_info() anyway. BTW, the use of device_domain_lock looks a bit unsafe to me... it's at least not obvious to me why we aren't vulnerable to the race below: iommu_support_dev_iotlb() domain_remove_dev_info() lock device_domain_lock find info unlock device_domain_lock lock device_domain_lock find same info unlock device_domain_lock free_devinfo_mem(info) do stuff with info after it's free However I don't understand the locking here well enough to know if this is a real problem, let alone what the best fix is. Anyway here's the full lockdep output that prompted all of this: ======================================================= [ INFO: possible circular locking dependency detected ] 2.6.39.1+ #1 ------------------------------------------------------- bash/13954 is trying to acquire lock: (&(&iommu->lock)->rlock){......}, at: [<ffffffff812f6421>] domain_remove_one_dev_info+0x121/0x230 but task is already holding lock: (device_domain_lock){-.-...}, at: [<ffffffff812f6508>] domain_remove_one_dev_info+0x208/0x230 which lock already depends on the new lock. the existing dependency chain (in reverse order) is: -> #1 (device_domain_lock){-.-...}: [<ffffffff8109ca9d>] lock_acquire+0x9d/0x130 [<ffffffff81571475>] _raw_spin_lock_irqsave+0x55/0xa0 [<ffffffff812f8350>] domain_context_mapping_one+0x600/0x750 [<ffffffff812f84df>] domain_context_mapping+0x3f/0x120 [<ffffffff812f9175>] iommu_prepare_identity_map+0x1c5/0x1e0 [<ffffffff81ccf1ca>] intel_iommu_init+0x88e/0xb5e [<ffffffff81cab204>] pci_iommu_init+0x16/0x41 [<ffffffff81002165>] do_one_initcall+0x45/0x190 [<ffffffff81ca3d3f>] kernel_init+0xe3/0x168 [<ffffffff8157ac24>] kernel_thread_helper+0x4/0x10 -> #0 (&(&iommu->lock)->rlock){......}: [<ffffffff8109bf3e>] __lock_acquire+0x195e/0x1e10 [<ffffffff8109ca9d>] lock_acquire+0x9d/0x130 [<ffffffff81571475>] _raw_spin_lock_irqsave+0x55/0xa0 [<ffffffff812f6421>] domain_remove_one_dev_info+0x121/0x230 [<ffffffff812f8b42>] device_notifier+0x72/0x90 [<ffffffff8157555c>] notifier_call_chain+0x8c/0xc0 [<ffffffff81089768>] __blocking_notifier_call_chain+0x78/0xb0 [<ffffffff810897b6>] blocking_notifier_call_chain+0x16/0x20 [<ffffffff81373a5c>] __device_release_driver+0xbc/0xe0 [<ffffffff81373ccf>] device_release_driver+0x2f/0x50 [<ffffffff81372ee3>] driver_unbind+0xa3/0xc0 [<ffffffff813724ac>] drv_attr_store+0x2c/0x30 [<ffffffff811e4506>] sysfs_write_file+0xe6/0x170 [<ffffffff8117569e>] vfs_write+0xce/0x190 [<ffffffff811759e4>] sys_write+0x54/0xa0 [<ffffffff81579a82>] system_call_fastpath+0x16/0x1b other info that might help us debug this: 6 locks held by bash/13954: #0: (&buffer->mutex){+.+.+.}, at: [<ffffffff811e4464>] sysfs_write_file+0x44/0x170 #1: (s_active#3){++++.+}, at: [<ffffffff811e44ed>] sysfs_write_file+0xcd/0x170 #2: (&__lockdep_no_validate__){+.+.+.}, at: [<ffffffff81372edb>] driver_unbind+0x9b/0xc0 #3: (&__lockdep_no_validate__){+.+.+.}, at: [<ffffffff81373cc7>] device_release_driver+0x27/0x50 #4: (&(&priv->bus_notifier)->rwsem){.+.+.+}, at: [<ffffffff8108974f>] __blocking_notifier_call_chain+0x5f/0xb0 #5: (device_domain_lock){-.-...}, at: [<ffffffff812f6508>] domain_remove_one_dev_info+0x208/0x230 stack backtrace: Pid: 13954, comm: bash Not tainted 2.6.39.1+ #1 Call Trace: [<ffffffff810993a7>] print_circular_bug+0xf7/0x100 [<ffffffff8109bf3e>] __lock_acquire+0x195e/0x1e10 [<ffffffff810972bd>] ? trace_hardirqs_off+0xd/0x10 [<ffffffff8109d57d>] ? trace_hardirqs_on_caller+0x13d/0x180 [<ffffffff8109ca9d>] lock_acquire+0x9d/0x130 [<ffffffff812f6421>] ? domain_remove_one_dev_info+0x121/0x230 [<ffffffff81571475>] _raw_spin_lock_irqsave+0x55/0xa0 [<ffffffff812f6421>] ? domain_remove_one_dev_info+0x121/0x230 [<ffffffff810972bd>] ? trace_hardirqs_off+0xd/0x10 [<ffffffff812f6421>] domain_remove_one_dev_info+0x121/0x230 [<ffffffff812f8b42>] device_notifier+0x72/0x90 [<ffffffff8157555c>] notifier_call_chain+0x8c/0xc0 [<ffffffff81089768>] __blocking_notifier_call_chain+0x78/0xb0 [<ffffffff810897b6>] blocking_notifier_call_chain+0x16/0x20 [<ffffffff81373a5c>] __device_release_driver+0xbc/0xe0 [<ffffffff81373ccf>] device_release_driver+0x2f/0x50 [<ffffffff81372ee3>] driver_unbind+0xa3/0xc0 [<ffffffff813724ac>] drv_attr_store+0x2c/0x30 [<ffffffff811e4506>] sysfs_write_file+0xe6/0x170 [<ffffffff8117569e>] vfs_write+0xce/0x190 [<ffffffff811759e4>] sys_write+0x54/0xa0 [<ffffffff81579a82>] system_call_fastpath+0x16/0x1b Signed-off-by: NRoland Dreier <roland@purestorage.com> Signed-off-by: NDavid Woodhouse <David.Woodhouse@intel.com>
-
由 Wolfgang Grandegger 提交于
Due to the 16 bit access to mscan registers there's too much data copied to the zero initialized CAN frame when having an odd number of bytes to copy. This patch ensures that only the requested bytes are copied by using an 8 bit access for the remaining byte. Reported-by: NAndre Naujoks <nautsch@gmail.com> Signed-off-by: NOliver Hartkopp <socketcan@hartkopp.net> Signed-off-by: NWolfgang Grandegger <wg@grandegger.com> Signed-off-by: NDavid S. Miller <davem@davemloft.net>
-
由 Dmitry Kravkov 提交于
There are some consolidations of NPAR configuration when FCoE and iSCSI L2 clients will get the same id, in this case FCoE ring will be non-functional. Signed-off-by: NDmitry Kravkov <dmitry@broadcom.com> Signed-off-by: NEilon Greenstein <eilong@broadcom.com> Signed-off-by: NDavid S. Miller <davem@davemloft.net>
-
The doorbell register was being unconditionally swapped. In x86, that meant it was being swapped to BE and written to the descriptor and to memory, depending on the case of blue frame support or writing to doorbell register. On PPC, this meant it was being swapped to LE and then swapped back to BE while writing to the register. But in the blue frame case, it was being written as LE to the descriptor. The fix is not to swap doorbell unconditionally, write it to the register as BE and convert it to BE when writing it to the descriptor. Signed-off-by: NThadeu Lima de Souza Cascardo <cascardo@linux.vnet.ibm.com> Reported-by: NRichard Hendrickson <richhend@us.ibm.com> Cc: Eli Cohen <eli@dev.mellanox.co.il> Cc: Yevgeny Petrilin <yevgenyp@mellanox.co.il> Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org> Signed-off-by: NDavid S. Miller <davem@davemloft.net>
-
- 06 10月, 2011 1 次提交
-
-
由 Alex Deucher 提交于
The encoders are supposedly fully routeable, but changing the mapping doesn't always seem to take. Using a hardcoded mapping is much more reliable. Fixes: https://bugs.freedesktop.org/show_bug.cgi?id=41366Signed-off-by: NAlex Deucher <alexander.deucher@amd.com> Tested-by: NSimon Farnsworth <simon.farnsworth@onelan.co.uk> Cc: stable@kernel.org Signed-off-by: NDave Airlie <airlied@redhat.com>
-
- 05 10月, 2011 9 次提交
-
-
由 Alex Deucher 提交于
The HPD pin is not reliable for detecting whether a monitor is connected or not. Skip HPD and just use DDC or load detection. Fixes phantom VGA connected bugs. [Michel: fixes phantom VGA bugs on his llano system.] Signed-off-by: NAlex Deucher <alexander.deucher@amd.com> Reviewed-by: NMichel Dänzer <michel.daenzer@amd.com> Tested-by: NMichel Dänzer <michel.daenzer@amd.com> Cc: stable@kernel.org Signed-off-by: NDave Airlie <airlied@redhat.com>
-
由 Alex Deucher 提交于
If there are error flags in the aux status, retry the transaction. This makes aux much more reliable, especially on llano systems. Signed-off-by: NAlex Deucher <alexander.deucher@amd.com> Reviewed-by: NMichel Dänzer <michel.daenzer@amd.com> Cc: stable@kernel.org Signed-off-by: NDave Airlie <airlied@redhat.com>
-
由 Jason Gerecke 提交于
This reverts commit 71c86ce5. The 21UX2 does have touchstrips, but they are in a somewhat- hidden location. Signed-off-by: NJason Gerecke <killertofu@gmail.com> Acked-by: NPing Cheng <pinglinux@gmail.com> Signed-off-by: NDmitry Torokhov <dtor@mail.ru>
-
由 David Ward 提交于
Packets should always be forwarded to the lowerdev using dev_forward_skb. vlan->forward is for packets being forwarded directly to another macvlan/ macvtap device (used for multicast in bridge mode). Reported-and-tested-by: NShlomo Pongratz <shlomop@mellanox.com> Signed-off-by: NDavid Ward <david.ward@ll.mit.edu> Signed-off-by: NDavid S. Miller <davem@davemloft.net>
-
由 Jon Mason 提交于
Add the ability to disable PCI-E MPS turning and using the BIOS configured MPS defaults. Due to the number of issues recently discovered on some x86 chipsets, make this the default behavior. Also, add the option for peer to peer DMA MPS configuration. Peer to peer DMA is outside the scope of this patch, but MPS configuration could prevent it from working by having the MPS on one root port different than the MPS on another. To work around this, simply make the system wide MPS the smallest possible value (128B). Signed-off-by: NJon Mason <mason@myri.com> Acked-by: NBenjamin Herrenschmidt <benh@kernel.crashing.org> Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
-
由 Alex Deucher 提交于
Most asics just use the hw default value which requires no explicit programming. For those that need a different value, the vbios will program it properly. As such, there's no need to program these registers explicitly in the driver. Changing MC_SHARED_CHREMAP requires a reload of all data in vram otherwise its contents will be scambled. Fixes: https://bugs.freedesktop.org/show_bug.cgi?id=40103 v2: drop now unused channel_remap functions. Signed-off-by: NAlex Deucher <alexander.deucher@amd.com> Reviewed-by: NMichel Dänzer <michel.daenzer@amd.com> Cc: stable@kernel.org Signed-off-by: NDave Airlie <airlied@redhat.com>
-
由 Tomoya MORINAGA 提交于
We found that adding load, Rx data sometimes drops.(with DMA transfer mode) The cause is that before starting Rx-DMA processing, Tx-DMA processing starts. This causes FIFO overrun occurs. This patch fixes the issue by modifying FIFO tx-threshold and DMA descriptor size like below. Current this patch Rx-descriptor 4Byte+12Byte*341 --> 12Byte*340-4Byte-12Byte Rx-threshold (Not modified) Tx-descriptor 4Byte+12Byte*341 --> 16Byte-12Byte*340 Rx-threshold 12Byte --> 2Byte Signed-off-by: NTomoya MORINAGA <tomoya-linux@dsn.okisemi.com> Signed-off-by: NGrant Likely <grant.likely@secretlab.ca>
-
由 Tomoya MORINAGA 提交于
Add recovery processing in case FIFO overrun error occurs with DMA transfer mode. Signed-off-by: NTomoya MORINAGA <tomoya-linux@dsn.okisemi.com> Signed-off-by: NGrant Likely <grant.likely@secretlab.ca>
-
由 Tomoya MORINAGA 提交于
We found Rx data sometimes drops.(with non-DMA transfer mode) The cause is read complete condition is not true. This patch fixes the issue. Signed-off-by: NTomoya MORINAGA <tomoya-linux@dsn.okisemi.com> Signed-off-by: NGrant Likely <grant.likely@secretlab.ca>
-