- 15 Dec, 2015 1 commit
-
-
git://anongit.freedesktop.org/drm-intelDave Airlie authored
Last (very likely at least) drm-misc pull for 4.5. 3 big things: - piles of docs for kms vtables. - drm.debug dmesg output prettification from Ville (i915 parts are for 4.6 I think) - connector mode probing/validating/merging cleanup from Ville. [airlied : fix drm_encoder_init conflict.] * tag 'topic/drm-misc-2015-12-14' of git://anongit.freedesktop.org/drm-intel: (43 commits) drm: modes: Revert cc344980 "replace simple_strtoul by kstrtouint" drm: Expand the drm_helper_probe_single_connector_modes() docs drm: Allow override_edid to override the firmware EDID drm/sti: Drop bogus drm_mode_sort() call drm: Drop drm_helper_probe_single_connector_modes_nomerge() drm: Only merge mode type bits between new probed modes drm: Flatten drm_mode_connector_list_update() a bit drm: Rename MODE_UNVERIFIED to MODE_STALE drm: Don't overwrite UNVERFIED mode status to OK drm: Add plane->name and use it in debug prints drm: Add crtc->name and use it in debug messages drm: Use driver specified encoder name drm: Pass 'name' to drm_encoder_init() drm: Pass 'name' to drm_universal_plane_init() drm: Pass 'name' to drm_crtc_init_with_planes() drm: Documentation style guide drm: Document drm_encoder/crtc_helper_funcs drm: Move drm_display_mode an related docs into kerneldoc drm/atomic-helper: Mention the new system/resume helpers the docs drm: Document drm_connector_helper_funcs ...
-
- 14 Dec, 2015 30 commits
-
-
git://people.freedesktop.org/~robclark/linuxDave Airlie authored
Main thing this time around is DSI support for msm8960/apq8064, which should be helpful for getting an upstream kernel working on nexus7/nexus4/etc. * 'msm-next' of git://people.freedesktop.org/~robclark/linux: (29 commits) drm/msm/mdp: fix a problematic usage of WARN_ON() drm/msm/dsi: Added missing mutex_unlock drm/msm: ratelimit error irq msgs drm/msm: Use unlocked gem unreferencing drm/msm: trivial whitespace fix dt-bindings: msm/dsi: Add DSIv2 documentation dt-bindings: msm/dsi: Fix the order in which clocks are listed drm/msm/dsi: Enable MMSS SPFB port via syscon drm/msm/dsi: Don't use iommu for command TX buffer for DSIv2 drm/msm/dsi: Add dsi_cfg for APQ8064 drm/msm/dsi: Set up link clocks for DSIv2 drm/msm/dsi: Parse bus clocks from a list drm/msm/dsi: Delay dsi_clk_init drm/msm/dsi: Use a better way to figure out DSI version drm/msm/dsi: Add DSI PLL for 28nm 8960 PHY drm/msm/dsi: Add support for 28nm PHY on 8960 drm/msm/dsi: Don't get byte/pixel source clocks from DT drm/msm/mdp4: Initialize DSI encoders drm/msm/mdp4: Call custom round_pixclk helper only if the encoder type is TMDS drm/msm/dsi: Add a mdp4 encoder for DSI ...
-
Geliang Tang authored
WARN_ON() takes a condition rather than a format string. This patch converted WARN_ON() to WARN() instead. Signed-off-by:
Geliang Tang <geliangtang@163.com> Signed-off-by:
Rob Clark <robdclark@gmail.com>
-
saurabh authored
in case of failed to get iova, function was returning without releasing the mutex. Added it. Signed-off-by:
Saurabh Sengar <saurabh.truth@gmail.com> Signed-off-by:
-
Rob Clark authored
When things go bad and don't recover, we can be getting an err irq every vblank. Signed-off-by: -
Daniel Vetter authored
For drm_gem_object_unreference callers are required to hold dev->struct_mutex, which these paths don't. Enforcing this requirement has become a bit more strict with commit ef4c6270 Author: Daniel Vetter <daniel.vetter@ffwll.ch> Date: Thu Oct 15 09:36:25 2015 +0200 drm/gem: Check locking in drm_gem_object_unreference Cc: Rob Clark <robdclark@gmail.com> Signed-off-by:
Daniel Vetter <daniel.vetter@intel.com> Signed-off-by:
-
Rob Clark authored
Signed-off-by: -
Archit Taneja authored
Add additional property info needed for DSIv2 DT. Cc: devicetree@vger.kernel.org Cc: Rob Herring <robh@kernel.org> Acked-by:
Rob Herring <robh@kernel.org> Signed-off-by:
Archit Taneja <architt@codeaurora.org> Signed-off-by:
-
Archit Taneja authored
List the clocks in the order that's used in DT. We don't have mdp/dsi DT nodes for any SoC in upstream yet, but we align with the order we intend to use. Cc: devicetree@vger.kernel.org Cc: Rob Herring <robh@kernel.org> Acked-by:
-
Archit Taneja authored
For DSIv2 to work, we need to enable MMSS_AHB_ARB_MASTER_PORT in MMSS_SFPB. We enable the required bitfield by retrieving MMSS_SFPB regmap pointer via syscon. Signed-off-by:
-
Archit Taneja authored
We currently use iommu allocated DMA buffers for sending DSI commands. DSIv2 doesn't have a port connected to the MDP iommu. Therefore, it can't use iommu allocated buffers to fetch DSI commands. Use a regular contiguous DMA buffer if we are DSIv2. Signed-off-by:
-
Archit Taneja authored
Add a dsi_cfg entry for APQ8064. Since this is the first DSIv2 chip to be supported, add a list of bus clocks that are required by the DSIv2 block. Signed-off-by:
-
Archit Taneja authored
DSIv2 (DSI on older A family chips) has slightly different link clock requirements. First, we have an extra clock called src_clk (with a dedicated RCG). This is required by the DSI controller to process the pixel data coming from MDP. It needs to be set at the rate "pclk * bytes_per_pixel". We also need to explicitly configure esc_clk. On DSI6G chips, we don't need to set a rate to esc_clk because its RCG is always sourced from crystal clock (19.2 Mhz in all cases), which is within the escape clock frequency range in the mipi DSI spec. For chips with DSIv2, the crystal clock rate may not be within the required range (27Mhz on APQ8064). Therefore, we derive it from the DSI byte clock. We calculate an esc_clck rate that is within the mipi spec and also divisible by the byte clock rate. When setting rate and enabling the link clocks, we make sure that byte_clk is configured before esc_clk, and src_clk before pixel_clk. We create two different link_enable funcs for DSI6G and DSIv2 since the sequences are different. We also obtain two extra source clocks (dsi_src_clk and esc_src_clk) and set their parent to the clocks provided by DSI PLL. Signed-off-by:
-
Archit Taneja authored
DSI bus clocks seem to vary between different DSI host versions, and the SOC to which they belong. Even the enable/disable sequence varies. Provide a list of bus clock names in dsi_cfg. The driver will use this to retrieve the clocks, and enable/disable them. Add bus clock lists for DSI6G, and DSI for MSM8916(this is DSI6G too, but there is no MMSS_CC specific clock since there is no MMSS clock controller on 8916). Signed-off-by:
-
Archit Taneja authored
Initialize clocks only after we get the DSI host version. This will allow us to get clocks using a pre-defined list based on the DSI major/minor version of the host. This is required since clock requirements of different major DSI revisions(v2 vs 6g) aren't the same. Modify dsi_get_version to get the interface clock, and then put it after it is used. Signed-off-by:
-
Archit Taneja authored
The current version checking mechanism works fine for DSI6G blocks. It doesn't work so well for older generation DSIv2 blocks. The initial read of REG_DSI_6G_HW_VERSION(offset 0x0) would result in a read of REG_DSI_CTRL for DSIv2. This register won't necessarily be 0 on DSIv2. It can be non zero if DSI was previously initialized by the bootloader. Instead of reading offset 0x0, we now read offset 0x1f0. For DSIv2, this register is DSI_VERSION, and is bound to be non-zero. On DSI6G, this register(offset 0x1f0) is SCRATCH_REGISTER_0, which no one ever seems to touch, and from all register dumps I'vc seen, holds 0 all the time. Modify dsi_get_version to read REG_DSI_VERSION to determine whether we are DSI6G or DSIv2. Signed-off-by:
-
Archit Taneja authored
Add DSI PLL common clock framework clocks for 8960 PHY. The PLL here is different from the ones found in B family msm chips. As before, the DSI provides two clocks to the outside world. dsixpll and dsixpllbyte (x = 1, 2). dsixpll is a regular clock divider, but dsixpllbyte is modelled as a custom clock divider. dsixpllbyte is the starting point of the PLL configuration. It is the one that sets up the VCO clock rate. We need the VCO clock rate in the form: F * byteclk, where F is a multiplication factor that varies on the byte clock the DSI driver is trying to set. We use the custom clk_ops for dsixpllbyte to ensure that the parent (VCO) is set at this rate. An additional divider (POSTDIV1) generates the bitclk. Since bit clock can be derived from byteclock, we calculate it internally, and don't expose it as a clock. Cc: Stephen Boyd <sboyd@codeaurora.org> Signed-off-by:
-
Archit Taneja authored
DSI PHY on MSM8960 and APQ8064 is a 28nm PHY that's different from the supported 28nm LP PHY found in newer chips. Add support for the new PHY. Signed-off-by:
-
Archit Taneja authored
We retrieve the byte and pixel source clocks (RCG clocks) in the dsi driver via DT. These are needed so that we can re-parent these source clocks if we want to drive it using a different DSI PLL. We shouldn't get these via DT because they aren't clocks that directly serve as inputs to the dsi host. Fortunately, there is a static parent-child link between the byte_clk_src/pixel_clk_src and byte_clk/pixel_clk clocks. So, we can retrieve the source clocks via clk_get_parent. Do this instead of retrieving via DT. Cc: Rob Herring <robh@kernel.org> Cc: Stephen Boyd <sboyd@codeaurora.org> Signed-off-by:
-
Archit Taneja authored
Create DSI encoders during modeset_init. The 2 encoders should ideally be one command mode and one video mode DSI encoder respectively, but we don't support command mode yet. We just create 2 of the same because the dsi driver expects it, we end up using only the first one. Signed-off-by:
-
Archit Taneja authored
The mdp_kms round_pixclk op creates problems when we have more interfaces in use. It calls the DTV encoder's helper by default. Check on encoder type and call the corresponding encoder's func meant for rounding pixel clock. DSI and LVDS don't require rounding, so just return rate in their case. Signed-off-by:
-
Vinay Simha BN authored
Create an mdp4 incoder for DSI. Only DSI video mode is supported as of now. Signed-off-by:
Vinay Simha BN <vinaysimha@inforcecomputing.com> Signed-off-by:
-
Archit Taneja authored
Currently, the driver defers if it doesn't find a drm_panel. This forces us to have a drm_panel, if not, the driver isn't usable. Make the lcdc encoder initialization independent of the availability of the drm panel. We only check if there is a panel node specified in DT. If it isn't, then we don't initialize the encoder at all. The panel node is passed to the lcdc encoder and lvds connector drivers. The connector driver takes the responsibility to retrieve the drm_panel from the panel node, and update the status on whether the panel is connected or not. This makes the panel usable even if the drm_panel driver is inserted as a module later on. Signed-off-by:
-
Archit Taneja authored
modeset_init() for mdp4 isn't very flexible. That makes it hard to add more interfaces. Split out the encoder/connector creation code in modeset_init into a separate function. This is similar to what's done in modeset_init for mdp5. Signed-off-by:
-
Archit Taneja authored
Remove CONFIG_OF checks in adreno_device.c. The downstream bus scaling stuff is included only when CONFIG_OF is not set. So, remove that too. Signed-off-by:
-
Archit Taneja authored
We now only care about kernels that support DT. Remote the non-DT stuff. While we're at it, use of_device_get_match_data to retrieve match data. Signed-off-by:
-
Archit Taneja authored
We don't intend to use downstream non-DT kernels anymore, so remove CONFIG_OF checks. Update the TODO comment so that we don't forget about max_clk setting for non APQ8064 chips having MDP4. Signed-off-by:
-
Archit Taneja authored
Update DT bindings for mdp. We now have a more uniform and future-proof set of compatible strings. MDP5 bindings were missing. Add those and update details on the clock-names properties. Signed-off-by:
-
Archit Taneja authored
Create distinct compatible strings for mdp4 and mdp5. Keep "qcom,mdss_mdp" as is to support downstream kernels. Signed-off-by:
-
Archit Taneja authored
Support for non-DT kernels was mainly to use v3.4 downstream kernels. This is no longer a priority now as we have reasonable support upstream. Remove CONFIG_OF from the top level msm_drv.c file. While we're at it, clean up the data matching process using of_device_get_match_data. Signed-off-by:
-
Archit Taneja authored
MDP5 has line count and frame count registers for each interface. Enable these counters and use them to implement the get_vblank_timestamp drm driver op. The line counter starts with the value 1 at the beginning of the VSYNC pulse and ends with value VTOTAL at the end of VFP. This value is used to determine whether we're in blanking period or not, and an adjusted value of this counter is used to get vpos as expected by get_scanout_position. Since there is no way to calculate hpos, we always set it to 0. Signed-off-by:
-
- 11 Dec, 2015 9 commits
-
-
LABBE Corentin authored
My latest commit introduce some case where a valid mode, could be rejected. simple_strtox functions stop at first non-digit character, but kstrtox not. So args like "video=HDMI-A-1:720x480-16@60" will be reject when checking 16@. Discussions about this change comes to the conclusion that the best solution is to revert my commit cc344980. Signed-off-by:
LABBE Corentin <clabbe.montjoie@gmail.com> Signed-off-by:
Daniel Vetter <daniel.vetter@ffwll.ch> Link: http://patchwork.freedesktop.org/patch/msgid/1449838739-29969-1-git-send-email-clabbe.montjoie@gmail.com
-
Ville Syrjälä authored
Describe the procedure that drm_helper_probe_single_connector_modes() uses to do it's work in the kernel-doc comment. Caveat: Looks like crap and trying to reverse engineer the documentation tools is not something I want to do. Suggested-by:
Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by:
-
Ville Syrjälä authored
IMO the override_edid should override any default EDID for the connector, whether that came in via the connector helper ->get_modes() vfunc or via the firmware EDID mechanism. Cc: Thomas Wood <thomas.wood@intel.com> Signed-off-by:
-
Ville Syrjälä authored
sti seems confused about which mode list is used in its .get_modes() hook. It adds the modes to the probed_modes list (as is appropriate) but then for some reason it tries to sort the old mode list. Just drop the sorting since it does nothing, and let the probe helper do its thing. It will sort the final mode list after merging in the modes from the probed_modes list and validating them. Cc: Benjamin Gaignard <benjamin.gaignard@linaro.org> Cc: Vincent Abriou <vincent.abriou@st.com> Signed-off-by:
-
Ville Syrjälä authored
Now that the mode type bit merge logic is fixed to only merge between new probed modes, hopefully we can eliminat the special case for qxl and virtio. That is make the merge the mode type bits from all matching new probed modes, just like every other driver. qxl and virtio got excluded from the merging in commit 3fbd6439 ("drm: copy mode type in drm_mode_connector_list_update()") commit abce1ec9 ("Revert "drm: copy mode type in drm_mode_connector_list_update()"") commit b87577b7 ("drm: try harder to avoid regression when merging mode bits") Cc: Marc-André Lureau <marcandre.lureau@redhat.com> Cc: Dave Airlie <airlied@redhat.com> Cc: Daniel Vetter <daniel.vetter@ffwll.ch> Cc: Adam Jackson <ajax@redhat.com> Signed-off-by:
-
Ville Syrjälä authored
Currently most drivers request that any mode appearing on both the old mode list and the new probed_modes list get their type bits ORed together if the modes are deemed to otherwise match each other. I don't know why anyone would want to merge in the mode type bits from any mode left over from a previous probe. For instance, you could never get rid of ther preferred bit if a matching non-preferred mode is returned by the new probe. So let's not merge anything from the stale old modes, and just replace them outright with matching new modes. If multiple matching modes are produced by the same probe, merging the type bits between them would seem like a sensible thing to do. For a bit of extra finesse if two modes are considered equal we can pick the actual timings from the one marked as preferrred. And if multiple preferred modes are produced by the same probe somehow, we can just favor the first one added to the probed_modes list. You may be asking yourself why we bother with the merging at all if nothing from the old list survives in practice. The only answer I have is "debug output". That is we want to print out a list of pruned modes, which is why we still want to look for duplicates with the old modes. There was a previous attempt to get rid of the mode type merging entirely, but it caused some kind of regression on Daniels's G33 machine. Apparently the sdvo transcoder on said machine started to die at around the same time and has since rotted away totally, so it may have been a red herring. So we don't have to worry about it anymore. The relevant commits are: commit 3fbd6439 ("drm: copy mode type in drm_mode_connector_list_update()") commit abce1ec9 ("Revert "drm: copy mode type in drm_mode_connector_list_update()"") It was then decided in commit b87577b7 ("drm: try harder to avoid regression when merging mode bits") that just qxl virtio are excluded from the merging, while everyone else does it. That is not changed, although now even qxl and virtio will be subject to the previously mentioned logic to choose which actual timings are picked for the new mode. v2: Fix typos in commit message, and clarify the details on the G33 regression from the previous attempt (Daniel) Cc: Marc-André Lureau <marcandre.lureau@redhat.com> Cc: Dave Airlie <airlied@redhat.com> Cc: Daniel Vetter <daniel.vetter@ffwll.ch> Cc: Adam Jackson <ajax@redhat.com> Signed-off-by:
-
Ville Syrjälä authored
Use 'continue' to eliminate one indent level from drm_mode_connector_list_update(). And while at it, make 'found_it' bool. Cc: Adam Jackson <ajax@redhat.com> Signed-off-by:
-
Ville Syrjälä authored
MODE_UNVERIFIED actually means that the mode came from a previous probe, and if the new probe doesn't produce a matching mode it will get pruned from the list. Rename the flag to MODE_STALE to better convey the meaning. v2: Rebased due to conflicts with Daniel's doc stuff Cc: Adam Jackson <ajax@redhat.com> Signed-off-by:
-
Ville Syrjälä authored
The way the mode probing works is this: 1. All modes currently on the mode list are marked as UNVERIFIED 2. New modes are on the probed_modes list (they start with status OK) 3. Modes are moved from the probed_modes list to the actual mode list. If a mode already on the mode list is deemed to match one of the probed modes, the duplicate is dropped and the mode status updated to OK. After this the probed_modes list will be empty. 4. All modes on the mode list are verified to not violate any constraints. Any that do are marked as such. 5. Any mode left with a non-OK status is pruned from the list, with an appropriate debug message. What all this means is that any mode on the original list that didn't have a duplicate on the probed_modes list, should be left with status UNVERFIED (or previously could have been left with some other status, but never OK). I broke that in commit 05acaec3 ("drm: Reorganize probed mode validation") by always assigning something to the mode->status during the validation step. So any mode from the old list that still passed the validation would be left on the list with status OK in the end. Fix this by not doing the basic mode validation unless the mode already has status OK (meaning it came from the probed_modes list, or at least a duplicate of it was on that list). This way we will correctly prune away any mode from the old mode list that didn't appear on the probed_modes list. Cc: stable@vger.kernel.org Cc: Adam Jackson <ajax@redhat.com> Fixes: 05acaec3 ("drm: Reorganize probed mode validation") Signed-off-by:
-
