[This is picked out of the differences between the upstream driver and
the staging driver. I'm resolving the differences as a series of updates -AC]
Signed-off-by: Alan Cox <alan@linux.intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Older out of tree drivers that were desgined to the Android Alarm
in-kernel API may not build due to the namespace collision fixed in
an earlier patch. Per Arve's suggestion, this patch provides
preprocessor macros that allow older drivers to build.
CC: Arve Hjønnevåg <arve@android.com>
CC: Android Kernel Team <kernel-team@android.com>
Signed-off-by: John Stultz <john.stultz@linaro.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
This patch fixes the following warnings:
drivers/staging/android/alarm.c: In function ‘alarm_timer_triggered’:
drivers/staging/android/alarm.c:344: warning: format ‘%d’ expects type ‘int’, but argument 2 has type ‘long int’
drivers/staging/android/alarm.c:367: warning: format ‘%d’ expects type ‘int’, but argument 2 has type ‘long int’
CC: Arve Hjønnevåg <arve@android.com>
CC: Android Kernel Team <kernel-team@android.com>
Signed-off-by: John Stultz <john.stultz@linaro.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
If an alarm was restarted with a value that moved it away from the head
of a queue, the hrtimer would not be updated. This would cause unnecessary
wakeups.
CC: Arve Hjønnevåg <arve@android.com>
CC: Android Kernel Team <kernel-team@android.com>
Change-Id: If379f8dd92b0bdb3173bd8d057adfe0dc1d15259
Signed-off-by: Arve Hjønnevåg <arve@android.com>
Signed-off-by: John Stultz <john.stultz@linaro.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
The upstreamed alarmtimers are similar but not quite 100% API
compatibile with the android in-kernel alarm api. To aid the
transition, prefix the the android in-kernel api with android_
CC: Arve Hjønnevåg <arve@android.com>
CC: Android Kernel Team <kernel-team@android.com>
Signed-off-by: John Stultz <john.stultz@linaro.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Drivers can now create alarms that will use an hrtimer while the
system is running and the rtc to wake up from suspend.
CC: Arve Hjønnevåg <arve@android.com>
CC: Android Kernel Team <kernel-team@android.com>
Signed-off-by: Arve Hjønnevåg <arve@android.com>
[Fold and move alarm driver and interface to staging,
fix whitespace issue, drop kconfig & make file changes
as it currently doesn't build -jstultz]
Signed-off-by: John Stultz <john.stultz@linaro.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Stop reusing dquots from the freelist when allocating new ones directly, and
implement a shrinker that actually follows the specifications for the
interface. The shrinker implementation is still highly suboptimal at this
point, but we can gradually work on it.
This also fixes an bug in the previous lock ordering, where we would take
the hash and dqlist locks inside of the freelist lock against the normal
lock ordering. This is only solvable by introducing the dispose list,
and thus not when using direct reclaim of unused dquots for new allocations.
As a side-effect the quota upper bound and used to free ratio values in
/proc/fs/xfs/xqm are set to 0 as these values don't make any sense in the
new world order.
Signed-off-by: Christoph Hellwig <hch@lst.de>
Signed-off-by: Ben Myers <bpm@sgi.com>
This is a patch to the led_control.h file that fixes numerous warnings
and errors reported by the checkpatch.pl tool. There still remain a few
more, but as this is my first attempt at a commit, I'm not going to be
too adventurous!
Signed-off-by: Gerard Ryan <gerard@ryan.lt>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
When this driver was upgraded to the vendor 20100831 version in
commit 93c55dda09 et al,, one listhead initialization was missed.
This broke complete operation of the driver whenever AP mode was
enabled. This fixes https://bugs.archlinux.org/task/27996.
The configuration parameter R8712_AP is misleading as the driver cannot
function as an AP without a heavily hacked version of hostapd. Thus, it
makes sense to remove the parameter; however the code and data configured
for the option is left in.
Signed-off-by: Larry Finger <Larry.Finger@lwfinger.net>
Cc: Stable <stable@vger.kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
This patch removes the remaining defines that are already defined
identically in the sis initdef.h header.
Signed-off-by: Peter Huewe <peterhuewe@gmx.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Since the defines TVVCLKDIV2, TVVCLK, HiTVVCLKDIV2, HiTVVCLK,
HiTVSimuVCLK and HiTVTextVCLK are now defined as relative values, we
have to use TVCLKBASE_315 (0x31) as a base address to get the same values
as before the merge.
The old and now duplicated defines were removed
Signed-off-by: Peter Huewe <peterhuewe@gmx.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
This patch renames some of the defines that exist in the sis initdef.h
but seem to have a different value.
In order to preserve the functionality of the driver, we simply prepend
these defines with XGI_ (for now) to resolve conflicts and review them
later on.
Renames:
SetCRT2ToLCDA -> XGI_SetCRT2ToLCDA
LCDVESATiming -> XGI_LCDVESATiming
EnableLVDSDDA -> XGI_EnableLVDSDDA
LCDDualLink -> XGI_LCDDualLink
ModeSwitchStatus -> XGI_ModeSwitchStatus
YPbPr750pVCLK -> XGI_YPbPr750pVCLK
Signed-off-by: Peter Huewe <peterhuewe@gmx.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
This patch renames the Panel* defines and their usage to the naming
convention of the sis initdef.h and removes the now duplicated defines.
Renames:
Panel320x480 -> Panel_320x480
Panel800x600 -> Panel_800x600
Panel1024x768 -> Panel_1024x768
Panel1024x768x75 -> Panel_1024x768x75
Panel1280x1024 -> Panel_1280x1024
Panel1280x1024x75 -> Panel_1280x1024x75
Panel1280x960 -> Panel_1280x960
Panel1400x1050 -> Panel_1400x1050
Panel1600x1200 -> Panel_1600x1200
Signed-off-by: Peter Huewe <peterhuewe@gmx.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
This patch includes the initdef.h header from the sis driver.
Since the xgi driver used to redefine a lot of stuff from the sis
driver, we can simply include the headers of the sis driver itself, so
we can remove duplicated stuff later on.
In order to include the initdef.h we have to rename the header guards.
Signed-off-by: Peter Huewe <peterhuewe@gmx.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Turns out it's not quite ready to be included, thanks to some other work
done in the zcache and zram code, which breaks this driver.
So, delete it for now, per the recommendation of Dan.
Acked-by: Dan Magenheimer <dan.magenheimer@oracle.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
* 'drm-fixes' of git://people.freedesktop.org/~airlied/linux:
drm/i915: fixup interlaced bits clearing in PIPECONF on PCH_SPLIT (v2)
drm/i915: no lvds quirk for AOpen MP45
drm/i915: Force explicit bpp selection for intel_dp_link_required
drm/radeon: do not continue after error from r600_ib_test
drivers/gpu/drm/drm_ioc32.c: initialize all fields
drm/i915: fixup interlaced bits clearing in PIPECONF on PCH_SPLIT
drm/i915:: Disable FBC on SandyBridge
* 'perf-urgent-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip:
perf: Fix double start/stop in x86_pmu_start()
perf evsel: Fix an issue where perf report fails to show the proper percentage
perf tools: Fix prefix matching for kernel maps
perf tools: Fix perf stack to non executable on x86_64
perf: Remove deprecated WARN_ON_ONCE()
Couple of regressions, couple of zero-day bugs, a minor enhancement.
Nothing really major.
* tag 'hwmon-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/groeck/linux-staging:
hwmon: (f75375s) Let f75375_update_device treat pwmX as a measured value
hwmon: (f75375s) Fix bit shifting in f75375_write16
hwmon: (f75375s) Fix reading of wrong register when initializing the F75387
hwmon: (f75375s) Fix automatic pwm mode setting for F75373 & F75375
hwmon: (w83627ehf) Remove duplicate code
I'm not sure why they are needed (I didn't notice any difference in my
tests), but these bits are in our documentation and they are also set by
the Windows driver.
Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Reviewed-by: Jesse Barnes <jbarnes@virtuousgeek.org>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
The drm core _really_ likes to frob around with the crtc timings and
put halfed vertical timings (in fields) in there. Which confuses the
overlay code, resulting in it's refusal to display anything at the
lower half of an interlaced pipe.
Tested-by: Christopher Egert <cme3000@gmail.com>
Reviewed-by: Eugeni Dodonov <eugeni.dodonov@intel.com>
Signed-Off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
The hw seems to use this to correctly insert the required delay
before/after an even/odd interlaced field. This might also explain
why we need to substract 1 half-line from vtotal - if the hw just
adds the delay programmend in VSYNCSHIFT the total frame time would be
about that too long.
These registers seems to only exist on gen4 and later. For paranoia
also program it to 0 for progressive modes, but according to
documentation the hw should just ignore it in this case.
Reviewed-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Tested-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Tested-by: Alfonso Fiore <alfonso.fiore@gmail.com>
Signed-Off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
gen2 doesn't support it, so be a bit more paranoid and add a check to
ensure that we never ever set an unsupported interlaced bit.
Ensure that userspace can't set an interlaced mode by resetting
interlace_allowed for the crt on gen2. dvo and lvds are the only other
encoders that gen2 supports and these already disallow interlaced
modes.
Reviewed-by: Eugeni Dodonov <eugeni.dodonov@intel.com>
Reviewed-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Signed-Off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
According to bspec, we need to subtract an additional line from vtotal
for interlaced modes and vblank_end needs to equal vtotal. All other
timing fields do not need this special treatment, so kill it.
Bspec says that this is irrespective of whether the interlaced mode
has an odd or even vtotal, both modes are supported.
Reviewed-by: Eugeni Dodonov <eugeni.dodonov@intel.com>
Reviewed-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Tested-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Tested-by: Christopher Egert <cme3000@gmail.com>
Tested-by: Alfonso Fiore <alfonso.fiore@gmail.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
We have a pretty decent confusion about vertical timings of interlaced
modes. Peter Ross has written a patch that makes interlace modes work
on a lot more platforms/output combinations by doubling the vertical
timings.
The issue with that patch is that core drm _does_ support specifying
whether we want these vertical timings in fields or frames, we just
haven't managed to consistently use this facility. The relavant
function is drm_mode_set_crtcinfo, which fills in the crtc timing
information.
The first thing to note is that the drm core keeps interlaced modes in
frames, but displays modelines in fields. So when the crtc modeset
helper copies over the mode into adjusted_mode it will already contain
vertical timings in half-frames. The result is that the fixup code in
intel_crtc_mode_fixup doesn't actually do anything (in most cases at
least).
Now gen3+ natively supports interlaced modes and wants the vertical
timings in frames. Which is what sdvo already fixes up, at least under
some conditions.
There are a few other place that demand vertical timings in fields
but never actually deal with interlaced modes, so use frame timings
for consistency, too. These are:
- lvds panel,
- dvo encoders - dvo is the only way gen2 could support interlaced
mode, but currently we don't support any encoders that do.
- tv out - despite that the tv dac sends out an interlaced signal it
expects a progressive mode pipe configuration.
All these encoders enforce progressive modes by resetting
interlace_allowed.
Hence we always want crtc vertical timings in frames. Enforce this in
our crtc mode_fixup function and rip out any redudant timing
computations from the encoders' mode_fixup function.
v2-4: Adjust the vertical timings a bit.
v5: Split out the 'subtract-one for interlaced' fixes.
v6: Clarify issues around tv-out and gen2.
Reviewed-by: Eugeni Dodonov <eugeni.dodonov@intel.com>
Reviewed-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Tested-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Tested-by: Christopher Egert <cme3000@gmail.com>
Tested-by: Alfonso Fiore <alfonso.fiore@gmail.com>
Signed-Off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
- Clarify which bits are for which chips.
- Note that gen2 can't do interlaced directly (only via dvo tv chips).
- Move the mask to the top to make it clearer how wide this field is.
- Add defintions for all possible values.
This patch doesn't change any code.
v2: Paulo Zanoni pointed out that the pixel doubling modes do no
longer exist on ivb.
Cc: Peter Ross <pross@xvid.org>
Reviewed-by: Eugeni Dodonov <eugeni.dodonov@intel.com>
Reviewed-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Tested-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Tested-by: Christopher Egert <cme3000@gmail.com>
Tested-by: Alfonso Fiore <alfonso.fiore@gmail.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Back-merge from drm-fixes into drm-intel-next to sort out two things:
- interlaced support: -fixes contains a bugfix to correctly clear
interlaced configuration bits in case the bios sets up an interlaced
mode and we want to set up the progressive mode (current kernels
don't support interlaced). The actual feature work to support
interlaced depends upon (and conflicts with) this bugfix.
- forcewake voodoo to workaround missed IRQ issues: -fixes only enabled
this for ivybridge, but some recent bug reports indicate that we
need this on Sandybridge, too. But in a slightly different flavour
and with other fixes and reworks on top. Additionally there are some
forcewake cleanup patches heading to -next that would conflict with
currrent -fixes.
Signed-Off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Fix below build error which is introduced by
commit 022658 "ASoC: core: Add support for DAI and machine kcontrols".
CC [M] sound/soc/omap/n810.o
sound/soc/omap/n810.c: In function 'n810_set_input':
sound/soc/omap/n810.c:194: error: 'codec' undeclared (first use in this function)
sound/soc/omap/n810.c:194: error: (Each undeclared identifier is reported only once
sound/soc/omap/n810.c:194: error: for each function it appears in.)
sound/soc/omap/n810.c:188: warning: unused variable 'card'
make[3]: *** [sound/soc/omap/n810.o] Error 1
make[2]: *** [sound/soc/omap] Error 2
make[1]: *** [sound/soc] Error 2
make: *** [sound] Error 2
Signed-off-by: Axel Lin <axel.lin@gmail.com>
Acked-by: Jarkko Nikula <jarkko.nikula@bitmer.com>
Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
When host requests us to enter a test mode,
we cannot directly enter the test mode before
Status Phase is completed, otherwise the core
will never be able to deliver the Status ZLP
to host, because it has already entered the
requested Test Mode.
In order to fix the error, we move the actual
start of Test Mode right after we receive
Transfer Complete event of the status phase.
Signed-off-by: Gerard Cauvy <g-cauvy1@ti.com>
Signed-off-by: Felipe Balbi <balbi@ti.com>
time_t was used in the signature and key packet headers,
which is typedef of long and is different on 32 and 64 bit architectures.
Signature and key format should be independent of architecture.
Similar to GPG, I have changed the type to uint32_t.
Signed-off-by: Dmitry Kasatkin <dmitry.kasatkin@intel.com>
Signed-off-by: James Morris <jmorris@namei.org>
When implementing the USB2 testmode support via debugfs,
Felipe has committed a mistake when counting the number
of letters of some of the strings, resulting on an off
by one error which prevented some of the Test modes to
be entered properly.
This patch, fixes that mistake.
Signed-off-by: Gerard Cauvy <g-cauvy1@ti.com>
Signed-off-by: Felipe Balbi <balbi@ti.com>
Mark A. Allyn