The platform_bus_set_pm_ops() operation is deprecated in favor of the
new device power domain infrastructre implemented in commit
7538e3db6e (PM: add support for device
power domains)
Signed-off-by: Kevin Hilman <khilman@ti.com>
Signed-off-by: Rafael J. Wysocki <rjw@sisk.pl>
Added implementation of FW download feature for Lancer.
Signed-off-by: Shripad Nunjundarao <shripad.nunjundarao@emulex.com>
Signed-off-by: Sevin Xavier <selvin.xavier@emulex.com>
Signed-off-by: Padmanabh Ratnakar <padmanabh.ratnakar@emulex.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Added support to get version 1 of the stats for BE3.
Use old stats command for BE2.
Signed-off-by: Ajit Khaparde <ajit.khaparde@emulex.com>
Signed-off-by: Selvin Xavier <selvin.xavier@emulex.com>
Signed-off-by: Padmanabh Ratnakar <padmanabh.ratnakar@emulex.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
mwifiex was using its own implementation of converting 802.11n
AMSDU to 802.3s. This patch removes mwifiex specific
implementation and uses existing ieee80211_amsdu_to_8023s
routine.
Signed-off-by: Yogesh Ashok Powar <yogeshp@marvell.com>
Signed-off-by: Bing Zhao <bzhao@marvell.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
Currently the devices that have already stripped IEEE 802.11
header from the AMSDU SKB can not use ieee80211_amsdu_to_8023s
routine. This patch enhances ieee80211_amsdu_to_8023s() API by
changing mandatory removing of IEEE 802.11 header from AMSDU
to optional.
Signed-off-by: Yogesh Ashok Powar <yogeshp@marvell.com>
Signed-off-by: Bing Zhao <bzhao@marvell.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
we are not doing anything by tracking the number of pending frames.
bail out when we first find a pending frame in any one of the 10 queues.
Signed-off-by: Mohammed Shafi Shajakhan <mshajakhan@atheros.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
some times the rssi control descriptor for the main antenna may be
negative like that of alternate antenna, hence before incrementing
packet counts/rssi of main/alternate antenna make sure both main_rssi
and alt_rssi are positive only. this avoids wrong selection of antenna
due to diversity
Cc: Gabriel Tseng <Gabriel.Tseng@Atheros.com>
Cc: Senthilkumar Balasubramanian <Senthilkumar.Balasubramanian@Atheros.com>
Signed-off-by: Mohammed Shafi Shajakhan <mshajakhan@atheros.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
configure fast diversity bias based on the antenna diversity group and
based on main/alt LNA configurations. also configure main antenna and
alternate antenna to gain-table 0 for diversity group 2(AR9485)
Cc: Gabriel Tseng <Gabriel.Tseng@Atheros.com>
Cc: Senthilkumar Balasubramanian <Senthilkumar.Balasubramanian@Atheros.com>
Signed-off-by: Mohammed Shafi Shajakhan <mshajakhan@atheros.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
for the diversity group 2(AR9485) we swap the LNA's of main/ALT antenna
based on alternate antenna's rssi average in comparision with main
antenna's rssi, while for AR9285(antenna diversity group 0)we still
follow the older method of looking at the packet count in alternate
antenna
Cc: Gabriel Tseng <Gabriel.Tseng@Atheros.com>
Cc: Senthilkumar Balasubramanian <Senthilkumar.Balasubramanian@Atheros.com>
Signed-off-by: Mohammed Shafi Shajakhan <mshajakhan@atheros.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
AR9285 belongs to diversity group 0 and AR9485 belongs to diversity
group 2. Based on the diversity group we configure certain antenna
diversity paramaters such as lna1_lna2_delta and fast diversity
bias values. For AR9485 we have some gain table parameter which
selects the gain table 0/1 for main and alternate antenna
Cc: Gabriel Tseng <Gabriel.Tseng@Atheros.com>
Cc: Senthilkumar Balasubramanian <Senthilkumar.Balasubramanian@Atheros.com>
Signed-off-by: Mohammed Shafi Shajakhan <mshajakhan@atheros.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
these are the two important modules that will be called by the antenna
diversity algorithm module in the rx. this will continuosly configure
the hardware based on the current diversity status obtained
from the algorithm
Cc: Gabriel Tseng <Gabriel.Tseng@Atheros.com>
Cc: Senthilkumar Balasubramanian <Senthilkumar.Balasubramanian@Atheros.com>
Signed-off-by: Mohammed Shafi Shajakhan <mshajakhan@atheros.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
* enable LNA-diversity, fast-diversity for AR9485 based on
the value read from EEPROM content
* if antenna diversity/combining is supported, set LNA1 for the main
antenna and LNA2 for the alternate antenna based on the new diversity
algorithm
Cc: Gabriel Tseng <Gabriel.Tseng@Atheros.com>
Cc: Senthilkumar Balasubramanian <Senthilkumar.Balasubramanian@Atheros.com>
Cc: Luis Rodriguez <Luis.Rodriguez@Atheros.com>
Signed-off-by: Mohammed Shafi Shajakhan <mshajakhan@atheros.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
define few registers and macros to configure/enable Antenna diversity
parameters in AR9485
Cc: Gabriel Tseng <Gabriel.Tseng@Atheros.com>
Cc: Senthilkumar Balasubramanian <Senthilkumar.Balasubramanian@Atheros.com>
Signed-off-by: Mohammed Shafi Shajakhan <mshajakhan@atheros.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
read antenna diversity and combining information from the EEPROM.
Enable antenna diversity/combining feature only when both LNA
diversity and fast diversity are supported
Cc: Gabriel Tseng <Gabriel.Tseng@Atheros.com>
Cc: Senthilkumar Balasubramanian <Senthilkumar.Balasubramanian@Atheros.com>
Tested-by: Mohammed Shafi Shajakhan <mshajakhan@atheros.com>
Signed-off-by: Mohammed Shafi Shajakhan <mshajakhan@atheros.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
this is necessary to support Antenna diversity and combining in new chip
sets such as AR9485, previously Antenna diversity support is available
only in AR9285
Cc: Gabriel Tseng <Gabriel.Tseng@Atheros.com>
Cc: Senthilkumar Balasubramanian <Senthilkumar.Balasubramanian@Atheros.com>
Signed-off-by: Mohammed Shafi Shajakhan <mshajakhan@atheros.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
Enabling DEBUG_STRICT_USER_COPY_CHECKS causes the following
warning:
In file included from arch/x86/include/asm/uaccess.h:573,
from include/net/checksum.h:25,
from include/linux/skbuff.h:28,
from drivers/net/wireless/iwlwifi/iwl-agn-rs.c:28:
In function 'copy_from_user',
inlined from 'rs_sta_dbgfs_scale_table_write' at
drivers/net/wireless/iwlwifi/iwl-agn-rs.c:3099:
arch/x86/include/asm/uaccess_64.h:65:
warning: call to 'copy_from_user_overflow' declared with
attribute warning: copy_from_user() buffer size is not provably
correct
presumably due to buf_size being signed causing GCC to fail to
see that buf_size can't become negative.
Signed-off-by: Stephen Boyd <sboyd@codeaurora.org>
Signed-off-by: Wey-Yi Guy <wey-yi.w.guy@intel.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
Enabling DEBUG_STRICT_USER_COPY_CHECKS causes the following
warning:
In file included from arch/x86/include/asm/uaccess.h:573,
from include/net/checksum.h:25,
from include/linux/skbuff.h:28,
from drivers/net/wireless/iwlegacy/iwl-4965-rs.c:28:
In function 'copy_from_user',
inlined from 'iwl4965_rs_sta_dbgfs_scale_table_write' at
drivers/net/wireless/iwlegacy/iwl-4965-rs.c:2616:
arch/x86/include/asm/uaccess_64.h:65:
warning: call to 'copy_from_user_overflow' declared with
attribute warning: copy_from_user() buffer size is not provably
correct
presumably due to buf_size being signed causing GCC to fail to
see that buf_size can't become negative.
Cc: Johannes Berg <johannes.berg@intel.com>
Signed-off-by: Stephen Boyd <sboyd@codeaurora.org>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
1) in the calling of erst_read, the parameter of buffer size
maybe overflows and cause crash
2) the return value of erst_read should be checked more strictly
Signed-off-by: Chen Gong <gong.chen@linux.intel.com>
Signed-off-by: Tony Luck <tony.luck@intel.com>
Currently after mount/remount operation on pstore filesystem,
the content on pstore will be lost. It is because current ERST
implementation doesn't support multi-user usage, which moves
internal pointer to the end after accessing it. Adding
multi-user support for pstore usage.
Signed-off-by: Chen Gong <gong.chen@linux.intel.com>
Signed-off-by: Tony Luck <tony.luck@intel.com>
the return type of function _read_ in pstore is size_t,
but in the callback function of _read_, the logic doesn't
consider it too much, which means if negative value (assuming
error here) is returned, it will be converted to positive because
of type casting. ssize_t is enough for this function.
Signed-off-by: Chen Gong <gong.chen@linux.intel.com>
Signed-off-by: Tony Luck <tony.luck@intel.com>
This patch updates the bnx2x_set_features() to handle loopback mode.
When enabled; it sets internal-MAC loopback.
Signed-off-by: Mahesh Bandewar <maheshb@google.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
This option appears to have been broken by commit
8313aca38b ('sfc: Allocate each channel
separately, along with its RX and TX queues').
Signed-off-by: Ben Hutchings <bhutchings@solarflare.com>
* 'drm-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/airlied/drm-2.6:
drm: Take lock around probes for drm_fb_helper_hotplug_event
drm/i915: Revert i915.semaphore=1 default from 47ae63e0
vga_switcheroo: don't toggle-switch devices
drm/radeon/kms: add some evergreen/ni safe regs
drm/radeon/kms: fix extended lvds info parsing
drm/radeon/kms: fix tiling reg on fusion
The line buffer sizes vary across DSI modules, create a function
dsi_get_line_buf_size() using DSI_GNQ register to get the size of
line buffer used for the DISPC video port data.
Signed-off-by: Archit Taneja <archit@ti.com>
Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
On OMAP3, the DSI module has 2 data lanes. On OMAP4, DSI1 has 4 data lanes
and DSI2 has 2 data lanes. Introduce function dsi_get_num_data_lanes() which
returns the number of data lanes on the dsi interface, introduce function
dsi_get_num_data_lanes_dssdev() which returns the number of data lanes used by
the omap_dss_device connected to the lanes.
Use the DSI_GNQ register on OMAP4 to get the number of data lanes, modify
dsi.c to use the number of lanes and the extra data lanes on DSI1.
Signed-off-by: Archit Taneja <archit@ti.com>
Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
In the previous DSI driver design, a private workqueue was needed to prevent a
deadlock as explained in the commit : 0f16aa0ae6
. In the current design, the workqueue is only used for queueing delayed work in
the case where we don't get a FRAMEDONE interrupt for 250 milliseconds. It is
safe to remove the private workqueue amd use the system workqueue instead to
schedule the delayed work with the new design where the deadlock can't occur.
Signed-off-by: Archit Taneja <archit@ti.com>
Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
dsi_dump_clocks() prints lck and pck rates for the DISPC channel which it is
connected to. Remove this since it is already printed by dispc_dump_clocks()
in debugfs.
Signed-off-by: Archit Taneja <archit@ti.com>
Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
We need to hold the dev->mode_config.mutex whilst detecting the output
status. But we also need to drop it for the call into
drm_fb_helper_single_fb_probe(), which indirectly acquires the lock when
attaching the fbcon.
Failure to do so exposes a race with normal output probing. Detected by
adding some warnings that the mutex is held to the backend detect routines:
[ 17.772456] WARNING: at drivers/gpu/drm/i915/intel_crt.c:471 intel_crt_detect+0x3e/0x373 [i915]()
[ 17.772458] Hardware name: Latitude E6400
[ 17.772460] Modules linked in: ....
[ 17.772582] Pid: 11, comm: kworker/0:1 Tainted: G W 2.6.38.4-custom.2 #8
[ 17.772584] Call Trace:
[ 17.772591] [<ffffffff81046af5>] ? warn_slowpath_common+0x78/0x8c
[ 17.772603] [<ffffffffa03f3e5c>] ? intel_crt_detect+0x3e/0x373 [i915]
[ 17.772612] [<ffffffffa0355d49>] ? drm_helper_probe_single_connector_modes+0xbf/0x2af [drm_kms_helper]
[ 17.772619] [<ffffffffa03534d5>] ? drm_fb_helper_probe_connector_modes+0x39/0x4d [drm_kms_helper]
[ 17.772625] [<ffffffffa0354760>] ? drm_fb_helper_hotplug_event+0xa5/0xc3 [drm_kms_helper]
[ 17.772633] [<ffffffffa035577f>] ? output_poll_execute+0x146/0x17c [drm_kms_helper]
[ 17.772638] [<ffffffff81193c01>] ? cfq_init_queue+0x247/0x345
[ 17.772644] [<ffffffffa0355639>] ? output_poll_execute+0x0/0x17c [drm_kms_helper]
[ 17.772648] [<ffffffff8105b540>] ? process_one_work+0x193/0x28e
[ 17.772652] [<ffffffff8105c6bc>] ? worker_thread+0xef/0x172
[ 17.772655] [<ffffffff8105c5cd>] ? worker_thread+0x0/0x172
[ 17.772658] [<ffffffff8105c5cd>] ? worker_thread+0x0/0x172
[ 17.772663] [<ffffffff8105f767>] ? kthread+0x7a/0x82
[ 17.772668] [<ffffffff8100a724>] ? kernel_thread_helper+0x4/0x10
[ 17.772671] [<ffffffff8105f6ed>] ? kthread+0x0/0x82
[ 17.772674] [<ffffffff8100a720>] ? kernel_thread_helper+0x0/0x10
Reported-by: Frederik Himpe <fhimpe@telenet.be>
References: https://bugs.freedesktop.org/show_bug.cgi?id=36394
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Dave Airlie <airlied@redhat.com>
Fix build errors when CONFIG_ACPI is enabled but MXM_WMI is not enabled
by selecting both MXM_WMI and ACPI_WMI (the latter just for kconfig
dependencies):
nouveau_acpi.c:(.text+0x2400c8): undefined reference to `mxm_wmi_call_mxmx'
nouveau_acpi.c:(.text+0x2400cf): undefined reference to `mxm_wmi_call_mxds'
nouveau_acpi.c:(.text+0x2400fe): undefined reference to `mxm_wmi_call_mxmx'
nouveau_acpi.c:(.text+0x2402ba): undefined reference to `mxm_wmi_supported
Signed-off-by: Randy Dunlap <randy.dunlap@oracle.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
* 'nouveau/drm-nouveau-next' of /ssd/git/drm-nouveau-next: (55 commits)
drm/nouveau: make cursor_set implementation consistent with other drivers
drm/nva3/clk: better pll calculation when no fractional fb div available
drm/nouveau/pm: translate ramcfg strap through ram restrict table
drm/nva3/pm: allow use of divisor 16
drm/nvc0/pm: parse clock for pll 0x0a (0x137020) from perf table
drm/nvc0/pm: correct core/mem/shader perflvl parsing
drm/nouveau/pm: remove memtiming support check when assigning to perflvl
drm/nva3: support for memory timing map table
drm/nouveau: Associate memtimings with performance levels on cards <= nv98
drm/nva3/pm: initial pass at set_clock() hook
drm/nvc0/gr: calculate some more of our magic numbers
drm/nv50: respect LVDS link count from EDID on SPWG panels
drm/nouveau: recognise DCB connector type 0x41 as LVDS
drm/nouveau: fix uninitialised variable warning
drm/nouveau: Fix a crash at card takedown for NV40 and older cards
drm/nouveau: Free nv04 instmem ramin heap at card takedown
drm/nva3: somewhat improve clock reporting
drm/nouveau: pull refclk from vbios on limits 0x40 boards
drm/nv40/gr: oops, fix random bits getting set in engine obj
drm/nv50: improve nv50_pm_get_clock()
...
When xorg state tracker wants to hide the cursor it calls set_cursor
with NULL buffer_handle and size=0x0, but nouveau refuses to hide it
because size is not 64x64... which is a bit odd. Both radeon and intel
check buffer_handle before validating size of cursor, so make nouveau
implementation consistent with them.
Signed-off-by: Marcin Slusarz <marcin.slusarz@gmail.com>
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
The core/mem/shader clocks don't support the fractional feedback divider,
causing our calculated clocks to be off by quite a lot in some cases. To
solve this we will switch to a search-based algorithm when fN is NULL.
For my NVA8 at PL3, this actually generates identical cooefficients to
the binary driver. Hopefully that's a good sign, and that does not
break VPLL calculation for someone..
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
Hopefully this is how we're supposed to correctly handle when the RAMCFG
strap is above the number of entries in timing-related tables.
It's rather difficult to confirm without finding a configuration where
the ram restrict table doesn't map 8-15 back onto 0-7 anyway. There's
not a single vbios in the repo which is configured differently..
In any case, this is probably still better than potentially reading
outside of the bounds of various tables..
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
We need to parse some of these other entries still, but I've yet to
determine exactly which PLLs the rest map to.
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
Really not necessary here, we want to be able to see if/how we managed to
match a timingset to a performance level, even if we can't currently
program it.
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
v2 (Ben Skeggs): fix ramcfg strap, and remove bogus handling of perf 0x40
Signed-off-by: Martin Peres <martin.peres@ensi-bourges.fr>
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
Again, doesn't quite match NVIDIA's, but not sure it really matters. This
will however, match the same rules we use to calculate the other related
grctx magics.
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
After looking at a number of different logs, it appears 0x41 likely
indicates the presense of an LVDS panel following the SPWG spec
(http://www.spwg.org/)
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
NV40 and older cards (pre NV50) reserve a vram bo for the vga memory at
card init. This bo is then freed at card shutdown. The problem is that
the ttm bo vram manager was already freed. So a crash occurs when the
vga bo is freed. The fix is to free the vga bo prior to freeing the ttm
bo vram manager. There might be other solutions but this seemed the
simplest to me.
Signed-off-by: Jimmy Rentz <jb17bsome@gmail.com>
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
Definitely not 100% correct, but, for the configurations I've seen used
it'll read back the correct clocks now.
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
