This isuue got introduced in -
commit 24ee0e6490
Author: Gaurav K Singh <gaurav.k.singh@intel.com>
Date: Fri Dec 5 14:24:21 2014 +0530
drm/i915: Update the DSI enable path to support dual
Signed-off-by: Shobhit Kumar <shobhit.kumar@intel.com>
Reviewed-by: Jani Nikula <jani.nikula@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
The removed functions can be resurrected in intel_dsi.c as need arises.
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Reviewed-By: Shobhit Kumar <shobhit.kumar@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
No functional changes.
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Reviewed-By: Shobhit Kumar <shobhit.kumar@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Add basic support for using the drm mipi dsi framework for DSI. We don't
use device tree which is pretty much required by mipi_dsi_host_register
and friends, and we don't have the kind of device model the functions
expect either. So we cheat and use it as a library to abstract what we
need: a nice, clean interface for DSI transfers. This means we will have
to be careful with what functions we call, as the driver model devices
in mipi_dsi_host and mipi_dsi_device will *not* be initialized.
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Reviewed-By: Shobhit Kumar <shobhit.kumar@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Replace intel_dsi_device and intel_dsi_dev_ops with drm_panel and
drm_panel_funcs. They are adequate for what we have now, and if we end
up needing more than this we should improve drm_panel. This will keep us
better aligned with the drm core infrastructure.
The panel driver initialization changes a bit. It still remains hideous,
but fixing that is beyond the scope here.
v2: extend mode config mutex to cover drm_panel_get_modes (Shobhit)
vbt_panel->intel_dsi = intel_dsi in vbt panel init (Shobhit)
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Reviewed-By: Shobhit Kumar <shobhit.kumar@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Even though we only support atomic plane updates at the moment, we still
need to add an .atomic_get_property() entrypoint for connectors before
we allow the driver to flip on the DRIVER_ATOMIC bit. As soon as that
bit gets set, the DRM core will start adding atomic connector properties
(in addition to the plane properties we care about at the moment), so we
need to be able to handle the new way the DRM core will interact with
us.
For simplicity, we just lookup driver-specific connector properties in
the usual shadow array maintained by the core. Once we get real atomic
modeset support for crtc's and planes, this code should be re-written to
pull the data out of crtc/connector state structures.
v2: Fix intel_dvo and intel_dsi that I missed on the first pass (Ander)
Signed-off-by: Matt Roper <matthew.d.roper@intel.com>
Reviewed-by: Ander Conselvan de Oliveira <conselvan2@gmail.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
We want to enable/test plane updates via the atomic interface, but as
soon as we flip DRIVER_ATOMIC on, the DRM core will take some atomic
codepaths to lookup properties during drmModeGetConnector() and some of
those codepaths unconditionally dereference connector->state
(specifically when looking up the CRTC ID property in
drm_atomic_connector_get_property()). Create a dummy connector state
for each connector at init time to ensure the DRM core doesn't try to
dereference a NULL connector->state. The actual connector properties
will never be updated or contain useful information, but since we're
doing this specifically for testing/debug of the plane operations (and
only when a specific kernel module option is given), that shouldn't
really matter.
Once we start creating connector states, the DRM core will want to be
able to clean them up for us. We also need to hook up the destruction
entrypoint to the core's helper.
v2: Squash in the patch to set the state destruction hook (Ander & Bob)
v3: Only create dummy connector states when we're actually faking
atomic support. (Ander)
Signed-off-by: Matt Roper <matthew.d.roper@intel.com>
Reviewed-by: Ander Conselvan de Oliveira <conselvan2@gmail.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Remove all the trivial and/or dummy callbacks from intel dsi device
ops. Merge send_otp_cmds into panel_reset as they're called back to
back.
This will be helpful for switching to use drm_panel for the
callbacks. If we ever need the additional callbacks, we should add them
to drm_panel funcs.
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Reviewed-By: Shobhit Kumar <shobhit.kumar@intel.com>
[danvet: Resolve tiny conflict with ongoing atomic work.]
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Add port parameter to wait_for_dsi_fifo_empty, and call it for each dsi
port.
We can now remove the transitional intel_dsi_pipe_to_port() function.
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Reviewed-By: Shobhit Kumar <shobhit.kumar@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
wait_for_dsi_fifo_empty can be static in intel_dsi.c. No functional
changes.
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Reviewed-By: Shobhit Kumar <shobhit.kumar@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
This seems like the right thing to do. This also gets rid of a call to
intel_dsi_pipe_to_port() which we want to remove eventually.
v2: add braces to fix else logic (Shobhit)
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Reviewed-By: Shobhit Kumar <shobhit.kumar@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Instead of having the for each dsi port loop within dpi_send_cmd(), add
a port parameter to the function and call it for each port instead.
This is a rewrite of
commit 4510cd779e
Author: Gaurav K Singh <gaurav.k.singh@intel.com>
Date: Thu Dec 4 10:58:51 2014 +0530
drm/i915: Dual link needs Shutdown and Turn on packet for both ports
to add more flexibility in using dpi_send_cmd() for just one port as
necessary. No functional changes.
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Reviewed-By: Shobhit Kumar <shobhit.kumar@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
To match the semantics of drm_crtc->state, which this will eventually
become. The allocation of the memory for config will be fixed in a
followup patch. By adding the extra _config field to intel_crtc it was
possible to generate this entire patch with the cocci script below.
@@ @@
struct intel_crtc {
...
-struct intel_crtc_state config;
+struct intel_crtc_state _config;
+struct intel_crtc_state *config;
...
}
@@ struct intel_crtc *crtc; @@
-memset(&crtc->config, 0, sizeof(crtc->config));
+memset(crtc->config, 0, sizeof(*crtc->config));
@@ @@
__intel_set_mode(...) {
<...
-to_intel_crtc(crtc)->config = *pipe_config;
+(*(to_intel_crtc(crtc)->config)) = *pipe_config;
...>
}
@@ @@
intel_crtc_init(...) {
...
WARN_ON(drm_crtc_index(&intel_crtc->base) != intel_crtc->pipe);
+intel_crtc->config = &intel_crtc->_config;
return;
...
}
@@ struct intel_crtc *crtc; @@
-&crtc->config
+crtc->config
@@ struct intel_crtc *crtc; identifier member; @@
-crtc->config.member
+crtc->config->member
@@ expression E; @@
-&(to_intel_crtc(E)->config)
+to_intel_crtc(E)->config
@@ expression E; identifier member; @@
-to_intel_crtc(E)->config.member
+to_intel_crtc(E)->config->member
v2: Clarify manual changes by splitting them into another patch. (Matt)
Improve cocci script to generate even more of the changes. (Ander)
Signed-off-by: Ander Conselvan de Oliveira <ander.conselvan.de.oliveira@intel.com>
Reviewed-by: Matt Roper <matthew.d.roper@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
The objective is to make this structure usable with the atomic helpers,
so let's start with the rename. Patch generated with coccinelle:
@@ @@
-struct intel_crtc_config {
+struct intel_crtc_state {
...
}
@@ @@
-struct intel_crtc_config
+struct intel_crtc_state
v2: Completely generate the patch with cocci. (Ander)
Signed-off-by: Ander Conselvan de Oliveira <ander.conselvan.de.oliveira@intel.com>
Reviewed-by: Matt Roper <matthew.d.roper@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Due to hardware limitations on BYT, MIPI Port C DPI Enable bit
does not get set. To check whether DSI Port C was enabled in BIOS,
check the Pipe B enable bit for DSI Port C. In hardware, DSI Port C
is linked with Pipe B.
v2: Addressed review comments of Jani, Nikula
- Used platform checks for this software workaround for BYT
Signed-off-by: Gaurav K Singh <gaurav.k.singh@intel.com>
Reviewed-by: Jani Nikula <jani.nikula@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Common bit to be used for both DSI Port A & DSI Port C.
Signed-off-by: Gaurav K Singh <gaurav.k.singh@intel.com>
Reviewed-by: Jani Nikula <jani.nikula@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
We need to program both port registers during dual link enable path.
v2: Address review comments by Jani
- Used a for loop instead of do-while loop.
v3: Used for_each_dsi_port macro instead of for loop
v4: Renamed mode_hactive variable to mode_hdisplay
Signed-off-by: Gaurav K Singh <gaurav.k.singh@intel.com>
Signed-off-by: Shobhit Kumar <shobhit.kumar@intel.com>
Reviewed-by: Jani Nikula <jani.nikula@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
We need to program both port registers during dual link disable path.
v2: Address review comments by Jani
- Used a for loop instead of do-while loop.
v3: Used for_each_dsi_port macro instead of for loop
v4: Added comments for the usage of AFE latchout bit
Signed-off-by: Gaurav K Singh <gaurav.k.singh@intel.com>
Signed-off-by: Shobhit Kumar <shobhit.kumar@intel.com>
Reviewed-by: Jani Nikula <jani.nikula@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
hactive, hfp, hbp, hsync needs to be halved for dual link MIPI Panels.
Accordingly timing related mmio regs needs to be programmed for both MIPI Ports.
v2: Address review comments by Jani
- Used a for loop instead of do-while loop
v3: Used for_each_dsi_port macro instead of for loop
Signed-off-by: Gaurav K Singh <gaurav.k.singh@intel.com>
Signed-off-by: Shobhit Kumar <shobhit.kumar@intel.com>
Reviewed-by: Jani Nikula <jani.nikula@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
For dual link MIPI Panels, each port needs half of pixel clock. Pixel overlap
can be enabled if needed by panel, then in that case, pixel clock will be
increased for extra pixels.
v2 : Address review comments by Jani
- Removed the bit mask used for ->dual_link
- Used DSI instead of MIPI for #define variables
v3: Added the VLV_DISPLAY_BASE to VLV_CHICKEN_3 register
Signed-off-by: Gaurav K Singh <gaurav.k.singh@intel.com>
Signed-off-by: Shobhit Kumar <shobhit.kumar@intel.com>
Reviewed-by: Jani Nikula <jani.nikula@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
For Dual Link MIPI Panels, both Port A and Port C should be enabled
during the MIPI encoder enabling sequence. Similarly, during the
disabling sequence, both ports needs to be disabled.
v2: Used for_each_dsi_port macro instead of for loop
v3: Used intel_dsi->ports instead of dual_link var for dual link configuration check
v4: Masking of the required MIPI port bits before writing proper values
Signed-off-by: Gaurav K Singh <gaurav.k.singh@intel.com>
Signed-off-by: Shobhit Kumar <shobhit.kumar@intel.com>
Reviewed-by: Jani Nikula <jani.nikula@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
This patch is in preparation for the DSI dual link
port enable and disable related changes.
Signed-off-by: Gaurav K Singh <gaurav.k.singh@intel.com>
Signed-off-by: Shobhit Kumar <shobhit.kumar@intel.com>
Reviewed-by: Jani Nikula <jani.nikula@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Later on this can include multiple ports (e.g. (1 << PORT_A) | (1 <<
PORT_C)) to describe dual link DSI.
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Reviewed-by: Gaurav K Singh <gaurav.k.singh@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
MIPI DSI works on ports A and C, which map to pipes A and B,
respectively. Things are going to get more complicated with the
introduction of dual link DSI support, so clean up the register defines
and code to match reality.
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Reviewed-by: Gaurav K Singh <gaurav.k.singh@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
- fini goes with init, so call it intel_power_domains_fini. While
at it shovel some of the fini code that leaked out of it back in.
- give power_enabled functions the verb _is_ to make the meaning clearer.
Also use a __ prefix instead of _unlocked to really discourage users.
- rename runtime_pm_init/fini to enable/disable since that's what they do.
Reviewed-by: Imre Deak <imre.deak@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
I'm not really that insisting on checkpath compliance, but ragged
function paramter alignment does get me. Please adjust your editor to
just do this for you.
Cc: Shobhit Kumar <shobhit.kumar@intel.com>
Cc: Imre Deak <imre.deak@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
v2: Updated the error log as suggested by Imre
Signed-off-by: Shobhit Kumar <shobhit.kumar@intel.com>
Reviewed-by: Imre Deak <imre.deak@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Check in vlv_crtc_clock_get if DPLL is enabled before calling dpio read.
It will not be enabled for DSI and avoid dpio read WARN dumps.
Absence of ->get_config was causing other WARN dumps as well. Update
dpll_hw_state as well correctly
v2: Address review comments by Daniel
- Check if DPLL is enabled rather than checking pipe output type
- set adjusted_mode->flags to 0 in compute_config rather than using
pipe_config->quirks
- Add helper function in intel_dsi_pll.c and use that in intel_dsi.c
- updated dpll_hw_state correctly
- Updated commit message and title
v3: Address review comments by Imre
- Proper masking of P1, M1 fields while computing divisors
- assert in case of bpp mismatch
- guard for divide by 0 while computing pclk
- Use ARRAY_SIZE instead of direct calculation
Signed-off-by: Shobhit Kumar <shobhit.kumar@intel.com>
Reviewed-by: Imre Deak <imre.deak@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Ensure that the DSI packets for a particular sequence are completely
sent before going ahead in the enabling or disabling of the panel
Signed-off-by: Shobhit Kumar <shobhit.kumar@intel.com>
Reviewed-by: Imre Deak <imre.deak@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
We should keep DEVICE_READY bit set in the ULPS enter sequence. In
exit sequence also we should set DEVICE_READY, but thats causing
blankout for me. Also exit sequence is simplified as per hw team
recommendation.
This should fix -
[drm:intel_dsi_clear_device_ready] *ERROR* DSI LP not going Low
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=80818
Signed-off-by: Shobhit Kumar <shobhit.kumar@intel.com>
Tested-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
- Accurate frontbuffer tracking and frontbuffer rendering invalidate, flush and
flip events. This is prep work for proper PSR support and should also be
useful for DRRS&fbc.
- Runtime suspend hardware on system suspend to support the new SOix sleep
states, from Jesse.
- PSR updates for broadwell (Rodrigo)
- Universal plane support for cursors (Matt Roper), including core drm patches.
- Prefault gtt mappings (Chris)
- baytrail write-enable pte bit support (Akash Goel)
- mmio based flips (Sourab Gupta) instead of blitter ring flips
- interrupt handling race fixes (Oscar Mateo)
And old, not yet merged features from the previous round:
- rps/turbo support for chv (Deepak)
- some other straggling chv patches (Ville)
- proper universal plane conversion for the primary plane (Matt Roper)
- ppgtt on vlv from Jesse
- pile of cleanups, little fixes for insane corner cases and improved debug
support all over
* tag 'drm-intel-next-2014-06-20' of git://anongit.freedesktop.org/drm-intel: (99 commits)
drm/i915: Update DRIVER_DATE to 20140620
drivers/i915: Fix unnoticed failure of init_ring_common()
drm/i915: Track frontbuffer invalidation/flushing
drm/i915: Use new frontbuffer bits to increase pll clock
drm/i915: don't take runtime PM reference around freeze/thaw
drm/i915: use runtime irq suspend/resume in freeze/thaw
drm/i915: Properly track domain of the fbcon fb
drm/i915: Print obj->frontbuffer_bits in debugfs output
drm/i915: Introduce accurate frontbuffer tracking
drm/i915: Drop schedule_back from psr_exit
drm/i915: Ditch intel_edp_psr_update
drm/i915: Drop unecessary complexity from psr_inactivate
drm/i915: Remove ctx->last_ring
drm/i915/chv: Ack interrupts before handling them (CHV)
drm/i915/bdw: Ack interrupts before handling them (GEN8)
drm/i915/vlv: Ack interrupts before handling them (VLV)
drm/i915: Ack interrupts before handling them (GEN5 - GEN7)
drm/i915: Don't BUG_ON in i915_gem_obj_offset
drm/i915: Grab dev->struct_mutex in i915_gem_pageflip_info
drm/i915: Add some L3 registers to the parser whitelist
...
Conflicts:
drivers/gpu/drm/i915/i915_drv.c
Introduce generic functions to register and unregister connectors. This
provides a common place to add and remove associated user space
interfaces.
Signed-off-by: Thomas Wood <thomas.wood@intel.com>
Reviewed-by: David Herrmann <dh.herrmann@gmail.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
intel_dsi_init() bails out without freeing the memory 'intel_dsi' and
'intel_connector' point to. Simply bail out before allocating memory.
Picked up by Coverity - CID 1222750.
Signed-off-by: Christoph Jaeger <christophjaeger@linux.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Functions that can't fail are such a bliss to work with, it'd be shame
to miss the occasion. The "failure" mode is the DSI connector not being
created, the rest of the initialization can carry on happily.
We weren't even checking that value anyway.
Suggested-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Suggested-by: Shobhit Kumar <shobhit.kumar@intel.com>
Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Cc: Shobhit Kumar <shobhit.kumar@intel.com>
Signed-off-by: Damien Lespiau <damien.lespiau@intel.com>
[danvet: Also convert the missed return statement due to other patches
merged meanwhile.]
[danvet2: Squash in fixup from Damien to remove empty return; at the
end of intel_dsi_init.]
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
If we disable first the port (by disabling DPI) and only then the
display pipe the pipe-off flag will never be set, possibly leading to a
hanged pipe state at the next modeset-enable.
Note that according to the VLV2 display cluster HAS, we should disable
the port before the pipe. This doesn't seem to match reality based on
the above and it's also asymmetric with the enabling sequence, where we
first enable the port and then the pipe.
v2:
- send the panel shutdown command before stopping the pipe, since this
is the recommended sequence (Shobhit)
Signed-off-by: Imre Deak <imre.deak@intel.com>
Reviewed-by: Shobhit Kumar <shobhit.kumar@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
It seems by default the VBT has MIPI configuration block as well. The
Generic driver will assume always MIPI if MIPI configuration block is found.
This is causing probelm when actually there is eDP. Fix this by looking
into general definition block which will have device configurations. From here
we can figure out what is the LFP type and initialize MIPI only if MIPI
is found.
v2: Addressed review comments by Damien
- Moved PORT definitions to intel_bios.h and renamed as DVO_PORT_MIPIA
- renamed is_mipi to has_mipi and moved definition as suggested
- Check has_mipi inside parse_mipi and intel_dsi_init insted of outside
v3: Make has_mipi as a bitfield as suggested
Signed-off-by: Shobhit Kumar <shobhit.kumar@intel.com>
Reviewed-by: Damien Lespiau <damien.lespiau@intel.com>
[danvet: fold in conditions to pack everything neatly below 80 chars.]
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
This driver makes use of the generic panel information from the VBT.
Panel information is classified into two - panel configuration and panel
power sequence which is unique to each panel. The generic driver uses the
panel configuration and sequence parsed from VBT block #52 and #53
v2: Address review comments by Jani
- Move all of the things in driver c file from header
- Make all functions static
- Make use of video/mipi_display.c instead of redefining
- Null checks during sequence execution
v3: Address review comments by Damien
- Rename the panel driver file as intel_dsi_panel_vbt.c
- Fix style changes as suggested
- Correct comments for lp->hs and hs->lp count calculations
- General updating comments to have more clarity
- using max() instead of ternary operator
- Fix names (ui_num, ui_den) while using UI in calculations
- compute max of lp_to_hs switch and hs_to_lp switch while computing
hs_lp_switch_count
Signed-off-by: Shobhit Kumar <shobhit.kumar@intel.com>
Reviewed-by: Damien Lespiau <damien.lespiau@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
This patch adds a mmio base address variable for DSI display,
to make the DSI code generic, so that, if required, the same code
can be re-used for future platforms with different mmio base.
Signed-off-by: Shashank Sharma <shashank.sharma@intel.com>
Reviewed-by: Damien Lespiau <damien.lespiau@intel.com>
[danvet: Appease checkpatch.]
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Looking at our current dsi driver I note that:
- We don't have any slave driver right now.
- There's zero support for the hardware state readout and cross check
code.
- All the modeset state seems to be tracked in the intel_dsi structure
instead of the pipe config.
Given all that I can't properly audit the dsi ->mode_set callback. So
just do it as the first thing in the ->pre_pll_enable hook and hope
for the best.
Reviewed-by: Imre Deak <imre.deak@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Added as generic parameters which will be initialized in the panel
driver and are specific to panels.
Backlight delays have also kept as placeholders and will be used used
once we have MIPI backlight enabling support
Signed-off-by: Shobhit Kumar <shobhit.kumar@intel.com>
Reviewed-by: Damien Lespiau <damien.lespiau@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
In VBT fields operation mode is 0 for Video mode and 1 for command mode.
This field will be directly used as is in generic panel driver. So
adjust accordingly.
Signed-off-by: Shobhit Kumar <shobhit.kumar@intel.com>
Reviewed-by: Damien Lespiau <damien.lespiau@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Some MIPI panels might not have resolution which is a multiple of 64 like
1366x768. Enable this feature for such panels by default
Signed-off-by: Shobhit Kumar <shobhit.kumar@intel.com>
Reviewed-by: Jani Nikula <jani.nikula@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Though HS mode also should work.
v2: Change parameter as "bool hs" as suggested by Jani
Signed-off-by: Shobhit Kumar <shobhit.kumar@intel.com>
Reviewed-by: Jani Nikula <jani.nikula@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
In preparation for Generic driver
Signed-off-by: Shobhit Kumar <shobhit.kumar@intel.com>
Reviewed-by: Jani Nikula <jani.nikula@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Otherwise, this can stall pipe. We also need DPLL REFA always
enabled
Signed-off-by: Shobhit Kumar <shobhit.kumar@intel.com>
Reviewed-by: Jani Nikula <jani.nikula@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
As per the hw team's recommendation we need to enable the MIPI port
before enabling the plane and pipe. So call MIPI port enable in
pre_enable phase itself
Signed-off-by: Shobhit Kumar <shobhit.kumar@intel.com>
Reviewed-by: Jani Nikula <jani.nikula@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
