- 10 10月, 2013 9 次提交
-
-
由 Ville Syrjälä 提交于
We limit the maximum n divider value in order to make sure the PLL's reference inout is at least 19.2 MHz. I assume that is done to satisfy some hardware requirement. However we never check whether that calculated limit is below the maximum supoorted N divider value (7). In practice that is always true since we only support 100 MHz reference clock, but making the code safe against higher reference clocks seems like a reasoanble thing to do. Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by: NMika Kuoppala <mika.kuoppala@intel.com> Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
-
由 Ville Syrjälä 提交于
The p2 divider on VLV needs to be even when it's > 10. The current code to make that happen is rather weird. Just make the step size adjustement in the for loop decrement step. Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by: NMika Kuoppala <mika.kuoppala@intel.com> Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
-
由 Ville Syrjälä 提交于
Rewrite vlv_find_best_dpll() to use intel_clock_t rather than an army of local variables. Also extract the code to calculate the derived values into vlv_clock(). v2: Split up the earlier fixes, extract vlv_clock() v3: Initialize best_clock Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by: NMika Kuoppala <mika.kuoppala@intel.com> Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
-
由 Ville Syrjälä 提交于
We do 'bestppm - 10' in vlv_find_best_dpll() but never check whether that might underflow. Add such a check. Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by: NMika Kuoppala <mika.kuoppala@intel.com> Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
-
由 Ville Syrjälä 提交于
Use div_u64() to make the ppm calculation in vlv_find_best_dpll() safe against interger overflows. Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by: NMika Kuoppala <mika.kuoppala@intel.com> Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
-
由 Jani Nikula 提交于
Signed-off-by: NJani Nikula <jani.nikula@intel.com> Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
-
由 Damien Lespiau 提交于
Signed-off-by: NDamien Lespiau <damien.lespiau@intel.com> Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
-
由 Chris Wilson 提交于
The interface uses an unsigned long, and we can use the unsigned counter throughout our code, so do so. In the process, we notice one instance where the shrink count is based on a heuristic rather than the result, and another where we ask for too many pages to be purged. v2: nr_to_scan needs to be promoted to a long as well, so just use sc->nr_to_scan directly. Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk> Cc: Daniel Vetter <daniel.vetter@ffwll.ch> Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
-
由 Chris Wilson 提交于
Since we are waiting upon IO completion, inform the kernel through use of the io_schedule() call rather than the regular schedule(). This should allow the kernel to make better decisions regarding scheduling and power management. Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk> Cc: Daniel Vetter <daniel.vetter@ffwll.ch> Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
-
- 09 10月, 2013 7 次提交
-
-
由 Jani Nikula 提交于
It's not really needed, rather just adds another place to hold intermediate values that could go wrong, and it's not clear that the training pattern set or training lane set should be written at this point at all. Signed-off-by: NJani Nikula <jani.nikula@intel.com> Reviewed-by: NVille Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: NDave Airlie <airlied@redhat.com>
-
由 Ville Syrjälä 提交于
The user of these counters was killed in commit d79cdc83 Author: Daniel Vetter <daniel.vetter@ffwll.ch> Date: Thu Aug 8 15:41:32 2013 +0200 drm: no-op out GET_STATS ioctl so clean up the leftovers as well. Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by: NDaniel Vetter <daniel.vetter@ffwll.ch> Reviewed-by: NAlex Deucher <alexander.deucher@amd.com> Signed-off-by: NDave Airlie <airlied@redhat.com>
-
由 Ville Syrjälä 提交于
We can get the PCI vendor and device IDs via dev->pdev. So we can drop the duplicated information. Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by: NDaniel Vetter <daniel.vetter@ffwll.ch> Reviewed-by: NAlex Deucher <alexander.deucher@amd.com> Signed-off-by: NDave Airlie <airlied@redhat.com>
-
由 Ville Syrjälä 提交于
drm_vblank_init() is too ugly. Make it a bit easier on the eye by collecting all the per-crtc vblank counters, timestamps etc. to a structure and just allocate an array of those. Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by: NDaniel Vetter <daniel.vetter@ffwll.ch> Reviewed-by: NAlex Deucher <alexander.deucher@amd.com> Signed-off-by: NDave Airlie <airlied@redhat.com>
-
由 Ville Syrjälä 提交于
vblank_disable_allowed is only ever 0 or 1, so make it a bool. Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by: NDaniel Vetter <daniel.vetter@ffwll.ch> Reviewed-by: NAlex Deucher <alexander.deucher@amd.com> Signed-off-by: NDave Airlie <airlied@redhat.com>
-
由 Jani Nikula 提交于
v2: duplicate intel_connector->edid, not uninitialized edid (Dave Airlie). Signed-off-by: NJani Nikula <jani.nikula@intel.com> Signed-off-by: NDave Airlie <airlied@redhat.com>
-
由 David Herrmann 提交于
All drivers embed gem-objects into their own buffer objects. There is no reason to keep drm_gem_object_alloc(), gem->driver_private and ->gem_init_object() anymore. New drivers are highly encouraged to do the same. There is no benefit in allocating gem-objects separately. Cc: Dave Airlie <airlied@gmail.com> Cc: Alex Deucher <alexdeucher@gmail.com> Cc: Daniel Vetter <daniel@ffwll.ch> Cc: Jerome Glisse <jglisse@redhat.com> Cc: Rob Clark <robdclark@gmail.com> Cc: Inki Dae <inki.dae@samsung.com> Cc: Ben Skeggs <skeggsb@gmail.com> Cc: Patrik Jakobsson <patrik.r.jakobsson@gmail.com> Signed-off-by: NDavid Herrmann <dh.herrmann@gmail.com> Acked-by: NAlex Deucher <alexander.deucher@amd.com> Signed-off-by: NDave Airlie <airlied@redhat.com>
-
- 04 10月, 2013 14 次提交
-
-
由 Damien Lespiau 提交于
When booting with i915.fastboot=1, we always take tha code path and end up undoing what we're trying to do with adjusted_mode. Hopefully, as the fastboot hardware readout code is using adjusted_mode as well, it should be equivalent. Signed-off-by: NDamien Lespiau <damien.lespiau@intel.com> Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
-
由 Damien Lespiau 提交于
Instead of it just being on the mailing list, let's put Jesse's explanation next to the code in question. Signed-off-by: NDamien Lespiau <damien.lespiau@intel.com> Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
-
由 Chon Ming Lee 提交于
During system boot up, by default, the power gate for render, media and display well still power gated. Normally, BIOS will turn off the power gate. In the BIOS-less system, the driver need to turn off the power gate very early during driver load. v2: Move this to intel_uncore_sanitize to allow it to get call during resume path. (Daniel) v3: Remove redundant write 0 to DPIO_CTL, and use DPIO_RESET instead of just 0x1 (Ville) Add turn of power gate for display 2d/render well/media well. v4: Remove toggle cmnreset in intel_uncore_sanitize. Cmnreset should toggle after CRI clock source has been selected. Jesse DPIO reset patch which toggle the cmnreset in intel_modeset_init_hw() should handle it. (Ville) Signed-off-by: NChon Ming Lee <chon.ming.lee@intel.com> Reviewed-by: NVille Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
-
由 Jesse Barnes 提交于
DPIO needs to have common reset de-asserted on soft resets like boot and S3. In some cases, the BIOS will have done this for us, but it should be safe to do at runtime as well, as long as we do it when the pipes are otherwise off. v2: update bit name to match docs better (Ville) reset after CRI clock select (Ville) References: https://bugs.freedesktop.org/show_bug.cgi?id=69166Signed-off-by: NJesse Barnes <jbarnes@virtuousgeek.org> Reviewed-by: NVille Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
-
由 Rodrigo Vivi 提交于
for igt test case. v2: remove trailing spaces and fix conflicts Signed-off-by: NRodrigo Vivi <rodrigo.vivi@gmail.com> [danvet: - make it comipile - s/IS_HASWELL/HAS_PSR/] Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
-
由 Chris Wilson 提交于
After applying wait-boost we often find ourselves stuck at higher clocks than required. The current threshold value requires the GPU to be continuously and completely idle for 313ms before it is dropped by one bin. Conversely, we require the GPU to be busy for an average of 90% over a 84ms period before we upclock. So the current thresholds almost never downclock the GPU, and respond very slowly to sudden demands for more power. It is easy to observe that we currently lock into the wrong bin and both underperform in benchmarks and consume more power than optimal (just by repeating the task and measuring the different results). An alternative approach, as discussed in the bspec, is to use a continuous threshold for upclocking, and an average value for downclocking. This is good for quickly detecting and reacting to state changes within a frame, however it fails with the common throttling method of waiting upon the outstanding frame - at least it is difficult to choose a threshold that works well at 15,000fps and at 60fps. So continue to use average busy/idle loads to determine frequency change. v2: Use 3 power zones to keep frequencies low in steady-state mostly idle (e.g. scrolling, interactive 2D drawing), and frequencies high for demanding games. In between those end-states, we use a fast-reclocking algorithm to converge more quickly on the desired bin. v3: Bug fixes - make sure we reset adj after switching power zones. v4: Tune - drop the continuous busy thresholds as it prevents us from choosing the right frequency for glxgears style swap benchmarks. Instead the goal is to be able to find the right clocks irrespective of the wait-boost. Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk> Cc: Kenneth Graunke <kenneth@whitecape.org> Cc: Stéphane Marchesin <stephane.marchesin@gmail.com> Cc: Owen Taylor <otaylor@redhat.com> Cc: "Meng, Mengmeng" <mengmeng.meng@intel.com> Cc: "Zhuang, Lena" <lena.zhuang@intel.com> Reviewed-by: NJesse Barnes <jbarnes@virtuousgeek.org> Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
-
由 Chris Wilson 提交于
If we encounter a situation where the CPU blocks waiting for results from the GPU, give the GPU a kick to boost its the frequency. This should work to reduce user interface stalls and to quickly promote mesa to high frequencies - but the cost is that our requested frequency stalls high (as we do not idle for long enough before rc6 to start reducing frequencies, nor are we aggressive at down clocking an underused GPU). However, this should be mitigated by rc6 itself powering off the GPU when idle, and that energy use is dependent upon the workload of the GPU in addition to its frequency (e.g. the math or sampler functions only consume power when used). Still, this is likely to adversely affect light workloads. In particular, this nearly eliminates the highly noticeable wake-up lag in animations from idle. For example, expose or workspace transitions. (However, given the situation where we fail to downclock, our requested frequency is almost always the maximum, except for Baytrail where we manually downclock upon idling. This often masks the latency of upclocking after being idle, so animations are typically smooth - at the cost of increased power consumption.) Stéphane raised the concern that this will punish good applications and reward bad applications - but due to the nature of how mesa performs its client throttling, I believe all mesa applications will be roughly equally affected. To address this concern, and to prevent applications like compositors from permanently boosting the RPS state, we ratelimit the frequency of the wait-boosts each client recieves. Unfortunately, this techinique is ineffective with Ironlake - which also has dynamic render power states and suffers just as dramatically. For Ironlake, the thermal/power headroom is shared with the CPU through Intelligent Power Sharing and the intel-ips module. This leaves us with no GPU boost frequencies available when coming out of idle, and due to hardware limitations we cannot change the arbitration between the CPU and GPU quickly enough to be effective. v2: Limit each client to receiving a single boost for each active period. Tested by QA to only marginally increase power, and to demonstrably increase throughput in games. No latency measurements yet. v3: Cater for front-buffer rendering with manual throttling. v4: Tidy up. v5: Sadly the compositor needs frequent boosts as it may never idle, but due to its picking mechanism (using ReadPixels) may require frequent waits. Those waits, along with the waits for the vrefresh swap, conspire to keep the GPU at low frequencies despite the interactive latency. To overcome this we ditch the one-boost-per-active-period and just ratelimit the number of wait-boosts each client can receive. Reported-and-tested-by: NPaul Neumann <paul104x@yahoo.de> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=68716Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk> Cc: Kenneth Graunke <kenneth@whitecape.org> Cc: Stéphane Marchesin <stephane.marchesin@gmail.com> Cc: Owen Taylor <otaylor@redhat.com> Cc: "Meng, Mengmeng" <mengmeng.meng@intel.com> Cc: "Zhuang, Lena" <lena.zhuang@intel.com> Reviewed-by: NJesse Barnes <jbarnes@virtuousgeek.org> [danvet: No extern for function prototypes in headers.] Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
-
由 Chris Wilson 提交于
When we switched to always using a timeout in conjunction with wait_seqno, we lost the ability to detect missed interrupts. Since, we have had issues with interrupts on a number of generations, and they are required to be delivered in a timely fashion for a smooth UX, it is important that we do log errors found in the wild and prevent the display stalling for upwards of 1s every time the seqno interrupt is missed. Rather than continue to fix up the timeouts to work around the interface impedence in wait_event_*(), open code the combination of wait_event[_interruptible][_timeout], and use the exposed timer to poll for seqno should we detect a lost interrupt. v2: In order to satisfy the debug requirement of logging missed interrupts with the real world requirments of making machines work even if interrupts are hosed, we revert to polling after detecting a missed interrupt. v3: Throw in a debugfs interface to simulate broken hw not reporting interrupts. v4: s/EGAIN/EAGAIN/ (Imre) Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk> Reviewed-by: NImre Deak <imre.deak@intel.com> [danvet: Don't use the struct typedef in new code.] Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
-
由 Chris Wilson 提交于
We missed adding a few cleanup steps for recent additions. Reviewer: Ben Widawsky <ben@bwidawsk.net> Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk> Signed-off-by: NRodrigo Vivi <rodrigo.vivi@gmail.com> Reviewed-by: NBen Widawsky <ben@bwidawsk.net> Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
-
由 Ben Widawsky 提交于
This patch attempts to clean up the ring/IA scaling programming in the following ways. 1. Fix the comment about the DDR frequency. The math is 266MHz, not 133MHz. Formula was right, docs are wrong. 2. Mask the DCLK register since I don't know how it is defined on future platforms. 3. use mult_frac instead of magic math. This helps for future platform enabling. v2: Actually use the right patch. The v1 was a mix of things, none of which was right. Note that due to rounding, we actually get different values (slightly higher) for the effective ring frequency. v3: Use 1.25 instead of 1.33 as the original code did. (Jesse) CC: Jesse Barnes <jbarnes@virtuousgeek.org> CC: Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by: NBen Widawsky <ben@bwidawsk.net> Reviewed-by: NJesse Barnes <jbarnes@virtuousgeek.org> Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
-
由 Ville Syrjälä 提交于
If we ever end up doing the retry loop due to bandwidth constraints, we would rewrite pipe_src_{w,n} based on adjusted_mode timings. But by that time the encoder may have already replaced the adjusted_mode with a fixed panel mode, which would then corrupt pipe_src_{w,h}. v2: Use requested_mode and slap on a big comment from Daniel Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
-
由 Paulo Zanoni 提交于
This workaround is described in the mode set sequence documentation. When enabling planes for the second pipe, we need to wait for 2 vblanks on the first pipe. This should solve "a flash of screen corruption if planes are enabled on second/third pipe during the time that big FIFO mode is exiting". Watermarks are fun :) v2: Save indentation levels Signed-off-by: NPaulo Zanoni <paulo.r.zanoni@intel.com> Reviewed-by: NVille Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
-
由 Ville Syrjälä 提交于
Refactor the plane enabling/disabling into helper functions and move the calls to happen as the first thing during .crtc_disable, and the last thing during .crtc_enable. Those are the two clear points where we are sure that the pipe is actually running regardless of the encoder type or hardware generation. v2: Made by Paulo: Remove the code touching everything but the Haswell functions. We need this change on Haswell right now since it fixes a FIFO underrun that we get on pipe A while we enable pipe B (see the workaround notes on the Haswell mode set sequence documentation). We can bring back the code to gens 2-7 later, once they're tested. Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: NPaulo Zanoni <paulo.r.zanoni@intel.com> Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
-
由 Jesse Barnes 提交于
The global integrated clock source bit resides in DPLL B on VLV, but we were treating it as a per-pipe resource. It needs to be set whenever any PLL is active, so pull setting the bit out of vlv_update_pll and into vlv_enable_pll. Also add a vlv_disable_pll to prevent disabling it when pipe B shuts down. I'm guessing on the references here, I expect this to bite any config where multiple displays are active or displays are moved from pipe to pipe. v2: re-add bits in vlv_update_pll to keep from confusing the state checker v3: use enum pipe checks (Daniel) set CRI clock source early (Ville) consistently set CRI clock source everywhere (Ville) v4: drop unnecessary setting of bit in vlv enable pll (Ville) References: https://bugs.freedesktop.org/show_bug.cgi?id=67245 References: https://bugs.freedesktop.org/show_bug.cgi?id=69693Signed-off-by: NJesse Barnes <jbarnes@virtuousgeek.org> Reviewed-by: NVille Syrjälä <ville.syrjala@linux.intel.com> [danvet: s/1/PIPE_B/] Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
-
- 01 10月, 2013 10 次提交
-
-
由 Jani Nikula 提交于
Signed-off-by: NJani Nikula <jani.nikula@intel.com> Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
-
由 Damien Lespiau 提交于
Signed-off-by: NDamien Lespiau <damien.lespiau@intel.com> Reviewed-by: NVille Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
-
由 Paulo Zanoni 提交于
For some reason, every single time I try to run module_reload something tries to read the connector sysfs files. This happens after we destroy the encoders and before we destroy the connectors, so when the sysfs read triggers the connector detect() function, intel_conector->encoder points to memory that was already freed. The bad backtrace is just: [<ffffffff8163ca9a>] dump_stack+0x54/0x74 [<ffffffffa00c2c8e>] intel_dp_detect+0x1e/0x4b0 [i915] [<ffffffffa001913d>] status_show+0x3d/0x80 [drm] [<ffffffff813d5340>] dev_attr_show+0x20/0x60 [<ffffffff81221f50>] ? sysfs_read_file+0x80/0x1b0 [<ffffffff81221f79>] sysfs_read_file+0xa9/0x1b0 [<ffffffff811aaf1e>] vfs_read+0x9e/0x170 [<ffffffff811aba4c>] SyS_read+0x4c/0xa0 [<ffffffff8164e392>] system_call_fastpath+0x16/0x1b But if you add tons of memory checking debug options to your Kernel you'll also see: - general protection fault: 0000 - BUG kmalloc-4096 (Tainted: G D W ): Poison overwritten - INFO: Allocated in intel_ddi_init+0x65/0x270 [i915] - INFO: Freed in intel_dp_encoder_destroy+0x69/0xb0 [i915] Among a bunch of other error messages. So this commit just destroys the sysfs files before both the encoder and connectors are freed. Signed-off-by: NPaulo Zanoni <paulo.r.zanoni@intel.com> Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
-
由 Jani Nikula 提交于
Neither the DP spec nor the compliance test spec state or imply that we should write the DP_TRAINING_PATTERN_SET at every voltage swing and pre-emphasis change. Indeed we probably shouldn't. So don't. Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=49402Signed-off-by: NJani Nikula <jani.nikula@intel.com> Smoke-tested-by: NPaulo Zanoni <paulo.r.zanoni@intel.com> Reviewed-by: NVille Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
-
由 Jani Nikula 提交于
Per DP1.2 spec. Signed-off-by: NJani Nikula <jani.nikula@intel.com> Reviewed-by: NTodd Previte <tprevite@gmail.com> Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
-
由 Jesse Barnes 提交于
It indicates a probable BIOS bug, but it appears to be harmless, and there's nothing the user can do about it anyway, so reduce to a debug msg. I've filed a bug with the BIOS folks about it anyway, so hopefully they'll fix whatever GT SB read they were doing when the GT was off. References: https://bugs.freedesktop.org/show_bug.cgi?id=69396Signed-off-by: NJesse Barnes <jbarnes@virtuousgeek.org> Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
-
由 Jesse Barnes 提交于
We need to use the clock control reg to figure out how many CZ clks are in 30ns and use that as the basis for our RC6 residency calculations. v2: use ULL everywhere for consistency (Chris) factor out bias for clarity (Chris) References: https://bugs.freedesktop.org/show_bug.cgi?id=69692Signed-off-by: NJesse Barnes <jbarnes@virtuousgeek.org> Reviewed-by: NChris Wilson <chris@chris-wilson.co.uk> Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
-
由 Jesse Barnes 提交于
And add some reg defines while we're at it. Since the units of the RC6 residency counter are actually in CZ clocks, we want to just use the high bits or we'll overflow too frequently. Signed-off-by: NJesse Barnes <jbarnes@virtuousgeek.org> Reviewed-by: NChris Wilson <chris@chris-wilson.co.uk> Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
-
由 Ville Syrjälä 提交于
vlv_find_best_dpll() has an open coded DIV_ROUND_CLOSEST(). Replace it with the real thing. Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by: NMika Kuoppala <mika.kuoppala@intel.com> Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
-
由 Ville Syrjälä 提交于
Use 'continue' to get rid of one indent level in vlv_find_best_dpll() Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by: NMika Kuoppala <mika.kuoppala@intel.com> Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
-