[git pull] drm fixes for 4.9-rc5
Hi Linus, amdgpu/radeon have a number of power management regressions and fixes along with some better error checking, imx has a single regression fix, udl has a single kmalloc instead of stack for usb control msg fix msm has some fixes for modesetting bugs and regressions, i915 has a one fix for a Sandybridge regression along with some others for DP audio. They all seem pretty okay at this stage, we've got one MST fix I know going through process for i915, but I expect it'll be next week. Dave. The following changes since commit bc33b0ca11e3df46a4fa7639ba488c9d4911: Linux 4.9-rc4 (2016-11-05 16:23:36 -0700) are available in the git repository at: git://people.freedesktop.org/~airlied/linux tags/drm-fixes-for-v4.9-rc5 for you to fetch changes up to 24399f4f0b95522e01e212537d26880227787670: Merge tag 'imx-drm-fixes-2016-11-10' of git://git.pengutronix.de/git/pza/linux into drm-fixes (2016-11-11 09:09:57 +1000) amd, radeon, i915, imx, msm and udl fixes Alex Deucher (9): drm/amdgpu: add support for new smc firmware on tonga drm/amdgpu: add support for new smc firmware on iceland drm/radeon: disable runtime pm in certain cases drm/amdgpu: disable runtime pm in certain cases drm/amdgpu: make sure ddc_bus is valid in connector unregister drm/amdgpu: fix crash in acp_hw_fini drm/amd/powerplay: propagate errors in phm_get_voltage_evv_on_sclk drm/amd/powerplay: update phm_get_voltage_evv_on_sclk for iceland drm/amd/powerplay/smu7: fix checks in smu7_get_evv_voltages (v2) Andrew Shadura (1): drm/amd/powerplay: return false instead of -EINVAL Archit Taneja (3): drm/msm/dsi: Queue HPD helper work in attach/detach callbacks drm/msm: Set CLK_IGNORE_UNUSED flag for PLL clocks drm/msm: Fix error handling crashes seen when VRAM allocation fails Arnd Bergmann (1): drm/amdgpu/powerplay/smu7: fix unintialized data usage Chris Wilson (2): drm/i915: Round tile chunks up for constructing partial VMAs drm/i915: Limit Valleyview and earlier to only using mappable scanout Christian König (2): drm/amd: fix scheduler fence teardown order v2 drm/amdgpu: add some error handling to amdgpu_init v2 Dave Airlie (7): Merge branch 'drm-fixes-4.9' of git://people.freedesktop.org/~agd5f/linux into drm-fixes Merge branch 'msm-fixes-4.9' of git://people.freedesktop.org/~robclark/linux into drm-fixes Merge tag 'drm-intel-fixes-2016-11-09' of git://anongit.freedesktop.org/drm-intel into drm-fixes Merge branch 'drm-fixes-4.9' of git://people.freedesktop.org/~agd5f/linux into drm-fixes drm/udl: make control msg static const. (v2) Merge branch 'drm-fixes-4.9' of git://people.freedesktop.org/~agd5f/linux into drm-fixes Merge tag 'imx-drm-fixes-2016-11-10' of git://git.pengutronix.de/git/pza/linux into drm-fixes Dhinakaran Pandiyan (2): drm/i915/dp: BDW cdclk fix for DP audio drm/i915/dp: Extend BDW DP audio workaround to GEN9 platforms Grazvydas Ignotas (1): drm/amd/powerplay: don't succeed in getters if fan is missing Larry Finger (1): drm/radeon: Fix kernel panic on shutdown Lucas Stach (1): drm/imx: disable planes before DC Lyude (1): drm/i915/vlv: Prevent enabling hpd polling in late suspend Rex Zhu (1): drm/amd/powerplay: implement get_clock_by_type for iceland. Rob Clark (3): drm/msm/mdp5: handle non-fullscreen base plane case drm/msm/mdp5: no scaling support on RGBn pipes for 8x16 drm/msm/mdp5: 8x16 actually has 8 mixer stages Ville Syrjälä (1): drm/i915: Respect alternate_ddc_pin for all DDI ports drivers/gpu/drm/amd/amdgpu/amdgpu_acp.c| 5 +- drivers/gpu/drm/amd/amdgpu/amdgpu_cgs.c| 13 +++- drivers/gpu/drm/amd/amdgpu/amdgpu_connectors.c | 2 +- drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c| 26 ++- drivers/gpu/drm/amd/amdgpu/amdgpu_kms.c| 2 + drivers/gpu/drm/amd/amdgpu/vi.c| 2 + .../gpu/drm/amd/powerplay/hwmgr/hardwaremanager.c | 2 +- drivers/gpu/drm/amd/powerplay/hwmgr/hwmgr.c| 6 +- drivers/gpu/drm/amd/powerplay/hwmgr/smu7_hwmgr.c | 70 +++--- drivers/gpu/drm/amd/powerplay/hwmgr/smu7_thermal.c | 6 +- drivers/gpu/drm/amd/scheduler/gpu_scheduler.c | 13 drivers/gpu/drm/amd/scheduler/gpu_scheduler.h | 6 +- drivers/gpu/drm/amd/scheduler/sched_fence.c| 19 + drivers/gpu/drm/i915/i915_gem.c| 20 +- drivers/gpu/drm/i915/intel_display.c | 29 +++- drivers/gpu/drm/i915/intel_hdmi.c | 84 -- drivers/gpu/drm/i915/intel_runtime_pm.c| 4 +- drivers/gpu/drm/imx/ipuv3-crtc.c | 9 ++- drivers/gpu/drm/msm/dsi/dsi_host.c |
[PATCH v2] drm/arcpgu: Accommodate adv7511 switch to DRM bridge
On 10 November 2016 at 21:06, Alexey Brodkin
wrote:
> Hi Daniel, David,
>
> On Wed, 2016-11-02 at 12:23 +, Alexey Brodkin wrote:
>> Hi Daniel, David,
>>
>> On Mon, 2016-10-24 at 18:33 +, Alexey Brodkin wrote:
>> >
>> > Hi Daniel,
>> >
>> > >
>> > >
>> > > -Original Message-
>> > > From: linux-snps-arc [mailto:linux-snps-arc-bounces at
>> > > lists.infradead.org] On Behalf Of Alexey Brodkin
>> > > Sent: 19 окÑÑбÑÑ 2016 г. 12:33
>> > > To: dri-devel at lists.freedesktop.org; architt at codeaurora.org;
>> > > Eugeniy.Paltsev at synopsys.com
>> > > Cc: linux-snps-arc at lists.infradead.org; linux-kernel at
>> > > vger.kernel.org
>> > > Subject: Re: [PATCH v2] drm/arcpgu: Accommodate adv7511 switch to DRM
>> > > bridge
>> > >
>> > > Hi Archit, all,
>> > >
>> > > On Wed, 2016-10-19 at 14:43 +0530, Archit Taneja wrote:
>> > > >
>> > > >
>> > > >
>> > > > On 10/19/2016 01:16 PM, Eugeniy Paltsev wrote:
>> > > > >
>> > > > >
>> > > > >
>> > > > > ARC PGU driver starts crashing on initialization after
>> > > > > 'commit e12c2f645557 ("drm/i2c: adv7511: Convert to drm_bridge")'
>> > > > > This happenes because in "arcpgu_drm_hdmi_init" function we get
>> > > > > pointer
>> > > > > of "drm_i2c_encoder_driver" structure, which doesn't exist after
>> > > > > adv7511 hdmi encoder interface changed from slave encoder to drm
>> > > > > bridge.
>> > > > > So, when we call "encoder_init" function from this structure driver
>> > > > > crashes.
>> > >
>> > > [snip]
>> > >
>> > > >
>> > > >
>> > > > Looks good now.
>> > > >
>> > > > Reviewed-by: Archit Taneja
>> > >
>> > > And IMHO it would be really good to get this one back-ported to 4.8
>> > > because it really fixes kernel crash if ARC PGU driver is used.
>> > >
>> > > It might be a bit of a problem because patch itself a little-bit larger
>> > > than formal requirement for stable backports but let's see if it gets
>> > > accepted.
>> >
>> > Could you please pick this one up?
>> > I may alternatively send a pull-request to David but not sure if 1 patch
>> > worth it.
>> >
>> > Also if that's not really too late it would be good to get this one in 4.9
>> > since the patch
>> > In question fixes a real driver crash on its instantiation.
>> > Actually driver crash happens since 4.8 but I failed to notice it earlier
>> > and given amount
>> > of changes I think there's barely a chance for it it to be accepted in
>> > stable branches...
>> > which in its turn makes at least 4.9 very desirable.
>>
>> Any chance this one gets accepted anytime soon?
>
> Please treat this as another polite reminder to apply this patch.
> If you prefer I may send a pull-request otherwise.
Please send a pull request for -fixes.
For everyone else, pull requests for single patches is not overkill,
it fits into my workflow a lot better.
Dave.
[GIT PULL] bridge/dw-hdmi: I2C master controller support
On 9 November 2016 at 10:52, Stefan Agner wrote: > Hi Dave, > > On 2016-09-19 00:16, Philipp Zabel wrote: >> Hi Dave, >> >> this tag contains support for the I2C master controller contained in the >> HDMI TX IP core, for those boards that don't allow to mux their DDC pins >> to SoC I2C controllers. This will make the dw-hdmi driver register its >> internal I2C master if the ddc-i2c-bus property is not set on the device >> tree node. > > This did not get merged so far, any specific reason? > > We have some device tree changes building on-top of that, so it would > nice if it makes it into 4.10... Oops pulled into drm-next now. Dave.
[PATCH v2] PCI: create revision file in sysfs
On 10 November 2016 at 23:59, Bjorn Helgaas wrote: > Hi Emil, > > On Thu, Nov 10, 2016 at 01:14:35PM +, Emil Velikov wrote: >> On 10 November 2016 at 07:13, Greg KH wrote: >> > On Wed, Nov 09, 2016 at 04:56:07PM +, Emil Velikov wrote: >> >> From: Emil Velikov >> >> >> >> Currently the revision isn't available via sysfs/libudev thus if one >> >> wants to know the value they need to read through the config file. >> >> >> >> This in itself wakes/powers up the device, causing unwanted delays. >> >> >> >> There are at least two userspace components which could make use the new >> >> file - libpciaccess and libdrm. At the moment the former will wake up >> >> _every_ PCI device for simple invocation of glxinfo [when using Mesa >> >> 10.0+ drivers]. While the latter [in association with Mesa 13.0] can >> >> lead to 2-3 second delays while starting firefox, thunderbird or >> >> chromium. > > I agree, these unwanted delays are completely unacceptable. My > question is whether we should fix them by exporting more information > from the kernel, or by changing the way the userspace components work. > > It should not take anywhere near 2 seconds to wake up a PCI device. > That makes me think there's a more serious problem than just a lack of > caching for the revision field, e.g., maybe we're looking at far more > PCI devices than we need to, or we're doing it many times to the same > device, or ... > > If I understand correctly, the delay was bisected to > https://cgit.freedesktop.org/mesa/mesa/commit/?id=be239326aa4f, which > removed a bunch of code that looked up the vendor and device IDs, and > replaced it with drmGetDevice(). And apparently drmGetDevice(), in > this path: > > drmGetDevice > drmProcessPciDevice > drmParsePciDeviceInfo > > is a little more thorough in that it looks up the *revision* in > addition to the vendor and device IDs. So we pay the cost for the > revision even though in this instance we don't care about the revision > at all. > Above all, apologies for all the "lovely" code that you had to go through for these. And yes, you've got it spot on. > drmParsePciDeviceInfo() currently reads the whole config header from > sysfs (https://cgit.freedesktop.org/drm/libdrm/tree/xf86drm.c#n2949), > but I think you're extending that to try the vendor, device, > subsystem_vendor, subsystem_device, and (if present) revision sysfs > files first (http://www.spinics.net/lists/dri-devel/msg122319.html). > Yes, making the revision file optional and "faking it" was my first thought, esp. since we don't have any users of it (yet). Although people are not too keen on it, so we'll likely opt for revision-less API. > Bottom line, I guess I'm not super opposed to this, but I do feel like > we're making a kernel change to cover up a userspace problem, and I > think it would be better to push on that userspace problem a little > more. > Yes, definitely we can beat some sense into userspace. Yet that shouldn't be a deterrent for exposing the revision. As hinted before the other prominent user libpciaccess wakes up probes _every_ pci device. Atm that library is used by Xorg, Spice, libvirt and a few others. Amongst which are the Intel GL drivers (via libdrm_intel.so), [only] when GLX_MESA_query_renderer is used. Or in other words - if Firefox/other GL app wants to use the extension, they'll get similar delays. We should look into that one as well, but it will be more picky to address (read "slower to reach end users"). >> I've updated Documentation/filesystems/sysfs-pci.txt [locally] yet >> looking through ABI/ there is only a 'testing' one - >> Documentation/ABI/testing/sysfs-bus-pci. >> >> Feels a bit strange there is no stable one, guess I should/could start one ? > > I wouldn't jump to the conclusion that this new ABI is "stable" when > all the existing ones are only "testing". I'd just leave it in > testing along with all the others. > Agreed. Thank you ! Emil
[PATCH] drm/rockchip: return ERR_PTR instead of NULL
On 2016å¹´11æ11æ¥ 05:10, Julia Lawall wrote: > rockchip_drm_framebuffer_init is only used in one case, in > rockchip_drm_fbdev.c, where its return value is tested using IS_ERR. To > enable propagating the reason for the error, change the definition so that > it returns an ERR_PTR value. > > Problem found with the help of Coccinelle. > > Signed-off-by: Julia Lawall Thanks for the fix. Applied to my drm-next. > > --- > drivers/gpu/drm/rockchip/rockchip_drm_fb.c |2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/drivers/gpu/drm/rockchip/rockchip_drm_fb.c > b/drivers/gpu/drm/rockchip/rockchip_drm_fb.c > index 0f6eda0..01e11bf 100644 > --- a/drivers/gpu/drm/rockchip/rockchip_drm_fb.c > +++ b/drivers/gpu/drm/rockchip/rockchip_drm_fb.c > @@ -213,7 +213,7 @@ struct drm_framebuffer * > > rockchip_fb = rockchip_fb_alloc(dev, mode_cmd, &obj, 1); > if (IS_ERR(rockchip_fb)) > - return NULL; > + return ERR_CAST(rockchip_fb); > > return &rockchip_fb->fb; > } > > > > -- ï¼ark Yao
[PATCH v8 0/3] drm: add explict fencing
From: Gustavo Padovan Hi, New version of the DRM fences patches with all comments on v7 adressed. Please refer to the cover letter[1] in a previous version to check for more details. The changes since the last version can be seen in commit message on each patch. Robert Foss managed to port Android's drm_hwcomposer to the new HWC2 API and added support to fences. Current patches can be seen here: https://git.collabora.com/cgit/user/robertfoss/drm_hwcomposer.git/log/?h=hwc2_fence_v1 He ran AOSP on top of padovan/fences kernel branch with full fence support on qemu/virgl and msm db410c. That means we already have a working open source userspace using the explicit fencing implementation. Also i-g-t testing are available with all tests suggested in v7 included: https://git.collabora.com/cgit/user/padovan/intel-gpu-tools.git/log/ Please review! Gustavo [1] https://www.mail-archive.com/linux-kernel at vger.kernel.org/msg1253822.html --- Gustavo Padovan (3): drm/fence: add in-fences support drm/fence: add fence timeline to drm_crtc drm/fence: add out-fences support drivers/gpu/drm/Kconfig | 1 + drivers/gpu/drm/drm_atomic.c| 256 +--- drivers/gpu/drm/drm_atomic_helper.c | 5 + drivers/gpu/drm/drm_crtc.c | 45 +++ drivers/gpu/drm/drm_plane.c | 1 + include/drm/drm_atomic.h| 1 + include/drm/drm_crtc.h | 56 7 files changed, 320 insertions(+), 45 deletions(-) -- 2.5.5
[PATCH v8 1/3] drm/fence: add in-fences support
From: Gustavo Padovan
There is now a new property called IN_FENCE_FD attached to every plane
state that receives sync_file fds from userspace via the atomic commit
IOCTL.
The fd is then translated to a fence (that may be a fence_array
subclass or just a normal fence) and then used by DRM to fence_wait() for
all fences in the sync_file to signal. So it only commits when all
framebuffers are ready to scanout.
v2: Comments by Daniel Vetter:
- remove set state->fence = NULL in destroy phase
- accept fence -1 as valid and just return 0
- do not call fence_get() - sync_file_fences_get() already calls it
- fence_put() if state->fence is already set, in case userspace
set the property more than once.
v3: WARN_ON if fence is set but state has no FB
v4: Comment from Maarten Lankhorst
- allow set fence with no related fb
v5: rename FENCE_FD to IN_FENCE_FD
v6: Comments by Daniel Vetter:
- rename plane_state->in_fence back to "fence"
- re-introduce WARN_ON if fence set but no fb
- rebase after fence -> dma_fence rename
v7: Comments by Brian Starkey
- set state->fence to NULL when duplicating the state
- fail if IN_FENCE_FD was already set
Signed-off-by: Gustavo Padovan
---
drivers/gpu/drm/Kconfig | 1 +
drivers/gpu/drm/drm_atomic.c| 14 ++
drivers/gpu/drm/drm_atomic_helper.c | 5 +
drivers/gpu/drm/drm_crtc.c | 6 ++
drivers/gpu/drm/drm_plane.c | 1 +
include/drm/drm_crtc.h | 5 +
6 files changed, 32 insertions(+)
diff --git a/drivers/gpu/drm/Kconfig b/drivers/gpu/drm/Kconfig
index 25e8e37..360cb92 100644
--- a/drivers/gpu/drm/Kconfig
+++ b/drivers/gpu/drm/Kconfig
@@ -12,6 +12,7 @@ menuconfig DRM
select I2C
select I2C_ALGOBIT
select DMA_SHARED_BUFFER
+ select SYNC_FILE
help
Kernel-level support for the Direct Rendering Infrastructure (DRI)
introduced in XFree86 4.0. If you say Y here, you need to select
diff --git a/drivers/gpu/drm/drm_atomic.c b/drivers/gpu/drm/drm_atomic.c
index b096c16..8e26ad1 100644
--- a/drivers/gpu/drm/drm_atomic.c
+++ b/drivers/gpu/drm/drm_atomic.c
@@ -31,6 +31,7 @@
#include
#include
#include
+#include
#include "drm_crtc_internal.h"
@@ -709,6 +710,17 @@ int drm_atomic_plane_set_property(struct drm_plane *plane,
drm_atomic_set_fb_for_plane(state, fb);
if (fb)
drm_framebuffer_unreference(fb);
+ } else if (property == config->prop_in_fence_fd) {
+ if (state->fence)
+ return -EINVAL;
+
+ if (U642I64(val) == -1)
+ return 0;
+
+ state->fence = sync_file_get_fence(val);
+ if (!state->fence)
+ return -EINVAL;
+
} else if (property == config->prop_crtc_id) {
struct drm_crtc *crtc = drm_crtc_find(dev, val);
return drm_atomic_set_crtc_for_plane(state, crtc);
@@ -770,6 +782,8 @@ drm_atomic_plane_get_property(struct drm_plane *plane,
if (property == config->prop_fb_id) {
*val = (state->fb) ? state->fb->base.id : 0;
+ } else if (property == config->prop_in_fence_fd) {
+ *val = -1;
} else if (property == config->prop_crtc_id) {
*val = (state->crtc) ? state->crtc->base.id : 0;
} else if (property == config->prop_crtc_x) {
diff --git a/drivers/gpu/drm/drm_atomic_helper.c
b/drivers/gpu/drm/drm_atomic_helper.c
index 75ad01d..caed870 100644
--- a/drivers/gpu/drm/drm_atomic_helper.c
+++ b/drivers/gpu/drm/drm_atomic_helper.c
@@ -3076,6 +3076,8 @@ void __drm_atomic_helper_plane_duplicate_state(struct
drm_plane *plane,
if (state->fb)
drm_framebuffer_reference(state->fb);
+
+ state->fence = NULL;
}
EXPORT_SYMBOL(__drm_atomic_helper_plane_duplicate_state);
@@ -3114,6 +3116,9 @@ void __drm_atomic_helper_plane_destroy_state(struct
drm_plane_state *state)
{
if (state->fb)
drm_framebuffer_unreference(state->fb);
+
+ if (state->fence)
+ dma_fence_put(state->fence);
}
EXPORT_SYMBOL(__drm_atomic_helper_plane_destroy_state);
diff --git a/drivers/gpu/drm/drm_crtc.c b/drivers/gpu/drm/drm_crtc.c
index ce274ed..154e040 100644
--- a/drivers/gpu/drm/drm_crtc.c
+++ b/drivers/gpu/drm/drm_crtc.c
@@ -397,6 +397,12 @@ static int drm_mode_create_standard_properties(struct
drm_device *dev)
return -ENOMEM;
dev->mode_config.prop_fb_id = prop;
+ prop = drm_property_create_signed_range(dev, DRM_MODE_PROP_ATOMIC,
+ "IN_FENCE_FD", -1, INT_MAX);
+ if (!prop)
+ return -ENOMEM;
+ dev->mode_config.prop_in_fence_fd = prop;
+
prop = drm_property_create_object(dev, DRM_MODE_PROP_ATOMIC,
"CRTC_ID", DRM_MODE_OBJECT_CRTC);
[PATCH v8 2/3] drm/fence: add fence timeline to drm_crtc
From: Gustavo Padovan
Create one timeline context for each CRTC to be able to handle out-fences
and signal them. It adds a few members to struct drm_crtc: fence_context,
where we store the context we get from fence_context_alloc(), the
fence seqno and the fence lock, that we pass in fence_init() to be
used by the fence.
v2: Comment by Daniel Stone:
- add BUG_ON() to fence_to_crtc() macro
v3: Comment by Ville Syrjälä
- Use more meaningful name as crtc timeline name
v4: Comments by Brian Starkey
- Use even more meaninful name for the crtc timeline
- add doc for timeline_name
Comment by Daniel Vetter
- use in-line style for comments
- rebase after fence -> dma_fence rename
v5: Comment by Daniel Vetter
- Add doc for drm_crtc_fence_ops
Signed-off-by: Gustavo Padovan
Reviewed-by: Daniel Vetter
---
drivers/gpu/drm/drm_crtc.c | 31 +++
include/drm/drm_crtc.h | 45 +
2 files changed, 76 insertions(+)
diff --git a/drivers/gpu/drm/drm_crtc.c b/drivers/gpu/drm/drm_crtc.c
index 154e040..9b9881b 100644
--- a/drivers/gpu/drm/drm_crtc.c
+++ b/drivers/gpu/drm/drm_crtc.c
@@ -165,6 +165,32 @@ static void drm_crtc_crc_fini(struct drm_crtc *crtc)
#endif
}
+static const char *drm_crtc_fence_get_driver_name(struct dma_fence *fence)
+{
+ struct drm_crtc *crtc = fence_to_crtc(fence);
+
+ return crtc->dev->driver->name;
+}
+
+static const char *drm_crtc_fence_get_timeline_name(struct dma_fence *fence)
+{
+ struct drm_crtc *crtc = fence_to_crtc(fence);
+
+ return crtc->timeline_name;
+}
+
+static bool drm_crtc_fence_enable_signaling(struct dma_fence *fence)
+{
+ return true;
+}
+
+const struct dma_fence_ops drm_crtc_fence_ops = {
+ .get_driver_name = drm_crtc_fence_get_driver_name,
+ .get_timeline_name = drm_crtc_fence_get_timeline_name,
+ .enable_signaling = drm_crtc_fence_enable_signaling,
+ .wait = dma_fence_default_wait,
+};
+
/**
* drm_crtc_init_with_planes - Initialise a new CRTC object with
*specified primary and cursor planes.
@@ -222,6 +248,11 @@ int drm_crtc_init_with_planes(struct drm_device *dev,
struct drm_crtc *crtc,
return -ENOMEM;
}
+ crtc->fence_context = dma_fence_context_alloc(1);
+ spin_lock_init(&crtc->fence_lock);
+ snprintf(crtc->timeline_name, sizeof(crtc->timeline_name),
+"CRTC:%d-%s", crtc->base.id, crtc->name);
+
crtc->base.properties = &crtc->properties;
list_add_tail(&crtc->head, &config->crtc_list);
diff --git a/include/drm/drm_crtc.h b/include/drm/drm_crtc.h
index 11780a9..0870de1 100644
--- a/include/drm/drm_crtc.h
+++ b/include/drm/drm_crtc.h
@@ -32,6 +32,8 @@
#include
#include
#include
+#include
+#include
#include
#include
#include
@@ -739,9 +741,52 @@ struct drm_crtc {
*/
struct drm_crtc_crc crc;
#endif
+
+ /**
+* @fence_context:
+*
+* timeline context used for fence operations.
+*/
+ unsigned int fence_context;
+
+ /**
+* @fence_lock:
+*
+* spinlock to protect the fences in the fence_context.
+*/
+
+ spinlock_t fence_lock;
+ /**
+* @fence_seqno:
+*
+* Seqno variable used as monotonic counter for the fences
+* created on the CRTC's timeline.
+*/
+ unsigned long fence_seqno;
+
+ /**
+* @timeline_name:
+*
+* The name of the CRTC's fence timeline.
+*/
+ char timeline_name[32];
};
/**
+ * dma_crtc_fence_ops - fence ops for the drm_crtc timeline
+ *
+ * It contains the dma_fence_ops that should be called by the dma_fence
+ * code. CRTC core should use this ops when initializing fences.
+ */
+extern const struct dma_fence_ops drm_crtc_fence_ops;
+
+static inline struct drm_crtc *fence_to_crtc(struct dma_fence *fence)
+{
+ BUG_ON(fence->ops != &drm_crtc_fence_ops);
+ return container_of(fence->lock, struct drm_crtc, fence_lock);
+}
+
+/**
* struct drm_mode_set - new values for a CRTC config change
* @fb: framebuffer to use for new config
* @crtc: CRTC whose configuration we're about to change
--
2.5.5
[PATCH v8 3/3] drm/fence: add out-fences support
From: Gustavo Padovan
Support DRM out-fences by creating a sync_file with a fence for each CRTC
that sets the OUT_FENCE_PTR property.
We use the out_fence pointer received in the OUT_FENCE_PTR prop to send
the sync_file fd back to userspace.
The sync_file and fd are allocated/created before commit, but the
fd_install operation only happens after we know that commit succeed.
v2: Comment by Rob Clark:
- Squash commit that adds DRM_MODE_ATOMIC_OUT_FENCE flag here.
Comment by Daniel Vetter:
- Add clean up code for out_fences
v3: Comments by Daniel Vetter:
- create DRM_MODE_ATOMIC_EVENT_MASK
- userspace should fill out_fences_ptr with the crtc_ids for which
it wants fences back.
v4: Create OUT_FENCE_PTR properties and remove old approach.
v5: Comments by Brian Starkey:
- Remove extra fence_get() in atomic_ioctl()
- Check ret before iterating on the crtc_state
- check ret before fd_install
- set fence_state to NULL at the beginning
- check fence_state->out_fence_ptr before put_user()
- change order of fput() and put_unused_fd() on failure
- Add access_ok() check to the out_fence_ptr received
- Rebase after fence -> dma_fence rename
- Store out_fence_ptr in the drm_atomic_state
- Split crtc_setup_out_fence()
- return -1 as out_fence with TEST_ONLY flag
v6: Comments by Daniel Vetter
- Add prepare/unprepare_crtc_signaling()
- move struct drm_out_fence_state to drm_atomic.c
- mark get_crtc_fence() as static
Comments by Brian Starkey
- proper set fence_ptr fence_state array
- isolate fence_idx increment
- improve error handling
v7: Comments by Daniel Vetter
- remove prefix from internal functions
- make out_fence_ptr an s64 pointer
- degrade DRM_INFO to DRM_DEBUG_ATOMIC when put_user fail
- fix doc issues
- filter out OUT_FENCE_PTR == NULL and do fail in this case
- add complete_crtc_signalling()
- krealloc fence_state on demand
Comment by Brian Starkey
- remove unused crtc_state arg from get_out_fence()
Signed-off-by: Gustavo Padovan
---
drivers/gpu/drm/drm_atomic.c | 242 +++
drivers/gpu/drm/drm_crtc.c | 8 ++
include/drm/drm_atomic.h | 1 +
include/drm/drm_crtc.h | 6 ++
4 files changed, 212 insertions(+), 45 deletions(-)
diff --git a/drivers/gpu/drm/drm_atomic.c b/drivers/gpu/drm/drm_atomic.c
index 8e26ad1..cd39f13 100644
--- a/drivers/gpu/drm/drm_atomic.c
+++ b/drivers/gpu/drm/drm_atomic.c
@@ -290,6 +290,23 @@ drm_atomic_get_crtc_state(struct drm_atomic_state *state,
}
EXPORT_SYMBOL(drm_atomic_get_crtc_state);
+static void set_out_fence_for_crtc(struct drm_atomic_state *state,
+ struct drm_crtc *crtc, u64 __user *fence_ptr)
+{
+ state->crtcs[drm_crtc_index(crtc)].out_fence_ptr = fence_ptr;
+}
+
+static u64 __user * get_out_fence_for_crtc(struct drm_atomic_state *state,
+ struct drm_crtc *crtc)
+{
+ u64 __user *fence_ptr;
+
+ fence_ptr = state->crtcs[drm_crtc_index(crtc)].out_fence_ptr;
+ state->crtcs[drm_crtc_index(crtc)].out_fence_ptr = NULL;
+
+ return fence_ptr;
+}
+
/**
* drm_atomic_set_mode_for_crtc - set mode for CRTC
* @state: the CRTC whose incoming state to update
@@ -491,6 +508,16 @@ int drm_atomic_crtc_set_property(struct drm_crtc *crtc,
&replaced);
state->color_mgmt_changed |= replaced;
return ret;
+ } else if (property == config->prop_out_fence_ptr) {
+ s64 __user *fence_ptr = u64_to_user_ptr(val);
+
+ if (!fence_ptr)
+ return 0;
+
+ if (!access_ok(VERIFY_WRITE, fence_ptr, sizeof(*fence_ptr)))
+ return -EFAULT;
+
+ set_out_fence_for_crtc(state->state, crtc, fence_ptr);
} else if (crtc->funcs->atomic_set_property)
return crtc->funcs->atomic_set_property(crtc, state, property,
val);
else
@@ -533,6 +560,8 @@ drm_atomic_crtc_get_property(struct drm_crtc *crtc,
*val = (state->ctm) ? state->ctm->base.id : 0;
else if (property == config->gamma_lut_property)
*val = (state->gamma_lut) ? state->gamma_lut->base.id : 0;
+ else if (property == config->prop_out_fence_ptr)
+ *val = 0;
else if (crtc->funcs->atomic_get_property)
return crtc->funcs->atomic_get_property(crtc, state, property,
val);
else
@@ -1659,11 +1688,9 @@ int drm_atomic_debugfs_init(struct drm_minor *minor)
*/
static struct drm_pending_vblank_event *create_vblank_event(
- struct drm_device *dev, struct drm_file *file_priv,
- struct dma_fence *fence, uint64_t user_data)
+ struct drm_device *
[PATCH 5/5] drm/sun4i: Add support for the overscan profiles
On Thu, Nov 10, 2016 at 03:56:30PM +0100, Maxime Ripard wrote: > Hi Daniel, > > On Tue, Nov 08, 2016 at 09:59:27AM +0100, Daniel Vetter wrote: > > On Tue, Oct 18, 2016 at 10:29:38AM +0200, Maxime Ripard wrote: > > > Create overscan profiles reducing the displayed zone. > > > > > > For each TV standard (PAL and NTSC so far), we create 4 more reduced modes > > > by steps of 5% that the user will be able to select. > > > > > > Signed-off-by: Maxime Ripard > > > > tbh I think if we agree to do this (and that still seems an open question) > > I think there should be a generic helper to add these overscan modes with > > increased porches. Anything that only depends upon the sink (and > > overscanning is something the sink does) should imo be put into a suitable > > helper library for everyone to share. > > > > Or maybe even stash it into the probe helpers and call it for all TV > > connectors. Definitely not a driver-private thing. > > Last time we discussed it, my recollection was that you didn't want to > have generic code for it, but I'd be happy to implement it. > > I'll come up with something like that. Well I can flip-flop around with the nonsense I'm sometimes emitting ;-) Since you called me out, feel free to do whatever you want ... -Daniel -- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch
[Intel-gfx] [PATCH v3] drm: move allocation out of drm_get_format_name()
On Wed, Nov 09, 2016 at 04:59:31PM +, Eric Engestrom wrote: > On Wednesday, 2016-11-09 14:13:40 +0100, Daniel Vetter wrote: > > On Wed, Nov 9, 2016 at 12:42 PM, Eric Engestrom > > wrote: > > >> Well, had to drop it again since it didn't compile: > > >> > > >> > > >> CC [M] drivers/gpu/drm/drm_blend.o > > >> drivers/gpu/drm/drm_atomic.c: In function > > >> âdrm_atomic_plane_print_stateâ: > > >> drivers/gpu/drm/drm_atomic.c:920:5: error: too few arguments to function > > >> âdrm_get_format_nameâ > > >> drm_get_format_name(fb->pixel_format)); > > >> ^~~ > > >> In file included from ./include/drm/drmP.h:71:0, > > >> from drivers/gpu/drm/drm_atomic.c:29: > > >> ./include/drm/drm_fourcc.h:65:7: note: declared here > > >> char *drm_get_format_name(uint32_t format, struct drm_format_name_buf > > >> *buf); > > >>^~~ > > >> > > >> Can you pls rebase onto drm-misc or linux-next or something? > > > > > > That was based on airlied/drm-next (last fetched on Sunday I think), > > > I can rebase it on drm-misc if it helps, but it seems older than > > > drm-next. > > > Should I just rebase on top of current head of drm-next? > > > > It needs to be drm-misc (linux-next doesn't have it yet) due to the > > new atomic debug work that we just landed. I'm working on drm-tip as a > > drm local integration tree to ease pains like these a bit, but that > > doesn't really exist yet. > > I'm confused as to how the different trees and branches merge back to > Torvalds' tree (I'm interested in particular in drm), and I'm not sure > which branch you want me to rebase on in the drm-misc tree [1], > especially since all of them are older than drm-next [2]. Dave just pulled in all outstanding pull requests, so just basing on top of his drm-next should be good enough. > I'll try to rebase on drm-misc-fixes (currently at 4da5caa6a6f82cda3193) > as it sounds about right, but it doesn't apply at all, so it'll take > a little while. > > Could you give me a quick explanation or point me to a doc/page that > explains how the various trees and branches get merged? > I googled a bit and found this doc [4] by Jani, but it doesn't mention > drm-misc for instance, so I'm not sure how up-to-date and > non-intel-specific it is. We atm don't have it :( drm-misc was kinda just a (very long running) experiment, but I want to know make it official. Unfortunately the scripting rework to split out a new drm-misc.git repo is taking a bit longer. Atm things are still in flux, but I hope that'll settle soon-ish. > Looking at this page, something just occurred to me: did you mean > drm-fixes [3], instead of one of the branches on drm-misc? > > Cheers, > Eric > > [1] git://anongit.freedesktop.org/drm/drm-misc Yeah, that's the new location, but atm it's just under testing and it's not the real drm-misc. That one is in drm-intel.git, in the topic/drm-misc branch. > [2] git://people.freedesktop.org/~airlied/linux drm-next > [2] git://people.freedesktop.org/~airlied/linux drm-fixes > [3] https://01.org/linuxgraphics/gfx-docs/maintainer-tools/drm-intel.html https://01.org/linuxgraphics/gfx-docs/maintainer-tools/drm-misc.html We need to flesh that out, and maybe feature it a bit more prominently. -Daniel -- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch
gnome-shell is frozen upon wakeup from DPMS (bisected)
On Thu, Nov 10, 2016 at 06:21:50PM +0100, Max Staudt wrote: > Hi, > > I have bisected a commit in v4.6 that fixes a freeze of the screen on > DPMS sleep: > > 777e3cbc791f131806d9bf24b3325637c7fc228d drm/radeon: Switch to > drm_vblank_on/off > > > When running 'xset dpms force off' in a GNOME session (I tested this on > openSUSE Leap 42.2), sometimes the screen will freeze, sometimes it will > not. It may take several tries. > > When it does freeze, the mouse can still be used, but clicking anything > will (seem to?) have no effect. Typing in an open terminal still works, > albeit the screen will still be frozen. Run "xterm" and the screen will > unfreeze. Running "xlogo" does not unfreeze it. > > > Can we include the above commit in linux-stable? > > I have tested it on v4.4 - it applies cleanly and resolves the issue. I had to take a few rounds in getting this one right, personally I'd be wary with backporting due to that fireworks potential. Yes it works for you, but who knows where it blows up. Leaving the final decision to Alex ofc. -Daniel -- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch
[Intel-gfx] [PATCH 5/5] drm/i915: Implement Link Rate fallback on Link training failure
On Thu, 10 Nov 2016, Daniel Vetter wrote:
> On Wed, Nov 09, 2016 at 08:42:08PM -0800, Manasi Navare wrote:
>> @@ -5692,6 +5751,39 @@ static bool intel_edp_init_connector(struct intel_dp
>> *intel_dp,
>> return false;
>> }
>>
>> +static void intel_dp_modeset_retry_work_fn(struct work_struct *work)
>> +{
>> +struct intel_connector *intel_connector;
>> +struct drm_connector *connector;
>> +struct drm_display_mode *mode;
>> +bool verbose_prune = true;
>> +
>> +intel_connector = container_of(work, typeof(*intel_connector),
>> + modeset_retry_work);
>> +connector = &intel_connector->base;
>> +
>> +/* Grab the locks before changing connector property*/
>> +mutex_lock(&connector->dev->mode_config.mutex);
>> +DRM_DEBUG_KMS("[CONNECTOR:%d:%s]\n", connector->base.id,
>> + connector->name);
>> +list_for_each_entry(mode, &connector->modes, head) {
>> +mode->status = intel_dp_mode_valid(connector,
>> + mode);
>> +}
>> +drm_mode_prune_invalid(connector->dev, &connector->modes,
>> + verbose_prune);
>> +
>> +/* Set connector link status to BAD and send a Uevent to notify
>> + * userspace to do a modeset.
>> + */
>> +intel_dp_set_link_status_property(connector,
>> + DRM_MODE_LINK_STATUS_BAD);
>> +mutex_unlock(&connector->dev->mode_config.mutex);
>> +
>> +/* Send Hotplug uevent so userspace can reprobe */
>> +drm_kms_helper_hotplug_event(connector->dev);
>
> One downside of keeping all the signalling logic here in i915 is that we
> don't have a good spot to put the kerneldoc for this new link status
> property within drm_connector.c for others to easily spot. My suggestion
> would be to extract function with the following rough pseudo-code:
Thanks for this. I wanted Manasi to keep the work struct and function
within i915, but I fell short of coming up with this division.
BR,
Jani.
>
> drm_connector_set_link_status(connector, status)
> {
> mutex_lock(mode_config.mutex);
>
> /* what intel_dp_set_link_status_property() does */
>
> mutex_unlock(mode_config.mutex);
> drm_kms_helper_hotplug_event()
> }
>
> Within intel_dp_modeset_retry_work_fn we'd then first need to drop the
> lock, and then call this function. The lock drop&reacquire is a bit ugly,
> but:
> - it doesn't matter from a performance pov, this is a slow, asynchronous
> work.
> - it doesn't matter for correctnes, the only thing we need is to drop the
> lock before calling drm_kms_helper_hotplug_event, and that we update the
> link status and the mode list before that too.
> - long term I expect that properties will get separate locks to protect
> their values, and restrict mode_config.mutex to just mode probing. Which
> means drm_connnector_set_link_status will use a different lock anyway.
> - it nicely encapsulates stuff imo.
>
> Kerneldoc for drm_connector_set_link_status should mention that this needs
> to be run from some async work item, and ofc have the full explanation
> (maybe even quote some pseudo-code, see e.g. drm_modeset_lock.c comments)
> of how this should be used.
>
> Since this is late-stage polish definitely wait for more feedback and for
> the design to fully settle first.
> -Daniel
--
Jani Nikula, Intel Open Source Technology Center
[PATCH v8 1/3] drm/fence: add in-fences support
Hi Gustavo,
On Fri, Nov 11, 2016 at 02:16:07PM +0900, Gustavo Padovan wrote:
>From: Gustavo Padovan
>
>There is now a new property called IN_FENCE_FD attached to every plane
>state that receives sync_file fds from userspace via the atomic commit
>IOCTL.
>
>The fd is then translated to a fence (that may be a fence_array
>subclass or just a normal fence) and then used by DRM to fence_wait() for
>all fences in the sync_file to signal. So it only commits when all
>framebuffers are ready to scanout.
>
>v2: Comments by Daniel Vetter:
> - remove set state->fence = NULL in destroy phase
> - accept fence -1 as valid and just return 0
> - do not call fence_get() - sync_file_fences_get() already calls it
> - fence_put() if state->fence is already set, in case userspace
> set the property more than once.
>
>v3: WARN_ON if fence is set but state has no FB
>
>v4: Comment from Maarten Lankhorst
> - allow set fence with no related fb
>
>v5: rename FENCE_FD to IN_FENCE_FD
>
>v6: Comments by Daniel Vetter:
> - rename plane_state->in_fence back to "fence"
> - re-introduce WARN_ON if fence set but no fb
>
> - rebase after fence -> dma_fence rename
>
>v7: Comments by Brian Starkey
> - set state->fence to NULL when duplicating the state
> - fail if IN_FENCE_FD was already set
>
>Signed-off-by: Gustavo Padovan
lgtm,
Reviewed-by: Brian Starkey
>---
> drivers/gpu/drm/Kconfig | 1 +
> drivers/gpu/drm/drm_atomic.c| 14 ++
> drivers/gpu/drm/drm_atomic_helper.c | 5 +
> drivers/gpu/drm/drm_crtc.c | 6 ++
> drivers/gpu/drm/drm_plane.c | 1 +
> include/drm/drm_crtc.h | 5 +
> 6 files changed, 32 insertions(+)
>
>diff --git a/drivers/gpu/drm/Kconfig b/drivers/gpu/drm/Kconfig
>index 25e8e37..360cb92 100644
>--- a/drivers/gpu/drm/Kconfig
>+++ b/drivers/gpu/drm/Kconfig
>@@ -12,6 +12,7 @@ menuconfig DRM
> select I2C
> select I2C_ALGOBIT
> select DMA_SHARED_BUFFER
>+ select SYNC_FILE
> help
> Kernel-level support for the Direct Rendering Infrastructure (DRI)
> introduced in XFree86 4.0. If you say Y here, you need to select
>diff --git a/drivers/gpu/drm/drm_atomic.c b/drivers/gpu/drm/drm_atomic.c
>index b096c16..8e26ad1 100644
>--- a/drivers/gpu/drm/drm_atomic.c
>+++ b/drivers/gpu/drm/drm_atomic.c
>@@ -31,6 +31,7 @@
> #include
> #include
> #include
>+#include
>
> #include "drm_crtc_internal.h"
>
>@@ -709,6 +710,17 @@ int drm_atomic_plane_set_property(struct drm_plane *plane,
> drm_atomic_set_fb_for_plane(state, fb);
> if (fb)
> drm_framebuffer_unreference(fb);
>+ } else if (property == config->prop_in_fence_fd) {
>+ if (state->fence)
>+ return -EINVAL;
>+
>+ if (U642I64(val) == -1)
>+ return 0;
>+
>+ state->fence = sync_file_get_fence(val);
>+ if (!state->fence)
>+ return -EINVAL;
>+
> } else if (property == config->prop_crtc_id) {
> struct drm_crtc *crtc = drm_crtc_find(dev, val);
> return drm_atomic_set_crtc_for_plane(state, crtc);
>@@ -770,6 +782,8 @@ drm_atomic_plane_get_property(struct drm_plane *plane,
>
> if (property == config->prop_fb_id) {
> *val = (state->fb) ? state->fb->base.id : 0;
>+ } else if (property == config->prop_in_fence_fd) {
>+ *val = -1;
> } else if (property == config->prop_crtc_id) {
> *val = (state->crtc) ? state->crtc->base.id : 0;
> } else if (property == config->prop_crtc_x) {
>diff --git a/drivers/gpu/drm/drm_atomic_helper.c
>b/drivers/gpu/drm/drm_atomic_helper.c
>index 75ad01d..caed870 100644
>--- a/drivers/gpu/drm/drm_atomic_helper.c
>+++ b/drivers/gpu/drm/drm_atomic_helper.c
>@@ -3076,6 +3076,8 @@ void __drm_atomic_helper_plane_duplicate_state(struct
>drm_plane *plane,
>
> if (state->fb)
> drm_framebuffer_reference(state->fb);
>+
>+ state->fence = NULL;
> }
> EXPORT_SYMBOL(__drm_atomic_helper_plane_duplicate_state);
>
>@@ -3114,6 +3116,9 @@ void __drm_atomic_helper_plane_destroy_state(struct
>drm_plane_state *state)
> {
> if (state->fb)
> drm_framebuffer_unreference(state->fb);
>+
>+ if (state->fence)
>+ dma_fence_put(state->fence);
> }
> EXPORT_SYMBOL(__drm_atomic_helper_plane_destroy_state);
>
>diff --git a/drivers/gpu/drm/drm_crtc.c b/drivers/gpu/drm/drm_crtc.c
>index ce274ed..154e040 100644
>--- a/drivers/gpu/drm/drm_crtc.c
>+++ b/drivers/gpu/drm/drm_crtc.c
>@@ -397,6 +397,12 @@ static int drm_mode_create_standard_properties(struct
>drm_device *dev)
> return -ENOMEM;
> dev->mode_config.prop_fb_id = prop;
>
>+ prop = drm_property_create_signed_range(dev, DRM_MODE_PROP_ATOMIC,
>+ "IN_FENCE_FD", -1, INT_MAX);
>+ if (!prop)
>+
[PATCH] Gpu: drm: arm: - Fix possible dereference of NULL
Hi Shailendra,
On Fri, Nov 11, 2016 at 02:16:08PM +0530, Shailendra Verma wrote:
> From: "Shailendra Verma"
>
> There is possible dereference of NULL pointer if kmalloc fails.
You could add: ... when the function returns. From the patch itself it is
not clear where the problem is.
> So return NULL if kmalloc fails.
>
> Signed-off-by: Shailendra Verma
Acked-by: Liviu Dudau
Thanks for spotting this!
Liviu
> ---
> drivers/gpu/drm/arm/malidp_planes.c |3 +++
> 1 file changed, 3 insertions(+)
>
> diff --git a/drivers/gpu/drm/arm/malidp_planes.c
> b/drivers/gpu/drm/arm/malidp_planes.c
> index 82c193e..f769398 100644
> --- a/drivers/gpu/drm/arm/malidp_planes.c
> +++ b/drivers/gpu/drm/arm/malidp_planes.c
> @@ -54,6 +54,9 @@ struct drm_plane_state *malidp_duplicate_plane_state(struct
> drm_plane *plane)
> return NULL;
>
> state = kmalloc(sizeof(*state), GFP_KERNEL);
> + if (!state)
> + return NULL;
> +
> if (state) {
> m_state = to_malidp_plane_state(plane->state);
> __drm_atomic_helper_plane_duplicate_state(plane, &state->base);
> --
> 1.7.9.5
>
--
| I would like to |
| fix the world, |
| but they're not |
| giving me the |
\ source code! /
---
¯\_(ã)_/¯
[PATCH v8 3/3] drm/fence: add out-fences support
Hi Gustavo,
On Fri, Nov 11, 2016 at 02:16:09PM +0900, Gustavo Padovan wrote:
>From: Gustavo Padovan
>
>Support DRM out-fences by creating a sync_file with a fence for each CRTC
>that sets the OUT_FENCE_PTR property.
>
>We use the out_fence pointer received in the OUT_FENCE_PTR prop to send
>the sync_file fd back to userspace.
>
>The sync_file and fd are allocated/created before commit, but the
>fd_install operation only happens after we know that commit succeed.
>
>v2: Comment by Rob Clark:
> - Squash commit that adds DRM_MODE_ATOMIC_OUT_FENCE flag here.
>
>Comment by Daniel Vetter:
> - Add clean up code for out_fences
>
>v3: Comments by Daniel Vetter:
> - create DRM_MODE_ATOMIC_EVENT_MASK
> - userspace should fill out_fences_ptr with the crtc_ids for which
> it wants fences back.
>
>v4: Create OUT_FENCE_PTR properties and remove old approach.
>
>v5: Comments by Brian Starkey:
> - Remove extra fence_get() in atomic_ioctl()
> - Check ret before iterating on the crtc_state
> - check ret before fd_install
> - set fence_state to NULL at the beginning
> - check fence_state->out_fence_ptr before put_user()
> - change order of fput() and put_unused_fd() on failure
>
> - Add access_ok() check to the out_fence_ptr received
> - Rebase after fence -> dma_fence rename
> - Store out_fence_ptr in the drm_atomic_state
> - Split crtc_setup_out_fence()
> - return -1 as out_fence with TEST_ONLY flag
>
>v6: Comments by Daniel Vetter
> - Add prepare/unprepare_crtc_signaling()
> - move struct drm_out_fence_state to drm_atomic.c
> - mark get_crtc_fence() as static
>
>Comments by Brian Starkey
> - proper set fence_ptr fence_state array
> - isolate fence_idx increment
>
>- improve error handling
>
>v7: Comments by Daniel Vetter
> - remove prefix from internal functions
> - make out_fence_ptr an s64 pointer
> - degrade DRM_INFO to DRM_DEBUG_ATOMIC when put_user fail
> - fix doc issues
> - filter out OUT_FENCE_PTR == NULL and do fail in this case
Do *not* fail in this case?
> - add complete_crtc_signalling()
> - krealloc fence_state on demand
>
>Comment by Brian Starkey
> - remove unused crtc_state arg from get_out_fence()
>
>Signed-off-by: Gustavo Padovan
From an integration with writeback point of view, this looks fine to
me - I can add writeback to this easily.
A few comments below though:
>---
> drivers/gpu/drm/drm_atomic.c | 242 +++
> drivers/gpu/drm/drm_crtc.c | 8 ++
> include/drm/drm_atomic.h | 1 +
> include/drm/drm_crtc.h | 6 ++
> 4 files changed, 212 insertions(+), 45 deletions(-)
>
>diff --git a/drivers/gpu/drm/drm_atomic.c b/drivers/gpu/drm/drm_atomic.c
>index 8e26ad1..cd39f13 100644
>--- a/drivers/gpu/drm/drm_atomic.c
>+++ b/drivers/gpu/drm/drm_atomic.c
>@@ -290,6 +290,23 @@ drm_atomic_get_crtc_state(struct drm_atomic_state *state,
> }
> EXPORT_SYMBOL(drm_atomic_get_crtc_state);
>
>+static void set_out_fence_for_crtc(struct drm_atomic_state *state,
>+ struct drm_crtc *crtc, u64 __user *fence_ptr)
>+{
>+ state->crtcs[drm_crtc_index(crtc)].out_fence_ptr = fence_ptr;
>+}
>+
>+static u64 __user * get_out_fence_for_crtc(struct drm_atomic_state *state,
>+ struct drm_crtc *crtc)
>+{
>+ u64 __user *fence_ptr;
>+
>+ fence_ptr = state->crtcs[drm_crtc_index(crtc)].out_fence_ptr;
>+ state->crtcs[drm_crtc_index(crtc)].out_fence_ptr = NULL;
>+
>+ return fence_ptr;
>+}
>+
You missed a couple of s/u64/s64/ in the two functions above.
> /**
> * drm_atomic_set_mode_for_crtc - set mode for CRTC
> * @state: the CRTC whose incoming state to update
>@@ -491,6 +508,16 @@ int drm_atomic_crtc_set_property(struct drm_crtc *crtc,
> &replaced);
> state->color_mgmt_changed |= replaced;
> return ret;
>+ } else if (property == config->prop_out_fence_ptr) {
>+ s64 __user *fence_ptr = u64_to_user_ptr(val);
>+
>+ if (!fence_ptr)
>+ return 0;
>+
>+ if (!access_ok(VERIFY_WRITE, fence_ptr, sizeof(*fence_ptr)))
>+ return -EFAULT;
>+
>+ set_out_fence_for_crtc(state->state, crtc, fence_ptr);
> } else if (crtc->funcs->atomic_set_property)
> return crtc->funcs->atomic_set_property(crtc, state, property,
> val);
> else
>@@ -533,6 +560,8 @@ drm_atomic_crtc_get_property(struct drm_crtc *crtc,
> *val = (state->ctm) ? state->ctm->base.id : 0;
> else if (property == config->gamma_lut_property)
> *val = (state->gamma_lut) ? state->gamma_lut->base.id : 0;
>+ else if (property == config->prop_out_fence_ptr)
>+ *val = 0;
> else if (crtc->funcs->atomic_get_property)
> ret
[PATCH v9 00/10] MT2701 DRM support
This is MT2701 DRM support PATCH v9, based on 4.9-rc1. We add DSI interrupt control, transfer function for MIPI DSI panel support. Most codes are the same, except some register changed. For example: - DISP_OVL address offset changed, color format definition changed. - DISP_RDMA fifo size changed. - DISP_COLOR offset changed. - MIPI_TX setting changed. We add a new component DDP_COMPONENT_BLS, and the connections are updated. OVL -> RDMA -> COLOR -> BLS -> DSI RDMA -> DPI And we have shadow register support in MT2701. We remove dts patch from the patch series, which depends on MT2701 CCF and scpsys. Changes since v8: - enable 3 DSI interrupts only - move mtk_dsi_wait_for_irq_done() to the patch of irq control - use the name BLS in DRM driver part - move BLS declaration to a separate patch - update mtk_dsi_switch_to_cmd_mode() - update mtk_output_dsi_enable() and mtk_output_dsi_disable() Changes since v7: - Remove redundant codes - Move the definition of DDP_COMPONENT_BLS to patch of "drm/mediatek: update display module connections" - Move _dsi_irq_wait_queue into platform driver data - Move mtk_dsi_irq_data_clear() to patch of "drm/mediatek: add dsi interrupt control" - Add more descriptions in the commit messages Changes since v6: - Change data type of irq_data to u32 - Rewrite mtk_dsi_host_transfer() for simplify - Move some MIPI_TX config to patch of "drm/mediatek: add *driver_data for different hardware settings". - Remove device tree from this patch series Changes since v5: - Remove DPI device tree and compatible string - Use one wait queue to handle interrupt status - Update the interrupt check flow and DSI_INT_ALL_BITS - Use same function for host read/write command - various fixes Changes since v4: - Add messages when timeout in mtk_disp_mutex_acquire() - Add descriptions for DISP_REG_MUTEX registers - Move connection settings for display modules to a separate patch - Remove 'mt2701-disp-wdma' because it is unused - Move cleaning up and renaming to a separate patch - Use wait_event_interruptible_timeout() to replace polling - Remove irq_num from mtk_dsi structure - Remove redundant and debug codes Changes since v3: - Add DSI support for MIPI DSI panels - Update BLS binding to PWM nodes - Remove ufoe device nodes - Remove redundant parentheses - Remove global variable initialization Changes since v2: - Rename mtk_ddp_mux_sel to mtk_ddp_sout_sel - Update mt2701_mtk_ddp_ext components - Changed to prefix naming - Reorder the patch series - Use of_device_get_match_data() to get driver private data - Use iopoll macros to implement mtk_disp_mutex_acquire() - Removed empty device tree nodes Changes since v1: - Removed BLS bindings and codes, which belong to pwm driver - Moved mtk_disp_mutex_acquire() just before mtk_crtc_ddp_config() - Split patch into smaller parts - Added const keyword to constant structure - Removed codes for special memory align Thanks, yt.shen YT Shen (8): drm/mediatek: rename macros, add chip prefix drm/mediatek: add *driver_data for different hardware settings drm/mediatek: add shadow register support drm/mediatek: add BLS component drm/mediatek: update display module connections drm/mediatek: cleaning up and refine drm/mediatek: update DSI sub driver flow for sending commands to panel drm/mediatek: add support for Mediatek SoC MT2701 shaoming chen (2): drm/mediatek: add dsi interrupt control drm/mediatek: add dsi transfer function drivers/gpu/drm/mediatek/mtk_disp_ovl.c | 33 ++- drivers/gpu/drm/mediatek/mtk_disp_rdma.c| 17 +- drivers/gpu/drm/mediatek/mtk_drm_crtc.c | 76 +++-- drivers/gpu/drm/mediatek/mtk_drm_ddp.c | 138 ++--- drivers/gpu/drm/mediatek/mtk_drm_ddp.h | 2 + drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.c | 38 ++- drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.h | 15 + drivers/gpu/drm/mediatek/mtk_drm_drv.c | 54 +++- drivers/gpu/drm/mediatek/mtk_drm_drv.h | 9 + drivers/gpu/drm/mediatek/mtk_dsi.c | 429 drivers/gpu/drm/mediatek/mtk_mipi_tx.c | 70 +++-- 11 files changed, 715 insertions(+), 166 deletions(-) -- 1.9.1
[PATCH v9 01/10] drm/mediatek: rename macros, add chip prefix
Add MT8173 prefix for hardware related macros.
Signed-off-by: YT Shen
---
drivers/gpu/drm/mediatek/mtk_drm_ddp.c | 60 +-
1 file changed, 30 insertions(+), 30 deletions(-)
diff --git a/drivers/gpu/drm/mediatek/mtk_drm_ddp.c
b/drivers/gpu/drm/mediatek/mtk_drm_ddp.c
index 17ba935..2fc4321 100644
--- a/drivers/gpu/drm/mediatek/mtk_drm_ddp.c
+++ b/drivers/gpu/drm/mediatek/mtk_drm_ddp.c
@@ -36,21 +36,21 @@
#define DISP_REG_MUTEX_MOD(n) (0x2c + 0x20 * (n))
#define DISP_REG_MUTEX_SOF(n) (0x30 + 0x20 * (n))
-#define MUTEX_MOD_DISP_OVL0BIT(11)
-#define MUTEX_MOD_DISP_OVL1BIT(12)
-#define MUTEX_MOD_DISP_RDMA0 BIT(13)
-#define MUTEX_MOD_DISP_RDMA1 BIT(14)
-#define MUTEX_MOD_DISP_RDMA2 BIT(15)
-#define MUTEX_MOD_DISP_WDMA0 BIT(16)
-#define MUTEX_MOD_DISP_WDMA1 BIT(17)
-#define MUTEX_MOD_DISP_COLOR0 BIT(18)
-#define MUTEX_MOD_DISP_COLOR1 BIT(19)
-#define MUTEX_MOD_DISP_AAL BIT(20)
-#define MUTEX_MOD_DISP_GAMMA BIT(21)
-#define MUTEX_MOD_DISP_UFOEBIT(22)
-#define MUTEX_MOD_DISP_PWM0BIT(23)
-#define MUTEX_MOD_DISP_PWM1BIT(24)
-#define MUTEX_MOD_DISP_OD BIT(25)
+#define MT8173_MUTEX_MOD_DISP_OVL0 BIT(11)
+#define MT8173_MUTEX_MOD_DISP_OVL1 BIT(12)
+#define MT8173_MUTEX_MOD_DISP_RDMA0BIT(13)
+#define MT8173_MUTEX_MOD_DISP_RDMA1BIT(14)
+#define MT8173_MUTEX_MOD_DISP_RDMA2BIT(15)
+#define MT8173_MUTEX_MOD_DISP_WDMA0BIT(16)
+#define MT8173_MUTEX_MOD_DISP_WDMA1BIT(17)
+#define MT8173_MUTEX_MOD_DISP_COLOR0 BIT(18)
+#define MT8173_MUTEX_MOD_DISP_COLOR1 BIT(19)
+#define MT8173_MUTEX_MOD_DISP_AAL BIT(20)
+#define MT8173_MUTEX_MOD_DISP_GAMMABIT(21)
+#define MT8173_MUTEX_MOD_DISP_UFOE BIT(22)
+#define MT8173_MUTEX_MOD_DISP_PWM0 BIT(23)
+#define MT8173_MUTEX_MOD_DISP_PWM1 BIT(24)
+#define MT8173_MUTEX_MOD_DISP_OD BIT(25)
#define MUTEX_SOF_SINGLE_MODE 0
#define MUTEX_SOF_DSI0 1
@@ -80,21 +80,21 @@ struct mtk_ddp {
};
static const unsigned int mutex_mod[DDP_COMPONENT_ID_MAX] = {
- [DDP_COMPONENT_AAL] = MUTEX_MOD_DISP_AAL,
- [DDP_COMPONENT_COLOR0] = MUTEX_MOD_DISP_COLOR0,
- [DDP_COMPONENT_COLOR1] = MUTEX_MOD_DISP_COLOR1,
- [DDP_COMPONENT_GAMMA] = MUTEX_MOD_DISP_GAMMA,
- [DDP_COMPONENT_OD] = MUTEX_MOD_DISP_OD,
- [DDP_COMPONENT_OVL0] = MUTEX_MOD_DISP_OVL0,
- [DDP_COMPONENT_OVL1] = MUTEX_MOD_DISP_OVL1,
- [DDP_COMPONENT_PWM0] = MUTEX_MOD_DISP_PWM0,
- [DDP_COMPONENT_PWM1] = MUTEX_MOD_DISP_PWM1,
- [DDP_COMPONENT_RDMA0] = MUTEX_MOD_DISP_RDMA0,
- [DDP_COMPONENT_RDMA1] = MUTEX_MOD_DISP_RDMA1,
- [DDP_COMPONENT_RDMA2] = MUTEX_MOD_DISP_RDMA2,
- [DDP_COMPONENT_UFOE] = MUTEX_MOD_DISP_UFOE,
- [DDP_COMPONENT_WDMA0] = MUTEX_MOD_DISP_WDMA0,
- [DDP_COMPONENT_WDMA1] = MUTEX_MOD_DISP_WDMA1,
+ [DDP_COMPONENT_AAL] = MT8173_MUTEX_MOD_DISP_AAL,
+ [DDP_COMPONENT_COLOR0] = MT8173_MUTEX_MOD_DISP_COLOR0,
+ [DDP_COMPONENT_COLOR1] = MT8173_MUTEX_MOD_DISP_COLOR1,
+ [DDP_COMPONENT_GAMMA] = MT8173_MUTEX_MOD_DISP_GAMMA,
+ [DDP_COMPONENT_OD] = MT8173_MUTEX_MOD_DISP_OD,
+ [DDP_COMPONENT_OVL0] = MT8173_MUTEX_MOD_DISP_OVL0,
+ [DDP_COMPONENT_OVL1] = MT8173_MUTEX_MOD_DISP_OVL1,
+ [DDP_COMPONENT_PWM0] = MT8173_MUTEX_MOD_DISP_PWM0,
+ [DDP_COMPONENT_PWM1] = MT8173_MUTEX_MOD_DISP_PWM1,
+ [DDP_COMPONENT_RDMA0] = MT8173_MUTEX_MOD_DISP_RDMA0,
+ [DDP_COMPONENT_RDMA1] = MT8173_MUTEX_MOD_DISP_RDMA1,
+ [DDP_COMPONENT_RDMA2] = MT8173_MUTEX_MOD_DISP_RDMA2,
+ [DDP_COMPONENT_UFOE] = MT8173_MUTEX_MOD_DISP_UFOE,
+ [DDP_COMPONENT_WDMA0] = MT8173_MUTEX_MOD_DISP_WDMA0,
+ [DDP_COMPONENT_WDMA1] = MT8173_MUTEX_MOD_DISP_WDMA1,
};
static unsigned int mtk_ddp_mout_en(enum mtk_ddp_comp_id cur,
--
1.9.1
[PATCH v9 02/10] drm/mediatek: add *driver_data for different hardware settings
There are some hardware settings changed, between MT8173 & MT2701:
DISP_OVL address offset changed, color format definition changed.
DISP_RDMA fifo size changed.
DISP_COLOR offset changed.
MIPI_TX pll setting changed.
And add prefix for mtk_ddp_main & mtk_ddp_ext & mutex_mod.
Signed-off-by: YT Shen
---
drivers/gpu/drm/mediatek/mtk_disp_ovl.c | 27 ---
drivers/gpu/drm/mediatek/mtk_disp_rdma.c| 11 +--
drivers/gpu/drm/mediatek/mtk_drm_ddp.c | 11 +++
drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.c | 27 +--
drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.h | 13 +
drivers/gpu/drm/mediatek/mtk_drm_drv.c | 25 ++---
drivers/gpu/drm/mediatek/mtk_drm_drv.h | 8
drivers/gpu/drm/mediatek/mtk_mipi_tx.c | 24 +++-
8 files changed, 115 insertions(+), 31 deletions(-)
diff --git a/drivers/gpu/drm/mediatek/mtk_disp_ovl.c
b/drivers/gpu/drm/mediatek/mtk_disp_ovl.c
index 019b7ca..1139834 100644
--- a/drivers/gpu/drm/mediatek/mtk_disp_ovl.c
+++ b/drivers/gpu/drm/mediatek/mtk_disp_ovl.c
@@ -35,13 +35,10 @@
#define DISP_REG_OVL_PITCH(n) (0x0044 + 0x20 * (n))
#define DISP_REG_OVL_RDMA_CTRL(n) (0x00c0 + 0x20 * (n))
#define DISP_REG_OVL_RDMA_GMC(n) (0x00c8 + 0x20 * (n))
-#define DISP_REG_OVL_ADDR(n) (0x0f40 + 0x20 * (n))
#defineOVL_RDMA_MEM_GMC0x40402020
#define OVL_CON_BYTE_SWAP BIT(24)
-#define OVL_CON_CLRFMT_RGB565 (0 << 12)
-#define OVL_CON_CLRFMT_RGB888 (1 << 12)
#define OVL_CON_CLRFMT_RGBA(2 << 12)
#define OVL_CON_CLRFMT_ARGB(3 << 12)
#defineOVL_CON_AEN BIT(8)
@@ -137,18 +134,18 @@ static void mtk_ovl_layer_off(struct mtk_ddp_comp *comp,
unsigned int idx)
writel(0x0, comp->regs + DISP_REG_OVL_RDMA_CTRL(idx));
}
-static unsigned int ovl_fmt_convert(unsigned int fmt)
+static unsigned int ovl_fmt_convert(struct mtk_ddp_comp *comp, unsigned int
fmt)
{
switch (fmt) {
default:
case DRM_FORMAT_RGB565:
- return OVL_CON_CLRFMT_RGB565;
+ return comp->data->ovl.fmt_rgb565;
case DRM_FORMAT_BGR565:
- return OVL_CON_CLRFMT_RGB565 | OVL_CON_BYTE_SWAP;
+ return comp->data->ovl.fmt_rgb565 | OVL_CON_BYTE_SWAP;
case DRM_FORMAT_RGB888:
- return OVL_CON_CLRFMT_RGB888;
+ return comp->data->ovl.fmt_rgb888;
case DRM_FORMAT_BGR888:
- return OVL_CON_CLRFMT_RGB888 | OVL_CON_BYTE_SWAP;
+ return comp->data->ovl.fmt_rgb888 | OVL_CON_BYTE_SWAP;
case DRM_FORMAT_RGBX:
case DRM_FORMAT_RGBA:
return OVL_CON_CLRFMT_ARGB;
@@ -178,7 +175,7 @@ static void mtk_ovl_layer_config(struct mtk_ddp_comp *comp,
unsigned int idx,
if (!pending->enable)
mtk_ovl_layer_off(comp, idx);
- con = ovl_fmt_convert(fmt);
+ con = ovl_fmt_convert(comp, fmt);
if (idx != 0)
con |= OVL_CON_AEN | OVL_CON_ALPHA;
@@ -186,7 +183,8 @@ static void mtk_ovl_layer_config(struct mtk_ddp_comp *comp,
unsigned int idx,
writel_relaxed(pitch, comp->regs + DISP_REG_OVL_PITCH(idx));
writel_relaxed(src_size, comp->regs + DISP_REG_OVL_SRC_SIZE(idx));
writel_relaxed(offset, comp->regs + DISP_REG_OVL_OFFSET(idx));
- writel_relaxed(addr, comp->regs + DISP_REG_OVL_ADDR(idx));
+ writel_relaxed(addr, comp->regs + comp->data->ovl.addr_offset
+ + idx * 0x20);
if (pending->enable)
mtk_ovl_layer_on(comp, idx);
@@ -270,6 +268,8 @@ static int mtk_disp_ovl_probe(struct platform_device *pdev)
return ret;
}
+ priv->ddp_comp.data = of_device_get_match_data(dev);
+
platform_set_drvdata(pdev, priv);
ret = component_add(dev, &mtk_disp_ovl_component_ops);
@@ -286,8 +286,13 @@ static int mtk_disp_ovl_remove(struct platform_device
*pdev)
return 0;
}
+static const struct mtk_ddp_comp_driver_data mt8173_ovl_driver_data = {
+ .ovl = {0x0f40, 0, 1 << 12}
+};
+
static const struct of_device_id mtk_disp_ovl_driver_dt_match[] = {
- { .compatible = "mediatek,mt8173-disp-ovl", },
+ { .compatible = "mediatek,mt8173-disp-ovl",
+ .data = &mt8173_ovl_driver_data},
{},
};
MODULE_DEVICE_TABLE(of, mtk_disp_ovl_driver_dt_match);
diff --git a/drivers/gpu/drm/mediatek/mtk_disp_rdma.c
b/drivers/gpu/drm/mediatek/mtk_disp_rdma.c
index 0df05f9..b4225e2 100644
--- a/drivers/gpu/drm/mediatek/mtk_disp_rdma.c
+++ b/drivers/gpu/drm/mediatek/mtk_disp_rdma.c
@@ -123,7 +123,7 @@ static void mtk_rdma_config(struct mtk_ddp_comp *comp,
unsigned int width,
*/
threshold = width * height * vrefresh * 4 * 7 / 100;
reg = RDMA_FIFO_UNDERFLOW_EN |
- RDMA_FIFO_PSEUDO_SIZE(SZ_8K
[PATCH v9 03/10] drm/mediatek: add shadow register support
We need to acquire mutex before using the resources,
and need to release it after finished.
So we don't need to write registers in the blanking period.
Signed-off-by: YT Shen
---
drivers/gpu/drm/mediatek/mtk_drm_crtc.c | 76 -
drivers/gpu/drm/mediatek/mtk_drm_ddp.c | 25 +++
drivers/gpu/drm/mediatek/mtk_drm_ddp.h | 2 +
drivers/gpu/drm/mediatek/mtk_drm_drv.h | 1 +
4 files changed, 75 insertions(+), 29 deletions(-)
diff --git a/drivers/gpu/drm/mediatek/mtk_drm_crtc.c
b/drivers/gpu/drm/mediatek/mtk_drm_crtc.c
index 01a21dd..a4f2b3a 100644
--- a/drivers/gpu/drm/mediatek/mtk_drm_crtc.c
+++ b/drivers/gpu/drm/mediatek/mtk_drm_crtc.c
@@ -329,6 +329,42 @@ static void mtk_crtc_ddp_hw_fini(struct mtk_drm_crtc
*mtk_crtc)
pm_runtime_put(drm->dev);
}
+static void mtk_crtc_ddp_config(struct drm_crtc *crtc)
+{
+ struct mtk_drm_crtc *mtk_crtc = to_mtk_crtc(crtc);
+ struct mtk_crtc_state *state = to_mtk_crtc_state(mtk_crtc->base.state);
+ struct mtk_ddp_comp *ovl = mtk_crtc->ddp_comp[0];
+ unsigned int i;
+
+ /*
+* TODO: instead of updating the registers here, we should prepare
+* working registers in atomic_commit and let the hardware command
+* queue update module registers on vblank.
+*/
+ if (state->pending_config) {
+ mtk_ddp_comp_config(ovl, state->pending_width,
+ state->pending_height,
+ state->pending_vrefresh, 0);
+
+ state->pending_config = false;
+ }
+
+ if (mtk_crtc->pending_planes) {
+ for (i = 0; i < OVL_LAYER_NR; i++) {
+ struct drm_plane *plane = &mtk_crtc->planes[i];
+ struct mtk_plane_state *plane_state;
+
+ plane_state = to_mtk_plane_state(plane->state);
+
+ if (plane_state->pending.config) {
+ mtk_ddp_comp_layer_config(ovl, i, plane_state);
+ plane_state->pending.config = false;
+ }
+ }
+ mtk_crtc->pending_planes = false;
+ }
+}
+
static void mtk_drm_crtc_enable(struct drm_crtc *crtc)
{
struct mtk_drm_crtc *mtk_crtc = to_mtk_crtc(crtc);
@@ -405,6 +441,7 @@ static void mtk_drm_crtc_atomic_flush(struct drm_crtc *crtc,
struct drm_crtc_state *old_crtc_state)
{
struct mtk_drm_crtc *mtk_crtc = to_mtk_crtc(crtc);
+ struct mtk_drm_private *priv = crtc->dev->dev_private;
unsigned int pending_planes = 0;
int i;
@@ -423,6 +460,13 @@ static void mtk_drm_crtc_atomic_flush(struct drm_crtc
*crtc,
}
if (pending_planes)
mtk_crtc->pending_planes = true;
+
+ if (priv->data->shadow_register) {
+ mtk_disp_mutex_acquire(mtk_crtc->mutex);
+ mtk_crtc_ddp_config(crtc);
+ mtk_disp_mutex_release(mtk_crtc->mutex);
+ }
+
if (crtc->state->color_mgmt_changed)
for (i = 0; i < mtk_crtc->ddp_comp_nr; i++)
mtk_ddp_gamma_set(mtk_crtc->ddp_comp[i], crtc->state);
@@ -471,36 +515,10 @@ static int mtk_drm_crtc_init(struct drm_device *drm,
void mtk_crtc_ddp_irq(struct drm_crtc *crtc, struct mtk_ddp_comp *ovl)
{
struct mtk_drm_crtc *mtk_crtc = to_mtk_crtc(crtc);
- struct mtk_crtc_state *state = to_mtk_crtc_state(mtk_crtc->base.state);
- unsigned int i;
+ struct mtk_drm_private *priv = crtc->dev->dev_private;
- /*
-* TODO: instead of updating the registers here, we should prepare
-* working registers in atomic_commit and let the hardware command
-* queue update module registers on vblank.
-*/
- if (state->pending_config) {
- mtk_ddp_comp_config(ovl, state->pending_width,
- state->pending_height,
- state->pending_vrefresh, 0);
-
- state->pending_config = false;
- }
-
- if (mtk_crtc->pending_planes) {
- for (i = 0; i < OVL_LAYER_NR; i++) {
- struct drm_plane *plane = &mtk_crtc->planes[i];
- struct mtk_plane_state *plane_state;
-
- plane_state = to_mtk_plane_state(plane->state);
-
- if (plane_state->pending.config) {
- mtk_ddp_comp_layer_config(ovl, i, plane_state);
- plane_state->pending.config = false;
- }
- }
- mtk_crtc->pending_planes = false;
- }
+ if (!priv->data->shadow_register)
+ mtk_crtc_ddp_config(crtc);
mtk_drm_finish_page_flip(mtk_crtc);
}
diff --git a/drivers/gpu/drm/mediatek/mtk_drm_ddp.c
b/drivers/gpu/drm/mediatek/mtk_drm_ddp.c
index 8030769..b77d456 1
[PATCH v9 04/10] drm/mediatek: add BLS component
Add BLS component for PWM + GAMMA function
Signed-off-by: YT Shen
---
drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.c | 5 -
drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.h | 2 ++
2 files changed, 6 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.c
b/drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.c
index 661a4a0..b78b2e6 100644
--- a/drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.c
+++ b/drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.c
@@ -235,6 +235,7 @@ static void mtk_gamma_set(struct mtk_ddp_comp *comp,
[MTK_DISP_PWM] = "pwm",
[MTK_DISP_MUTEX] = "mutex",
[MTK_DISP_OD] = "od",
+ [MTK_DISP_BLS] = "bls",
};
struct mtk_ddp_comp_match {
@@ -245,6 +246,7 @@ struct mtk_ddp_comp_match {
static const struct mtk_ddp_comp_match mtk_ddp_matches[DDP_COMPONENT_ID_MAX] =
{
[DDP_COMPONENT_AAL] = { MTK_DISP_AAL, 0, &ddp_aal },
+ [DDP_COMPONENT_BLS] = { MTK_DISP_BLS, 0, NULL },
[DDP_COMPONENT_COLOR0] = { MTK_DISP_COLOR, 0, &ddp_color },
[DDP_COMPONENT_COLOR1] = { MTK_DISP_COLOR, 1, &ddp_color },
[DDP_COMPONENT_DPI0]= { MTK_DPI,0, NULL },
@@ -303,7 +305,8 @@ int mtk_ddp_comp_init(struct device *dev, struct
device_node *node,
comp->id = comp_id;
comp->funcs = funcs ?: mtk_ddp_matches[comp_id].funcs;
- if (comp_id == DDP_COMPONENT_DPI0 ||
+ if (comp_id == DDP_COMPONENT_BLS ||
+ comp_id == DDP_COMPONENT_DPI0 ||
comp_id == DDP_COMPONENT_DSI0 ||
comp_id == DDP_COMPONENT_PWM0) {
comp->regs = NULL;
diff --git a/drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.h
b/drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.h
index 2f6872a..30faf46 100644
--- a/drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.h
+++ b/drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.h
@@ -36,11 +36,13 @@ enum mtk_ddp_comp_type {
MTK_DISP_PWM,
MTK_DISP_MUTEX,
MTK_DISP_OD,
+ MTK_DISP_BLS,
MTK_DDP_COMP_TYPE_MAX,
};
enum mtk_ddp_comp_id {
DDP_COMPONENT_AAL,
+ DDP_COMPONENT_BLS,
DDP_COMPONENT_COLOR0,
DDP_COMPONENT_COLOR1,
DDP_COMPONENT_DPI0,
--
1.9.1
[PATCH v9 05/10] drm/mediatek: update display module connections
update connections for OVL, RDMA, BLS, DSI
Signed-off-by: YT Shen
---
drivers/gpu/drm/mediatek/mtk_drm_ddp.c | 25 +
1 file changed, 25 insertions(+)
diff --git a/drivers/gpu/drm/mediatek/mtk_drm_ddp.c
b/drivers/gpu/drm/mediatek/mtk_drm_ddp.c
index b77d456..a9b209c 100644
--- a/drivers/gpu/drm/mediatek/mtk_drm_ddp.c
+++ b/drivers/gpu/drm/mediatek/mtk_drm_ddp.c
@@ -32,6 +32,10 @@
#define DISP_REG_CONFIG_DISP_RDMA1_MOUT_EN 0x0c8
#define DISP_REG_CONFIG_MMSYS_CG_CON0 0x100
+#define DISP_REG_CONFIG_DISP_OVL_MOUT_EN 0x030
+#define DISP_REG_CONFIG_OUT_SEL0x04c
+#define DISP_REG_CONFIG_DSI_SEL0x050
+
#define DISP_REG_MUTEX_EN(n) (0x20 + 0x20 * (n))
#define DISP_REG_MUTEX(n) (0x24 + 0x20 * (n))
#define DISP_REG_MUTEX_RST(n) (0x28 + 0x20 * (n))
@@ -71,6 +75,10 @@
#define DPI0_SEL_IN_RDMA1 0x1
#define COLOR1_SEL_IN_OVL1 0x1
+#define OVL_MOUT_EN_RDMA 0x1
+#define BLS_TO_DSI_RDMA1_TO_DPI1 0x8
+#define DSI_SEL_IN_BLS 0x0
+
struct mtk_disp_mutex {
int id;
bool claimed;
@@ -111,6 +119,9 @@ static unsigned int mtk_ddp_mout_en(enum mtk_ddp_comp_id
cur,
if (cur == DDP_COMPONENT_OVL0 && next == DDP_COMPONENT_COLOR0) {
*addr = DISP_REG_CONFIG_DISP_OVL0_MOUT_EN;
value = OVL0_MOUT_EN_COLOR0;
+ } else if (cur == DDP_COMPONENT_OVL0 && next == DDP_COMPONENT_RDMA0) {
+ *addr = DISP_REG_CONFIG_DISP_OVL_MOUT_EN;
+ value = OVL_MOUT_EN_RDMA;
} else if (cur == DDP_COMPONENT_OD && next == DDP_COMPONENT_RDMA0) {
*addr = DISP_REG_CONFIG_DISP_OD_MOUT_EN;
value = OD_MOUT_EN_RDMA0;
@@ -148,6 +159,9 @@ static unsigned int mtk_ddp_sel_in(enum mtk_ddp_comp_id cur,
} else if (cur == DDP_COMPONENT_OVL1 && next == DDP_COMPONENT_COLOR1) {
*addr = DISP_REG_CONFIG_DISP_COLOR1_SEL_IN;
value = COLOR1_SEL_IN_OVL1;
+ } else if (cur == DDP_COMPONENT_BLS && next == DDP_COMPONENT_DSI0) {
+ *addr = DISP_REG_CONFIG_DSI_SEL;
+ value = DSI_SEL_IN_BLS;
} else {
value = 0;
}
@@ -155,6 +169,15 @@ static unsigned int mtk_ddp_sel_in(enum mtk_ddp_comp_id
cur,
return value;
}
+static void mtk_ddp_sout_sel(void __iomem *config_regs,
+enum mtk_ddp_comp_id cur,
+enum mtk_ddp_comp_id next)
+{
+ if (cur == DDP_COMPONENT_BLS && next == DDP_COMPONENT_DSI0)
+ writel_relaxed(BLS_TO_DSI_RDMA1_TO_DPI1,
+ config_regs + DISP_REG_CONFIG_OUT_SEL);
+}
+
void mtk_ddp_add_comp_to_path(void __iomem *config_regs,
enum mtk_ddp_comp_id cur,
enum mtk_ddp_comp_id next)
@@ -167,6 +190,8 @@ void mtk_ddp_add_comp_to_path(void __iomem *config_regs,
writel_relaxed(reg, config_regs + addr);
}
+ mtk_ddp_sout_sel(config_regs, cur, next);
+
value = mtk_ddp_sel_in(cur, next, &addr);
if (value) {
reg = readl_relaxed(config_regs + addr) | value;
--
1.9.1
[PATCH v9 06/10] drm/mediatek: cleaning up and refine
cleaning up unused define and refine function name and variable
Signed-off-by: shaoming chen
Signed-off-by: YT Shen
---
drivers/gpu/drm/mediatek/mtk_dsi.c | 77 --
drivers/gpu/drm/mediatek/mtk_mipi_tx.c | 8 ++--
2 files changed, 41 insertions(+), 44 deletions(-)
diff --git a/drivers/gpu/drm/mediatek/mtk_dsi.c
b/drivers/gpu/drm/mediatek/mtk_dsi.c
index 28b2044..4efeb38 100644
--- a/drivers/gpu/drm/mediatek/mtk_dsi.c
+++ b/drivers/gpu/drm/mediatek/mtk_dsi.c
@@ -27,9 +27,6 @@
#include "mtk_drm_ddp_comp.h"
-#define DSI_VIDEO_FIFO_DEPTH (1920 / 4)
-#define DSI_HOST_FIFO_DEPTH64
-
#define DSI_START 0x00
#define DSI_CON_CTRL 0x10
@@ -46,7 +43,7 @@
#define MIX_MODE BIT(17)
#define DSI_TXRX_CTRL 0x18
-#define VC_NUM (2 << 0)
+#define VC_NUM BIT(1)
#define LANE_NUM (0xf << 2)
#define DIS_EOTBIT(6)
#define NULL_ENBIT(7)
@@ -158,11 +155,11 @@ static void mtk_dsi_mask(struct mtk_dsi *dsi, u32 offset,
u32 mask, u32 data)
writel((temp & ~mask) | (data & mask), dsi->regs + offset);
}
-static void dsi_phy_timconfig(struct mtk_dsi *dsi)
+static void mtk_dsi_phy_timconfig(struct mtk_dsi *dsi)
{
u32 timcon0, timcon1, timcon2, timcon3;
- unsigned int ui, cycle_time;
- unsigned int lpx;
+ u32 ui, cycle_time;
+ u32 lpx;
ui = 1000 / dsi->data_rate + 0x01;
cycle_time = 8000 / dsi->data_rate + 0x01;
@@ -192,7 +189,7 @@ static void mtk_dsi_disable(struct mtk_dsi *dsi)
mtk_dsi_mask(dsi, DSI_CON_CTRL, DSI_EN, 0);
}
-static void mtk_dsi_reset(struct mtk_dsi *dsi)
+static void mtk_dsi_reset_engine(struct mtk_dsi *dsi)
{
mtk_dsi_mask(dsi, DSI_CON_CTRL, DSI_RESET, DSI_RESET);
mtk_dsi_mask(dsi, DSI_CON_CTRL, DSI_RESET, 0);
@@ -235,8 +232,8 @@ static int mtk_dsi_poweron(struct mtk_dsi *dsi)
}
mtk_dsi_enable(dsi);
- mtk_dsi_reset(dsi);
- dsi_phy_timconfig(dsi);
+ mtk_dsi_reset_engine(dsi);
+ mtk_dsi_phy_timconfig(dsi);
return 0;
@@ -249,33 +246,33 @@ static int mtk_dsi_poweron(struct mtk_dsi *dsi)
return ret;
}
-static void dsi_clk_ulp_mode_enter(struct mtk_dsi *dsi)
+static void mtk_dsi_clk_ulp_mode_enter(struct mtk_dsi *dsi)
{
mtk_dsi_mask(dsi, DSI_PHY_LCCON, LC_HS_TX_EN, 0);
mtk_dsi_mask(dsi, DSI_PHY_LCCON, LC_ULPM_EN, 0);
}
-static void dsi_clk_ulp_mode_leave(struct mtk_dsi *dsi)
+static void mtk_dsi_clk_ulp_mode_leave(struct mtk_dsi *dsi)
{
mtk_dsi_mask(dsi, DSI_PHY_LCCON, LC_ULPM_EN, 0);
mtk_dsi_mask(dsi, DSI_PHY_LCCON, LC_WAKEUP_EN, LC_WAKEUP_EN);
mtk_dsi_mask(dsi, DSI_PHY_LCCON, LC_WAKEUP_EN, 0);
}
-static void dsi_lane0_ulp_mode_enter(struct mtk_dsi *dsi)
+static void mtk_dsi_lane0_ulp_mode_enter(struct mtk_dsi *dsi)
{
mtk_dsi_mask(dsi, DSI_PHY_LD0CON, LD0_HS_TX_EN, 0);
mtk_dsi_mask(dsi, DSI_PHY_LD0CON, LD0_ULPM_EN, 0);
}
-static void dsi_lane0_ulp_mode_leave(struct mtk_dsi *dsi)
+static void mtk_dsi_lane0_ulp_mode_leave(struct mtk_dsi *dsi)
{
mtk_dsi_mask(dsi, DSI_PHY_LD0CON, LD0_ULPM_EN, 0);
mtk_dsi_mask(dsi, DSI_PHY_LD0CON, LD0_WAKEUP_EN, LD0_WAKEUP_EN);
mtk_dsi_mask(dsi, DSI_PHY_LD0CON, LD0_WAKEUP_EN, 0);
}
-static bool dsi_clk_hs_state(struct mtk_dsi *dsi)
+static bool mtk_dsi_clk_hs_state(struct mtk_dsi *dsi)
{
u32 tmp_reg1;
@@ -283,15 +280,15 @@ static bool dsi_clk_hs_state(struct mtk_dsi *dsi)
return ((tmp_reg1 & LC_HS_TX_EN) == 1) ? true : false;
}
-static void dsi_clk_hs_mode(struct mtk_dsi *dsi, bool enter)
+static void mtk_dsi_clk_hs_mode(struct mtk_dsi *dsi, bool enter)
{
- if (enter && !dsi_clk_hs_state(dsi))
+ if (enter && !mtk_dsi_clk_hs_state(dsi))
mtk_dsi_mask(dsi, DSI_PHY_LCCON, LC_HS_TX_EN, LC_HS_TX_EN);
- else if (!enter && dsi_clk_hs_state(dsi))
+ else if (!enter && mtk_dsi_clk_hs_state(dsi))
mtk_dsi_mask(dsi, DSI_PHY_LCCON, LC_HS_TX_EN, 0);
}
-static void dsi_set_mode(struct mtk_dsi *dsi)
+static void mtk_dsi_set_mode(struct mtk_dsi *dsi)
{
u32 vid_mode = CMD_MODE;
@@ -306,7 +303,7 @@ static void dsi_set_mode(struct mtk_dsi *dsi)
writel(vid_mode, dsi->regs + DSI_MODE_CTRL);
}
-static void dsi_ps_control_vact(struct mtk_dsi *dsi)
+static void mtk_dsi_ps_control_vact(struct mtk_dsi *dsi)
{
struct videomode *vm = &dsi->vm;
u32 dsi_buf_bpp, ps_wc;
@@ -340,7 +337,7 @@ static void dsi_ps_control_vact(struct mtk_dsi *dsi)
writel(ps_wc, dsi->regs + DSI_HSTX_CKL_WC);
}
-static void dsi_rxtx_control(struct mtk_dsi *dsi)
+static void mtk_dsi_rxtx_control(struct mtk_dsi *dsi)
{
u32 tmp_reg;
@@ -365,9 +362,9 @@ static void dsi_rxtx_control(struct mtk_dsi *dsi)
writel(tmp_reg, dsi->regs + DSI_TXRX_CTR
[PATCH v9 07/10] drm/mediatek: add dsi interrupt control
From: shaoming chen
add dsi interrupt control
Signed-off-by: shaoming chen
---
drivers/gpu/drm/mediatek/mtk_dsi.c | 93 ++
1 file changed, 93 insertions(+)
diff --git a/drivers/gpu/drm/mediatek/mtk_dsi.c
b/drivers/gpu/drm/mediatek/mtk_dsi.c
index 4efeb38..e5832837 100644
--- a/drivers/gpu/drm/mediatek/mtk_dsi.c
+++ b/drivers/gpu/drm/mediatek/mtk_dsi.c
@@ -18,6 +18,7 @@
#include
#include
#include
+#include
#include
#include
#include
@@ -29,6 +30,16 @@
#define DSI_START 0x00
+#define DSI_INTEN 0x08
+
+#define DSI_INTSTA 0x0c
+#define LPRX_RD_RDY_INT_FLAG BIT(0)
+#define CMD_DONE_INT_FLAG BIT(1)
+#define TE_RDY_INT_FLAGBIT(2)
+#define VM_DONE_INT_FLAG BIT(3)
+#define EXT_TE_RDY_INT_FLAGBIT(4)
+#define DSI_BUSY BIT(31)
+
#define DSI_CON_CTRL 0x10
#define DSI_RESET BIT(0)
#define DSI_EN BIT(1)
@@ -71,6 +82,9 @@
#define DSI_HSTX_CKL_WC0x64
+#define DSI_RACK 0x84
+#define RACK BIT(0)
+
#define DSI_PHY_LCCON 0x104
#define LC_HS_TX_ENBIT(0)
#define LC_ULPM_EN BIT(1)
@@ -131,6 +145,8 @@ struct mtk_dsi {
struct videomode vm;
int refcount;
bool enabled;
+ u32 irq_data;
+ wait_queue_head_t irq_wait_queue;
};
static inline struct mtk_dsi *encoder_to_dsi(struct drm_encoder *e)
@@ -437,6 +453,64 @@ static void mtk_dsi_start(struct mtk_dsi *dsi)
writel(1, dsi->regs + DSI_START);
}
+static void mtk_dsi_set_interrupt_enable(struct mtk_dsi *dsi)
+{
+ u32 inten = LPRX_RD_RDY_INT_FLAG | CMD_DONE_INT_FLAG | VM_DONE_INT_FLAG;
+
+ writel(inten, dsi->regs + DSI_INTEN);
+}
+
+static void mtk_dsi_irq_data_set(struct mtk_dsi *dsi, u32 irq_bit)
+{
+ dsi->irq_data |= irq_bit;
+}
+
+static __maybe_unused void mtk_dsi_irq_data_clear(struct mtk_dsi *dsi, u32
irq_bit)
+{
+ dsi->irq_data &= ~irq_bit;
+}
+
+static __maybe_unused s32 mtk_dsi_wait_for_irq_done(struct mtk_dsi *dsi, u32
irq_flag,
+unsigned int timeout)
+{
+ s32 ret = 0;
+ unsigned long jiffies = msecs_to_jiffies(timeout);
+
+ ret = wait_event_interruptible_timeout(dsi->irq_wait_queue,
+ dsi->irq_data & irq_flag,
+ jiffies);
+ if (ret == 0) {
+ dev_info(dsi->dev, "Wait DSI IRQ(0x%08x) Timeout\n", irq_flag);
+
+ mtk_dsi_enable(dsi);
+ mtk_dsi_reset_engine(dsi);
+ }
+
+ return ret;
+}
+
+static irqreturn_t mtk_dsi_irq(int irq, void *dev_id)
+{
+ struct mtk_dsi *dsi = dev_id;
+ u32 status, tmp;
+ u32 flag = LPRX_RD_RDY_INT_FLAG | CMD_DONE_INT_FLAG | VM_DONE_INT_FLAG;
+
+ status = readl(dsi->regs + DSI_INTSTA) & flag;
+
+ if (status) {
+ do {
+ mtk_dsi_mask(dsi, DSI_RACK, RACK, RACK);
+ tmp = readl(dsi->regs + DSI_INTSTA);
+ } while (tmp & DSI_BUSY);
+
+ mtk_dsi_mask(dsi, DSI_INTSTA, status, 0);
+ mtk_dsi_irq_data_set(dsi, status);
+ wake_up_interruptible(&dsi->irq_wait_queue);
+ }
+
+ return IRQ_HANDLED;
+}
+
static void mtk_dsi_poweroff(struct mtk_dsi *dsi)
{
if (WARN_ON(dsi->refcount == 0))
@@ -485,6 +559,7 @@ static void mtk_output_dsi_enable(struct mtk_dsi *dsi)
mtk_dsi_ps_control_vact(dsi);
mtk_dsi_config_vdo_timing(dsi);
+ mtk_dsi_set_interrupt_enable(dsi);
mtk_dsi_set_mode(dsi);
mtk_dsi_clk_hs_mode(dsi, 1);
@@ -793,6 +868,7 @@ static int mtk_dsi_probe(struct platform_device *pdev)
struct device *dev = &pdev->dev;
struct device_node *remote_node, *endpoint;
struct resource *regs;
+ int irq_num;
int comp_id;
int ret;
@@ -869,6 +945,23 @@ static int mtk_dsi_probe(struct platform_device *pdev)
return ret;
}
+ irq_num = platform_get_irq(pdev, 0);
+ if (irq_num < 0) {
+ dev_err(&pdev->dev, "failed to request dsi irq resource\n");
+ return -EPROBE_DEFER;
+ }
+
+ irq_set_status_flags(irq_num, IRQ_TYPE_LEVEL_LOW);
+ ret = devm_request_irq(&pdev->dev, irq_num, mtk_dsi_irq,
+ IRQF_TRIGGER_LOW, dev_name(&pdev->dev), dsi);
+ if (ret) {
+ dev_err(&pdev->dev, "failed to request mediatek dsi irq\n");
+ return -EPROBE_DEFER;
+ }
+ dev_info(dev, "dsi irq num is 0x%x\n", irq_num);
+
+ init_waitqueue_head(&dsi->irq_wait_queue);
+
platform_set_drvdata(pdev, dsi);
return component_add(&pdev->dev, &mtk_dsi_component_ops);
--
1.9.1
[PATCH v9 08/10] drm/mediatek: add dsi transfer function
From: shaoming chen
add dsi read/write commands for transfer function
Signed-off-by: shaoming chen
---
drivers/gpu/drm/mediatek/mtk_dsi.c | 168 -
1 file changed, 166 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/mediatek/mtk_dsi.c
b/drivers/gpu/drm/mediatek/mtk_dsi.c
index e5832837..860b84f 100644
--- a/drivers/gpu/drm/mediatek/mtk_dsi.c
+++ b/drivers/gpu/drm/mediatek/mtk_dsi.c
@@ -24,6 +24,7 @@
#include
#include
#include
+#include
#include
#include "mtk_drm_ddp_comp.h"
@@ -80,8 +81,16 @@
#define DSI_HBP_WC 0x54
#define DSI_HFP_WC 0x58
+#define DSI_CMDQ_SIZE 0x60
+#define CMDQ_SIZE 0x3f
+
#define DSI_HSTX_CKL_WC0x64
+#define DSI_RX_DATA0 0x74
+#define DSI_RX_DATA1 0x78
+#define DSI_RX_DATA2 0x7c
+#define DSI_RX_DATA3 0x80
+
#define DSI_RACK 0x84
#define RACK BIT(0)
@@ -117,8 +126,23 @@
#define CLK_HS_POST(0xff << 8)
#define CLK_HS_EXIT(0xff << 16)
+#define DSI_CMDQ0 0x180
+#define CONFIG (0xff << 0)
+#define SHORT_PACKET 0
+#define LONG_PACKET2
+#define BTABIT(2)
+#define DATA_ID(0xff << 8)
+#define DATA_0 (0xff << 16)
+#define DATA_1 (0xff << 24)
+
#define NS_TO_CYCLE(n, c)((n) / (c) + (((n) % (c)) ? 1 : 0))
+#define MTK_DSI_HOST_IS_READ(type) \
+ ((type == MIPI_DSI_GENERIC_READ_REQUEST_0_PARAM) || \
+ (type == MIPI_DSI_GENERIC_READ_REQUEST_1_PARAM) || \
+ (type == MIPI_DSI_GENERIC_READ_REQUEST_2_PARAM) || \
+ (type == MIPI_DSI_DCS_READ))
+
struct phy;
struct mtk_dsi {
@@ -465,12 +489,12 @@ static void mtk_dsi_irq_data_set(struct mtk_dsi *dsi, u32
irq_bit)
dsi->irq_data |= irq_bit;
}
-static __maybe_unused void mtk_dsi_irq_data_clear(struct mtk_dsi *dsi, u32
irq_bit)
+static void mtk_dsi_irq_data_clear(struct mtk_dsi *dsi, u32 irq_bit)
{
dsi->irq_data &= ~irq_bit;
}
-static __maybe_unused s32 mtk_dsi_wait_for_irq_done(struct mtk_dsi *dsi, u32
irq_flag,
+static s32 mtk_dsi_wait_for_irq_done(struct mtk_dsi *dsi, u32 irq_flag,
unsigned int timeout)
{
s32 ret = 0;
@@ -807,9 +831,149 @@ static int mtk_dsi_host_detach(struct mipi_dsi_host *host,
return 0;
}
+static void mtk_dsi_wait_for_idle(struct mtk_dsi *dsi)
+{
+ u32 timeout_ms = 50; /* total 1s ~ 2s timeout */
+
+ while (timeout_ms--) {
+ if (!(readl(dsi->regs + DSI_INTSTA) & DSI_BUSY))
+ break;
+
+ usleep_range(2, 4);
+ }
+
+ if (timeout_ms == 0) {
+ dev_info(dsi->dev, "polling dsi wait not busy timeout!\n");
+
+ mtk_dsi_enable(dsi);
+ mtk_dsi_reset_engine(dsi);
+ }
+}
+
+static u32 mtk_dsi_recv_cnt(u8 type, u8 *read_data)
+{
+ switch (type) {
+ case MIPI_DSI_RX_GENERIC_SHORT_READ_RESPONSE_1BYTE:
+ case MIPI_DSI_RX_DCS_SHORT_READ_RESPONSE_1BYTE:
+ return 1;
+ case MIPI_DSI_RX_GENERIC_SHORT_READ_RESPONSE_2BYTE:
+ case MIPI_DSI_RX_DCS_SHORT_READ_RESPONSE_2BYTE:
+ return 2;
+ case MIPI_DSI_RX_GENERIC_LONG_READ_RESPONSE:
+ case MIPI_DSI_RX_DCS_LONG_READ_RESPONSE:
+ return read_data[1] + read_data[2] * 16;
+ case MIPI_DSI_RX_ACKNOWLEDGE_AND_ERROR_REPORT:
+ DRM_INFO("type is 0x02, try again\n");
+ break;
+ default:
+ DRM_INFO("type(0x%x) cannot be non-recognite\n", type);
+ break;
+ }
+
+ return 0;
+}
+
+static void mtk_dsi_cmdq(struct mtk_dsi *dsi, const struct mipi_dsi_msg *msg)
+{
+ const char *tx_buf = msg->tx_buf;
+ u8 config, cmdq_size, cmdq_off, type = msg->type;
+ u32 reg_val, cmdq_mask, i;
+
+ if (MTK_DSI_HOST_IS_READ(type))
+ config = BTA;
+ else
+ config = (msg->tx_len > 2) ? LONG_PACKET : SHORT_PACKET;
+
+ if (msg->tx_len > 2) {
+ cmdq_size = 1 + (msg->tx_len + 3) / 4;
+ cmdq_off = 4;
+ cmdq_mask = CONFIG | DATA_ID | DATA_0 | DATA_1;
+ reg_val = (msg->tx_len << 16) | (type << 8) | config;
+ } else {
+ cmdq_size = 1;
+ cmdq_off = 2;
+ cmdq_mask = CONFIG | DATA_ID;
+ reg_val = (type << 8) | config;
+ }
+
+ for (i = 0; i < msg->tx_len; i++)
+ writeb(tx_buf[i], dsi->regs + DSI_CMDQ0 + cmdq_off + i);
+
+ mtk_dsi_mask(dsi, DSI_CMDQ0, cmdq_mask, reg_val);
+ mtk_dsi_mask(dsi, DSI_CMDQ_SIZE, CMDQ_SIZE, cmdq_size);
+}
+
+static ssize_t mtk_dsi_host_send_cmd(struct mtk_dsi *dsi,
+
[PATCH v9 09/10] drm/mediatek: update DSI sub driver flow for sending commands to panel
This patch update enable/disable flow of DSI module and MIPI TX module.
Original flow works on there is a bridge chip: DSI -> bridge -> panel.
In this case: DSI -> panel, the DSI sub driver flow should be updated.
We need to initialize DSI first so that we can send commands to panel.
Signed-off-by: shaoming chen
Signed-off-by: YT Shen
---
drivers/gpu/drm/mediatek/mtk_dsi.c | 110 ++---
drivers/gpu/drm/mediatek/mtk_mipi_tx.c | 32 +-
2 files changed, 103 insertions(+), 39 deletions(-)
diff --git a/drivers/gpu/drm/mediatek/mtk_dsi.c
b/drivers/gpu/drm/mediatek/mtk_dsi.c
index 860b84f..12a1206 100644
--- a/drivers/gpu/drm/mediatek/mtk_dsi.c
+++ b/drivers/gpu/drm/mediatek/mtk_dsi.c
@@ -94,6 +94,8 @@
#define DSI_RACK 0x84
#define RACK BIT(0)
+#define DSI_MEM_CONTI 0x90
+
#define DSI_PHY_LCCON 0x104
#define LC_HS_TX_ENBIT(0)
#define LC_ULPM_EN BIT(1)
@@ -126,6 +128,10 @@
#define CLK_HS_POST(0xff << 8)
#define CLK_HS_EXIT(0xff << 16)
+#define DSI_VM_CMD_CON 0x130
+#define VM_CMD_EN BIT(0)
+#define TS_VFP_EN BIT(5)
+
#define DSI_CMDQ0 0x180
#define CONFIG (0xff << 0)
#define SHORT_PACKET 0
@@ -219,12 +225,12 @@ static void mtk_dsi_phy_timconfig(struct mtk_dsi *dsi)
writel(timcon3, dsi->regs + DSI_PHY_TIMECON3);
}
-static void mtk_dsi_enable(struct mtk_dsi *dsi)
+static void mtk_dsi_engine_enable(struct mtk_dsi *dsi)
{
mtk_dsi_mask(dsi, DSI_CON_CTRL, DSI_EN, DSI_EN);
}
-static void mtk_dsi_disable(struct mtk_dsi *dsi)
+static void mtk_dsi_engine_disable(struct mtk_dsi *dsi)
{
mtk_dsi_mask(dsi, DSI_CON_CTRL, DSI_EN, 0);
}
@@ -249,7 +255,9 @@ static int mtk_dsi_poweron(struct mtk_dsi *dsi)
* mipi_ratio is mipi clk coefficient for balance the pixel clk in mipi.
* we set mipi_ratio is 1.05.
*/
- dsi->data_rate = dsi->vm.pixelclock * 3 * 21 / (1 * 1000 * 10);
+ dsi->data_rate = dsi->vm.pixelclock * 12 * 21;
+ dsi->data_rate /= (dsi->lanes * 1000 * 10);
+ dev_info(dev, "set mipitx's data rate: %dMHz\n", dsi->data_rate);
ret = clk_set_rate(dsi->hs_clk, dsi->data_rate * 100);
if (ret < 0) {
@@ -271,7 +279,7 @@ static int mtk_dsi_poweron(struct mtk_dsi *dsi)
goto err_disable_engine_clk;
}
- mtk_dsi_enable(dsi);
+ mtk_dsi_engine_enable(dsi);
mtk_dsi_reset_engine(dsi);
mtk_dsi_phy_timconfig(dsi);
@@ -289,7 +297,7 @@ static int mtk_dsi_poweron(struct mtk_dsi *dsi)
static void mtk_dsi_clk_ulp_mode_enter(struct mtk_dsi *dsi)
{
mtk_dsi_mask(dsi, DSI_PHY_LCCON, LC_HS_TX_EN, 0);
- mtk_dsi_mask(dsi, DSI_PHY_LCCON, LC_ULPM_EN, 0);
+ mtk_dsi_mask(dsi, DSI_PHY_LCCON, LC_ULPM_EN, LC_ULPM_EN);
}
static void mtk_dsi_clk_ulp_mode_leave(struct mtk_dsi *dsi)
@@ -302,7 +310,7 @@ static void mtk_dsi_clk_ulp_mode_leave(struct mtk_dsi *dsi)
static void mtk_dsi_lane0_ulp_mode_enter(struct mtk_dsi *dsi)
{
mtk_dsi_mask(dsi, DSI_PHY_LD0CON, LD0_HS_TX_EN, 0);
- mtk_dsi_mask(dsi, DSI_PHY_LD0CON, LD0_ULPM_EN, 0);
+ mtk_dsi_mask(dsi, DSI_PHY_LD0CON, LD0_ULPM_EN, LD0_ULPM_EN);
}
static void mtk_dsi_lane0_ulp_mode_leave(struct mtk_dsi *dsi)
@@ -338,11 +346,21 @@ static void mtk_dsi_set_mode(struct mtk_dsi *dsi)
if ((dsi->mode_flags & MIPI_DSI_MODE_VIDEO_BURST) &&
!(dsi->mode_flags & MIPI_DSI_MODE_VIDEO_SYNC_PULSE))
vid_mode = BURST_MODE;
+ else
+ vid_mode = SYNC_EVENT_MODE;
}
writel(vid_mode, dsi->regs + DSI_MODE_CTRL);
}
+static void mtk_dsi_set_vm_cmd(struct mtk_dsi *dsi)
+{
+ writel(0x3c, dsi->regs + DSI_MEM_CONTI);
+
+ mtk_dsi_mask(dsi, DSI_VM_CMD_CON, VM_CMD_EN, VM_CMD_EN);
+ mtk_dsi_mask(dsi, DSI_VM_CMD_CON, TS_VFP_EN, TS_VFP_EN);
+}
+
static void mtk_dsi_ps_control_vact(struct mtk_dsi *dsi)
{
struct videomode *vm = &dsi->vm;
@@ -399,6 +417,9 @@ static void mtk_dsi_rxtx_control(struct mtk_dsi *dsi)
break;
}
+ tmp_reg |= (dsi->mode_flags & MIPI_DSI_CLOCK_NON_CONTINUOUS) << 6;
+ tmp_reg |= (dsi->mode_flags & MIPI_DSI_MODE_EOT_PACKET) >> 3;
+
writel(tmp_reg, dsi->regs + DSI_TXRX_CTRL);
}
@@ -477,6 +498,16 @@ static void mtk_dsi_start(struct mtk_dsi *dsi)
writel(1, dsi->regs + DSI_START);
}
+static void mtk_dsi_stop(struct mtk_dsi *dsi)
+{
+ writel(0, dsi->regs + DSI_START);
+}
+
+static void mtk_dsi_set_cmd_mode(struct mtk_dsi *dsi)
+{
+ writel(CMD_MODE, dsi->regs + DSI_MODE_CTRL);
+}
+
static void mtk_dsi_set_interrupt_enable(struct mtk_dsi *dsi)
{
u32 inten = LPRX_RD_RDY_INT_FLAG | CMD_DONE_INT_FLAG | VM_DONE_INT_FLAG;
@@ -506,7 +537,
[PATCH v9 10/10] drm/mediatek: add support for Mediatek SoC MT2701
This patch add support for the Mediatek MT2701 DISP subsystem.
There is only one OVL engine in MT2701.
Signed-off-by: YT Shen
---
drivers/gpu/drm/mediatek/mtk_disp_ovl.c | 6 ++
drivers/gpu/drm/mediatek/mtk_disp_rdma.c| 6 ++
drivers/gpu/drm/mediatek/mtk_drm_ddp.c | 17 +
drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.c | 6 ++
drivers/gpu/drm/mediatek/mtk_drm_drv.c | 29 +
drivers/gpu/drm/mediatek/mtk_dsi.c | 1 +
drivers/gpu/drm/mediatek/mtk_mipi_tx.c | 6 ++
7 files changed, 71 insertions(+)
diff --git a/drivers/gpu/drm/mediatek/mtk_disp_ovl.c
b/drivers/gpu/drm/mediatek/mtk_disp_ovl.c
index 1139834..d174905 100644
--- a/drivers/gpu/drm/mediatek/mtk_disp_ovl.c
+++ b/drivers/gpu/drm/mediatek/mtk_disp_ovl.c
@@ -286,11 +286,17 @@ static int mtk_disp_ovl_remove(struct platform_device
*pdev)
return 0;
}
+static const struct mtk_ddp_comp_driver_data mt2701_ovl_driver_data = {
+ .ovl = {0x0040, 1 << 12, 0}
+};
+
static const struct mtk_ddp_comp_driver_data mt8173_ovl_driver_data = {
.ovl = {0x0f40, 0, 1 << 12}
};
static const struct of_device_id mtk_disp_ovl_driver_dt_match[] = {
+ { .compatible = "mediatek,mt2701-disp-ovl",
+ .data = &mt2701_ovl_driver_data},
{ .compatible = "mediatek,mt8173-disp-ovl",
.data = &mt8173_ovl_driver_data},
{},
diff --git a/drivers/gpu/drm/mediatek/mtk_disp_rdma.c
b/drivers/gpu/drm/mediatek/mtk_disp_rdma.c
index b4225e2..5d363de 100644
--- a/drivers/gpu/drm/mediatek/mtk_disp_rdma.c
+++ b/drivers/gpu/drm/mediatek/mtk_disp_rdma.c
@@ -226,11 +226,17 @@ static int mtk_disp_rdma_remove(struct platform_device
*pdev)
return 0;
}
+static const struct mtk_ddp_comp_driver_data mt2701_rdma_driver_data = {
+ .rdma_fifo_pseudo_size = SZ_4K,
+};
+
static const struct mtk_ddp_comp_driver_data mt8173_rdma_driver_data = {
.rdma_fifo_pseudo_size = SZ_8K,
};
static const struct of_device_id mtk_disp_rdma_driver_dt_match[] = {
+ { .compatible = "mediatek,mt2701-disp-rdma",
+ .data = &mt2701_rdma_driver_data},
{ .compatible = "mediatek,mt8173-disp-rdma",
.data = &mt8173_rdma_driver_data},
{},
diff --git a/drivers/gpu/drm/mediatek/mtk_drm_ddp.c
b/drivers/gpu/drm/mediatek/mtk_drm_ddp.c
index a9b209c..8130f3d 100644
--- a/drivers/gpu/drm/mediatek/mtk_drm_ddp.c
+++ b/drivers/gpu/drm/mediatek/mtk_drm_ddp.c
@@ -60,6 +60,13 @@
#define MT8173_MUTEX_MOD_DISP_PWM1 BIT(24)
#define MT8173_MUTEX_MOD_DISP_OD BIT(25)
+#define MT2701_MUTEX_MOD_DISP_OVL BIT(3)
+#define MT2701_MUTEX_MOD_DISP_WDMA BIT(6)
+#define MT2701_MUTEX_MOD_DISP_COLORBIT(7)
+#define MT2701_MUTEX_MOD_DISP_BLS BIT(9)
+#define MT2701_MUTEX_MOD_DISP_RDMA0BIT(10)
+#define MT2701_MUTEX_MOD_DISP_RDMA1BIT(12)
+
#define MUTEX_SOF_SINGLE_MODE 0
#define MUTEX_SOF_DSI0 1
#define MUTEX_SOF_DSI1 2
@@ -92,6 +99,15 @@ struct mtk_ddp {
const unsigned int *mutex_mod;
};
+static const unsigned int mt2701_mutex_mod[DDP_COMPONENT_ID_MAX] = {
+ [DDP_COMPONENT_BLS] = MT2701_MUTEX_MOD_DISP_BLS,
+ [DDP_COMPONENT_COLOR0] = MT2701_MUTEX_MOD_DISP_COLOR,
+ [DDP_COMPONENT_OVL0] = MT2701_MUTEX_MOD_DISP_OVL,
+ [DDP_COMPONENT_RDMA0] = MT2701_MUTEX_MOD_DISP_RDMA0,
+ [DDP_COMPONENT_RDMA1] = MT2701_MUTEX_MOD_DISP_RDMA1,
+ [DDP_COMPONENT_WDMA0] = MT2701_MUTEX_MOD_DISP_WDMA,
+};
+
static const unsigned int mt8173_mutex_mod[DDP_COMPONENT_ID_MAX] = {
[DDP_COMPONENT_AAL] = MT8173_MUTEX_MOD_DISP_AAL,
[DDP_COMPONENT_COLOR0] = MT8173_MUTEX_MOD_DISP_COLOR0,
@@ -390,6 +406,7 @@ static int mtk_ddp_remove(struct platform_device *pdev)
}
static const struct of_device_id ddp_driver_dt_match[] = {
+ { .compatible = "mediatek,mt2701-disp-mutex", .data = mt2701_mutex_mod},
{ .compatible = "mediatek,mt8173-disp-mutex", .data = mt8173_mutex_mod},
{},
};
diff --git a/drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.c
b/drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.c
index b78b2e6..60d4783 100644
--- a/drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.c
+++ b/drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.c
@@ -265,11 +265,17 @@ struct mtk_ddp_comp_match {
[DDP_COMPONENT_WDMA1] = { MTK_DISP_WDMA, 1, NULL },
};
+static const struct mtk_ddp_comp_driver_data mt2701_color_driver_data = {
+ .color_offset = 0x0f00,
+};
+
static const struct mtk_ddp_comp_driver_data mt8173_color_driver_data = {
.color_offset = 0x0c00,
};
static const struct of_device_id mtk_disp_color_driver_dt_match[] = {
+ { .compatible = "mediatek,mt2701-disp-color",
+ .data = &mt2701_color_driver_data},
{ .compatible = "mediatek,mt8173-disp-color",
.data = &mt8173_color_driver_data},
{},
diff --git a/drivers/gpu/
[PATCH v6 2/9] drm/hisilicon/hibmc: Add video memory management
On Fri, Nov 11, 2016 at 6:16 AM, Rongrong Zou wrote:
> å¨ 2016/11/11 1:35, Sean Paul åé:
>>
>> On Fri, Oct 28, 2016 at 3:27 AM, Rongrong Zou
>> wrote:
>>>
>>> Hibmc have 32m video memory which can be accessed through PCIe by host,
>>> we use ttm to manage these memory.
>>>
>>> Signed-off-by: Rongrong Zou
>>> ---
>>> drivers/gpu/drm/hisilicon/hibmc/Kconfig | 1 +
>>> drivers/gpu/drm/hisilicon/hibmc/Makefile| 2 +-
>>> drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_drv.c | 12 +
>>> drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_drv.h | 46 +++
>>> drivers/gpu/drm/hisilicon/hibmc/hibmc_ttm.c | 490
>>>
>>> 5 files changed, 550 insertions(+), 1 deletion(-)
>>> create mode 100644 drivers/gpu/drm/hisilicon/hibmc/hibmc_ttm.c
>>>
>>> diff --git a/drivers/gpu/drm/hisilicon/hibmc/Kconfig
>>> b/drivers/gpu/drm/hisilicon/hibmc/Kconfig
>>> index a9af90d..bcb8c18 100644
>>> --- a/drivers/gpu/drm/hisilicon/hibmc/Kconfig
>>> +++ b/drivers/gpu/drm/hisilicon/hibmc/Kconfig
>>> @@ -1,6 +1,7 @@
>>> config DRM_HISI_HIBMC
>>> tristate "DRM Support for Hisilicon Hibmc"
>>> depends on DRM && PCI
>>> + select DRM_TTM
>>>
>>> help
>>>Choose this option if you have a Hisilicon Hibmc soc chipset.
>>> diff --git a/drivers/gpu/drm/hisilicon/hibmc/Makefile
>>> b/drivers/gpu/drm/hisilicon/hibmc/Makefile
>>> index 97cf4a0..d5c40b8 100644
>>> --- a/drivers/gpu/drm/hisilicon/hibmc/Makefile
>>> +++ b/drivers/gpu/drm/hisilicon/hibmc/Makefile
>>> @@ -1,5 +1,5 @@
>>> ccflags-y := -Iinclude/drm
>>> -hibmc-drm-y := hibmc_drm_drv.o hibmc_drm_power.o
>>> +hibmc-drm-y := hibmc_drm_drv.o hibmc_drm_power.o hibmc_ttm.o
>>>
>>> obj-$(CONFIG_DRM_HISI_HIBMC) +=hibmc-drm.o
>>> #obj-y += hibmc-drm.o
>>> diff --git a/drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_drv.c
>>> b/drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_drv.c
>>> index 4669d42..81f4301 100644
>>> --- a/drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_drv.c
>>> +++ b/drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_drv.c
>>> @@ -31,6 +31,7 @@
>>> #ifdef CONFIG_COMPAT
>>> .compat_ioctl = drm_compat_ioctl,
>>> #endif
>>> + .mmap = hibmc_mmap,
>>> .poll = drm_poll,
>>> .read = drm_read,
>>> .llseek = no_llseek,
>>> @@ -46,6 +47,8 @@ static void hibmc_disable_vblank(struct drm_device
>>> *dev, unsigned int pipe)
>>> }
>>>
>>> static struct drm_driver hibmc_driver = {
>>> + .driver_features= DRIVER_GEM,
>>> +
>>
>>
>> nit: extra space
>>
>>> .fops = &hibmc_fops,
>>> .name = "hibmc",
>>> .date = "20160828",
>>> @@ -55,6 +58,10 @@ static void hibmc_disable_vblank(struct drm_device
>>> *dev, unsigned int pipe)
>>> .get_vblank_counter = drm_vblank_no_hw_counter,
>>> .enable_vblank = hibmc_enable_vblank,
>>> .disable_vblank = hibmc_disable_vblank,
>>> + .gem_free_object_unlocked = hibmc_gem_free_object,
>>> + .dumb_create= hibmc_dumb_create,
>>> + .dumb_map_offset= hibmc_dumb_mmap_offset,
>>> + .dumb_destroy = drm_gem_dumb_destroy,
>>> };
>>>
>>> static int hibmc_pm_suspend(struct device *dev)
>>> @@ -163,6 +170,7 @@ static int hibmc_unload(struct drm_device *dev)
>>> {
>>> struct hibmc_drm_device *hidev = dev->dev_private;
>>>
>>> + hibmc_mm_fini(hidev);
>>> hibmc_hw_fini(hidev);
>>> dev->dev_private = NULL;
>>> return 0;
>>> @@ -183,6 +191,10 @@ static int hibmc_load(struct drm_device *dev,
>>> unsigned long flags)
>>> if (ret)
>>> goto err;
>>>
>>> + ret = hibmc_mm_init(hidev);
>>> + if (ret)
>>> + goto err;
>>> +
>>> return 0;
>>>
>>> err:
>>> diff --git a/drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_drv.h
>>> b/drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_drv.h
>>> index 0037341..db8d80e 100644
>>> --- a/drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_drv.h
>>> +++ b/drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_drv.h
>>> @@ -20,6 +20,8 @@
>>> #define HIBMC_DRM_DRV_H
>>>
>>> #include
>>> +#include
>>> +#include
>>
>>
>> nit: alphabetize
>
>
> will fix it, thanks.
>
>>
>>>
>>> struct hibmc_drm_device {
>>> /* hw */
>>> @@ -30,6 +32,50 @@ struct hibmc_drm_device {
>>>
>>> /* drm */
>>> struct drm_device *dev;
>>> +
>>> + /* ttm */
>>> + struct {
>>> + struct drm_global_reference mem_global_ref;
>>> + struct ttm_bo_global_ref bo_global_ref;
>>> + struct ttm_bo_device bdev;
>>> + bool initialized;
>>> + } ttm;
>>
>>
>> I don't think you gain anything other than keystrokes from the substruct
>
>
> I'm sorry i didn't catch you, i looked at the all drivers used ttm such
> as ast/bochs/cirrus/mgag200/qxl/virtio_gpu, they all embedded
[PATCH v6 3/9] drm/hisilicon/hibmc: Add support for frame buffer
On Fri, Nov 11, 2016 at 8:16 AM, Rongrong Zou wrote:
> å¨ 2016/11/11 2:30, Sean Paul åé:
>>
>> On Fri, Oct 28, 2016 at 3:27 AM, Rongrong Zou
>> wrote:
>>>
>>> Add support for fbdev and kms fb management.
>>>
>>> Signed-off-by: Rongrong Zou
>>> ---
>>> drivers/gpu/drm/hisilicon/hibmc/Makefile | 2 +-
>>> drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_drv.c | 17 ++
>>> drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_drv.h | 24 ++
>>> drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_fbdev.c | 255
>>> ++
>>> drivers/gpu/drm/hisilicon/hibmc/hibmc_ttm.c | 66 ++
>>> 5 files changed, 363 insertions(+), 1 deletion(-)
>>> create mode 100644 drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_fbdev.c
>>>
>>> diff --git a/drivers/gpu/drm/hisilicon/hibmc/Makefile
>>> b/drivers/gpu/drm/hisilicon/hibmc/Makefile
>>> index d5c40b8..810a37e 100644
>>> --- a/drivers/gpu/drm/hisilicon/hibmc/Makefile
>>> +++ b/drivers/gpu/drm/hisilicon/hibmc/Makefile
>>> @@ -1,5 +1,5 @@
>>> ccflags-y := -Iinclude/drm
>>> -hibmc-drm-y := hibmc_drm_drv.o hibmc_drm_power.o hibmc_ttm.o
>>> +hibmc-drm-y := hibmc_drm_drv.o hibmc_drm_fbdev.o hibmc_drm_power.o
>>> hibmc_ttm.o
>>>
>>> obj-$(CONFIG_DRM_HISI_HIBMC) +=hibmc-drm.o
>>> #obj-y += hibmc-drm.o
>>> diff --git a/drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_drv.c
>>> b/drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_drv.c
>>> index 81f4301..5ac7a7e 100644
>>> --- a/drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_drv.c
>>> +++ b/drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_drv.c
>>> @@ -66,11 +66,23 @@ static void hibmc_disable_vblank(struct drm_device
>>> *dev, unsigned int pipe)
>>>
>>> static int hibmc_pm_suspend(struct device *dev)
>>> {
>>> + struct pci_dev *pdev = to_pci_dev(dev);
>>> + struct drm_device *drm_dev = pci_get_drvdata(pdev);
>>> + struct hibmc_drm_device *hidev = drm_dev->dev_private;
>>> +
>>> + drm_fb_helper_set_suspend_unlocked(&hidev->fbdev->helper, 1);
>>> +
>>
>>
>> We have atomic helpers for suspend/resume now. Please use those.
>
>
> drm_atomic_helper_suspend/resume()?
>
Correct
>
>>
>>> return 0;
>>> }
>>>
>>> static int hibmc_pm_resume(struct device *dev)
>>> {
>>> + struct pci_dev *pdev = to_pci_dev(dev);
>>> + struct drm_device *drm_dev = pci_get_drvdata(pdev);
>>> + struct hibmc_drm_device *hidev = drm_dev->dev_private;
>>> +
>>> + drm_fb_helper_set_suspend_unlocked(&hidev->fbdev->helper, 0);
>>> +
>>> return 0;
>>> }
>>>
>>> @@ -170,6 +182,7 @@ static int hibmc_unload(struct drm_device *dev)
>>> {
>>> struct hibmc_drm_device *hidev = dev->dev_private;
>>>
>>> + hibmc_fbdev_fini(hidev);
>>> hibmc_mm_fini(hidev);
>>> hibmc_hw_fini(hidev);
>>> dev->dev_private = NULL;
>>> @@ -195,6 +208,10 @@ static int hibmc_load(struct drm_device *dev,
>>> unsigned long flags)
>>> if (ret)
>>> goto err;
>>>
>>> + ret = hibmc_fbdev_init(hidev);
>>> + if (ret)
>>> + goto err;
>>> +
>>> return 0;
>>>
>>> err:
>>> diff --git a/drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_drv.h
>>> b/drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_drv.h
>>> index db8d80e..a40e9a7 100644
>>> --- a/drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_drv.h
>>> +++ b/drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_drv.h
>>> @@ -20,9 +20,22 @@
>>> #define HIBMC_DRM_DRV_H
>>>
>>> #include
>>> +#include
>>> #include
>>> #include
>>>
>>> +struct hibmc_framebuffer {
>>> + struct drm_framebuffer fb;
>>> + struct drm_gem_object *obj;
>>> + bool is_fbdev_fb;
>>> +};
>>> +
>>> +struct hibmc_fbdev {
>>> + struct drm_fb_helper helper;
>>> + struct hibmc_framebuffer *fb;
>>> + int size;
>>> +};
>>> +
>>> struct hibmc_drm_device {
>>> /* hw */
>>> void __iomem *mmio;
>>> @@ -41,9 +54,13 @@ struct hibmc_drm_device {
>>> bool initialized;
>>> } ttm;
>>>
>>> + /* fbdev */
>>> + struct hibmc_fbdev *fbdev;
>>> bool mm_inited;
>>> };
>>>
>>> +#define to_hibmc_framebuffer(x) container_of(x, struct
>>> hibmc_framebuffer, fb)
>>> +
>>> struct hibmc_bo {
>>> struct ttm_buffer_object bo;
>>> struct ttm_placement placement;
>>> @@ -65,8 +82,15 @@ static inline struct hibmc_bo *gem_to_hibmc_bo(struct
>>> drm_gem_object *gem)
>>>
>>> #define DRM_FILE_PAGE_OFFSET (0x1ULL >> PAGE_SHIFT)
>>>
>>> +int hibmc_fbdev_init(struct hibmc_drm_device *hidev);
>>> +void hibmc_fbdev_fini(struct hibmc_drm_device *hidev);
>>> +
>>> int hibmc_gem_create(struct drm_device *dev, u32 size, bool iskernel,
>>> struct drm_gem_object **obj);
>>> +struct hibmc_framebuffer *
>>> +hibmc_framebuffer_init(struct drm_device *dev,
>>> + const struct drm_mode_fb_cmd2 *mode_cmd,
>>> + struct drm_gem_object *obj);
>>>
>>> int hibmc_mm_init(struct hibmc_drm_device *hi
[PATCH libdrm] headers: Add README file
On 10 November 2016 at 21:07, Alex Deucher wrote:
> On Thu, Nov 10, 2016 at 11:44 AM, Emil Velikov
> wrote:
>> From: Emil Velikov
>>
>> Since we're trying to standardise and make things more consistent in
>> the area, add a basic README which covers some of the more popular
>> topics.
>>
>> Cc: Dave Airlie
>> Cc: Daniel Vetter
>> Signed-off-by: Emil Velikov
>> ---
>> Dave, did I get it right on the "why only drm files should live here" ?
>>
>> Dave, Daniel, which trees/branches [in drm-misc] we can use as reference
>> point here ?
>> ---
>> include/drm/README | 72
>> ++
>> 1 file changed, 72 insertions(+)
>> create mode 100644 include/drm/README
>>
>> diff --git a/include/drm/README b/include/drm/README
>> new file mode 100644
>> index 000..2f80c15
>> --- /dev/null
>> +++ b/include/drm/README
>> @@ -0,0 +1,72 @@
>> +What are these headers ?
>> +
>> +This is the canonical source of drm headers that user space should use for
>> +communicating with the kernel DRM subsystem.
>> +
>> +They flow from the kernel, thus any changes must be merged there first.
>> +Do _not_ attempt to "fix" these by deviating from the kernel ones !
>> +
>> +
>> +Non-linux platforms - changes/patches
>> +-
>> +If your platform has local changes, please send them upstream for inclusion.
>> +Even if your patches don't get accepted in their current form, devs will
>> +give you feedback on how to address things properly.
>> +
>> +git send-email --subject-prefix="PATCH libdrm" your patches to dri-devel
>> +mailing list.
>> +
>> +Before doing so, please consider the following:
>> + - Have the [libdrm vs kernel] headers on your platform deviated ?
>> +Consider unifying them first.
>> +
>> + - Have you introduced additional ABI that's not available in Linux ?
>> +Propose it for [Linux kernel] upstream inclusion.
>> +If that doesn't work out (hopefully it never does), move it to another
>> header
>> +and/or keep the change(s) local ?
>> +
>> + - Are your changes DRI1/UMS specific ?
>> +There is virtually no interest/power in keeping those legacy interfaces.
>> They
>> +are around due to the kernel "thou shalt not break existing user space"
>> rule.
>> +
>> +Consider porting the driver to DRI2/KMS - all (almost?) sensible hardware is
>> +capable of supporting those.
>> +
>> +
>> +Which headers go where ?
>> +
>> +A snipped from the, now removed, Makefile.am used to state:
>> +
>> + XXX airlied says, nothing besides *_drm.h and drm*.h should be necessary.
>> + however, r300 and via need their reg headers installed in order to build.
>> + better solutions are welcome.
>> +
>> +Obviously the r300 and via headers are no longer around ;-)
>> +
>> +Reason behind is that the drm headers can be used as a basic communications
>> +channel with the respective kernel modules. If more advanced functionality
>> is
>> +required one can pull the specific libdrm_$driver which is free to pull
>> +additional files from the kernel.
>> +
>> +For example: nouveau has nouveau/nvif/*.h while vc4 has vc4/*.h
>> +
>> +If your driver is still in prototyping/staging state, consider moving the
>> +$driver_drm.h into $driver and _not_ installing it. An header providing
>> opaque
>> +definitions and access [via $driver_drmif.h or similar] would be better fit.
>> +
>> +
>> +When and how to update these files
>> +--
>> +Ideally on each libdrm release these will be kept in sync, with the latest
>> +released kernels. This way users won't need to provide local definitions.
>> +
>> +In order to update the files do the following:
>> + - Switch to a Linux kernel tree/branch which is not rebased.
>> +For example: airlied/drm-next, drm-misc/XXX
>
> If we just want to update it to the latest released kernel, why not
> just specify Linus' tree? There's a chance there may be flux in -next
> that you wouldn't necessarily want in libdrm.
My understanding is that things are "fully carved in stone" only as
they reach Linus. Yet things in drm-next are good enough.
> Also, I think
> generally, it would be the individual driver maintainers or people
> working on specific core features that do this. Does it really make
> sense to update these en masse regularly?
>
Ideally we'll mass import (update only) from Linus and do individuals
(from -next) as devs. deem fit. We want the former since devs can
forget about the latter.
Former is "not there yet", so I'll add a mention on the whole topic.
Speaking of which - can anyone from the team skim through amdgpu_drm.h
and radeon_drm.h update them.
Former is trivial, while the latter needs a closer look:
- missing (trailing) padding -
drm_radeon_gem_{create,{g,s}et_tiling,set_domain} others ?
- "broken" API - missing RADEON_TILING_R600_NO_SCANOUT, CIK_TILE_MODE_*
Thanks
Emil
[PATCH] drm/radeon: use list_move in radeon_vm_bo_update
Am 11.11.2016 um 13:26 schrieb Geliang Tang:
> Use list_move() instead of list_del() + list_add() to simplify the code.
>
> Signed-off-by: Geliang Tang
Reviewed-by: Christian König .
> ---
> drivers/gpu/drm/radeon/radeon_vm.c | 3 +--
> 1 file changed, 1 insertion(+), 2 deletions(-)
>
> diff --git a/drivers/gpu/drm/radeon/radeon_vm.c
> b/drivers/gpu/drm/radeon/radeon_vm.c
> index a135874..2f1e372 100644
> --- a/drivers/gpu/drm/radeon/radeon_vm.c
> +++ b/drivers/gpu/drm/radeon/radeon_vm.c
> @@ -933,8 +933,7 @@ int radeon_vm_bo_update(struct radeon_device *rdev,
> }
> list_del_init(&bo_va->vm_status);
> } else {
> - list_del(&bo_va->vm_status);
> - list_add(&bo_va->vm_status, &vm->cleared);
> + list_move(&bo_va->vm_status, &vm->cleared);
> }
> spin_unlock(&vm->status_lock);
>
[PATCH] Gpu: drm: arm: - Fix possible dereference of NULL
On 11 November 2016 at 10:56, Liviu Dudau wrote:
> Hi Shailendra,
>
> On Fri, Nov 11, 2016 at 02:16:08PM +0530, Shailendra Verma wrote:
>> From: "Shailendra Verma"
>>
>> There is possible dereference of NULL pointer if kmalloc fails.
>
> You could add: ... when the function returns. From the patch itself it is
> not clear where the problem is.
>
As the function returns we have "return &state->base;" Since base is
at offset 0 there will be no deref and the compiler will return NULL.
Not sure if that's 100% legal, though.
>> ---
>> drivers/gpu/drm/arm/malidp_planes.c |3 +++
>> 1 file changed, 3 insertions(+)
>>
>> diff --git a/drivers/gpu/drm/arm/malidp_planes.c
>> b/drivers/gpu/drm/arm/malidp_planes.c
>> index 82c193e..f769398 100644
>> --- a/drivers/gpu/drm/arm/malidp_planes.c
>> +++ b/drivers/gpu/drm/arm/malidp_planes.c
>> @@ -54,6 +54,9 @@ struct drm_plane_state
>> *malidp_duplicate_plane_state(struct drm_plane *plane)
>> return NULL;
>>
>> state = kmalloc(sizeof(*state), GFP_KERNEL);
>> + if (!state)
>> + return NULL;
>> +
>> if (state) {
Might want to drop this line - as-is things read quite weird ?
Either way, not my driver - so don't read too much into the above ;-)
Emil
[Intel-gfx] [PATCH 0/5] Handle Link Training Failure during modeset
On Thu, Nov 10, 2016 at 06:51:40PM +, Cheng, Tony wrote: > Amdgpu dal implementation will do a test link training at end of detection to > verify we can achieve the capability reported in DPCD. We then report mode > base on result of test training. > > AMD hardware (at least the generations supported by amdgpu) is able to link > train without timing being setup (DP encoder and CRTC is decoupled). Do we > have limitation from other vendors where you need timing to be there before > you can link train? I can't recall the specifics for all of our supported platforms, but at least I have the recollection that it would be the case yes. The other problem wiyh this apporach is that even if you don't need the crtc, you still need the link itself. What happens if the link is still active since userspace just didn't bother to shut it down when the cable was yanked? Can you keep the crtc going but stop it from feeding the link in a way that userspace won't be able to notice? The kms design has always been pretty much that policy is in userspace, and thus the kernel shouldn't shut down crtcs unless explicitly asked to do so. > > We can also past DP1.2 link layer compliance with this approach. > > -Original Message- > From: Deucher, Alexander > Sent: Thursday, November 10, 2016 1:43 PM > To: 'Jani Nikula' ; Manasi Navare > ; dri-devel at lists.freedesktop.org; intel-gfx > at lists.freedesktop.org; Wentland, Harry ; Cheng, > Tony > Cc: Dave Airlie ; Peres, Martin intel.com> > Subject: RE: [Intel-gfx] [PATCH 0/5] Handle Link Training Failure during > modeset > > Adding Harry and Tony from our display team to review. > > > -Original Message- > > From: Jani Nikula [mailto:jani.nikula at linux.intel.com] > > Sent: Thursday, November 10, 2016 1:20 PM > > To: Manasi Navare; dri-devel at lists.freedesktop.org; intel- > > gfx at lists.freedesktop.org > > Cc: Dave Airlie; Peres, Martin; Deucher, Alexander > > Subject: Re: [Intel-gfx] [PATCH 0/5] Handle Link Training Failure > > during modeset > > > > On Thu, 10 Nov 2016, Manasi Navare wrote: > > > Link training failure is handled by lowering the link rate first > > > until it reaches the minimum and keeping the lane count maximum and > > > then lowering the lane count until it reaches minimim. These > > > fallback values are saved and hotplug uevent is sent to the > > > userspace after setting the connector link status property to BAD. > > > Userspace should triiger another modeset on a uevent and if link > > > status property is BAD. This will retrain the link at fallback values. > > > This is repeated until the link is successfully trained. > > > > > > This has been validated to pass DP compliance. > > > > This cover letter and the commit messages do a good job of explaining > > what the patches do. However, you're lacking the crucial information > > of > > *why* we need userspace cooperation to handle link training failures > > on DP mode setting, and *why* a new connector property is a good > > solution for this. > > > > Here goes, including some alternative approaches we've considered (and > > even tried): > > > > At the time userspace does setcrtc, we've already promised the mode > > would work. The promise is based on the theoretical capabilities of > > the link, but it's possible we can't reach this in practice. The DP > > spec describes how the link should be reduced, but we can't reduce the > > link below the requirements of the mode. Black screen follows. > > > > One idea would be to have setcrtc return a failure. However, it is my > > understanding that it already should not fail as the atomic checks > > have passed [citation needed]. It would also conflict with the idea of > > making setcrtc asynchronous in the future, returning before the actual > > mode setting and link training. > > > > Another idea is to train the link "upfront" at hotplug time, before > > pruning the mode list, so that we can do the pruning based on > > practical not theoretical capabilities. However, the changes for link > > training are pretty drastic, all for the sake of error handling and DP > > compliance, when the most common happy day scenario is the current > > approach of link training at mode setting time, using the optimal > > parameters for the mode. It is also not certain all hardware could do > > this without the pipe on; not even all our hardware can do this. Some > > of this can be solved, but not trivially. > > > > Both of the above ideas also fail to address link degradation *during* > > operation. > > > > So the idea presented in these patches is to do this in a way that a) > > changes the current happy day scenario as little as possible, to avoid > > regressions, b) can be implemented the same way by all drm drivers, c) > > is still opt-in for the drivers and userspace, and opting out doesn't > > regress the user experience, d) doesn't prevent drivers from > > implementing better or alterna
[Intel-gfx] [PATCH 5/5] drm/i915: Implement Link Rate fallback on Link training failure
On Thu, Nov 10, 2016 at 09:58:31PM +0100, Daniel Vetter wrote:
> On Wed, Nov 09, 2016 at 08:42:08PM -0800, Manasi Navare wrote:
> > @@ -5692,6 +5751,39 @@ static bool intel_edp_init_connector(struct intel_dp
> > *intel_dp,
> > return false;
> > }
> >
> > +static void intel_dp_modeset_retry_work_fn(struct work_struct *work)
> > +{
> > + struct intel_connector *intel_connector;
> > + struct drm_connector *connector;
> > + struct drm_display_mode *mode;
> > + bool verbose_prune = true;
> > +
> > + intel_connector = container_of(work, typeof(*intel_connector),
> > + modeset_retry_work);
> > + connector = &intel_connector->base;
> > +
> > + /* Grab the locks before changing connector property*/
> > + mutex_lock(&connector->dev->mode_config.mutex);
> > + DRM_DEBUG_KMS("[CONNECTOR:%d:%s]\n", connector->base.id,
> > + connector->name);
> > + list_for_each_entry(mode, &connector->modes, head) {
> > + mode->status = intel_dp_mode_valid(connector,
> > + mode);
> > + }
> > + drm_mode_prune_invalid(connector->dev, &connector->modes,
> > + verbose_prune);
> > +
> > + /* Set connector link status to BAD and send a Uevent to notify
> > +* userspace to do a modeset.
> > +*/
> > + intel_dp_set_link_status_property(connector,
> > + DRM_MODE_LINK_STATUS_BAD);
> > + mutex_unlock(&connector->dev->mode_config.mutex);
> > +
> > + /* Send Hotplug uevent so userspace can reprobe */
> > + drm_kms_helper_hotplug_event(connector->dev);
>
> One downside of keeping all the signalling logic here in i915 is that we
> don't have a good spot to put the kerneldoc for this new link status
> property within drm_connector.c for others to easily spot. My suggestion
> would be to extract function with the following rough pseudo-code:
>
> drm_connector_set_link_status(connector, status)
> {
> mutex_lock(mode_config.mutex);
>
> /* what intel_dp_set_link_status_property() does */
>
> mutex_unlock(mode_config.mutex);
> drm_kms_helper_hotplug_event()
> }
>
> Within intel_dp_modeset_retry_work_fn we'd then first need to drop the
> lock, and then call this function. The lock drop&reacquire is a bit ugly,
> but:
The mode re-validation should be done in the core as well. Not sure if
we could just stuff it all into one place, and then there would be no
need for any lock dropping.
> - it doesn't matter from a performance pov, this is a slow, asynchronous
> work.
> - it doesn't matter for correctnes, the only thing we need is to drop the
> lock before calling drm_kms_helper_hotplug_event, and that we update the
> link status and the mode list before that too.
> - long term I expect that properties will get separate locks to protect
> their values, and restrict mode_config.mutex to just mode probing. Which
> means drm_connnector_set_link_status will use a different lock anyway.
> - it nicely encapsulates stuff imo.
>
> Kerneldoc for drm_connector_set_link_status should mention that this needs
> to be run from some async work item, and ofc have the full explanation
> (maybe even quote some pseudo-code, see e.g. drm_modeset_lock.c comments)
> of how this should be used.
>
> Since this is late-stage polish definitely wait for more feedback and for
> the design to fully settle first.
> -Daniel
> --
> Daniel Vetter
> Software Engineer, Intel Corporation
> http://blog.ffwll.ch
> ___
> Intel-gfx mailing list
> Intel-gfx at lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/intel-gfx
--
Ville Syrjälä
Intel OTC
[PATCH v8 0/3] drm: add explict fencing
From: Gustavo Padovan Hi, Another iteration after Brian comments. Please refer to the cover letter[1] in a previous version to check for more details. The changes since the last version can be seen in commit message on each patch. Robert Foss managed to port Android's drm_hwcomposer to the new HWC2 API and added support to fences. Current patches can be seen here: https://git.collabora.com/cgit/user/robertfoss/drm_hwcomposer.git/log/?h=hwc2_fence_v1 He ran AOSP on top of padovan/fences kernel branch with full fence support on qemu/virgl and msm db410c. That means we already have a working open source userspace using the explicit fencing implementation. Also i-g-t testing are available with all tests suggested in v7 included: https://git.collabora.com/cgit/user/padovan/intel-gpu-tools.git/log/ Please review! Gustavo [1] https://www.mail-archive.com/linux-kernel at vger.kernel.org/msg1253822.html --- Gustavo Padovan (3): drm/fence: add in-fences support drm/fence: add fence timeline to drm_crtc drm/fence: add out-fences support drivers/gpu/drm/Kconfig | 1 + drivers/gpu/drm/drm_atomic.c| 257 +--- drivers/gpu/drm/drm_atomic_helper.c | 5 + drivers/gpu/drm/drm_crtc.c | 45 +++ drivers/gpu/drm/drm_plane.c | 1 + include/drm/drm_atomic.h| 1 + include/drm/drm_crtc.h | 56 7 files changed, 321 insertions(+), 45 deletions(-) -- 2.5.5
[PATCH v8 1/3] drm/fence: add in-fences support
From: Gustavo Padovan
There is now a new property called IN_FENCE_FD attached to every plane
state that receives sync_file fds from userspace via the atomic commit
IOCTL.
The fd is then translated to a fence (that may be a fence_array
subclass or just a normal fence) and then used by DRM to fence_wait() for
all fences in the sync_file to signal. So it only commits when all
framebuffers are ready to scanout.
v2: Comments by Daniel Vetter:
- remove set state->fence = NULL in destroy phase
- accept fence -1 as valid and just return 0
- do not call fence_get() - sync_file_fences_get() already calls it
- fence_put() if state->fence is already set, in case userspace
set the property more than once.
v3: WARN_ON if fence is set but state has no FB
v4: Comment from Maarten Lankhorst
- allow set fence with no related fb
v5: rename FENCE_FD to IN_FENCE_FD
v6: Comments by Daniel Vetter:
- rename plane_state->in_fence back to "fence"
- re-introduce WARN_ON if fence set but no fb
- rebase after fence -> dma_fence rename
v7: Comments by Brian Starkey
- set state->fence to NULL when duplicating the state
- fail if IN_FENCE_FD was already set
Signed-off-by: Gustavo Padovan
Reviewed-by: Brian Starkey
---
drivers/gpu/drm/Kconfig | 1 +
drivers/gpu/drm/drm_atomic.c| 14 ++
drivers/gpu/drm/drm_atomic_helper.c | 5 +
drivers/gpu/drm/drm_crtc.c | 6 ++
drivers/gpu/drm/drm_plane.c | 1 +
include/drm/drm_crtc.h | 5 +
6 files changed, 32 insertions(+)
diff --git a/drivers/gpu/drm/Kconfig b/drivers/gpu/drm/Kconfig
index 25e8e37..360cb92 100644
--- a/drivers/gpu/drm/Kconfig
+++ b/drivers/gpu/drm/Kconfig
@@ -12,6 +12,7 @@ menuconfig DRM
select I2C
select I2C_ALGOBIT
select DMA_SHARED_BUFFER
+ select SYNC_FILE
help
Kernel-level support for the Direct Rendering Infrastructure (DRI)
introduced in XFree86 4.0. If you say Y here, you need to select
diff --git a/drivers/gpu/drm/drm_atomic.c b/drivers/gpu/drm/drm_atomic.c
index b096c16..8e26ad1 100644
--- a/drivers/gpu/drm/drm_atomic.c
+++ b/drivers/gpu/drm/drm_atomic.c
@@ -31,6 +31,7 @@
#include
#include
#include
+#include
#include "drm_crtc_internal.h"
@@ -709,6 +710,17 @@ int drm_atomic_plane_set_property(struct drm_plane *plane,
drm_atomic_set_fb_for_plane(state, fb);
if (fb)
drm_framebuffer_unreference(fb);
+ } else if (property == config->prop_in_fence_fd) {
+ if (state->fence)
+ return -EINVAL;
+
+ if (U642I64(val) == -1)
+ return 0;
+
+ state->fence = sync_file_get_fence(val);
+ if (!state->fence)
+ return -EINVAL;
+
} else if (property == config->prop_crtc_id) {
struct drm_crtc *crtc = drm_crtc_find(dev, val);
return drm_atomic_set_crtc_for_plane(state, crtc);
@@ -770,6 +782,8 @@ drm_atomic_plane_get_property(struct drm_plane *plane,
if (property == config->prop_fb_id) {
*val = (state->fb) ? state->fb->base.id : 0;
+ } else if (property == config->prop_in_fence_fd) {
+ *val = -1;
} else if (property == config->prop_crtc_id) {
*val = (state->crtc) ? state->crtc->base.id : 0;
} else if (property == config->prop_crtc_x) {
diff --git a/drivers/gpu/drm/drm_atomic_helper.c
b/drivers/gpu/drm/drm_atomic_helper.c
index 75ad01d..caed870 100644
--- a/drivers/gpu/drm/drm_atomic_helper.c
+++ b/drivers/gpu/drm/drm_atomic_helper.c
@@ -3076,6 +3076,8 @@ void __drm_atomic_helper_plane_duplicate_state(struct
drm_plane *plane,
if (state->fb)
drm_framebuffer_reference(state->fb);
+
+ state->fence = NULL;
}
EXPORT_SYMBOL(__drm_atomic_helper_plane_duplicate_state);
@@ -3114,6 +3116,9 @@ void __drm_atomic_helper_plane_destroy_state(struct
drm_plane_state *state)
{
if (state->fb)
drm_framebuffer_unreference(state->fb);
+
+ if (state->fence)
+ dma_fence_put(state->fence);
}
EXPORT_SYMBOL(__drm_atomic_helper_plane_destroy_state);
diff --git a/drivers/gpu/drm/drm_crtc.c b/drivers/gpu/drm/drm_crtc.c
index ce274ed..154e040 100644
--- a/drivers/gpu/drm/drm_crtc.c
+++ b/drivers/gpu/drm/drm_crtc.c
@@ -397,6 +397,12 @@ static int drm_mode_create_standard_properties(struct
drm_device *dev)
return -ENOMEM;
dev->mode_config.prop_fb_id = prop;
+ prop = drm_property_create_signed_range(dev, DRM_MODE_PROP_ATOMIC,
+ "IN_FENCE_FD", -1, INT_MAX);
+ if (!prop)
+ return -ENOMEM;
+ dev->mode_config.prop_in_fence_fd = prop;
+
prop = drm_property_create_object(dev, DRM_MODE_PROP_ATOMIC,
"CRTC_ID",
[PATCH v8 2/3] drm/fence: add fence timeline to drm_crtc
From: Gustavo Padovan
Create one timeline context for each CRTC to be able to handle out-fences
and signal them. It adds a few members to struct drm_crtc: fence_context,
where we store the context we get from fence_context_alloc(), the
fence seqno and the fence lock, that we pass in fence_init() to be
used by the fence.
v2: Comment by Daniel Stone:
- add BUG_ON() to fence_to_crtc() macro
v3: Comment by Ville Syrjälä
- Use more meaningful name as crtc timeline name
v4: Comments by Brian Starkey
- Use even more meaninful name for the crtc timeline
- add doc for timeline_name
Comment by Daniel Vetter
- use in-line style for comments
- rebase after fence -> dma_fence rename
v5: Comment by Daniel Vetter
- Add doc for drm_crtc_fence_ops
Signed-off-by: Gustavo Padovan
Reviewed-by: Daniel Vetter
---
drivers/gpu/drm/drm_crtc.c | 31 +++
include/drm/drm_crtc.h | 45 +
2 files changed, 76 insertions(+)
diff --git a/drivers/gpu/drm/drm_crtc.c b/drivers/gpu/drm/drm_crtc.c
index 154e040..9b9881b 100644
--- a/drivers/gpu/drm/drm_crtc.c
+++ b/drivers/gpu/drm/drm_crtc.c
@@ -165,6 +165,32 @@ static void drm_crtc_crc_fini(struct drm_crtc *crtc)
#endif
}
+static const char *drm_crtc_fence_get_driver_name(struct dma_fence *fence)
+{
+ struct drm_crtc *crtc = fence_to_crtc(fence);
+
+ return crtc->dev->driver->name;
+}
+
+static const char *drm_crtc_fence_get_timeline_name(struct dma_fence *fence)
+{
+ struct drm_crtc *crtc = fence_to_crtc(fence);
+
+ return crtc->timeline_name;
+}
+
+static bool drm_crtc_fence_enable_signaling(struct dma_fence *fence)
+{
+ return true;
+}
+
+const struct dma_fence_ops drm_crtc_fence_ops = {
+ .get_driver_name = drm_crtc_fence_get_driver_name,
+ .get_timeline_name = drm_crtc_fence_get_timeline_name,
+ .enable_signaling = drm_crtc_fence_enable_signaling,
+ .wait = dma_fence_default_wait,
+};
+
/**
* drm_crtc_init_with_planes - Initialise a new CRTC object with
*specified primary and cursor planes.
@@ -222,6 +248,11 @@ int drm_crtc_init_with_planes(struct drm_device *dev,
struct drm_crtc *crtc,
return -ENOMEM;
}
+ crtc->fence_context = dma_fence_context_alloc(1);
+ spin_lock_init(&crtc->fence_lock);
+ snprintf(crtc->timeline_name, sizeof(crtc->timeline_name),
+"CRTC:%d-%s", crtc->base.id, crtc->name);
+
crtc->base.properties = &crtc->properties;
list_add_tail(&crtc->head, &config->crtc_list);
diff --git a/include/drm/drm_crtc.h b/include/drm/drm_crtc.h
index 11780a9..0870de1 100644
--- a/include/drm/drm_crtc.h
+++ b/include/drm/drm_crtc.h
@@ -32,6 +32,8 @@
#include
#include
#include
+#include
+#include
#include
#include
#include
@@ -739,9 +741,52 @@ struct drm_crtc {
*/
struct drm_crtc_crc crc;
#endif
+
+ /**
+* @fence_context:
+*
+* timeline context used for fence operations.
+*/
+ unsigned int fence_context;
+
+ /**
+* @fence_lock:
+*
+* spinlock to protect the fences in the fence_context.
+*/
+
+ spinlock_t fence_lock;
+ /**
+* @fence_seqno:
+*
+* Seqno variable used as monotonic counter for the fences
+* created on the CRTC's timeline.
+*/
+ unsigned long fence_seqno;
+
+ /**
+* @timeline_name:
+*
+* The name of the CRTC's fence timeline.
+*/
+ char timeline_name[32];
};
/**
+ * dma_crtc_fence_ops - fence ops for the drm_crtc timeline
+ *
+ * It contains the dma_fence_ops that should be called by the dma_fence
+ * code. CRTC core should use this ops when initializing fences.
+ */
+extern const struct dma_fence_ops drm_crtc_fence_ops;
+
+static inline struct drm_crtc *fence_to_crtc(struct dma_fence *fence)
+{
+ BUG_ON(fence->ops != &drm_crtc_fence_ops);
+ return container_of(fence->lock, struct drm_crtc, fence_lock);
+}
+
+/**
* struct drm_mode_set - new values for a CRTC config change
* @fb: framebuffer to use for new config
* @crtc: CRTC whose configuration we're about to change
--
2.5.5
[PATCH v8 3/3] drm/fence: add out-fences support
From: Gustavo Padovan
Support DRM out-fences by creating a sync_file with a fence for each CRTC
that sets the OUT_FENCE_PTR property.
We use the out_fence pointer received in the OUT_FENCE_PTR prop to send
the sync_file fd back to userspace.
The sync_file and fd are allocated/created before commit, but the
fd_install operation only happens after we know that commit succeed.
v2: Comment by Rob Clark:
- Squash commit that adds DRM_MODE_ATOMIC_OUT_FENCE flag here.
Comment by Daniel Vetter:
- Add clean up code for out_fences
v3: Comments by Daniel Vetter:
- create DRM_MODE_ATOMIC_EVENT_MASK
- userspace should fill out_fences_ptr with the crtc_ids for which
it wants fences back.
v4: Create OUT_FENCE_PTR properties and remove old approach.
v5: Comments by Brian Starkey:
- Remove extra fence_get() in atomic_ioctl()
- Check ret before iterating on the crtc_state
- check ret before fd_install
- set fence_state to NULL at the beginning
- check fence_state->out_fence_ptr before put_user()
- change order of fput() and put_unused_fd() on failure
- Add access_ok() check to the out_fence_ptr received
- Rebase after fence -> dma_fence rename
- Store out_fence_ptr in the drm_atomic_state
- Split crtc_setup_out_fence()
- return -1 as out_fence with TEST_ONLY flag
v6: Comments by Daniel Vetter
- Add prepare/unprepare_crtc_signaling()
- move struct drm_out_fence_state to drm_atomic.c
- mark get_crtc_fence() as static
Comments by Brian Starkey
- proper set fence_ptr fence_state array
- isolate fence_idx increment
- improve error handling
v7: Comments by Daniel Vetter
- remove prefix from internal functions
- make out_fence_ptr an s64 pointer
- degrade DRM_INFO to DRM_DEBUG_ATOMIC when put_user fail
- fix doc issues
- filter out OUT_FENCE_PTR == NULL and do not fail in this case
- add complete_crtc_signalling()
- krealloc fence_state on demand
Comment by Brian Starkey
- remove unused crtc_state arg from get_out_fence()
v8: Comment by Brian Starkey
- cancel events before check for !fence_state
- convert a few lefovers u64 types for out_fence_ptr
- fix memleak by assign fence_state earlier after realloc
- proper accout num_fences in case of error
Signed-off-by: Gustavo Padovan
---
drivers/gpu/drm/drm_atomic.c | 243 +++
drivers/gpu/drm/drm_crtc.c | 8 ++
include/drm/drm_atomic.h | 1 +
include/drm/drm_crtc.h | 6 ++
4 files changed, 213 insertions(+), 45 deletions(-)
diff --git a/drivers/gpu/drm/drm_atomic.c b/drivers/gpu/drm/drm_atomic.c
index 8e26ad1..34cdc6e 100644
--- a/drivers/gpu/drm/drm_atomic.c
+++ b/drivers/gpu/drm/drm_atomic.c
@@ -290,6 +290,23 @@ drm_atomic_get_crtc_state(struct drm_atomic_state *state,
}
EXPORT_SYMBOL(drm_atomic_get_crtc_state);
+static void set_out_fence_for_crtc(struct drm_atomic_state *state,
+ struct drm_crtc *crtc, s64 __user *fence_ptr)
+{
+ state->crtcs[drm_crtc_index(crtc)].out_fence_ptr = fence_ptr;
+}
+
+static s64 __user * get_out_fence_for_crtc(struct drm_atomic_state *state,
+ struct drm_crtc *crtc)
+{
+ s64 __user *fence_ptr;
+
+ fence_ptr = state->crtcs[drm_crtc_index(crtc)].out_fence_ptr;
+ state->crtcs[drm_crtc_index(crtc)].out_fence_ptr = NULL;
+
+ return fence_ptr;
+}
+
/**
* drm_atomic_set_mode_for_crtc - set mode for CRTC
* @state: the CRTC whose incoming state to update
@@ -491,6 +508,16 @@ int drm_atomic_crtc_set_property(struct drm_crtc *crtc,
&replaced);
state->color_mgmt_changed |= replaced;
return ret;
+ } else if (property == config->prop_out_fence_ptr) {
+ s64 __user *fence_ptr = u64_to_user_ptr(val);
+
+ if (!fence_ptr)
+ return 0;
+
+ if (!access_ok(VERIFY_WRITE, fence_ptr, sizeof(*fence_ptr)))
+ return -EFAULT;
+
+ set_out_fence_for_crtc(state->state, crtc, fence_ptr);
} else if (crtc->funcs->atomic_set_property)
return crtc->funcs->atomic_set_property(crtc, state, property,
val);
else
@@ -533,6 +560,8 @@ drm_atomic_crtc_get_property(struct drm_crtc *crtc,
*val = (state->ctm) ? state->ctm->base.id : 0;
else if (property == config->gamma_lut_property)
*val = (state->gamma_lut) ? state->gamma_lut->base.id : 0;
+ else if (property == config->prop_out_fence_ptr)
+ *val = 0;
else if (crtc->funcs->atomic_get_property)
return crtc->funcs->atomic_get_property(crtc, state, property,
val);
else
@@ -1659,11 +1688,9 @@ int drm_atomic_deb
[PATCH] Gpu: drm: arm: - Fix possible dereference of NULL
On Fri, Nov 11, 2016 at 01:58:46PM +, Emil Velikov wrote:
> On 11 November 2016 at 10:56, Liviu Dudau wrote:
> > Hi Shailendra,
> >
> > On Fri, Nov 11, 2016 at 02:16:08PM +0530, Shailendra Verma wrote:
> >> From: "Shailendra Verma"
> >>
> >> There is possible dereference of NULL pointer if kmalloc fails.
> >
> > You could add: ... when the function returns. From the patch itself it is
> > not clear where the problem is.
> >
> As the function returns we have "return &state->base;" Since base is
> at offset 0 there will be no deref and the compiler will return NULL.
> Not sure if that's 100% legal, though.
>
> >> ---
> >> drivers/gpu/drm/arm/malidp_planes.c |3 +++
> >> 1 file changed, 3 insertions(+)
> >>
> >> diff --git a/drivers/gpu/drm/arm/malidp_planes.c
> >> b/drivers/gpu/drm/arm/malidp_planes.c
> >> index 82c193e..f769398 100644
> >> --- a/drivers/gpu/drm/arm/malidp_planes.c
> >> +++ b/drivers/gpu/drm/arm/malidp_planes.c
> >> @@ -54,6 +54,9 @@ struct drm_plane_state
> >> *malidp_duplicate_plane_state(struct drm_plane *plane)
> >> return NULL;
> >>
> >> state = kmalloc(sizeof(*state), GFP_KERNEL);
> >> + if (!state)
> >> + return NULL;
> >> +
> >> if (state) {
> Might want to drop this line - as-is things read quite weird ?
I've already done that in the patched that I've queued in my tree, I just need
to push
it to the public tree.
... now if that server would be online when I need it :(
Best regards,
Liviu
>
> Either way, not my driver - so don't read too much into the above ;-)
> Emil
--
| I would like to |
| fix the world, |
| but they're not |
| giving me the |
\ source code! /
---
¯\_(ã)_/¯
[PATCH 1/4] gpu: host1x: Store device address to all bufs
On Tue, Nov 08, 2016 at 07:51:32PM +0200, Mikko Perttunen wrote: > From: Arto Merilainen > > Currently job pinning is optimized to handle only the first buffer > using a certain host1x_bo object and all subsequent buffers using > the same host1x_bo are considered done. > > In most cases this is correct, however, in case the same host1x_bo > is used in multiple gathers inside the same job, we skip also > storing the device address (physical or iova) to this buffer. > > This patch reworks the host1x_job_pin() to store the device address > to all gathers. > > Signed-off-by: Andrew Chew > Signed-off-by: Arto Merilainen > Signed-off-by: Mikko Perttunen > --- > drivers/gpu/host1x/job.c | 9 ++--- > 1 file changed, 6 insertions(+), 3 deletions(-) Applied, thanks. Thierry -- next part -- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 801 bytes Desc: not available URL: <https://lists.freedesktop.org/archives/dri-devel/attachments/2016/3cb81144/attachment.sig>
[PATCH 2/4] gpu: host1x: Add locking to syncpt
On Tue, Nov 08, 2016 at 07:51:33PM +0200, Mikko Perttunen wrote: [...] > @@ -86,7 +88,17 @@ static struct host1x_syncpt *host1x_syncpt_alloc(struct > host1x *host, > else > sp->client_managed = false; > > + mutex_unlock(&host->syncpt_mutex); > return sp; > + > +err_alloc_name: It's better to use labels that describe what they do, rather than when they get called. > + host1x_syncpt_base_free(sp->base); > + sp->base = NULL; > +err_alloc_base: > + sp = NULL; This is useless because the variable is no longer used after this and goes out of scope. I fixed up these two issues and applied. Thanks, Thierry -- next part -- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 801 bytes Desc: not available URL: <https://lists.freedesktop.org/archives/dri-devel/attachments/2016/9ae53c10/attachment.sig>
BUG: 'list_empty(&vgdev->free_vbufs)' is true!
On 11/08/2016, 09:37 PM, Michael S. Tsirkin wrote:
> On Mon, Nov 07, 2016 at 09:43:24AM +0100, Jiri Slaby wrote:
> The following might be helpful for debugging - if kernel still will
> not stop panicing, we are looking at some kind
> of memory corruption.
>
>
> diff --git a/drivers/gpu/drm/virtio/virtgpu_vq.c
> b/drivers/gpu/drm/virtio/virtgpu_vq.c
> index 5a0f8a7..d5e1e72 100644
> --- a/drivers/gpu/drm/virtio/virtgpu_vq.c
> +++ b/drivers/gpu/drm/virtio/virtgpu_vq.c
> @@ -127,7 +127,11 @@ virtio_gpu_get_vbuf(struct virtio_gpu_device *vgdev,
> struct virtio_gpu_vbuffer *vbuf;
>
> spin_lock(&vgdev->free_vbufs_lock);
> - BUG_ON(list_empty(&vgdev->free_vbufs));
> + WARN_ON(list_empty(&vgdev->free_vbufs));
> + if (list_empty(&vgdev->free_vbufs)) {
> + spin_unlock(&vgdev->free_vbufs_lock);
> + return ERR_PTR(-EINVAL);
> + }
Yeah, I already tried that, but it dies immediately after that:
WARNING: '1' is true!
[ cut here ]
WARNING: CPU: 2 PID: 5019 at
/home/latest/linux/drivers/gpu/drm/virtio/virtgpu_vq.c:130
virtio_gpu_get_vbuf+0x415/0x6a0
Modules linked in:
CPU: 2 PID: 5019 Comm: kworker/2:3 Not tainted 4.9.0-rc2-next-20161028+ #33
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS
rel-1.9.3-0-ge2fc41e-prebuilt.qemu-project.org 04/01/2014
Workqueue: events drm_fb_helper_dirty_work
Call Trace:
dump_stack+0xcd/0x134
? _atomic_dec_and_lock+0xcc/0xcc
? vprintk_default+0x1f/0x30
? printk+0x99/0xb5
__warn+0x19e/0x1d0
warn_slowpath_null+0x1d/0x20
virtio_gpu_get_vbuf+0x415/0x6a0
? lock_pin_lock+0x4a0/0x4a0
? virtio_gpu_cmd_capset_cb+0x460/0x460
? debug_check_no_locks_freed+0x350/0x350
virtio_gpu_cmd_resource_flush+0x8d/0x2d0
? virtio_gpu_cmd_set_scanout+0x310/0x310
virtio_gpu_surface_dirty+0x364/0x930
? mark_held_locks+0xff/0x290
? virtio_gpufb_create+0xab0/0xab0
? _raw_spin_unlock_irqrestore+0x53/0x70
? trace_hardirqs_on_caller+0x46c/0x6b0
virtio_gpu_framebuffer_surface_dirty+0x14/0x20
drm_fb_helper_dirty_work+0x27a/0x400
? drm_fb_helper_is_bound+0x300/0x300
process_one_work+0x834/0x1c90
? process_one_work+0x7a5/0x1c90
? pwq_dec_nr_in_flight+0x3a0/0x3a0
? worker_thread+0x1b2/0x1540
worker_thread+0x650/0x1540
? process_one_work+0x1c90/0x1c90
? process_one_work+0x1c90/0x1c90
kthread+0x206/0x310
? kthread_create_on_node+0xa0/0xa0
? trace_hardirqs_on+0xd/0x10
? kthread_create_on_node+0xa0/0xa0
? kthread_create_on_node+0xa0/0xa0
ret_from_fork+0x2a/0x40
---[ end trace c723c98d382423f4 ]---
BUG: unable to handle kernel paging request at fc00
IP: check_memory_region+0x7f/0x1a0
PGD 0
Oops: [#1] PREEMPT SMP KASAN
Modules linked in:
CPU: 2 PID: 5019 Comm: kworker/2:3 Tainted: GW
4.9.0-rc2-next-20161028+ #33
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS
rel-1.9.3-0-ge2fc41e-prebuilt.qemu-project.org 04/01/2014
Workqueue: events drm_fb_helper_dirty_work
task: 8800455f4980 task.stack: 88001fd78000
RIP: 0010:check_memory_region+0x7f/0x1a0
RSP: 0018:88001fd7f938 EFLAGS: 00010282
RAX: fc00 RBX: dc01 RCX: 8260afb3
RDX: 0001 RSI: 0030 RDI: fff4
RBP: 88001fd7f948 R08: fc01 R09: dc04
R10: 0023 R11: dc05 R12: 0030
R13: R14: 0050 R15: 0001
FS: () GS:88007dd0() knlGS:
CS: 0010 DS: ES: CR0: 80050033
CR2: fc00 CR3: 773a CR4: 06e0
Call Trace:
Code: 83 fb 10 7f 3f 4d 85 db 74 34 48 bb 01 00 00 00 00 fc ff df 49 01
c3 49 01 d8 80 38 00 75 13 4d 39 c3 4c 89 c0 74 17 49 83 c0 01 <41> 80
78 ff 00 74 ed 49 89 c0 4d 85 c0 0f 85 8f 00 00 00 5b 41
RIP: check_memory_region+0x7f/0x1a0 RSP: 88001fd7f938
CR2: fc00
thanks,
--
js
suse labs
[PATCH 3/4] drm/tegra: Support kernel mappings with IOMMU
On Tue, Nov 08, 2016 at 07:51:34PM +0200, Mikko Perttunen wrote: > From: Arto Merilainen > > Host1x command buffer patching requires that the buffer object can be > mapped into kernel address space, however, the recent addition of > IOMMU did not account to this requirement. Therefore Host1x engines > cannot be used if IOMMU is enabled. > > This patch implements kmap, kunmap, mmap and munmap functions to > host1x bo objects. > > Signed-off-by: Arto Merilainen > Signed-off-by: Mikko Perttunen > --- > drivers/gpu/drm/tegra/gem.c | 34 +++--- > 1 file changed, 31 insertions(+), 3 deletions(-) Applied with a tiny fixup of the commit message, thanks. Thierry -- next part -- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 801 bytes Desc: not available URL: <https://lists.freedesktop.org/archives/dri-devel/attachments/2016/4c924bf6/attachment.sig>
[PATCH v3] PCI: create revision file in sysfs
From: Emil Velikov
Currently the revision isn't available via sysfs/libudev thus if one
wants to know the value they need to read through the config file.
This in itself wakes/powers up the device, causing unwanted delay
since it can be quite costly.
There are at least two userspace components which could make use the new
file libpciaccess and libdrm. The former [used in various places] wakes
up _every_ PCI device, which can be observed via glxinfo [when using
Mesa 10.0+ drivers]. While the latter [in association with Mesa 13.0]
can lead to 2-3 second delays while starting firefox, thunderbird or
chromium.
Expose the revision as a separate file, just like we do for the device,
vendor, their subsystem version and class.
Cc: Bjorn Helgaas
Cc: linux-pci at vger.kernel.org
Cc: Greg KH
Link: https://bugs.freedesktop.org/show_bug.cgi?id=98502
Tested-by: Mauro Santos
Reviewed-by: Alex Deucher
Signed-off-by: Emil Velikov
---
v2: Add r-b/t-b tags, slim down CC list, add note about userspace.
v3: Add Documentation/ bits (Greg KH)
Gents, please keep me in the CC list.
Thanks
Emil
---
Documentation/ABI/testing/sysfs-bus-pci | 7 +++
Documentation/filesystems/sysfs-pci.txt | 2 ++
drivers/pci/pci-sysfs.c | 2 ++
3 files changed, 11 insertions(+)
diff --git a/Documentation/ABI/testing/sysfs-bus-pci
b/Documentation/ABI/testing/sysfs-bus-pci
index b3bc50f..5a1732b 100644
--- a/Documentation/ABI/testing/sysfs-bus-pci
+++ b/Documentation/ABI/testing/sysfs-bus-pci
@@ -294,3 +294,10 @@ Description:
a firmware bug to the system vendor. Writing to this file
taints the kernel with TAINT_FIRMWARE_WORKAROUND, which
reduces the supportability of your system.
+
+What: /sys/bus/pci/devices/.../revision
+Date: November 2016
+Contact: Emil Velikov
+Description:
+ This file contains the revision field of the the PCI device.
+ The value comes from device config space. The file is read only.
diff --git a/Documentation/filesystems/sysfs-pci.txt
b/Documentation/filesystems/sysfs-pci.txt
index 74eaac2..6ea1ced 100644
--- a/Documentation/filesystems/sysfs-pci.txt
+++ b/Documentation/filesystems/sysfs-pci.txt
@@ -17,6 +17,7 @@ that support it. For example, a given bus might look like
this:
| |-- resource0
| |-- resource1
| |-- resource2
+ | |-- revision
| |-- rom
| |-- subsystem_device
| |-- subsystem_vendor
@@ -41,6 +42,7 @@ files, each with their own function.
resource PCI resource host addresses (ascii, ro)
resource0..N PCI resource N, if present (binary, mmap, rw[1])
resource0_wc..N_wc PCI WC map resource N, if prefetchable (binary,
mmap)
+ revision PCI revision (ascii, ro)
romPCI ROM resource, if present (binary, ro)
subsystem_device PCI subsystem device (ascii, ro)
subsystem_vendor PCI subsystem vendor (ascii, ro)
diff --git a/drivers/pci/pci-sysfs.c b/drivers/pci/pci-sysfs.c
index bcd10c7..0666287 100644
--- a/drivers/pci/pci-sysfs.c
+++ b/drivers/pci/pci-sysfs.c
@@ -50,6 +50,7 @@ pci_config_attr(vendor, "0x%04x\n");
pci_config_attr(device, "0x%04x\n");
pci_config_attr(subsystem_vendor, "0x%04x\n");
pci_config_attr(subsystem_device, "0x%04x\n");
+pci_config_attr(revision, "0x%02x\n");
pci_config_attr(class, "0x%06x\n");
pci_config_attr(irq, "%u\n");
@@ -568,6 +569,7 @@ static struct attribute *pci_dev_attrs[] = {
&dev_attr_device.attr,
&dev_attr_subsystem_vendor.attr,
&dev_attr_subsystem_device.attr,
+ &dev_attr_revision.attr,
&dev_attr_class.attr,
&dev_attr_irq.attr,
&dev_attr_local_cpus.attr,
--
2.9.3
[PATCH 4/4] drm/tegra: Set sgt pointer in BO pin
On Tue, Nov 08, 2016 at 07:51:35PM +0200, Mikko Perttunen wrote: > Fix tegra_bo_pin to set the parameter sgt pointer. > Host1x job pinning requires the sgt to determine > physical memory addresses of gathers. > > Signed-off-by: Mikko Perttunen > --- > drivers/gpu/drm/tegra/gem.c | 2 ++ > 1 file changed, 2 insertions(+) Applied with a slightly reformatted commit message. Please use all of the 72 columns to avoid "squeezed" commit messages. Thanks, Thierry -- next part -- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 801 bytes Desc: not available URL: <https://lists.freedesktop.org/archives/dri-devel/attachments/2016/af8eadee/attachment.sig>
[PATCH v8 0/3] drm: add explict fencing
I tested this series on the db410c platform and I've seen no regressions from previous versions of this series. Tested-by: Robert Foss
[PATCH RFC 00/12] tda998x updates
On 11/08/16 14:24, Russell King - ARM Linux wrote: > As no one responded to the previous round, I'm not spending soo much > time writing up a description of these changes again. It's also been > quite a long time, so I've forgotten all the details of the changes, > so I'll do my best. > > Changes from the previous series include: > - reorder the initial three patches > - change the (now third patch)... I think to increase the size of the > locked region. > - fix edid parsing for infoframe generation - as was pointed out for > dw-hdmi, parsing the EDID in get_modes() is incorrect, as that method > will not be called when an override-edid is in effect. We need to > parse the override-edid. Moreover, infoframe generation should not > be keyed to whether the monitor is HDMI or not, CEA-861B allows non- > HDMI to send infoframes. > - only send audio if audio and infoframes are supported. > > Otherwise, these are very much like the previous posting of the series, > except rebased upon the mali/hdlcd/tda998x change to remove the > drm_connector_register() call. > > https://www.spinics.net/lists/dri-devel/msg121495.html > > It'd be nice to have other tda998x users ack and test these patches, > I've tried to test on Juno, but the Juno situation seems to be a huge > fail. (HBI0282B completely fails with latest firmware - (a) FPGA image > incompatibilities io_b118 causes all FPGA AMBA devices to vanish, (b) > seems no way to get SCPI support on it - adding the BL0 executable > start address in the SCC registers seems to be incompatible with the > devchip, causing the PLLs to fail. In discussion with Sudeep over > these issues, but no idea where things are with it at the moment, other > than Sudeep needs to investigate. All Linaro firmware releases are > broken on HBI0282B.) > > drivers/gpu/drm/i2c/tda998x_drv.c | 826 > -- > 1 file changed, 429 insertions(+), 397 deletions(-) > Reviewed-by: Jyri Sarha For the whole series. I am also happy to test these patches if I can fetch them from some git repo. Best regards, Jyri
[Intel-gfx] [PATCH 5/5] drm/i915: Implement Link Rate fallback on Link training failure
On Fri, Nov 11, 2016 at 04:08:26PM +0200, Ville Syrjälä wrote:
> On Thu, Nov 10, 2016 at 09:58:31PM +0100, Daniel Vetter wrote:
> > On Wed, Nov 09, 2016 at 08:42:08PM -0800, Manasi Navare wrote:
> > > @@ -5692,6 +5751,39 @@ static bool intel_edp_init_connector(struct
> > > intel_dp *intel_dp,
> > > return false;
> > > }
> > >
> > > +static void intel_dp_modeset_retry_work_fn(struct work_struct *work)
> > > +{
> > > + struct intel_connector *intel_connector;
> > > + struct drm_connector *connector;
> > > + struct drm_display_mode *mode;
> > > + bool verbose_prune = true;
> > > +
> > > + intel_connector = container_of(work, typeof(*intel_connector),
> > > +modeset_retry_work);
> > > + connector = &intel_connector->base;
> > > +
> > > + /* Grab the locks before changing connector property*/
> > > + mutex_lock(&connector->dev->mode_config.mutex);
> > > + DRM_DEBUG_KMS("[CONNECTOR:%d:%s]\n", connector->base.id,
> > > + connector->name);
> > > + list_for_each_entry(mode, &connector->modes, head) {
> > > + mode->status = intel_dp_mode_valid(connector,
> > > +mode);
> > > + }
> > > + drm_mode_prune_invalid(connector->dev, &connector->modes,
> > > +verbose_prune);
> > > +
> > > + /* Set connector link status to BAD and send a Uevent to notify
> > > + * userspace to do a modeset.
> > > + */
> > > + intel_dp_set_link_status_property(connector,
> > > + DRM_MODE_LINK_STATUS_BAD);
> > > + mutex_unlock(&connector->dev->mode_config.mutex);
> > > +
> > > + /* Send Hotplug uevent so userspace can reprobe */
> > > + drm_kms_helper_hotplug_event(connector->dev);
> >
> > One downside of keeping all the signalling logic here in i915 is that we
> > don't have a good spot to put the kerneldoc for this new link status
> > property within drm_connector.c for others to easily spot. My suggestion
> > would be to extract function with the following rough pseudo-code:
> >
> > drm_connector_set_link_status(connector, status)
> > {
> > mutex_lock(mode_config.mutex);
> >
> > /* what intel_dp_set_link_status_property() does */
> >
> > mutex_unlock(mode_config.mutex);
> > drm_kms_helper_hotplug_event()
> > }
> >
> > Within intel_dp_modeset_retry_work_fn we'd then first need to drop the
> > lock, and then call this function. The lock drop&reacquire is a bit ugly,
> > but:
>
> The mode re-validation should be done in the core as well. Not sure if
> we could just stuff it all into one place, and then there would be no
> need for any lock dropping.
>
I can move the moderevalidation to the core as well, but then the function name
has to be something else than just drm_set_link_status_property(),cant think
of a name that combines mode revalidation and setting link sttaus property,
any suggestions?
Manasi
> > - it doesn't matter from a performance pov, this is a slow, asynchronous
> > work.
> > - it doesn't matter for correctnes, the only thing we need is to drop the
> > lock before calling drm_kms_helper_hotplug_event, and that we update the
> > link status and the mode list before that too.
> > - long term I expect that properties will get separate locks to protect
> > their values, and restrict mode_config.mutex to just mode probing. Which
> > means drm_connnector_set_link_status will use a different lock anyway.
> > - it nicely encapsulates stuff imo.
> >
> > Kerneldoc for drm_connector_set_link_status should mention that this needs
> > to be run from some async work item, and ofc have the full explanation
> > (maybe even quote some pseudo-code, see e.g. drm_modeset_lock.c comments)
> > of how this should be used.
> >
> > Since this is late-stage polish definitely wait for more feedback and for
> > the design to fully settle first.
> > -Daniel
> > --
> > Daniel Vetter
> > Software Engineer, Intel Corporation
> > http://blog.ffwll.ch
> > ___
> > Intel-gfx mailing list
> > Intel-gfx at lists.freedesktop.org
> > https://lists.freedesktop.org/mailman/listinfo/intel-gfx
>
> --
> Ville Syrjälä
> Intel OTC
[PATCH v8 2/3] drm/fence: add fence timeline to drm_crtc
On Fri, Nov 11, 2016 at 12:16 AM, Gustavo Padovan
wrote:
> From: Gustavo Padovan
>
> Create one timeline context for each CRTC to be able to handle out-fences
> and signal them. It adds a few members to struct drm_crtc: fence_context,
> where we store the context we get from fence_context_alloc(), the
> fence seqno and the fence lock, that we pass in fence_init() to be
> used by the fence.
>
> v2: Comment by Daniel Stone:
> - add BUG_ON() to fence_to_crtc() macro
>
> v3: Comment by Ville Syrjälä
> - Use more meaningful name as crtc timeline name
>
> v4: Comments by Brian Starkey
> - Use even more meaninful name for the crtc timeline
> - add doc for timeline_name
> Comment by Daniel Vetter
> - use in-line style for comments
>
> - rebase after fence -> dma_fence rename
>
> v5: Comment by Daniel Vetter
> - Add doc for drm_crtc_fence_ops
>
> Signed-off-by: Gustavo Padovan
> Reviewed-by: Daniel Vetter
Reviewed-by: Sean Paul
> ---
> drivers/gpu/drm/drm_crtc.c | 31 +++
> include/drm/drm_crtc.h | 45 +
> 2 files changed, 76 insertions(+)
>
> diff --git a/drivers/gpu/drm/drm_crtc.c b/drivers/gpu/drm/drm_crtc.c
> index 154e040..9b9881b 100644
> --- a/drivers/gpu/drm/drm_crtc.c
> +++ b/drivers/gpu/drm/drm_crtc.c
> @@ -165,6 +165,32 @@ static void drm_crtc_crc_fini(struct drm_crtc *crtc)
> #endif
> }
>
> +static const char *drm_crtc_fence_get_driver_name(struct dma_fence *fence)
> +{
> + struct drm_crtc *crtc = fence_to_crtc(fence);
> +
> + return crtc->dev->driver->name;
> +}
> +
> +static const char *drm_crtc_fence_get_timeline_name(struct dma_fence *fence)
> +{
> + struct drm_crtc *crtc = fence_to_crtc(fence);
> +
> + return crtc->timeline_name;
> +}
> +
> +static bool drm_crtc_fence_enable_signaling(struct dma_fence *fence)
> +{
> + return true;
> +}
> +
> +const struct dma_fence_ops drm_crtc_fence_ops = {
> + .get_driver_name = drm_crtc_fence_get_driver_name,
> + .get_timeline_name = drm_crtc_fence_get_timeline_name,
> + .enable_signaling = drm_crtc_fence_enable_signaling,
> + .wait = dma_fence_default_wait,
> +};
> +
> /**
> * drm_crtc_init_with_planes - Initialise a new CRTC object with
> *specified primary and cursor planes.
> @@ -222,6 +248,11 @@ int drm_crtc_init_with_planes(struct drm_device *dev,
> struct drm_crtc *crtc,
> return -ENOMEM;
> }
>
> + crtc->fence_context = dma_fence_context_alloc(1);
> + spin_lock_init(&crtc->fence_lock);
> + snprintf(crtc->timeline_name, sizeof(crtc->timeline_name),
> +"CRTC:%d-%s", crtc->base.id, crtc->name);
> +
> crtc->base.properties = &crtc->properties;
>
> list_add_tail(&crtc->head, &config->crtc_list);
> diff --git a/include/drm/drm_crtc.h b/include/drm/drm_crtc.h
> index 11780a9..0870de1 100644
> --- a/include/drm/drm_crtc.h
> +++ b/include/drm/drm_crtc.h
> @@ -32,6 +32,8 @@
> #include
> #include
> #include
> +#include
> +#include
> #include
> #include
> #include
> @@ -739,9 +741,52 @@ struct drm_crtc {
> */
> struct drm_crtc_crc crc;
> #endif
> +
> + /**
> +* @fence_context:
> +*
> +* timeline context used for fence operations.
> +*/
> + unsigned int fence_context;
> +
> + /**
> +* @fence_lock:
> +*
> +* spinlock to protect the fences in the fence_context.
> +*/
> +
> + spinlock_t fence_lock;
> + /**
> +* @fence_seqno:
> +*
> +* Seqno variable used as monotonic counter for the fences
> +* created on the CRTC's timeline.
> +*/
> + unsigned long fence_seqno;
> +
> + /**
> +* @timeline_name:
> +*
> +* The name of the CRTC's fence timeline.
> +*/
> + char timeline_name[32];
> };
>
> /**
> + * dma_crtc_fence_ops - fence ops for the drm_crtc timeline
> + *
> + * It contains the dma_fence_ops that should be called by the dma_fence
> + * code. CRTC core should use this ops when initializing fences.
> + */
> +extern const struct dma_fence_ops drm_crtc_fence_ops;
> +
> +static inline struct drm_crtc *fence_to_crtc(struct dma_fence *fence)
> +{
> + BUG_ON(fence->ops != &drm_crtc_fence_ops);
> + return container_of(fence->lock, struct drm_crtc, fence_lock);
> +}
> +
> +/**
> * struct drm_mode_set - new values for a CRTC config change
> * @fb: framebuffer to use for new config
> * @crtc: CRTC whose configuration we're about to change
> --
> 2.5.5
>
[Intel-gfx] [PATCH 5/5] drm/i915: Implement Link Rate fallback on Link training failure
On Fri, Nov 11, 2016 at 11:41:22AM +0200, Jani Nikula wrote:
> On Thu, 10 Nov 2016, Daniel Vetter wrote:
> > On Wed, Nov 09, 2016 at 08:42:08PM -0800, Manasi Navare wrote:
> >> @@ -5692,6 +5751,39 @@ static bool intel_edp_init_connector(struct
> >> intel_dp *intel_dp,
> >>return false;
> >> }
> >>
> >> +static void intel_dp_modeset_retry_work_fn(struct work_struct *work)
> >> +{
> >> + struct intel_connector *intel_connector;
> >> + struct drm_connector *connector;
> >> + struct drm_display_mode *mode;
> >> + bool verbose_prune = true;
> >> +
> >> + intel_connector = container_of(work, typeof(*intel_connector),
> >> + modeset_retry_work);
> >> + connector = &intel_connector->base;
> >> +
> >> + /* Grab the locks before changing connector property*/
> >> + mutex_lock(&connector->dev->mode_config.mutex);
> >> + DRM_DEBUG_KMS("[CONNECTOR:%d:%s]\n", connector->base.id,
> >> +connector->name);
> >> + list_for_each_entry(mode, &connector->modes, head) {
> >> + mode->status = intel_dp_mode_valid(connector,
> >> + mode);
> >> + }
> >> + drm_mode_prune_invalid(connector->dev, &connector->modes,
> >> + verbose_prune);
> >> +
> >> + /* Set connector link status to BAD and send a Uevent to notify
> >> + * userspace to do a modeset.
> >> + */
> >> + intel_dp_set_link_status_property(connector,
> >> +DRM_MODE_LINK_STATUS_BAD);
> >> + mutex_unlock(&connector->dev->mode_config.mutex);
> >> +
> >> + /* Send Hotplug uevent so userspace can reprobe */
> >> + drm_kms_helper_hotplug_event(connector->dev);
> >
> > One downside of keeping all the signalling logic here in i915 is that we
> > don't have a good spot to put the kerneldoc for this new link status
> > property within drm_connector.c for others to easily spot. My suggestion
> > would be to extract function with the following rough pseudo-code:
>
> Thanks for this. I wanted Manasi to keep the work struct and function
> within i915, but I fell short of coming up with this division.
>
> BR,
> Jani.
>
>
Jani, so we ar elooking at two functions going in core,
1. that does mode validation and pruning
2. set link status property
These should be in a separate patch right after declaring the
drm connector property, what do you think?
Regards
Manasi
>
> >
> > drm_connector_set_link_status(connector, status)
> > {
> > mutex_lock(mode_config.mutex);
> >
> > /* what intel_dp_set_link_status_property() does */
> >
> > mutex_unlock(mode_config.mutex);
> > drm_kms_helper_hotplug_event()
> > }
> >
> > Within intel_dp_modeset_retry_work_fn we'd then first need to drop the
> > lock, and then call this function. The lock drop&reacquire is a bit ugly,
> > but:
> > - it doesn't matter from a performance pov, this is a slow, asynchronous
> > work.
> > - it doesn't matter for correctnes, the only thing we need is to drop the
> > lock before calling drm_kms_helper_hotplug_event, and that we update the
> > link status and the mode list before that too.
> > - long term I expect that properties will get separate locks to protect
> > their values, and restrict mode_config.mutex to just mode probing. Which
> > means drm_connnector_set_link_status will use a different lock anyway.
> > - it nicely encapsulates stuff imo.
> >
> > Kerneldoc for drm_connector_set_link_status should mention that this needs
> > to be run from some async work item, and ofc have the full explanation
> > (maybe even quote some pseudo-code, see e.g. drm_modeset_lock.c comments)
> > of how this should be used.
> >
> > Since this is late-stage polish definitely wait for more feedback and for
> > the design to fully settle first.
> > -Daniel
>
> --
> Jani Nikula, Intel Open Source Technology Center
> ___
> dri-devel mailing list
> dri-devel at lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH libdrm] headers: Add README file
On Fri, Nov 11, 2016 at 8:44 AM, Emil Velikov
wrote:
> On 10 November 2016 at 21:07, Alex Deucher wrote:
>> On Thu, Nov 10, 2016 at 11:44 AM, Emil Velikov
>> wrote:
>>> From: Emil Velikov
>>>
>>> Since we're trying to standardise and make things more consistent in
>>> the area, add a basic README which covers some of the more popular
>>> topics.
>>>
>>> Cc: Dave Airlie
>>> Cc: Daniel Vetter
>>> Signed-off-by: Emil Velikov
>>> ---
>>> Dave, did I get it right on the "why only drm files should live here" ?
>>>
>>> Dave, Daniel, which trees/branches [in drm-misc] we can use as reference
>>> point here ?
>>> ---
>>> include/drm/README | 72
>>> ++
>>> 1 file changed, 72 insertions(+)
>>> create mode 100644 include/drm/README
>>>
>>> diff --git a/include/drm/README b/include/drm/README
>>> new file mode 100644
>>> index 000..2f80c15
>>> --- /dev/null
>>> +++ b/include/drm/README
>>> @@ -0,0 +1,72 @@
>>> +What are these headers ?
>>> +
>>> +This is the canonical source of drm headers that user space should use for
>>> +communicating with the kernel DRM subsystem.
>>> +
>>> +They flow from the kernel, thus any changes must be merged there first.
>>> +Do _not_ attempt to "fix" these by deviating from the kernel ones !
>>> +
>>> +
>>> +Non-linux platforms - changes/patches
>>> +-
>>> +If your platform has local changes, please send them upstream for
>>> inclusion.
>>> +Even if your patches don't get accepted in their current form, devs will
>>> +give you feedback on how to address things properly.
>>> +
>>> +git send-email --subject-prefix="PATCH libdrm" your patches to dri-devel
>>> +mailing list.
>>> +
>>> +Before doing so, please consider the following:
>>> + - Have the [libdrm vs kernel] headers on your platform deviated ?
>>> +Consider unifying them first.
>>> +
>>> + - Have you introduced additional ABI that's not available in Linux ?
>>> +Propose it for [Linux kernel] upstream inclusion.
>>> +If that doesn't work out (hopefully it never does), move it to another
>>> header
>>> +and/or keep the change(s) local ?
>>> +
>>> + - Are your changes DRI1/UMS specific ?
>>> +There is virtually no interest/power in keeping those legacy interfaces.
>>> They
>>> +are around due to the kernel "thou shalt not break existing user space"
>>> rule.
>>> +
>>> +Consider porting the driver to DRI2/KMS - all (almost?) sensible hardware
>>> is
>>> +capable of supporting those.
>>> +
>>> +
>>> +Which headers go where ?
>>> +
>>> +A snipped from the, now removed, Makefile.am used to state:
>>> +
>>> + XXX airlied says, nothing besides *_drm.h and drm*.h should be necessary.
>>> + however, r300 and via need their reg headers installed in order to build.
>>> + better solutions are welcome.
>>> +
>>> +Obviously the r300 and via headers are no longer around ;-)
>>> +
>>> +Reason behind is that the drm headers can be used as a basic communications
>>> +channel with the respective kernel modules. If more advanced functionality
>>> is
>>> +required one can pull the specific libdrm_$driver which is free to pull
>>> +additional files from the kernel.
>>> +
>>> +For example: nouveau has nouveau/nvif/*.h while vc4 has vc4/*.h
>>> +
>>> +If your driver is still in prototyping/staging state, consider moving the
>>> +$driver_drm.h into $driver and _not_ installing it. An header providing
>>> opaque
>>> +definitions and access [via $driver_drmif.h or similar] would be better
>>> fit.
>>> +
>>> +
>>> +When and how to update these files
>>> +--
>>> +Ideally on each libdrm release these will be kept in sync, with the latest
>>> +released kernels. This way users won't need to provide local definitions.
>>> +
>>> +In order to update the files do the following:
>>> + - Switch to a Linux kernel tree/branch which is not rebased.
>>> +For example: airlied/drm-next, drm-misc/XXX
>>
>> If we just want to update it to the latest released kernel, why not
>> just specify Linus' tree? There's a chance there may be flux in -next
>> that you wouldn't necessarily want in libdrm.
> My understanding is that things are "fully carved in stone" only as
> they reach Linus. Yet things in drm-next are good enough.
>
>> Also, I think
>> generally, it would be the individual driver maintainers or people
>> working on specific core features that do this. Does it really make
>> sense to update these en masse regularly?
>>
> Ideally we'll mass import (update only) from Linus and do individuals
> (from -next) as devs. deem fit. We want the former since devs can
> forget about the latter.
> Former is "not there yet", so I'll add a mention on the whole topic.
>
> Speaking of which - can anyone from the team skim through amdgpu_drm.h
> and radeon_drm.h update them.
> Former is trivial, while the latter needs a closer look:
> - missing (trailing) padding -
> drm_radeon_gem_{create,{g,s}
[PATCH RFC 00/12] tda998x updates
On 11/11/16 17:27, Russell King - ARM Linux wrote: > On Fri, Nov 11, 2016 at 05:10:09PM +0200, Jyri Sarha wrote: >> On 11/08/16 14:24, Russell King - ARM Linux wrote: >>> As no one responded to the previous round, I'm not spending soo much >>> time writing up a description of these changes again. It's also been >>> quite a long time, so I've forgotten all the details of the changes, >>> so I'll do my best. >>> >>> Changes from the previous series include: >>> - reorder the initial three patches >>> - change the (now third patch)... I think to increase the size of the >>> locked region. >>> - fix edid parsing for infoframe generation - as was pointed out for >>> dw-hdmi, parsing the EDID in get_modes() is incorrect, as that method >>> will not be called when an override-edid is in effect. We need to >>> parse the override-edid. Moreover, infoframe generation should not >>> be keyed to whether the monitor is HDMI or not, CEA-861B allows non- >>> HDMI to send infoframes. >>> - only send audio if audio and infoframes are supported. >>> >>> Otherwise, these are very much like the previous posting of the series, >>> except rebased upon the mali/hdlcd/tda998x change to remove the >>> drm_connector_register() call. >>> >>> https://www.spinics.net/lists/dri-devel/msg121495.html >>> >>> It'd be nice to have other tda998x users ack and test these patches, >>> I've tried to test on Juno, but the Juno situation seems to be a huge >>> fail. (HBI0282B completely fails with latest firmware - (a) FPGA image >>> incompatibilities io_b118 causes all FPGA AMBA devices to vanish, (b) >>> seems no way to get SCPI support on it - adding the BL0 executable >>> start address in the SCC registers seems to be incompatible with the >>> devchip, causing the PLLs to fail. In discussion with Sudeep over >>> these issues, but no idea where things are with it at the moment, other >>> than Sudeep needs to investigate. All Linaro firmware releases are >>> broken on HBI0282B.) >>> >>> drivers/gpu/drm/i2c/tda998x_drv.c | 826 >>> -- >>> 1 file changed, 429 insertions(+), 397 deletions(-) >>> >> >> Reviewed-by: Jyri Sarha >> >> For the whole series. I am also happy to test these patches if I can >> fetch them from some git repo. > > git://git.armlinux.org.uk/~rmk/linux-arm.git drm-tda998x-devel > > The commit IDs are unstable, because I'll have to recommit them to add > your r-by and any other tags you later give me. :) > I tested the branch with my Beaglebone-black and couple of TVs. I played audio on different sample-rates while plugging and unplugging the cable to the TVs and changing video modes. Everything worked as it should. I let you decide whether or not this adhoc testing qualifies: Tested-by: Jyri Sarha Best regards, Jyri
[PATCH] drm/atomic: fix memory leak when fetching format name
From: Colin Ian King
drm_get_format_name allocates memory that is not currently free'd
when printing the state. Fix this by kfree'ing the memory after
use.
Signed-off-by: Colin Ian King
---
drivers/gpu/drm/drm_atomic.c | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/drm_atomic.c b/drivers/gpu/drm/drm_atomic.c
index f5ea7db..1d5e86a 100644
--- a/drivers/gpu/drm/drm_atomic.c
+++ b/drivers/gpu/drm/drm_atomic.c
@@ -917,9 +917,10 @@ static void drm_atomic_plane_print_state(struct
drm_printer *p,
if (state->fb) {
struct drm_framebuffer *fb = state->fb;
int i, n = drm_format_num_planes(fb->pixel_format);
+ char *format_name = drm_get_format_name(fb->pixel_format);
- drm_printf(p, "\t\tformat=%s\n",
- drm_get_format_name(fb->pixel_format));
+ drm_printf(p, "\t\tformat=%s\n", format_name);
+ kfree(format_name);
drm_printf(p, "\t\tsize=%dx%d\n", fb->width, fb->height);
drm_printf(p, "\t\tlayers:\n");
for (i = 0; i < n; i++) {
--
2.10.2
BUG: 'list_empty(&vgdev->free_vbufs)' is true!
On 11/09/2016, 09:01 AM, Gerd Hoffmann wrote:
> On Di, 2016-11-08 at 22:37 +0200, Michael S. Tsirkin wrote:
>> On Mon, Nov 07, 2016 at 09:43:24AM +0100, Jiri Slaby wrote:
>>> Hi,
>>>
>>> I can relatively easily reproduce this bug:
>
> How?
Run dmesg -w in the qemu window (virtio_gpu) to see a lot of output.
Run pps [1] without exit(0); on e.g. serial console.
Wait a bit. The lot of output causes the BUG.
[1] https://github.com/jirislaby/collected_sources/blob/master/pps.c
>>> BUG: 'list_empty(&vgdev->free_vbufs)' is true!
>
>> The following might be helpful for debugging - if kernel still will
>> not stop panicing, we are looking at some kind
>> of memory corruption.
>
> Looking carefully through the code I think it isn't impossible to
> trigger this, but you need for that:
>
> (1) command queue full (quite possible),
> (2) cursor queue full too (unlikely), and
> (3) multiple threads trying to submit commands and waiting for free
> space in the command queue (possible with virgl enabled).
I use -vga virtio with no -display option, so no virtgl, I suppose:
[drm] virgl 3d acceleration not available
> Do things improve if you allocate some extra bufs?
>
> int virtio_gpu_alloc_vbufs(struct virtio_gpu_device *vgdev)
> {
> struct virtio_gpu_vbuffer *vbuf;
> - int i, size, count = 0;
> + int i, size, count = 16;
This seems to help.
thanks,
--
js
suse labs
[Bug 98005] VCE dual instance encoding inconsistent since st/va: enable dual instances encode by sync surface
https://bugs.freedesktop.org/show_bug.cgi?id=98005
--- Comment #8 from Boyuan Zhang ---
(In reply to Andy Furniss from comment #7)
> (In reply to Boyuan Zhang from comment #6)
> > Hi Andy,
> >
> > I just submitted 2 reviews for fixing the bit-rate issue. The 2 patches can
> > be found at
> > https://lists.freedesktop.org/archives/mesa-dev/2016-November/134944.html
> >
> > 0001-st/va: force to submit two consecutive single jobs
> > 0002-st/va: fix gop size for rate control
> >
> > Please give a try and let me know how it works.
> >
> > Regards,
> > Boyuan
>
> Hi, I can't get those to apply to current mesa head.
>
> Checking patch src/gallium/state_trackers/va/picture.c...
> Hunk #1 succeeded at 413 (offset 1 line).
> Hunk #2 succeeded at 568 (offset 1 line).
> Checking patch src/gallium/state_trackers/va/surface.c...
> error: while searching for:
>
>if (context->decoder->entrypoint == PIPE_VIDEO_ENTRYPOINT_ENCODE) {
> int frame_diff;
> if (context->desc.h264enc.frame_num_cnt > surf->frame_num_cnt)
> frame_diff = context->desc.h264enc.frame_num_cnt -
> surf->frame_num_cnt;
> else
> frame_diff = 0x - surf->frame_num_cnt + 1 +
> context->desc.h264enc.frame_num_cnt;
> if (frame_diff < 2)
> context->decoder->flush(context->decoder);
> context->decoder->get_feedback(context->decoder, surf->feedback,
> &(surf->coded_buf->coded_size));
>}
>pipe_mutex_unlock(drv->mutex);
>
> error: patch failed: src/gallium/state_trackers/va/surface.c:119
> error: src/gallium/state_trackers/va/surface.c: patch does not apply
> Checking patch src/gallium/state_trackers/va/va_private.h...
> Hunk #2 succeeded at 275 (offset 1 line).
>
> and
>
> Checking patch src/gallium/state_trackers/va/picture.c...
> Hunk #1 succeeded at 351 (offset 1 line).
> error: while searching for:
>context->desc.h264enc.not_referenced = false;
>context->desc.h264enc.is_idr = (h264->pic_fields.bits.idr_pic_flag == 1);
>context->desc.h264enc.pic_order_cnt = h264->CurrPic.TopFieldOrderCnt / 2;
>if (context->desc.h264enc.is_idr)
> context->desc.h264enc.i_remain = 1;
>else
> context->desc.h264enc.i_remain = 0;
>
>context->desc.h264enc.p_remain = context->desc.h264enc.gop_size -
> context->desc.h264enc.gop_cnt - context->desc.h264enc.i_remain;
>
>
> error: patch failed: src/gallium/state_trackers/va/picture.c:390
> error: src/gallium/state_trackers/va/picture.c: patch does not apply
> Checking patch src/gallium/state_trackers/va/va_private.h...
Hi Andy,
Sorry about that. Just rebased my codes. Please find the new patches here:
https://lists.freedesktop.org/archives/mesa-dev/2016-November/135076.html
https://lists.freedesktop.org/archives/mesa-dev/2016-November/135077.html
Regards,
Boyuan
--
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<https://lists.freedesktop.org/archives/dri-devel/attachments/2016/a4af8d43/attachment-0001.html>
[Intel-gfx] [PATCH 0/5] Handle Link Training Failure during modeset
On Fri, Nov 11, 2016 at 04:21:58PM +, Cheng, Tony wrote: > For HDMI, you can yank the cable, plug back in, HDMI will light up without > user mode or kernel mode doing anything. > > For DP this is not possible, someone will have to retrain the link when > plugging back in or DP will not light up. We see that on Ubuntu if someone > unplug display and plug it back into same connector, we do not get KMS so in > this case. It appears there is some optimizations somewhere in user mode > stack which I am not familiar with yet. dal added workaround to retrain the > link to light it back up (after the test training at end of detection). The link should get retrained as the driver should check the link state on HPD and retrain if it's not good. At least that's what we do in i915. Of course if it's not the same display that got plugged back, the retraining might fail. The new property can help with that case as userspace would then attempt a full modeset after the failed link training. > > >From user mode perspective I think it make sense to keep CRTC running, so > >vblank is still going so UMD isn't impacted. As regard to connector and > >encoder does it matter if kernel mode change state without user mode > >knowing? It seems to me those are more informational to UMD as UMD doesn't > >act on them. > > windows does not know link state and all link management is hidden behind > kernel driver. If the user visible state doesn't change in any way, then the kernel could try to manage it all internally. > > -Original Message- > From: Ville Syrjälä [mailto:ville.syrjala at linux.intel.com] > Sent: Friday, November 11, 2016 9:05 AM > To: Cheng, Tony > Cc: Deucher, Alexander ; 'Jani Nikula' > ; Manasi Navare intel.com>; dri-devel at lists.freedesktop.org; intel-gfx at > lists.freedesktop.org; Wentland, Harry ; Peres, > Martin > Subject: Re: [Intel-gfx] [PATCH 0/5] Handle Link Training Failure during > modeset > > On Thu, Nov 10, 2016 at 06:51:40PM +, Cheng, Tony wrote: > > Amdgpu dal implementation will do a test link training at end of detection > > to verify we can achieve the capability reported in DPCD. We then report > > mode base on result of test training. > > > > AMD hardware (at least the generations supported by amdgpu) is able to link > > train without timing being setup (DP encoder and CRTC is decoupled). Do we > > have limitation from other vendors where you need timing to be there before > > you can link train? > > I can't recall the specifics for all of our supported platforms, but at least > I have the recollection that it would be the case yes. > > The other problem wiyh this apporach is that even if you don't need the crtc, > you still need the link itself. What happens if the link is still active > since userspace just didn't bother to shut it down when the cable was yanked? > Can you keep the crtc going but stop it from feeding the link in a way that > userspace won't be able to notice? The kms design has always been pretty much > that policy is in userspace, and thus the kernel shouldn't shut down crtcs > unless explicitly asked to do so. > > > > > We can also past DP1.2 link layer compliance with this approach. > > > > -Original Message- > > From: Deucher, Alexander > > Sent: Thursday, November 10, 2016 1:43 PM > > To: 'Jani Nikula' ; Manasi Navare > > ; dri-devel at lists.freedesktop.org; > > intel-gfx at lists.freedesktop.org; Wentland, Harry > > ; Cheng, Tony > > Cc: Dave Airlie ; Peres, Martin > > > > Subject: RE: [Intel-gfx] [PATCH 0/5] Handle Link Training Failure > > during modeset > > > > Adding Harry and Tony from our display team to review. > > > > > -Original Message- > > > From: Jani Nikula [mailto:jani.nikula at linux.intel.com] > > > Sent: Thursday, November 10, 2016 1:20 PM > > > To: Manasi Navare; dri-devel at lists.freedesktop.org; intel- > > > gfx at lists.freedesktop.org > > > Cc: Dave Airlie; Peres, Martin; Deucher, Alexander > > > Subject: Re: [Intel-gfx] [PATCH 0/5] Handle Link Training Failure > > > during modeset > > > > > > On Thu, 10 Nov 2016, Manasi Navare wrote: > > > > Link training failure is handled by lowering the link rate first > > > > until it reaches the minimum and keeping the lane count maximum > > > > and then lowering the lane count until it reaches minimim. These > > > > fallback values are saved and hotplug uevent is sent to the > > > > userspace after setting the connector link status property to BAD. > > > > Userspace should triiger another modeset on a uevent and if link > > > > status property is BAD. This will retrain the link at fallback values. > > > > This is repeated until the link is successfully trained. > > > > > > > > This has been validated to pass DP compliance. > > > > > > This cover letter and the commit messages do a good job of > > > explaining what the patches do. However, you're lacking the crucial > > > information of > > > *why*
[PATCH v8 3/3] drm/fence: add out-fences support
On Fri, Nov 11, 2016 at 9:15 AM, Gustavo Padovan wrote:
> From: Gustavo Padovan
>
> Support DRM out-fences by creating a sync_file with a fence for each CRTC
> that sets the OUT_FENCE_PTR property.
>
> We use the out_fence pointer received in the OUT_FENCE_PTR prop to send
> the sync_file fd back to userspace.
>
> The sync_file and fd are allocated/created before commit, but the
> fd_install operation only happens after we know that commit succeed.
>
> v2: Comment by Rob Clark:
> - Squash commit that adds DRM_MODE_ATOMIC_OUT_FENCE flag here.
>
> Comment by Daniel Vetter:
> - Add clean up code for out_fences
>
> v3: Comments by Daniel Vetter:
> - create DRM_MODE_ATOMIC_EVENT_MASK
> - userspace should fill out_fences_ptr with the crtc_ids for which
> it wants fences back.
>
> v4: Create OUT_FENCE_PTR properties and remove old approach.
>
> v5: Comments by Brian Starkey:
> - Remove extra fence_get() in atomic_ioctl()
> - Check ret before iterating on the crtc_state
> - check ret before fd_install
> - set fence_state to NULL at the beginning
> - check fence_state->out_fence_ptr before put_user()
> - change order of fput() and put_unused_fd() on failure
>
> - Add access_ok() check to the out_fence_ptr received
> - Rebase after fence -> dma_fence rename
> - Store out_fence_ptr in the drm_atomic_state
> - Split crtc_setup_out_fence()
> - return -1 as out_fence with TEST_ONLY flag
>
> v6: Comments by Daniel Vetter
> - Add prepare/unprepare_crtc_signaling()
> - move struct drm_out_fence_state to drm_atomic.c
> - mark get_crtc_fence() as static
>
> Comments by Brian Starkey
> - proper set fence_ptr fence_state array
> - isolate fence_idx increment
>
> - improve error handling
>
> v7: Comments by Daniel Vetter
> - remove prefix from internal functions
> - make out_fence_ptr an s64 pointer
> - degrade DRM_INFO to DRM_DEBUG_ATOMIC when put_user fail
> - fix doc issues
> - filter out OUT_FENCE_PTR == NULL and do not fail in this case
> - add complete_crtc_signalling()
> - krealloc fence_state on demand
>
> Comment by Brian Starkey
> - remove unused crtc_state arg from get_out_fence()
>
> v8: Comment by Brian Starkey
> - cancel events before check for !fence_state
> - convert a few lefovers u64 types for out_fence_ptr
> - fix memleak by assign fence_state earlier after realloc
> - proper accout num_fences in case of error
>
> Signed-off-by: Gustavo Padovan
A couple of nits below, other than that, looks good to me
> ---
> drivers/gpu/drm/drm_atomic.c | 243
> +++
> drivers/gpu/drm/drm_crtc.c | 8 ++
> include/drm/drm_atomic.h | 1 +
> include/drm/drm_crtc.h | 6 ++
> 4 files changed, 213 insertions(+), 45 deletions(-)
>
> diff --git a/drivers/gpu/drm/drm_atomic.c b/drivers/gpu/drm/drm_atomic.c
> index 8e26ad1..34cdc6e 100644
> --- a/drivers/gpu/drm/drm_atomic.c
> +++ b/drivers/gpu/drm/drm_atomic.c
> @@ -290,6 +290,23 @@ drm_atomic_get_crtc_state(struct drm_atomic_state *state,
> }
> EXPORT_SYMBOL(drm_atomic_get_crtc_state);
>
> +static void set_out_fence_for_crtc(struct drm_atomic_state *state,
> + struct drm_crtc *crtc, s64 __user
> *fence_ptr)
> +{
> + state->crtcs[drm_crtc_index(crtc)].out_fence_ptr = fence_ptr;
> +}
> +
> +static s64 __user * get_out_fence_for_crtc(struct drm_atomic_state *state,
> + struct drm_crtc *crtc)
> +{
> + s64 __user *fence_ptr;
> +
> + fence_ptr = state->crtcs[drm_crtc_index(crtc)].out_fence_ptr;
> + state->crtcs[drm_crtc_index(crtc)].out_fence_ptr = NULL;
> +
> + return fence_ptr;
> +}
> +
> /**
> * drm_atomic_set_mode_for_crtc - set mode for CRTC
> * @state: the CRTC whose incoming state to update
> @@ -491,6 +508,16 @@ int drm_atomic_crtc_set_property(struct drm_crtc *crtc,
> &replaced);
> state->color_mgmt_changed |= replaced;
> return ret;
> + } else if (property == config->prop_out_fence_ptr) {
> + s64 __user *fence_ptr = u64_to_user_ptr(val);
> +
> + if (!fence_ptr)
> + return 0;
> +
> + if (!access_ok(VERIFY_WRITE, fence_ptr, sizeof(*fence_ptr)))
> + return -EFAULT;
> +
> + set_out_fence_for_crtc(state->state, crtc, fence_ptr);
> } else if (crtc->funcs->atomic_set_property)
> return crtc->funcs->atomic_set_property(crtc, state,
> property, val);
> else
> @@ -533,6 +560,8 @@ drm_atomic_crtc_get_property(struct drm_crtc *crtc,
> *val = (state->ctm) ? state->ctm->base.id : 0;
> else if (property == config->gamma_lut_proper
[PATCH] drm/etnaviv: Allow DRAW_INSTANCED commands
Vivante GPUs with HALTI0 feature support a DRAW_INSTANCED command in the command stream to draw a number of instances of the same geometry. The information that has been figured out about the command can be found here: https://github.com/etnaviv/etna_viv/blob/master/rnndb/cmdstream.xml#L270 This command is not allowed currently by the DRM driver because it was not known before. This patch enables parsing it in command streams and allows using it by userspace drivers. Signed-off-by: Wladimir J. van der Laan --- drivers/gpu/drm/etnaviv/cmdstream.xml.h | 60 ++-- drivers/gpu/drm/etnaviv/etnaviv_cmd_parser.c | 1 + 2 files changed, 57 insertions(+), 4 deletions(-) diff --git a/drivers/gpu/drm/etnaviv/cmdstream.xml.h b/drivers/gpu/drm/etnaviv/cmdstream.xml.h index 8c44ba9..65f1ba1 100644 --- a/drivers/gpu/drm/etnaviv/cmdstream.xml.h +++ b/drivers/gpu/drm/etnaviv/cmdstream.xml.h @@ -8,10 +8,34 @@ This file was generated by the rules-ng-ng headergen tool in this git repository git clone git://0x04.net/rules-ng-ng The rules-ng-ng source files this header was generated from are: -- cmdstream.xml ( 12589 bytes, from 2014-02-17 14:57:56) -- common.xml( 18437 bytes, from 2015-03-25 11:27:41) - -Copyright (C) 2014 +- cmdstream.xml ( 14094 bytes, from 2016-11-11 06:55:14) +- copyright.xml ( 1597 bytes, from 2016-10-29 07:29:22) +- common.xml( 23344 bytes, from 2016-11-10 15:14:07) + +Copyright (C) 2012-2016 by the following authors: +- Wladimir J. van der Laan +- Christian Gmeiner +- Lucas Stach +- Russell King + +Permission is hereby granted, free of charge, to any person obtaining a +copy of this software and associated documentation files (the "Software"), +to deal in the Software without restriction, including without limitation +the rights to use, copy, modify, merge, publish, distribute, sub license, +and/or sell copies of the Software, and to permit persons to whom the +Software is furnished to do so, subject to the following conditions: + +The above copyright notice and this permission notice (including the +next paragraph) shall be included in all copies or substantial portions +of the Software. + +THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR +IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, +FITNESS FOR A PARTICULAR PURPOSE AND NON-INFRINGEMENT. IN NO EVENT SHALL +THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER +LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING +FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER +DEALINGS IN THE SOFTWARE. */ @@ -26,6 +50,7 @@ Copyright (C) 2014 #define FE_OPCODE_STALL 0x0009 #define FE_OPCODE_CALL 0x000a #define FE_OPCODE_RETURN 0x000b +#define FE_OPCODE_DRAW_INSTANCED 0x000c #define FE_OPCODE_CHIP_SELECT 0x000d #define PRIMITIVE_TYPE_POINTS 0x0001 #define PRIMITIVE_TYPE_LINES 0x0002 @@ -214,5 +239,32 @@ Copyright (C) 2014 #define VIV_FE_CHIP_SELECT_HEADER_ENABLE_CHIP1 0x0002 #define VIV_FE_CHIP_SELECT_HEADER_ENABLE_CHIP0 0x0001 +#define VIV_FE_DRAW_INSTANCED 0x + +#define VIV_FE_DRAW_INSTANCED_HEADER 0x +#define VIV_FE_DRAW_INSTANCED_HEADER_OP__MASK 0xf800 +#define VIV_FE_DRAW_INSTANCED_HEADER_OP__SHIFT 27 +#define VIV_FE_DRAW_INSTANCED_HEADER_OP_DRAW_INSTANCED 0x6000 +#define VIV_FE_DRAW_INSTANCED_HEADER_INDEXED 0x0010 +#define VIV_FE_DRAW_INSTANCED_HEADER_TYPE__MASK 0x000f +#define VIV_FE_DRAW_INSTANCED_HEADER_TYPE__SHIFT 16 +#define VIV_FE_DRAW_INSTANCED_HEADER_TYPE(x) (((x) << VIV_FE_DRAW_INSTANCED_HEADER_TYPE__SHIFT) & VIV_FE_DRAW_INSTANCED_HEADER_TYPE__MASK) +#define VIV_FE_DRAW_INSTANCED_HEADER_INSTANCE_COUNT_LO__MASK 0x +#define VIV_FE_DRAW_INSTANCED_HEADER_INSTANCE_COUNT_LO__SHIFT 0 +#define VIV_FE_DRAW_INSTANCED_HEADER_INSTANCE_COUNT_LO(x) (((x) << VIV_FE_DRAW_INSTANCED_HEADER_INSTANCE_COUNT_LO__SHIFT) & VIV_FE_DRAW_INSTANCED_HEADER_INSTANCE_COUNT_LO__MASK) + +#define VIV_FE_DRAW_INSTANCED_COUNT0x0004 +#define VIV_FE_DRAW_INSTANCED_COUNT_INSTANCE_COUNT_HI__MASK0xff00 +#define VIV_FE_DRAW_INSTANCED_COUNT_INSTANCE_COUNT_HI__SHIFT 24 +#define VIV_FE_DRAW_INSTANCED_COUNT_INSTANCE_COUNT_HI(x) (((x) << VIV_FE_DRAW_INSTANCED_COUNT_INSTANCE_COUNT_HI__SHIFT) & VIV_FE_DRAW_INSTANCED_COUNT_INSTANCE_COUNT_HI__MASK) +#define VIV_FE_DRAW_INSTANCED_COUNT_VERTEX_COUNT__MASK 0x00ff +#define VIV_
[PATCH 1/2] Revert "drm: Add and handle new aspect ratios in DRM layer"
On Thu, Nov 03, 2016 at 02:31:43PM +0200, ville.syrjala at linux.intel.com wrote: > From: Ville Syrjälä > > This reverts commit a68362fe3e84fcbedd49939aa200519aa5410135. > > Adding new mode flags willy nilly breaks existing userspace. We need to > coordinate this better, potentially with a new client cap that only > exposes the aspect ratio flags when userspace is prepared for them > (similar to what we do with stereo 3D modes). As a demonstration here's the change in the xrandr mode list after doing the revert: HDMI2 connected 1920x1080+0+0 (normal left inverted right x axis y axis) 700mm x 390mm - 1920x1080 60.00*+ - 1920x1080i60.0050.00 + 1920x1080 60.00*+ 50.0059.9430.0025.0024.0029.97 23.98 + 1920x1080i60.0050.0059.94 1600x1200 60.00 1680x1050 59.88 1280x1024 75.0260.02 @@ -13,30 +13,29 @@ 1360x768 60.02 1280x800 59.91 1152x864 75.00 - 1280x720 60.0050.00 + 1280x720 60.0050.0059.94 1024x768 75.0370.0760.00 832x624 74.55 800x600 72.1975.0060.32 - 640x480 75.0072.8166.6759.94 + 720x576 50.00 + 720x480 60.0059.94 + 640x480 75.0072.8166.6760.0059.94 720x400 70.08 This was with sna, which does this: #define KNOWN_MODE_FLAGS ((1<<14)-1) if (mode->status == MODE_OK && kmode->flags & ~KNOWN_MODE_FLAGS) mode->status = MODE_BAD; /* unknown flags => unhandled */ so all the modes with an aspect ratio just vanished. -modesetting and -ati on the other hand just copy over the unknown bits into the xrandr mode structure, which sounds dubious at best: mode->Flags = kmode->flags; //& FLAG_BITS; I've not checked what damage it can actually cause. It looks like a few modes disappeared from the kernel's mode list as well, presumably because some cea modes in the list originated from DTDs and whanot so they don't have an aspect ratio and that causes add_alternate_cea_modes() to ignore them. So not populating an aspect ratio for cea modes originating from a source other than edid_cea_modes[] looks like another bug to me as well. Another bug I think might be the ordering of the modes with aspect ratio specified. IIRC the spec says that the preferred aspect ratio should be listed first in the EDID, but I don't think we preserve that ordering in the final mode list. I guess we could fix that by somehow noting which aspect ratio is preferred and sort based on that, or we try to preserve the order from the EDID until we're ready to sort, and then do the sorting with a stable algorithm. -- Ville Syrjälä Intel OTC
[PATCH 1/2] Revert "drm: Add and handle new aspect ratios in DRM layer"
On Fri, Nov 11, 2016 at 07:00:17PM +0200, Ville Syrjälä wrote: > On Thu, Nov 03, 2016 at 02:31:43PM +0200, ville.syrjala at linux.intel.com > wrote: > > From: Ville Syrjälä > > > > This reverts commit a68362fe3e84fcbedd49939aa200519aa5410135. > > > > Adding new mode flags willy nilly breaks existing userspace. We need to > > coordinate this better, potentially with a new client cap that only > > exposes the aspect ratio flags when userspace is prepared for them > > (similar to what we do with stereo 3D modes). > > As a demonstration here's the change in the xrandr mode list after doing > the revert: > > HDMI2 connected 1920x1080+0+0 (normal left inverted right x axis y axis) > 700mm x 390mm > - 1920x1080 60.00*+ > - 1920x1080i60.0050.00 > + 1920x1080 60.00*+ 50.0059.9430.0025.0024.0029.97 >23.98 > + 1920x1080i60.0050.0059.94 > 1600x1200 60.00 > 1680x1050 59.88 > 1280x1024 75.0260.02 > @@ -13,30 +13,29 @@ > 1360x768 60.02 > 1280x800 59.91 > 1152x864 75.00 > - 1280x720 60.0050.00 > + 1280x720 60.0050.0059.94 > 1024x768 75.0370.0760.00 > 832x624 74.55 > 800x600 72.1975.0060.32 > - 640x480 75.0072.8166.6759.94 > + 720x576 50.00 > + 720x480 60.0059.94 > + 640x480 75.0072.8166.6760.0059.94 > 720x400 70.08 > > This was with sna, which does this: > #define KNOWN_MODE_FLAGS ((1<<14)-1) > if (mode->status == MODE_OK && kmode->flags & ~KNOWN_MODE_FLAGS) > mode->status = MODE_BAD; /* unknown flags => unhandled */ > so all the modes with an aspect ratio just vanished. > > -modesetting and -ati on the other hand just copy over the unknown > bits into the xrandr mode structure, which sounds dubious at best: > mode->Flags = kmode->flags; //& FLAG_BITS; > I've not checked what damage it can actually cause. > > > It looks like a few modes disappeared from the kernel's mode list > as well, presumably because some cea modes in the list originated from > DTDs and whanot so they don't have an aspect ratio and that causes > add_alternate_cea_modes() to ignore them. So not populating an aspect > ratio for cea modes originating from a source other than > edid_cea_modes[] looks like another bug to me as well. Oh and I guess this is also the reason most people didn't notice anything wrong. The preferred mode usually (or maybe always?) comes from some other source than edid_cea_modes[] and hence doesn't tend to go AWOL. -- Ville Syrjälä Intel OTC
[PATCH 1/2] Revert "drm: Add and handle new aspect ratios in DRM layer"
On Fri, Nov 11, 2016 at 12:00 PM, Ville Syrjälä wrote: > On Thu, Nov 03, 2016 at 02:31:43PM +0200, ville.syrjala at linux.intel.com > wrote: >> From: Ville Syrjälä >> >> This reverts commit a68362fe3e84fcbedd49939aa200519aa5410135. >> >> Adding new mode flags willy nilly breaks existing userspace. We need to >> coordinate this better, potentially with a new client cap that only >> exposes the aspect ratio flags when userspace is prepared for them >> (similar to what we do with stereo 3D modes). > > As a demonstration here's the change in the xrandr mode list after doing > the revert: > > HDMI2 connected 1920x1080+0+0 (normal left inverted right x axis y axis) > 700mm x 390mm > - 1920x1080 60.00*+ > - 1920x1080i60.0050.00 > + 1920x1080 60.00*+ 50.0059.9430.0025.0024.0029.97 >23.98 > + 1920x1080i60.0050.0059.94 > 1600x1200 60.00 > 1680x1050 59.88 > 1280x1024 75.0260.02 > @@ -13,30 +13,29 @@ > 1360x768 60.02 > 1280x800 59.91 > 1152x864 75.00 > - 1280x720 60.0050.00 > + 1280x720 60.0050.0059.94 > 1024x768 75.0370.0760.00 > 832x624 74.55 > 800x600 72.1975.0060.32 > - 640x480 75.0072.8166.6759.94 > + 720x576 50.00 > + 720x480 60.0059.94 > + 640x480 75.0072.8166.6760.0059.94 > 720x400 70.08 > > This was with sna, which does this: > #define KNOWN_MODE_FLAGS ((1<<14)-1) > if (mode->status == MODE_OK && kmode->flags & ~KNOWN_MODE_FLAGS) > mode->status = MODE_BAD; /* unknown flags => unhandled */ > so all the modes with an aspect ratio just vanished. > > -modesetting and -ati on the other hand just copy over the unknown > bits into the xrandr mode structure, which sounds dubious at best: > mode->Flags = kmode->flags; //& FLAG_BITS; > I've not checked what damage it can actually cause. What problems could this cause? Presumably the kernel driver has validated the modes already or they wouldn't showing up in the first place. Or is your concern that something in the xserver itself may barf on the new flags? Alex
[PATCH 1/2] Revert "drm: Add and handle new aspect ratios in DRM layer"
On Fri, Nov 11, 2016 at 6:07 PM, Alex Deucher wrote: >> This was with sna, which does this: >> #define KNOWN_MODE_FLAGS ((1<<14)-1) >> if (mode->status == MODE_OK && kmode->flags & ~KNOWN_MODE_FLAGS) >> mode->status = MODE_BAD; /* unknown flags => unhandled */ >> so all the modes with an aspect ratio just vanished. >> >> -modesetting and -ati on the other hand just copy over the unknown >> bits into the xrandr mode structure, which sounds dubious at best: >> mode->Flags = kmode->flags; //& FLAG_BITS; >> I've not checked what damage it can actually cause. > > What problems could this cause? Presumably the kernel driver has > validated the modes already or they wouldn't showing up in the first > place. Or is your concern that something in the xserver itself may > barf on the new flags? See above snipped from sna, we now lost a bunch of modes. -Daniel -- Daniel Vetter Software Engineer, Intel Corporation +41 (0) 79 365 57 48 - http://blog.ffwll.ch
[PATCH v8 3/3] drm/fence: add out-fences support
On Fri, Nov 11, 2016 at 11:48:09AM -0500, Sean Paul wrote:
> On Fri, Nov 11, 2016 at 9:15 AM, Gustavo Padovan
> wrote:
> > +static void complete_crtc_signaling(struct drm_device *dev,
> > +struct drm_atomic_state *state,
> > +struct drm_out_fence_state
> > *fence_state,
> > +unsigned int num_fences, int ret)
> > +{
> > + struct drm_crtc *crtc;
> > + struct drm_crtc_state *crtc_state;
> > + int i;
> > +
> > + if (!ret) {
>
> I don't think there's any reason to smash the fd install and clean-up
> into one function. I think splitting into 2 functions and calling the
> right one from atomic_ioctl would be better.
Hm, I suggested this because the control flow in one of Gustavo's earlier
patches look really funny. I guess it could be split up again, but with
both callers in the current position. tbh I don't care whether it's this
or that, both are clear improvement over the older version.
-Daniel
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
[PATCH] drm/atomic: fix memory leak when fetching format name
On Friday, 2016-11-11 16:26:22 +, Colin King wrote:
> From: Colin Ian King
>
> drm_get_format_name allocates memory that is not currently free'd
> when printing the state. Fix this by kfree'ing the memory after
> use.
You are correct, but there are more cases of this, and another fix
has been chosen. See this patch [1] for the fix and the rest of that
thread [2] for the discussion.
I'll send v4 (rebase and a missed `const`) as soon as I have the time,
but the usage will remain the same as in v3.
Cheers,
Eric
[1] https://lists.freedesktop.org/archives/dri-devel/2016-November/123250.html
[2]
https://lists.freedesktop.org/archives/dri-devel/2016-November/thread.html#122845
>
> Signed-off-by: Colin Ian King
> ---
> drivers/gpu/drm/drm_atomic.c | 5 +++--
> 1 file changed, 3 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/gpu/drm/drm_atomic.c b/drivers/gpu/drm/drm_atomic.c
> index f5ea7db..1d5e86a 100644
> --- a/drivers/gpu/drm/drm_atomic.c
> +++ b/drivers/gpu/drm/drm_atomic.c
> @@ -917,9 +917,10 @@ static void drm_atomic_plane_print_state(struct
> drm_printer *p,
> if (state->fb) {
> struct drm_framebuffer *fb = state->fb;
> int i, n = drm_format_num_planes(fb->pixel_format);
> + char *format_name = drm_get_format_name(fb->pixel_format);
>
> - drm_printf(p, "\t\tformat=%s\n",
> - drm_get_format_name(fb->pixel_format));
> + drm_printf(p, "\t\tformat=%s\n", format_name);
> + kfree(format_name);
> drm_printf(p, "\t\tsize=%dx%d\n", fb->width, fb->height);
> drm_printf(p, "\t\tlayers:\n");
> for (i = 0; i < n; i++) {
> --
> 2.10.2
>
[PATCH v8 3/3] drm/fence: add out-fences support
On Fri, Nov 11, 2016 at 12:11 PM, Daniel Vetter wrote:
> On Fri, Nov 11, 2016 at 11:48:09AM -0500, Sean Paul wrote:
>> On Fri, Nov 11, 2016 at 9:15 AM, Gustavo Padovan
>> wrote:
>> > +static void complete_crtc_signaling(struct drm_device *dev,
>> > +struct drm_atomic_state *state,
>> > +struct drm_out_fence_state
>> > *fence_state,
>> > +unsigned int num_fences, int ret)
>> > +{
>> > + struct drm_crtc *crtc;
>> > + struct drm_crtc_state *crtc_state;
>> > + int i;
>> > +
>> > + if (!ret) {
>>
>> I don't think there's any reason to smash the fd install and clean-up
>> into one function. I think splitting into 2 functions and calling the
>> right one from atomic_ioctl would be better.
>
> Hm, I suggested this because the control flow in one of Gustavo's earlier
> patches look really funny. I guess it could be split up again, but with
> both callers in the current position. tbh I don't care whether it's this
> or that, both are clear improvement over the older version.
I really don't have a strong opinion either. Perhaps meet in the
middle and pass bool install_fds instead of ret (since that's kind of
an anti-pattern)?
Sean
> -Daniel
> --
> Daniel Vetter
> Software Engineer, Intel Corporation
> http://blog.ffwll.ch
[PATCH 1/2] Revert "drm: Add and handle new aspect ratios in DRM layer"
On Fri, Nov 11, 2016 at 12:07:29PM -0500, Alex Deucher wrote: > On Fri, Nov 11, 2016 at 12:00 PM, Ville Syrjälä > wrote: > > On Thu, Nov 03, 2016 at 02:31:43PM +0200, ville.syrjala at linux.intel.com > > wrote: > >> From: Ville Syrjälä > >> > >> This reverts commit a68362fe3e84fcbedd49939aa200519aa5410135. > >> > >> Adding new mode flags willy nilly breaks existing userspace. We need to > >> coordinate this better, potentially with a new client cap that only > >> exposes the aspect ratio flags when userspace is prepared for them > >> (similar to what we do with stereo 3D modes). > > > > As a demonstration here's the change in the xrandr mode list after doing > > the revert: > > > > HDMI2 connected 1920x1080+0+0 (normal left inverted right x axis y axis) > > 700mm x 390mm > > - 1920x1080 60.00*+ > > - 1920x1080i60.0050.00 > > + 1920x1080 60.00*+ 50.0059.9430.0025.0024.00 > > 29.9723.98 > > + 1920x1080i60.0050.0059.94 > > 1600x1200 60.00 > > 1680x1050 59.88 > > 1280x1024 75.0260.02 > > @@ -13,30 +13,29 @@ > > 1360x768 60.02 > > 1280x800 59.91 > > 1152x864 75.00 > > - 1280x720 60.0050.00 > > + 1280x720 60.0050.0059.94 > > 1024x768 75.0370.0760.00 > > 832x624 74.55 > > 800x600 72.1975.0060.32 > > - 640x480 75.0072.8166.6759.94 > > + 720x576 50.00 > > + 720x480 60.0059.94 > > + 640x480 75.0072.8166.6760.0059.94 > > 720x400 70.08 > > > > This was with sna, which does this: > > #define KNOWN_MODE_FLAGS ((1<<14)-1) > > if (mode->status == MODE_OK && kmode->flags & ~KNOWN_MODE_FLAGS) > > mode->status = MODE_BAD; /* unknown flags => unhandled */ > > so all the modes with an aspect ratio just vanished. > > > > -modesetting and -ati on the other hand just copy over the unknown > > bits into the xrandr mode structure, which sounds dubious at best: > > mode->Flags = kmode->flags; //& FLAG_BITS; > > I've not checked what damage it can actually cause. > > What problems could this cause? As I wrote, I haven't analyzed the potential damage from this. Either something in the server might go wonky, or maybe we even leak that stuff over the protocol all the way to the clients? Not sure. > Presumably the kernel driver has > validated the modes already or they wouldn't showing up in the first > place. Or is your concern that something in the xserver itself may > barf on the new flags? > > Alex -- Ville Syrjälä Intel OTC
[Bug 98687] Discrete R5 M330 GPU stopped working completely
https://bugs.freedesktop.org/show_bug.cgi?id=98687 Bug ID: 98687 Summary: Discrete R5 M330 GPU stopped working completely Product: DRI Version: DRI git Hardware: Other OS: All Status: NEW Keywords: bisected, regression Severity: normal Priority: medium Component: DRM/Radeon Assignee: dri-devel at lists.freedesktop.org Reporter: pavel.ondracka at email.cz CC: alexdeucher at gmail.com Created attachment 127916 --> https://bugs.freedesktop.org/attachment.cgi?id=127916&action=edit dmesg After Fedora updated the kernel to 4.8 my discrete AMD GPU stopped working. Even the most simple commands like DRI_PRIME=1 glxinfo produce: radeon: Failed to allocate virtual address for buffer: radeon:size : 65536 bytes radeon:alignment : 4096 bytes radeon:domains : 4 radeon:va: 0x0080 radeon: Failed to deallocate virtual address for buffer: radeon:size : 65536 bytes radeon:va: 0x80 .. radeonsi: Failed to create a context. X Error of failed request: GLXBadContext Major opcode of failed request: 154 (GLX) Minor opcode of failed request: 6 (X_GLXIsDirect) Serial number of failed request: 44 Current serial number in output stream: 43 Dmesg from booting and attempting to run glxinfo is attached. I managed to bisect it to: b817634276f7f68c9d1d6d4a27117ff3c2f16956 is the first bad commit commit b817634276f7f68c9d1d6d4a27117ff3c2f16956 Author: Alex Deucher Date: Tue Aug 9 00:21:45 2016 -0400 Revert "drm/radeon: work around lack of upstream ACPI support for D3cold" This reverts commit bdfb76040068d960cb9e226876be8a508d741c4a. Now that d3cold is upstream, there is no more need for this workaround. Reverting this commit from top of the current linux git fixes things for me. This might be duplicate of bug 98505, however this is with radeon driver instead of the amdgpu, so filling separately. This is Lenovo G50-80 laptop discrete GPU: 04:00.0 Display controller: Advanced Micro Devices, Inc. [AMD/ATI] Sun XT [Radeon HD 8670A/8670M/8690M / R5 M330 / M430] (rev ff) integrated GPU: 00:02.0 VGA compatible controller: Intel Corporation HD Graphics 5500 (rev 09) Mesa: 12.0.3-2.fc24 Libdrm: 2.4.71-2.fc24 -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <https://lists.freedesktop.org/archives/dri-devel/attachments/2016/1df82587/attachment.html>
[PATCH v8 3/3] drm/fence: add out-fences support
Spotted one more thing on a cleanup path...
On Fri, Nov 11, 2016 at 11:15:59PM +0900, Gustavo Padovan wrote:
>From: Gustavo Padovan
>
>Support DRM out-fences by creating a sync_file with a fence for each CRTC
>that sets the OUT_FENCE_PTR property.
>
>We use the out_fence pointer received in the OUT_FENCE_PTR prop to send
>the sync_file fd back to userspace.
>
>The sync_file and fd are allocated/created before commit, but the
>fd_install operation only happens after we know that commit succeed.
>
>v2: Comment by Rob Clark:
> - Squash commit that adds DRM_MODE_ATOMIC_OUT_FENCE flag here.
>
>Comment by Daniel Vetter:
> - Add clean up code for out_fences
>
>v3: Comments by Daniel Vetter:
> - create DRM_MODE_ATOMIC_EVENT_MASK
> - userspace should fill out_fences_ptr with the crtc_ids for which
> it wants fences back.
>
>v4: Create OUT_FENCE_PTR properties and remove old approach.
>
>v5: Comments by Brian Starkey:
> - Remove extra fence_get() in atomic_ioctl()
> - Check ret before iterating on the crtc_state
> - check ret before fd_install
> - set fence_state to NULL at the beginning
> - check fence_state->out_fence_ptr before put_user()
> - change order of fput() and put_unused_fd() on failure
>
> - Add access_ok() check to the out_fence_ptr received
> - Rebase after fence -> dma_fence rename
> - Store out_fence_ptr in the drm_atomic_state
> - Split crtc_setup_out_fence()
> - return -1 as out_fence with TEST_ONLY flag
>
>v6: Comments by Daniel Vetter
> - Add prepare/unprepare_crtc_signaling()
> - move struct drm_out_fence_state to drm_atomic.c
> - mark get_crtc_fence() as static
>
>Comments by Brian Starkey
> - proper set fence_ptr fence_state array
> - isolate fence_idx increment
>
>- improve error handling
>
>v7: Comments by Daniel Vetter
> - remove prefix from internal functions
> - make out_fence_ptr an s64 pointer
> - degrade DRM_INFO to DRM_DEBUG_ATOMIC when put_user fail
> - fix doc issues
> - filter out OUT_FENCE_PTR == NULL and do not fail in this case
> - add complete_crtc_signalling()
> - krealloc fence_state on demand
>
>Comment by Brian Starkey
> - remove unused crtc_state arg from get_out_fence()
>
>v8: Comment by Brian Starkey
> - cancel events before check for !fence_state
> - convert a few lefovers u64 types for out_fence_ptr
> - fix memleak by assign fence_state earlier after realloc
> - proper accout num_fences in case of error
>
>Signed-off-by: Gustavo Padovan
>---
> drivers/gpu/drm/drm_atomic.c | 243 +++
> drivers/gpu/drm/drm_crtc.c | 8 ++
> include/drm/drm_atomic.h | 1 +
> include/drm/drm_crtc.h | 6 ++
> 4 files changed, 213 insertions(+), 45 deletions(-)
>
>diff --git a/drivers/gpu/drm/drm_atomic.c b/drivers/gpu/drm/drm_atomic.c
>index 8e26ad1..34cdc6e 100644
>--- a/drivers/gpu/drm/drm_atomic.c
>+++ b/drivers/gpu/drm/drm_atomic.c
>@@ -290,6 +290,23 @@ drm_atomic_get_crtc_state(struct drm_atomic_state *state,
> }
> EXPORT_SYMBOL(drm_atomic_get_crtc_state);
>
>+static void set_out_fence_for_crtc(struct drm_atomic_state *state,
>+ struct drm_crtc *crtc, s64 __user *fence_ptr)
>+{
>+ state->crtcs[drm_crtc_index(crtc)].out_fence_ptr = fence_ptr;
>+}
>+
>+static s64 __user * get_out_fence_for_crtc(struct drm_atomic_state *state,
>+ struct drm_crtc *crtc)
>+{
>+ s64 __user *fence_ptr;
>+
>+ fence_ptr = state->crtcs[drm_crtc_index(crtc)].out_fence_ptr;
>+ state->crtcs[drm_crtc_index(crtc)].out_fence_ptr = NULL;
>+
>+ return fence_ptr;
>+}
>+
> /**
> * drm_atomic_set_mode_for_crtc - set mode for CRTC
> * @state: the CRTC whose incoming state to update
>@@ -491,6 +508,16 @@ int drm_atomic_crtc_set_property(struct drm_crtc *crtc,
> &replaced);
> state->color_mgmt_changed |= replaced;
> return ret;
>+ } else if (property == config->prop_out_fence_ptr) {
>+ s64 __user *fence_ptr = u64_to_user_ptr(val);
>+
>+ if (!fence_ptr)
>+ return 0;
>+
>+ if (!access_ok(VERIFY_WRITE, fence_ptr, sizeof(*fence_ptr)))
>+ return -EFAULT;
>+
>+ set_out_fence_for_crtc(state->state, crtc, fence_ptr);
> } else if (crtc->funcs->atomic_set_property)
> return crtc->funcs->atomic_set_property(crtc, state, property,
> val);
> else
>@@ -533,6 +560,8 @@ drm_atomic_crtc_get_property(struct drm_crtc *crtc,
> *val = (state->ctm) ? state->ctm->base.id : 0;
> else if (property == config->gamma_lut_property)
> *val = (state->gamma_lut) ? state->gamma_lut->base.id : 0;
>+ else if (property == config->prop_out_fence_ptr)
>+ *val = 0;
>
[PATCH 2/2] drm/i915: Update i915_driver_load kerneldoc
On Thu, Nov 10, 2016 at 03:36:34PM +0200, Joonas Lahtinen wrote: > Update i915_driver_load kerneldoc to match code. > > Cc: Chris Wilson > Signed-off-by: Joonas Lahtinen Reviewed-by: Chris Wilson -Chris -- Chris Wilson, Intel Open Source Technology Centre
[Bug 98687] Discrete R5 M330 GPU stopped working completely
https://bugs.freedesktop.org/show_bug.cgi?id=98687 Alex Deucher changed: What|Removed |Added Resolution|--- |DUPLICATE Status|NEW |RESOLVED --- Comment #1 from Alex Deucher --- *** This bug has been marked as a duplicate of bug 98505 *** -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <https://lists.freedesktop.org/archives/dri-devel/attachments/20161111/1abd3012/attachment.html>
[Bug 98505] [Topaz] Regression introduces in 4.8-rc3
https://bugs.freedesktop.org/show_bug.cgi?id=98505 Alex Deucher changed: What|Removed |Added CC||pavel.ondracka at email.cz --- Comment #18 from Alex Deucher --- *** Bug 98687 has been marked as a duplicate of this bug. *** -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <https://lists.freedesktop.org/archives/dri-devel/attachments/20161111/ca187e45/attachment.html>
[Bug 98505] [radeon, amdgpu] Regression introduced in 4.8-rc3
https://bugs.freedesktop.org/show_bug.cgi?id=98505 Alex Deucher changed: What|Removed |Added Summary|[Topaz] Regression |[radeon, amdgpu] Regression |introduces in 4.8-rc3 |introduced in 4.8-rc3 -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <https://lists.freedesktop.org/archives/dri-devel/attachments/20161111/2428b599/attachment.html>
[Bug 98505] [radeon, amdgpu] Regression introduced in 4.8-rc3
https://bugs.freedesktop.org/show_bug.cgi?id=98505 --- Comment #19 from Alex Deucher --- (In reply to Peter Wu from comment #16) > Ok, do you have any certainty about the earliest BIOS date where _PR3 is > used? E.g. if the minimum date is lowered to 2014 without checking for _PR3, > would it be likely to miss out some models? Can you add me to any relevant threads? I'd like to help get this fixed for 4.9. -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <https://lists.freedesktop.org/archives/dri-devel/attachments/2016/667125a0/attachment.html>
[Bug 98505] [radeon, amdgpu] Regression introduced in 4.8-rc3
https://bugs.freedesktop.org/show_bug.cgi?id=98505 --- Comment #20 from Peter Wu --- (In reply to Alex Deucher from comment #19) > (In reply to Peter Wu from comment #16) > > Ok, do you have any certainty about the earliest BIOS date where _PR3 is > > used? E.g. if the minimum date is lowered to 2014 without checking for _PR3, > > would it be likely to miss out some models? > > Can you add me to any relevant threads? I'd like to help get this fixed for > 4.9. I will, but did you get any feedback from the Windows architects yet? I'd like to get some solid reasons that support lowering the version requirement. -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <https://lists.freedesktop.org/archives/dri-devel/attachments/2016/9303f3f9/attachment.html>
[PATCH 01/10] drm: bridge/dw_hdmi: add dw hdmi i2c bus adapter support
Hi Ulrich, On 11/11/2016 07:07 PM, Ulrich Hecht wrote: > From: Vladimir Zapolskiy > > The change adds support of internal HDMI I2C master controller, this > subdevice is used by default, if "ddc-i2c-bus" DT property is omitted. > > The main purpose of this functionality is to support reading EDID from > an HDMI monitor on boards, which don't have an I2C bus connected to > DDC pins. > > The current implementation does not support "I2C Master Interface > Extended Read Mode" to read data addressed by non-zero segment > pointer, this means that if EDID has more than 1 extension blocks, > EDID reading operation won't succeed, in my practice all tested HDMI > monitors have at maximum one extension block. > > Signed-off-by: Vladimir Zapolskiy > Acked-by: Rob Herring many thanks to Philipp for pushing the change, as for today, it is in drm-next: https://cgit.freedesktop.org/~airlied/linux/commit/?h=drm-next&id=90233ee5d1 -- With best wishes, Vladimir
[Bug 97879] [amdgpu] Rocket League: long hangs (several seconds) when loading assets (models/textures/shaders?)
https://bugs.freedesktop.org/show_bug.cgi?id=97879 --- Comment #43 from Steven --- I also experience the issue. If someone can explain or point me to how I can profile it I can also try to provide some api traces. I'm running Mesa 12.0.3 OpenGL renderer string: Gallium 0.4 on AMD HAWAII (DRM 2.46.0 / 4.8.0-27-generic, LLVM 3.8.1) AMD 290X intel i7 -- You are receiving this mail because: You are on the CC list for the bug. -- next part -- An HTML attachment was scrubbed... URL: <https://lists.freedesktop.org/archives/dri-devel/attachments/2016/8b3084e7/attachment.html>
[PATCH libdrm] headers: Add README file
On Fri, Nov 11, 2016 at 5:21 PM, Alex Deucher wrote: > On Fri, Nov 11, 2016 at 8:44 AM, Emil Velikov > wrote: >> On 10 November 2016 at 21:07, Alex Deucher wrote: >>> On Thu, Nov 10, 2016 at 11:44 AM, Emil Velikov >> gmail.com> wrote: From: Emil Velikov Since we're trying to standardise and make things more consistent in the area, add a basic README which covers some of the more popular topics. Cc: Dave Airlie Cc: Daniel Vetter Signed-off-by: Emil Velikov --- Dave, did I get it right on the "why only drm files should live here" ? Dave, Daniel, which trees/branches [in drm-misc] we can use as reference point here ? --- include/drm/README | 72 ++ 1 file changed, 72 insertions(+) create mode 100644 include/drm/README diff --git a/include/drm/README b/include/drm/README new file mode 100644 index 000..2f80c15 --- /dev/null +++ b/include/drm/README @@ -0,0 +1,72 @@ +What are these headers ? + +This is the canonical source of drm headers that user space should use for +communicating with the kernel DRM subsystem. + +They flow from the kernel, thus any changes must be merged there first. +Do _not_ attempt to "fix" these by deviating from the kernel ones ! + + +Non-linux platforms - changes/patches +- +If your platform has local changes, please send them upstream for inclusion. +Even if your patches don't get accepted in their current form, devs will +give you feedback on how to address things properly. + +git send-email --subject-prefix="PATCH libdrm" your patches to dri-devel +mailing list. + +Before doing so, please consider the following: + - Have the [libdrm vs kernel] headers on your platform deviated ? +Consider unifying them first. + + - Have you introduced additional ABI that's not available in Linux ? +Propose it for [Linux kernel] upstream inclusion. +If that doesn't work out (hopefully it never does), move it to another header +and/or keep the change(s) local ? + + - Are your changes DRI1/UMS specific ? +There is virtually no interest/power in keeping those legacy interfaces. They +are around due to the kernel "thou shalt not break existing user space" rule. + +Consider porting the driver to DRI2/KMS - all (almost?) sensible hardware is +capable of supporting those. + + +Which headers go where ? + +A snipped from the, now removed, Makefile.am used to state: + + XXX airlied says, nothing besides *_drm.h and drm*.h should be necessary. + however, r300 and via need their reg headers installed in order to build. + better solutions are welcome. + +Obviously the r300 and via headers are no longer around ;-) + +Reason behind is that the drm headers can be used as a basic communications +channel with the respective kernel modules. If more advanced functionality is +required one can pull the specific libdrm_$driver which is free to pull +additional files from the kernel. + +For example: nouveau has nouveau/nvif/*.h while vc4 has vc4/*.h + +If your driver is still in prototyping/staging state, consider moving the +$driver_drm.h into $driver and _not_ installing it. An header providing opaque +definitions and access [via $driver_drmif.h or similar] would be better fit. + + +When and how to update these files +-- +Ideally on each libdrm release these will be kept in sync, with the latest +released kernels. This way users won't need to provide local definitions. + +In order to update the files do the following: + - Switch to a Linux kernel tree/branch which is not rebased. +For example: airlied/drm-next, drm-misc/XXX >>> >>> If we just want to update it to the latest released kernel, why not >>> just specify Linus' tree? There's a chance there may be flux in -next >>> that you wouldn't necessarily want in libdrm. >> My understanding is that things are "fully carved in stone" only as >> they reach Linus. Yet things in drm-next are good enough. >> >>> Also, I think >>> generally, it would be the individual driver maintainers or people >>> working on specific core features that do this. Does it really make >>> sense to update these en masse regularly? >>> >> Ideally we'll mass import (update only) from Linus and do individuals >> (from -next) as devs. deem fit. We want the former since devs can >> forget about the latter. >> Former is "not there yet", so I'll add a mention on the whole topic. >> >> Speaking of which - ca
[Bug 98505] [radeon, amdgpu] Regression introduced in 4.8-rc3
https://bugs.freedesktop.org/show_bug.cgi?id=98505 --- Comment #21 from Alex Deucher --- (In reply to Peter Wu from comment #20) > > I will, but did you get any feedback from the Windows architects yet? I'd > like to get some solid reasons that support lowering the version requirement. Still waiting to hear back if they have any opinion on the dates. On windows it will always use PR3 if it's available. -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <https://lists.freedesktop.org/archives/dri-devel/attachments/2016/10c290c3/attachment.html>
[PATCH v2] PCI: create revision file in sysfs
Hi Bjorn, On 11 November 2016 at 14:49, Bjorn Helgaas wrote: > On Fri, Nov 11, 2016 at 12:31:47AM +, Emil Velikov wrote: >> On 10 November 2016 at 23:59, Bjorn Helgaas wrote: >> > Hi Emil, >> > >> > On Thu, Nov 10, 2016 at 01:14:35PM +, Emil Velikov wrote: >> >> On 10 November 2016 at 07:13, Greg KH >> >> wrote: >> >> > On Wed, Nov 09, 2016 at 04:56:07PM +, Emil Velikov wrote: >> >> >> From: Emil Velikov >> >> >> >> >> >> Currently the revision isn't available via sysfs/libudev thus if one >> >> >> wants to know the value they need to read through the config file. >> >> >> >> >> >> This in itself wakes/powers up the device, causing unwanted delays. >> >> >> >> >> >> There are at least two userspace components which could make use the >> >> >> new >> >> >> file - libpciaccess and libdrm. At the moment the former will wake up >> >> >> _every_ PCI device for simple invocation of glxinfo [when using Mesa >> >> >> 10.0+ drivers]. While the latter [in association with Mesa 13.0] can >> >> >> lead to 2-3 second delays while starting firefox, thunderbird or >> >> >> chromium. >> > >> > I agree, these unwanted delays are completely unacceptable. My >> > question is whether we should fix them by exporting more information >> > from the kernel, or by changing the way the userspace components work. >> > >> > It should not take anywhere near 2 seconds to wake up a PCI device. >> > That makes me think there's a more serious problem than just a lack of >> > caching for the revision field, e.g., maybe we're looking at far more >> > PCI devices than we need to, or we're doing it many times to the same >> > device, or ... >> > >> > If I understand correctly, the delay was bisected to >> > https://cgit.freedesktop.org/mesa/mesa/commit/?id=be239326aa4f, which >> > removed a bunch of code that looked up the vendor and device IDs, and >> > replaced it with drmGetDevice(). And apparently drmGetDevice(), in >> > this path: >> > >> > drmGetDevice >> > drmProcessPciDevice >> > drmParsePciDeviceInfo >> > >> > is a little more thorough in that it looks up the *revision* in >> > addition to the vendor and device IDs. So we pay the cost for the >> > revision even though in this instance we don't care about the revision >> > at all. >> > >> Above all, apologies for all the "lovely" code that you had to go >> through for these. >> And yes, you've got it spot on. >> >> > drmParsePciDeviceInfo() currently reads the whole config header from >> > sysfs (https://cgit.freedesktop.org/drm/libdrm/tree/xf86drm.c#n2949), >> > but I think you're extending that to try the vendor, device, >> > subsystem_vendor, subsystem_device, and (if present) revision sysfs >> > files first (http://www.spinics.net/lists/dri-devel/msg122319.html). >> > >> Yes, making the revision file optional and "faking it" was my first >> thought, esp. since we don't have any users of it (yet). >> Although people are not too keen on it, so we'll likely opt for >> revision-less API. >> >> > Bottom line, I guess I'm not super opposed to this, but I do feel like >> > we're making a kernel change to cover up a userspace problem, and I >> > think it would be better to push on that userspace problem a little >> > more. >> > >> Yes, definitely we can beat some sense into userspace. Yet that >> shouldn't be a deterrent for exposing the revision. > > Maybe. If we speed things up by extending this kernel ABI, there's > much less incentive to optimize the userspace stuff. I feel a little > bit like an enabler for undesirable userspace behavior :) > Yes, fixing userspace to not do silly things is the goal. But at the same time even if userspace is perfect, there is no reason to power on the device just to get the revision field, is it ? Especially since everything else is readily available. >> As hinted before the other prominent user libpciaccess wakes up probes >> _every_ pci device. > > Is it really necessary to probe *every* PCI device? That doesn't > sound like a scalable design. > > As you can tell, the argument that "we should add this kernel ABI to > make suboptimal userspace algorithms go faster" doesn't feel very > compelling to me. > "Don't shoot the messenger" comes to mind. I'm just the stupid^Wnice person who's trying to untangle unfortunate design decisions - don't force me to rewrite more than a dozen pieces of software, please ? Even then, I wonder how long it'll take for those to hit end users. Yes I see your concern - userspace does do stupid stuff. Yet it [sometimes] must know the information and the current way of retrieving it (waking up the device) is quite sub-optimal. Thanks Emil P.S. Some drivers have custom ioctls to retrieve the device info (incl. revision). Surely we won't want to continue promoting/assisting that ?
[PATCH libdrm] xd86drm: read more than 128 bytes of uevent in drmParsePciBusInfo
From: Emil Velikov
Some platforms (such as Macs using OF) can have more information in the
uevent file thus reading only the first 128 might not be sufficient.
Bump it to 512, which "should be enough for everybody" ;-)
Cc: Mingcong Bai
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=98629
Signed-off-by: Emil Velikov
---
Mingcong Bai, this should fix things but you'll need to apply it
on top of your libdrm package. There's no need to rebuild mesa
afterwords.
Note to self:
Strictly speaking we can rework drmGetDevice[s] to use [just] uevent...
---
xf86drm.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/xf86drm.c b/xf86drm.c
index 676effc..80e2f27 100644
--- a/xf86drm.c
+++ b/xf86drm.c
@@ -2871,7 +2871,7 @@ static int drmParsePciBusInfo(int maj, int min,
drmPciBusInfoPtr info)
{
#ifdef __linux__
char path[PATH_MAX + 1];
-char data[128 + 1];
+char data[512 + 1];
char *str;
int domain, bus, dev, func;
int fd, ret;
@@ -2882,7 +2882,7 @@ static int drmParsePciBusInfo(int maj, int min,
drmPciBusInfoPtr info)
return -errno;
ret = read(fd, data, sizeof(data));
-data[128] = '\0';
+data[512] = '\0';
close(fd);
if (ret < 0)
return -errno;
--
2.10.2
[PATCH libdrm] headers: Add README file
On 11 November 2016 at 18:33, Marek Olšák wrote: > On Fri, Nov 11, 2016 at 5:21 PM, Alex Deucher > wrote: >> On Fri, Nov 11, 2016 at 8:44 AM, Emil Velikov >> wrote: >>> On 10 November 2016 at 21:07, Alex Deucher wrote: On Thu, Nov 10, 2016 at 11:44 AM, Emil Velikov >>> gmail.com> wrote: > From: Emil Velikov > > Since we're trying to standardise and make things more consistent in > the area, add a basic README which covers some of the more popular > topics. > > Cc: Dave Airlie > Cc: Daniel Vetter > Signed-off-by: Emil Velikov > --- > Dave, did I get it right on the "why only drm files should live here" ? > > Dave, Daniel, which trees/branches [in drm-misc] we can use as reference > point here ? > --- > include/drm/README | 72 > ++ > 1 file changed, 72 insertions(+) > create mode 100644 include/drm/README > > diff --git a/include/drm/README b/include/drm/README > new file mode 100644 > index 000..2f80c15 > --- /dev/null > +++ b/include/drm/README > @@ -0,0 +1,72 @@ > +What are these headers ? > + > +This is the canonical source of drm headers that user space should use > for > +communicating with the kernel DRM subsystem. > + > +They flow from the kernel, thus any changes must be merged there first. > +Do _not_ attempt to "fix" these by deviating from the kernel ones ! > + > + > +Non-linux platforms - changes/patches > +- > +If your platform has local changes, please send them upstream for > inclusion. > +Even if your patches don't get accepted in their current form, devs will > +give you feedback on how to address things properly. > + > +git send-email --subject-prefix="PATCH libdrm" your patches to dri-devel > +mailing list. > + > +Before doing so, please consider the following: > + - Have the [libdrm vs kernel] headers on your platform deviated ? > +Consider unifying them first. > + > + - Have you introduced additional ABI that's not available in Linux ? > +Propose it for [Linux kernel] upstream inclusion. > +If that doesn't work out (hopefully it never does), move it to another > header > +and/or keep the change(s) local ? > + > + - Are your changes DRI1/UMS specific ? > +There is virtually no interest/power in keeping those legacy interfaces. > They > +are around due to the kernel "thou shalt not break existing user space" > rule. > + > +Consider porting the driver to DRI2/KMS - all (almost?) sensible > hardware is > +capable of supporting those. > + > + > +Which headers go where ? > + > +A snipped from the, now removed, Makefile.am used to state: > + > + XXX airlied says, nothing besides *_drm.h and drm*.h should be > necessary. > + however, r300 and via need their reg headers installed in order to > build. > + better solutions are welcome. > + > +Obviously the r300 and via headers are no longer around ;-) > + > +Reason behind is that the drm headers can be used as a basic > communications > +channel with the respective kernel modules. If more advanced > functionality is > +required one can pull the specific libdrm_$driver which is free to pull > +additional files from the kernel. > + > +For example: nouveau has nouveau/nvif/*.h while vc4 has vc4/*.h > + > +If your driver is still in prototyping/staging state, consider moving the > +$driver_drm.h into $driver and _not_ installing it. An header providing > opaque > +definitions and access [via $driver_drmif.h or similar] would be better > fit. > + > + > +When and how to update these files > +-- > +Ideally on each libdrm release these will be kept in sync, with the > latest > +released kernels. This way users won't need to provide local definitions. > + > +In order to update the files do the following: > + - Switch to a Linux kernel tree/branch which is not rebased. > +For example: airlied/drm-next, drm-misc/XXX If we just want to update it to the latest released kernel, why not just specify Linus' tree? There's a chance there may be flux in -next that you wouldn't necessarily want in libdrm. >>> My understanding is that things are "fully carved in stone" only as >>> they reach Linus. Yet things in drm-next are good enough. >>> Also, I think generally, it would be the individual driver maintainers or people working on specific core features that do this. Does it really make sense to update these en masse regularly? >>> Ideally we'll mass import (update only) from Linus and do individuals >>> (f
[Bug 97988] [radeonsi] playing back videos with VDPAU exhibits deinterlacing/anti-aliasing issues not visible with VA-API
https://bugs.freedesktop.org/show_bug.cgi?id=97988 --- Comment #26 from Kai --- Created attachment 127922 --> https://bugs.freedesktop.org/attachment.cgi?id=127922&action=edit Updated version of attachment 127812 (In reply to Nicolai Hähnle from comment #20) > Created attachment 127812 > Mesa part of fix > > LLVM patch https://reviews.llvm.org/D26348 together with the attached patch > for Mesa fix this bug. I can confirm, that this seems to fix the issue for me. You can have my Tested-by: Kai Wasserbäch Note: I had to update attachment 127812 to the attached version in order to apply it on top of current Mesa master. See below for the full stack details. (In reply to Andy Furniss from comment #21) > (In reply to Nicolai Hähnle from comment #20) > > Created attachment 127812 [details] [review] [review] > > Mesa part of fix > > > > LLVM patch https://reviews.llvm.org/D26348 together with the attached patch > > for Mesa fix this bug. > > Nice, will test later, but is there a actually a nice way to get a patch > from Phabricator that will apply from top level with git apply? > > I usually fail with "download raw diff" and have to search/sort out the > paths by hand. patch -p0 is your friend. (If you use quilt: quilt import -p0) The stack used to verify the issue is fixed was (Debian testing as a base): GPU: Hawaii PRO [Radeon R9 290] (ChipID = 0x67b1) Mesa: Git:master/3ff9f8c532 + the modified version of attachment 127812 libdrm: 2.4.71-1 LLVM: SVN:trunk/r282761 (4.0 devel) + <https://reviews.llvm.org/D26348?download=true> X.Org: 2:1.18.4-2 Linux: 4.8.7 Firmware: Git:master/a179db9791 libclc: Git:master/520743b0b7 DDX (amdgpu): 1.1.2-1 -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <https://lists.freedesktop.org/archives/dri-devel/attachments/2016/f4ff4081/attachment.html>
[Bug 98505] [radeon, amdgpu] Regression introduced in 4.8-rc3
https://bugs.freedesktop.org/show_bug.cgi?id=98505 --- Comment #22 from Alex Deucher --- Update from our windows team: Hybrid graphics platforms using _PR3 were first available in Oct 2013 (when windows 8.1 was released). -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <https://lists.freedesktop.org/archives/dri-devel/attachments/20161111/1011ecde/attachment.html>
[Bug 98005] VCE dual instance encoding inconsistent since st/va: enable dual instances encode by sync surface
https://bugs.freedesktop.org/show_bug.cgi?id=98005 --- Comment #9 from Andy Furniss --- The transcoding test above now makes similar size to cbr. There is a new issue though. The GOP patch (2) is problematic. It doesn't show on the transcoding test, but after reading the patch comment about gop affecting rate control I tested with gstreamer default (30) and max = keyframe-period=300 With vbr plus high bitrates this makes a large difference in file size. This still happens if I disable dual instance in radeon_vce.c. CBR seems to be unaffected, though dual instance encoding seems to come out a bit lower than single instance. The vbr test = gst-launch-1.0 -f filesrc location=/mnt/ramdisk/trees-1440p50.nv12 blocksize=5529600 ! video/x-raw,format=NV12,width=2560,height=1440,framerate=50/1 ! queue ! vaapih264enc rate-control=vbr bitrate=5 keyframe-period=300 ! video/x-h264, profile=baseline ! filesink location=/mnt/ramdisk/out.264 Result = 9.4M file (source is 500 frames) above with keyframe-period=30 = 42M which is close to expected result. -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <https://lists.freedesktop.org/archives/dri-devel/attachments/2016/1bb86a6e/attachment.html>
[Bug 98005] VCE dual instance encoding inconsistent since st/va: enable dual instances encode by sync surface
https://bugs.freedesktop.org/show_bug.cgi?id=98005 --- Comment #10 from Andy Furniss --- Testing more/with a longer stream - cbr is affected by this as well, though the difference is smaller. -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <https://lists.freedesktop.org/archives/dri-devel/attachments/20161111/d28fbb8b/attachment-0001.html>
[Bug 97879] [amdgpu] Rocket League: long hangs (several seconds) when loading assets (models/textures/shaders?)
https://bugs.freedesktop.org/show_bug.cgi?id=97879 --- Comment #44 from Jani Kärkkäinen --- I'm quite sure I'm getting this as well. I'm however on a HD6850, so that'd be the r600 driver I believe? Anything I can do to help pinpoint the culprit? Some specs: OpenGL renderer string: Gallium 0.4 on AMD BARTS (DRM 2.46.0 / 4.8.7-xanmod9, LLVM 4.0.0) OpenGL core profile version string: 3.3 (Core Profile) Mesa 13.1.0-devel - padoka PPA Ubuntu Gnome 16.10 64-bit -- You are receiving this mail because: You are on the CC list for the bug. -- next part -- An HTML attachment was scrubbed... URL: <https://lists.freedesktop.org/archives/dri-devel/attachments/2016/672d0c0c/attachment.html>
[PATCH v8 3/3] drm/fence: add out-fences support
Hi Brian,
2016-11-11 Brian Starkey :
> Hi Gustavo,
>
> On Fri, Nov 11, 2016 at 02:16:09PM +0900, Gustavo Padovan wrote:
> > From: Gustavo Padovan
> >
> > Support DRM out-fences by creating a sync_file with a fence for each CRTC
> > that sets the OUT_FENCE_PTR property.
> >
> > We use the out_fence pointer received in the OUT_FENCE_PTR prop to send
> > the sync_file fd back to userspace.
> >
> > The sync_file and fd are allocated/created before commit, but the
> > fd_install operation only happens after we know that commit succeed.
> >
> > v2: Comment by Rob Clark:
> > - Squash commit that adds DRM_MODE_ATOMIC_OUT_FENCE flag here.
> >
> >Comment by Daniel Vetter:
> > - Add clean up code for out_fences
> >
> > v3: Comments by Daniel Vetter:
> > - create DRM_MODE_ATOMIC_EVENT_MASK
> > - userspace should fill out_fences_ptr with the crtc_ids for which
> > it wants fences back.
> >
> > v4: Create OUT_FENCE_PTR properties and remove old approach.
> >
> > v5: Comments by Brian Starkey:
> > - Remove extra fence_get() in atomic_ioctl()
> > - Check ret before iterating on the crtc_state
> > - check ret before fd_install
> > - set fence_state to NULL at the beginning
> > - check fence_state->out_fence_ptr before put_user()
> > - change order of fput() and put_unused_fd() on failure
> >
> > - Add access_ok() check to the out_fence_ptr received
> > - Rebase after fence -> dma_fence rename
> > - Store out_fence_ptr in the drm_atomic_state
> > - Split crtc_setup_out_fence()
> > - return -1 as out_fence with TEST_ONLY flag
> >
> > v6: Comments by Daniel Vetter
> > - Add prepare/unprepare_crtc_signaling()
> > - move struct drm_out_fence_state to drm_atomic.c
> > - mark get_crtc_fence() as static
> >
> >Comments by Brian Starkey
> > - proper set fence_ptr fence_state array
> > - isolate fence_idx increment
> >
> >- improve error handling
> >
> > v7: Comments by Daniel Vetter
> > - remove prefix from internal functions
> > - make out_fence_ptr an s64 pointer
> > - degrade DRM_INFO to DRM_DEBUG_ATOMIC when put_user fail
> > - fix doc issues
> > - filter out OUT_FENCE_PTR == NULL and do fail in this case
>
> Do *not* fail in this case?
>
> > - add complete_crtc_signalling()
> > - krealloc fence_state on demand
> >
> >Comment by Brian Starkey
> > - remove unused crtc_state arg from get_out_fence()
> >
> > Signed-off-by: Gustavo Padovan
>
> From an integration with writeback point of view, this looks fine to
> me - I can add writeback to this easily.
>
> A few comments below though:
>
> > ---
> > drivers/gpu/drm/drm_atomic.c | 242
> > +++
> > drivers/gpu/drm/drm_crtc.c | 8 ++
> > include/drm/drm_atomic.h | 1 +
> > include/drm/drm_crtc.h | 6 ++
> > 4 files changed, 212 insertions(+), 45 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/drm_atomic.c b/drivers/gpu/drm/drm_atomic.c
> > index 8e26ad1..cd39f13 100644
> > --- a/drivers/gpu/drm/drm_atomic.c
> > +++ b/drivers/gpu/drm/drm_atomic.c
> > @@ -290,6 +290,23 @@ drm_atomic_get_crtc_state(struct drm_atomic_state
> > *state,
> > }
> > EXPORT_SYMBOL(drm_atomic_get_crtc_state);
> >
> > +static void set_out_fence_for_crtc(struct drm_atomic_state *state,
> > + struct drm_crtc *crtc, u64 __user *fence_ptr)
> > +{
> > + state->crtcs[drm_crtc_index(crtc)].out_fence_ptr = fence_ptr;
> > +}
> > +
> > +static u64 __user * get_out_fence_for_crtc(struct drm_atomic_state *state,
> > + struct drm_crtc *crtc)
> > +{
> > + u64 __user *fence_ptr;
> > +
> > + fence_ptr = state->crtcs[drm_crtc_index(crtc)].out_fence_ptr;
> > + state->crtcs[drm_crtc_index(crtc)].out_fence_ptr = NULL;
> > +
> > + return fence_ptr;
> > +}
> > +
>
> You missed a couple of s/u64/s64/ in the two functions above.
>
> > /**
> > * drm_atomic_set_mode_for_crtc - set mode for CRTC
> > * @state: the CRTC whose incoming state to update
> > @@ -491,6 +508,16 @@ int drm_atomic_crtc_set_property(struct drm_crtc *crtc,
> > &replaced);
> > state->color_mgmt_changed |= replaced;
> > return ret;
> > + } else if (property == config->prop_out_fence_ptr) {
> > + s64 __user *fence_ptr = u64_to_user_ptr(val);
> > +
> > + if (!fence_ptr)
> > + return 0;
> > +
> > + if (!access_ok(VERIFY_WRITE, fence_ptr, sizeof(*fence_ptr)))
> > + return -EFAULT;
> > +
> > + set_out_fence_for_crtc(state->state, crtc, fence_ptr);
> > } else if (crtc->funcs->atomic_set_property)
> > return crtc->funcs->atomic_set_property(crtc, state, property,
> > val);
> > else
> > @@ -533,6 +560,8 @@ drm_atomic_crtc_get_property(struct drm_crtc *crtc,
> > *val = (state->ctm) ? state->ctm->base.id : 0;
> > els
[PATCH 08/10] arm64: dts: salvator-x: Add DU pins, HDMI connectors and encoder
From: Koji Matsuoka
Based on work by Koji Matsuoka.
[geert: Re-add removed extal_clk]
[geert: Modify existing du node instead of moving it around]
[geert: Use generic pinctrl properties]
Signed-off-by: Ulrich Hecht
---
arch/arm64/boot/dts/renesas/r8a7795-salvator-x.dts | 95 ++
1 file changed, 95 insertions(+)
diff --git a/arch/arm64/boot/dts/renesas/r8a7795-salvator-x.dts
b/arch/arm64/boot/dts/renesas/r8a7795-salvator-x.dts
index b1eab68..3c783dd 100644
--- a/arch/arm64/boot/dts/renesas/r8a7795-salvator-x.dts
+++ b/arch/arm64/boot/dts/renesas/r8a7795-salvator-x.dts
@@ -178,6 +178,44 @@
};
};
};
+
+ hdmi0-out {
+ compatible = "hdmi-connector";
+ type = "a";
+
+ port {
+ hdmi0_con: endpoint {
+ remote-endpoint = <&rcar_dw_hdmi0_out>;
+ };
+ };
+ };
+
+ hdmi1-out {
+ compatible = "hdmi-connector";
+ type = "a";
+
+ port {
+ hdmi1_con: endpoint {
+ remote-endpoint = <&rcar_dw_hdmi1_out>;
+ };
+ };
+ };
+};
+
+&programmable_clk0 {
+ clock-frequency = <14850>;
+};
+
+&x21_clk {
+ clock-frequency = <3300>;
+};
+
+&x22_clk {
+ clock-frequency = <3300>;
+};
+
+&programmable_clk1 {
+ clock-frequency = <10800>;
};
&du {
@@ -191,6 +229,58 @@
remote-endpoint = <&adv7123_in>;
};
};
+ port at 1 {
+ endpoint {
+ remote-endpoint = <&rcar_dw_hdmi0_in>;
+ };
+ };
+ port at 2 {
+ endpoint {
+ remote-endpoint = <&rcar_dw_hdmi1_in>;
+ };
+ };
+ };
+};
+
+&hdmi0 {
+ status = "okay";
+
+ ports {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ port at 0 {
+ reg = <0>;
+ rcar_dw_hdmi0_in: endpoint {
+ remote-endpoint = <&du_out_hdmi0>;
+ };
+ };
+ port at 1 {
+ reg = <1>;
+ rcar_dw_hdmi0_out: endpoint {
+ remote-endpoint = <&hdmi0_con>;
+ };
+ };
+ };
+};
+
+&hdmi1 {
+ status = "okay";
+
+ ports {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ port at 0 {
+ reg = <0>;
+ rcar_dw_hdmi1_in: endpoint {
+ remote-endpoint = <&du_out_hdmi1>;
+ };
+ };
+ port at 1 {
+ reg = <1>;
+ rcar_dw_hdmi1_out: endpoint {
+ remote-endpoint = <&hdmi1_con>;
+ };
+ };
};
};
@@ -269,6 +359,11 @@
groups = "usb2";
function = "usb2";
};
+
+ du_pins: du {
+ groups = "du_rgb888", "du_sync", "du_clk_out_0", "du_disp";
+ function = "du";
+ };
};
&scif1 {
--
2.7.4
[PATCH v2] PCI: create revision file in sysfs
On Fri, Nov 11, 2016 at 12:31:47AM +, Emil Velikov wrote: > On 10 November 2016 at 23:59, Bjorn Helgaas wrote: > > Hi Emil, > > > > On Thu, Nov 10, 2016 at 01:14:35PM +, Emil Velikov wrote: > >> On 10 November 2016 at 07:13, Greg KH > >> wrote: > >> > On Wed, Nov 09, 2016 at 04:56:07PM +, Emil Velikov wrote: > >> >> From: Emil Velikov > >> >> > >> >> Currently the revision isn't available via sysfs/libudev thus if one > >> >> wants to know the value they need to read through the config file. > >> >> > >> >> This in itself wakes/powers up the device, causing unwanted delays. > >> >> > >> >> There are at least two userspace components which could make use the new > >> >> file - libpciaccess and libdrm. At the moment the former will wake up > >> >> _every_ PCI device for simple invocation of glxinfo [when using Mesa > >> >> 10.0+ drivers]. While the latter [in association with Mesa 13.0] can > >> >> lead to 2-3 second delays while starting firefox, thunderbird or > >> >> chromium. > > > > I agree, these unwanted delays are completely unacceptable. My > > question is whether we should fix them by exporting more information > > from the kernel, or by changing the way the userspace components work. > > > > It should not take anywhere near 2 seconds to wake up a PCI device. > > That makes me think there's a more serious problem than just a lack of > > caching for the revision field, e.g., maybe we're looking at far more > > PCI devices than we need to, or we're doing it many times to the same > > device, or ... > > > > If I understand correctly, the delay was bisected to > > https://cgit.freedesktop.org/mesa/mesa/commit/?id=be239326aa4f, which > > removed a bunch of code that looked up the vendor and device IDs, and > > replaced it with drmGetDevice(). And apparently drmGetDevice(), in > > this path: > > > > drmGetDevice > > drmProcessPciDevice > > drmParsePciDeviceInfo > > > > is a little more thorough in that it looks up the *revision* in > > addition to the vendor and device IDs. So we pay the cost for the > > revision even though in this instance we don't care about the revision > > at all. > > > Above all, apologies for all the "lovely" code that you had to go > through for these. > And yes, you've got it spot on. > > > drmParsePciDeviceInfo() currently reads the whole config header from > > sysfs (https://cgit.freedesktop.org/drm/libdrm/tree/xf86drm.c#n2949), > > but I think you're extending that to try the vendor, device, > > subsystem_vendor, subsystem_device, and (if present) revision sysfs > > files first (http://www.spinics.net/lists/dri-devel/msg122319.html). > > > Yes, making the revision file optional and "faking it" was my first > thought, esp. since we don't have any users of it (yet). > Although people are not too keen on it, so we'll likely opt for > revision-less API. > > > Bottom line, I guess I'm not super opposed to this, but I do feel like > > we're making a kernel change to cover up a userspace problem, and I > > think it would be better to push on that userspace problem a little > > more. > > > Yes, definitely we can beat some sense into userspace. Yet that > shouldn't be a deterrent for exposing the revision. Maybe. If we speed things up by extending this kernel ABI, there's much less incentive to optimize the userspace stuff. I feel a little bit like an enabler for undesirable userspace behavior :) > As hinted before the other prominent user libpciaccess wakes up probes > _every_ pci device. Is it really necessary to probe *every* PCI device? That doesn't sound like a scalable design. As you can tell, the argument that "we should add this kernel ABI to make suboptimal userspace algorithms go faster" doesn't feel very compelling to me. > Atm that library is used by Xorg, Spice, libvirt and a few others. > Amongst which are the Intel GL drivers (via libdrm_intel.so), [only] > when GLX_MESA_query_renderer is used. > > Or in other words - if Firefox/other GL app wants to use the > extension, they'll get similar delays. > We should look into that one as well, but it will be more picky to > address (read "slower to reach end users").
[PATCH RFC 00/12] tda998x updates
On Fri, Nov 11, 2016 at 05:10:09PM +0200, Jyri Sarha wrote: > On 11/08/16 14:24, Russell King - ARM Linux wrote: > > As no one responded to the previous round, I'm not spending soo much > > time writing up a description of these changes again. It's also been > > quite a long time, so I've forgotten all the details of the changes, > > so I'll do my best. > > > > Changes from the previous series include: > > - reorder the initial three patches > > - change the (now third patch)... I think to increase the size of the > > locked region. > > - fix edid parsing for infoframe generation - as was pointed out for > > dw-hdmi, parsing the EDID in get_modes() is incorrect, as that method > > will not be called when an override-edid is in effect. We need to > > parse the override-edid. Moreover, infoframe generation should not > > be keyed to whether the monitor is HDMI or not, CEA-861B allows non- > > HDMI to send infoframes. > > - only send audio if audio and infoframes are supported. > > > > Otherwise, these are very much like the previous posting of the series, > > except rebased upon the mali/hdlcd/tda998x change to remove the > > drm_connector_register() call. > > > > https://www.spinics.net/lists/dri-devel/msg121495.html > > > > It'd be nice to have other tda998x users ack and test these patches, > > I've tried to test on Juno, but the Juno situation seems to be a huge > > fail. (HBI0282B completely fails with latest firmware - (a) FPGA image > > incompatibilities io_b118 causes all FPGA AMBA devices to vanish, (b) > > seems no way to get SCPI support on it - adding the BL0 executable > > start address in the SCC registers seems to be incompatible with the > > devchip, causing the PLLs to fail. In discussion with Sudeep over > > these issues, but no idea where things are with it at the moment, other > > than Sudeep needs to investigate. All Linaro firmware releases are > > broken on HBI0282B.) > > > > drivers/gpu/drm/i2c/tda998x_drv.c | 826 > > -- > > 1 file changed, 429 insertions(+), 397 deletions(-) > > > > Reviewed-by: Jyri Sarha > > For the whole series. I am also happy to test these patches if I can > fetch them from some git repo. git://git.armlinux.org.uk/~rmk/linux-arm.git drm-tda998x-devel The commit IDs are unstable, because I'll have to recommit them to add your r-by and any other tags you later give me. :) Thanks. -- RMK's Patch system: http://www.armlinux.org.uk/developer/patches/ FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up according to speedtest.net.
[PATCH 03/10] drm: rcar-du: Add R8A7795 device support
From: Koji Matsuoka
Signed-off-by: Koji Matsuoka
---
drivers/gpu/drm/rcar-du/rcar_du_crtc.h | 4 +++-
drivers/gpu/drm/rcar-du/rcar_du_drv.c | 14 --
drivers/gpu/drm/rcar-du/rcar_du_drv.h | 2 ++
3 files changed, 17 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/rcar-du/rcar_du_crtc.h
b/drivers/gpu/drm/rcar-du/rcar_du_crtc.h
index 6f08b7e..459e539 100644
--- a/drivers/gpu/drm/rcar-du/rcar_du_crtc.h
+++ b/drivers/gpu/drm/rcar-du/rcar_du_crtc.h
@@ -1,7 +1,7 @@
/*
* rcar_du_crtc.h -- R-Car Display Unit CRTCs
*
- * Copyright (C) 2013-2014 Renesas Electronics Corporation
+ * Copyright (C) 2013-2015 Renesas Electronics Corporation
*
* Contact: Laurent Pinchart (laurent.pinchart at ideasonboard.com)
*
@@ -61,6 +61,8 @@ enum rcar_du_output {
RCAR_DU_OUTPUT_DPAD1,
RCAR_DU_OUTPUT_LVDS0,
RCAR_DU_OUTPUT_LVDS1,
+ RCAR_DU_OUTPUT_HDMI0,
+ RCAR_DU_OUTPUT_HDMI1,
RCAR_DU_OUTPUT_TCON,
RCAR_DU_OUTPUT_MAX,
};
diff --git a/drivers/gpu/drm/rcar-du/rcar_du_drv.c
b/drivers/gpu/drm/rcar-du/rcar_du_drv.c
index 73c971e..4d0ae8a 100644
--- a/drivers/gpu/drm/rcar-du/rcar_du_drv.c
+++ b/drivers/gpu/drm/rcar-du/rcar_du_drv.c
@@ -140,14 +140,24 @@ static const struct rcar_du_device_info
rcar_du_r8a7795_info = {
| RCAR_DU_FEATURE_VSP1_SOURCE,
.num_crtcs = 4,
.routes = {
- /* R8A7795 has one RGB output, one LVDS output and two
-* (currently unsupported) HDMI outputs.
+ /* R8A7795 has one RGB output, two HDMI outputs and one
+* LVDS output.
*/
[RCAR_DU_OUTPUT_DPAD0] = {
.possible_crtcs = BIT(3),
.encoder_type = DRM_MODE_ENCODER_NONE,
.port = 0,
},
+ [RCAR_DU_OUTPUT_HDMI0] = {
+ .possible_crtcs = BIT(1),
+ .encoder_type = RCAR_DU_ENCODER_HDMI,
+ .port = 1,
+ },
+ [RCAR_DU_OUTPUT_HDMI1] = {
+ .possible_crtcs = BIT(2),
+ .encoder_type = RCAR_DU_ENCODER_HDMI,
+ .port = 2,
+ },
[RCAR_DU_OUTPUT_LVDS0] = {
.possible_crtcs = BIT(0),
.encoder_type = DRM_MODE_ENCODER_LVDS,
diff --git a/drivers/gpu/drm/rcar-du/rcar_du_drv.h
b/drivers/gpu/drm/rcar-du/rcar_du_drv.h
index c843c31..c9db610 100644
--- a/drivers/gpu/drm/rcar-du/rcar_du_drv.h
+++ b/drivers/gpu/drm/rcar-du/rcar_du_drv.h
@@ -20,6 +20,7 @@
#include "rcar_du_crtc.h"
#include "rcar_du_group.h"
#include "rcar_du_vsp.h"
+#include "rcar_du_encoder.h"
struct clk;
struct device;
@@ -31,6 +32,7 @@ struct rcar_du_lvdsenc;
#define RCAR_DU_FEATURE_CRTC_IRQ_CLOCK (1 << 0)/* Per-CRTC IRQ and
clock */
#define RCAR_DU_FEATURE_EXT_CTRL_REGS (1 << 1)/* Has extended control
registers */
#define RCAR_DU_FEATURE_VSP1_SOURCE(1 << 2)/* Has inputs from VSP1
*/
+#define RCAR_DU_FEATURE_GEN3_REGS (1 << 3)/* Use Gen3 registers */
#define RCAR_DU_QUIRK_ALIGN_128B (1 << 0)/* Align pitches to 128
bytes */
#define RCAR_DU_QUIRK_LVDS_LANES (1 << 1)/* LVDS lanes 1 and 3
inverted */
--
2.7.4
[PATCH 04/10] drm: rcar-du: Add dw_hdmi driver startup
From: Koji Matsuoka
The HDMI driver in the R-Car Gen3 uses dw_hdmi driver.
Signed-off-by: Koji Matsuoka
[geert: Select DRM_DW_HDMI on non-r8a7795 to fix shmobile_defconfig build]
[uli: assume encoder hardware is described in the encoder node]
Signed-off-by: Ulrich Hecht
---
drivers/gpu/drm/rcar-du/Kconfig | 2 +
drivers/gpu/drm/rcar-du/rcar_du_encoder.c | 9 +-
drivers/gpu/drm/rcar-du/rcar_du_encoder.h | 6 +-
drivers/gpu/drm/rcar-du/rcar_du_hdmienc.c | 215 +++---
drivers/gpu/drm/rcar-du/rcar_du_kms.c | 6 +-
5 files changed, 218 insertions(+), 20 deletions(-)
diff --git a/drivers/gpu/drm/rcar-du/Kconfig b/drivers/gpu/drm/rcar-du/Kconfig
index 4c2fd05..5ee9011 100644
--- a/drivers/gpu/drm/rcar-du/Kconfig
+++ b/drivers/gpu/drm/rcar-du/Kconfig
@@ -14,6 +14,8 @@ config DRM_RCAR_DU
config DRM_RCAR_HDMI
bool "R-Car DU HDMI Encoder Support"
depends on DRM_RCAR_DU
+ depends on OF
+ select DRM_DW_HDMI
help
Enable support for external HDMI encoders.
diff --git a/drivers/gpu/drm/rcar-du/rcar_du_encoder.c
b/drivers/gpu/drm/rcar-du/rcar_du_encoder.c
index ab8645c..b374695 100644
--- a/drivers/gpu/drm/rcar-du/rcar_du_encoder.c
+++ b/drivers/gpu/drm/rcar-du/rcar_du_encoder.c
@@ -1,7 +1,7 @@
/*
* rcar_du_encoder.c -- R-Car Display Unit Encoder
*
- * Copyright (C) 2013-2014 Renesas Electronics Corporation
+ * Copyright (C) 2013-2015 Renesas Electronics Corporation
*
* Contact: Laurent Pinchart (laurent.pinchart at ideasonboard.com)
*
@@ -106,7 +106,8 @@ int rcar_du_encoder_init(struct rcar_du_device *rcdu,
enum rcar_du_encoder_type type,
enum rcar_du_output output,
struct device_node *enc_node,
-struct device_node *con_node)
+struct device_node *con_node,
+const char *device_name)
{
struct rcar_du_encoder *renc;
struct drm_encoder *encoder;
@@ -150,8 +151,12 @@ int rcar_du_encoder_init(struct rcar_du_device *rcdu,
break;
}
+ renc->device_name = device_name;
+
if (type == RCAR_DU_ENCODER_HDMI) {
ret = rcar_du_hdmienc_init(rcdu, renc, enc_node);
+ if (of_device_is_compatible(enc_node, "renesas,rcar-dw-hdmi"))
+ goto done;
if (ret < 0)
goto done;
} else {
diff --git a/drivers/gpu/drm/rcar-du/rcar_du_encoder.h
b/drivers/gpu/drm/rcar-du/rcar_du_encoder.h
index 7fc10a9..5d769d8 100644
--- a/drivers/gpu/drm/rcar-du/rcar_du_encoder.h
+++ b/drivers/gpu/drm/rcar-du/rcar_du_encoder.h
@@ -1,7 +1,7 @@
/*
* rcar_du_encoder.h -- R-Car Display Unit Encoder
*
- * Copyright (C) 2013-2014 Renesas Electronics Corporation
+ * Copyright (C) 2013-2015 Renesas Electronics Corporation
*
* Contact: Laurent Pinchart (laurent.pinchart at ideasonboard.com)
*
@@ -33,6 +33,7 @@ struct rcar_du_encoder {
enum rcar_du_output output;
struct rcar_du_hdmienc *hdmi;
struct rcar_du_lvdsenc *lvds;
+ const char *device_name;
};
#define to_rcar_encoder(e) \
@@ -52,6 +53,7 @@ int rcar_du_encoder_init(struct rcar_du_device *rcdu,
enum rcar_du_encoder_type type,
enum rcar_du_output output,
struct device_node *enc_node,
-struct device_node *con_node);
+struct device_node *con_node,
+const char *device_name);
#endif /* __RCAR_DU_ENCODER_H__ */
diff --git a/drivers/gpu/drm/rcar-du/rcar_du_hdmienc.c
b/drivers/gpu/drm/rcar-du/rcar_du_hdmienc.c
index e03004f..47bd7bc 100644
--- a/drivers/gpu/drm/rcar-du/rcar_du_hdmienc.c
+++ b/drivers/gpu/drm/rcar-du/rcar_du_hdmienc.c
@@ -1,7 +1,7 @@
/*
* R-Car Display Unit HDMI Encoder
*
- * Copyright (C) 2014 Renesas Electronics Corporation
+ * Copyright (C) 2014-2015 Renesas Electronics Corporation
*
* Contact: Laurent Pinchart (laurent.pinchart at ideasonboard.com)
*
@@ -13,10 +13,13 @@
#include
+#include
#include
#include
#include
+#include
+
#include "rcar_du_drv.h"
#include "rcar_du_encoder.h"
#include "rcar_du_hdmienc.h"
@@ -24,7 +27,9 @@
struct rcar_du_hdmienc {
struct rcar_du_encoder *renc;
+ struct device *dev;
bool enabled;
+ unsigned int index;
};
#define to_rcar_hdmienc(e) (to_rcar_encoder(e)->hdmi)
@@ -32,6 +37,10 @@ struct rcar_du_hdmienc {
static void rcar_du_hdmienc_disable(struct drm_encoder *encoder)
{
struct rcar_du_hdmienc *hdmienc = to_rcar_hdmienc(encoder);
+ const struct drm_bridge_funcs *bfuncs = encoder->bridge->funcs;
+
+ if ((bfuncs) && (bfuncs->post_disable))
+ bfuncs->post_disable(encoder->bridge);
if (hdmienc->renc->lvds)
rcar_du_lvdsenc_enable(hdmienc->renc->lvds, encoder->crtc,
[PATCH v6 3/9] drm/hisilicon/hibmc: Add support for frame buffer
å¨ 2016/11/11 2:30, Sean Paul åé:
> On Fri, Oct 28, 2016 at 3:27 AM, Rongrong Zou
> wrote:
>> Add support for fbdev and kms fb management.
>>
>> Signed-off-by: Rongrong Zou
>> ---
>> drivers/gpu/drm/hisilicon/hibmc/Makefile | 2 +-
>> drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_drv.c | 17 ++
>> drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_drv.h | 24 ++
>> drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_fbdev.c | 255
>> ++
>> drivers/gpu/drm/hisilicon/hibmc/hibmc_ttm.c | 66 ++
>> 5 files changed, 363 insertions(+), 1 deletion(-)
>> create mode 100644 drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_fbdev.c
>>
>> diff --git a/drivers/gpu/drm/hisilicon/hibmc/Makefile
>> b/drivers/gpu/drm/hisilicon/hibmc/Makefile
>> index d5c40b8..810a37e 100644
>> --- a/drivers/gpu/drm/hisilicon/hibmc/Makefile
>> +++ b/drivers/gpu/drm/hisilicon/hibmc/Makefile
>> @@ -1,5 +1,5 @@
>> ccflags-y := -Iinclude/drm
>> -hibmc-drm-y := hibmc_drm_drv.o hibmc_drm_power.o hibmc_ttm.o
>> +hibmc-drm-y := hibmc_drm_drv.o hibmc_drm_fbdev.o hibmc_drm_power.o
>> hibmc_ttm.o
>>
>> obj-$(CONFIG_DRM_HISI_HIBMC) +=hibmc-drm.o
>> #obj-y += hibmc-drm.o
>> diff --git a/drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_drv.c
>> b/drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_drv.c
>> index 81f4301..5ac7a7e 100644
>> --- a/drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_drv.c
>> +++ b/drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_drv.c
>> @@ -66,11 +66,23 @@ static void hibmc_disable_vblank(struct drm_device *dev,
>> unsigned int pipe)
>>
>> static int hibmc_pm_suspend(struct device *dev)
>> {
>> + struct pci_dev *pdev = to_pci_dev(dev);
>> + struct drm_device *drm_dev = pci_get_drvdata(pdev);
>> + struct hibmc_drm_device *hidev = drm_dev->dev_private;
>> +
>> + drm_fb_helper_set_suspend_unlocked(&hidev->fbdev->helper, 1);
>> +
>
> We have atomic helpers for suspend/resume now. Please use those.
drm_atomic_helper_suspend/resume()?
>
>> return 0;
>> }
>>
>> static int hibmc_pm_resume(struct device *dev)
>> {
>> + struct pci_dev *pdev = to_pci_dev(dev);
>> + struct drm_device *drm_dev = pci_get_drvdata(pdev);
>> + struct hibmc_drm_device *hidev = drm_dev->dev_private;
>> +
>> + drm_fb_helper_set_suspend_unlocked(&hidev->fbdev->helper, 0);
>> +
>> return 0;
>> }
>>
>> @@ -170,6 +182,7 @@ static int hibmc_unload(struct drm_device *dev)
>> {
>> struct hibmc_drm_device *hidev = dev->dev_private;
>>
>> + hibmc_fbdev_fini(hidev);
>> hibmc_mm_fini(hidev);
>> hibmc_hw_fini(hidev);
>> dev->dev_private = NULL;
>> @@ -195,6 +208,10 @@ static int hibmc_load(struct drm_device *dev, unsigned
>> long flags)
>> if (ret)
>> goto err;
>>
>> + ret = hibmc_fbdev_init(hidev);
>> + if (ret)
>> + goto err;
>> +
>> return 0;
>>
>> err:
>> diff --git a/drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_drv.h
>> b/drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_drv.h
>> index db8d80e..a40e9a7 100644
>> --- a/drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_drv.h
>> +++ b/drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_drv.h
>> @@ -20,9 +20,22 @@
>> #define HIBMC_DRM_DRV_H
>>
>> #include
>> +#include
>> #include
>> #include
>>
>> +struct hibmc_framebuffer {
>> + struct drm_framebuffer fb;
>> + struct drm_gem_object *obj;
>> + bool is_fbdev_fb;
>> +};
>> +
>> +struct hibmc_fbdev {
>> + struct drm_fb_helper helper;
>> + struct hibmc_framebuffer *fb;
>> + int size;
>> +};
>> +
>> struct hibmc_drm_device {
>> /* hw */
>> void __iomem *mmio;
>> @@ -41,9 +54,13 @@ struct hibmc_drm_device {
>> bool initialized;
>> } ttm;
>>
>> + /* fbdev */
>> + struct hibmc_fbdev *fbdev;
>> bool mm_inited;
>> };
>>
>> +#define to_hibmc_framebuffer(x) container_of(x, struct hibmc_framebuffer,
>> fb)
>> +
>> struct hibmc_bo {
>> struct ttm_buffer_object bo;
>> struct ttm_placement placement;
>> @@ -65,8 +82,15 @@ static inline struct hibmc_bo *gem_to_hibmc_bo(struct
>> drm_gem_object *gem)
>>
>> #define DRM_FILE_PAGE_OFFSET (0x1ULL >> PAGE_SHIFT)
>>
>> +int hibmc_fbdev_init(struct hibmc_drm_device *hidev);
>> +void hibmc_fbdev_fini(struct hibmc_drm_device *hidev);
>> +
>> int hibmc_gem_create(struct drm_device *dev, u32 size, bool iskernel,
>> struct drm_gem_object **obj);
>> +struct hibmc_framebuffer *
>> +hibmc_framebuffer_init(struct drm_device *dev,
>> + const struct drm_mode_fb_cmd2 *mode_cmd,
>> + struct drm_gem_object *obj);
>>
>> int hibmc_mm_init(struct hibmc_drm_device *hibmc);
>> void hibmc_mm_fini(struct hibmc_drm_device *hibmc);
>> diff --git a/drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_fbdev.c
>> b/drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_fbdev.c
>> new file mode 100644
>> in
[v17 2/2] drm/bridge: Add I2C based driver for ps8640 bridge
Hi Jitao, I couldn't locate the original mail, so posting on this thread instead. Some comments below. On 11/10/2016 10:09 PM, Enric Balletbo Serra wrote: > Hi Jitao, > > 2016-08-27 8:44 GMT+02:00 Jitao Shi : >> This patch adds drm_bridge driver for parade DSI to eDP bridge chip. >> >> Signed-off-by: Jitao Shi >> Reviewed-by: Daniel Kurtz >> --- >> Changes since v16: >> - Disable ps8640 DSI MCS Function. >> - Rename gpios name more clearly. >> - Tune the ps8640 power on sequence. >> >> Changes since v15: >> - Drop drm_connector_(un)register calls from parade ps8640. >>The main DRM driver mtk_drm_drv now calls >>drm_connector_register_all() after drm_dev_register() in the >>mtk_drm_bind() function. That function should iterate over all >>connectors and call drm_connector_register() for each of them. >>So, remove drm_connector_(un)register calls from parade ps8640. >> >> Changes since v14: >> - update copyright info. >> - change bridge_to_ps8640 and connector_to_ps8640 to inline function. >> - fix some coding style. >> - use sizeof as array counter. >> - use drm_get_edid when read edid. >> - add mutex when firmware updating. >> >> Changes since v13: >> - add const on data, ps8640_write_bytes(struct i2c_client *client, const u8 >> *data, u16 data_len) >> - fix PAGE2_SW_REST tyro. >> - move the buf[3] init to entrance of the function. >> >> Changes since v12: >> - fix hw_chip_id build warning >> >> Changes since v11: >> - Remove depends on I2C, add DRM depends >> - Reuse ps8640_write_bytes() in ps8640_write_byte() >> - Use timer check for polling like the routines in >> - Fix no drm_connector_unregister/drm_connector_cleanup when >> ps8640_bridge_attach fail >> - Check the ps8640 hardware id in ps8640_validate_firmware >> - Remove fw_version check >> - Move ps8640_validate_firmware before ps8640_enter_bl >> - Add ddc_i2c unregister when probe fail and ps8640_remove >> --- >> drivers/gpu/drm/bridge/Kconfig | 12 + >> drivers/gpu/drm/bridge/Makefile|1 + >> drivers/gpu/drm/bridge/parade-ps8640.c | 1077 >> >> 3 files changed, 1090 insertions(+) >> create mode 100644 drivers/gpu/drm/bridge/parade-ps8640.c >> >> diff --git a/drivers/gpu/drm/bridge/Kconfig b/drivers/gpu/drm/bridge/Kconfig >> index b590e67..c59d043 100644 >> --- a/drivers/gpu/drm/bridge/Kconfig >> +++ b/drivers/gpu/drm/bridge/Kconfig >> @@ -50,6 +50,18 @@ config DRM_PARADE_PS8622 >> ---help--- >> Parade eDP-LVDS bridge chip driver. >> >> +config DRM_PARADE_PS8640 >> + tristate "Parade PS8640 MIPI DSI to eDP Converter" >> + depends on DRM >> + depends on OF >> + select DRM_KMS_HELPER >> + select DRM_MIPI_DSI >> + select DRM_PANEL >> + ---help--- >> + Choose this option if you have PS8640 for display >> + The PS8640 is a high-performance and low-power >> + MIPI DSI to eDP converter >> + >> config DRM_SII902X >> tristate "Silicon Image sii902x RGB/HDMI bridge" >> depends on OF >> diff --git a/drivers/gpu/drm/bridge/Makefile >> b/drivers/gpu/drm/bridge/Makefile >> index efdb07e..3360537 100644 >> --- a/drivers/gpu/drm/bridge/Makefile >> +++ b/drivers/gpu/drm/bridge/Makefile >> @@ -5,6 +5,7 @@ obj-$(CONFIG_DRM_DW_HDMI) += dw-hdmi.o >> obj-$(CONFIG_DRM_DW_HDMI_AHB_AUDIO) += dw-hdmi-ahb-audio.o >> obj-$(CONFIG_DRM_NXP_PTN3460) += nxp-ptn3460.o >> obj-$(CONFIG_DRM_PARADE_PS8622) += parade-ps8622.o >> +obj-$(CONFIG_DRM_PARADE_PS8640) += parade-ps8640.o >> obj-$(CONFIG_DRM_SII902X) += sii902x.o >> obj-$(CONFIG_DRM_TOSHIBA_TC358767) += tc358767.o >> obj-$(CONFIG_DRM_ANALOGIX_DP) += analogix/ >> diff --git a/drivers/gpu/drm/bridge/parade-ps8640.c >> b/drivers/gpu/drm/bridge/parade-ps8640.c >> new file mode 100644 >> index 000..7d67431 >> --- /dev/null >> +++ b/drivers/gpu/drm/bridge/parade-ps8640.c >> @@ -0,0 +1,1077 @@ >> +/* >> + * Copyright (c) 2016 MediaTek Inc. >> + * >> + * This program is free software; you can redistribute it and/or modify >> + * it under the terms of the GNU General Public License version 2 as >> + * published by the Free Software Foundation. >> + * >> + * This program is distributed in the hope that it will be useful, >> + * but WITHOUT ANY WARRANTY; without even the implied warranty of >> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the >> + * GNU General Public License for more details. >> + */ >> + >> +#include >> +#include >> +#include >> +#include Not needed. >> +#include >> +#include >> +#include >> +#include >> +#include The above 2 aren't needed. >> +#include >> +#include >> +#include >> +#include >> + >> +#include >> +#include >> +#include >> +#include Not needed. >> +#include >> +#include >> + >> +#define PAGE1_VSTART 0x6b >> +#define PAGE2_SPI_CFG3 0x82 >> +#define I2C_TO_SPI_RESET 0x20 >> +#define PAGE2_ROMADD_BYTE1 0x8e >> +#define PAGE2
[PATCH] drm/i2c: tda998x: power down pre-filter and color conversion
Disabling the pre-filter block of the TDA998x saves 40mW and the colour
conversion block saves 15mW. As we always disable these two blocks, we
can power these sections of the chip down to save 55mW of unnecessary
power consumption.
Signed-off-by: Russell King
---
This is the next patch in my ongoing TDA998x work, which applies on top
of my previously sent series (and my drm-tda998x-devel branch.) Please
can folk with TDA998x test on their platforms that there has been no
apparent regression. Thanks.
drivers/gpu/drm/i2c/tda998x_drv.c | 4
1 file changed, 4 insertions(+)
diff --git a/drivers/gpu/drm/i2c/tda998x_drv.c
b/drivers/gpu/drm/i2c/tda998x_drv.c
index 3a5e5c466972..bf5eec0c1b4f 100644
--- a/drivers/gpu/drm/i2c/tda998x_drv.c
+++ b/drivers/gpu/drm/i2c/tda998x_drv.c
@@ -107,6 +107,8 @@ struct tda998x_priv {
# define I2C_MASTER_DIS_FILT (1 << 1)
# define I2C_MASTER_APP_STRT_LAT (1 << 2)
#define REG_FEAT_POWERDOWNREG(0x00, 0x0e) /* read/write */
+# define FEAT_POWERDOWN_PREFILT BIT(0)
+# define FEAT_POWERDOWN_CSC BIT(1)
# define FEAT_POWERDOWN_SPDIF (1 << 3)
#define REG_INT_FLAGS_0 REG(0x00, 0x0f) /* read/write */
#define REG_INT_FLAGS_1 REG(0x00, 0x10) /* read/write */
@@ -1284,6 +1286,7 @@ tda998x_encoder_mode_set(struct drm_encoder *encoder,
/* no pre-filter or interpolator: */
reg_write(priv, REG_HVF_CNTRL_0, HVF_CNTRL_0_PREFIL(0) |
HVF_CNTRL_0_INTPOL(0));
+ reg_set(priv, REG_FEAT_POWERDOWN, FEAT_POWERDOWN_PREFILT);
reg_write(priv, REG_VIP_CNTRL_5, VIP_CNTRL_5_SP_CNT(0));
reg_write(priv, REG_VIP_CNTRL_4, VIP_CNTRL_4_BLANKIT(0) |
VIP_CNTRL_4_BLC(0));
@@ -1306,6 +1309,7 @@ tda998x_encoder_mode_set(struct drm_encoder *encoder,
/* set color matrix bypass flag: */
reg_write(priv, REG_MAT_CONTRL, MAT_CONTRL_MAT_BP |
MAT_CONTRL_MAT_SC(1));
+ reg_set(priv, REG_FEAT_POWERDOWN, FEAT_POWERDOWN_CSC);
/* set BIAS tmds value: */
reg_write(priv, REG_ANA_GENERAL, 0x09);
--
2.7.4
[GIT PULL] drm/arcpgu: Accommodate adv7511 switch to DRM bridge
Hi Dave, Please pull that change for ARC PGU that fixes driver instantiation on AXS 10x boards. The patch was published for review here: https://lists.freedesktop.org/archives/dri-devel/2016-October/121245.html It is based on today's "drm-next" branch. Probably it's already too late for 4.9 but if there's a chance to squeeze it there it will be super nice because it's a fix for inevitable driver crash right on start. Best regards, Alexey The following changes since commit fa860a1751e388385a7f249dd3f24a6c76db0ba9: drm: Print device information again in debugfs (2016-10-17 16:20:53 +1000) are available in the git repository at: https://github.com/foss-for-synopsys-dwc-arc-processors/linux.git topic-arcpgu-fixes for you to fetch changes up to 7bc61cc5df808008b77a3b72cf814960c675518b: drm/arcpgu: Accommodate adv7511 switch to DRM bridge (2016-11-11 04:31:35 +0300) Eugeniy Paltsev (1): drm/arcpgu: Accommodate adv7511 switch to DRM bridge drivers/gpu/drm/arc/arcpgu_hdmi.c | 159 +--- 1 file changed, 17 insertions(+), 142 deletions(-)
[PATCH v2 1/5] ARM: memory: da8xx-ddrctl: new driver
On Wednesday 09 November 2016 11:54 PM, Rob Herring wrote: > On Mon, Oct 31, 2016 at 03:45:34PM +0100, Bartosz Golaszewski wrote: >> Create a new driver for the da8xx DDR2/mDDR controller and implement >> support for writing to the Peripheral Bus Burst Priority Register. >> >> Signed-off-by: Bartosz Golaszewski >> --- >> .../memory-controllers/ti-da8xx-ddrctl.txt | 20 +++ > > Acked-by: Rob Herring Applied to v4.10/drivers Thanks, Sekhar
[PATCH 05/10] drm: rcar-du: Add DPLL support
From: Koji Matsuoka
The workaround of DPLLCR2 register is required at the time of
H3(WS1.0) and H3(WS1.1). This patch adds procedure to apply
the workaround by revision.
Signed-off-by: Koji Matsuoka
[uli: replace PRR hack with soc_device_match()]
Signed-off-by: Ulrich Hecht
---
drivers/gpu/drm/rcar-du/rcar_du_crtc.c | 88 -
drivers/gpu/drm/rcar-du/rcar_du_crtc.h | 8 +++
drivers/gpu/drm/rcar-du/rcar_du_drv.c | 5 ++
drivers/gpu/drm/rcar-du/rcar_du_drv.h | 3 +-
drivers/gpu/drm/rcar-du/rcar_du_plane.h | 7 ++-
drivers/gpu/drm/rcar-du/rcar_du_regs.h | 21 +++-
6 files changed, 128 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/rcar-du/rcar_du_crtc.c
b/drivers/gpu/drm/rcar-du/rcar_du_crtc.c
index 7316fc7..85e3c53 100644
--- a/drivers/gpu/drm/rcar-du/rcar_du_crtc.c
+++ b/drivers/gpu/drm/rcar-du/rcar_du_crtc.c
@@ -13,6 +13,7 @@
#include
#include
+#include
#include
#include
@@ -106,14 +107,70 @@ static void rcar_du_crtc_put(struct rcar_du_crtc *rcrtc)
* Hardware Setup
*/
+static void rcar_du_dpll_divider(struct dpll_info *dpll, unsigned int extclk,
+unsigned int mode_clock)
+{
+ unsigned long dpllclk;
+ unsigned long diff;
+ unsigned long n, m, fdpll;
+ bool match_flag = false;
+ bool clk_diff_set = true;
+
+ for (n = 39; n < 120; n++) {
+ for (m = 0; m < 4; m++) {
+ for (fdpll = 1; fdpll < 32; fdpll++) {
+ /* 1/2 (FRQSEL=1) for duty rate 50% */
+ dpllclk = extclk * (n + 1) / (m + 1)
+/ (fdpll + 1) / 2;
+ if (dpllclk >= 4)
+ continue;
+
+ diff = abs((long)dpllclk - (long)mode_clock);
+ if (clk_diff_set ||
+ ((diff == 0) || (dpll->diff > diff))) {
+ dpll->diff = diff;
+ dpll->n = n;
+ dpll->m = m;
+ dpll->fdpll = fdpll;
+ dpll->dpllclk = dpllclk;
+
+ if (clk_diff_set)
+ clk_diff_set = false;
+
+ if (diff == 0) {
+ match_flag = true;
+ break;
+ }
+ }
+ }
+ if (match_flag)
+ break;
+ }
+ if (match_flag)
+ break;
+ }
+}
+
+static const struct soc_device_attribute r8a7795es1[] = {
+ { .soc_id = "r8a7795", .revision = "ES1.*" },
+ { /* sentinel */ }
+};
+
static void rcar_du_crtc_set_display_timing(struct rcar_du_crtc *rcrtc)
{
const struct drm_display_mode *mode = &rcrtc->crtc.state->adjusted_mode;
+ struct rcar_du_device *rcdu = rcrtc->group->dev;
unsigned long mode_clock = mode->clock * 1000;
unsigned long clk;
u32 value;
u32 escr;
u32 div;
+ u32 dpll_reg = 0;
+ struct dpll_info *dpll;
+
+ dpll = kzalloc(sizeof(*dpll), GFP_KERNEL);
+ if (dpll == NULL)
+ return;
/* Compute the clock divisor and select the internal or external dot
* clock based on the requested frequency.
@@ -130,6 +187,15 @@ static void rcar_du_crtc_set_display_timing(struct
rcar_du_crtc *rcrtc)
u32 extdiv;
extclk = clk_get_rate(rcrtc->extclock);
+
+ if (rcdu->info->dpll_ch & (0x01 << rcrtc->index)) {
+ rcar_du_dpll_divider(dpll, extclk, mode_clock);
+ extclk = dpll->dpllclk;
+ dev_dbg(rcrtc->group->dev->dev,
+ "dpllclk:%d, fdpll:%d, n:%d, m:%d, diff:%d\n",
+dpll->dpllclk, dpll->fdpll, dpll->n, dpll->m,
+dpll->diff);
+ }
extdiv = DIV_ROUND_CLOSEST(extclk, mode_clock);
extdiv = clamp(extdiv, 1U, 64U) - 1;
@@ -140,7 +206,27 @@ static void rcar_du_crtc_set_display_timing(struct
rcar_du_crtc *rcrtc)
abs((long)rate - (long)mode_clock)) {
dev_dbg(rcrtc->group->dev->dev,
"crtc%u: using external clock\n", rcrtc->index);
- escr = extdiv | ESCR_DCLKSEL_DCLKIN;
+ if (rcdu->info->dpll_ch & (0x01 << rcrtc->index)) {
+ escr = ESCR_DCLKSEL_DCLKIN | 0x01;
+ dpll_reg
[Intel-gfx] [PATCH 0/5] Handle Link Training Failure during modeset
In case of link training failure and requiring user space to set a lower mode, would full mode set address it? How do we make user mode select lower resolution? For example 4k at 60Hz monitor, and link training at 4 lane HBR2 fails and fallback to 4 lanes HBR, 4k at 60 is no longer doable. I would think preventing user mode from seeing 4K at 60Hz from the start is a easier and more robust solution and requiring user mode to have logic to decide how to fallback. -Original Message- From: Ville Syrjälä [mailto:ville.syrj...@linux.intel.com] Sent: Friday, November 11, 2016 11:44 AM To: Cheng, Tony Cc: Deucher, Alexander ; 'Jani Nikula' ; Manasi Navare ; dri-devel at lists.freedesktop.org; intel-gfx at lists.freedesktop.org; Wentland, Harry ; Peres, Martin Subject: Re: [Intel-gfx] [PATCH 0/5] Handle Link Training Failure during modeset On Fri, Nov 11, 2016 at 04:21:58PM +, Cheng, Tony wrote: > For HDMI, you can yank the cable, plug back in, HDMI will light up without > user mode or kernel mode doing anything. > > For DP this is not possible, someone will have to retrain the link when > plugging back in or DP will not light up. We see that on Ubuntu if someone > unplug display and plug it back into same connector, we do not get KMS so in > this case. It appears there is some optimizations somewhere in user mode > stack which I am not familiar with yet. dal added workaround to retrain the > link to light it back up (after the test training at end of detection). The link should get retrained as the driver should check the link state on HPD and retrain if it's not good. At least that's what we do in i915. Of course if it's not the same display that got plugged back, the retraining might fail. The new property can help with that case as userspace would then attempt a full modeset after the failed link training. > > >From user mode perspective I think it make sense to keep CRTC running, so > >vblank is still going so UMD isn't impacted. As regard to connector and > >encoder does it matter if kernel mode change state without user mode > >knowing? It seems to me those are more informational to UMD as UMD doesn't > >act on them. > > windows does not know link state and all link management is hidden behind > kernel driver. If the user visible state doesn't change in any way, then the kernel could try to manage it all internally. > > -Original Message- > From: Ville Syrjälä [mailto:ville.syrjala at linux.intel.com] > Sent: Friday, November 11, 2016 9:05 AM > To: Cheng, Tony > Cc: Deucher, Alexander ; 'Jani Nikula' > ; Manasi Navare > ; dri-devel at lists.freedesktop.org; > intel-gfx at lists.freedesktop.org; Wentland, Harry > ; Peres, Martin > Subject: Re: [Intel-gfx] [PATCH 0/5] Handle Link Training Failure > during modeset > > On Thu, Nov 10, 2016 at 06:51:40PM +, Cheng, Tony wrote: > > Amdgpu dal implementation will do a test link training at end of detection > > to verify we can achieve the capability reported in DPCD. We then report > > mode base on result of test training. > > > > AMD hardware (at least the generations supported by amdgpu) is able to link > > train without timing being setup (DP encoder and CRTC is decoupled). Do we > > have limitation from other vendors where you need timing to be there before > > you can link train? > > I can't recall the specifics for all of our supported platforms, but at least > I have the recollection that it would be the case yes. > > The other problem wiyh this apporach is that even if you don't need the crtc, > you still need the link itself. What happens if the link is still active > since userspace just didn't bother to shut it down when the cable was yanked? > Can you keep the crtc going but stop it from feeding the link in a way that > userspace won't be able to notice? The kms design has always been pretty much > that policy is in userspace, and thus the kernel shouldn't shut down crtcs > unless explicitly asked to do so. > > > > > We can also past DP1.2 link layer compliance with this approach. > > > > -Original Message- > > From: Deucher, Alexander > > Sent: Thursday, November 10, 2016 1:43 PM > > To: 'Jani Nikula' ; Manasi Navare > > ; dri-devel at lists.freedesktop.org; > > intel-gfx at lists.freedesktop.org; Wentland, Harry > > ; Cheng, Tony > > Cc: Dave Airlie ; Peres, Martin > > > > Subject: RE: [Intel-gfx] [PATCH 0/5] Handle Link Training Failure > > during modeset > > > > Adding Harry and Tony from our display team to review. > > > > > -Original Message- > > > From: Jani Nikula [mailto:jani.nikula at linux.intel.com] > > > Sent: Thursday, November 10, 2016 1:20 PM > > > To: Manasi Navare; dri-devel at lists.freedesktop.org; intel- > > > gfx at lists.freedesktop.org > > > Cc: Dave Airlie; Peres, Martin; Deucher, Alexander > > > Subject: Re: [Intel-gfx] [PATCH 0/5] Handle Link Training Failure > > > during modeset > > > > > > On Th
[GIT PULL] mediatek-drm: fix a typo, vblank interrupt disable, and HDMI 4K support.
Hi, Dave: This branch include one patch to fix a typo, two patches to disable vblank interrupt, and three patches to support HDMI 4K resolution. Regards, CK The following changes since commit 1001354ca34179f3db924eb66672442a173147dc: Linux 4.9-rc1 (2016-10-15 12:17:50 -0700) are available in the git repository at: https://github.com/ckhu-mediatek/linux.git-tags.git mediatek-drm-fixes-2016-11-11 for you to fetch changes up to 0d2200794f0a2c1ebb3b6613842914d8ce4b67f9: drm/mediatek: modify the factor to make the pll_rate set in the 1G-2G range (2016-10-19 09:07:08 +0800) Bibby Hsieh (3): drm/mediatek: fix a typo of OD_CFG to OD_RELAYMODE drm/mediatek: set vblank_disable_allowed to true drm/mediatek: clear IRQ status before enable OVL interrupt Junzhi Zhao (3): drm/mediatek: do mtk_hdmi_send_infoframe after HDMI clock enable drm/mediatek: enhance the HDMI driving current drm/mediatek: modify the factor to make the pll_rate set in the 1G-2G range drivers/gpu/drm/mediatek/mtk_disp_ovl.c| 1 + drivers/gpu/drm/mediatek/mtk_dpi.c | 9 -- drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.c| 2 +- drivers/gpu/drm/mediatek/mtk_drm_drv.c | 1 + drivers/gpu/drm/mediatek/mtk_hdmi.c| 17 +++ drivers/gpu/drm/mediatek/mtk_mt8173_hdmi_phy.c | 42 ++ 6 files changed, 51 insertions(+), 21 deletions(-)
