[Intel-gfx] [PATCH 2/3] drm/vma_manage: Drop has_offset
Hi Daniel,
[auto build test ERROR on drm/drm-next -- if it's inappropriate base, please
suggest rules for selecting the more suitable base]
url:
https://github.com/0day-ci/linux/commits/Daniel-Vetter/drm-Update-GEM-refcounting-docs/20151023-011317
config: i386-randconfig-s1-201542 (attached as .config)
reproduce:
# save the attached .config to linux build tree
make ARCH=i386
All errors (new ones prefixed by >>):
drivers/gpu/drm/vgem/vgem_drv.c: In function 'vgem_gem_dumb_map':
>> drivers/gpu/drm/vgem/vgem_drv.c:211:7: error: implicit declaration of
>> function 'drm_vma_node_has_offset' [-Werror=implicit-function-declaration]
if (!drm_vma_node_has_offset(&obj->vma_node)) {
^
cc1: some warnings being treated as errors
vim +/drm_vma_node_has_offset +211 drivers/gpu/drm/vgem/vgem_drv.c
502e95c6 Zach Reizner 2015-03-04 205 obj = drm_gem_object_lookup(dev, file,
handle);
502e95c6 Zach Reizner 2015-03-04 206 if (!obj) {
502e95c6 Zach Reizner 2015-03-04 207 ret = -ENOENT;
502e95c6 Zach Reizner 2015-03-04 208 goto unlock;
502e95c6 Zach Reizner 2015-03-04 209 }
502e95c6 Zach Reizner 2015-03-04 210
502e95c6 Zach Reizner 2015-03-04 @211 if
(!drm_vma_node_has_offset(&obj->vma_node)) {
502e95c6 Zach Reizner 2015-03-04 212 ret =
drm_gem_create_mmap_offset(obj);
502e95c6 Zach Reizner 2015-03-04 213 if (ret)
502e95c6 Zach Reizner 2015-03-04 214 goto unref;
:: The code at line 211 was first introduced by commit
:: 502e95c6678505474f1056480310cd9382bacbac drm/vgem: implement virtual GEM
:: TO: Zach Reizner
:: CC: Dave Airlie
---
0-DAY kernel test infrastructureOpen Source Technology Center
https://lists.01.org/pipermail/kbuild-all Intel Corporation
-- next part --
A non-text attachment was scrubbed...
Name: .config.gz
Type: application/octet-stream
Size: 23181 bytes
Desc: not available
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20151023/4baa9e4f/attachment-0001.obj>
[Intel-gfx] [PATCH 2/3] drm/vma_manage: Drop has_offset
Hi Daniel,
[auto build test WARNING on drm/drm-next -- if it's inappropriate base, please
suggest rules for selecting the more suitable base]
url:
https://github.com/0day-ci/linux/commits/Daniel-Vetter/drm-Update-GEM-refcounting-docs/20151023-011317
config: x86_64-randconfig-s1-10230205 (attached as .config)
reproduce:
# save the attached .config to linux build tree
make ARCH=x86_64
All warnings (new ones prefixed by >>):
In file included from include/uapi/linux/stddef.h:1:0,
from include/linux/stddef.h:4,
from include/uapi/linux/posix_types.h:4,
from include/uapi/linux/types.h:13,
from include/linux/types.h:5,
from include/linux/list.h:4,
from include/linux/module.h:9,
from drivers/gpu/drm/vgem/vgem_drv.c:33:
drivers/gpu/drm/vgem/vgem_drv.c: In function 'vgem_gem_dumb_map':
drivers/gpu/drm/vgem/vgem_drv.c:211:7: error: implicit declaration of
function 'drm_vma_node_has_offset' [-Werror=implicit-function-declaration]
if (!drm_vma_node_has_offset(&obj->vma_node)) {
^
include/linux/compiler.h:147:28: note: in definition of macro '__trace_if'
if (__builtin_constant_p((cond)) ? !!(cond) : \
^
>> drivers/gpu/drm/vgem/vgem_drv.c:211:2: note: in expansion of macro 'if'
if (!drm_vma_node_has_offset(&obj->vma_node)) {
^
cc1: some warnings being treated as errors
vim +/if +211 drivers/gpu/drm/vgem/vgem_drv.c
502e95c6 Zach Reizner 2015-03-04 27
502e95c6 Zach Reizner 2015-03-04 28 /**
502e95c6 Zach Reizner 2015-03-04 29 * This is vgem, a
(non-hardware-backed) GEM service. This is used by Mesa's
502e95c6 Zach Reizner 2015-03-04 30 * software renderer and the X
server for efficient buffer sharing.
502e95c6 Zach Reizner 2015-03-04 31 */
502e95c6 Zach Reizner 2015-03-04 32
502e95c6 Zach Reizner 2015-03-04 @33 #include
502e95c6 Zach Reizner 2015-03-04 34 #include
502e95c6 Zach Reizner 2015-03-04 35 #include
502e95c6 Zach Reizner 2015-03-04 36 #include
502e95c6 Zach Reizner 2015-03-04 37 #include "vgem_drv.h"
502e95c6 Zach Reizner 2015-03-04 38
502e95c6 Zach Reizner 2015-03-04 39 #define DRIVER_NAME"vgem"
502e95c6 Zach Reizner 2015-03-04 40 #define DRIVER_DESC
"Virtual GEM provider"
502e95c6 Zach Reizner 2015-03-04 41 #define DRIVER_DATE
"20120112"
502e95c6 Zach Reizner 2015-03-04 42 #define DRIVER_MAJOR 1
502e95c6 Zach Reizner 2015-03-04 43 #define DRIVER_MINOR 0
502e95c6 Zach Reizner 2015-03-04 44
502e95c6 Zach Reizner 2015-03-04 45 void vgem_gem_put_pages(struct
drm_vgem_gem_object *obj)
502e95c6 Zach Reizner 2015-03-04 46 {
502e95c6 Zach Reizner 2015-03-04 47 drm_gem_put_pages(&obj->base,
obj->pages, false, false);
502e95c6 Zach Reizner 2015-03-04 48 obj->pages = NULL;
502e95c6 Zach Reizner 2015-03-04 49 }
502e95c6 Zach Reizner 2015-03-04 50
502e95c6 Zach Reizner 2015-03-04 51 static void
vgem_gem_free_object(struct drm_gem_object *obj)
502e95c6 Zach Reizner 2015-03-04 52 {
502e95c6 Zach Reizner 2015-03-04 53 struct drm_vgem_gem_object
*vgem_obj = to_vgem_bo(obj);
502e95c6 Zach Reizner 2015-03-04 54
502e95c6 Zach Reizner 2015-03-04 55 drm_gem_free_mmap_offset(obj);
502e95c6 Zach Reizner 2015-03-04 56
502e95c6 Zach Reizner 2015-03-04 57 if (vgem_obj->use_dma_buf &&
obj->dma_buf) {
502e95c6 Zach Reizner 2015-03-04 58
dma_buf_put(obj->dma_buf);
502e95c6 Zach Reizner 2015-03-04 59 obj->dma_buf = NULL;
502e95c6 Zach Reizner 2015-03-04 60 }
502e95c6 Zach Reizner 2015-03-04 61
502e95c6 Zach Reizner 2015-03-04 62 drm_gem_object_release(obj);
502e95c6 Zach Reizner 2015-03-04 63
502e95c6 Zach Reizner 2015-03-04 64 if (vgem_obj->pages)
502e95c6 Zach Reizner 2015-03-04 65
vgem_gem_put_pages(vgem_obj);
502e95c6 Zach Reizner 2015-03-04 66
502e95c6 Zach Reizner 2015-03-04 67 vgem_obj->pages = NULL;
502e95c6 Zach Reizner 2015-03-04 68
502e95c6 Zach Reizner 2015-03-04 69 kfree(vgem_obj);
502e95c6 Zach Reizner 2015-03-04 70 }
502e95c6 Zach Reizner 2015-03-04 71
502e95c6 Zach Reizner 2015-03-04 72 int vgem_gem_get_pages(struct
drm_vgem_gem_object *obj)
502e95c6 Zach Reizner 2015-03-04 73 {
502e95c6 Zach Reizner 2015-03-04 74 struct page **pages;
502e95c6 Zach Reizner 2015-03-04
[GIT PULL] Raspberry Pi KMS driver
On 23 October 2015 at 05:58, Daniel Vetter wrote: > On Thu, Oct 22, 2015 at 12:40:23PM -0500, Rob Herring wrote: >> On Wed, Oct 21, 2015 at 4:53 AM, Eric Anholt wrote: >> > Dave suggested it was time to just send a pull request on the driver, so >> > here goes: >> >> Why is that when the binding is still under discussion[1]? Even the >> agreed changes never got reposted. > > Bit a longer story, so here we go: I don't really like drivers/staging > since it's a cage where drivers get forgotten about, and even if there is > activity it's completely separate from all the other drm drivers. Which > doesn't help with collaboration, which is the entire point really of > upstreaming. > > Otoh I really like how drivers/staging allows not-quite-ready drivers to > get in and get more visibility. So for drm I think the right approach is > to just merge drivers which are reasonable close to good enough, and fix > up anything erregrious once merged. This might be special for drm, since > gpus change ridiculously fast, resulting in anyone contributing for more > than 2-3 years to be constantly busy cleaning up past code that turned out > a mistake in light of todays hardware. I think that means overall drm has > a lower bar to entry and much higher acceptance for crap. And there's lots > of it. Could very well be that most of the drm subsystem should be in > drivers/staging by everyone else's standard. > > For this specific case here of the rpi driver the only ongoing thing was > the dt binding discussion, and it didn't look like it would reach closure > anytime soon. On top of that this driver is for rpi specifically (vc5 will > require a completely new driver for a bunch of reasons), and on those > boards the boot loader will never ship a dt file, it will always come from > the kernel. Which means it's really just an internal interface and there's > zero concerns about compatibility. Yes besides the binding everything was ready, the drm API was more likely to go stale and cause regressions/problems than fixing up what is at least in this case going to be an in-tree interface, since there are thousands of these boards in existance. I'm also travelling next week and I'd rather not be pulling trees into drm-next too much. The dt discussion can still go on, and we can merge the changes, before, during after the merge window. Dave.
[PATCH drm 4/6] drm: add drm_gem_prime_page_flip() helper
On Thu, Oct 22, 2015 at 11:31 PM, Alexander Goins wrote: >>This looks really strange - you force-complete the fence already attached >>(which might be from any driver attached to this dma-buf)? >>The creator of the fence is supposed to complete it when whatever async >>operation that is scheduled and which is using this dma-buf is done. So the >>way to go about this here is to take out the excl fence from the reservation >>object, and wait for it to complete. > > Yeah, true. I had just added that as a contingency - in reality this ioctl is > never called (by my changes) on a buffer with an unsignaled fence. You're > right that a wait would be better. I'll have it changed the revised patch set > if we end up keeping the ioctl. It's not just that you should wait on the fence, there's no reason for a page_flip to attach an exclusive fence at all - display block at most reads from the buffer, we don't need to block anyone from reading (e.g. to do a front->back copy before rendering the next frame). >>But if your goal is to only fix up the page_flip path, and only for i915 as >>the display driver > > I'd be fine with the atomic modesetting path if i915 supported async atomic > updates; really I just need a way to fence flips between two shared buffers. > While i915 is the main target, we'd ideally like to support this with other > devices/drivers as well. Every other driver supporting dma-buf import of foreign objects should just do the same. The only case you care about is probably tegra. Note that atomic helpers already are prepared for both implicit and explicit fences, there's plane_state->fence which they wait to complete on. The idea is to fill this out in your plane->prepare_fb hook. >>For your limited use-case it really would be simplest to fix up the i915 mmio >>flip code to handle fences attached to dma-bufs, and teach the nvidia blob to >>attach a suitable exclusive fence somehow. > > This sounds like a pretty good solution - as long as the semantics stay the > same as to who attaches the fence, transitioning from this to an atomic > modesetting solution could be relatively painless. I'd need a way to query if > a driver supports fencing on page_flip and/or async atomic modesetting in > order to get graceful fallback on X. Feature flags for kernel bugs are kinda not something I like all that much. If you _really_ want it, we'll just backport the minimal fix and that's it. Otherwise I gues carry a list of drivers/kernels that work/dont in your X driver. >>Wrt merge coordination: RSN (well that's the case since months) all the >>legacy pageflip code will be ripped out from i915 and replaced by async >>atomic updates). So except for a proof-of-concept I'd prefer if we just >>implement this in the atomic codepaths directly. > > What kind of timeline are we looking at for i915 supporting async atomic > updates? Will the legacy pageflip code be ripped out at the same time, or > will there be a transition period? With the ability to query for fenced > page_flip / fenced async atomic modesetting, I can probably get X to use the > best available method. I should be able to test a fenced async atomic update > implementation using dGPU + Tegra PRIME prior to i915 supporting it, but I'd > be interested to hear from those more well versed on that path as to how > they'd like it implemented. Legacy flip code will be ripped out as soon as async atomic works, and implemented using atomic modeset code using the usual helpers. But since it's a giantic task I don't want to add more features to the legacy flip code, that'll only make it slower to get to the goal. At least if you don't also implement the atomic side. So two patches: 1. for the mmio_flip code, which we could also maybe backport. 2. for the new atomic code, for future-proofing. Both should be really minimal patches. Cheers, Daniel -- Daniel Vetter Software Engineer, Intel Corporation +41 (0) 79 365 57 48 - http://blog.ffwll.ch
[PATCH 2/8] ASoC : dwc : add different playback/capture base
On Thu, Oct 08, 2015 at 12:12:35PM -0400, Alex Deucher wrote: > From: Maruthi Srinivas Bayyavarapu > > Some platforms (Ex: AMD CZ) can have separate dwc controllers with > different base address for playback and capture. This patch adds > necessary changes to support it. Platforms which make use of it can > supply a quirk in platform data to make use of this. By default, > playback and capture base addesses are assumed to be same. If these are two physically separate controllers that don't share anything then why are they being represented as a single device as opposed to just having two devices, one for playback and one for capture? You'd still need to register the DAI differently but it should be a much less invasive change and map much more naturally onto the device model (what if some system has put playback and capture into separate power domains for example?). If we do go with this then we will also need an update to the DT binding to document how the additional resources associated with the second controller are described. -- next part -- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 473 bytes Desc: not available URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20151023/430d83d2/attachment.sig>
[PATCH 6/8] drm/amd: add ACP driver support
On Thu, Oct 08, 2015 at 12:12:39PM -0400, Alex Deucher wrote: > +config DRM_AMD_ACP > + bool "Enable ACP IP support" > + default y > + depends on MFD_CORE > + help > + Choose this option to enable ACP IP support for AMD SOCs. Why does this depend on rather than select MFD_CORE (as all other users do)? Since MFD_CORE has no help text and hence is not directly user selectable the above means the user won't be able to enable this driver unless they happen to enable something else which uses MFD which doesn't seem ideal. -- next part -- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 473 bytes Desc: not available URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20151023/2b08108f/attachment.sig>
[PATCH 8/8] ASoC: AMD: add AMD ASoC ACP-I2S driver
gt; + mmACP_AXI2DAGB_GARLIC_CNTL);
The comments don't match the code...
> +/* Update DMA postion in audio ring buffer at period level granularity.
> + * This will be used by ALSA PCM driver
> + */
> +u32 acp_update_dma_pointer(void __iomem *acp_mmio, int direction,
> + u32 period_size)
> +{
> + u32 pos;
> + u16 dscr;
> + u32 mul;
> + u32 dma_config;
> +
> + pos = 0;
> +
> + if (direction == SNDRV_PCM_STREAM_PLAYBACK) {
> + dscr = acp_reg_read(acp_mmio, mmACP_DMA_CUR_DSCR_13);
> +
> + mul = (dscr == PLAYBACK_START_DMA_DESCR_CH13) ? 0 : 1;
> + pos = (mul * period_size);
Don't limit the accuracy to period level if the harwdare can do better,
report the current position as accurately as possible please. This is
also feeling like we've got an unneeded abstraction here - why was this
not just directly the pointer operation?
> +/* Wait for initial buffering to complete in HOST to SRAM DMA channel
> + * for plaback usecase
> + */
> +void prebuffer_audio(void __iomem *acp_mmio)
> +{
> + u32 dma_ch_sts;
> + u32 channel_mask = BIT(SYSRAM_TO_ACP_CH_NUM);
> +
> + do {
> + /* Read the channel status to poll dma transfer completion
> + * (System RAM to SRAM)
> + * In this case, it will be runtime->start_threshold
> + * (2 ALSA periods) of transfer. Rendering starts after this
> + * threshold is met.
> + */
> + dma_ch_sts = acp_reg_read(acp_mmio, mmACP_DMA_CH_STS);
> + udelay(20);
> + } while (dma_ch_sts & channel_mask);
This will hang hard if the hardware fails to respond for some reason,
please have a timeout. A cpu_relax() would also be friendly.
> +#define DISABLE 0
> +#define ENABLE 1
Please don't do this :(
> +#define STATUS_SUCCESS 0
> +#define STATUS_UNSUCCESSFUL -1
Please use normal Linux error codes.
-- next part --
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 473 bytes
Desc: not available
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20151023/a6917f9c/attachment.sig>
[PATCH 3/8] ASoC : dwc : add quirk for dwc controller instances
On Thu, Oct 08, 2015 at 12:12:36PM -0400, Alex Deucher wrote:
> From: Maruthi Srinivas Bayyavarapu
>
> Added a qurik to assign different base addresses for different
> dwc controllers present on platform for playback and capture.
I don't understand what the above means, sorry. Normally the address
ranges for devices are supplied via resources when the device is
registered.
> + if (dev->quirks & DW_I2S_QUIRK_MULTI_DWC) {
> + if (substream->stream == SNDRV_PCM_STREAM_PLAYBACK) {
> + i2s_write_reg(dev->i2s_pbase, CER, 0);
> + i2s_write_reg(dev->i2s_pbase, IER, 0);
> + } else {
> + i2s_write_reg(dev->i2s_cbase, CER, 0);
> + i2s_write_reg(dev->i2s_cbase, IER, 0);
> + }
This looks like it might be part of the previous change to merge
separate playback and capture instances of the controller into one
device rather than a separate change? But perhaps what this is saying
is also that the controller instances aren't actually totally separate
after all and the prior change maps well onto the hardware...
-- next part --
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 473 bytes
Desc: not available
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20151023/4a18b5ed/attachment.sig>
[Bug 92303] [radeonsi] Buffer sharing (with/without IOMMU) locks up GPU display with dGPU only
https://bugs.freedesktop.org/show_bug.cgi?id=92303 Shawn Starr changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |INVALID --- Comment #7 from Shawn Starr --- Disabled some kernel options, close this and reopen specific for AMD only. -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20151023/efe583ea/attachment-0001.html>
[GIT PULL] On-demand device probing
On Thu, Oct 22, 2015 at 04:02:13PM +0100, Russell King - ARM Linux wrote: > If it was such a problem, then in the _eight_ days that this has been > discussed so far, _someone_ would have sent some data showing the > problem. I think the fact is, there is no data. > Someone prove me wrong. Someone post the verifiable data showing that > there is a problem to be solved here. > Someone show what the specific failure cases are that are hampering > vendors moving forwards. Someone show the long boot times by way of > kernel message log. Someone show some evidence of the problems that > have been alluded to. > If no one can show some evidence, there isn't a problem here. :) Yeah, I'm not convinced the timing is *such* a big deal either - I do think that the log spam is a real problem but I think something much less invasive like the interface you proposed is good for addressing that. -- next part -- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 473 bytes Desc: not available URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20151023/e3085cff/attachment-0001.sig>
[Intel-gfx] [PATCH 2/2] drm/i915/skl: Add support for pipe background color
Hi Matt,
[auto build test WARNING on drm/drm-next -- if it's inappropriate base, please
suggest rules for selecting the more suitable base]
url:
https://github.com/0day-ci/linux/commits/Matt-Roper/CRTC-background-color-support-for-i915/20151023-082852
config: x86_64-randconfig-x005-10211812 (attached as .config)
reproduce:
# save the attached .config to linux build tree
make ARCH=x86_64
All warnings (new ones prefixed by >>):
drivers/gpu/drm/i915/i915_debugfs.c: In function 'i915_display_info':
>> drivers/gpu/drm/i915/i915_debugfs.c:2983:18: warning: format '%x' expects
>> argument of type 'unsigned int', but argument 3 has type 'uint64_t {aka long
>> long unsigned int}' [-Wformat=]
seq_printf(m, "\tbackground color (10bpc): r=%x g=%x b=%x\n",
^
>> drivers/gpu/drm/i915/i915_debugfs.c:2983:18: warning: too many arguments for
>> format [-Wformat-extra-args]
vim +2983 drivers/gpu/drm/i915/i915_debugfs.c
2967 crtc->base.base.id, pipe_name(crtc->pipe),
2968 yesno(pipe_config->base.active),
2969 pipe_config->pipe_src_w,
pipe_config->pipe_src_h);
2970 if (pipe_config->base.active) {
2971 intel_crtc_info(m, crtc);
2972
2973 active = cursor_position(dev, crtc->pipe, &x,
&y);
2974 seq_printf(m, "\tcursor visible? %s, position
(%d, %d), size %dx%d, addr 0x%08x, active? %s\n",
2975 yesno(crtc->cursor_base),
2976 x, y,
crtc->base.cursor->state->crtc_w,
2977 crtc->base.cursor->state->crtc_h,
2978 crtc->cursor_addr, yesno(active));
2979 }
2980 if (INTEL_INFO(dev)->gen >= 9 &&
pipe_config->base.active) {
2981 drm_rgba_t background =
pipe_config->base.background_color;
2982
> 2983 seq_printf(m, "\tbackground color (10bpc): r=%x
> g=%x b=%x\n",
2984 background.v,
2985 DRM_RGBA_REDBITS(background, 10),
2986 DRM_RGBA_GREENBITS(background, 10),
2987 DRM_RGBA_BLUEBITS(background, 10));
2988 }
2989
2990 seq_printf(m, "\tunderrun reporting: cpu=%s pch=%s \n",
2991 yesno(!crtc->cpu_fifo_underrun_disabled),
---
0-DAY kernel test infrastructureOpen Source Technology Center
https://lists.01.org/pipermail/kbuild-all Intel Corporation
-- next part ------
A non-text attachment was scrubbed...
Name: .config.gz
Type: application/octet-stream
Size: 24098 bytes
Desc: not available
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20151023/b8aba3cd/attachment-0001.obj>
[Intel-gfx] [PATCH 2/2] drm/i915/skl: Add support for pipe background color
Hi Matt,
[auto build test WARNING on drm/drm-next -- if it's inappropriate base, please
suggest rules for selecting the more suitable base]
url:
https://github.com/0day-ci/linux/commits/Matt-Roper/CRTC-background-color-support-for-i915/20151023-082852
config: x86_64-rhel (attached as .config)
reproduce:
# save the attached .config to linux build tree
make ARCH=x86_64
All warnings (new ones prefixed by >>):
drivers/gpu/drm/i915/i915_debugfs.c: In function 'i915_display_info':
>> drivers/gpu/drm/i915/i915_debugfs.c:2987:8: warning: format '%x' expects
>> argument of type 'unsigned int', but argument 3 has type 'uint64_t'
>> [-Wformat=]
DRM_RGBA_BLUEBITS(background, 10));
^
drivers/gpu/drm/i915/i915_debugfs.c:2987:8: warning: too many arguments for
format [-Wformat-extra-args]
vim +2987 drivers/gpu/drm/i915/i915_debugfs.c
2971 intel_crtc_info(m, crtc);
2972
2973 active = cursor_position(dev, crtc->pipe, &x,
&y);
2974 seq_printf(m, "\tcursor visible? %s, position
(%d, %d), size %dx%d, addr 0x%08x, active? %s\n",
2975 yesno(crtc->cursor_base),
2976 x, y,
crtc->base.cursor->state->crtc_w,
2977 crtc->base.cursor->state->crtc_h,
2978 crtc->cursor_addr, yesno(active));
2979 }
2980 if (INTEL_INFO(dev)->gen >= 9 &&
pipe_config->base.active) {
2981 drm_rgba_t background =
pipe_config->base.background_color;
2982
2983 seq_printf(m, "\tbackground color (10bpc): r=%x
g=%x b=%x\n",
2984 background.v,
2985 DRM_RGBA_REDBITS(background, 10),
2986 DRM_RGBA_GREENBITS(background, 10),
> 2987 DRM_RGBA_BLUEBITS(background, 10));
2988 }
2989
2990 seq_printf(m, "\tunderrun reporting: cpu=%s pch=%s \n",
2991 yesno(!crtc->cpu_fifo_underrun_disabled),
2992 yesno(!crtc->pch_fifo_underrun_disabled));
2993 }
2994
2995 seq_printf(m, "\n");
---
0-DAY kernel test infrastructureOpen Source Technology Center
https://lists.01.org/pipermail/kbuild-all Intel Corporation
-- next part --
A non-text attachment was scrubbed...
Name: .config.gz
Type: application/octet-stream
Size: 35271 bytes
Desc: not available
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20151023/e0e3dcfa/attachment-0001.obj>
[Intel-gfx] [PATCH 1/2] drm: Add infrastructure for CRTC background color property
Hi Matt, [auto build test WARNING on drm/drm-next -- if it's inappropriate base, please suggest rules for selecting the more suitable base] url: https://github.com/0day-ci/linux/commits/Matt-Roper/CRTC-background-color-support-for-i915/20151023-082852 reproduce: make htmldocs All warnings (new ones prefixed by >>): drivers/gpu/drm/i915/i915_irq.c:2582: warning: No description found for parameter 'wedged' drivers/gpu/drm/i915/i915_irq.c:2582: warning: No description found for parameter 'fmt' >> include/drm/drm_crtc.h:267: warning: cannot understand function prototype: >> 'typedef struct ' include/drm/drm_crtc.h:353: warning: No description found for parameter 'mode_blob' include/drm/drm_crtc.h:780: warning: No description found for parameter 'tile_blob_ptr' include/drm/drm_crtc.h:819: warning: No description found for parameter 'rotation' include/drm/drm_crtc.h:915: warning: No description found for parameter 'mutex' include/drm/drm_crtc.h:915: warning: No description found for parameter 'helper_private' include/drm/drm_crtc.h:1203: warning: No description found for parameter 'tile_idr' include/drm/drm_crtc.h:1203: warning: No description found for parameter 'delayed_event' include/drm/drm_crtc.h:1203: warning: No description found for parameter 'edid_property' include/drm/drm_crtc.h:1203: warning: No description found for parameter 'dpms_property' include/drm/drm_crtc.h:1203: warning: No description found for parameter 'path_property' include/drm/drm_crtc.h:1203: warning: No description found for parameter 'tile_property' include/drm/drm_crtc.h:1203: warning: No description found for parameter 'plane_type_property' include/drm/drm_crtc.h:1203: warning: No description found for parameter 'rotation_property' include/drm/drm_crtc.h:1203: warning: No description found for parameter 'prop_src_x' include/drm/drm_crtc.h:1203: warning: No description found for parameter 'prop_src_y' include/drm/drm_crtc.h:1203: warning: No description found for parameter 'prop_src_w' include/drm/drm_crtc.h:1203: warning: No description found for parameter 'prop_src_h' include/drm/drm_crtc.h:1203: warning: No description found for parameter 'prop_crtc_x' include/drm/drm_crtc.h:1203: warning: No description found for parameter 'prop_crtc_y' include/drm/drm_crtc.h:1203: warning: No description found for parameter 'prop_crtc_w' include/drm/drm_crtc.h:1203: warning: No description found for parameter 'prop_crtc_h' include/drm/drm_crtc.h:1203: warning: No description found for parameter 'prop_fb_id' include/drm/drm_crtc.h:1203: warning: No description found for parameter 'prop_crtc_id' include/drm/drm_crtc.h:1203: warning: No description found for parameter 'prop_active' include/drm/drm_crtc.h:1203: warning: No description found for parameter 'prop_mode_id' >> include/drm/drm_crtc.h:1203: warning: No description found for parameter >> 'prop_background_color' include/drm/drm_crtc.h:1203: warning: No description found for parameter 'dvi_i_subconnector_property' include/drm/drm_crtc.h:1203: warning: No description found for parameter 'dvi_i_select_subconnector_property' include/drm/drm_crtc.h:1203: warning: No description found for parameter 'tv_subconnector_property' include/drm/drm_crtc.h:1203: warning: No description found for parameter 'tv_select_subconnector_property' include/drm/drm_crtc.h:1203: warning: No description found for parameter 'tv_mode_property' include/drm/drm_crtc.h:1203: warning: No description found for parameter 'tv_left_margin_property' include/drm/drm_crtc.h:1203: warning: No description found for parameter 'tv_right_margin_property' include/drm/drm_crtc.h:1203: warning: No description found for parameter 'tv_top_margin_property' include/drm/drm_crtc.h:1203: warning: No description found for parameter 'tv_bottom_margin_property' include/drm/drm_crtc.h:1203: warning: No description found for parameter 'tv_brightness_property' include/drm/drm_crtc.h:1203: warning: No description found for parameter 'tv_contrast_property' include/drm/drm_crtc.h:1203: warning: No description found for parameter 'tv_flicker_reduction_property' include/drm/drm_crtc.h:1203: warning: No description found for parameter 'tv_overscan_property' include/drm/drm_crtc.h:1203: warning: No description found for parameter 'tv_saturation_property' include/drm/drm_crtc.h:1203: warning: No description found for paramete
[PATCH 2/3] drm/vma_manage: Drop has_offset
Hi
On Thu, Oct 22, 2015 at 7:11 PM, Daniel Vetter
wrote:
> It's racy, creating mmap offsets is a slowpath, so better to remove it
> to avoid drivers doing broken things.
>
> The only user is i915, and it's ok there because everything (well
> almost) is protected by dev->struct_mutex in i915-gem.
>
> While at it add a note in the create_mmap_offset kerneldoc that
> drivers must release it again. And then I also noticed that
> drm_gem_object_release entirely lacks kerneldoc.
>
> Cc: David Herrmann
> Signed-off-by: Daniel Vetter
I'd even argue that no driver should ever call into
drm_vma_offset_add() nor drm_vma_offset_remove(). For TTM this is
already the case, for plain old gem drivers still call
drm_vma_offset_add() (which is fine to me, but could be turned into a
gem helper).
Anyway, if TTM wasn't a module, we should drop the export of
drm_vma_offset_remove(), but that'll never happen, I guess.
Long story short: If anyone calls drm_vma_offset_remove() somewhere
but in the destructor, it's probably racy, so I fully support this
patch. The vma helpers are also made fail-safe on purpose, it has
never been a fast-path.
Reviewed-by: David Herrmann
Thanks
David
> ---
> drivers/gpu/drm/drm_gem.c | 17 +
> drivers/gpu/drm/i915/i915_gem.c | 3 ---
> include/drm/drm_vma_manager.h | 15 +--
> 3 files changed, 18 insertions(+), 17 deletions(-)
>
> diff --git a/drivers/gpu/drm/drm_gem.c b/drivers/gpu/drm/drm_gem.c
> index 64353d40db53..38680380c6b3 100644
> --- a/drivers/gpu/drm/drm_gem.c
> +++ b/drivers/gpu/drm/drm_gem.c
> @@ -387,6 +387,10 @@ EXPORT_SYMBOL(drm_gem_handle_create);
> * @obj: obj in question
> *
> * This routine frees fake offsets allocated by drm_gem_create_mmap_offset().
> + *
> + * Note that drm_gem_object_release() already calls this function, so drivers
> + * don't have to take care of releasing the mmap offset themselves when
> freeing
> + * the GEM object.
> */
> void
> drm_gem_free_mmap_offset(struct drm_gem_object *obj)
> @@ -410,6 +414,9 @@ EXPORT_SYMBOL(drm_gem_free_mmap_offset);
> * This routine allocates and attaches a fake offset for @obj, in cases where
> * the virtual size differs from the physical size (ie. obj->size).
> Otherwise
> * just use drm_gem_create_mmap_offset().
> + *
> + * This function is idempotent and handles an already allocated mmap offset
> + * transparently. Drivers do not need to check for this case.
> */
> int
> drm_gem_create_mmap_offset_size(struct drm_gem_object *obj, size_t size)
> @@ -431,6 +438,9 @@ EXPORT_SYMBOL(drm_gem_create_mmap_offset_size);
> * structures.
> *
> * This routine allocates and attaches a fake offset for @obj.
> + *
> + * Drivers can call drm_gem_free_mmap_offset() before freeing @obj to release
> + * the fake offset again.
> */
> int drm_gem_create_mmap_offset(struct drm_gem_object *obj)
> {
> @@ -739,6 +749,13 @@ drm_gem_release(struct drm_device *dev, struct drm_file
> *file_private)
> idr_destroy(&file_private->object_idr);
> }
>
> +/**
> + * drm_gem_object_release - release GEM buffer object resources
> + * @obj: GEM buffer object
> + *
> + * This releases any structures and resources used by @obj and is the invers
> of
> + * drm_gem_object_init().
> + */
> void
> drm_gem_object_release(struct drm_gem_object *obj)
> {
> diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
> index d0fa5481543c..01fef54ecb2d 100644
> --- a/drivers/gpu/drm/i915/i915_gem.c
> +++ b/drivers/gpu/drm/i915/i915_gem.c
> @@ -1972,9 +1972,6 @@ static int i915_gem_object_create_mmap_offset(struct
> drm_i915_gem_object *obj)
> struct drm_i915_private *dev_priv = obj->base.dev->dev_private;
> int ret;
>
> - if (drm_vma_node_has_offset(&obj->base.vma_node))
> - return 0;
> -
> dev_priv->mm.shrinker_no_lock_stealing = true;
>
> ret = drm_gem_create_mmap_offset(&obj->base);
> diff --git a/include/drm/drm_vma_manager.h b/include/drm/drm_vma_manager.h
> index 2f63dd5e05eb..06ea8e077ec2 100644
> --- a/include/drm/drm_vma_manager.h
> +++ b/include/drm/drm_vma_manager.h
> @@ -176,19 +176,6 @@ static inline unsigned long drm_vma_node_size(struct
> drm_vma_offset_node *node)
> }
>
> /**
> - * drm_vma_node_has_offset() - Check whether node is added to offset manager
> - * @node: Node to be checked
> - *
> - * RETURNS:
> - * true iff the node was previously allocated an offset and added to
> - * an vma offset manager.
> - */
> -static inline bool drm_vma_node_has_offset(struct drm_vma_offset_node *node)
> -{
> - return drm_mm_node_allocated(&node->vm_node);
> -}
> -
> -/**
> * drm_vma_node_offset_addr() - Return sanitized offset for user-space mmaps
> * @node: Linked offset node
> *
> @@ -220,7 +207,7 @@ static inline __u64 drm_vma_node_offset_addr(struct
> drm_vma_offset_node *node)
> static inline void drm_vma_node_unmap(struct drm_vma_offset_node *node,
>
[Bug 84717] DP MST: wrong device names in /sys/class/drm
https://bugs.freedesktop.org/show_bug.cgi?id=84717 Jani Nikula changed: What|Removed |Added CC|intel-gfx-bugs at lists.freede |dri-devel at lists.freedesktop |sktop.org |.org Component|DRM/Intel |DRM/other Assignee|intel-gfx-bugs at lists.freede |airlied at freedesktop.org |sktop.org | QA Contact|intel-gfx-bugs at lists.freede | |sktop.org | -- You are receiving this mail because: You are on the CC list for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20151023/d1a3f1ff/attachment.html>
[PATCH 2/6] drm/vc4: fix platform_no_drv_owner.cocci warnings
From: Julia Lawall
drivers/gpu/drm/vc4/vc4_drv.c:248:3-8: No need to set .owner here. The core
will do it.
Remove .owner field if calls are used which set it automatically
Generated by: scripts/coccinelle/api/platform_no_drv_owner.cocci
Signed-off-by: Fengguang Wu
Signed-off-by: Julia Lawall
Signed-off-by: Eric Anholt
---
drivers/gpu/drm/vc4/vc4_drv.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/drivers/gpu/drm/vc4/vc4_drv.c b/drivers/gpu/drm/vc4/vc4_drv.c
index 6e73060..d5db9e0 100644
--- a/drivers/gpu/drm/vc4/vc4_drv.c
+++ b/drivers/gpu/drm/vc4/vc4_drv.c
@@ -259,7 +259,6 @@ static struct platform_driver vc4_platform_driver = {
.remove = vc4_platform_drm_remove,
.driver = {
.name = "vc4-drm",
- .owner = THIS_MODULE,
.of_match_table = vc4_of_match,
},
};
--
2.6.1
[PATCH 4/6] drm/vc4: Fix some failure to track __iomem decorations on pointers.
Caught by the kbuild test robot.
Signed-off-by: Eric Anholt
---
drivers/gpu/drm/vc4/vc4_crtc.c | 3 ++-
drivers/gpu/drm/vc4/vc4_hvs.c | 8
2 files changed, 6 insertions(+), 5 deletions(-)
diff --git a/drivers/gpu/drm/vc4/vc4_crtc.c b/drivers/gpu/drm/vc4/vc4_crtc.c
index a3a77dd..32c0348 100644
--- a/drivers/gpu/drm/vc4/vc4_crtc.c
+++ b/drivers/gpu/drm/vc4/vc4_crtc.c
@@ -401,7 +401,8 @@ static void vc4_crtc_atomic_flush(struct drm_crtc *crtc,
dlist_next++;
HVS_WRITE(SCALER_DISPLISTX(vc4_crtc->channel),
- (u32 *)vc4_crtc->dlist - (u32 *)vc4->hvs->dlist);
+ (u32 __iomem *)vc4_crtc->dlist -
+ (u32 __iomem *)vc4->hvs->dlist);
/* Make the next display list start after ours. */
vc4_crtc->dlist_size -= (dlist_next - vc4_crtc->dlist);
diff --git a/drivers/gpu/drm/vc4/vc4_hvs.c b/drivers/gpu/drm/vc4/vc4_hvs.c
index ab1673f..4d81d43 100644
--- a/drivers/gpu/drm/vc4/vc4_hvs.c
+++ b/drivers/gpu/drm/vc4/vc4_hvs.c
@@ -75,10 +75,10 @@ void vc4_hvs_dump_state(struct drm_device *dev)
for (i = 0; i < 64; i += 4) {
DRM_INFO("0x%08x (%s): 0x%08x 0x%08x 0x%08x 0x%08x\n",
i * 4, i < HVS_BOOTLOADER_DLIST_END ? "B" : "D",
-((uint32_t *)vc4->hvs->dlist)[i + 0],
-((uint32_t *)vc4->hvs->dlist)[i + 1],
-((uint32_t *)vc4->hvs->dlist)[i + 2],
-((uint32_t *)vc4->hvs->dlist)[i + 3]);
+readl((u32 __iomem *)vc4->hvs->dlist + 0),
+readl((u32 __iomem *)vc4->hvs->dlist + 1),
+readl((u32 __iomem *)vc4->hvs->dlist + 2),
+readl((u32 __iomem *)vc4->hvs->dlist + 3));
}
}
--
2.6.1
VC4 fixes for -next
Merging vc4 to drm-next got a few automatic sparse and coccinelle warning reports generated. The first 3 patches come from the maintainers of those systems (thanks!), and the last 3 are fixes I've come up with in the last few days.
[PATCH 1/6] drm/vc4: vc4_plane_duplicate_state() can be static
From: kbuild test robot
Signed-off-by: Fengguang Wu
Signed-off-by: Eric Anholt
---
drivers/gpu/drm/vc4/vc4_plane.c | 8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/vc4/vc4_plane.c b/drivers/gpu/drm/vc4/vc4_plane.c
index cdd8b10..2db5092 100644
--- a/drivers/gpu/drm/vc4/vc4_plane.c
+++ b/drivers/gpu/drm/vc4/vc4_plane.c
@@ -70,7 +70,7 @@ static bool plane_enabled(struct drm_plane_state *state)
return state->fb && state->crtc;
}
-struct drm_plane_state *vc4_plane_duplicate_state(struct drm_plane *plane)
+static struct drm_plane_state *vc4_plane_duplicate_state(struct drm_plane
*plane)
{
struct vc4_plane_state *vc4_state;
@@ -97,8 +97,8 @@ struct drm_plane_state *vc4_plane_duplicate_state(struct
drm_plane *plane)
return &vc4_state->base;
}
-void vc4_plane_destroy_state(struct drm_plane *plane,
-struct drm_plane_state *state)
+static void vc4_plane_destroy_state(struct drm_plane *plane,
+ struct drm_plane_state *state)
{
struct vc4_plane_state *vc4_state = to_vc4_plane_state(state);
@@ -108,7 +108,7 @@ void vc4_plane_destroy_state(struct drm_plane *plane,
}
/* Called during init to allocate the plane's atomic state. */
-void vc4_plane_reset(struct drm_plane *plane)
+static void vc4_plane_reset(struct drm_plane *plane)
{
struct vc4_plane_state *vc4_state;
--
2.6.1
[PATCH 3/6] drm/vc4: fix itnull.cocci warnings
From: Julia Lawall
Connector cannot be null because it is a list entry, ie accessed at an
offset from the positions of the list structure pointers themselves.
Generated by: scripts/coccinelle/iterators/itnull.cocci
Signed-off-by: Fengguang Wu
Signed-off-by: Julia Lawall
Signed-off-by: Eric Anholt
---
drivers/gpu/drm/vc4/vc4_crtc.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/vc4/vc4_crtc.c b/drivers/gpu/drm/vc4/vc4_crtc.c
index 8489d5b..a3a77dd 100644
--- a/drivers/gpu/drm/vc4/vc4_crtc.c
+++ b/drivers/gpu/drm/vc4/vc4_crtc.c
@@ -168,7 +168,7 @@ static int vc4_get_clock_select(struct drm_crtc *crtc)
struct drm_connector *connector;
drm_for_each_connector(connector, crtc->dev) {
- if (connector && connector->state->crtc == crtc) {
+ if (connector->state->crtc == crtc) {
struct drm_encoder *encoder = connector->encoder;
struct vc4_encoder *vc4_encoder =
to_vc4_encoder(encoder);
--
2.6.1
[PATCH 6/6] drm/vc4: Add support for more a few more RGB display plane formats.
These were all touch-tested with modetest.
Signed-off-by: Eric Anholt
---
drivers/gpu/drm/vc4/vc4_plane.c | 16
1 file changed, 16 insertions(+)
diff --git a/drivers/gpu/drm/vc4/vc4_plane.c b/drivers/gpu/drm/vc4/vc4_plane.c
index 887f3ca..b31dfce 100644
--- a/drivers/gpu/drm/vc4/vc4_plane.c
+++ b/drivers/gpu/drm/vc4/vc4_plane.c
@@ -51,6 +51,22 @@ static const struct hvs_format {
.drm = DRM_FORMAT_ARGB, .hvs = HVS_PIXEL_FORMAT_RGBA,
.pixel_order = HVS_PIXEL_ORDER_ABGR, .has_alpha = true,
},
+ {
+ .drm = DRM_FORMAT_RGB565, .hvs = HVS_PIXEL_FORMAT_RGB565,
+ .pixel_order = HVS_PIXEL_ORDER_XRGB, .has_alpha = false,
+ },
+ {
+ .drm = DRM_FORMAT_BGR565, .hvs = HVS_PIXEL_FORMAT_RGB565,
+ .pixel_order = HVS_PIXEL_ORDER_XBGR, .has_alpha = false,
+ },
+ {
+ .drm = DRM_FORMAT_ARGB1555, .hvs = HVS_PIXEL_FORMAT_RGBA5551,
+ .pixel_order = HVS_PIXEL_ORDER_ABGR, .has_alpha = true,
+ },
+ {
+ .drm = DRM_FORMAT_XRGB1555, .hvs = HVS_PIXEL_FORMAT_RGBA5551,
+ .pixel_order = HVS_PIXEL_ORDER_ABGR, .has_alpha = false,
+ },
};
static const struct hvs_format *vc4_get_hvs_format(u32 drm_format)
--
2.6.1
[PATCH 5/6] drm/vc4: Make sure that planes aren't scaled.
We would scan out the memory around them if an upscale was attempted,
and would just scan out incorrectly for downscaling.
Signed-off-by: Eric Anholt
---
It looks like, while modetest only wants to set scaling on overlay
planes, one could do so on our primary/cursor planes if the fd was in
universal planes mode.
drivers/gpu/drm/vc4/vc4_plane.c | 10 ++
1 file changed, 10 insertions(+)
diff --git a/drivers/gpu/drm/vc4/vc4_plane.c b/drivers/gpu/drm/vc4/vc4_plane.c
index 2db5092..887f3ca 100644
--- a/drivers/gpu/drm/vc4/vc4_plane.c
+++ b/drivers/gpu/drm/vc4/vc4_plane.c
@@ -157,6 +157,16 @@ static int vc4_plane_mode_set(struct drm_plane *plane,
int crtc_w = state->crtc_w;
int crtc_h = state->crtc_h;
+ if (state->crtc_w << 16 != state->src_w ||
+ state->crtc_h << 16 != state->src_h) {
+ /* We don't support scaling yet, which involves
+* allocating the LBM memory for scaling temporary
+* storage, and putting filter kernels in the HVS
+* context.
+*/
+ return -EINVAL;
+ }
+
if (crtc_x < 0) {
offset += drm_format_plane_cpp(fb->pixel_format, 0) * -crtc_x;
crtc_w += crtc_x;
--
2.6.1
[Bug 92214] Flightgear crashes during splashboot with R600 driver, LLVM 3.7.0 and mesa 11.0.2
https://bugs.freedesktop.org/show_bug.cgi?id=92214 --- Comment #37 from Jose Fonseca --- (In reply to Roland Scheidegger from comment #36) > I don't think llvm's behavior makes sense. We got the cpu name from llvm, > that we have to manually list cpu features which it CAN'T use when just > using that name then is imho crazy. I've updated the llvm bug accordingly. The fact is that the cpu name is ambigous, so whether LLVM takes the "usually" support features, vs the "minimally" supported features is really a matter of convention. We should set negative flags where appropriate. My concern is whether passing "-sse4_1" to a non-Intel CPU will cause problems. A quick check with altivec shows that's the case: '-altivec' is not a recognized feature for this target (ignoring feature) I'll attach a patch that should fix this. -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20151023/a94544ca/attachment.html>
[Bug 92214] Flightgear crashes during splashboot with R600 driver, LLVM 3.7.0 and mesa 11.0.2
https://bugs.freedesktop.org/show_bug.cgi?id=92214 Jose Fonseca changed: What|Removed |Added CC||jfonseca at vmware.com --- Comment #38 from Jose Fonseca --- Created attachment 119141 --> https://bugs.freedesktop.org/attachment.cgi?id=119141&action=edit llvm-mattrs.patch Comprehensive fix. -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20151023/27b4efcc/attachment-0001.html>
[PATCH 5/6] drm/vc4: Make sure that planes aren't scaled.
On Fri, Oct 23, 2015 at 11:32:35AM +0100, Eric Anholt wrote:
> We would scan out the memory around them if an upscale was attempted,
> and would just scan out incorrectly for downscaling.
>
> Signed-off-by: Eric Anholt
> ---
>
> It looks like, while modetest only wants to set scaling on overlay
> planes, one could do so on our primary/cursor planes if the fd was in
> universal planes mode.
>
> drivers/gpu/drm/vc4/vc4_plane.c | 10 ++
> 1 file changed, 10 insertions(+)
>
> diff --git a/drivers/gpu/drm/vc4/vc4_plane.c b/drivers/gpu/drm/vc4/vc4_plane.c
> index 2db5092..887f3ca 100644
> --- a/drivers/gpu/drm/vc4/vc4_plane.c
> +++ b/drivers/gpu/drm/vc4/vc4_plane.c
> @@ -157,6 +157,16 @@ static int vc4_plane_mode_set(struct drm_plane *plane,
> int crtc_w = state->crtc_w;
> int crtc_h = state->crtc_h;
>
> + if (state->crtc_w << 16 != state->src_w ||
> + state->crtc_h << 16 != state->src_h) {
> + /* We don't support scaling yet, which involves
> + * allocating the LBM memory for scaling temporary
> + * storage, and putting filter kernels in the HVS
> + * context.
> + */
> + return -EINVAL;
> + }
Just aside: There's drm_plane_helper_check_update for the common cases.
Unfortunately it suffers a bit from a bikeshed since it wants struct
drm_rect but atomic states don't give you that.
-Daniel
> +
> if (crtc_x < 0) {
> offset += drm_format_plane_cpp(fb->pixel_format, 0) * -crtc_x;
> crtc_w += crtc_x;
> --
> 2.6.1
>
> ___
> dri-devel mailing list
> dri-devel at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/dri-devel
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
[PATCH 10/10] drm/exynos/decon5433: add support for DECON-TV
Hi Andrzej,
2015ë
10ì 20ì¼ 18:22ì Andrzej Hajda ì´(ê°) ì´ ê¸:
> DECON-TV IP is responsible for generating video stream which is transferred
> to HDMI IP. It is almost fully compatible with DECON IP.
>
> The patch is based on initial work of Hyungwon Hwang.
>
> Signed-off-by: Andrzej Hajda
> ---
> drivers/gpu/drm/exynos/exynos5433_drm_decon.c | 154
> --
> include/video/exynos5433_decon.h | 29 +
> 2 files changed, 122 insertions(+), 61 deletions(-)
>
> diff --git a/drivers/gpu/drm/exynos/exynos5433_drm_decon.c
> b/drivers/gpu/drm/exynos/exynos5433_drm_decon.c
> index 3c9aa4e..fbe1b31 100644
> --- a/drivers/gpu/drm/exynos/exynos5433_drm_decon.c
> +++ b/drivers/gpu/drm/exynos/exynos5433_drm_decon.c
> @@ -13,6 +13,7 @@
> #include
> #include
> #include
> +#include
> #include
> #include
>
> @@ -37,6 +38,12 @@ static const char * const decon_clks_name[] = {
> "sclk_decon_eclk",
> };
>
> +enum decon_iftype {
> + IFTYPE_RGB,
> + IFTYPE_I80,
> + IFTYPE_HDMI
> +};
> +
> enum decon_flag_bits {
> BIT_CLKS_ENABLED,
> BIT_IRQS_ENABLED,
> @@ -53,7 +60,8 @@ struct decon_context {
> struct clk *clks[ARRAY_SIZE(decon_clks_name)];
> int pipe;
> unsigned long flags;
> - booli80_if;
> + enum decon_iftype out_type;
> + int first_win;
> };
>
> static const uint32_t decon_formats[] = {
> @@ -80,7 +88,7 @@ static int decon_enable_vblank(struct exynos_drm_crtc *crtc)
>
> if (test_and_set_bit(BIT_IRQS_ENABLED, &ctx->flags)) {
> val = VIDINTCON0_INTEN;
> - if (ctx->i80_if)
> + if (ctx->out_type == IFTYPE_I80)
> val |= VIDINTCON0_FRAMEDONE;
> else
> val |= VIDINTCON0_INTFRMEN;
> @@ -104,8 +112,11 @@ static void decon_disable_vblank(struct exynos_drm_crtc
> *crtc)
>
> static void decon_setup_trigger(struct decon_context *ctx)
> {
> - u32 val = TRIGCON_TRIGEN_PER_F | TRIGCON_TRIGEN_F |
> - TRIGCON_TE_AUTO_MASK | TRIGCON_SWTRIGEN;
> + u32 val = (ctx->out_type != IFTYPE_HDMI)
> + ? TRIGCON_TRIGEN_PER_F | TRIGCON_TRIGEN_F |
> + TRIGCON_TE_AUTO_MASK | TRIGCON_SWTRIGEN
> + : TRIGCON_TRIGEN_PER_F | TRIGCON_TRIGEN_F |
> + TRIGCON_HWTRIGMASK_I80_RGB | TRIGCON_HWTRIGEN_I80_RGB;
> writel(val, ctx->addr + DECON_TRIGCON);
> }
>
> @@ -118,13 +129,22 @@ static void decon_commit(struct exynos_drm_crtc *crtc)
> if (test_bit(BIT_SUSPENDED, &ctx->flags))
> return;
>
> + if (ctx->out_type == IFTYPE_HDMI) {
> + m->crtc_hsync_start = m->crtc_hdisplay + 10;
> + m->crtc_hsync_end = m->crtc_htotal - 92;
> + m->crtc_vsync_start = m->crtc_vdisplay + 1;
> + m->crtc_vsync_end = m->crtc_vsync_start + 1;
> + }
> +
> + decon_set_bits(ctx, DECON_VIDCON0, VIDCON0_ENVID, 0);
> +
> /* enable clock gate */
> val = CMU_CLKGAGE_MODE_SFR_F | CMU_CLKGAGE_MODE_MEM_F;
> writel(val, ctx->addr + DECON_CMU);
>
> /* lcd on and use command if */
> val = VIDOUT_LCD_ON;
> - if (ctx->i80_if)
> + if (ctx->out_type == IFTYPE_I80)
> val |= VIDOUT_COMMAND_IF;
> else
> val |= VIDOUT_RGB_IF;
> @@ -134,7 +154,7 @@ static void decon_commit(struct exynos_drm_crtc *crtc)
> VIDTCON2_HOZVAL(m->hdisplay - 1);
> writel(val, ctx->addr + DECON_VIDTCON2);
>
> - if (!ctx->i80_if) {
> + if (ctx->out_type != IFTYPE_I80) {
> val = VIDTCON00_VBPD_F(
> m->crtc_vtotal - m->crtc_vsync_end - 1) |
> VIDTCON00_VFPD_F(
> @@ -159,15 +179,9 @@ static void decon_commit(struct exynos_drm_crtc *crtc)
> decon_setup_trigger(ctx);
>
> /* enable output and display signal */
> - val = VIDCON0_ENVID | VIDCON0_ENVID_F;
> - writel(val, ctx->addr + DECON_VIDCON0);
> + decon_set_bits(ctx, DECON_VIDCON0, VIDCON0_ENVID | VIDCON0_ENVID_F, ~0);
> }
>
> -#define COORDINATE_X(x) (((x) & 0xfff) << 12)
> -#define COORDINATE_Y(x) ((x) & 0xfff)
> -#define OFFSIZE(x) (((x) & 0x3fff) << 14)
> -#define PAGEWIDTH(x) ((x) & 0x3fff)
> -
> static void decon_win_set_pixfmt(struct decon_context *ctx, unsigned int
> win,
>struct drm_framebuffer *fb)
> {
> @@ -238,6 +252,10 @@ static void decon_atomic_begin(struct exynos_drm_crtc
> *crtc,
> decon_shadow_protect_win(ctx, plane->zpos, true);
> }
>
> +#define BIT_VAL(x, e, s) (((x) & ((1 << ((e) - (s) + 1)) - 1)) << (s))
> +#define COORDINATE_X(x) BIT_VAL((x), 23, 12)
> +#define COORDINATE_Y(x) BIT_VAL((x), 11, 0)
> +
> static void decon_update_plane(struct exynos_drm_crtc *cr
[RFC v4 05/11] dt-bindings: drm/mediatek: Add Mediatek HDMI dts binding
On Fri, Oct 16, 2015 at 3:12 PM, Philipp Zabel
wrote:
> Add the device tree binding documentation for Mediatek HDMI,
> HDMI PHY and HDMI DDC devices.
>
> Signed-off-by: Philipp Zabel
> ---
> Changes since v3:
> - Split CEC block into a separate node, move the hotplug interrupt there
> - Removed reg-names, hdmi now only as a single register range
> - Added mediatek,cec and mediatek,syscon-hdmi phandles
> - Shortened clock names, removed div and sel clocks from the binding
> - Added a pll_ref clock input to the hdmi phy.
> - Fixed the hdmi interrupt to the documented value.
> ---
> .../bindings/drm/mediatek/mediatek,hdmi.txt| 127
> +
> 1 file changed, 127 insertions(+)
> create mode 100644
> Documentation/devicetree/bindings/drm/mediatek/mediatek,hdmi.txt
>
> diff --git a/Documentation/devicetree/bindings/drm/mediatek/mediatek,hdmi.txt
> b/Documentation/devicetree/bindings/drm/mediatek/mediatek,hdmi.txt
> new file mode 100644
> index 000..2ba5f65
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/drm/mediatek/mediatek,hdmi.txt
> @@ -0,0 +1,127 @@
> +Mediatek HDMI Encoder
> +=
> +
> +The Mediatek HDMI encoder can generate HDMI 1.4a or MHL 2.0 signals from
> +its parallel input.
How do you know whether it is HDMI or MHL on a given board? You should
have a connector node perhaps.
> +
> +Required properties:
> +- compatible: Should be "mediatek,-hdmi".
> +- reg: Physical base address and length of the controller's registers
> +- interrupts: The interrupt signal from the function block.
> +- clocks: device clocks
> + See Documentation/devicetree/bindings/clock/clock-bindings.txt for details.
> +- clock-names: must contain "pixel", "pll", "bclk", and "spdif".
> +- mediatek,cec: phandle link to the HDMI CEC node.
Do you have more than 1 CEC block? If not, just find the compatible
node with of_find_compatible_node.
> +- ddc-i2c-bus: phandle link to the I2C controller used for DDC EDID probing
This really should be part of a connector node as I2C bus goes to the
connector, not the HDMI block.
> +- phys: phandle link to the HDMI PHY node.
> + See Documentation/devicetree/bindings/phy/phy-bindings.txt for details.
> +- phy-names: must contain "hdmi"
> +- mediatek,syscon-hdmi: phandle link and register offset to the system
> + configuration registers. For mt8173 this must be offset 0x900 into the
> + MMSYS_CONFIG region: <&mmsys 0x900>.
> +- ports: A node containing input and output port nodes with endpoint
> + definitions as documented in Documentation/devicetree/bindings/graph.txt.
> +- port at 0: The input port in the ports node should be connected to a DPI
> output
> + port.
> +
> +Optional properties:
> +- port at 1: The output port in the ports node can be connected to the input
> port
> + of an attached bridge chip, such as a SlimPort transmitter.
> +
> +HDMI CEC
> +
> +
> +The HDMI CEC controller handles hotplug detection and CEC communication.
> +
> +Required properties:
> +- compatible: Should be "mediatek,-cec"
> +- reg: Physical base address and length of the controller's registers
> +- interrupts: The interrupt signal from the function block.
> +- clocks: device clock
> +
> +HDMI DDC
> +
> +
> +The HDMI DDC i2c controller is used to interface with the HDMI DDC pins.
> +The Mediatek's I2C controller is used to interface with I2C devices.
> +
> +Required properties:
> +- compatible: Should be "mediatek,-hdmi-ddc"
> +- reg: Physical base address and length of the controller's registers
> +- clocks: device clock
> +- clock-names: Should be "ddc-i2c".
> +
> +HDMI PHY
> +
> +
> +The HDMI PHY serializes the HDMI encoder's three channel 10-bit parallel
> +output and drives the HDMI pads.
> +
> +Required properties:
> +- compatible: "mediatek,-hdmi-phy"
> +- reg: Physical base address and length of the module's registers
> +- clocks: PLL reference clock
> +- clock-names: must contain "pll_ref"
> +- #phy-cells: must be <0>.
> +
> +Optional properties:
> +- ibias: TX DRV bias current for <1.65Gbps, defaults to 0xa
> +- ibias_up: TX DRV bias current for >1.65Gbps, defaults to 0x1c
prefix with "mediatek,"
> +
> +Example:
> +
> +cec: cec at 10013000 {
> + compatible = "mediatek,mt8173-cec";
> + reg = <0 0x10013000 0 0xbc>;
> + interrupts = ;
> + clocks = <&infracfg CLK_INFRA_CEC>;
> +};
> +
> +hdmi_phy: hdmi-phy at 10209100 {
> + compatible = "mediatek,mt8173-hdmi-phy";
> + reg = <0 0x10209100 0 0x24>;
> + clocks = <&apmixedsys CLK_APMIXED_HDMI_REF>;
> + clock-names = "pll_ref";
> + ibias = <0xa>;
> + ibias_up = <0x1c>;
> + #phy-cells = <0>;
> +};
> +
> +hdmi_ddc0: i2c at 11012000 {
> + compatible = "mediatek,mt8173-hdmi-ddc";
> + reg = <0 0x11012000 0 0x1c>;
> + interrupts = ;
> + clocks = <&pericfg CLK_PERI_I2C5>;
> + clock-names = "ddc-i2c";
> +};
> +
> +hdmi0: hdmi at 14025000 {
> + compatible = "mediat
[RFC v4 01/11] dt-bindings: drm/mediatek: Add Mediatek display subsystem dts binding
On Fri, Oct 16, 2015 at 3:12 PM, Philipp Zabel wrote: > From: CK Hu > > Add device tree binding documentation for the display subsystem in > Mediatek MT8173 SoCs. The display function block nodes are grouped > under a display-subsystem node. > > Signed-off-by: CK Hu > Signed-off-by: Philipp Zabel > --- > Changes since v3: > - Moved DISP function blocks back out of the group node, updated example >from the device tree, including wdma blocks. > - Removed the divider and mux clocks from the DPI bindings, those are >not direct inputs and can be set by the clock framework. > --- > .../bindings/drm/mediatek/mediatek,disp.txt| 182 > + > .../bindings/drm/mediatek/mediatek,dpi.txt | 35 > .../bindings/drm/mediatek/mediatek,dsi.txt | 53 ++ This all looks good to me, but please move to bindings/display/mediatek/ Rob
[PATCH drm 4/6] drm: add drm_gem_prime_page_flip() helper
Hi, On 22 October 2015 at 21:25, Daniel Vetter wrote: > Maarten Lankhorst had patches to do that for i915, but they just didn't go > anywhere since i915 gem locking is a bit ... antique. But if your goal is > to only fix up the page_flip path, and only for i915 as the display > driver, then the only thing you need to do is: > - grab the reservation of the gem bo underlying the fb > - grab the exclusive fence (fence_get) > - wait for that fence to complete in the async worker (we already have the > mmio_flip stuff for when you do the flip from the cpu) > - drop the fence once done with fence_put > > Works as long as the producer correctly sets the exclusive fence (doesn't > matter whether that's done with an explicit ioctl or at command > submission). And that's already done by nouveau (well ttm) afaik. > > No changes at all in userspace required. Totally agree. For implicit sync, this is also how we (and ChromeOS) do it on ARM, e.g.: https://git.collabora.com/cgit/user/daniels/linux.git/tree/drivers/gpu/drm/exynos/exynos_drm_fb.c?h=tmp/lfrb#n288 This was never upstreamed as the users (Exynos, Rockchip, et al) depended on Mali, but it does offer a perfect implementation of implicit synchronisation between multiple separate devices when you place reservation objects. > Now if you want to do proper explicit fencing for kms, that's an entirely > different story. For that we want something like android's hw composer > in/out fences, and obviously for atomic (because interface extensions for > legacy modeset ioctls just don't make sense). But that means we need the > full stack, using open-source userspace, and that's a lot more pain. Totally agreed. New legacy API is pretty much a no-go - especially given the painful semantics they force you to implement - and wouldn't take any less time to roll out through the kernel and userspace, including working on tests, than it would to wait for Maarten Lankhorst's existing async-atomic work to land. Cheers, Daniel
[PATCH 10/10] drm/exynos/decon5433: add support for DECON-TV
On 10/23/2015 01:55 PM, Inki Dae wrote:
> Hi Andrzej,
>
>
> 2015ë
10ì 20ì¼ 18:22ì Andrzej Hajda ì´(ê°) ì´ ê¸:
>> DECON-TV IP is responsible for generating video stream which is transferred
>> to HDMI IP. It is almost fully compatible with DECON IP.
>>
>> The patch is based on initial work of Hyungwon Hwang.
>>
>> Signed-off-by: Andrzej Hajda
>> ---
>> drivers/gpu/drm/exynos/exynos5433_drm_decon.c | 154
>> --
>> include/video/exynos5433_decon.h | 29 +
>> 2 files changed, 122 insertions(+), 61 deletions(-)
>>
>> diff --git a/drivers/gpu/drm/exynos/exynos5433_drm_decon.c
>> b/drivers/gpu/drm/exynos/exynos5433_drm_decon.c
>> index 3c9aa4e..fbe1b31 100644
>> --- a/drivers/gpu/drm/exynos/exynos5433_drm_decon.c
>> +++ b/drivers/gpu/drm/exynos/exynos5433_drm_decon.c
>> @@ -13,6 +13,7 @@
>> #include
>> #include
>> #include
>> +#include
>> #include
>> #include
>>
>> @@ -37,6 +38,12 @@ static const char * const decon_clks_name[] = {
>> "sclk_decon_eclk",
>> };
>>
>> +enum decon_iftype {
>> +IFTYPE_RGB,
>> +IFTYPE_I80,
>> +IFTYPE_HDMI
>> +};
>> +
>> enum decon_flag_bits {
>> BIT_CLKS_ENABLED,
>> BIT_IRQS_ENABLED,
>> @@ -53,7 +60,8 @@ struct decon_context {
>> struct clk *clks[ARRAY_SIZE(decon_clks_name)];
>> int pipe;
>> unsigned long flags;
>> -booli80_if;
>> +enum decon_iftype out_type;
>> +int first_win;
>> };
>>
>> static const uint32_t decon_formats[] = {
>> @@ -80,7 +88,7 @@ static int decon_enable_vblank(struct exynos_drm_crtc
>> *crtc)
>>
>> if (test_and_set_bit(BIT_IRQS_ENABLED, &ctx->flags)) {
>> val = VIDINTCON0_INTEN;
>> -if (ctx->i80_if)
>> +if (ctx->out_type == IFTYPE_I80)
>> val |= VIDINTCON0_FRAMEDONE;
>> else
>> val |= VIDINTCON0_INTFRMEN;
>> @@ -104,8 +112,11 @@ static void decon_disable_vblank(struct exynos_drm_crtc
>> *crtc)
>>
>> static void decon_setup_trigger(struct decon_context *ctx)
>> {
>> -u32 val = TRIGCON_TRIGEN_PER_F | TRIGCON_TRIGEN_F |
>> -TRIGCON_TE_AUTO_MASK | TRIGCON_SWTRIGEN;
>> +u32 val = (ctx->out_type != IFTYPE_HDMI)
>> +? TRIGCON_TRIGEN_PER_F | TRIGCON_TRIGEN_F |
>> + TRIGCON_TE_AUTO_MASK | TRIGCON_SWTRIGEN
>> +: TRIGCON_TRIGEN_PER_F | TRIGCON_TRIGEN_F |
>> + TRIGCON_HWTRIGMASK_I80_RGB | TRIGCON_HWTRIGEN_I80_RGB;
>> writel(val, ctx->addr + DECON_TRIGCON);
>> }
>>
>> @@ -118,13 +129,22 @@ static void decon_commit(struct exynos_drm_crtc *crtc)
>> if (test_bit(BIT_SUSPENDED, &ctx->flags))
>> return;
>>
>> +if (ctx->out_type == IFTYPE_HDMI) {
>> +m->crtc_hsync_start = m->crtc_hdisplay + 10;
>> +m->crtc_hsync_end = m->crtc_htotal - 92;
>> +m->crtc_vsync_start = m->crtc_vdisplay + 1;
>> +m->crtc_vsync_end = m->crtc_vsync_start + 1;
>> +}
>> +
>> +decon_set_bits(ctx, DECON_VIDCON0, VIDCON0_ENVID, 0);
>> +
>> /* enable clock gate */
>> val = CMU_CLKGAGE_MODE_SFR_F | CMU_CLKGAGE_MODE_MEM_F;
>> writel(val, ctx->addr + DECON_CMU);
>>
>> /* lcd on and use command if */
>> val = VIDOUT_LCD_ON;
>> -if (ctx->i80_if)
>> +if (ctx->out_type == IFTYPE_I80)
>> val |= VIDOUT_COMMAND_IF;
>> else
>> val |= VIDOUT_RGB_IF;
>> @@ -134,7 +154,7 @@ static void decon_commit(struct exynos_drm_crtc *crtc)
>> VIDTCON2_HOZVAL(m->hdisplay - 1);
>> writel(val, ctx->addr + DECON_VIDTCON2);
>>
>> -if (!ctx->i80_if) {
>> +if (ctx->out_type != IFTYPE_I80) {
>> val = VIDTCON00_VBPD_F(
>> m->crtc_vtotal - m->crtc_vsync_end - 1) |
>> VIDTCON00_VFPD_F(
>> @@ -159,15 +179,9 @@ static void decon_commit(struct exynos_drm_crtc *crtc)
>> decon_setup_trigger(ctx);
>>
>> /* enable output and display signal */
>> -val = VIDCON0_ENVID | VIDCON0_ENVID_F;
>> -writel(val, ctx->addr + DECON_VIDCON0);
>> +decon_set_bits(ctx, DECON_VIDCON0, VIDCON0_ENVID | VIDCON0_ENVID_F, ~0);
>> }
>>
>> -#define COORDINATE_X(x) (((x) & 0xfff) << 12)
>> -#define COORDINATE_Y(x) ((x) & 0xfff)
>> -#define OFFSIZE(x) (((x) & 0x3fff) << 14)
>> -#define PAGEWIDTH(x)((x) & 0x3fff)
>> -
>> static void decon_win_set_pixfmt(struct decon_context *ctx, unsigned int
>> win,
>> struct drm_framebuffer *fb)
>> {
>> @@ -238,6 +252,10 @@ static void decon_atomic_begin(struct exynos_drm_crtc
>> *crtc,
>> decon_shadow_protect_win(ctx, plane->zpos, true);
>> }
>>
>> +#define BIT_VAL(x, e, s) (((x) & ((1 << ((e) - (s) + 1)) - 1)) << (s))
>> +#define COORDINATE_X(x) BIT_VAL((
[Bug 92214] Flightgear crashes during splashboot with R600 driver, LLVM 3.7.0 and mesa 11.0.2
https://bugs.freedesktop.org/show_bug.cgi?id=92214 --- Comment #39 from Barto --- thanks Jose for this patch just for the record : in 2013 in llvm's bugzilla someone has already opened a bug report about the same problem ( his pentium dual core was treaten as penryn instead of core2 by llvm, which triggers bug about SSE4.1 ) : https://llvm.org/bugs/show_bug.cgi?id=16721 at that time the solution found by Benjamin Kramer was to fix the problem by adding the "SSE4.1 test" in /lib/Support/Host.cpp : http://lists.llvm.org/pipermail/llvm-commits/Week-of-Mon-20130729/182469.html unfortunately this fix was deleted by Craig Cooper with his commit cd83d5b5071f072882ad06cc4b904b2d27d1e54a in march 2015 gcc seems to handle this problem differently, my pentium dual core is identified as "core2" when I use "-march=native" : $ gcc -march=native -Q --help=target | grep march -march= core2 $ gcc -march=native -Q --help=target | grep sse -mno-sse4 [enabled] -msse [enabled] -msse2[enabled] -msse2avx [disabled] -msse3[enabled] -msse4[disabled] -msse4.1 [disabled] -msse4.2 [disabled] -msse4a [disabled] -msse5 -msseregparm [disabled] -mssse3 [enabled] but with clang 3.7.0 the "-march=native" argument leads to "cpu penryn" with maybe the use of sse4.1 even if the CPU is a pentium dual core who doesn't support sse4.1 $ clang -v -E -march=native - "/usr/bin/clang-3.7" -cc1 -triple x86_64-unknown-linux-gnu -E -disable-free -disable-llvm-verifier -main-file-name - -mrelocation-model static -mthread-model posix -mdisable-fp-elim -fmath-errno -masm-verbose -mconstructor-aliases -munwind-tables -fuse-init-array -target-cpu penryn -target-feature -sse4a -target-feature -avx512bw -target-feature +cx16 -target-feature -tbm -target-feature -adx -target-feature -fma4 -target-feature -avx512vl -target-feature -prfchw -target-feature -bmi2 -target-feature -avx512pf -target-feature -fsgsbase -target-feature -avx -target-feature -avx512cd -target-feature -rtm -target-feature -popcnt -target-feature -fma -target-feature -bmi -target-feature -aes -target-feature -rdrnd -target-feature -sse4.1 -target-feature -sse4.2 -target-feature -avx2 -target-feature -avx512er -target-feature +sse -target-feature -lzcnt -target-feature -pclmul -target-feature -avx512f -target-feature -f16c -target-feature +ssse3 -target-feature +mmx -target-feature +cmov -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20151023/12007168/attachment.html>
[PATCH 4/6] drm/vc4: Fix some failure to track __iomem decorations on pointers.
On Oct 23, 2015 6:32 AM, "Eric Anholt" wrote:
>
> Caught by the kbuild test robot.
>
> Signed-off-by: Eric Anholt
> ---
> drivers/gpu/drm/vc4/vc4_crtc.c | 3 ++-
> drivers/gpu/drm/vc4/vc4_hvs.c | 8
> 2 files changed, 6 insertions(+), 5 deletions(-)
>
> diff --git a/drivers/gpu/drm/vc4/vc4_crtc.c
b/drivers/gpu/drm/vc4/vc4_crtc.c
> index a3a77dd..32c0348 100644
> --- a/drivers/gpu/drm/vc4/vc4_crtc.c
> +++ b/drivers/gpu/drm/vc4/vc4_crtc.c
> @@ -401,7 +401,8 @@ static void vc4_crtc_atomic_flush(struct drm_crtc
*crtc,
> dlist_next++;
>
> HVS_WRITE(SCALER_DISPLISTX(vc4_crtc->channel),
> - (u32 *)vc4_crtc->dlist - (u32
*)vc4->hvs->dlist);
> + (u32 __iomem *)vc4_crtc->dlist -
> + (u32 __iomem *)vc4->hvs->dlist);
>
> /* Make the next display list start after ours. */
> vc4_crtc->dlist_size -= (dlist_next - vc4_crtc->dlist);
> diff --git a/drivers/gpu/drm/vc4/vc4_hvs.c b/drivers/gpu/drm/vc4/vc4_hvs.c
> index ab1673f..4d81d43 100644
> --- a/drivers/gpu/drm/vc4/vc4_hvs.c
> +++ b/drivers/gpu/drm/vc4/vc4_hvs.c
> @@ -75,10 +75,10 @@ void vc4_hvs_dump_state(struct drm_device *dev)
> for (i = 0; i < 64; i += 4) {
> DRM_INFO("0x%08x (%s): 0x%08x 0x%08x 0x%08x 0x%08x\n",
> i * 4, i < HVS_BOOTLOADER_DLIST_END ? "B" : "D",
> -((uint32_t *)vc4->hvs->dlist)[i + 0],
> -((uint32_t *)vc4->hvs->dlist)[i + 1],
> -((uint32_t *)vc4->hvs->dlist)[i + 2],
> -((uint32_t *)vc4->hvs->dlist)[i + 3]);
> +readl((u32 __iomem *)vc4->hvs->dlist + 0),
> +readl((u32 __iomem *)vc4->hvs->dlist + 1),
> +readl((u32 __iomem *)vc4->hvs->dlist + 2),
> +readl((u32 __iomem *)vc4->hvs->dlist + 3));
Looks like you lost the +i here, no?
> }
> }
>
> --
> 2.6.1
>
> ___
> dri-devel mailing list
> dri-devel at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/dri-devel
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20151023/1aaabece/attachment-0001.html>
[Bug 92645] kodi vdpau interop fails since mesa,meta: move gl_texture_object::TargetIndex initializations
https://bugs.freedesktop.org/show_bug.cgi?id=92645 Bug ID: 92645 Summary: kodi vdpau interop fails since mesa,meta: move gl_texture_object::TargetIndex initializations Product: Mesa Version: git Hardware: x86-64 (AMD64) OS: Linux (All) Status: NEW Severity: normal Priority: medium Component: Drivers/Gallium/radeonsi Assignee: dri-devel at lists.freedesktop.org Reporter: adf.lists at gmail.com QA Contact: dri-devel at lists.freedesktop.org Kodi when using vdpau decode on tonga GPU does not render anything since commit 7d7dd1871174905dfdd3ca874a09d9d7837ac743 Author: Brian Paul Date: Mon Oct 5 08:14:56 2015 -0600 mesa,meta: move gl_texture_object::TargetIndex initializations Before, we were unconditionally assigning the TargetIndex field in _mesa_BindTexture(), even if it was already set properly. Now we initialize TargetIndex wherever we initialize the Target field, in _mesa_initialize_texture_object(), finish_texture_init(), etc. v2: also update the meta_copy_image code. In make_view() the view_tex_obj->Target field was set, but not the TargetIndex field. Also, remove a second, redundant assignment to view_tex_obj->Target. Add sanity check assertions too. Its debug log shows - 15:52:36 T:140075084736256 NOTICE: VDPAU::COutput registered output surfaces 15:52:36 T:140076208588672 NOTICE: Previous line repeats 4 times. 15:52:36 T:140076208588672 DEBUG: CLinuxRendererGL::GetPlaneTextureSize - invalid size 0x0 - 0 I guess this is something to do with vdpau interop, but mpv interop still works ... -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20151023/c480719d/attachment.html>
[pull] amdgpu and radeon drm-fixes-4.3
Hi Dave, Two regression fixes and a memory leak fix for amdgpu and radeon. The following changes since commit c50f13f911b90a722308bffbf26187ff3890aa1e: Merge branch 'drm-fixes-4.3' of git://people.freedesktop.org/~agd5f/linux into drm-fixes (2015-10-22 10:24:55 +1000) are available in the git repository at: git://people.freedesktop.org/~agd5f/linux drm-fixes-4.3 for you to fetch changes up to c86f5ebfbd147d1a228ab89ee1658e18939bd7ad: drm/amdgpu: don't try to recreate sysfs entries on resume (2015-10-23 10:45:35 -0400) Alex Deucher (2): drm/radeon: don't try to recreate sysfs entries on resume drm/amdgpu: don't try to recreate sysfs entries on resume Christian König (1): drm/amdgpu: stop leaking page flip fence drivers/gpu/drm/amd/amdgpu/amdgpu.h | 1 + drivers/gpu/drm/amd/amdgpu/amdgpu_display.c | 4 drivers/gpu/drm/amd/amdgpu/amdgpu_pm.c | 5 + drivers/gpu/drm/radeon/radeon.h | 1 + drivers/gpu/drm/radeon/radeon_pm.c | 35 + 5 files changed, 28 insertions(+), 18 deletions(-)
[PATCH 4/6] drm/vc4: Fix some failure to track __iomem decorations on pointers.
Ilia Mirkin writes:
> On Oct 23, 2015 6:32 AM, "Eric Anholt" wrote:
>>
>> Caught by the kbuild test robot.
>>
>> Signed-off-by: Eric Anholt
>> ---
>> drivers/gpu/drm/vc4/vc4_crtc.c | 3 ++-
>> drivers/gpu/drm/vc4/vc4_hvs.c | 8
>> 2 files changed, 6 insertions(+), 5 deletions(-)
>>
>> diff --git a/drivers/gpu/drm/vc4/vc4_crtc.c
> b/drivers/gpu/drm/vc4/vc4_crtc.c
>> index a3a77dd..32c0348 100644
>> --- a/drivers/gpu/drm/vc4/vc4_crtc.c
>> +++ b/drivers/gpu/drm/vc4/vc4_crtc.c
>> @@ -401,7 +401,8 @@ static void vc4_crtc_atomic_flush(struct drm_crtc
> *crtc,
>> dlist_next++;
>>
>> HVS_WRITE(SCALER_DISPLISTX(vc4_crtc->channel),
>> - (u32 *)vc4_crtc->dlist - (u32
> *)vc4->hvs->dlist);
>> + (u32 __iomem *)vc4_crtc->dlist -
>> + (u32 __iomem *)vc4->hvs->dlist);
>>
>> /* Make the next display list start after ours. */
>> vc4_crtc->dlist_size -= (dlist_next - vc4_crtc->dlist);
>> diff --git a/drivers/gpu/drm/vc4/vc4_hvs.c b/drivers/gpu/drm/vc4/vc4_hvs.c
>> index ab1673f..4d81d43 100644
>> --- a/drivers/gpu/drm/vc4/vc4_hvs.c
>> +++ b/drivers/gpu/drm/vc4/vc4_hvs.c
>> @@ -75,10 +75,10 @@ void vc4_hvs_dump_state(struct drm_device *dev)
>> for (i = 0; i < 64; i += 4) {
>> DRM_INFO("0x%08x (%s): 0x%08x 0x%08x 0x%08x 0x%08x\n",
>> i * 4, i < HVS_BOOTLOADER_DLIST_END ? "B" : "D",
>> -((uint32_t *)vc4->hvs->dlist)[i + 0],
>> -((uint32_t *)vc4->hvs->dlist)[i + 1],
>> -((uint32_t *)vc4->hvs->dlist)[i + 2],
>> -((uint32_t *)vc4->hvs->dlist)[i + 3]);
>> +readl((u32 __iomem *)vc4->hvs->dlist + 0),
>> +readl((u32 __iomem *)vc4->hvs->dlist + 1),
>> +readl((u32 __iomem *)vc4->hvs->dlist + 2),
>> + readl((u32 __iomem *)vc4->hvs->dlist + 3));
>
> Looks like you lost the +i here, no?
Indeed. Thanks!
-- next part --
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 818 bytes
Desc: not available
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20151023/cf15c1f0/attachment-0001.sig>
[PATCH 1/3] drm/amdgpu/dce8: optimize pageflip
Taking the grph update lock is only necessary when
updating the the secondary address (for single pipe stereo).
Reviewed-by: Christian König
Reviewed-by: Jammy Zhou
Signed-off-by: Alex Deucher
---
drivers/gpu/drm/amd/amdgpu/dce_v8_0.c | 38 +++
1 file changed, 7 insertions(+), 31 deletions(-)
diff --git a/drivers/gpu/drm/amd/amdgpu/dce_v8_0.c
b/drivers/gpu/drm/amd/amdgpu/dce_v8_0.c
index 00c34f8..b17abbe 100644
--- a/drivers/gpu/drm/amd/amdgpu/dce_v8_0.c
+++ b/drivers/gpu/drm/amd/amdgpu/dce_v8_0.c
@@ -211,46 +211,22 @@ static u32 dce_v8_0_vblank_get_counter(struct
amdgpu_device *adev, int crtc)
* @crtc_id: crtc to cleanup pageflip on
* @crtc_base: new address of the crtc (GPU MC address)
*
- * Does the actual pageflip (evergreen+).
- * During vblank we take the crtc lock and wait for the update_pending
- * bit to go high, when it does, we release the lock, and allow the
- * double buffered update to take place.
- * Returns the current update pending status.
+ * Triggers the actual pageflip by updating the primary
+ * surface base address.
*/
static void dce_v8_0_page_flip(struct amdgpu_device *adev,
int crtc_id, u64 crtc_base)
{
struct amdgpu_crtc *amdgpu_crtc = adev->mode_info.crtcs[crtc_id];
- u32 tmp = RREG32(mmGRPH_UPDATE + amdgpu_crtc->crtc_offset);
- int i;
-
- /* Lock the graphics update lock */
- tmp |= GRPH_UPDATE__GRPH_UPDATE_LOCK_MASK;
- WREG32(mmGRPH_UPDATE + amdgpu_crtc->crtc_offset, tmp);
-
- /* update the scanout addresses */
- WREG32(mmGRPH_SECONDARY_SURFACE_ADDRESS_HIGH + amdgpu_crtc->crtc_offset,
- upper_32_bits(crtc_base));
- WREG32(mmGRPH_SECONDARY_SURFACE_ADDRESS + amdgpu_crtc->crtc_offset,
- (u32)crtc_base);
+ /* update the primary scanout addresses */
WREG32(mmGRPH_PRIMARY_SURFACE_ADDRESS_HIGH + amdgpu_crtc->crtc_offset,
upper_32_bits(crtc_base));
+ /* writing to the low address triggers the update */
WREG32(mmGRPH_PRIMARY_SURFACE_ADDRESS + amdgpu_crtc->crtc_offset,
- (u32)crtc_base);
-
- /* Wait for update_pending to go high. */
- for (i = 0; i < adev->usec_timeout; i++) {
- if (RREG32(mmGRPH_UPDATE + amdgpu_crtc->crtc_offset) &
- GRPH_UPDATE__GRPH_SURFACE_UPDATE_PENDING_MASK)
- break;
- udelay(1);
- }
- DRM_DEBUG("Update pending now high. Unlocking vupdate_lock.\n");
-
- /* Unlock the lock, so double-buffering can take place inside vblank */
- tmp &= ~GRPH_UPDATE__GRPH_UPDATE_LOCK_MASK;
- WREG32(mmGRPH_UPDATE + amdgpu_crtc->crtc_offset, tmp);
+ lower_32_bits(crtc_base));
+ /* post the write */
+ RREG32(mmGRPH_PRIMARY_SURFACE_ADDRESS + amdgpu_crtc->crtc_offset);
}
static int dce_v8_0_crtc_get_scanoutpos(struct amdgpu_device *adev, int crtc,
--
1.8.3.1
[PATCH 2/3] drm/amdgpu/dce10: optimize pageflip
Taking the grph update lock is only necessary when
updating the the secondary address (for single pipe stereo).
Reviewed-by: Christian König
Reviewed-by: Jammy Zhou
Signed-off-by: Alex Deucher
---
drivers/gpu/drm/amd/amdgpu/dce_v10_0.c | 36 ++
1 file changed, 6 insertions(+), 30 deletions(-)
diff --git a/drivers/gpu/drm/amd/amdgpu/dce_v10_0.c
b/drivers/gpu/drm/amd/amdgpu/dce_v10_0.c
index a6ea2d8..6132051 100644
--- a/drivers/gpu/drm/amd/amdgpu/dce_v10_0.c
+++ b/drivers/gpu/drm/amd/amdgpu/dce_v10_0.c
@@ -262,46 +262,22 @@ static u32 dce_v10_0_vblank_get_counter(struct
amdgpu_device *adev, int crtc)
* @crtc_id: crtc to cleanup pageflip on
* @crtc_base: new address of the crtc (GPU MC address)
*
- * Does the actual pageflip (evergreen+).
- * During vblank we take the crtc lock and wait for the update_pending
- * bit to go high, when it does, we release the lock, and allow the
- * double buffered update to take place.
- * Returns the current update pending status.
+ * Triggers the actual pageflip by updating the primary
+ * surface base address.
*/
static void dce_v10_0_page_flip(struct amdgpu_device *adev,
int crtc_id, u64 crtc_base)
{
struct amdgpu_crtc *amdgpu_crtc = adev->mode_info.crtcs[crtc_id];
- u32 tmp = RREG32(mmGRPH_UPDATE + amdgpu_crtc->crtc_offset);
- int i;
-
- /* Lock the graphics update lock */
- tmp = REG_SET_FIELD(tmp, GRPH_UPDATE, GRPH_UPDATE_LOCK, 1);
- WREG32(mmGRPH_UPDATE + amdgpu_crtc->crtc_offset, tmp);
-
- /* update the scanout addresses */
- WREG32(mmGRPH_SECONDARY_SURFACE_ADDRESS_HIGH + amdgpu_crtc->crtc_offset,
- upper_32_bits(crtc_base));
- WREG32(mmGRPH_SECONDARY_SURFACE_ADDRESS + amdgpu_crtc->crtc_offset,
- lower_32_bits(crtc_base));
+ /* update the primary scanout address */
WREG32(mmGRPH_PRIMARY_SURFACE_ADDRESS_HIGH + amdgpu_crtc->crtc_offset,
upper_32_bits(crtc_base));
+ /* writing to the low address triggers the update */
WREG32(mmGRPH_PRIMARY_SURFACE_ADDRESS + amdgpu_crtc->crtc_offset,
lower_32_bits(crtc_base));
-
- /* Wait for update_pending to go high. */
- for (i = 0; i < adev->usec_timeout; i++) {
- if (RREG32(mmGRPH_UPDATE + amdgpu_crtc->crtc_offset) &
- GRPH_UPDATE__GRPH_SURFACE_UPDATE_PENDING_MASK)
- break;
- udelay(1);
- }
- DRM_DEBUG("Update pending now high. Unlocking vupdate_lock.\n");
-
- /* Unlock the lock, so double-buffering can take place inside vblank */
- tmp = REG_SET_FIELD(tmp, GRPH_UPDATE, GRPH_UPDATE_LOCK, 0);
- WREG32(mmGRPH_UPDATE + amdgpu_crtc->crtc_offset, tmp);
+ /* post the write */
+ RREG32(mmGRPH_PRIMARY_SURFACE_ADDRESS + amdgpu_crtc->crtc_offset);
}
static int dce_v10_0_crtc_get_scanoutpos(struct amdgpu_device *adev, int crtc,
--
1.8.3.1
[PATCH 3/3] drm/amdgpu/dce11: optimize pageflip
Taking the grph update lock is only necessary when
updating the the secondary address (for single pipe stereo).
Reviewed-by: Christian König
Reviewed-by: Jammy Zhou
Signed-off-by: Alex Deucher
---
drivers/gpu/drm/amd/amdgpu/dce_v11_0.c | 34 +-
1 file changed, 5 insertions(+), 29 deletions(-)
diff --git a/drivers/gpu/drm/amd/amdgpu/dce_v11_0.c
b/drivers/gpu/drm/amd/amdgpu/dce_v11_0.c
index 444d930..4898c46 100644
--- a/drivers/gpu/drm/amd/amdgpu/dce_v11_0.c
+++ b/drivers/gpu/drm/amd/amdgpu/dce_v11_0.c
@@ -252,46 +252,22 @@ static u32 dce_v11_0_vblank_get_counter(struct
amdgpu_device *adev, int crtc)
* @crtc_id: crtc to cleanup pageflip on
* @crtc_base: new address of the crtc (GPU MC address)
*
- * Does the actual pageflip (evergreen+).
- * During vblank we take the crtc lock and wait for the update_pending
- * bit to go high, when it does, we release the lock, and allow the
- * double buffered update to take place.
- * Returns the current update pending status.
+ * Triggers the actual pageflip by updating the primary
+ * surface base address.
*/
static void dce_v11_0_page_flip(struct amdgpu_device *adev,
int crtc_id, u64 crtc_base)
{
struct amdgpu_crtc *amdgpu_crtc = adev->mode_info.crtcs[crtc_id];
- u32 tmp = RREG32(mmGRPH_UPDATE + amdgpu_crtc->crtc_offset);
- int i;
-
- /* Lock the graphics update lock */
- tmp = REG_SET_FIELD(tmp, GRPH_UPDATE, GRPH_UPDATE_LOCK, 1);
- WREG32(mmGRPH_UPDATE + amdgpu_crtc->crtc_offset, tmp);
/* update the scanout addresses */
- WREG32(mmGRPH_SECONDARY_SURFACE_ADDRESS_HIGH + amdgpu_crtc->crtc_offset,
- upper_32_bits(crtc_base));
- WREG32(mmGRPH_SECONDARY_SURFACE_ADDRESS + amdgpu_crtc->crtc_offset,
- lower_32_bits(crtc_base));
-
WREG32(mmGRPH_PRIMARY_SURFACE_ADDRESS_HIGH + amdgpu_crtc->crtc_offset,
upper_32_bits(crtc_base));
+ /* writing to the low address triggers the update */
WREG32(mmGRPH_PRIMARY_SURFACE_ADDRESS + amdgpu_crtc->crtc_offset,
lower_32_bits(crtc_base));
-
- /* Wait for update_pending to go high. */
- for (i = 0; i < adev->usec_timeout; i++) {
- if (RREG32(mmGRPH_UPDATE + amdgpu_crtc->crtc_offset) &
- GRPH_UPDATE__GRPH_SURFACE_UPDATE_PENDING_MASK)
- break;
- udelay(1);
- }
- DRM_DEBUG("Update pending now high. Unlocking vupdate_lock.\n");
-
- /* Unlock the lock, so double-buffering can take place inside vblank */
- tmp = REG_SET_FIELD(tmp, GRPH_UPDATE, GRPH_UPDATE_LOCK, 0);
- WREG32(mmGRPH_UPDATE + amdgpu_crtc->crtc_offset, tmp);
+ /* post the write */
+ RREG32(mmGRPH_PRIMARY_SURFACE_ADDRESS + amdgpu_crtc->crtc_offset);
}
static int dce_v11_0_crtc_get_scanoutpos(struct amdgpu_device *adev, int crtc,
--
1.8.3.1
[PATCH] drm/radeon/dce4+: optimize pageflip
Taking the grph update lock is only necessary when
updating the the secondary address (for single pipe stereo).
Signed-off-by: Alex Deucher
---
drivers/gpu/drm/radeon/evergreen.c | 31 ---
1 file changed, 4 insertions(+), 27 deletions(-)
diff --git a/drivers/gpu/drm/radeon/evergreen.c
b/drivers/gpu/drm/radeon/evergreen.c
index 0acde19..511b8d6 100644
--- a/drivers/gpu/drm/radeon/evergreen.c
+++ b/drivers/gpu/drm/radeon/evergreen.c
@@ -1405,43 +1405,20 @@ void dce4_wait_for_vblank(struct radeon_device *rdev,
int crtc)
* @crtc_base: new address of the crtc (GPU MC address)
*
* Does the actual pageflip (evergreen+).
- * During vblank we take the crtc lock and wait for the update_pending
- * bit to go high, when it does, we release the lock, and allow the
- * double buffered update to take place.
- * Returns the current update pending status.
+ * Triggers the actual pageflip by updating the primary
+ * surface base address.
*/
void evergreen_page_flip(struct radeon_device *rdev, int crtc_id, u64
crtc_base)
{
struct radeon_crtc *radeon_crtc = rdev->mode_info.crtcs[crtc_id];
- u32 tmp = RREG32(EVERGREEN_GRPH_UPDATE + radeon_crtc->crtc_offset);
- int i;
-
- /* Lock the graphics update lock */
- tmp |= EVERGREEN_GRPH_UPDATE_LOCK;
- WREG32(EVERGREEN_GRPH_UPDATE + radeon_crtc->crtc_offset, tmp);
/* update the scanout addresses */
- WREG32(EVERGREEN_GRPH_SECONDARY_SURFACE_ADDRESS_HIGH +
radeon_crtc->crtc_offset,
- upper_32_bits(crtc_base));
- WREG32(EVERGREEN_GRPH_SECONDARY_SURFACE_ADDRESS +
radeon_crtc->crtc_offset,
- (u32)crtc_base);
-
WREG32(EVERGREEN_GRPH_PRIMARY_SURFACE_ADDRESS_HIGH +
radeon_crtc->crtc_offset,
upper_32_bits(crtc_base));
WREG32(EVERGREEN_GRPH_PRIMARY_SURFACE_ADDRESS +
radeon_crtc->crtc_offset,
(u32)crtc_base);
-
- /* Wait for update_pending to go high. */
- for (i = 0; i < rdev->usec_timeout; i++) {
- if (RREG32(EVERGREEN_GRPH_UPDATE + radeon_crtc->crtc_offset) &
EVERGREEN_GRPH_SURFACE_UPDATE_PENDING)
- break;
- udelay(1);
- }
- DRM_DEBUG("Update pending now high. Unlocking vupdate_lock.\n");
-
- /* Unlock the lock, so double-buffering can take place inside vblank */
- tmp &= ~EVERGREEN_GRPH_UPDATE_LOCK;
- WREG32(EVERGREEN_GRPH_UPDATE + radeon_crtc->crtc_offset, tmp);
+ /* post the write */
+ RREG32(EVERGREEN_GRPH_PRIMARY_SURFACE_ADDRESS +
radeon_crtc->crtc_offset);
}
/**
--
1.8.3.1
[PATCH 1/2] intel: Add SKL GT4 PCI IDs
Cc: Kristian Høgsberg Cc: Damien Lespiau Signed-off-by: Ben Widawsky --- intel/intel_chipset.h | 12 +++- 1 file changed, 11 insertions(+), 1 deletion(-) diff --git a/intel/intel_chipset.h b/intel/intel_chipset.h index 253ea71..6c8dc73 100644 --- a/intel/intel_chipset.h +++ b/intel/intel_chipset.h @@ -180,6 +180,10 @@ #define PCI_CHIP_SKYLAKE_SRV_GT3 0x192A #define PCI_CHIP_SKYLAKE_SRV_GT1 0x190A #define PCI_CHIP_SKYLAKE_WKS_GT2 0x191D +#define PCI_CHIP_SKYLAKE_DT_GT40x1932 +#define PCI_CHIP_SKYLAKE_SRV_GT4 0x193A +#define PCI_CHIP_SKYLAKE_H_GT4 0x193B +#define PCI_CHIP_SKYLAKE_WKS_GT4 0x193D #define PCI_CHIP_BROXTON_0 0x0A84 #define PCI_CHIP_BROXTON_1 0x1A84 @@ -362,9 +366,15 @@ (devid) == PCI_CHIP_SKYLAKE_HALO_GT3 || \ (devid) == PCI_CHIP_SKYLAKE_SRV_GT3) +#define IS_SKL_GT4(devid) ((devid) == PCI_CHIP_SKYLAKE_DT_GT4 || \ +(devid) == PCI_CHIP_SKYLAKE_SRV_GT4|| \ +(devid) == PCI_CHIP_SKYLAKE_H_GT4 || \ +(devid) == PCI_CHIP_SKYLAKE_WKS_GT4) + #define IS_SKYLAKE(devid) (IS_SKL_GT1(devid) || \ IS_SKL_GT2(devid) || \ -IS_SKL_GT3(devid)) +IS_SKL_GT3(devid) || \ +IS_SKL_GT4(devid)) #define IS_BROXTON(devid) ((devid) == PCI_CHIP_BROXTON_0 || \ (devid) == PCI_CHIP_BROXTON_1 || \ -- 2.6.1
[PATCH 2/2] intel: Cleanup SKL PCI ID definitions.
This removes ones which aren't used 0x190b, 192a), and adds some new ones. I kept the original names where possible. Cc: Kristian Høgsberg Cc: Damien Lespiau Signed-off-by: Ben Widawsky --- intel/intel_chipset.h | 46 ++ 1 file changed, 26 insertions(+), 20 deletions(-) diff --git a/intel/intel_chipset.h b/intel/intel_chipset.h index 6c8dc73..a0f17c6 100644 --- a/intel/intel_chipset.h +++ b/intel/intel_chipset.h @@ -165,21 +165,24 @@ #define PCI_CHIP_CHERRYVIEW_2 0x22b2 #define PCI_CHIP_CHERRYVIEW_3 0x22b3 -#define PCI_CHIP_SKYLAKE_ULT_GT2 0x1916 +#define PCI_CHIP_SKYLAKE_DT_GT10x1902 #define PCI_CHIP_SKYLAKE_ULT_GT1 0x1906 -#define PCI_CHIP_SKYLAKE_ULT_GT3 0x1926 -#define PCI_CHIP_SKYLAKE_ULT_GT2F 0x1921 -#define PCI_CHIP_SKYLAKE_ULX_GT1 0x190E -#define PCI_CHIP_SKYLAKE_ULX_GT2 0x191E +#define PCI_CHIP_SKYLAKE_SRV_GT1 0x190A /* Reserved */ +#define PCI_CHIP_SKYLAKE_ULX_GT1 0x190E /* Reserved */ #define PCI_CHIP_SKYLAKE_DT_GT20x1912 -#define PCI_CHIP_SKYLAKE_DT_GT10x1902 +#define PCI_CHIP_SKYLAKE_FUSED0_GT20x1913 /* Reserved */ +#define PCI_CHIP_SKYLAKE_FUSED1_GT20x1915 /* Reserved */ +#define PCI_CHIP_SKYLAKE_ULT_GT2 0x1916 +#define PCI_CHIP_SKYLAKE_FUSED2_GT20x1917 /* Reserved */ +#define PCI_CHIP_SKYLAKE_SRV_GT2 0x191A /* Reserved */ #define PCI_CHIP_SKYLAKE_HALO_GT2 0x191B -#define PCI_CHIP_SKYLAKE_HALO_GT3 0x192B -#define PCI_CHIP_SKYLAKE_HALO_GT1 0x190B -#define PCI_CHIP_SKYLAKE_SRV_GT2 0x191A -#define PCI_CHIP_SKYLAKE_SRV_GT3 0x192A -#define PCI_CHIP_SKYLAKE_SRV_GT1 0x190A #define PCI_CHIP_SKYLAKE_WKS_GT2 0x191D +#define PCI_CHIP_SKYLAKE_ULX_GT2 0x191E +#define PCI_CHIP_SKYLAKE_MOBILE_GT20x1921 /* Reserved */ +#define PCI_CHIP_SKYLAKE_GT3E_540 0x1923 +#define PCI_CHIP_SKYLAKE_GT3 0x1926 +#define PCI_CHIP_SKYLAKE_GT3E_550 0x1927 +#define PCI_CHIP_SKYLAKE_HALO_GT3 0x192B /* Reserved */ #define PCI_CHIP_SKYLAKE_DT_GT40x1932 #define PCI_CHIP_SKYLAKE_SRV_GT4 0x193A #define PCI_CHIP_SKYLAKE_H_GT4 0x193B @@ -351,20 +354,23 @@ #define IS_SKL_GT1(devid) ((devid) == PCI_CHIP_SKYLAKE_ULT_GT1|| \ (devid) == PCI_CHIP_SKYLAKE_ULX_GT1|| \ (devid) == PCI_CHIP_SKYLAKE_DT_GT1 || \ -(devid) == PCI_CHIP_SKYLAKE_HALO_GT1 || \ (devid) == PCI_CHIP_SKYLAKE_SRV_GT1) -#define IS_SKL_GT2(devid) ((devid) == PCI_CHIP_SKYLAKE_ULT_GT2|| \ -(devid) == PCI_CHIP_SKYLAKE_ULT_GT2F || \ -(devid) == PCI_CHIP_SKYLAKE_ULX_GT2|| \ -(devid) == PCI_CHIP_SKYLAKE_DT_GT2 || \ -(devid) == PCI_CHIP_SKYLAKE_HALO_GT2 || \ +#define IS_SKL_GT2(devid) ((devid) == PCI_CHIP_SKYLAKE_DT_GT2 || \ +(devid) == PCI_CHIP_SKYLAKE_FUSED0_GT2 || \ +(devid) == PCI_CHIP_SKYLAKE_FUSED1_GT2 || \ +(devid) == PCI_CHIP_SKYLAKE_ULT_GT2|| \ +(devid) == PCI_CHIP_SKYLAKE_FUSED2_GT2 || \ (devid) == PCI_CHIP_SKYLAKE_SRV_GT2|| \ -(devid) == PCI_CHIP_SKYLAKE_WKS_GT2) +(devid) == PCI_CHIP_SKYLAKE_HALO_GT2 || \ +(devid) == PCI_CHIP_SKYLAKE_WKS_GT2|| \ +(devid) == PCI_CHIP_SKYLAKE_ULX_GT2|| \ +(devid) == PCI_CHIP_SKYLAKE_MOBILE_GT2) -#define IS_SKL_GT3(devid) ((devid) == PCI_CHIP_SKYLAKE_ULT_GT3|| \ +#define IS_SKL_GT3(devid) ((devid) == PCI_CHIP_SKYLAKE_GT3|| \ (devid) == PCI_CHIP_SKYLAKE_HALO_GT3 || \ -(devid) == PCI_CHIP_SKYLAKE_SRV_GT3) +(devid) == PCI_CHIP_SKYLAKE_GT3E_540 || \ +(devid) == PCI_CHIP_SKYLAKE_GT3E_550) #define IS_SKL_GT4(devid) ((devid) == PCI_CHIP_SKYLAKE_DT_GT4 || \ (devid) == PCI_CHIP_SKYLAKE_SRV_GT4|| \ -- 2.6.1
[Bug 92214] Flightgear crashes during splashboot with R600 driver, LLVM 3.7.0 and mesa 11.0.2
https://bugs.freedesktop.org/show_bug.cgi?id=92214 Jose Fonseca changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #40 from Jose Fonseca --- I pushed the patch, and listed all the referred LLVM PRs in a comment for future reference. -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20151023/188eb5db/attachment.html>
[Bug 92428] Sword Coast Legends causing GPU lockup. radeon 0000:01:00.0: GPU lockup (current fence id 0x000000000000afd1 last fence id 0x000000000000b194 on ring 3)
https://bugs.freedesktop.org/show_bug.cgi?id=92428 --- Comment #3 from Francesco Biscani --- I am also experiencing a lockup with this game. In my case the lockup happens before I get to the main menu right after starting the game. I have a radeon r9 270x, and I am using the radeonsi driver (version 7.5.0), mesa 11.0.3, llvm 3.7.0, xorg server 1.17.2. The OS is Linux 4.2.2 64 bit. # glxinfo|grep -i opengl OpenGL vendor string: X.Org OpenGL renderer string: Gallium 0.4 on AMD PITCAIRN (DRM 2.43.0, LLVM 3.7.0) OpenGL core profile version string: 4.1 (Core Profile) Mesa 11.0.3 OpenGL core profile shading language version string: 4.10 OpenGL core profile context flags: (none) OpenGL core profile profile mask: core profile OpenGL core profile extensions: OpenGL version string: 3.0 Mesa 11.0.3 OpenGL shading language version string: 1.30 OpenGL context flags: (none) OpenGL extensions: OpenGL ES profile version string: OpenGL ES 3.0 Mesa 11.0.3 OpenGL ES profile shading language version string: OpenGL ES GLSL ES 3.00 # sudo lspci |grep -i vga 01:00.0 VGA compatible controller: Advanced Micro Devices, Inc. [AMD/ATI] Curacao XT [Radeon R7 370 / R9 270X/370 OEM] -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20151023/e50fcf15/attachment.html>
[alsa-devel] [PATCH 8/8] ASoC: AMD: add AMD ASoC ACP-I2S driver
On Fri, Oct 23, 2015 at 3:31 PM, Mark Brown wrote:
> On Sat, Oct 24, 2015 at 12:20:09AM +0530, maruthi srinivas wrote:
>> On Thu, Oct 22, 2015 at 9:44 PM, Mark Brown wrote:
>> > On Thu, Oct 08, 2015 at 12:12:40PM -0400, Alex Deucher wrote:
>
>> >> +/* ACP DMA irq handler routine for playback, capture usecases */
>> >> +int dma_irq_handler(struct device *dev)
>> >> +{
>> >> + u16 dscr_idx;
>> >> + u32 intr_flag;
>> >
>> > This says it's an interrupt handler but it's using some custom,
>> > non-genirq interface?
>
>> Irq handling is based on parent device's (part of other subsystem)
>> provided interfaces. I will coordinate with others for this.
>
>> Do you mean, using virtual irq assignment for MFD devices
>> (ACP is a MFD device) and registering irq handler for it ?
>
> Well, I'd expect that if we're exporting interrupts around the system
> we'd be doing so using genirq rather than open coding something.
I think the problem is, that in a lot of cases, it's not always
readily clear that there is an existing infrastructure to do
something. In this particular case, most of the common infrastructure
that should be utilized for this particular patch set comes from
non-traditional x86 platforms so most of us that come from a more
traditional x86 background as not as familiar with them. Searching
for information on how to solve these does not always produce
particularly useful results (e.g., genirq). So we end up open coding
a solution, not out of malice, but ignorance. If there is
infrastructure we should be using, please continue to point it out
during code review and we'll do our best to take advantage of it.
In the case of this hardware, audio interrupts are triggered on the
GPU. The GPU driver's interrupt handler checks the interrupt source
and calls the handler registered to handle that source. Until now the
ACP audio block was added, all the GPU interrupt sources were stuff
handled directly by the GPU driver (vblanks, display hotplug, command
submission fences, etc.).
Thanks,
Alex
>
>> >> + /* Let ACP know the Allocated memory */
>> >> + num_of_pages = PAGE_ALIGN(size) >> PAGE_SHIFT;
>> >> +
>> >> + /* Fill the page table entries in ACP SRAM */
>> >> + rtd->pg = pg;
>> >> + rtd->size = size;
>> >> + rtd->num_of_pages = num_of_pages;
>> >> + rtd->direction = substream->stream;
>
>> > We never reference num_of_pages other than to assign it into the page
>> > table entry?
>
>> Sorry, I didn't understand your comment.
>> I used 'num_of_pages' to configure ACP audio device for accessing system
>> memory. The implementation is in 'acp_pte_config' function in the patch.
>
> In the above code we have two blocks of code, one doing an assignment to
> a local variable and the other initialising the struct but the local
> variable in the first block is only ever referenced in the second block.
>
>> >> +static int acp_dma_close(struct snd_pcm_substream *substream)
>> >> +{
>> >> + struct snd_pcm_runtime *runtime = substream->runtime;
>> >> + struct audio_substream_data *rtd = runtime->private_data;
>> >> + struct snd_soc_pcm_runtime *prtd = substream->private_data;
>
>> >> + kfree(rtd);
>
>> >> + pm_runtime_mark_last_busy(prtd->platform->dev);
>
>> > Why the _mark_last_busy() here?
>
>> I want to power off ACP audio IP, when the audio usecase is not active for
>> sometime (run time PM). I felt, 'close' is the correct place to mark this.
>
> That's not what _mark_last_busy() does... the core already takes
> runtime PM references for you.
>
>> >> +static int acp_pcm_suspend(struct device *dev)
>> >> +{
>> >> + bool pm_rts;
>> >> + struct audio_drv_data *adata = dev_get_drvdata(dev);
>> >> +
>> >> + pm_rts = pm_runtime_status_suspended(dev);
>> >> + if (pm_rts == false)
>> >> + acp_suspend(adata->acp_mmio);
>> >> +
>> >> + return 0;
>> >> +}
>
>> > This appears to merely call into the parent/core device (at least it
>> > looks like this is the intention, there's a bunch of infrastructure fo
>> > the core device which appeaars to replicate standard infrastructure).
>> > Isn't whatever this eventually ends up doing handled by the parent
>> > device in the normal PM callbacks.
>
>> ACP device (child) can power off itself, when it receives suspend
>> request. So, the intention is to call 'acp_suspend' (defined in same patch)
>> from the 'suspend' callback of ACP device.
>
> This doesn't address why you're open coding this rather than using
> standard infrastructure.
>
>> >> + pm_rts = pm_runtime_status_suspended(dev);
>> >> + if (pm_rts == true) {
>> >> + /* Resumed from system wide suspend and there is
>> >> + * no pending audio activity to resume. */
>> >> + pm_runtime_disable(dev);
>> >> + pm_runtime_set_active(dev);
>> >> + pm_runtime_enable(dev);
>> >
>> > The above looks very strange - why are we
[pull] radeon and amdgpu drm-next-4.4
Hi Dave, More amdgpu and radeon stuff for drm-next. Stoney support is the big change. The rest is just bug fixes and code cleanups. The Stoney stuff is pretty low impact with respect to existing chips. The following changes since commit 2fcef6ec87a044221fc3c2f16873f7c02b9ae991: drm/amdgpu: fix lockup when clean pending fences (2015-10-14 16:20:32 -0400) are available in the git repository at: git://people.freedesktop.org/~agd5f/linux drm-next-4.4 for you to fetch changes up to ed885b210752563b5e90dc0933e262f768ea9fa4: drm/amdgpu: change VM size default to 64GB (2015-10-21 12:32:02 -0400) Alex Deucher (2): drm/amdgpu/gfx8: set TC_WB_ACTION_EN in RELEASE_MEM packet drm/amdgpu/dce: simplify suspend/resume Christian König (3): drm/amdgpu: remove old lockup detection infrastructure drm/amdgpu: remove the exclusive lock drm/amdgpu: change VM size default to 64GB Chunming Zhou (1): drm/amdgpu: fix the broken vm->mutex V2 Daniel Vetter (1): drm/radeon: Use rdev->gem.mutex to protect hyperz/cmask owners Geliang Tang (1): drm: fix trivial typos Junwei Zhang (1): drm/amdgpu: remove the unnecessary parameter adev for amdgpu_fence_wait_any() Samuel Li (10): drm/amdgpu: add Stoney chip family drm/amdgpu: add GMC support for Stoney drm/amdgpu: Update SMC/DPM for Stoney drm/amdgpu: add DCE support for Stoney drm/amdgpu: add SDMA support for Stoney (v2) drm/amdgpu: add GFX support for Stoney (v2) drm/amdgpu: add UVD support for Stoney drm/amdgpu: add VCE support for Stoney (v2) drm/amdgpu: update the core VI support for Stoney drm/amdgpu: add Stoney pci ids drivers/gpu/drm/amd/amdgpu/amdgpu.h | 11 +- drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c | 18 +- drivers/gpu/drm/amd/amdgpu/amdgpu_device.c | 14 +- drivers/gpu/drm/amd/amdgpu/amdgpu_display.c | 7 +- drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c | 6 +- drivers/gpu/drm/amd/amdgpu/amdgpu_fence.c | 50 +-- drivers/gpu/drm/amd/amdgpu/amdgpu_gem.c | 29 +- drivers/gpu/drm/amd/amdgpu/amdgpu_ib.c | 1 - drivers/gpu/drm/amd/amdgpu/amdgpu_ring.c| 43 --- drivers/gpu/drm/amd/amdgpu/amdgpu_sa.c | 2 +- drivers/gpu/drm/amd/amdgpu/amdgpu_uvd.c | 5 + drivers/gpu/drm/amd/amdgpu/amdgpu_vce.c | 5 + drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c | 35 +- drivers/gpu/drm/amd/amdgpu/cik_sdma.c | 19 -- drivers/gpu/drm/amd/amdgpu/cz_dpm.c | 21 +- drivers/gpu/drm/amd/amdgpu/cz_smc.c | 60 +++- drivers/gpu/drm/amd/amdgpu/dce_v10_0.c | 15 +- drivers/gpu/drm/amd/amdgpu/dce_v11_0.c | 36 ++- drivers/gpu/drm/amd/amdgpu/dce_v8_0.c | 15 +- drivers/gpu/drm/amd/amdgpu/gfx_v7_0.c | 20 -- drivers/gpu/drm/amd/amdgpu/gfx_v8_0.c | 412 ++-- drivers/gpu/drm/amd/amdgpu/gmc_v8_0.c | 12 + drivers/gpu/drm/amd/amdgpu/sdma_v2_4.c | 19 -- drivers/gpu/drm/amd/amdgpu/sdma_v3_0.c | 47 +-- drivers/gpu/drm/amd/amdgpu/uvd_v4_2.c | 1 - drivers/gpu/drm/amd/amdgpu/uvd_v5_0.c | 1 - drivers/gpu/drm/amd/amdgpu/uvd_v6_0.c | 1 - drivers/gpu/drm/amd/amdgpu/vce_v2_0.c | 1 - drivers/gpu/drm/amd/amdgpu/vce_v3_0.c | 6 +- drivers/gpu/drm/amd/amdgpu/vi.c | 36 ++- drivers/gpu/drm/amd/include/amd_shared.h| 1 + drivers/gpu/drm/amd/include/atombios.h | 2 +- drivers/gpu/drm/radeon/cayman_blit_shaders.c| 2 +- drivers/gpu/drm/radeon/evergreen_blit_shaders.c | 2 +- drivers/gpu/drm/radeon/r600_blit_shaders.c | 2 +- drivers/gpu/drm/radeon/radeon_kms.c | 10 +- include/uapi/drm/amdgpu_drm.h | 2 +- 37 files changed, 617 insertions(+), 352 deletions(-)
[PATCH 1/8] ASoC : dwc : add check for master/slave format
On Thu, Oct 22, 2015 at 10:56 AM, Mark Brown wrote: > On Thu, Oct 08, 2015 at 12:12:34PM -0400, Alex Deucher wrote: >> From: Maruthi Srinivas Bayyavarapu >> >> DW i2s controller's master/slave config can be read from a >> read-only register. Machine driver can try to set a master/slave >> format on cpu-dai using 'set_fmt' of dai ops. A check is added to >> verify codec is master when dwc is slave and vice-versa. >> >> Signed-off-by: Maruthi Bayyavarapu >> --- > > I can't apply this, you've not added a Signed-off-by for code sent by > someone else as covered in SubmittingPatches. > > Please also try to use subject lines matching the style for the > subsystem. I'll resend with these fixed up. Thanks. Alex
[RESEND PATCH 1/8] ASoC: dwc: add check for master/slave format
From: Maruthi Srinivas Bayyavarapu
DW i2s controller's master/slave config can be read from a
read-only register. Machine driver can try to set a master/slave
format on cpu-dai using 'set_fmt' of dai ops. A check is added to
verify codec is master when dwc is slave and vice-versa.
Signed-off-by: Maruthi Bayyavarapu
Signed-off-by: Alex Deucher
---
sound/soc/dwc/designware_i2s.c | 31 +++
1 file changed, 31 insertions(+)
diff --git a/sound/soc/dwc/designware_i2s.c b/sound/soc/dwc/designware_i2s.c
index 3a52f82..f427325 100644
--- a/sound/soc/dwc/designware_i2s.c
+++ b/sound/soc/dwc/designware_i2s.c
@@ -341,12 +341,43 @@ static int dw_i2s_trigger(struct snd_pcm_substream
*substream,
return ret;
}
+static int dw_i2s_set_fmt(struct snd_soc_dai *cpu_dai, unsigned int fmt)
+{
+ struct dw_i2s_dev *dev = snd_soc_dai_get_drvdata(cpu_dai);
+ int ret = 0;
+
+ switch (fmt & SND_SOC_DAIFMT_MASTER_MASK) {
+ case SND_SOC_DAIFMT_CBM_CFM:
+ if (dev->capability & DW_I2S_SLAVE)
+ ret = 0;
+ else
+ ret = -EINVAL;
+ break;
+ case SND_SOC_DAIFMT_CBS_CFS:
+ if (dev->capability & DW_I2S_MASTER)
+ ret = 0;
+ else
+ ret = -EINVAL;
+ break;
+ case SND_SOC_DAIFMT_CBM_CFS:
+ case SND_SOC_DAIFMT_CBS_CFM:
+ ret = -EINVAL;
+ break;
+ default:
+ dev_dbg(dev->dev, "dwc : Invalid master/slave format\n");
+ ret = -EINVAL;
+ break;
+ }
+ return ret;
+}
+
static struct snd_soc_dai_ops dw_i2s_dai_ops = {
.startup= dw_i2s_startup,
.shutdown = dw_i2s_shutdown,
.hw_params = dw_i2s_hw_params,
.prepare= dw_i2s_prepare,
.trigger= dw_i2s_trigger,
+ .set_fmt= dw_i2s_set_fmt,
};
static const struct snd_soc_component_driver dw_i2s_component = {
--
1.8.3.1
[PATCH v7 04/17] drm: bridge: analogix/dp: remove duplicate configuration of link rate and link count
link_rate and lane_count already configured in analogix_dp_set_link_train(),
so we don't need to config those repeatly after training finished, just
remove them out.
Beside Display Port 1.2 already support 5.4Gbps link rate, the maximum sets
would change from {1.62Gbps, 2.7Gbps} to {1.62Gbps, 2.7Gbps, 5.4Gbps}.
Tested-by: Javier Martinez Canillas
Signed-off-by: Yakir Yang
---
Changes in v7: None
Changes in v6: None
Changes in v5: None
Changes in v4:
- Update commit message more readable. (Jingoo)
- Adjust the order from 05 to 04
Changes in v3:
- The link_rate and lane_count shouldn't config to the DT property value
directly, but we can take those as hardware limite. For example, RK3288
only support 4 physical lanes of 2.7/1.62 Gbps/lane, so DT property would
like "link-rate = 0x0a" "lane-count = 4". (Thierry)
Changes in v2: None
drivers/gpu/drm/bridge/analogix/analogix_dp_core.c | 8
drivers/gpu/drm/bridge/analogix/analogix_dp_core.h | 5 +++--
2 files changed, 7 insertions(+), 6 deletions(-)
diff --git a/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c
b/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c
index 334181c..96afb67 100644
--- a/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c
+++ b/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c
@@ -624,6 +624,8 @@ static void analogix_dp_get_max_rx_bandwidth(struct
analogix_dp_device *dp,
/*
* For DP rev.1.1, Maximum link rate of Main Link lanes
* 0x06 = 1.62 Gbps, 0x0a = 2.7 Gbps
+* For DP rev.1.2, Maximum link rate of Main Link lanes
+* 0x06 = 1.62 Gbps, 0x0a = 2.7 Gbps, 0x14 = 5.4Gbps
*/
analogix_dp_read_byte_from_dpcd(dp, DP_MAX_LINK_RATE, &data);
*bandwidth = data;
@@ -657,7 +659,8 @@ static void analogix_dp_init_training(struct
analogix_dp_device *dp,
analogix_dp_get_max_rx_lane_count(dp, &dp->link_train.lane_count);
if ((dp->link_train.link_rate != LINK_RATE_1_62GBPS) &&
- (dp->link_train.link_rate != LINK_RATE_2_70GBPS)) {
+ (dp->link_train.link_rate != LINK_RATE_2_70GBPS) &&
+ (dp->link_train.link_rate != LINK_RATE_5_40GBPS)) {
dev_err(dp->dev, "Rx Max Link Rate is abnormal :%x !\n",
dp->link_train.link_rate);
dp->link_train.link_rate = LINK_RATE_1_62GBPS;
@@ -898,9 +901,6 @@ static void analogix_dp_commit(struct analogix_dp_device
*dp)
analogix_dp_enable_rx_to_enhanced_mode(dp, 1);
analogix_dp_enable_enhanced_mode(dp, 1);
- analogix_dp_set_lane_count(dp, dp->video_info->lane_count);
- analogix_dp_set_link_bandwidth(dp, dp->video_info->link_rate);
-
analogix_dp_init_video(dp);
ret = analogix_dp_config_video(dp);
if (ret)
diff --git a/drivers/gpu/drm/bridge/analogix/analogix_dp_core.h
b/drivers/gpu/drm/bridge/analogix/analogix_dp_core.h
index 14d20be..9a90a18 100644
--- a/drivers/gpu/drm/bridge/analogix/analogix_dp_core.h
+++ b/drivers/gpu/drm/bridge/analogix/analogix_dp_core.h
@@ -21,8 +21,9 @@
#define MAX_EQ_LOOP 5
enum link_rate_type {
- LINK_RATE_1_62GBPS = 0x06,
- LINK_RATE_2_70GBPS = 0x0a
+ LINK_RATE_1_62GBPS = DP_LINK_BW_1_62,
+ LINK_RATE_2_70GBPS = DP_LINK_BW_2_7,
+ LINK_RATE_5_40GBPS = DP_LINK_BW_5_4,
};
enum link_lane_count_type {
--
2.1.2
[PATCH v7 0/17] Add Analogix Core Display Port Driver
Hi all,
The Samsung Exynos eDP controller and Rockchip RK3288 eDP controller
share the same IP, so a lot of parts can be re-used. I split the common
code into bridge directory, then rk3288 and exynos only need to keep
some platform code. Cause I can't find the exact IP name of exynos dp
controller, so I decide to name dp core driver with "analogix" which I
find in rk3288 eDP TRM :)
But there are still three light registers setting differents bewteen
exynos and rk3288.
1. RK3288 have five special pll resigters which not indicata in exynos
dp controller.
2. The address of DP_PHY_PD(dp phy power manager register) are different
between rk3288 and exynos.
3. Rk3288 and exynos have different setting with AUX_HW_RETRY_CTL(dp debug
register).
This series have been well tested on Rockchip platform with eDP panel on
Jerry Chromebook and Display Port Monitor on RK3288 board. Also I have
tested on Samsung Snow and Peach Pit Chromebooks, and thanks to Javier at
Samsung
help to retest the whole series on Samsung Exynos5800 Peach Pi Chromebook,
glad to say that things works rightlly.
This series have been keep very quite about one month from v5 to v7 (thanks
to Krzysztof's reviewed and Javier's test and some comment Kishon during this
time), is there any chances to share some ackes from Exynos DRM maintainers
and Bridge maintainers?
Best regards,
- Yakir
Changes in v7:
- Back to use the of_property_read_bool() interfacs to provoid backward
compatibility of "hsync-active-high" "vsync-active-high" "interlaced"
to avoid -EOVERFLOW error (Krzysztof)
Changes in v6:
- Fix the wrong code in previous series, and test on Samsung snow Chromebook
successfully, here are the detail changes:
=>
- if (!dp->panel && !dp->bridge) {
+ if (!dp->panel && !dp->ptn_bridge) {
ret = exynos_dp_dt_parse_panel(dp);
if (ret)
=>
+ encoder->bridge = bridge;
bridge->driver_private = dp;
bridge->encoder = encoder;
bridge->funcs = &exynos_dp_bridge_funcs;
ret = drm_bridge_attach(drm_dev, bridge);
- Fix the Kconfig recursive dependency (Javier)
- Fix Peach Pit hpd property name error:
- hpd-gpio = <&gpx2 6 0>;
+ hpd-gpios = <&gpx2 6 0>;
- Simply the commit message. (Kishon)
- Symmetrical enable/disbale the phy clock and power. (Kishon)
Changes in v5:
- Correct the check condition of gpio_is_valid when driver try to get
the "hpd-gpios" DT propery. (Heiko)
- Move the platform attach callback in the front of core driver bridge
attch function. Cause once platform failed at attach, core driver should
still failed, so no need to init connector before platform attached
(Krzysztof)
- Keep code style no changes with the previous exynos_dp_code.c in this
patch, and update commit message about the new export symbol (Krzysztof)
- Gather the device type patch (v4 11/16) into this one. (Krzysztof)
- leave out the connector registration to analogix platform driver. (Thierry)
- Resequence this patch after analogix_dp driver have been split
from exynos_dp code, and rephrase reasonable commit message, and
remove some controversial style (Krzysztof)
- analogix_dp_write_byte_to_dpcd(
- dp, DP_TEST_RESPONSE,
+ analogix_dp_write_byte_to_dpcd(dp,
+ DP_TEST_RESPONSE,
DP_TEST_EDID_CHECKSUM_WRITE);
- Switch video timing type to "u32", so driver could use "of_property_read_u32"
to get the backword timing values. Krzysztof suggest me that driver could use
the "of_property_read_bool" to get backword timing values, but that interfacs
would modify the original drm_display_mode timing directly (whether those
properties exists or not).
- Correct the misspell in commit message. (Krzysztof)
- Remove the empty line at the end of document, and correct the endpoint
numbers in the example DT node, and remove the regulator iomux setting
in driver code while using the pinctl in devicetree instead. (Heiko)
- Add device type declared, cause the previous "platform device type
support (v4 11/16)" already merge into (v5 02/14).
- Implement connector registration code. (Thierry)
- Split binding doc's from driver changes. (Rob)
- Add eDP hotplug pinctrl property. (Heiko)
- Remove "reg" DT property, cause driver could poweron/poweroff phy via
the exist "grf" syscon already. And rename the example DT node from
"edp_phy: phy at ff770274" to "edp_phy: edp-phy" directly. (Heiko)
- Add deivce_node at the front of driver, update phy_ops type from "static
struct" to "static const struct". And correct the input paramters of
devm_phy_create() interfaces. (Heiko)
- Split binding doc's from driver changes. (Rob)
- Update the rockchip,grf explain in document, and correct the clock required
elemets in document. (Rob & Heiko)
- Fix compiled error (Heiko)
- Using the connector display info message to configure eDP drive
[GIT PULL] On-demand device probing
On 10/22/2015 11:53 AM, Frank Rowand wrote: > On 10/22/2015 7:44 AM, Greg Kroah-Hartman wrote: >> >> >> On Thu, Oct 22, 2015 at 11:05:11AM +0200, Tomeu Vizoso wrote: >>> But that's moot currently because Greg believes that the time spent >>> probing devices at boot time could be reduced enough so that the order >>> in which devices are probed becomes irrelevant. IME that would have to >>> be under 200ms so that the user doesn't notice and that's unicorn-far >>> from any bootlog I have ever seen. >> >> But as no one has actually produced a bootlog, how do you know that? >> Where exactly is your time being spent? What driver is causing long >> delays? Why is the long-delay-drivers not being done in their own >> thread? And most importantly, why are you ignoring the work that people >> did back in 2008 to solve the issue on other hardware platforms? >> >>> Given that downstreams are already carrying as many hacks as they >>> could think of to speed total boot up, I think this is effectively >>> telling them to go away. >> >> No I'm not, I'm asking for real data, not hand-wavy-this-is-going-to >> solve-the-random-issue-i'm-having type patch by putting random calls in >> semi-random subsystems all over the kernel. >> >> And when I ask for real data, you respond with the fact that you aren't >> trying to speed up boot time here at all, so what am I supposed to think > > I also had the understanding that this patch series was about improving > boot time. But I was kindly corrected that the behavior change was > getting the panel displaying stuff at an earlier point in the boot sequence, > _not_ completing the entire boot faster. > > The claim for the current series, in patch 0 in v7 is: > >With this series I get the kernel to output to the panel in 0.5s, >instead of 2.8s. It's very common to want to get the display up before the rest of the system. So wanting to accelerate one part of the boot at the expense to the rest of the system is a valid use case. Deferred initcalls, which is out of tree primarily because it requires the type of manual tweaking that Tomeu describes, specifically addressed this issue. > > Just to get side-tracked, one other approach at ordering to reduce > deferrals reported a modest boot time reduction for four boards and a > very slight boot time increase for one other board.) The report of boot > times with that approach was in: > > http://article.gmane.org/gmane.linux.drivers.devicetree/133010 > > from Alexander Holler. > > I have not searched further to see if there is more data of boot time > reductions from any of the other attempts to change driver binding > order to move dependencies before use of a resource. But whether > there is a performance improvement or not, there continues to be > a stream of developers creatively impacting the binding order for > their specific driver(s) or board. So it seems that maybe there > is an underlying problem, or we don't have adequate documentation > explaining how to avoid a need to order bindings, or the > documentation exists and is not being read. Well, I have probe order problems unrelated to boot time, that I solved by resorting to putting stuff into modules and loading them post-boot. So I'd be interested in easy solutions to managing boot order in mainline. > > I have been defaulting to the position that has been asserted by > the device tree maintainters, that probe deferrals work just fine > for at least the majority of cases (and is the message I have been > sharing in my conference presentations about device tree). But I > suspect that there is at least a small minority of cases that are not > well served by probe deferral. (Not to be read as an endorsement of > this specific patch series, just a generic observation.) I've been worried about DT overhead adding to boot time for a while. And IMHO probe deferral is just about the lamest way to solve boot order dependencies I can imagine, from a computer science perspective. (Well, there's a certain elegance to it, but it's a stupid "make everything re-doable, back up and start over, time-wasting" elegance.) However, when Android takes 35 seconds to boot, and most people almost never cold-boot your product, a few seconds of kernel time-wasting on cold-boot seem less important. Alas, when I started working on mobile phones I stopped caring much about boot time. Thus, I've never worried about the DT overhead enough to actually measure it, as requested by Greg. So I'll just shut up now. :-) -- Tim
[PATCH v7 01/17] drm: exynos: dp: convert to drm bridge mode
In order to move exynos dp code to bridge directory,
we need to convert driver drm bridge mode first. As
dp driver already have a ptn3460 bridge, so we need
to move ptn bridge to the next bridge of dp bridge.
Tested-by: Javier Martinez Canillas
Signed-off-by: Yakir Yang
---
Changes in v7: None
Changes in v6:
- Fix the wrong code in previous series, and test on Samsung snow Chromebook
successfully, here are the detail changes:
=>
- if (!dp->panel && !dp->bridge) {
+ if (!dp->panel && !dp->ptn_bridge) {
ret = exynos_dp_dt_parse_panel(dp);
if (ret)
=>
+ encoder->bridge = bridge;
bridge->driver_private = dp;
bridge->encoder = encoder;
bridge->funcs = &exynos_dp_bridge_funcs;
ret = drm_bridge_attach(drm_dev, bridge);
Changes in v5: None
Changes in v4: None
Changes in v3: None
Changes in v2:
- Keep author name list no changed (Jingoo)
drivers/gpu/drm/exynos/exynos_dp_core.c | 103
drivers/gpu/drm/exynos/exynos_dp_core.h | 1 +
2 files changed, 78 insertions(+), 26 deletions(-)
diff --git a/drivers/gpu/drm/exynos/exynos_dp_core.c
b/drivers/gpu/drm/exynos/exynos_dp_core.c
index 124fb9a..aedd074 100644
--- a/drivers/gpu/drm/exynos/exynos_dp_core.c
+++ b/drivers/gpu/drm/exynos/exynos_dp_core.c
@@ -1009,9 +1009,9 @@ static int exynos_drm_attach_lcd_bridge(struct
exynos_dp_device *dp,
{
int ret;
- encoder->bridge = dp->bridge;
- dp->bridge->encoder = encoder;
- ret = drm_bridge_attach(encoder->dev, dp->bridge);
+ encoder->bridge->next = dp->ptn_bridge;
+ dp->ptn_bridge->encoder = encoder;
+ ret = drm_bridge_attach(encoder->dev, dp->ptn_bridge);
if (ret) {
DRM_ERROR("Failed to attach bridge to drm\n");
return ret;
@@ -1020,14 +1020,15 @@ static int exynos_drm_attach_lcd_bridge(struct
exynos_dp_device *dp,
return 0;
}
-static int exynos_dp_create_connector(struct drm_encoder *encoder)
+static int exynos_dp_bridge_attach(struct drm_bridge *bridge)
{
- struct exynos_dp_device *dp = encoder_to_dp(encoder);
+ struct exynos_dp_device *dp = bridge->driver_private;
+ struct drm_encoder *encoder = &dp->encoder;
struct drm_connector *connector = &dp->connector;
int ret;
/* Pre-empt DP connector creation if there's a bridge */
- if (dp->bridge) {
+ if (dp->ptn_bridge) {
ret = exynos_drm_attach_lcd_bridge(dp, encoder);
if (!ret)
return 0;
@@ -1052,22 +1053,9 @@ static int exynos_dp_create_connector(struct drm_encoder
*encoder)
return ret;
}
-static bool exynos_dp_mode_fixup(struct drm_encoder *encoder,
-const struct drm_display_mode *mode,
-struct drm_display_mode *adjusted_mode)
-{
- return true;
-}
-
-static void exynos_dp_mode_set(struct drm_encoder *encoder,
- struct drm_display_mode *mode,
- struct drm_display_mode *adjusted_mode)
-{
-}
-
-static void exynos_dp_enable(struct drm_encoder *encoder)
+static void exynos_dp_bridge_enable(struct drm_bridge *bridge)
{
- struct exynos_dp_device *dp = encoder_to_dp(encoder);
+ struct exynos_dp_device *dp = bridge->driver_private;
struct exynos_drm_crtc *crtc = dp_to_crtc(dp);
if (dp->dpms_mode == DRM_MODE_DPMS_ON)
@@ -1092,9 +1080,9 @@ static void exynos_dp_enable(struct drm_encoder *encoder)
dp->dpms_mode = DRM_MODE_DPMS_ON;
}
-static void exynos_dp_disable(struct drm_encoder *encoder)
+static void exynos_dp_bridge_disable(struct drm_bridge *bridge)
{
- struct exynos_dp_device *dp = encoder_to_dp(encoder);
+ struct exynos_dp_device *dp = bridge->driver_private;
struct exynos_drm_crtc *crtc = dp_to_crtc(dp);
if (dp->dpms_mode != DRM_MODE_DPMS_ON)
@@ -1123,6 +,69 @@ static void exynos_dp_disable(struct drm_encoder
*encoder)
dp->dpms_mode = DRM_MODE_DPMS_OFF;
}
+static void exynos_dp_bridge_nop(struct drm_bridge *bridge)
+{
+ /* do nothing */
+}
+
+static const struct drm_bridge_funcs exynos_dp_bridge_funcs = {
+ .enable = exynos_dp_bridge_enable,
+ .disable = exynos_dp_bridge_disable,
+ .pre_enable = exynos_dp_bridge_nop,
+ .post_disable = exynos_dp_bridge_nop,
+ .attach = exynos_dp_bridge_attach,
+};
+
+static int exynos_dp_create_connector(struct drm_encoder *encoder)
+{
+ struct exynos_dp_device *dp = encoder_to_dp(encoder);
+ struct drm_device *drm_dev = dp->drm_dev;
+ struct drm_bridge *bridge;
+ int ret;
+
+ bridge = devm_kzalloc(drm_dev->dev, sizeof(*bridge), GFP_KERNEL);
+ if (!bridge) {
+ DRM_ERROR("failed to allocate for drm bridge\n");
+ return -ENOMEM;
+ }
+
+ dp->bridge = bridge;
+
+
[PATCH v7 02/17] drm: bridge: analogix/dp: split exynos dp driver to bridge directory
Split the dp core driver from exynos directory to bridge directory,
and rename the core driver to analogix_dp_*, rename the platform
code to exynos_dp.
Beside the new analogix_dp driver would export four hooks.
"analogix_dp_bind()" and "analogix_dp_unbind()"
"analogix_dp_detect()" and "analogix_dp_get_modes()"
The bind/unbind symbols is used for analogix platform driver to connect
with analogix_dp core driver. And the detect/get_modes is used for analogix
platform driver to init the connector.
They reason why connector need register in helper driver is rockchip drm
haven't implement the atomic API, but Exynos drm have implement it, so
there would need two different connector helper functions, that's why we
leave the connector register in helper driver.
Tested-by: Javier Martinez Canillas
Signed-off-by: Yakir Yang
---
Changes in v7: None
Changes in v6:
- Fix the Kconfig recursive dependency (Javier)
Changes in v5:
- Correct the check condition of gpio_is_valid when driver try to get
the "hpd-gpios" DT propery. (Heiko)
- Move the platform attach callback in the front of core driver bridge
attch function. Cause once platform failed at attach, core driver should
still failed, so no need to init connector before platform attached
(Krzysztof)
- Keep code style no changes with the previous exynos_dp_code.c in this
patch, and update commit message about the new export symbol (Krzysztof)
- Gather the device type patch (v4 11/16) into this one. (Krzysztof)
- leave out the connector registration to analogix platform driver. (Thierry)
Changes in v4:
- Update "analogix,hpd-gpios" to "hpd-gpios" DT propery. (Rob)
- Rename "analogix_dp-exynos.c" file name to "exynos_dp.c" (Jingoo)
- Create a separate folder for analogix code in bridge/ (Archit)
Changes in v3:
- Move exynos's video_timing code to analogix_dp-exynos platform driver,
add get_modes method to struct analogix_dp_plat_data. (Thierry)
- Rename some "samsung*" dts propery to "analogix*". (Heiko)
Changes in v2:
- Remove new copyright (Jingoo)
- Fix compiled failed due to analogix_dp_device misspell
drivers/gpu/drm/bridge/Kconfig |2 +
drivers/gpu/drm/bridge/Makefile|1 +
drivers/gpu/drm/bridge/analogix/Kconfig|3 +
drivers/gpu/drm/bridge/analogix/Makefile |1 +
.../analogix/analogix_dp_core.c} | 753 +---
drivers/gpu/drm/bridge/analogix/analogix_dp_core.h | 277 +
drivers/gpu/drm/bridge/analogix/analogix_dp_reg.c | 1263
.../analogix/analogix_dp_reg.h}| 258 ++--
drivers/gpu/drm/exynos/Kconfig |3 +-
drivers/gpu/drm/exynos/Makefile|2 +-
drivers/gpu/drm/exynos/exynos_dp.c | 349 ++
drivers/gpu/drm/exynos/exynos_dp_core.h| 282 -
drivers/gpu/drm/exynos/exynos_dp_reg.c | 1263
include/drm/bridge/analogix_dp.h | 41 +
14 files changed, 2365 insertions(+), 2133 deletions(-)
create mode 100644 drivers/gpu/drm/bridge/analogix/Kconfig
create mode 100644 drivers/gpu/drm/bridge/analogix/Makefile
rename drivers/gpu/drm/{exynos/exynos_dp_core.c =>
bridge/analogix/analogix_dp_core.c} (51%)
create mode 100644 drivers/gpu/drm/bridge/analogix/analogix_dp_core.h
create mode 100644 drivers/gpu/drm/bridge/analogix/analogix_dp_reg.c
rename drivers/gpu/drm/{exynos/exynos_dp_reg.h =>
bridge/analogix/analogix_dp_reg.h} (64%)
create mode 100644 drivers/gpu/drm/exynos/exynos_dp.c
delete mode 100644 drivers/gpu/drm/exynos/exynos_dp_core.h
delete mode 100644 drivers/gpu/drm/exynos/exynos_dp_reg.c
create mode 100644 include/drm/bridge/analogix_dp.h
diff --git a/drivers/gpu/drm/bridge/Kconfig b/drivers/gpu/drm/bridge/Kconfig
index 639..ece8ff5 100644
--- a/drivers/gpu/drm/bridge/Kconfig
+++ b/drivers/gpu/drm/bridge/Kconfig
@@ -41,4 +41,6 @@ config DRM_PARADE_PS8622
---help---
Parade eDP-LVDS bridge chip driver.
+source "drivers/gpu/drm/bridge/analogix/Kconfig"
+
endmenu
diff --git a/drivers/gpu/drm/bridge/Makefile b/drivers/gpu/drm/bridge/Makefile
index d4e28be..8039c59 100644
--- a/drivers/gpu/drm/bridge/Makefile
+++ b/drivers/gpu/drm/bridge/Makefile
@@ -4,3 +4,4 @@ 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_ANALOGIX_DP) += analogix/
diff --git a/drivers/gpu/drm/bridge/analogix/Kconfig
b/drivers/gpu/drm/bridge/analogix/Kconfig
new file mode 100644
index 000..80f286f
--- /dev/null
+++ b/drivers/gpu/drm/bridge/analogix/Kconfig
@@ -0,0 +1,3 @@
+config DRM_ANALOGIX_DP
+ tristate
+ depends on DRM
diff --git a/drivers/gpu/drm/bridge/analogix/Makefile
b/drivers/gpu/drm/bridge/analogix/Makefile
new file mode 100644
index 000..9107b86
--- /dev/null
+++ b/drivers
[GIT PULL] On-demand device probing
On 10/22/2015 09:26 PM, Greg Kroah-Hartman wrote: > On Thu, Oct 22, 2015 at 11:53:31AM -0700, Frank Rowand wrote: >> On 10/22/2015 7:44 AM, Greg Kroah-Hartman wrote: >>> >>> >>> On Thu, Oct 22, 2015 at 11:05:11AM +0200, Tomeu Vizoso wrote: But that's moot currently because Greg believes that the time spent probing devices at boot time could be reduced enough so that the order in which devices are probed becomes irrelevant. IME that would have to be under 200ms so that the user doesn't notice and that's unicorn-far from any bootlog I have ever seen. >>> >>> But as no one has actually produced a bootlog, how do you know that? >>> Where exactly is your time being spent? What driver is causing long >>> delays? Why is the long-delay-drivers not being done in their own >>> thread? And most importantly, why are you ignoring the work that people >>> did back in 2008 to solve the issue on other hardware platforms? >>> Given that downstreams are already carrying as many hacks as they could think of to speed total boot up, I think this is effectively telling them to go away. >>> >>> No I'm not, I'm asking for real data, not hand-wavy-this-is-going-to >>> solve-the-random-issue-i'm-having type patch by putting random calls in >>> semi-random subsystems all over the kernel. >>> >>> And when I ask for real data, you respond with the fact that you aren't >>> trying to speed up boot time here at all, so what am I supposed to think >> >> I also had the understanding that this patch series was about improving >> boot time. But I was kindly corrected that the behavior change was >> getting the panel displaying stuff at an earlier point in the boot sequence, >> _not_ completing the entire boot faster. >> >> The claim for the current series, in patch 0 in v7 is: >> >>With this series I get the kernel to output to the panel in 0.5s, >>instead of 2.8s. >> >> Just to get side-tracked, one other approach at ordering to reduce >> deferrals reported a modest boot time reduction for four boards and a >> very slight boot time increase for one other board.) The report of boot >> times with that approach was in: >> >> http://article.gmane.org/gmane.linux.drivers.devicetree/133010 >> >> from Alexander Holler. >> >> I have not searched further to see if there is more data of boot time >> reductions from any of the other attempts to change driver binding >> order to move dependencies before use of a resource. But whether >> there is a performance improvement or not, there continues to be >> a stream of developers creatively impacting the binding order for >> their specific driver(s) or board. So it seems that maybe there >> is an underlying problem, or we don't have adequate documentation >> explaining how to avoid a need to order bindings, or the >> documentation exists and is not being read. >> >> I have been defaulting to the position that has been asserted by >> the device tree maintainters, that probe deferrals work just fine >> for at least the majority of cases (and is the message I have been >> sharing in my conference presentations about device tree). But I >> suspect that there is at least a small minority of cases that are not >> well served by probe deferral. (Not to be read as an endorsement of >> this specific patch series, just a generic observation.) > > I agree, there might be some small numbers that this is a problem for, > and if so, great, show us the boot logs where things are taking up all > of the time, and we can work on resolving those issues. > > But without hard numbers / details, this all is just random hand-waving, > and I don't like making core kernel changes on that basis. And no one > else should ever want us to do that either. Hi, have found the board in which Stéphane had the original issue on (exynos5250-snow), and I'm attaching the bootlog of next-20151013+exynos_defconfig with initcall_debug and DEBUG in dd.c. As can be seen, 145b.dp-controller is tried reasonably early (at 0.25s), but is deferred and only retried at 0.9s, with the display finally coming up at 1.35s. But I'm not sure what's the point in discussing this further if you have already said that it's fine if downstreams have to change the probing order by moving files around in the makefiles and by fiddling with initcall levels. To give a better understanding of what's going on here, I wasn't involved in the bringup of this board, but was tasked with fixing this issue in mainline so it doesn't have to be worked around in every product. Regards, Tomeu > thanks, > > greg k-h > -- next part -- [0.00] Booting Linux on physical CPU 0x0 [0.00] Linux version 4.3.0-rc5-next-20151013-dirty (tomeu at cizrna) (gcc version 5.2.1 20150716 (Red Hat Cross 5.2.1-3) (GCC) ) #3491 SMP PREEMPT Fri Oct 23 11:17:16 CEST 2015 [0.00] CPU: ARMv7 Processor [410fc0f4] revision 4 (ARMv7), cr=10c5387d [0.00] CPU: PIPT / VIPT nonaliasin
[GIT PULL] On-demand device probing
On Fri, Oct 23, 2015 at 10:45 AM, Tim Bird wrote: > On 10/22/2015 11:53 AM, Frank Rowand wrote: >> On 10/22/2015 7:44 AM, Greg Kroah-Hartman wrote: >>> >>> >>> On Thu, Oct 22, 2015 at 11:05:11AM +0200, Tomeu Vizoso wrote: But that's moot currently because Greg believes that the time spent probing devices at boot time could be reduced enough so that the order in which devices are probed becomes irrelevant. IME that would have to be under 200ms so that the user doesn't notice and that's unicorn-far from any bootlog I have ever seen. >>> >>> But as no one has actually produced a bootlog, how do you know that? >>> Where exactly is your time being spent? What driver is causing long >>> delays? Why is the long-delay-drivers not being done in their own >>> thread? And most importantly, why are you ignoring the work that people >>> did back in 2008 to solve the issue on other hardware platforms? >>> Given that downstreams are already carrying as many hacks as they could think of to speed total boot up, I think this is effectively telling them to go away. >>> >>> No I'm not, I'm asking for real data, not hand-wavy-this-is-going-to >>> solve-the-random-issue-i'm-having type patch by putting random calls in >>> semi-random subsystems all over the kernel. >>> >>> And when I ask for real data, you respond with the fact that you aren't >>> trying to speed up boot time here at all, so what am I supposed to think >> >> I also had the understanding that this patch series was about improving >> boot time. But I was kindly corrected that the behavior change was >> getting the panel displaying stuff at an earlier point in the boot sequence, >> _not_ completing the entire boot faster. >> >> The claim for the current series, in patch 0 in v7 is: >> >>With this series I get the kernel to output to the panel in 0.5s, >>instead of 2.8s. > > It's very common to want to get the display up before the > rest of the system. So wanting to accelerate one part of the boot > at the expense to the rest of the system is a valid use case. > Deferred initcalls, which is out of tree primarily because it requires > the type of manual tweaking that Tomeu describes, specifically > addressed this issue. Agreed and other folks will want other things up first. But it seems we are getting lucky with link order with the speed ups in this case. We need a way to specify priority of probing devices. If we have that piece, then all this plumbing can be used. A simple solution would be looking at stdout-path to get the console device to probe. That would be trivial to add on top of this. That may work for the display too, but you may not want the console on the display. That wouldn't work for CAN bus either, but then I'm not sure there is a generic solution for its requirements (respond within 50ms IIRC). >> Just to get side-tracked, one other approach at ordering to reduce >> deferrals reported a modest boot time reduction for four boards and a >> very slight boot time increase for one other board.) The report of boot >> times with that approach was in: >> >> http://article.gmane.org/gmane.linux.drivers.devicetree/133010 >> >> from Alexander Holler. >> >> I have not searched further to see if there is more data of boot time >> reductions from any of the other attempts to change driver binding >> order to move dependencies before use of a resource. But whether >> there is a performance improvement or not, there continues to be >> a stream of developers creatively impacting the binding order for >> their specific driver(s) or board. So it seems that maybe there >> is an underlying problem, or we don't have adequate documentation >> explaining how to avoid a need to order bindings, or the >> documentation exists and is not being read. > > Well, I have probe order problems unrelated to boot time, that > I solved by resorting to putting stuff into modules and loading > them post-boot. So I'd be interested in easy solutions to managing > boot order in mainline. I take it that this series doesn't help those problems? >> I have been defaulting to the position that has been asserted by >> the device tree maintainters, that probe deferrals work just fine >> for at least the majority of cases (and is the message I have been >> sharing in my conference presentations about device tree). But I >> suspect that there is at least a small minority of cases that are not >> well served by probe deferral. (Not to be read as an endorsement of >> this specific patch series, just a generic observation.) > > I've been worried about DT overhead adding to boot time for a while. Always beating up DT... ;) Yes, I'm sure there is some overhead, but looking at bootgraph there's much longer items not related to DT (USB, MMC and anything over I2C seem to be typical). With DT we lost most control of the order, and at the same time we added a load of new subsystems that are dependencies. > And IMHO probe deferral is just ab
[PATCH v7 03/17] drm: bridge: analogix/dp: fix some obvious code style
Fix some obvious alignment problems, like alignment and line
over 80 characters problems, make this easy to be maintained
later.
Reviewed-by: Krzysztof Kozlowski
Tested-by: Javier Martinez Canillas
Signed-off-by: Yakir Yang
---
Changes in v7: None
Changes in v6: None
Changes in v5:
- Resequence this patch after analogix_dp driver have been split
from exynos_dp code, and rephrase reasonable commit message, and
remove some controversial style (Krzysztof)
- analogix_dp_write_byte_to_dpcd(
- dp, DP_TEST_RESPONSE,
+ analogix_dp_write_byte_to_dpcd(dp,
+ DP_TEST_RESPONSE,
DP_TEST_EDID_CHECKSUM_WRITE);
Changes in v4: None
Changes in v3: None
Changes in v2:
- Improved commit message more readable, and avoid using some
uncommon style like bellow: (Joe Preches)
- retval = exynos_dp_read_bytes_from_i2c(...
...);
+ retval =
+ exynos_dp_read_bytes_from_i2c(..);
drivers/gpu/drm/bridge/analogix/analogix_dp_core.c | 129 ++---
drivers/gpu/drm/bridge/analogix/analogix_dp_core.h | 72 ++--
drivers/gpu/drm/bridge/analogix/analogix_dp_reg.c | 124 ++--
3 files changed, 163 insertions(+), 162 deletions(-)
diff --git a/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c
b/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c
index e561590..334181c 100644
--- a/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c
+++ b/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c
@@ -61,7 +61,7 @@ static int analogix_dp_detect_hpd(struct analogix_dp_device
*dp)
while (analogix_dp_get_plug_in_status(dp) != 0) {
timeout_loop++;
- if (DP_TIMEOUT_LOOP_COUNT < timeout_loop) {
+ if (timeout_loop > DP_TIMEOUT_LOOP_COUNT) {
dev_err(dp->dev, "failed to get hpd plug status\n");
return -ETIMEDOUT;
}
@@ -98,8 +98,8 @@ static int analogix_dp_read_edid(struct analogix_dp_device
*dp)
/* Read Extension Flag, Number of 128-byte EDID extension blocks */
retval = analogix_dp_read_byte_from_i2c(dp, I2C_EDID_DEVICE_ADDR,
- EDID_EXTENSION_FLAG,
- &extend_block);
+ EDID_EXTENSION_FLAG,
+ &extend_block);
if (retval)
return retval;
@@ -107,7 +107,8 @@ static int analogix_dp_read_edid(struct analogix_dp_device
*dp)
dev_dbg(dp->dev, "EDID data includes a single extension!\n");
/* Read EDID data */
- retval = analogix_dp_read_bytes_from_i2c(dp,
I2C_EDID_DEVICE_ADDR,
+ retval = analogix_dp_read_bytes_from_i2c(dp,
+ I2C_EDID_DEVICE_ADDR,
EDID_HEADER_PATTERN,
EDID_BLOCK_LENGTH,
&edid[EDID_HEADER_PATTERN]);
@@ -138,7 +139,7 @@ static int analogix_dp_read_edid(struct analogix_dp_device
*dp)
}
analogix_dp_read_byte_from_dpcd(dp, DP_TEST_REQUEST,
- &test_vector);
+ &test_vector);
if (test_vector & DP_TEST_LINK_EDID_READ) {
analogix_dp_write_byte_to_dpcd(dp,
DP_TEST_EDID_CHECKSUM,
@@ -152,10 +153,8 @@ static int analogix_dp_read_edid(struct analogix_dp_device
*dp)
/* Read EDID data */
retval = analogix_dp_read_bytes_from_i2c(dp,
- I2C_EDID_DEVICE_ADDR,
- EDID_HEADER_PATTERN,
- EDID_BLOCK_LENGTH,
- &edid[EDID_HEADER_PATTERN]);
+ I2C_EDID_DEVICE_ADDR, EDID_HEADER_PATTERN,
+ EDID_BLOCK_LENGTH, &edid[EDID_HEADER_PATTERN]);
if (retval != 0) {
dev_err(dp->dev, "EDID Read failed!\n");
return -EIO;
@@ -166,16 +165,13 @@ static int analogix_dp_read_edid(struct
analogix_dp_device *dp)
return -EIO;
}
- analogix_dp_read_byte_from_dpcd(dp,
- DP_TEST_REQUEST,
- &test_vector);
+ analogix_dp_read_byte_from_dpcd(dp, DP_TEST_REQUEST,
+ &test_vector);
if (test_vector & DP_TEST_LINK_EDID_READ) {
analogix_dp_write_byte_to_dpcd(dp,
- DP_TEST_EDID_CHECKSUM,
- edid[EDID_CHECKSUM]);
+
[PATCH v7 05/17] drm: bridge: analogix/dp: dynamic parse sync_pol & interlace & dynamic_range
Both hsync/vsync polarity and interlace mode can be parsed from
drm display mode, and dynamic_range and ycbcr_coeff can be judge
by the video code.
But presumably Exynos still relies on the DT properties, so take
good use of mode_fixup() in to achieve the compatibility hacks.
Reviewed-by: Krzysztof Kozlowski
Tested-by: Javier Martinez Canillas
Signed-off-by: Yakir Yang
---
Changes in v7:
- Back to use the of_property_read_bool() interfacs to provoid backward
compatibility of "hsync-active-high" "vsync-active-high" "interlaced"
to avoid -EOVERFLOW error (Krzysztof)
Changes in v6: None
Changes in v5:
- Switch video timing type to "u32", so driver could use "of_property_read_u32"
to get the backword timing values. Krzysztof suggest me that driver could use
the "of_property_read_bool" to get backword timing values, but that interfacs
would modify the original drm_display_mode timing directly (whether those
properties exists or not).
Changes in v4:
- Provide backword compatibility with samsung. (Krzysztof)
Changes in v3:
- Dynamic parse video timing info from struct drm_display_mode and
struct drm_display_info. (Thierry)
Changes in v2: None
drivers/gpu/drm/bridge/analogix/analogix_dp_core.c | 148 +
drivers/gpu/drm/bridge/analogix/analogix_dp_core.h | 2 +-
drivers/gpu/drm/bridge/analogix/analogix_dp_reg.c | 14 +-
3 files changed, 103 insertions(+), 61 deletions(-)
diff --git a/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c
b/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c
index 96afb67..6307060 100644
--- a/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c
+++ b/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c
@@ -890,8 +890,8 @@ static void analogix_dp_commit(struct analogix_dp_device
*dp)
return;
}
- ret = analogix_dp_set_link_train(dp, dp->video_info->lane_count,
-dp->video_info->link_rate);
+ ret = analogix_dp_set_link_train(dp, dp->video_info.lane_count,
+dp->video_info.link_rate);
if (ret) {
dev_err(dp->dev, "unable to do link train\n");
return;
@@ -1030,6 +1030,85 @@ static void analogix_dp_bridge_disable(struct drm_bridge
*bridge)
dp->dpms_mode = DRM_MODE_DPMS_OFF;
}
+static void analogix_dp_bridge_mode_set(struct drm_bridge *bridge,
+ struct drm_display_mode *orig_mode,
+ struct drm_display_mode *mode)
+{
+ struct analogix_dp_device *dp = bridge->driver_private;
+ struct drm_display_info *display_info = &dp->connector->display_info;
+ struct video_info *video = &dp->video_info;
+ struct device_node *dp_node = dp->dev->of_node;
+ int vic;
+
+ /* Input video interlaces & hsync pol & vsync pol */
+ video->interlaced = !!(mode->flags & DRM_MODE_FLAG_INTERLACE);
+ video->v_sync_polarity = !!(mode->flags & DRM_MODE_FLAG_NVSYNC);
+ video->h_sync_polarity = !!(mode->flags & DRM_MODE_FLAG_NHSYNC);
+
+ /* Input video dynamic_range & colorimetry */
+ vic = drm_match_cea_mode(mode);
+ if ((vic == 6) || (vic == 7) || (vic == 21) || (vic == 22) ||
+ (vic == 2) || (vic == 3) || (vic == 17) || (vic == 18)) {
+ video->dynamic_range = CEA;
+ video->ycbcr_coeff = COLOR_YCBCR601;
+ } else if (vic) {
+ video->dynamic_range = CEA;
+ video->ycbcr_coeff = COLOR_YCBCR709;
+ } else {
+ video->dynamic_range = VESA;
+ video->ycbcr_coeff = COLOR_YCBCR709;
+ }
+
+ /* Input vide bpc and color_formats */
+ switch (display_info->bpc) {
+ case 12:
+ video->color_depth = COLOR_12;
+ break;
+ case 10:
+ video->color_depth = COLOR_10;
+ break;
+ case 8:
+ video->color_depth = COLOR_8;
+ break;
+ case 6:
+ video->color_depth = COLOR_6;
+ break;
+ default:
+ video->color_depth = COLOR_8;
+ break;
+ }
+ if (display_info->color_formats & DRM_COLOR_FORMAT_YCRCB444)
+ video->color_space = COLOR_YCBCR444;
+ else if (display_info->color_formats & DRM_COLOR_FORMAT_YCRCB422)
+ video->color_space = COLOR_YCBCR422;
+ else if (display_info->color_formats & DRM_COLOR_FORMAT_RGB444)
+ video->color_space = COLOR_RGB;
+ else
+ video->color_space = COLOR_RGB;
+
+ /*
+* NOTE: those property parsing code is used for providing backward
+* compatibility for samsung platform.
+* Due to we used the "of_property_read_u32" interfaces, when this
+* property isn't present, the "video_info" can keep the original
+* values and wouldn't be modified.
+*/
+ of_proper
