- 23 10月, 2015 11 次提交
-
-
由 Archit Taneja 提交于
DRM_MSM_FBDEV config is used to enable/disable fbdev emulation for the msm kms driver. Replace this with the top level DRM_FBDEV_EMULATION config option where applicable. This also prevents build breaks caused by undefined drm_fb_helper_* functions when legacy fbdev support was disabled. Signed-off-by: NArchit Taneja <architt@codeaurora.org> Signed-off-by: NRob Clark <robdclark@gmail.com>
-
由 Stephane Viau 提交于
This change adds the basic MDP5 support for MSM8996. Signed-off-by: NStephane Viau <sviau@codeaurora.org> Signed-off-by: NRob Clark <robdclark@gmail.com>
-
由 Stephane Viau 提交于
In order to produce an image, the scalar needs to be fed extra pixels. These top/bottom/left/right values depend on a various of factors, including resolution, scaling type, phase step and initial phase. Pixel Extension are programmed by hardware in most targets - and can be overwritten by software. For some targets (e.g.: msm8996), software *must* program those registers. In order to ease this computation, let's always use bilinear filters, which are easier to program from kernel. Eventually, all of these values will come down from user space for better quality. Signed-off-by: NStephane Viau <sviau@codeaurora.org> Signed-off-by: NRob Clark <robdclark@gmail.com>
-
由 Stephane Viau 提交于
When calculating phase steps, let's use the same enum mdp_component_type in order to ease the readability; 0/1 indexes are a bit confusing and we now have explicit values to index this type of arrays. Signed-off-by: NStephane Viau <sviau@codeaurora.org> Signed-off-by: NRob Clark <robdclark@gmail.com>
-
由 Stephane Viau 提交于
The HDMI controller is new in MDP5 v1.7. As of now, this change doesn't reflect the novelty and only adds the basics so the probe gets triggered. Signed-off-by: NStephane Viau <sviau@codeaurora.org> Signed-off-by: NRob Clark <robdclark@gmail.com>
-
由 Stephane Viau 提交于
The current behavior is to try to get optional clocks and print a dev_err message in case of failure. This looks rather confusing and may increase with the amount of optional clocks. We may need a cleaner way to handle per-device clocks but in the meantime, let's reduce the amount of dev_err messages during the probe. Signed-off-by: NStephane Viau <sviau@codeaurora.org> Signed-off-by: NRob Clark <robdclark@gmail.com>
-
由 Stephane Viau 提交于
msm_iommu_new() can fail and this change makes sure that we detect the failure and free the allocated domain before going any further. Signed-off-by: NStephane Viau <sviau@codeaurora.org> Signed-off-by: NRob Clark <robdclark@gmail.com>
-
由 Stephane Viau 提交于
We want to make sure we control all the information being passed down to SMP block. Having access to the cfg pointer here may create bad things in the future. Signed-off-by: NStephane Viau <sviau@codeaurora.org> Signed-off-by: NRob Clark <robdclark@gmail.com>
-
由 Hai Li 提交于
The current settings for 28nm PHY data lane CFG4 registers do not work with certain panels. This change is to modify them to hw recommended values. Signed-off-by: NHai Li <hali@codeaurora.org> Signed-off-by: NRob Clark <robdclark@gmail.com>
-
由 Bjorn Andersson 提交于
In some configurations the supplies are voltage switches and not LDOs, making the set voltage call to fail. Check with the regulator framework if the supply can change voltage before attempting. Signed-off-by: NBjorn Andersson <bjorn.andersson@sonymobile.com> Reviewed-by: NArchit Taneja <architt@codeaurora.org> Signed-off-by: NRob Clark <robdclark@gmail.com>
-
由 Rob Clark 提交于
Signed-off-by: NRob Clark <robdclark@gmail.com>
-
- 22 10月, 2015 11 次提交
-
-
由 Christian König 提交于
That's still small enough to not waste to much memory on PD/PTs. Signed-off-by: NChristian König <christian.koenig@amd.com> Reviewed-by: NAlex Deucher <alexander.deucher@amd.com>
-
由 Samuel Li 提交于
Signed-off-by: NSamuel Li <samuel.li@amd.com> Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>
-
由 Samuel Li 提交于
Add core VI enablement for Stoney. Signed-off-by: NSamuel Li <samuel.li@amd.com> Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>
-
由 Samuel Li 提交于
Stoney is VCE 3.x single. v2: Stoney is single pipe like Fiji Signed-off-by: NSamuel Li <samuel.li@amd.com> Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>
-
由 Samuel Li 提交于
Stoney is UVD 6.x. Signed-off-by: NSamuel Li <samuel.li@amd.com> Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>
-
由 Samuel Li 提交于
Stoney is GFX 8.1. v2: update to latest golden settings Signed-off-by: NSamuel Li <samuel.li@amd.com> Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>
-
由 Samuel Li 提交于
Stoney is SDMA 3.x. v2: update to latest golden register settings Signed-off-by: NSamuel Li <samuel.li@amd.com> Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>
-
由 Samuel Li 提交于
Stoney is DCE 11.x. Signed-off-by: NSamuel Li <samuel.li@amd.com> Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>
-
由 Samuel Li 提交于
Stoney is SMC 8.x. Signed-off-by: NSamuel Li <samuel.li@amd.com> Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>
-
由 Samuel Li 提交于
Stoney is GMC 8.x. Signed-off-by: NSamuel Li <samuel.li@amd.com> Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>
-
由 Samuel Li 提交于
Stoney is based on Carrizo with some IP upgrades. Signed-off-by: NSamuel Li <samuel.li@amd.com> Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>
-
- 21 10月, 2015 12 次提交
-
-
由 Laurent Pinchart 提交于
The R8A7794 DU has a fixed output routing configuration with one RGB output per CRTC and thus lacks the RGB output routing register field. Signed-off-by: NLaurent Pinchart <laurent.pinchart+renesas@ideasonboard.com>
-
由 Laurent Pinchart 提交于
The R8A7793 DU is identical to the R8A7791 and thus only requires a new DT compatible string. Signed-off-by: NLaurent Pinchart <laurent.pinchart+renesas@ideasonboard.com>
-
由 Chunming Zhou 提交于
fix the vm->mutex and ww_mutex confilcts. vm->mutex is always token first, then ww_mutex. V2: remove unneccessary checking for pt bo. Change-Id: Iea56e183752c02831126d06d2f5b7a474a6e4743 Signed-off-by: NChunming Zhou <david1.zhou@amd.com> Reviewed-by: NChristian König <christian.koenig@amd.com>
-
由 Junwei Zhang 提交于
Signed-off-by: NJunwei Zhang <Jerry.Zhang@amd.com> Reviewed-by: NChristian König <christian.koenig@amd.com>
-
由 Christian König 提交于
Finally getting rid of it. Signed-off-by: NChristian König <christian.koenig@amd.com>
-
由 Christian König 提交于
It didn't worked to well anyway. Signed-off-by: NChristian König <christian.koenig@amd.com> Reviewed-by: NChunming Zhou <david1.zhou@amd.com> Reviewed-by: NJunwei Zhang <Jerry.Zhang@amd.com>
-
由 Geliang Tang 提交于
s/regsiter/register/ Signed-off-by: NGeliang Tang <geliangtang@163.com> Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>
-
由 Derek Foreman 提交于
Signed-off-by: NDerek Foreman <derekf@osg.samsung.com> Signed-off-by: NEric Anholt <eric@anholt.net>
-
由 Derek Foreman 提交于
Keep the fbdev_cma pointer around so we can use it on hotplog and close to ensure the frame buffer console is in a useful state. Signed-off-by: NDerek Foreman <derekf@osg.samsung.com> Signed-off-by: NEric Anholt <eric@anholt.net>
-
由 Eric Anholt 提交于
This is enough for fbcon and bringing up X using xf86-video-modesetting. It doesn't support the 3D accelerator or power management yet. v2: Drop FB_HELPER select thanks to Archit's patches. Do manual init ordering instead of using the .load hook. Structure registration more like tegra's, but still using the typical "component" code. Drop no-op hooks for atomic_begin and mode_fixup() now that they're optional. Drop sentinel in Makefile. Fix minor style nits I noticed on another reread. v3: Use the new bcm2835 clk driver to manage pixel/HSM clocks instead of having a fixed video mode. Use exynos-style component driver matching instead of devicetree nodes to list the component driver instances. Rename compatibility strings to say bcm2835, and distinguish pv0/1/2. Clean up some h/vsync code, and add in interlaced mode setup. Fix up probe/bind error paths. Use bitops.h macros for vc4_regs.h v4: Include i2c.h, allow building under COMPILE_TEST, drop msleep now that other bugs have been fixed, add timeouts to cpu_relax() loops, rename hpd-gpio to hpd-gpios. Signed-off-by: NEric Anholt <eric@anholt.net> Acked-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
-
由 Insu Yun 提交于
drm_property_create_range can be failed in memory pressure Therefore, check return value and handle an error Signed-off-by: NInsu Yun <wuninsu@gmail.com> Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
-
由 Lukas Wunner 提交于
vga_switcheroo_client_ops has always been declared const since its introduction with 26ec685f ("vga_switcheroo: Introduce struct vga_switcheroo_client_ops"). Do so for vga_switcheroo_handler as well. drivers/gpu/drm/amd/amdgpu/amdgpu.ko: 6 .rodata 00009888 - 19 .data 00001f00 + 19 .data 00001ee0 drivers/gpu/drm/nouveau/nouveau.ko: 6 .rodata 000460b8 17 .data 00018fe0 drivers/gpu/drm/radeon/radeon.ko: - 7 .rodata 00030944 + 7 .rodata 00030964 - 21 .data 0000d6a0 + 21 .data 0000d678 drivers/platform/x86/apple-gmux.ko: - 7 .rodata 00000140 + 7 .rodata 00000160 - 11 .data 000000e0 + 11 .data 000000b8 Cc: Ben Skeggs <bskeggs@redhat.com> Cc: Darren Hart <dvhart@linux.intel.com> Cc: Alex Deucher <alexander.deucher@amd.com> Signed-off-by: NLukas Wunner <lukas@wunner.de> Reviewed-by: Christian König <christian.koenig@amd.com>. Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
-
- 20 10月, 2015 6 次提交
-
-
由 Liviu Dudau 提交于
The armada DRM driver keeps some old platform data compatibility in the probe function that makes moving to the generic drm_of_component_probe() a bit more complicated that it should. Refactor the probe function to do the platform_data processing after the generic probe (and only if that fails). This way future cleanup can further remove support for it. Signed-off-by: NLiviu Dudau <Liviu.Dudau@arm.com> Acked-by: NRussell King <rmk+kernel@arm.linux.org.uk> Link: http://patchwork.freedesktop.org/patch/msgid/1445332995-11212-5-git-send-email-Liviu.Dudau@arm.comSigned-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
-
由 Liviu Dudau 提交于
Use the generic drm_of_component_probe() function to probe for components. Signed-off-by: NLiviu Dudau <Liviu.Dudau@arm.com> Link: http://patchwork.freedesktop.org/patch/msgid/1445332995-11212-4-git-send-email-Liviu.Dudau@arm.comSigned-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
-
由 Liviu Dudau 提交于
The generic function is functionally equivalent to the driver's imx_drm_platform_probe(). Use the generic function and reduce the overall code size. Signed-off-by: NLiviu Dudau <Liviu.Dudau@arm.com> Acked-by: NRussell King <rmk+kernel@arm.linux.org.uk> Link: http://patchwork.freedesktop.org/patch/msgid/1445332995-11212-3-git-send-email-Liviu.Dudau@arm.comSigned-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
-
由 Liviu Dudau 提交于
A lot of component based DRM drivers use a variant of the same code as the probe function. They bind the crtc ports in the first iteration and then scan through the child nodes and bind the encoders attached to the remote endpoints. Factor the common code into a separate function called drm_of_component_probe() in order to increase code reuse. Cc: David Airlie <airlied@linux.ie> Signed-off-by: NLiviu Dudau <Liviu.Dudau@arm.com> Acked-by: NRussell King <rmk+kernel@arm.linux.org.uk> Link: http://patchwork.freedesktop.org/patch/msgid/1445332995-11212-2-git-send-email-Liviu.Dudau@arm.comAcked-by: NEric Anholt <eric@anholt.net> Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
-
由 Ville Syrjälä 提交于
Rounding to the closest kHz seems like the better option that round down or up when computing the alternate clock for CEA/HDMI modes. It'll give us a slightly more accurate clock in some cases. Not sure why I went for the down+up approach originally. Perhaps I was thinking we can go back and forth betwen the two frequencies without introducing errors, but round to closest still maintains that property. Cc: Adam Jackson <ajax@redhat.com> Cc: Clint Taylor <clinton.a.taylor@intel.com> Cc: Libin Yang <libin.yang@intel.com> Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by: NAdam Jackson <ajax@redhat.com> Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
-
由 Ville Syrjälä 提交于
EDID detailed timings have a resolution of 10kHz for the pixel clock, so they can't represent certain CEA/HDMI modes accurately. If we see a mode coming in via detailed timings which otherwise matches one of the CEA/HDMI modes except the clock is just a bit off, let's assume that the intention was for that mode to be one of the CEA/HDMI modes and go ahead and fix up the clock to match the CEA/HDMI spec exactly (well, as close as we can get with the 1 kHz resolution we use). This should help code that's looking for an exact clock match (eg. i915 audio N/CTS setup). Cc: Adam Jackson <ajax@redhat.com> Cc: Clint Taylor <clinton.a.taylor@intel.com> Cc: Libin Yang <libin.yang@intel.com> Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by: NAdam Jackson <ajax@redhat.com> Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
-