Revision 9b4fe5fb0bdd8f31f24cbfe77e38ec8155c250c5 authored by Neil Horman on 12 July 2013, 17:35:33 UTC, committed by David S. Miller on 12 July 2013, 23:28:02 UTC
this bug:
https://bugzilla.redhat.com/show_bug.cgi?id=951695

Reported a dma debug backtrace:

WARNING: at lib/dma-debug.c:937 check_unmap+0x47d/0x930()
Hardware name: To Be Filled By O.E.M.
via-rhine 0000:00:12.0: DMA-API: device driver failed to check map error[device
address=0x0000000075a837b2] [size=90 bytes] [mapped as single]
Modules linked in: ip6_tables gspca_spca561 gspca_main videodev media
snd_hda_codec_realtek snd_hda_intel i2c_viapro snd_hda_codec snd_hwdep snd_seq
ppdev mperf via_rhine coretemp snd_pcm mii microcode snd_page_alloc snd_timer
snd_mpu401 snd_mpu401_uart snd_rawmidi snd_seq_device snd soundcore parport_pc
parport shpchp ata_generic pata_acpi radeon i2c_algo_bit drm_kms_helper ttm drm
pata_via sata_via i2c_core uinput
Pid: 295, comm: systemd-journal Not tainted 3.9.0-0.rc6.git2.1.fc20.x86_64 #1
Call Trace:
 <IRQ>  [<ffffffff81068dd0>] warn_slowpath_common+0x70/0xa0
 [<ffffffff81068e4c>] warn_slowpath_fmt+0x4c/0x50
 [<ffffffff8137ec6d>] check_unmap+0x47d/0x930
 [<ffffffff810ace9f>] ? local_clock+0x5f/0x70
 [<ffffffff8137f17f>] debug_dma_unmap_page+0x5f/0x70
 [<ffffffffa0225edc>] ? rhine_ack_events.isra.14+0x3c/0x50 [via_rhine]
 [<ffffffffa02275f8>] rhine_napipoll+0x1d8/0xd80 [via_rhine]
 [<ffffffff815d3d51>] ? net_rx_action+0xa1/0x380
 [<ffffffff815d3e22>] net_rx_action+0x172/0x380
 [<ffffffff8107345f>] __do_softirq+0xff/0x400
 [<ffffffff81073925>] irq_exit+0xb5/0xc0
 [<ffffffff81724cd6>] do_IRQ+0x56/0xc0
 [<ffffffff81719ff2>] common_interrupt+0x72/0x72
 <EOI>  [<ffffffff8170ff57>] ? __slab_alloc+0x4c2/0x526
 [<ffffffff811992e0>] ? mmap_region+0x2b0/0x5a0
 [<ffffffff810d5807>] ? __lock_is_held+0x57/0x80
 [<ffffffff811992e0>] ? mmap_region+0x2b0/0x5a0
 [<ffffffff811bf1bf>] kmem_cache_alloc+0x2df/0x360
 [<ffffffff811992e0>] mmap_region+0x2b0/0x5a0
 [<ffffffff811998e6>] do_mmap_pgoff+0x316/0x3d0
 [<ffffffff81183ca0>] vm_mmap_pgoff+0x90/0xc0
 [<ffffffff81197d6c>] sys_mmap_pgoff+0x4c/0x190
 [<ffffffff81367d7e>] ? trace_hardirqs_on_thunk+0x3a/0x3f
 [<ffffffff8101eb42>] sys_mmap+0x22/0x30
 [<ffffffff81722fd9>] system_call_fastpath+0x16/0x1b

Usual problem with the usual fix, add the appropriate calls to dma_mapping_error
where appropriate

Untested, as I don't have hardware, but its pretty straightforward

Signed-off-by: Neil Horman <nhorman@tuxdriver.com>
CC: David S. Miller <davem@davemloft.net>
CC: Roger Luethi <rl@hellgate.ch>
Signed-off-by: David S. Miller <davem@davemloft.net>
1 parent 352900b
Raw File
SM501.txt
			SM501 Driver
			============

Copyright 2006, 2007 Simtec Electronics

The Silicon Motion SM501 multimedia companion chip is a multifunction device
which may provide numerous interfaces including USB host controller USB gadget,
asynchronous serial ports, audio functions, and a dual display video interface.
The device may be connected by PCI or local bus with varying functions enabled.

Core
----

The core driver in drivers/mfd provides common services for the
drivers which manage the specific hardware blocks. These services
include locking for common registers, clock control and resource
management.

The core registers drivers for both PCI and generic bus based
chips via the platform device and driver system.

On detection of a device, the core initialises the chip (which may
be specified by the platform data) and then exports the selected
peripheral set as platform devices for the specific drivers.

The core re-uses the platform device system as the platform device
system provides enough features to support the drivers without the
need to create a new bus-type and the associated code to go with it.


Resources
---------

Each peripheral has a view of the device which is implicitly narrowed to
the specific set of resources that peripheral requires in order to
function correctly.

The centralised memory allocation allows the driver to ensure that the
maximum possible resource allocation can be made to the video subsystem
as this is by-far the most resource-sensitive of the on-chip functions.

The primary issue with memory allocation is that of moving the video
buffers once a display mode is chosen. Indeed when a video mode change
occurs the memory footprint of the video subsystem changes.

Since video memory is difficult to move without changing the display
(unless sufficient contiguous memory can be provided for the old and new
modes simultaneously) the video driver fully utilises the memory area
given to it by aligning fb0 to the start of the area and fb1 to the end
of it. Any memory left over in the middle is used for the acceleration
functions, which are transient and thus their location is less critical
as it can be moved.


Configuration
-------------

The platform device driver uses a set of platform data to pass
configurations through to the core and the subsidiary drivers
so that there can be support for more than one system carrying
an SM501 built into a single kernel image.

The PCI driver assumes that the PCI card behaves as per the Silicon
Motion reference design.

There is an errata (AB-5) affecting the selection of the
of the M1XCLK and M1CLK frequencies. These two clocks
must be sourced from the same PLL, although they can then
be divided down individually. If this is not set, then SM501 may
lock and hang the whole system. The driver will refuse to
attach if the PLL selection is different.
back to top