Upstreaming DAL
On 24 March 2016 at 03:27, Alex Deucher wrote: > Our goal is to transition to our new DAL display stack. It is the > path we are validating internally for both the open and hybrid stacks > and will be the only display stack we support going forward with new > asics. When we initially released the patches, there were some rough > edges and quite a few things were pointed out that need to be fixed. > Some are relatively easy to fix, others will take time. Our goal is > to make those changes. We'd like to target 4.7 for upstreaming DAL. > To that end, I think it would be easier to review and track our > progress if I maintained a public DAL branch and send out patches > against that branch rather than respinning giant squashed patches > every time we fix something. It's much harder to track what progress > has been made. DAL is currently at ~400 patches. We previously tried > to squash that down into a bunch of larger commits, but I'm not sure > that is particularly easy to review. I'm also not sure it's worth > spamming the list with 400 patches. I've posted our current DAL tree > here for review: > https://cgit.freedesktop.org/~agd5f/linux/log/?h=drm-next-4.7-wip-dal > I can certainly send out the patches if that is preferred. We will be > sending out all new patches to the list as the further clean up tasks > and new features are implemented. > > Our goal is to fix the following items in time for 4.7. Additional > fixes and re-factoring will continue as we work to address all of the > comments and concerns. I think people are focusing on the minor comments and concerns and possibly deliberately ignoring the bigger concern that this code is base is pretty much unmergeable as-is. Cleaning this up won't be a matter of just removing some memset's, mallocs and moving on. This code needs redesign by someone with Linux kernel development experience. Alex if you have any other tasks in AMD, I suggest you apply to have them all scrapped and you take this on board. So much of this code seems to be "architected" design. I mean someone senior draws a bunch of powerpoint slides with nice blocks, with what are abstraction layers between them, then a bunch of other coders take that powerpoint slide and work on a box each until it all comes together. However the abstractions don't survive so well and you end up with a bunch of leaky boxes all co-dependent and joined together but still abstracted. So let's take a massive step back from the edge here and figure out what we expect a modesetting codebase for a driver in the Linux kernel to look like and write that. Can we work out what code is actually per-GPU family and what code you want to write per GPU bringup etc. Because looking at this, for a new DCE variant or GPU you need to write: DC support: (dc/dce*) lots of code 9k-20k per DCE family DC clock gating support (dc/gpu/dce*) BIOS support: (bios_support/dce*) (can you spot leaky abstraction number one?) 1k lines bandwidth_calcs : wow that file alone is impenetrable, even after coding standards. adapter support: dc/adapter/dce* irq support gpio support asic_capability : per GPU code. Now tell me what the abstractions bring if you end up having to poke per-DCE holes into each layer to get them to talk. Maybe we should treat DAL as an example of how to drive the hardware, and evolve the driver to support things. Like you could start with pulling the bandwidth_calcs into the current driver codebase, and using it, then you could pull the bios parser into the current driver codebase and start cleaning up using that and iterate across things. So my advice is to spend more time on how a Linux display driver looks and not how to abstract everything away. I'm actually nearly getting to the point of realising nobody actually understands my concerns here and just trying to write a driver on my own. I'm still slightly open to some sort of STAGING for this, but I think I'm nearly at the level, that I'd only accept that on the understanding we'd try and evolve the driver to this level, rather than think we can clean DAL to the kernel standards. Dave.
[PATCH v2 13/18] mm/compaction: support non-lru movable pagemigration
An HTML attachment was scrubbed... URL: <https://lists.freedesktop.org/archives/dri-devel/attachments/20160324/6b36af8a/attachment-0001.html>
[PATCH 0/7] drm/exynos: HDMI and DECON fixes and enhancements
Hi Andrzej, 2016ë 03ì 23ì¼ 22:15ì Andrzej Hajda ì´(ê°) ì´ ê¸: > Hi Inki, > > This set of patches provides set of different fixes and enhancements > for DECON -> HDMI path. It is based on: > - my HDMI patches which are not yet merged[1], could you look at them > by the way, they were posted about 5 months ago :) Oops, really sorry. Will have a review ASAP. Thanks, Inki Dae > - IOMMU patches by Marek (for some mysterious reason HDMI path on 5433 > works only with IOMMU enabled), > - latest exynos-drm-next patches. > > [1]: http://permalink.gmane.org/gmane.comp.video.dri.devel/140109 > > Regards > Andrzej > > > Andrzej Hajda (7): > drm/exynos/hdmi: fix PHY configuration sequence > drm/exynos/hdmi: add PHY power off signal handling > drm/exynos/hdmi: add core reset code > drm/exynos/hdmi: remove registry dump > drm/exynos/decon5433: fix DECON standalone update > drm/exynos/decon5433: reset decon on start > drm/exynos/decon5433: do not protect window in plane disable > > drivers/gpu/drm/exynos/exynos5433_drm_decon.c | 22 +- > drivers/gpu/drm/exynos/exynos_hdmi.c | 293 > ++ > 2 files changed, 29 insertions(+), 286 deletions(-) >
[PATCH 0/7] drm/exynos: HDMI and DECON fixes and enhancements
2016ë 03ì 24ì¼ 10:07ì Inki Dae ì´(ê°) ì´ ê¸: > Hi Andrzej, > > 2016ë 03ì 23ì¼ 22:15ì Andrzej Hajda ì´(ê°) ì´ ê¸: >> Hi Inki, >> >> This set of patches provides set of different fixes and enhancements >> for DECON -> HDMI path. It is based on: >> - my HDMI patches which are not yet merged[1], could you look at them >> by the way, they were posted about 5 months ago :) > > Oops, really sorry. Will have a review ASAP. I had already a review for this patch series and merged them to exynos-drm-next-todo branch, http://www.spinics.net/lists/dri-devel/msg98354.html But I forgot to have a test. :) Thanks, Inki Dae > > Thanks, > Inki Dae > >> - IOMMU patches by Marek (for some mysterious reason HDMI path on 5433 >> works only with IOMMU enabled), >> - latest exynos-drm-next patches. >> >> [1]: http://permalink.gmane.org/gmane.comp.video.dri.devel/140109 >> >> Regards >> Andrzej >> >> >> Andrzej Hajda (7): >> drm/exynos/hdmi: fix PHY configuration sequence >> drm/exynos/hdmi: add PHY power off signal handling >> drm/exynos/hdmi: add core reset code >> drm/exynos/hdmi: remove registry dump >> drm/exynos/decon5433: fix DECON standalone update >> drm/exynos/decon5433: reset decon on start >> drm/exynos/decon5433: do not protect window in plane disable >> >> drivers/gpu/drm/exynos/exynos5433_drm_decon.c | 22 +- >> drivers/gpu/drm/exynos/exynos_hdmi.c | 293 >> ++ >> 2 files changed, 29 insertions(+), 286 deletions(-) >> > ___ > dri-devel mailing list > dri-devel at lists.freedesktop.org > https://lists.freedesktop.org/mailman/listinfo/dri-devel >
[PATCH 22/52] drm/amd/powerplay: enable dpm for baffin.
Alex Deucher gmail.com> writes: > + > + tmp_result = ellesmere_enable_thermal_auto_throttle(hwmgr); > + PP_ASSERT_WITH_CODE((0 == tmp_result), > + "Failed to enable thermal auto throttle!", result = > tmp_result); > + > + tmp_result = ellesmere_pcie_performance_request(hwmgr); > + PP_ASSERT_WITH_CODE((0 == tmp_result), > + "Failed to enable thermal auto throttle!", result = > tmp_result); Looks like the last message should be changed. //wbr VA
[PATCH v2 13/18] mm/compaction: support non-lru movable page migration
On Wed, Mar 23, 2016 at 02:05:11PM +0900, Joonsoo Kim wrote: > On Tue, Mar 22, 2016 at 11:55:45PM +0900, Minchan Kim wrote: > > On Tue, Mar 22, 2016 at 02:50:37PM +0900, Joonsoo Kim wrote: > > > On Mon, Mar 21, 2016 at 03:31:02PM +0900, Minchan Kim wrote: > > > > We have allowed migration for only LRU pages until now and it was > > > > enough to make high-order pages. But recently, embedded system(e.g., > > > > webOS, android) uses lots of non-movable pages(e.g., zram, GPU memory) > > > > so we have seen several reports about troubles of small high-order > > > > allocation. For fixing the problem, there were several efforts > > > > (e,g,. enhance compaction algorithm, SLUB fallback to 0-order page, > > > > reserved memory, vmalloc and so on) but if there are lots of > > > > non-movable pages in system, their solutions are void in the long run. > > > > > > > > So, this patch is to support facility to change non-movable pages > > > > with movable. For the feature, this patch introduces functions related > > > > to migration to address_space_operations as well as some page flags. > > > > > > > > Basically, this patch supports two page-flags and two functions related > > > > to page migration. The flag and page->mapping stability are protected > > > > by PG_lock. > > > > > > > > PG_movable > > > > PG_isolated > > > > > > > > bool (*isolate_page) (struct page *, isolate_mode_t); > > > > void (*putback_page) (struct page *); > > > > > > > > Duty of subsystem want to make their pages as migratable are > > > > as follows: > > > > > > > > 1. It should register address_space to page->mapping then mark > > > > the page as PG_movable via __SetPageMovable. > > > > > > > > 2. It should mark the page as PG_isolated via SetPageIsolated > > > > if isolation is sucessful and return true. > > > > > > > > 3. If migration is successful, it should clear PG_isolated and > > > > PG_movable of the page for free preparation then release the > > > > reference of the page to free. > > > > > > > > 4. If migration fails, putback function of subsystem should > > > > clear PG_isolated via ClearPageIsolated. > > > > > > I think that this feature needs a separate document to describe > > > requirement of each step in more detail. For example, #1 can be > > > possible without holding a lock? I'm not sure because you lock > > > the page when implementing zsmalloc page migration in 15th patch. > > > > Yes, we needs PG_lock because install page->mapping and PG_movable > > should be atomic and PG_lock protects it. > > > > Better interface might be > > > > void __SetPageMovable(struct page *page, sruct address_space *mapping); > > > > > > > > #3 also need more explanation. Before release, we need to > > > unregister address_space. I guess that it needs to be done > > > in migratepage() but there is no explanation. > > > > Okay, we can unregister address_space in __ClearPageMovable. > > I will change it. > > > > > > > > > > > > > Cc: Vlastimil Babka > > > > Cc: Mel Gorman > > > > Cc: Hugh Dickins > > > > Cc: dri-devel at lists.freedesktop.org > > > > Cc: virtualization at lists.linux-foundation.org > > > > Signed-off-by: Gioh Kim > > > > Signed-off-by: Minchan Kim > > > > --- > > > > Documentation/filesystems/Locking | 4 + > > > > Documentation/filesystems/vfs.txt | 5 ++ > > > > fs/proc/page.c | 3 + > > > > include/linux/fs.h | 2 + > > > > include/linux/migrate.h| 2 + > > > > include/linux/page-flags.h | 29 > > > > include/uapi/linux/kernel-page-flags.h | 1 + > > > > mm/compaction.c| 14 +++- > > > > mm/migrate.c | 132 > > > > + > > > > 9 files changed, 177 insertions(+), 15 deletions(-) > > > > > > > > diff --git a/Documentation/filesystems/Locking > > > > b/Documentation/filesystems/Locking > > > > index 619af9bfdcb3..0bb79560abb3 100644 > > > > --- a/Documentation/filesystems/Locking > > > > +++ b/Documentation/filesystems/Locking > > > > @@ -195,7 +195,9 @@ unlocks and drops the reference. > > > > int (*releasepage) (struct page *, int); > > > > void (*freepage)(struct page *); > > > > int (*direct_IO)(struct kiocb *, struct iov_iter *iter, loff_t > > > > offset); > > > > + bool (*isolate_page) (struct page *, isolate_mode_t); > > > > int (*migratepage)(struct address_space *, struct page *, > > > > struct page *); > > > > + void (*putback_page) (struct page *); > > > > int (*launder_page)(struct page *); > > > > int (*is_partially_uptodate)(struct page *, unsigned long, > > > > unsigned long); > > > > int (*error_remove_page)(struct address_space *, struct page *); > > > > @@ -219,7 +221,9 @@ invalidatepage: yes > > > > releasepage: yes > > > > freepage: yes > > > > direct_IO: > > > >
[PATCH v2 13/18] mm/compaction: support non-lru movable pagemigration
On Thu, Mar 24, 2016 at 05:26:50AM +0900, Gioh Kim wrote:
>Hmmm... But, in failure case, is it safe to call putback_lru_page() for
>them?
>And, PageIsolated() would be left. Is it okay? It's not symmetric that
>isolated page can be freed by decreasing ref count without calling
>putback function. This should be clarified and documented.
>
>I agree Joonsoo's idea.
>
>Freeing isolated page out of putback() could be confused.
If we makes such rule, subsystem cannot free the isolated pages until VM calls
putback. I don't think it's a good idea. With it, every users should make own
deferred page freeing logic which might be more error-prone and obstacle for
using this interface.
I want to make client free his pages whenever he want if possible.
>
>Every detail cannot be documented. And more documents mean less elegant
>code.
>
>Is it possible to free isolated page in putback()?
>
>In move_to_new_page(), can we call a_ops->migratepage like following?
>
>move_to_new_page()
>
>{
>
>mapping = page_mapping(page)
>
>if (!mapping)
>
>rc = migrate_page
>
>else if (mapping->a_ops->migratepage && IsolatePage(page))
>
> rc = mapping->a_ops->migratepage
>
It's not a problem. The problem is that a page failed migration
so VM will putback the page. But, between fail of migration and
putback of isolated page, user can free the page. In this case,
putback operation would be not called and pass the page in
putback_lru_page.
>else
>
>rc = fallback_migrate_page
>
>...
>
> return rc
>
>}
>
>I'm sorry that I couldn't review in detail because I forgot many
>details.
You're a human being, not Alphago. :)
Thanks for the review, Gioh!
>
>[1][Kk8NwEH1.I.q95.FfPs-qw00]
>[@from=gurugio&rcpt=minchan%40kernel%2Eorg&msgid=%3C20160324052650%2EHM
>%2Ee06t8Yn%40gurugio%2Ewwl1662%2Ehanmail%2Enet%3E]
>
> References
>
>1. mailto:gurugio at hanmail.net
Upstreaming DAL
Just my 2 cents^Wcomments. On Thu, Mar 24, 2016 at 12:15 AM, Dave Airlie wrote: > On 24 March 2016 at 03:27, Alex Deucher wrote: >> Our goal is to transition to our new DAL display stack. It is the >> path we are validating internally for both the open and hybrid stacks >> and will be the only display stack we support going forward with new >> asics. When we initially released the patches, there were some rough >> edges and quite a few things were pointed out that need to be fixed. >> Some are relatively easy to fix, others will take time. Our goal is >> to make those changes. We'd like to target 4.7 for upstreaming DAL. >> To that end, I think it would be easier to review and track our >> progress if I maintained a public DAL branch and send out patches >> against that branch rather than respinning giant squashed patches >> every time we fix something. It's much harder to track what progress >> has been made. DAL is currently at ~400 patches. We previously tried >> to squash that down into a bunch of larger commits, but I'm not sure >> that is particularly easy to review. I'm also not sure it's worth >> spamming the list with 400 patches. I've posted our current DAL tree >> here for review: >> https://cgit.freedesktop.org/~agd5f/linux/log/?h=drm-next-4.7-wip-dal >> I can certainly send out the patches if that is preferred. We will be >> sending out all new patches to the list as the further clean up tasks >> and new features are implemented. >> >> Our goal is to fix the following items in time for 4.7. Additional >> fixes and re-factoring will continue as we work to address all of the >> comments and concerns. > > I think people are focusing on the minor comments and concerns > and possibly deliberately ignoring the bigger concern that this > code is base is pretty much unmergeable as-is. > > Cleaning this up won't be a matter of just removing some memset's, > mallocs and moving on. > > This code needs redesign by someone with Linux kernel development > experience. Alex if you have any other tasks in AMD, I suggest you > apply to have them all scrapped and you take this on board. > > So much of this code seems to be "architected" design. I mean > someone senior draws a bunch of powerpoint slides with nice blocks, > with what are abstraction layers between them, then a bunch of other > coders take that powerpoint slide and work on a box each until it all > comes together. However the abstractions don't survive so well and you > end up with a bunch of leaky boxes all co-dependent and joined together > but still abstracted. > > So let's take a massive step back from the edge here and figure out what > we expect a modesetting codebase for a driver in the Linux kernel to look > like and write that. > > Can we work out what code is actually per-GPU family and what code > you want to write per GPU bringup etc. > > Because looking at this, for a new DCE variant or GPU you need to write: > > DC support: (dc/dce*) lots of code 9k-20k per DCE family > DC clock gating support (dc/gpu/dce*) > BIOS support: (bios_support/dce*) (can you spot leaky abstraction > number one?) 1k lines > bandwidth_calcs : wow that file alone is impenetrable, even after coding > standards. > adapter support: dc/adapter/dce* > irq support > gpio support > asic_capability : per GPU code. > > Now tell me what the abstractions bring if you end up having to poke > per-DCE holes > into each layer to get them to talk. > > Maybe we should treat DAL as an example of how to drive the hardware, and > evolve > the driver to support things. Still the approach I'd suggest as the one with likely the best end-result, and the fastest way to get immediate improvements upstream. Also probably the least amount of work. On top of that by chunking it up it's easier for the actual code owners to submit it and you have a much higher chance of getting external review. So much better chance DAL developers learn how to fence for their own things in an open&collaborative environment - assuming its not all Harry typing this much code ;-) > Like you could start with pulling the bandwidth_calcs into the current > driver codebase, > and using it, then you could pull the bios parser into the current > driver codebase and > start cleaning up using that and iterate across things. > > So my advice is to spend more time on how a Linux display driver looks > and not how > to abstract everything away. > > I'm actually nearly getting to the point of realising nobody actually > understands my concerns > here and just trying to write a driver on my own. > > I'm still slightly open to some sort of STAGING for this, but I think > I'm nearly at the level, > that I'd only accept that on the understanding we'd try and evolve the > driver to this level, > rather than think we can clean DAL to the kernel standards. This might work, as in merge DAL now, as-is, knowlingly still steaming. And then put all the focus on cleaning it up in public, with the goal that everyone o
[PATCH] drm: bridge: Make (pre/post) enable/disable callbacks optional
On 02/26/2016 03:21 PM, Laurent Pinchart wrote:
> Instead of forcing bridges to implement empty callbacks make them all
> optional.
Acked-by: Archit Taneja
>
> Signed-off-by: Laurent Pinchart
> ---
> drivers/gpu/drm/drm_bridge.c | 12
> include/drm/drm_crtc.h | 8
> 2 files changed, 16 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/gpu/drm/drm_bridge.c b/drivers/gpu/drm/drm_bridge.c
> index bd93453afa61..b3654404abd0 100644
> --- a/drivers/gpu/drm/drm_bridge.c
> +++ b/drivers/gpu/drm/drm_bridge.c
> @@ -186,7 +186,8 @@ void drm_bridge_disable(struct drm_bridge *bridge)
>
> drm_bridge_disable(bridge->next);
>
> - bridge->funcs->disable(bridge);
> + if (bridge->funcs->disable)
> + bridge->funcs->disable(bridge);
> }
> EXPORT_SYMBOL(drm_bridge_disable);
>
> @@ -206,7 +207,8 @@ void drm_bridge_post_disable(struct drm_bridge *bridge)
> if (!bridge)
> return;
>
> - bridge->funcs->post_disable(bridge);
> + if (bridge->funcs->post_disable)
> + bridge->funcs->post_disable(bridge);
>
> drm_bridge_post_disable(bridge->next);
> }
> @@ -256,7 +258,8 @@ void drm_bridge_pre_enable(struct drm_bridge *bridge)
>
> drm_bridge_pre_enable(bridge->next);
>
> - bridge->funcs->pre_enable(bridge);
> + if (bridge->funcs->pre_enable)
> + bridge->funcs->pre_enable(bridge);
> }
> EXPORT_SYMBOL(drm_bridge_pre_enable);
>
> @@ -276,7 +279,8 @@ void drm_bridge_enable(struct drm_bridge *bridge)
> if (!bridge)
> return;
>
> - bridge->funcs->enable(bridge);
> + if (bridge->funcs->enable)
> + bridge->funcs->enable(bridge);
>
> drm_bridge_enable(bridge->next);
> }
> diff --git a/include/drm/drm_crtc.h b/include/drm/drm_crtc.h
> index 7fad193dc645..fbc225414f01 100644
> --- a/include/drm/drm_crtc.h
> +++ b/include/drm/drm_crtc.h
> @@ -1584,6 +1584,8 @@ struct drm_bridge_funcs {
>*
>* The bridge can assume that the display pipe (i.e. clocks and timing
>* signals) feeding it is still running when this callback is called.
> + *
> + * The disable callback is optional.
>*/
> void (*disable)(struct drm_bridge *bridge);
>
> @@ -1600,6 +1602,8 @@ struct drm_bridge_funcs {
>* The bridge must assume that the display pipe (i.e. clocks and timing
>* singals) feeding it is no longer running when this callback is
>* called.
> + *
> + * The post_disable callback is optional.
>*/
> void (*post_disable)(struct drm_bridge *bridge);
>
> @@ -1628,6 +1632,8 @@ struct drm_bridge_funcs {
>* will not yet be running when this callback is called. The bridge must
>* not enable the display link feeding the next bridge in the chain (if
>* there is one) when this callback is called.
> + *
> + * The pre_enable callback is optional.
>*/
> void (*pre_enable)(struct drm_bridge *bridge);
>
> @@ -1645,6 +1651,8 @@ struct drm_bridge_funcs {
>* signals) feeding it is running when this callback is called. This
>* callback must enable the display link feeding the next bridge in the
>* chain if there is one.
> + *
> + * The enable callback is optional.
>*/
> void (*enable)(struct drm_bridge *bridge);
> };
>
--
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora
Forum, hosted by The Linux Foundation
Atomic mode-setting drivers
On Fri, Mar 04, 2016 at 05:20:00PM -0500, Alex Deucher wrote: > Code complexities and internal abstractions aside, we've implemented > the API and tested it and it appears to work. What sort of additional > semantics does atomic imply that you don't think DAL would handle? Michel asked me to follow up here. I thought I've followed up on irc. Anyway the big problem and reason why I didnt' fully dig into things are that reading 100kloc for an atomic review when it's clear the code overall needs some serious love is something I didn't want to do. I'm still up to reading things once they look a bit more reasonable, and it's not massively more work than all the other atomic drivers/conversions I looked at. So without looking again, with a few months of brain memory degradation: - The glue looked fairly incomplete, e.g. it wasn't using all the legacy2atomic helpers we have. Which likely means it wasn't really tested much. - Not universal planes, hence atomic plane updates not possible. - It did roll it's own commit (which is how this is meant to be really in the end), but I did not see the a clear reason, and it didn't seem to have been closely modelled after atomic helpers. Not necessarily bad, just increases chances that some of the semantics are wrong. And the more fundamental thing, but the one I couldn't check because abstraction: - Doesn't seem to stage derived state needed to check limits (e.g. clocks, memory bandwidth) in something subclassing drm_*_state structures. Either that means you're rolling your own atomic machinery (no-go) or you get it wrong (no-go). But since DAL completely forgoes drm structures I didn't have a map to read the code and got lost. - It looked liked DAL works with a try_commit()/rollback() model, but atomic requires a check()/commit() model. And the check phase is not allowed to change _any_ persistent state (whether sw or hw). That's why atomic needs to stage everything that might change, and which might need to be checked up-front in these free-standing state structures. I think for me to be able to actually give you a clear answer here we'd need 2 things: - Handle all the list of cleanup tasks to get rid of reinvented code. - Embed drm_* structs in corresponding DAL structs to really link concepts together, and have some kind of map to be able to read the code. I think only with that it's possible to have a clear idea whether DAL needs to be redesigned to be able to implement atomic, or not. Again: I din't look at the code, this is purely from memory. Cheers, Daniel -- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch
[RFC 0/6] drm/fences: add in-fences to DRM
Hey,
Op 23-03-16 om 19:47 schreef Gustavo Padovan:
> From: Gustavo Padovan
>
> Hi,
>
> This is a first proposal to discuss the addition of in-fences support
> to DRM. It adds a new struct to fence.c to abstract the use of sync_file
> in DRM drivers. The new struct fence_collection contains a array with all
> fences that a atomic commit needs to wait on
>
> /**
> * struct fence_collection - aggregate fences together
> * @num_fences: number of fence in the collection.
> * @user_data: user data.
> * @func: user callback to put user data.
> * @fences: array of @num_fences fences.
> */
> struct fence_collection {
>int num_fences;
>void *user_data;
>collection_put_func_t func;
>struct fence *fences[];
> };
>
>
> The fence_collection is allocated and filled by sync_file_fences_get() and
> atomic_commit helpers can use fence_collection_wait() to wait the fences to
> signal.
>
> These patches depends on the sync ABI rework:
>
> https://www.spinics.net/lists/dri-devel/msg102795.html
>
> and the patch to de-stage the sync framework:
>
> https://www.spinics.net/lists/dri-devel/msg102799.html
>
>
> I also hacked together some sync support into modetest for testing:
>
> https://git.collabora.com/cgit/user/padovan/libdrm.git/log/?h=atomic
>
Why did you choose to add fence_collection, rather than putting sync_file in
state?
There used to be a sync_fence_wait function, which would mean you'd have
everything you need.
~Maarten
VirtIO-GPU 3D OpenGL Hardware Acceleration for VMs
2016-02-15 10:34 GMT+08:00 Saket Sinha : > > It seems upstream Linux/Gallium3D/Mesa/Qemu/KVM has recently gained > virtualized support for 3D/OpenGL hardware acceleration in VMs, > allowing using the GPU of the host in VMs. > > As per my understanding the following components are needed - > > - Linux 4.4 kernel includes the DRM driver for VirtIO-GPU 3D > acceleration (needed in the VM). > - Qemu 2.5 includes the VirtIO-GPU 3D mode support. > - Gallium3D VirGL driver is included in Mesa git (needed in the VM, > supports up to OpenGL 3.3 atm). > - On the host *any* OpenGL driver (for the host GPU obviously), no > special requirements there. > > In order to do test this, if I can be guided as to what are the right > applications to test the entire Graphic stack on a QEMU-KVM Virtual > machine, I shall be grateful. If you are interested to test Android on QEMU with 3D hardware acceleration (via virgl, of course), here is an ISO you can test: http://www.fosshub.com/Android-x86.html/android-x86-6.0-20160318.iso The command to run QEMU qemu-kvm -smp 2 -m 2048 \ -device virtio-gpu-pci,virgl -display gtk,gl=on \ -d guest_errors \ -serial mon:stdio \ -cdrom android-x86-6.0-20160318.iso It's built with kernel 4.4.4 and Mesa 11.2.0-rc3. If you'd like to build the ISO yourself, please read https://sourceforge.net/p/android-x86/wiki/Downloading%20and%20Building/ -- Chih-Wei Android-x86 project http://www.android-x86.org
[RFC 1/6] drm/fence: add FENCE_FD property to planes
Hi,
2016ë
03ì 24ì¼ 03:47ì Gustavo Padovan ì´(ê°) ì´ ê¸:
> From: Gustavo Padovan
>
> FENCE_FD can now be set by the user during an atomic IOCTL, it
> will be used by atomic_commit to wait until the sync_file is signalled,
> i.e., the framebuffer is ready for scanout.
It seems that this patch makes Linux DRM to be dependent of Android which uses
explicit sync interfaces.
So was there any a consensus that Android sync driver is used for DMA buffer
synchronization as a Linux standard?
I see the Android sync driver exists in staging yet. Isn't the implicit sync
interface used for DMA device as a Linux standard?
I don't see why Android specific things are spreaded into Linux DRM.
Thanks,
Inki Dae
>
> Signed-off-by: Gustavo Padovan
> ---
> drivers/gpu/drm/drm_atomic.c| 4
> drivers/gpu/drm/drm_atomic_helper.c | 1 +
> drivers/gpu/drm/drm_crtc.c | 7 +++
> include/drm/drm_crtc.h | 3 +++
> 4 files changed, 15 insertions(+)
>
> diff --git a/drivers/gpu/drm/drm_atomic.c b/drivers/gpu/drm/drm_atomic.c
> index 8fb469c..8bc364c 100644
> --- a/drivers/gpu/drm/drm_atomic.c
> +++ b/drivers/gpu/drm/drm_atomic.c
> @@ -609,6 +609,8 @@ int drm_atomic_plane_set_property(struct drm_plane *plane,
> drm_atomic_set_fb_for_plane(state, fb);
> if (fb)
> drm_framebuffer_unreference(fb);
> + } else if (property == config->prop_fence_fd) {
> + state->fence_fd = val;
> } else if (property == config->prop_crtc_id) {
> struct drm_crtc *crtc = drm_crtc_find(dev, val);
> return drm_atomic_set_crtc_for_plane(state, crtc);
> @@ -666,6 +668,8 @@ drm_atomic_plane_get_property(struct drm_plane *plane,
>
> if (property == config->prop_fb_id) {
> *val = (state->fb) ? state->fb->base.id : 0;
> + } else if (property == config->prop_fence_fd) {
> + *val = state->fence_fd;
> } else if (property == config->prop_crtc_id) {
> *val = (state->crtc) ? state->crtc->base.id : 0;
> } else if (property == config->prop_crtc_x) {
> diff --git a/drivers/gpu/drm/drm_atomic_helper.c
> b/drivers/gpu/drm/drm_atomic_helper.c
> index 2b430b0..4f91f84 100644
> --- a/drivers/gpu/drm/drm_atomic_helper.c
> +++ b/drivers/gpu/drm/drm_atomic_helper.c
> @@ -2594,6 +2594,7 @@ void drm_atomic_helper_plane_reset(struct drm_plane
> *plane)
> if (plane->state) {
> plane->state->plane = plane;
> plane->state->rotation = BIT(DRM_ROTATE_0);
> + plane->state->fence_fd = -1;
> }
> }
> EXPORT_SYMBOL(drm_atomic_helper_plane_reset);
> diff --git a/drivers/gpu/drm/drm_crtc.c b/drivers/gpu/drm/drm_crtc.c
> index 65258ac..165f199 100644
> --- a/drivers/gpu/drm/drm_crtc.c
> +++ b/drivers/gpu/drm/drm_crtc.c
> @@ -1291,6 +1291,7 @@ int drm_universal_plane_init(struct drm_device *dev,
> struct drm_plane *plane,
>
> if (drm_core_check_feature(dev, DRIVER_ATOMIC)) {
> drm_object_attach_property(&plane->base, config->prop_fb_id, 0);
> + drm_object_attach_property(&plane->base, config->prop_fence_fd,
> -1);
> drm_object_attach_property(&plane->base, config->prop_crtc_id,
> 0);
> drm_object_attach_property(&plane->base, config->prop_crtc_x,
> 0);
> drm_object_attach_property(&plane->base, config->prop_crtc_y,
> 0);
> @@ -1546,6 +1547,12 @@ static int drm_mode_create_standard_properties(struct
> drm_device *dev)
> return -ENOMEM;
> dev->mode_config.prop_fb_id = prop;
>
> + prop = drm_property_create_signed_range(dev, DRM_MODE_PROP_ATOMIC,
> + "FENCE_FD", -1, INT_MAX);
> + if (!prop)
> + return -ENOMEM;
> + dev->mode_config.prop_fence_fd = prop;
> +
> prop = drm_property_create_object(dev, DRM_MODE_PROP_ATOMIC,
> "CRTC_ID", DRM_MODE_OBJECT_CRTC);
> if (!prop)
> diff --git a/include/drm/drm_crtc.h b/include/drm/drm_crtc.h
> index 8c7fb3d..a8f6ec0 100644
> --- a/include/drm/drm_crtc.h
> +++ b/include/drm/drm_crtc.h
> @@ -1239,6 +1239,7 @@ struct drm_connector {
> * @crtc: currently bound CRTC, NULL if disabled
> * @fb: currently bound framebuffer
> * @fence: optional fence to wait for before scanning out @fb
> + * @fence_fd: fd representing the sync_fence
> * @crtc_x: left position of visible portion of plane on crtc
> * @crtc_y: upper position of visible portion of plane on crtc
> * @crtc_w: width of visible portion of plane on crtc
> @@ -1257,6 +1258,7 @@ struct drm_plane_state {
> struct drm_crtc *crtc; /* do not write directly, use
> drm_atomic_set_crtc_for_plane() */
> struct drm_framebuffer *fb; /* do not write directly, use
> drm_atomic_set_fb_for_plane() */
> struct fence *fence;
> + int fence_fd;
>
> /* Signed dest location allows it to be partially off screen */
> int32_t crtc_x, crtc_y;
How do I substitute drm_gem.h with another header file for Linux 3.2 kernel?
Hi, I am one of the two developers (the other is Ran Huang who posted a patch on this mailing list recently) working on reviving VIA Technologies DRM module that will support KMS and TTM. Using the installation notes James Simmons (the previous developer who did a lot of work trying to finish this module, but has since disappeared), I am able to nominally install the work in progress DRM module. https://www.freedesktop.org/wiki/Openchrome/TtmGemKms/ The reason I call it "nominally" is due to the fact that if I boot Lubuntu 12.04 with Linux 3.19-rc6 kernel, I do not have any control of PS/2 or USB mouse (hot plugging a USB mouse does not work), although DRM module works with KMS activated (confirmed this by checking Xorg.0.log), and the system will not freeze (i.e., keyboard works and the OS is functional). However, the problem I have is, due to fact that I prefer using Lubuntu 12.04 for development (Linux 3.2 kernel), I am having compilation issues trying to backport the James Simmons' VIA Technologies DRM to Linux 3.2 kernel. In particular, I get the following error messages when I compile Linux 3.2 kernel with James Simmons' VIA Technologies DRM source code. ___ . . . CC [M] drivers/gpu/drm/via/via_drv.o In file included from drivers/gpu/drm/via/via_drv.c:30:0: drivers/gpu/drm/via/via_drv.h:46:25: fatal error: drm/drm_gem.h: No such file or directory compilation terminated. ___ I checked /include/drm of Linux 3.2 kernel source code, and indeed, there is no drm_gem.h there. How do I substitute drm_gem.h with another header file for Linux 3.2 kernel? Regards, Kevin Brace
[RFC 0/6] drm/fences: add in-fences to DRM
Hi,
2016ë
03ì 24ì¼ 03:47ì Gustavo Padovan ì´(ê°) ì´ ê¸:
> From: Gustavo Padovan
>
> Hi,
>
> This is a first proposal to discuss the addition of in-fences support
> to DRM. It adds a new struct to fence.c to abstract the use of sync_file
> in DRM drivers. The new struct fence_collection contains a array with all
> fences that a atomic commit needs to wait on
As I mentioned already like below,
http://www.spinics.net/lists/dri-devel/msg103225.html
I don't see why Android specific thing is tried to propagate to Linux DRM. In
Linux mainline, it has already implicit sync interfaces for DMA devices called
dma fence which forces registering a fence obejct to DMABUF through a
reservation obejct when a dmabuf object is created. However, Android sync
driver creates a new file for a sync object and this would have different point
of view.
Is there anyone who can explan why Android specific thing is tried to spread
into Linux DRM? Was there any consensus to use Android sync driver - which uses
explicit sync interfaces - as Linux standard?
Thanks,
Inki Dae
>
> /**
> * struct fence_collection - aggregate fences together
> * @num_fences: number of fence in the collection.
> * @user_data: user data.
> * @func: user callback to put user data.
> * @fences: array of @num_fences fences.
> */
> struct fence_collection {
>int num_fences;
>void *user_data;
>collection_put_func_t func;
>struct fence *fences[];
> };
>
>
> The fence_collection is allocated and filled by sync_file_fences_get() and
> atomic_commit helpers can use fence_collection_wait() to wait the fences to
> signal.
>
> These patches depends on the sync ABI rework:
>
> https://www.spinics.net/lists/dri-devel/msg102795.html
>
> and the patch to de-stage the sync framework:
>
> https://www.spinics.net/lists/dri-devel/msg102799.html
>
>
> I also hacked together some sync support into modetest for testing:
>
> https://git.collabora.com/cgit/user/padovan/libdrm.git/log/?h=atomic
>
>
> Gustavo
>
>
> Gustavo Padovan (6):
> drm/fence: add FENCE_FD property to planes
> dma-buf/fence: add struct fence_collection
> dma-buf/sync_file: add sync_file_fences_get()
> dma-buf/fence: add fence_collection_put()
> dma-buf/fence: add fence_collection_wait()
> drm/fence: support fence_collection on atomic commit
>
> drivers/dma-buf/fence.c | 33 +
> drivers/dma-buf/sync_file.c | 36
> drivers/gpu/drm/drm_atomic.c| 13 +
> drivers/gpu/drm/drm_atomic_helper.c | 10 ++
> drivers/gpu/drm/drm_crtc.c | 7 +++
> include/drm/drm_crtc.h | 5 -
> include/linux/fence.h | 19 +++
> include/linux/sync_file.h | 8
> 8 files changed, 126 insertions(+), 5 deletions(-)
>
[RFC 0/6] drm/fences: add in-fences to DRM
this patch series reminder me my another thoughts recently, But I don't
know if my idea is appropriated:
sometimes one person could only need wait any of these fence array, but
it doesn't want to call fence_wait_any since which will block its
thread. if there is a mechanism let the person register a callback to
these fence array, then that will be very convenient.
So I want to add a event fence, which is a special kind of fence and
indicates this event is satisfied and is signalled by any of the fence
array.
What do you think of it?
Regards,
David Zhou
On 2016å¹´03æ24æ¥ 15:20, Maarten Lankhorst wrote:
> Hey,
>
> Op 23-03-16 om 19:47 schreef Gustavo Padovan:
>> From: Gustavo Padovan
>>
>> Hi,
>>
>> This is a first proposal to discuss the addition of in-fences support
>> to DRM. It adds a new struct to fence.c to abstract the use of sync_file
>> in DRM drivers. The new struct fence_collection contains a array with all
>> fences that a atomic commit needs to wait on
>>
>> /**
>> * struct fence_collection - aggregate fences together
>> * @num_fences: number of fence in the collection.
>> * @user_data: user data.
>> * @func: user callback to put user data.
>> * @fences: array of @num_fences fences.
>> */
>> struct fence_collection {
>> int num_fences;
>> void *user_data;
>> collection_put_func_t func;
>> struct fence *fences[];
>> };
>>
>>
>> The fence_collection is allocated and filled by sync_file_fences_get() and
>> atomic_commit helpers can use fence_collection_wait() to wait the fences to
>> signal.
>>
>> These patches depends on the sync ABI rework:
>>
>> https://www.spinics.net/lists/dri-devel/msg102795.html
>>
>> and the patch to de-stage the sync framework:
>>
>> https://www.spinics.net/lists/dri-devel/msg102799.html
>>
>>
>> I also hacked together some sync support into modetest for testing:
>>
>> https://git.collabora.com/cgit/user/padovan/libdrm.git/log/?h=atomic
>>
> Why did you choose to add fence_collection, rather than putting sync_file in
> state?
>
> There used to be a sync_fence_wait function, which would mean you'd have
> everything you need.
>
> ~Maarten
> ___
> dri-devel mailing list
> dri-devel at lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 115051] HD 5870, GPU lockup
https://bugzilla.kernel.org/show_bug.cgi?id=115051 Tiger changed: What|Removed |Added CC||TigerLiu.ee at gmail.com --- Comment #1 from Tiger --- Does a lower Xorg version work better? -- You are receiving this mail because: You are watching the assignee of the bug.
[linux-sunxi] [PATCH v3 08/19] ARM: sun5i: Add DRAM gates
On Thu, Mar 24, 2016 at 12:38 AM, Maxime Ripard wrote: > The DRAM gates control whether the image / display devices on the SoC have > access to the DRAM clock or not. > > Enable it. > > Signed-off-by: Maxime Ripard Acked-by: Chen-Yu Tsai I assume you'll add another version for A10s, or move the whole thing to sun5i.dtsi later?
[Bug 94667] Artifacts on applications on discrete
https://bugs.freedesktop.org/show_bug.cgi?id=94667 Michel D�nzer changed: What|Removed |Added CC||chris at chris-wilson.co.uk --- Comment #6 from Michel D�nzer --- It looks like maybe the intel driver is incorrectly treating the shared buffer as non-linear. Chris, any ideas? -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <https://lists.freedesktop.org/archives/dri-devel/attachments/20160324/2e4ea7bb/attachment.html>
[PATCH v3 1/2 RESEND] drm/dp_helper: add workarounds from intel_dp_dpcd_read_wake()
On Wed, 23 Mar 2016, Lyude wrote:
> Some sinks need some time during the process of resuming the system from
> sleep before they're ready to handle transactions. While it would be
> nice if they responded with NACKs in these scenarios, this isn't always
> the case as a few sinks will just timeout on all of the transactions
> they receive.
>
> This patch was originally intended to be a workaround for a very
> mysterious bug on the T560, where any monitors connected to the dock
> would fail to turn back on after resume. When resuming the laptop, it
> appears that there's a short period of time where we're unable to
> complete any aux transactions, as they all immediately timeout. The only
> machine I'm able to reproduce this on is the T560 as other production
> Skylake models seem to be fine. The period during which AUX transactions
> fail appears to be around 22ms long. AFAIK, the dock for the T560 never
> actually turns off, the only difference is that it's in SST mode at the
> start of the resume process, so it's unclear as to why it would need so
> much time to come back up.
>
> There's been a discussion on this issue going on for a while on the
> intel-gfx mailing list about this that has, in addition to including
> developers from Intel, also had the correspondence of one of the
> hardware engineers for Intel:
>
> http://www.spinics.net/lists/intel-gfx/msg88831.html
> http://www.spinics.net/lists/intel-gfx/msg88410.html
>
> We've already looked into a couple of possible explanations for the
> problem:
>
> - Calling intel_dp_mst_resume() before right fix.
> intel_runtime_pm_enable_interrupts(). This was the first fix I tried,
> and while it worked it definitely wasn't the right fix. This worked
> because DP aux transactions don't actually require interrupts to work:
>
> static uint32_t
> intel_dp_aux_wait_done(struct intel_dp *intel_dp, bool has_aux_irq)
> {
> struct intel_digital_port *intel_dig_port =
> dp_to_dig_port(intel_dp);
> struct drm_device *dev = intel_dig_port->base.base.dev;
> struct drm_i915_private *dev_priv = dev->dev_private;
> i915_reg_t ch_ctl = intel_dp->aux_ch_ctl_reg;
> uint32_t status;
> bool done;
>
> #define C (((status = I915_READ_NOTRACE(ch_ctl)) &
> DP_AUX_CH_CTL_SEND_BUSY) == 0)
> if (has_aux_irq)
> done = wait_event_timeout(dev_priv->gmbus_wait_queue, C,
> msecs_to_jiffies_timeout(10));
> else
> done = wait_for_atomic(C, 10) == 0;
> if (!done)
> DRM_ERROR("dp aux hw did not signal timeout (has irq:
> %i)!\n",
> has_aux_irq);
> #undef C
>
> return status;
> }
>
> When there's no interrupts enabled, we end up timing out on the
> wait_event_timeout() call, which causes us to check the DP status
> register once to see if the transaction was successful or not. Since
> this adds a 10ms delay to each aux transaction, it ends up adding a
> long enough delay to the resume process for aux transactions to become
> functional again. This gave us the illusion that enabling interrupts
> had something to do with making things work again, and put me on the
> wrong track for a while.
>
> - Interrupts occurring when we try to perform the aux transactions
> required to put the dock back into MST mode. This isn't the problem,
> as the only interrupts I've observed that come during this timeout
> period are from the snd_hda_intel driver, and disabling that driver
> doesn't appear to change the behavior at all.
>
> - Skylake's PSR block causing issues by performing aux transactions
> while we try to bring the dock out of MST mode. Disabling PSR through
> i915's command line options doesn't seem to change the behavior
> either, nor does preventing the DMC firmware from being loaded.
>
> Since this investigation went on for about 2 weeks, we decided it would
> be better for the time being to just workaround this issue until we find
> a better fix. This patch adds some behavior we want in
> drm_dp_dpcd_access() anyway, since DP aux transactions aren't exactly
> robust and this will probably fix quite a few other issues with DP MST
> hardware not responding in time. Plus, this is something we already do
> in the i915 driver with intel_dp_dpcd_read_wake(), except that that
> function is somewhat of a hack and DRM helpers can't make use of it.
>
> Changes since v2
> - Reworked the patch again to incorporate all of the behavior of
> intel_dp_dpcd_read_wake() into drm_dp_dpcd_read() and
> drm_dp_dpcd_access()
>
> Changes since v1
>
> - Patch has been reworked to take the retry logic out of
> intel_dp_mst_resume() and into drm_dp_dpcd_access(), based off a
> suggestion from Daniel Vetter
>
[PATCH] drm: Add new DCS commands in the enum list
Adding new DCS commands which are specified in the
DCS 1.3 spec related to CABC.
Cc: Thierry Reding
Cc: David Airlie
Cc: Ville Syrjälä
Cc: Daniel Vetter
Suggested-by: Jani Nikula
Signed-off-by: Deepak M
---
include/video/mipi_display.h | 8
1 file changed, 8 insertions(+)
diff --git a/include/video/mipi_display.h b/include/video/mipi_display.h
index ddcc8ca..bb8195b 100644
--- a/include/video/mipi_display.h
+++ b/include/video/mipi_display.h
@@ -117,6 +117,14 @@ enum {
MIPI_DCS_GET_SCANLINE = 0x45,
MIPI_DCS_READ_DDB_START = 0xA1,
MIPI_DCS_READ_DDB_CONTINUE = 0xA8,
+ MIPI_DCS_GET_DISPLAY_BRIGHTNESS = 0x52,
+ MIPI_DCS_GET_CABC_MIN_BRIGHTNESS = 0x5F,
+ MIPI_DCS_GET_POWER_SAVE = 0x56,
+ MIPI_DCS_GET_CONTROL_DISPLAY= 0x54,
+ MIPI_DCS_SET_DISPLAY_BRIGHTNESS = 0x51,
+ MIPI_DCS_SET_CABC_MIN_BRIGHTNESS = 0x5E,
+ MIPI_DCS_WRITE_POWER_SAVE = 0x55,
+ MIPI_DCS_WRITE_CONTROL_DISPLAY = 0x53,
};
/* MIPI DCS pixel formats */
--
1.9.1
[Bug 94667] Artifacts on applications on discrete
https://bugs.freedesktop.org/show_bug.cgi?id=94667 --- Comment #7 from Chris Wilson --- Objects used for sharing backing pixmaps are converted to linear (SharePixmapBacking). Prime imports use whatever tiling is registered with the foreign surface (both DRI3 and SetSharedPixmapBacking), similarly we communicate the tiling for an export of an existing pixmap (DRI3). We definitely want to be able to pass tiled surfaces between DRI2/DRI3 clients and the Xserver! -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <https://lists.freedesktop.org/archives/dri-devel/attachments/20160324/e8052148/attachment-0001.html>
[PATCH 02/23] ARM: dts: n950: add display support
On Wed, 23 Mar 2016, Sebastian Reichel wrote: > On Wed, Mar 23, 2016 at 02:40:53PM +0200, Jani Nikula wrote: >> On Thu, 17 Mar 2016, Sebastian Reichel wrote: >> > On Thu, Mar 17, 2016 at 02:14:26PM +0200, Laurent Pinchart wrote: >> >> [...] >> >> > + >> >> > + /* panel is 480x464 with top and bottom 5 lines not >> >> > visible */ >> >> >> >> I assume you mean 480x864 ? >> > >> > Yes, nice catch. Basically the screen is 480x864, but only >> > 480x854 are visible. >> >> It's been a while, but I thought the full 480x864 was actually usable >> and visible. > > I tried that first and the first few lines were missing. The stock > kernel also uses only 854px: > > https://github.com/nemomobile/kernel-adaptation-n950-n9/blob/mer-n9-2.6.32-20121301/arch/arm/mach-omap2/board-rm680-video.c > > (search for partial_area) Heh, I was reminded by old colleagues that it was actually my commit back in the day that changed the resolution 864->854 in the stock kernel. And that I did it reluctantly, because there really was no technical reason to do the change. I don't really care all that much either way anymore. I just thought you'd like to get those 4800 pixels back that you've been missing all these years. Plus 864 was nicer to deal with because it has 2^5 as a prime factor while 854 only has 2. BR, Jani. -- Jani Nikula, Intel Open Source Technology Center
[Intel-gfx] [PATCH 1/3] drm: Add new DCS commands in the enum list
On Thu, 24 Mar 2016, Deepak M wrote:
> Adding new DCS commands which are specified in the
> DCS 1.3 spec related to CABC.
>
> Cc: Thierry Reding
> Cc: David Airlie
> Cc: Ville Syrjälä
> Cc: Daniel Vetter
> Suggested-by: Jani Nikula
> Signed-off-by: Deepak M
Deepak, for future reference, please use scripts/get_maintainer.pl to
see whom you should include for patches touching code outside of i915.
The commands added match the MIPI DCS 1.3 spec,
Reviewed-by: Jani Nikula
Jean-Christophe, Tomi, may I have your acks for merging this via
drm/i915 tree?
BR,
Jani.
> ---
> include/video/mipi_display.h | 8
> 1 file changed, 8 insertions(+)
>
> diff --git a/include/video/mipi_display.h b/include/video/mipi_display.h
> index ddcc8ca..bb8195b 100644
> --- a/include/video/mipi_display.h
> +++ b/include/video/mipi_display.h
> @@ -117,6 +117,14 @@ enum {
> MIPI_DCS_GET_SCANLINE = 0x45,
> MIPI_DCS_READ_DDB_START = 0xA1,
> MIPI_DCS_READ_DDB_CONTINUE = 0xA8,
> + MIPI_DCS_GET_DISPLAY_BRIGHTNESS = 0x52,
> + MIPI_DCS_GET_CABC_MIN_BRIGHTNESS = 0x5F,
> + MIPI_DCS_GET_POWER_SAVE = 0x56,
> + MIPI_DCS_GET_CONTROL_DISPLAY= 0x54,
> + MIPI_DCS_SET_DISPLAY_BRIGHTNESS = 0x51,
> + MIPI_DCS_SET_CABC_MIN_BRIGHTNESS = 0x5E,
> + MIPI_DCS_WRITE_POWER_SAVE = 0x55,
> + MIPI_DCS_WRITE_CONTROL_DISPLAY = 0x53,
> };
>
> /* MIPI DCS pixel formats */
--
Jani Nikula, Intel Open Source Technology Center
[Bug 46711] Monitor not turning on after DisplayPort re-plug in Xorg
https://bugs.freedesktop.org/show_bug.cgi?id=46711 --- Comment #23 from martin f. krafft --- I am also seeing this problem on Debian Sid with a new Radeon R9 390 card and two Samsung monitors connected with DisplayPort. The third monitor on DVI works just fine. Here's the card: 06:00.0 VGA compatible controller: Advanced Micro Devices, Inc. [AMD/ATI] Hawaii PRO [Radeon R9 290] (rev 80) Kernel is version 4.4.0 (amd64) X.org is version 7.7 Radeon driver is version 7.6.1 Restarting X.org does *not* turn the monitors/displays on. They are in a really weird state: not flashing as to indicate power-saving, but completely blank/dark, and I can't even call up the OSD menu. The only way to get these displays to work is to disconnect the DP cable, turn them off and on, and then connect the DP cable again. Here is abridged xrandr output: Screen 0: minimum 320 x 200, current 5888 x 1152, maximum 16384 x 16384 DisplayPort-0 connected 1920x1080+0+0 (normal left inverted right x axis y axis) 477mm x 268mm 1920x1080 60.00*+ 59.94 [â¦] DisplayPort-1 connected 1920x1080+3968+0 (normal left inverted right x axis y axis) 477mm x 268mm 1920x1080 60.00*+ 59.94 [â¦] DisplayPort-2 disconnected (normal left inverted right x axis y axis) HDMI-0 disconnected (normal left inverted right x axis y axis) DVI-0 connected primary 2048x1152+1920+0 (normal left inverted right x axis y axis) 510mm x 287mm 1920x1080 60.00 + 50.0059.94 2048x1152 59.91*+ [â¦] -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <https://lists.freedesktop.org/archives/dri-devel/attachments/20160324/857c8ab2/attachment.html>
[PATCH 2/3] devicetree: Add ANX7814 bridge binding.
The ANX7814 is an ultra-low power Full-HD (1080p60) SlimPort transmitter
designed for portable devices.
Signed-off-by: Enric Balletbo i Serra
---
.../devicetree/bindings/video/bridge/anx7814.txt | 41 ++
1 file changed, 41 insertions(+)
create mode 100644 Documentation/devicetree/bindings/video/bridge/anx7814.txt
diff --git a/Documentation/devicetree/bindings/video/bridge/anx7814.txt
b/Documentation/devicetree/bindings/video/bridge/anx7814.txt
new file mode 100644
index 000..5a47a42
--- /dev/null
+++ b/Documentation/devicetree/bindings/video/bridge/anx7814.txt
@@ -0,0 +1,41 @@
+Analogix ANX7814 SlimPort (Full-HD Transmitter)
+---
+
+The ANX7814 is an ultra-low power Full-HD (1080p60) SlimPort transmitter
+designed for portable devices.
+
+Required properties:
+
+ - compatible : "analogix,anx7814"
+ - reg : I2C address of the device
+ - interrupt-parent: Should be the phandle of the interrupt controller
+ that services interrupts for this device
+ - interrupts : Should contain the INTP interrupt
+ - cable-det-gpios : Which GPIO to use for cable detection
+ - pd-gpios: Which GPIO to use for power down
+ - reset-gpios : Which GPIO to use for reset
+
+Optional properties:
+
+ - v10-gpios : Which GPIO to use for V10 control.
+ - Video port for HDMI output, using the DT bindings defined in [1].
+
+[1]: Documentation/devicetree/bindings/media/video-interfaces.txt
+
+Example:
+
+ anx7814: anx7814 at 38 {
+ compatible = "analogix,anx7814";
+ reg = <0x38>;
+ interrupt-parent = <&gpio0>;
+ interrupts = <99 IRQ_TYPE_LEVEL_LOW>; /* INTP */
+ cable-det-gpios = <&pio 36 GPIO_ACTIVE_HIGH>;
+ pd-gpios = <&pio 33 GPIO_ACTIVE_HIGH>;
+ reset-gpios = <&pio 98 GPIO_ACTIVE_HIGH>;
+ v10-gpios = <&pio 35 GPIO_ACTIVE_HIGH>;
+ port {
+ anx7814_in: endpoint {
+ remote-endpoint = <&hdmi0_out>;
+ };
+ };
+ };
--
2.1.0
[PATCH 3/3] drm: bridge: anx78xx: Add anx78xx bridge driver support.
Although there are other chips from the same family that can reuse this
driver, at the moment we only tested ANX7814 chip.
The ANX7814 is an ultra-low power Full-HD (1080p60) SlimPort transmitter
designed for portable devices. This driver adds initial support for HDMI
to DP pass-through mode.
Signed-off-by: Enric Balletbo i Serra
---
drivers/gpu/drm/bridge/Kconfig |8 +
drivers/gpu/drm/bridge/Makefile |1 +
drivers/gpu/drm/bridge/anx78xx.c | 1433 ++
drivers/gpu/drm/bridge/anx78xx.h | 719 +++
4 files changed, 2161 insertions(+)
create mode 100644 drivers/gpu/drm/bridge/anx78xx.c
create mode 100644 drivers/gpu/drm/bridge/anx78xx.h
diff --git a/drivers/gpu/drm/bridge/Kconfig b/drivers/gpu/drm/bridge/Kconfig
index 27e2022..0f595ae 100644
--- a/drivers/gpu/drm/bridge/Kconfig
+++ b/drivers/gpu/drm/bridge/Kconfig
@@ -40,4 +40,12 @@ config DRM_PARADE_PS8622
---help---
Parade eDP-LVDS bridge chip driver.
+config DRM_ANX78XX
+ tristate "Analogix ANX78XX bridge"
+ select DRM_KMS_HELPER
+ select REGMAP_I2C
+ ---help---
+ ANX78XX is a HD video transmitter chip over micro-USB connector
+ for smartphone device.
+
endmenu
diff --git a/drivers/gpu/drm/bridge/Makefile b/drivers/gpu/drm/bridge/Makefile
index f13c33d..8f0d69e 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_ANX78XX) += anx78xx.o
diff --git a/drivers/gpu/drm/bridge/anx78xx.c b/drivers/gpu/drm/bridge/anx78xx.c
new file mode 100644
index 000..25d2d1c
--- /dev/null
+++ b/drivers/gpu/drm/bridge/anx78xx.c
@@ -0,0 +1,1433 @@
+/*
+ * Copyright(c) 2016, Analogix Semiconductor.
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 and
+ * only version 2 as published by the Free Software Foundation.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ *
+ * Based on anx7808 driver obtained from chromeos with copyright:
+ * Copyright(c) 2013, Google Inc.
+ *
+ */
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+#include "anx78xx.h"
+
+#define I2C_NUM_ADDRESSES 5
+#define I2C_IDX_TX_P0 0
+#define I2C_IDX_TX_P1 1
+#define I2C_IDX_TX_P2 2
+#define I2C_IDX_RX_P0 3
+#define I2C_IDX_RX_P1 4
+
+#define XTAL_CLK 270 /* 27M */
+#define AUX_CH_BUFFER_SIZE 16
+#define AUX_WAIT_TIMEOUT_MS15
+#define AUX_WAIT_INTERVAL_MS 1
+
+/*
+ * _wait_for - magic (register) wait macro
+ *
+ * Does the right thing for modeset paths when run under kdgb or similar atomic
+ * contexts. Note that it's important that we check the condition again after
+ * having timed out, since the timeout could be due to preemption or similar
and
+ * we've never had a chance to check the condition before the timeout.
+ */
+#define _wait_for(COND, TO_MS, INTVL_MS) ({ \
+ unsigned long timeout__ = jiffies + msecs_to_jiffies(TO_MS) + 1;\
+ int ret__ = 0; \
+ while (!(COND)) { \
+ if (time_after(jiffies, timeout__)) { \
+ if (!(COND))\
+ ret__ = -ETIMEDOUT; \
+ break; \
+ } \
+ if (drm_can_sleep()) { \
+ usleep_range(INTVL_MS * 1000, \
+ (INTVL_MS + 1) * 1000); \
+ } else {\
+ cpu_relax();\
+ } \
+ } \
+ ret__; \
+})
+
+#define wait_for(COND, TO_MS, INTVL_MS) _wait_for(COND, TO_MS, INTVL_MS)
+
+static const u8 anx78xx_i2c_addresses[] = {
+ [I2C_IDX_TX_P0] = TX_P0,
+ [I2C_IDX_TX_P1] = TX_P1,
+ [I2C_IDX_TX_P2] = TX_P2,
+ [I2C_IDX_RX_P0] = RX_P0,
+ [I2C_IDX_
[PATCH 0/3] Add ANX7814 I2C bridge driver
Hi all, This patch set to introduces the anx7814 slimport transmitter driver. These new series will replace the old series that can be found here [1]. The reason why I introduce these new series is because the driver changed significantly. The old approach used a polled state machine ans was not really well using the kernel mode setting API. With this new driver I tried to use better the drm API and use an interrupt driven model. Wating for your comments... [1] https://lwn.net/Articles/666885/ Enric Balletbo i Serra (3): of: Add vendor prefix for Analogix Semiconductor devicetree: Add ANX7814 SlimPort transmitter binding. drm: bridge: anx78xx: Add anx78xx driver support. .../devicetree/bindings/vendor-prefixes.txt|1 + .../devicetree/bindings/video/bridge/anx7814.txt | 41 + drivers/gpu/drm/bridge/Kconfig |8 + drivers/gpu/drm/bridge/Makefile|1 + drivers/gpu/drm/bridge/anx78xx.c | 1433 drivers/gpu/drm/bridge/anx78xx.h | 719 ++ 6 files changed, 2203 insertions(+) create mode 100644 Documentation/devicetree/bindings/video/bridge/anx7814.txt create mode 100644 drivers/gpu/drm/bridge/anx78xx.c create mode 100644 drivers/gpu/drm/bridge/anx78xx.h -- 2.1.0
[PATCH 1/3] of: Add vendor prefix for Analogix Semiconductor
Analogix Semiconductor Inc. develops analog and mixed-signal devices for digital media and communications interconnect applications. Signed-off-by: Enric Balletbo i Serra --- Documentation/devicetree/bindings/vendor-prefixes.txt | 1 + 1 file changed, 1 insertion(+) diff --git a/Documentation/devicetree/bindings/vendor-prefixes.txt b/Documentation/devicetree/bindings/vendor-prefixes.txt index 72e2c5a..c6eac94 100644 --- a/Documentation/devicetree/bindings/vendor-prefixes.txt +++ b/Documentation/devicetree/bindings/vendor-prefixes.txt @@ -21,6 +21,7 @@ amlogic Amlogic, Inc. ampire Ampire Co., Ltd. amsAMS AG amstaosAMS-Taos Inc. +analogix Analogix Semiconductor, Inc. apmApplied Micro Circuits Corporation (APM) aptina Aptina Imaging arasan Arasan Chip Systems -- 2.1.0
[PATCH] drm/exynos: fix cancel page flip code
Driver code did not remove event from the list of pending events before destroy.
As a result drm core tried later to inspect invalid memory location.
The patch replaces removal code with call to core helper.
The bug was detected using KASAN:
[ 10.107249]
==
[ 10.107518] BUG: KASAN: use-after-free in drm_release+0xe9c/0x1000 at addr
ffc089154a18
[ 10.107784] Read of size 8 by task modetest/103
[ 10.107931]
=
[ 10.113191] BUG kmalloc-128 (Not tainted): kasan: bad access detected
[ 10.119608]
-
[ 10.119608]
[ 10.129243] Disabling lock debugging due to kernel taint
[ 10.134551] INFO: Allocated in drm_mode_page_flip_ioctl+0x500/0xa98 age=4
cpu=0 pid=103
[ 10.142532] alloc_debug_processing+0x18c/0x198
[ 10.147043] ___slab_alloc.constprop.28+0x360/0x380
[ 10.151906] __slab_alloc.isra.25.constprop.27+0x54/0xa0
[ 10.157197] kmem_cache_alloc_trace+0x370/0x3b0
[ 10.161709] drm_mode_page_flip_ioctl+0x500/0xa98
[ 10.166400] drm_ioctl+0x4c4/0xb68
[ 10.169787] do_vfs_ioctl+0x16c/0xeb8
[ 10.173429] SyS_ioctl+0x8c/0xa0
[ 10.176642] el0_svc_naked+0x24/0x28
[ 10.180204] INFO: Freed in exynos_drm_crtc_cancel_page_flip+0xe0/0x160 age=0
cpu=0 pid=103
[ 10.188447] free_debug_processing+0x174/0x388
[ 10.192871] __slab_free+0x2e8/0x438
[ 10.196431] kfree+0x350/0x360
[ 10.199469] exynos_drm_crtc_cancel_page_flip+0xe0/0x160
[ 10.204762] exynos_drm_preclose+0x58/0xa0
[ 10.208844] drm_release+0x1f0/0x1000
[ 10.212491] __fput+0x1c4/0x5b8
[ 10.215613] fput+0xc/0x18
[ 10.218654] task_work_run+0x130/0x198
[ 10.222385] do_exit+0x700/0x2278
[ 10.225681] do_group_exit+0xe4/0x2c8
[ 10.229327] SyS_exit_group+0x1c/0x20
[ 10.232973] el0_svc_naked+0x24/0x28
[ 10.236532] INFO: Slab 0xffbdc2a45500 objects=32 used=10
fp=0xffc089154a00 flags=0x4080
[ 10.245210] INFO: Object 0xffc089154a00 @offset=2560
fp=0xffc089157600
[ 10.245210]
...
[ 10.384532] CPU: 0 PID: 103 Comm: modetest Tainted: GB
4.5.0-rc3-00748-gd5e2881 #271
[ 10.398325] Call trace:
[ 10.400764] [] dump_backtrace+0x0/0x328
[ 10.406141] [] show_stack+0x14/0x20
[ 10.411176] [] dump_stack+0xb0/0xe8
[ 10.416210] [] print_trailer+0xf8/0x160
[ 10.421592] [] object_err+0x3c/0x50
[ 10.426626] [] kasan_report_error+0x248/0x550
[ 10.432527] [] __asan_report_load8_noabort+0x40/0x48
[ 10.439039] [] drm_release+0xe9c/0x1000
[ 10.19] [] __fput+0x1c4/0x5b8
[ 10.449280] [] fput+0xc/0x18
[ 10.454055] [] task_work_run+0x130/0x198
[ 10.459522] [] do_exit+0x700/0x2278
[ 10.464557] [] do_group_exit+0xe4/0x2c8
[ 10.469939] [] SyS_exit_group+0x1c/0x20
[ 10.475320] [] el0_svc_naked+0x24/0x28
Signed-off-by: Andrzej Hajda
---
drivers/gpu/drm/exynos/exynos_drm_crtc.c | 26 +++---
1 file changed, 7 insertions(+), 19 deletions(-)
diff --git a/drivers/gpu/drm/exynos/exynos_drm_crtc.c
b/drivers/gpu/drm/exynos/exynos_drm_crtc.c
index 50dd33d..e78c36d 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_crtc.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_crtc.c
@@ -229,24 +229,12 @@ void exynos_drm_crtc_cancel_page_flip(struct drm_crtc
*crtc,
struct drm_file *file)
{
struct exynos_drm_crtc *exynos_crtc = to_exynos_crtc(crtc);
- struct drm_pending_vblank_event *e;
- unsigned long flags;
+ struct drm_pending_vblank_event *e = exynos_crtc->event;
- spin_lock_irqsave(&crtc->dev->event_lock, flags);
- e = exynos_crtc->event;
- if (e && e->base.file_priv == file) {
- exynos_crtc->event = NULL;
- /*
-* event will be destroyed by core part
-* so below line should be removed later with core changes
-*/
- e->base.destroy(&e->base);
- /*
-* event_space will be increased by core part
-* so below line should be removed later with core changes.
-*/
- file->event_space += sizeof(e->event);
- atomic_dec(&exynos_crtc->pending_update);
- }
- spin_unlock_irqrestore(&crtc->dev->event_lock, flags);
+ if (!e || e->base.file_priv != file)
+ return;
+
+ exynos_crtc->event = NULL;
+ atomic_dec(&exynos_crtc->pending_update);
+ drm_event_cancel_free(crtc->dev, &e->base);
}
--
1.9.1
[PATCH 3/3] drm: bridge: anx78xx: Add anx78xx bridge driver support.
On Thu, Mar 24, 2016 at 11:41:46AM +0100, Enric Balletbo i Serra wrote:
> + /* Map slave addresses of ANX7814 */
> + for (i = 0; i < I2C_NUM_ADDRESSES; i++) {
> + anx78xx->i2c_dummy[i] = i2c_new_dummy(client->adapter,
> + anx78xx_i2c_addresses[i] >> 1);
> + if (!anx78xx->i2c_dummy[i]) {
> + DRM_ERROR("Failed to reserve i2c bus %02x.\n",
> + anx78xx_i2c_addresses[i]);
Missing error code here.
> + goto err_i2c;
> + }
I'm, of course, not a fan of the naming. The name should be based on
what the goto location does... In this case it turns it off. Which is
slightly weird because we have not turned it on yet... I always say
that you should have multiple error labels and you only undo things
which have been done.
Having a common exit path for the other functions where it was "goto out"
makes sense. But again in those cases I would prefer a meaningful label
name like "goto unlock;". In the kernel "goto out;" is meaningless, it
could do anything or everything or nothing. A lot of people like it
of course, but out: label code tends to be buggier than using a
meaningful name.
regards,
dan carpenter
[Bug 94667] Artifacts on applications on discrete
https://bugs.freedesktop.org/show_bug.cgi?id=94667 --- Comment #8 from Vladislav Kamenev --- Runned into Mar 23 02:06:51 xubuntu-stable kernel: [14263.767781] [drm:intel_pipe_update_end [i915]] *ERROR* Atomic update failure on pipe A (start=857290 end=857291) time 130 us, min 1017, max 1023, scanline start 1012, end 1024 today. BTW, im suffering from kernel(?) hangups while playing in some games. Cannot get any logs even under SSH. Should i open a new bug for that? Also. Forgot to pin lspci to my bug report. Here it is $ lspci | grep VGA 00:02.0 VGA compatible controller: Intel Corporation 2nd Generation Core Processor Family Integrated Graphics Controller (rev 09) 01:00.0 VGA compatible controller: Advanced Micro Devices, Inc. [AMD/ATI] Whistler [Radeon HD 6630M/6650M/6750M/7670M/7690M] -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <https://lists.freedesktop.org/archives/dri-devel/attachments/20160324/81d3f941/attachment.html>
[Bug 94667] Artifacts on applications on discrete
https://bugs.freedesktop.org/show_bug.cgi?id=94667 --- Comment #9 from Vladislav Kamenev --- Created attachment 122519 --> https://bugs.freedesktop.org/attachment.cgi?id=122519&action=edit Xorg.conf in case it would be useful -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <https://lists.freedesktop.org/archives/dri-devel/attachments/20160324/bdcbda6f/attachment.html>
[PATCH] drm: bridge: anx78xx: fix ptr_ret.cocci warnings
drivers/gpu/drm/bridge/anx78xx.c:632:1-3: WARNING: PTR_ERR_OR_ZERO can be used Use PTR_ERR_OR_ZERO rather than if(IS_ERR(...)) + PTR_ERR Generated by: scripts/coccinelle/api/ptr_ret.cocci CC: Enric Balletbo i Serra Signed-off-by: Fengguang Wu --- anx78xx.c |5 + 1 file changed, 1 insertion(+), 4 deletions(-) --- a/drivers/gpu/drm/bridge/anx78xx.c +++ b/drivers/gpu/drm/bridge/anx78xx.c @@ -629,10 +629,7 @@ static int anx78xx_init_gpio(struct anx7 /* GPIO for V10 power control */ pdata->gpiod_v10 = devm_gpiod_get_optional(dev, "v10", GPIOD_OUT_LOW); - if (IS_ERR(pdata->gpiod_v10)) - return PTR_ERR(pdata->gpiod_v10); - - return 0; + return PTR_ERR_OR_ZERO(pdata->gpiod_v10); } static int anx78xx_dp_link_training(struct anx78xx *anx78xx)
[PATCH 3/3] drm: bridge: anx78xx: Add anx78xx bridge driver support.
Hi Enric, [auto build test WARNING on drm/drm-next] [also build test WARNING on v4.5 next-20160324] [if your patch is applied to the wrong git tree, please drop us a note to help improving the system] url: https://github.com/0day-ci/linux/commits/Enric-Balletbo-i-Serra/Add-ANX7814-I2C-bridge-driver/20160324-184430 base: git://people.freedesktop.org/~airlied/linux.git drm-next coccinelle warnings: (new ones prefixed by >>) >> drivers/gpu/drm/bridge/anx78xx.c:632:1-3: WARNING: PTR_ERR_OR_ZERO can be >> used Please review and possibly fold the followup patch. --- 0-DAY kernel test infrastructureOpen Source Technology Center https://lists.01.org/pipermail/kbuild-all Intel Corporation
[PATCH] drm: Add new DCS commands in the enum list
On 03/24/2016 10:18 AM, Deepak M wrote:
> Adding new DCS commands which are specified in the
> DCS 1.3 spec related to CABC.
>
> Cc: Thierry Reding
> Cc: David Airlie
> Cc: Ville Syrjälä
> Cc: Daniel Vetter
> Suggested-by: Jani Nikula
> Signed-off-by: Deepak M
> ---
> include/video/mipi_display.h | 8
> 1 file changed, 8 insertions(+)
>
> diff --git a/include/video/mipi_display.h b/include/video/mipi_display.h
> index ddcc8ca..bb8195b 100644
> --- a/include/video/mipi_display.h
> +++ b/include/video/mipi_display.h
> @@ -117,6 +117,14 @@ enum {
> MIPI_DCS_GET_SCANLINE = 0x45,
> MIPI_DCS_READ_DDB_START = 0xA1,
> MIPI_DCS_READ_DDB_CONTINUE = 0xA8,
> + MIPI_DCS_GET_DISPLAY_BRIGHTNESS = 0x52,
> + MIPI_DCS_GET_CABC_MIN_BRIGHTNESS = 0x5F,
> + MIPI_DCS_GET_POWER_SAVE = 0x56,
> + MIPI_DCS_GET_CONTROL_DISPLAY= 0x54,
> + MIPI_DCS_SET_DISPLAY_BRIGHTNESS = 0x51,
> + MIPI_DCS_SET_CABC_MIN_BRIGHTNESS = 0x5E,
> + MIPI_DCS_WRITE_POWER_SAVE = 0x55,
> + MIPI_DCS_WRITE_CONTROL_DISPLAY = 0x53,
Please keep the list sorted by value.
Maybe it would be worth to add comment indicating spec version?
MIPI_DCS_GET_DISPLAY_BRIGHTNESS = 0x52, /* Spec 1.3 */
Regards
Andrzej
> };
>
> /* MIPI DCS pixel formats */
>
[Bug 94667] Artifacts on applications on discrete
https://bugs.freedesktop.org/show_bug.cgi?id=94667 --- Comment #10 from Vladislav Kamenev --- Created attachment 122521 --> https://bugs.freedesktop.org/attachment.cgi?id=122521&action=edit Other case of artifacts The best i could screenshot. If you look precisely then u will see that right-bottom part of the screen looks weird -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <https://lists.freedesktop.org/archives/dri-devel/attachments/20160324/30a0aff5/attachment.html>
[PATCH 1/1] drm: fsl-dcu: Use flat cache
Using REGCACHE_RBTREE for MMIO regmap is not valid as spinlock's will be
used during cache allocation.
This fixes the following bug:
BUG: sleeping function called from invalid context at mm/slab.h:388
in_atomic(): 1, irqs_disabled(): 128, pid: 192, name: udevd
[...]
Signed-off-by: Alexander Stein
---
Please refer also to the discussion at
https://lists.freedesktop.org/archives/dri-devel/2016-January/098696.html
drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_drv.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_drv.c
b/drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_drv.c
index e8d9337..ea65140 100644
--- a/drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_drv.c
+++ b/drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_drv.c
@@ -40,7 +40,7 @@ static const struct regmap_config fsl_dcu_regmap_config = {
.reg_bits = 32,
.reg_stride = 4,
.val_bits = 32,
- .cache_type = REGCACHE_RBTREE,
+ .cache_type = REGCACHE_FLAT,
.volatile_reg = fsl_dcu_drm_is_volatile_reg,
};
--
2.7.3
[RFC 0/6] drm/fences: add in-fences to DRM
Hi Maarten,
2016-03-24 Maarten Lankhorst :
> Hey,
>
> Op 23-03-16 om 19:47 schreef Gustavo Padovan:
> > From: Gustavo Padovan
> >
> > Hi,
> >
> > This is a first proposal to discuss the addition of in-fences support
> > to DRM. It adds a new struct to fence.c to abstract the use of sync_file
> > in DRM drivers. The new struct fence_collection contains a array with all
> > fences that a atomic commit needs to wait on
> >
> > /**
> > * struct fence_collection - aggregate fences together
> > * @num_fences: number of fence in the collection.
> > * @user_data: user data.
> > * @func: user callback to put user data.
> > * @fences: array of @num_fences fences.
> > */
> > struct fence_collection {
> >int num_fences;
> >void *user_data;
> >collection_put_func_t func;
> >struct fence *fences[];
> > };
> >
> >
> > The fence_collection is allocated and filled by sync_file_fences_get() and
> > atomic_commit helpers can use fence_collection_wait() to wait the fences to
> > signal.
> >
> > These patches depends on the sync ABI rework:
> >
> > https://www.spinics.net/lists/dri-devel/msg102795.html
> >
> > and the patch to de-stage the sync framework:
> >
> > https://www.spinics.net/lists/dri-devel/msg102799.html
> >
> >
> > I also hacked together some sync support into modetest for testing:
> >
> > https://git.collabora.com/cgit/user/padovan/libdrm.git/log/?h=atomic
> >
> Why did you choose to add fence_collection, rather than putting sync_file in
> state?
>
> There used to be a sync_fence_wait function, which would mean you'd have
> everything you need.
We discussed this on #dri-devel a few days ago. The idea behind this is
to abstract sync_file from any drm driver and let only drm core deal
with sync_file.
In the next iteration even fence_collection will be gone, so the driver
we deal only with struct fence and the fence_collection will be a
subclass of fence.
Gustavo
[RFC 0/6] drm/fences: add in-fences to DRM
Hi Inki, 2016-03-24 Inki Dae : > Hi, > > 2016ë 03ì 24ì¼ 03:47ì Gustavo Padovan ì´(ê°) ì´ ê¸: > > From: Gustavo Padovan > > > > Hi, > > > > This is a first proposal to discuss the addition of in-fences support > > to DRM. It adds a new struct to fence.c to abstract the use of sync_file > > in DRM drivers. The new struct fence_collection contains a array with all > > fences that a atomic commit needs to wait on > > As I mentioned already like below, > http://www.spinics.net/lists/dri-devel/msg103225.html > > I don't see why Android specific thing is tried to propagate to Linux DRM. In > Linux mainline, it has already implicit sync interfaces for DMA devices > called dma fence which forces registering a fence obejct to DMABUF through a > reservation obejct when a dmabuf object is created. However, Android sync > driver creates a new file for a sync object and this would have different > point of view. > > Is there anyone who can explan why Android specific thing is tried to spread > into Linux DRM? Was there any consensus to use Android sync driver - which > uses explicit sync interfaces - as Linux standard? Because we want explicit fencing as the Linux standard in the future to be able to do smart scheduling, e.g., send async jobs to the gpu and at the same time send async atomic commits with sync_file fd attached so they can wait the GPU to finish and we don't block in userspace anymore, quite similar to what Android does. This would still use dma-buf fences in the driver level, but it has a lot more advantages than implicit fencing. Gustavo
Who is going to merge it [Was: Re: [PATCH v14 0/17] Add Analogix Core Display Port Driver]
On 03/22/2016 08:41 PM, Dave Airlie wrote: >>> So although it's small framework or just subdirectory, we would need >>> someone who can manage the framework to avoid further confusion if >>> necessary. >> So maybe it just doesn't need a maintainer, and maybe those the owner >> of the bridge driver should be responsible for choosing the tree which >> it's merged through along with updates. That's how dw-hdmi has been >> managed on the whole. >> >> It also means that the bridge driver maintainer is able to test changes >> to the bridge driver, rather than having some over-arching bridge >> subdirectory maintainer who doesn't have a clue whether the changes >> work on the hardware. >> >> IMHO, having bridge driver authors/maintainers look after their own >> code has many advantages. > The author just send me a pull request with acks from a git tree > that hopefully both people agreed and tested from. No need to > send this via another maintainer layer. > > Dave. > Wow, thanks all ! such cool news :-D I'll prepare my pull request soon - Yakir
[PATCH 2/4 v3] drm: Add DT bindings documentation for ARC PGU display controller
Hi Rob,
On Mon, 2016-03-21 at 08:04 -0500, Rob Herring wrote:
> On Fri, Mar 11, 2016 at 06:42:37PM +0300, Alexey Brodkin wrote:
> >
> > This add DT bindings documentation for ARC PGU display controller.
> >
> > Signed-off-by: Alexey Brodkin
> > Cc: Rob Herring
> > Cc: Pawel Moll
> > Cc: Mark Rutland
> > Cc: Ian Campbell
> > Cc: Kumar Gala
> > Cc: David Airlie
> > Cc: dri-devel at lists.freedesktop.org
> > Cc: devicetree at vger.kernel.org
> > Cc: linux-snps-arc at lists.infradead.org
> > ---
> >
> > Changes v2 -> v3:
> > Â * Reverted back to initial larger version of example
> > Â Â Â with minor fixes (thanks Rob for spotting those).
> >
> > Changes v1 -> v2:
> > Â * Removed everything except PGU node itself.
> >
> >  .../devicetree/bindings/display/snps,arcpgu.txt    | 72
> > ++
> > Â 1 file changed, 72 insertions(+)
> > Â create mode 100644
> > Documentation/devicetree/bindings/display/snps,arcpgu.txt
> >
> > diff --git a/Documentation/devicetree/bindings/display/snps,arcpgu.txt
> > b/Documentation/devicetree/bindings/display/snps,arcpgu.txt
> > new file mode 100644
> > index 000..b130924
> > --- /dev/null
> > +++ b/Documentation/devicetree/bindings/display/snps,arcpgu.txt
> > @@ -0,0 +1,72 @@
> > +ARC PGU
> > +
> > +This is a display controller found on several development boards produced
> > +by Synopsys. The ARC PGU is an RGB streamer that reads the data from a
> > +framebuffer and sends it to a single digital encoder (usually HDMI).
> > +
> > +Required properties:
> > +Â Â - compatible: "snps,arcpgu"
> > +Â Â - reg: Physical base address and length of the controller's registers.
> > +Â Â - clocks: A list of phandle + clock-specifier pairs, one for each
> > +Â Â Â Â entry in 'clock-names'.
> > +Â Â - clock-names: A list of clock names. For ARC PGU it should contain:
> > +Â Â Â Â Â Â - "pxlclk" for the clock feeding the output PLL of the
> > controller.
> > +Â Â - encoder-slave: Phandle of encoder chip.
> Drop this as discussed.
Ok I'll do that.
But what about my example below?
Do I need to remove encoder node from it as well?
> >
> > +
> > +Required sub-nodes:
> > +Â Â - port: The PGU connection to an encoder chip.
> > +
> > +Example:
> > +
> > +/ {
> > + ...
> > +
> > + pgu at {
> > + compatible = "snps,arcpgu";
> > + reg = <0x 0x400>;
> > + clocks = <&clock_node>;
> > + clock-names = "pxlclk";
> > + encoder-slave = <&encoder_node>;
> > +
> > + port {
> > + pgu_output: endpoint {
> > + remote-endpoint = <&hdmi_enc_input>;
> > + };
> > + };
> > + };
> > +
> > + /* HDMI encoder on I2C bus */
> > + i2c at {
> > + compatible = "...";
> > +
> > + encoder_node:encoder_node at 0xXX{
> Don't use underscores in node names. Just "hdmi at xx"
Ok still I may keep label "encoder_node" here, right?
-Alexey
[PATCH v14 0/17] Add Analogix Core Display Port Driver
Am Montag, 15. Februar 2016, 19:08:05 schrieb Yakir Yang: > 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 different between > exynos and rk3288. > 1. RK3288 have five special pll registers which not indicate 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). > > Due to Mark Yao have introduced the ATOMIC support to Rockchip drm, so it's > okay to use the ATOMIC helpers functions in connector_funcs. No need to > splict the connector init to platform driver anymore, and this is the > biggest change since version 11. > > This v14 didn't have lots of new changes which seems not the correct time to > upgrade the version number, but I have changed ordering of patches (adding > 2 more, and removing 2 out). Especially to prevent confusing people, so I > updated the whole series. I guess I never said that explicitly, but of course I have tested this numerous times, so This series Tested-by: Heiko Stuebner
[PATCH 02/23] ARM: dts: n950: add display support
Hi, On Thu, Mar 24, 2016 at 12:03:01PM +0200, Jani Nikula wrote: > On Wed, 23 Mar 2016, Sebastian Reichel wrote: > > On Wed, Mar 23, 2016 at 02:40:53PM +0200, Jani Nikula wrote: > >> On Thu, 17 Mar 2016, Sebastian Reichel wrote: > >> > On Thu, Mar 17, 2016 at 02:14:26PM +0200, Laurent Pinchart wrote: > >> >> [...] > >> >> > + > >> >> > + /* panel is 480x464 with top and bottom 5 lines not > >> >> > visible */ > >> >> > >> >> I assume you mean 480x864 ? > >> > > >> > Yes, nice catch. Basically the screen is 480x864, but only > >> > 480x854 are visible. > >> > >> It's been a while, but I thought the full 480x864 was actually usable > >> and visible. > > > > I tried that first and the first few lines were missing. The stock > > kernel also uses only 854px: > > > > https://github.com/nemomobile/kernel-adaptation-n950-n9/blob/mer-n9-2.6.32-20121301/arch/arm/mach-omap2/board-rm680-video.c > > > > (search for partial_area) > > Heh, I was reminded by old colleagues that it was actually my commit > back in the day that changed the resolution 864->854 in the stock > kernel. And that I did it reluctantly, because there really was no > technical reason to do the change. > > I don't really care all that much either way anymore. I just thought > you'd like to get those 4800 pixels back that you've been missing all > these years. Plus 864 was nicer to deal with because it has 2^5 as a > prime factor while 854 only has 2. As I said: I did use 864 initially. That results in missing pixels. This is what I observed before switching to 854: In fbcon the first line was rendered half (only the bottom part of each character was visible). Then, when I rotated fbcon (fbcon has native rotation support, which does not work with DRM, but just renders the text differently), the left part of each character was missing. In my case the "[" prefix of kernel messages was rendered as two dots. At least the vertical line was not visible at all. I _think_, that your HW team decided to cover the first and the last few pixels of the 864 display with plastic. So technically it's a 864 display, but effectively it's 854. -- Sebastian -- next part -- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: not available URL: <https://lists.freedesktop.org/archives/dri-devel/attachments/20160324/96a10107/attachment.sig>
[PATCH 02/23] ARM: dts: n950: add display support
On Thu, 24 Mar 2016, Sebastian Reichel wrote: > As I said: I did use 864 initially. That results in missing pixels. Sorry, I didn't mean to question this. Go with what works, not with some old fart's ramblings! > I _think_, that your HW team decided to cover the first and the > last few pixels of the 864 display with plastic. So technically > it's a 864 display, but effectively it's 854. (*shudder* at "your HW team" ;) It's plausible, the covers did change slightly for the developer edition. Good luck with the upstreaming efforts! BR, Jani. -- Jani Nikula, Intel Open Source Technology Center
[Bug 93178] Textures are filled with garbage
https://bugs.freedesktop.org/show_bug.cgi?id=93178 J�zef Kucia changed: What|Removed |Added Status|RESOLVED|CLOSED --- Comment #6 from J�zef Kucia --- (In reply to Nicolai H�hnle from comment #5) > This is a game bug. Thanks for debugging this. I am sorry for reporting invalid bug. This is actually a bug in Wine. For now the workaround is to enable StrictDrawOrdering. I will do more investigation before reporting a bug next time. -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <https://lists.freedesktop.org/archives/dri-devel/attachments/20160324/de15bfd1/attachment.html>
Upstreaming DAL
On Wed, Mar 23, 2016 at 01:27:21PM -0400, Alex Deucher wrote: > Our goal is to transition to our new DAL display stack. It is the > path we are validating internally for both the open and hybrid stacks > and will be the only display stack we support going forward with new > asics. When we initially released the patches, there were some rough > edges and quite a few things were pointed out that need to be fixed. > Some are relatively easy to fix, others will take time. Our goal is > to make those changes. We'd like to target 4.7 for upstreaming DAL. > To that end, I think it would be easier to review and track our > progress if I maintained a public DAL branch and send out patches > against that branch rather than respinning giant squashed patches > every time we fix something. It's much harder to track what progress > has been made. DAL is currently at ~400 patches. We previously tried > to squash that down into a bunch of larger commits, but I'm not sure > that is particularly easy to review. I'm also not sure it's worth > spamming the list with 400 patches. I've posted our current DAL tree > here for review: > https://cgit.freedesktop.org/~agd5f/linux/log/?h=drm-next-4.7-wip-dal > I can certainly send out the patches if that is preferred. We will be > sending out all new patches to the list as the further clean up tasks > and new features are implemented. > > Our goal is to fix the following items in time for 4.7. Additional > fixes and re-factoring will continue as we work to address all of the > comments and concerns. So the dal code is kind of revulsing, for two reasons. The first one as to do with the overall state of the code. It is full of dead code, unuse struct, unuse enum, unuse union, ... I pushed a branch on fdo which just barely scratch the surface at removing dead stuff (see dal branch at https://cgit.freedesktop.org/~glisse/linux/log/?h=dal). It is also poorly commented, not even per file top comments giving information about what each file is about, like a brief overlook. If i focus on the patchset and not on the final result then things are even worse. First a mega patch that adds all bunch of files instead of splitting things up in digestible chunk. Second you have several files that are added, then remove in latter patch, and some are added again latter with other name. Well this can be fix too, by redoing the patchset. But the second reason is far more troubling and so fundamental that DAL should just never be consider for merging, not even in STAGING. It is about the whole design of it. DAL is like a full replacement of DRM modesetting code all wrap into several layers of abstraction. Seriously DAL is abstraction on top of abstraction on top of abstraction (grep for ->base.base.base). It is just wrong. Like Dave said, it is so obviously wrong that you have to poke hole into your abstraction layer for hardware specific code. So you have hw specific code that call abstraction layer that endup just calling the function above the one you were looking at. The whole layer on top of layer become a maze in which you get lost. This is not how you do thing. If the DRM abstraction are not good enough then fix them working with others. Hardware is not fundamentaly different, it is not like their are specific brand of display for specific brand of GPU. This is a whole industry that rely on standardization. The DRM core modesetting have grown over the years to adapt not only to new userspace requirement (atomic) but also to new display technology like DP and MST. So if you feel core DRM modesetting abstractions does not allow for a specific feature then propose change there, in the core DRM modesetting abstraction. Also DAL seems to implement quite a few things that should be move as drm helpers function (whole infoframes stuff feels that way). This is a linux device driver, we share things and improve on each others. New modesetting code for amdgpu should not be about shoehorn an existing design behind an abstraction layer to interface with core modesetting. It should be about implementing core modesetting API (atomic being the flavor of the day). All this with only small abstraction inside device driver to leverage architectural similarities accross different GPU generation. But it should not be a monster of several thousand lines of code with dozens and dozens of functions callback struct. I do not see why existing modesetting design (modulo the fact that we need to implement atomic modesetting) does not allow you to implement any of the features you listed (freesync, sync timing accross different display, power features, 6 displays, ...). None of the abstraction are needed to implement any of this. If i am mistaken, take one thing and explain in details why ! What would be the roadblocks with the existing code. To sum up DAL is not only in an unreviewable state (code mess, patch mess) but it is fundamently wrong. I would not feel confortable having to fix thing inside it a
[RFC 0/6] drm/fences: add in-fences to DRM
On Thu, Mar 24, 2016 at 4:18 AM, Inki Dae wrote:
> Hi,
>
> 2016ë
03ì 24ì¼ 03:47ì Gustavo Padovan ì´(ê°) ì´ ê¸:
>> From: Gustavo Padovan
>>
>> Hi,
>>
>> This is a first proposal to discuss the addition of in-fences support
>> to DRM. It adds a new struct to fence.c to abstract the use of sync_file
>> in DRM drivers. The new struct fence_collection contains a array with all
>> fences that a atomic commit needs to wait on
>
> As I mentioned already like below,
> http://www.spinics.net/lists/dri-devel/msg103225.html
>
> I don't see why Android specific thing is tried to propagate to Linux DRM. In
> Linux mainline, it has already implicit sync interfaces for DMA devices
> called dma fence which forces registering a fence obejct to DMABUF through a
> reservation obejct when a dmabuf object is created. However, Android sync
> driver creates a new file for a sync object and this would have different
> point of view.
>
> Is there anyone who can explan why Android specific thing is tried to spread
> into Linux DRM? Was there any consensus to use Android sync driver - which
> uses explicit sync interfaces - as Linux standard?
>
btw, there is already plane_state->fence .. which I don't think has
any users yet, but I start to use it in my patchset that converts
drm/msm to 'struct fence'
That said, we do need syncpt as the way to expose fences to userspace
for explicit synchronization, but I'm not entirely sure that the
various drivers ever need to see that (vs just struct fence), at least
on the kms side of things.
BR,
-R
> Thanks,
> Inki Dae
>
>>
>> /**
>> * struct fence_collection - aggregate fences together
>> * @num_fences: number of fence in the collection.
>> * @user_data: user data.
>> * @func: user callback to put user data.
>> * @fences: array of @num_fences fences.
>> */
>> struct fence_collection {
>>int num_fences;
>>void *user_data;
>>collection_put_func_t func;
>>struct fence *fences[];
>> };
>>
>>
>> The fence_collection is allocated and filled by sync_file_fences_get() and
>> atomic_commit helpers can use fence_collection_wait() to wait the fences to
>> signal.
>>
>> These patches depends on the sync ABI rework:
>>
>> https://www.spinics.net/lists/dri-devel/msg102795.html
>>
>> and the patch to de-stage the sync framework:
>>
>> https://www.spinics.net/lists/dri-devel/msg102799.html
>>
>>
>> I also hacked together some sync support into modetest for testing:
>>
>> https://git.collabora.com/cgit/user/padovan/libdrm.git/log/?h=atomic
>>
>>
>> Gustavo
>>
>>
>> Gustavo Padovan (6):
>> drm/fence: add FENCE_FD property to planes
>> dma-buf/fence: add struct fence_collection
>> dma-buf/sync_file: add sync_file_fences_get()
>> dma-buf/fence: add fence_collection_put()
>> dma-buf/fence: add fence_collection_wait()
>> drm/fence: support fence_collection on atomic commit
>>
>> drivers/dma-buf/fence.c | 33 +
>> drivers/dma-buf/sync_file.c | 36
>>
>> drivers/gpu/drm/drm_atomic.c| 13 +
>> drivers/gpu/drm/drm_atomic_helper.c | 10 ++
>> drivers/gpu/drm/drm_crtc.c | 7 +++
>> include/drm/drm_crtc.h | 5 -
>> include/linux/fence.h | 19 +++
>> include/linux/sync_file.h | 8
>> 8 files changed, 126 insertions(+), 5 deletions(-)
>>
> ___
> dri-devel mailing list
> dri-devel at lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 94671] [radeonsi] Blue-ish textures in Shadow of Mordor
https://bugs.freedesktop.org/show_bug.cgi?id=94671 Nicolai H�hnle changed: What|Removed |Added Resolution|--- |FIXED Status|NEW |RESOLVED --- Comment #10 from Nicolai H�hnle --- Fixed in Mesa master, commit 6b763c0 -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <https://lists.freedesktop.org/archives/dri-devel/attachments/20160324/ae6d1d98/attachment-0001.html>
[Bug 94484] Kernel BUG with latest radeon driver
https://bugs.freedesktop.org/show_bug.cgi?id=94484 --- Comment #5 from Tyler Brock --- Anything I can do to help? Bisecting would be hard as its not reproducible 100% of the time. It would essentially take a day to test each revision. -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <https://lists.freedesktop.org/archives/dri-devel/attachments/20160324/87c48bd3/attachment-0001.html>
[PATCH v4 0/5] Move workarounds from intel_dp_dpcd_read_wake() into drm's DP helpers
This series of patches takes all of the workarounds we used in intel_dp_dpcd_read_wake() for working around misbehaving sinks into drm's DP aux transaction helpers, so that they can be applied to all aux transactions across each driver. While this patch series was intended to fix issues with the ThinkPad T560 not bringing displays connected to it's dock back up properly after suspend, this should fix a lot of other various DP issues by ensuring that we retry transactions appropriately in every possible failure scenario. Changes since v3 - Split the patch that moves the logic out of intel_dp_dpcd_read_wake() into multiple patches for each workaround that we apply, so that bisecting this change isn't difficult in the event that this breaks something - Made sure that drm_dp_dpcd_read() only returns the error it encountered during the first attempted aux transaction, since the error that following retries encounter might be different from the original Changes since v2 - Reworked the patch again to incorporate all of the behavior of intel_dp_dpcd_read_wake() into drm_dp_dpcd_read() and drm_dp_dpcd_access() Changes since v1 - Patch has been reworked to take the retry logic out of intel_dp_mst_resume() and into drm_dp_dpcd_access(), based off a suggestion from Daniel Vetter - Commit message is much longer and gives a better description of the issue this was originally intended to workaround. Lyude (5): drm/dp_helper: Increase retry interval to 1000us drm/dp_helper: Always wait before retrying native aux transactions drm/dp_helper: Retry aux transactions on all errors drm/dp_helper: Perform throw-away read before actual read in drm_dp_dpcd_read() drm/i915: Get rid of intel_dp_dpcd_read_wake() drivers/gpu/drm/drm_dp_helper.c | 55 drivers/gpu/drm/i915/intel_dp.c | 79 - 2 files changed, 54 insertions(+), 80 deletions(-) -- 2.5.5
[PATCH v4 1/5] drm/dp_helper: Increase retry interval to 1000us
This is part of a patch series to migrate all of the workarounds for commonly seen behavior from bad sinks in intel_dp_dpcd_read_wake() to drm's DP helper. Signed-off-by: Lyude --- drivers/gpu/drm/drm_dp_helper.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/gpu/drm/drm_dp_helper.c b/drivers/gpu/drm/drm_dp_helper.c index 7d58f59..d1128fb 100644 --- a/drivers/gpu/drm/drm_dp_helper.c +++ b/drivers/gpu/drm/drm_dp_helper.c @@ -160,7 +160,7 @@ int drm_dp_bw_code_to_link_rate(u8 link_bw) } EXPORT_SYMBOL(drm_dp_bw_code_to_link_rate); -#define AUX_RETRY_INTERVAL 500 /* us */ +#define AUX_RETRY_INTERVAL 1000 /* us */ /** * DOC: dp helpers -- 2.5.5
[PATCH v4 2/5] drm/dp_helper: Always wait before retrying native aux transactions
This is part of a patch series to migrate all of the workarounds for
commonly seen behavior from bad sinks in intel_dp_dpcd_read_wake() to
drm's DP helper.
Some sinks need some time during the process of resuming the system from
sleep before they're ready to handle transactions. While it would be
nice if they responded with NACKs in these scenarios, this isn't always
the case as a few sinks will just timeout on all of the transactions
they receive until they're ready.
Signed-off-by: Lyude
---
drivers/gpu/drm/drm_dp_helper.c | 11 +--
1 file changed, 5 insertions(+), 6 deletions(-)
diff --git a/drivers/gpu/drm/drm_dp_helper.c b/drivers/gpu/drm/drm_dp_helper.c
index d1128fb..3b915e2 100644
--- a/drivers/gpu/drm/drm_dp_helper.c
+++ b/drivers/gpu/drm/drm_dp_helper.c
@@ -179,7 +179,7 @@ static int drm_dp_dpcd_access(struct drm_dp_aux *aux, u8
request,
{
struct drm_dp_aux_msg msg;
unsigned int retry;
- int err;
+ int err = 0;
memset(&msg, 0, sizeof(msg));
msg.address = offset;
@@ -194,6 +194,10 @@ static int drm_dp_dpcd_access(struct drm_dp_aux *aux, u8
request,
* sufficient, bump to 32 which makes Dell 4k monitors happier.
*/
for (retry = 0; retry < 32; retry++) {
+ if (err != 0 && err != -ETIMEDOUT) {
+ usleep_range(AUX_RETRY_INTERVAL,
+AUX_RETRY_INTERVAL + 100);
+ }
mutex_lock(&aux->hw_mutex);
err = aux->transfer(aux, &msg);
@@ -205,7 +209,6 @@ static int drm_dp_dpcd_access(struct drm_dp_aux *aux, u8
request,
return err;
}
-
switch (msg.reply & DP_AUX_NATIVE_REPLY_MASK) {
case DP_AUX_NATIVE_REPLY_ACK:
if (err < size)
@@ -214,10 +217,6 @@ static int drm_dp_dpcd_access(struct drm_dp_aux *aux, u8
request,
case DP_AUX_NATIVE_REPLY_NACK:
return -EIO;
-
- case DP_AUX_NATIVE_REPLY_DEFER:
- usleep_range(AUX_RETRY_INTERVAL, AUX_RETRY_INTERVAL +
100);
- break;
}
}
--
2.5.5
[PATCH v4 3/5] drm/dp_helper: Retry aux transactions on all errors
This is part of a patch series to migrate all of the workarounds for
commonly seen behavior from bad sinks in intel_dp_dpcd_read_wake() to
drm's DP helper.
We cannot rely on sinks NACKing or deferring when they can't receive
transactions, nor can we rely on any other sort of consistent error to
know when we should stop retrying. As such, we need to just retry
unconditionally on errors. We also make sure here to return the error we
encountered during the first transaction, since it's possible that
retrying the transaction might return a different error then we had
originally.
This, along with the previous patch, work around a weird bug with the
ThinkPad T560's and it's dock. When resuming the laptop, it appears that
there's a short period of time where we're unable to complete any aux
transactions, as they all immediately timeout. The only machine I'm able
to reproduce this on is the T560 as other production Skylake models seem
to be fine. The period during which AUX transactions fail appears to be
around 22ms long. AFAIK, the dock for the T560 never actually turns off,
the only difference is that it's in SST mode at the start of the resume
process, so it's unclear as to why it would need so much time to come
back up.
There's been a discussion on this issue going on for a while on the
intel-gfx mailing list about this that has, in addition to including
developers from Intel, also had the correspondence of one of the
hardware engineers for Intel:
http://www.spinics.net/lists/intel-gfx/msg88831.html
http://www.spinics.net/lists/intel-gfx/msg88410.html
We've already looked into a couple of possible explanations for the
problem:
- Calling intel_dp_mst_resume() before right fix.
intel_runtime_pm_enable_interrupts(). This was the first fix I tried,
and while it worked it definitely wasn't the right fix. This worked
because DP aux transactions don't actually require interrupts to work:
static uint32_t
intel_dp_aux_wait_done(struct intel_dp *intel_dp, bool has_aux_irq)
{
struct intel_digital_port *intel_dig_port =
dp_to_dig_port(intel_dp);
struct drm_device *dev = intel_dig_port->base.base.dev;
struct drm_i915_private *dev_priv = dev->dev_private;
i915_reg_t ch_ctl = intel_dp->aux_ch_ctl_reg;
uint32_t status;
bool done;
#define C (((status = I915_READ_NOTRACE(ch_ctl)) &
DP_AUX_CH_CTL_SEND_BUSY) == 0)
if (has_aux_irq)
done = wait_event_timeout(dev_priv->gmbus_wait_queue, C,
msecs_to_jiffies_timeout(10));
else
done = wait_for_atomic(C, 10) == 0;
if (!done)
DRM_ERROR("dp aux hw did not signal timeout (has irq:
%i)!\n",
has_aux_irq);
#undef C
return status;
}
When there's no interrupts enabled, we end up timing out on the
wait_event_timeout() call, which causes us to check the DP status
register once to see if the transaction was successful or not. Since
this adds a 10ms delay to each aux transaction, it ends up adding a
long enough delay to the resume process for aux transactions to become
functional again. This gave us the illusion that enabling interrupts
had something to do with making things work again, and put me on the
wrong track for a while.
- Interrupts occurring when we try to perform the aux transactions
required to put the dock back into MST mode. This isn't the problem,
as the only interrupts I've observed that come during this timeout
period are from the snd_hda_intel driver, and disabling that driver
doesn't appear to change the behavior at all.
- Skylake's PSR block causing issues by performing aux transactions
while we try to bring the dock out of MST mode. Disabling PSR through
i915's command line options doesn't seem to change the behavior
either, nor does preventing the DMC firmware from being loaded.
Since this investigation went on for about 2 weeks, we decided it would
be better for the time being to just workaround this issue by making
sure AUX transactions wait a short period of time before retrying.
Signed-off-by: Lyude
---
drivers/gpu/drm/drm_dp_helper.c | 39 +--
1 file changed, 21 insertions(+), 18 deletions(-)
diff --git a/drivers/gpu/drm/drm_dp_helper.c b/drivers/gpu/drm/drm_dp_helper.c
index 3b915e2..86656ca 100644
--- a/drivers/gpu/drm/drm_dp_helper.c
+++ b/drivers/gpu/drm/drm_dp_helper.c
@@ -178,8 +178,8 @@ static int drm_dp_dpcd_access(struct drm_dp_aux *aux, u8
request,
unsigned int offset, void *buffer, size_t size)
{
struct drm_dp_aux_msg msg;
- unsigned int retry;
- int err = 0;
+ unsigned int retry, native_reply;
+ int err = 0, ret = 0;
memset(&msg, 0, sizeof(
[PATCH v4 4/5] drm/dp_helper: Perform throw-away read before actual read in drm_dp_dpcd_read()
This is part of a patch series to migrate all of the workarounds for
commonly seen behavior from bad sinks in intel_dp_dpcd_read_wake() to drm's
DP helper.
Some sinks will just return garbage for the first aux tranaction they
receive when coming out of sleep mode, so we need to perform an additional
read before the actual read to workaround this.
Signed-off-by: Lyude
---
drivers/gpu/drm/drm_dp_helper.c | 7 +++
1 file changed, 7 insertions(+)
diff --git a/drivers/gpu/drm/drm_dp_helper.c b/drivers/gpu/drm/drm_dp_helper.c
index 86656ca..702c78a 100644
--- a/drivers/gpu/drm/drm_dp_helper.c
+++ b/drivers/gpu/drm/drm_dp_helper.c
@@ -244,6 +244,13 @@ static int drm_dp_dpcd_access(struct drm_dp_aux *aux, u8
request,
ssize_t drm_dp_dpcd_read(struct drm_dp_aux *aux, unsigned int offset,
void *buffer, size_t size)
{
+ /*
+* Sometimes we just get the same incorrect byte repeated over the
+* entire buffer. Doing one throw away read initially seems to "solve"
+* it.
+*/
+ drm_dp_dpcd_access(aux, DP_AUX_NATIVE_READ, DP_DPCD_REV, buffer, 1);
+
return drm_dp_dpcd_access(aux, DP_AUX_NATIVE_READ, offset, buffer,
size);
}
--
2.5.5
[PATCH v4 5/5] drm/i915: Get rid of intel_dp_dpcd_read_wake()
Since we've fixed up drm_dp_dpcd_read() to allow for retries when things
timeout, there's no use for having this function anymore. Good riddens.
Signed-off-by: Lyude
---
drivers/gpu/drm/i915/intel_dp.c | 79 -
1 file changed, 22 insertions(+), 57 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
index f069a82..43c2933 100644
--- a/drivers/gpu/drm/i915/intel_dp.c
+++ b/drivers/gpu/drm/i915/intel_dp.c
@@ -3184,47 +3184,14 @@ static void chv_dp_post_pll_disable(struct
intel_encoder *encoder)
}
/*
- * Native read with retry for link status and receiver capability reads for
- * cases where the sink may still be asleep.
- *
- * Sinks are *supposed* to come up within 1ms from an off state, but we're also
- * supposed to retry 3 times per the spec.
- */
-static ssize_t
-intel_dp_dpcd_read_wake(struct drm_dp_aux *aux, unsigned int offset,
- void *buffer, size_t size)
-{
- ssize_t ret;
- int i;
-
- /*
-* Sometime we just get the same incorrect byte repeated
-* over the entire buffer. Doing just one throw away read
-* initially seems to "solve" it.
-*/
- drm_dp_dpcd_read(aux, DP_DPCD_REV, buffer, 1);
-
- for (i = 0; i < 3; i++) {
- ret = drm_dp_dpcd_read(aux, offset, buffer, size);
- if (ret == size)
- return ret;
- msleep(1);
- }
-
- return ret;
-}
-
-/*
* Fetch AUX CH registers 0x202 - 0x207 which contain
* link status information
*/
bool
intel_dp_get_link_status(struct intel_dp *intel_dp, uint8_t
link_status[DP_LINK_STATUS_SIZE])
{
- return intel_dp_dpcd_read_wake(&intel_dp->aux,
- DP_LANE0_1_STATUS,
- link_status,
- DP_LINK_STATUS_SIZE) ==
DP_LINK_STATUS_SIZE;
+ return drm_dp_dpcd_read(&intel_dp->aux, DP_LANE0_1_STATUS, link_status,
+ DP_LINK_STATUS_SIZE) == DP_LINK_STATUS_SIZE;
}
/* These are source-specific values. */
@@ -3859,8 +3826,8 @@ intel_dp_get_dpcd(struct intel_dp *intel_dp)
struct drm_i915_private *dev_priv = dev->dev_private;
uint8_t rev;
- if (intel_dp_dpcd_read_wake(&intel_dp->aux, 0x000, intel_dp->dpcd,
- sizeof(intel_dp->dpcd)) < 0)
+ if (drm_dp_dpcd_read(&intel_dp->aux, 0x000, intel_dp->dpcd,
+sizeof(intel_dp->dpcd)) < 0)
return false; /* aux transfer failed */
DRM_DEBUG_KMS("DPCD: %*ph\n", (int) sizeof(intel_dp->dpcd),
intel_dp->dpcd);
@@ -3871,9 +3838,9 @@ intel_dp_get_dpcd(struct intel_dp *intel_dp)
/* Check if the panel supports PSR */
memset(intel_dp->psr_dpcd, 0, sizeof(intel_dp->psr_dpcd));
if (is_edp(intel_dp)) {
- intel_dp_dpcd_read_wake(&intel_dp->aux, DP_PSR_SUPPORT,
- intel_dp->psr_dpcd,
- sizeof(intel_dp->psr_dpcd));
+ drm_dp_dpcd_read(&intel_dp->aux, DP_PSR_SUPPORT,
+intel_dp->psr_dpcd,
+sizeof(intel_dp->psr_dpcd));
if (intel_dp->psr_dpcd[0] & DP_PSR_IS_SUPPORTED) {
dev_priv->psr.sink_support = true;
DRM_DEBUG_KMS("Detected EDP PSR Panel.\n");
@@ -3884,9 +3851,9 @@ intel_dp_get_dpcd(struct intel_dp *intel_dp)
uint8_t frame_sync_cap;
dev_priv->psr.sink_support = true;
- intel_dp_dpcd_read_wake(&intel_dp->aux,
- DP_SINK_DEVICE_AUX_FRAME_SYNC_CAP,
- &frame_sync_cap, 1);
+ drm_dp_dpcd_read(&intel_dp->aux,
+DP_SINK_DEVICE_AUX_FRAME_SYNC_CAP,
+&frame_sync_cap, 1);
dev_priv->psr.aux_frame_sync = frame_sync_cap ? true :
false;
/* PSR2 needs frame sync as well */
dev_priv->psr.psr2_support =
dev_priv->psr.aux_frame_sync;
@@ -3902,15 +3869,13 @@ intel_dp_get_dpcd(struct intel_dp *intel_dp)
/* Intermediate frequency support */
if (is_edp(intel_dp) &&
(intel_dp->dpcd[DP_EDP_CONFIGURATION_CAP] &
DP_DPCD_DISPLAY_CONTROL_CAPABLE) &&
- (intel_dp_dpcd_read_wake(&intel_dp->aux, DP_EDP_DPCD_REV, &rev, 1)
== 1) &&
+ (drm_dp_dpcd_read(&intel_dp->aux, DP_EDP_DPCD_REV, &rev, 1) == 1) &&
(rev >= 0x03)) { /* eDp v1.4 or higher */
__le16 sink_rates[DP_MAX_SUPPORTED_RATES];
int i;
- intel_dp_dpcd_read_wake(&intel_dp->aux,
- DP_SUPPORTED_LINK_RATES,
-
[Bug 115251] New: amdgpu: Black screen + hang with Kaveri
https://bugzilla.kernel.org/show_bug.cgi?id=115251 Bug ID: 115251 Summary: amdgpu: Black screen + hang with Kaveri Product: Drivers Version: 2.5 Kernel Version: 4.4.5 Hardware: x86-64 OS: Linux Tree: Mainline Status: NEW Severity: normal Priority: P1 Component: Video(DRI - non Intel) Assignee: drivers_video-dri at kernel-bugs.osdl.org Reporter: linux at bernd-steinhauser.de Regression: No Created attachment 210661 --> https://bugzilla.kernel.org/attachment.cgi?id=210661&action=edit Xorg log With 4.4.6, I noticed I cannot use the xf86-video-amdgpu ddx anymore. When the X server starts, the screen will go black, in the log, there is a message telling me that the device initialization failed. I can't get the console back either, but emergency sync, ro remount and poweroff do work. Before starting X, the driver seems to work fine, only when starting X things go wrong. The issue is present with 4.5.0 as well. Will upload a Xorg log, but it won't be much of a help, because it seems to be cut off, even though I waited for a long time before sync and unmount. Also tried to capture dmesg, but got only a partial one as well which was cut off before things got interesting. bisect led to (on the 4.4.y branch): a46a700abc520bfadf5fa1cc371ba07d6d7f9230 is the first bad commit commit a46a700abc520bfadf5fa1cc371ba07d6d7f9230 Author: Christian König Date: Fri Feb 26 16:18:15 2016 +0100 drm/amdgpu: apply gfx_v8 fixes to gfx_v7 as well ···· commit feebe91aa9a9d99d9ec157612a614fadb79beb99 upstream. ···· We never ported that back to CIK, so we could run into VM faults here. ···· Signed-off-by: Christian König Reviewed-by: Alex Deucher Signed-off-by: Greg Kroah-Hartman :04 04 3930bee60c2e64b348ee8e5f618326b5f6141cdc 8501edda2a7d8ee201cde839ac01d943bec84a51 M drivers Reverting that commit on top of 4.4.6 (or the corresponding one on top of 4.5.0) gets things working again. -- You are receiving this mail because: You are watching the assignee of the bug.
[Bug 115141] radeon kernel module hangs suspend
https://bugzilla.kernel.org/show_bug.cgi?id=115141 --- Comment #4 from Paulo Dias --- sorry i cant, i dont have the resources :( maybe eugene? -- You are receiving this mail because: You are watching the assignee of the bug.
[Bug 115251] amdgpu: Black screen + hang with Kaveri
https://bugzilla.kernel.org/show_bug.cgi?id=115251 Alex Deucher changed: What|Removed |Added CC||alexdeucher at gmail.com --- Comment #1 from Alex Deucher --- Created attachment 210671 --> https://bugzilla.kernel.org/attachment.cgi?id=210671&action=edit fix for 4.5 The fix for 4.5 has already gone to stable, it just hasn't been applied yet. 4.6 is not affected. -- You are receiving this mail because: You are watching the assignee of the bug.
omap4: how to get the HDMI core IRQ?
Hi Tomi,
I hope you (or someone else on this list) can help me find the problem in this
code.
I am working on a kernel framework for HDMI CEC (see
https://lwn.net/Articles/680942/).
In order to get as much experience with different devices as possible I am
trying to
implement it on my omap4430 Pandaboard. The big problem I am facing is that the
CEC
interrupts come in through the HDMI_IRQ_CORE interrupt, and that just refuses to
trigger.
The code below adds support for this core interrupt and it is supposed to
trigger it
using the Software Induced interrupt to keep the code as simple as possible.
On boot I get this debug line from the pr_info in my code:
irqstat 0200 wp_irq 0601 raw 2001 intr_state 0001 intr1
0080 unmask1 0080 intr_ctrl 000a
As far as I can see everything looks perfectly fine, except for the fact that
bit 0
of the irqstat is stubbornly 0.
This is using kernel 4.5 with only this patch applied.
What am I missing?
The reward for the right answer will be HDMI CEC support for omap4 (and any
other TI device
with the same CEC IP).
Regards,
Hans
diff --git a/drivers/gpu/drm/omapdrm/dss/hdmi4.c
b/drivers/gpu/drm/omapdrm/dss/hdmi4.c
index 7103c65..999b5ec 100644
--- a/drivers/gpu/drm/omapdrm/dss/hdmi4.c
+++ b/drivers/gpu/drm/omapdrm/dss/hdmi4.c
@@ -75,6 +75,14 @@ static irqreturn_t hdmi_irq_handler(int irq, void *data)
irqstatus = hdmi_wp_get_irqstatus(wp);
hdmi_wp_set_irqstatus(wp, irqstatus);
+ pr_info("irqstat %08x wp_irq %08x raw %08x intr_state %08x intr1 %08x
unmask1 %08x intr_ctrl %08x\n",
+ irqstatus,
+ hdmi_read_reg(hdmi.wp.base, HDMI_WP_IRQENABLE_SET),
+ hdmi_read_reg(hdmi.wp.base, HDMI_WP_IRQSTATUS_RAW),
+ hdmi_read_reg(hdmi.core.base, HDMI_CORE_SYS_INTR_STATE),
+ hdmi_read_reg(hdmi.core.base, HDMI_CORE_SYS_INTR1),
+ hdmi_read_reg(hdmi.core.base, HDMI_CORE_SYS_INTR_UNMASK1),
+ hdmi_read_reg(hdmi.core.base, HDMI_CORE_SYS_INTR_CTRL));
if ((irqstatus & HDMI_IRQ_LINK_CONNECT) &&
irqstatus & HDMI_IRQ_LINK_DISCONNECT) {
/*
@@ -94,6 +102,13 @@ static irqreturn_t hdmi_irq_handler(int irq, void *data)
} else if (irqstatus & HDMI_IRQ_LINK_DISCONNECT) {
hdmi_wp_set_phy_pwr(wp, HDMI_PHYPWRCMD_LDOON);
}
+ if (irqstatus & HDMI_IRQ_CORE) {
+ u32 intr1 = hdmi_read_reg(hdmi.core.base, HDMI_CORE_SYS_INTR1);
+
+ hdmi_write_reg(hdmi.core.base, HDMI_CORE_SYS_INTR_CTRL, 2);
+ pr_info("clear sw irq\n");
+ hdmi_write_reg(hdmi.core.base, HDMI_CORE_SYS_INTR1, intr1);
+ }
return IRQ_HANDLED;
}
@@ -222,9 +237,12 @@ static int hdmi_power_on_full(struct omap_dss_device
*dssdev)
if (r)
goto err_mgr_enable;
+ hdmi_write_reg(hdmi.core.base, HDMI_CORE_SYS_INTR_UNMASK1, 0x80);
hdmi_wp_set_irqenable(wp,
- HDMI_IRQ_LINK_CONNECT | HDMI_IRQ_LINK_DISCONNECT);
+ HDMI_IRQ_LINK_CONNECT | HDMI_IRQ_LINK_DISCONNECT |
HDMI_IRQ_CORE);
+ pr_info("set sw irq\n");
+ hdmi_write_reg(hdmi.core.base, HDMI_CORE_SYS_INTR_CTRL, 0xa);
return 0;
err_mgr_enable:
[Bug 94689] Two monitor DisplayPort MST DaisyChain (Second/Last Monitor In Chain Black Screen)
https://bugs.freedesktop.org/show_bug.cgi?id=94689 Bug ID: 94689 Summary: Two monitor DisplayPort MST DaisyChain (Second/Last Monitor In Chain Black Screen) Product: DRI Version: XOrg git Hardware: x86-64 (AMD64) OS: Linux (All) Status: NEW Severity: major Priority: medium Component: DRM/Radeon Assignee: dri-devel at lists.freedesktop.org Reporter: mike.ennen at gmail.com As per our chat in #radeon (I am brcolow). Here is the dmesg with dri.debug=6: https://gist.github.com/brcolow/e27a5e46b175dd0966af Here is /sys/kernel/debug/dri/0/radeon_mst_info contents: mst: 88061cedfb40, 0 port: 1: ddps: 1 ldps: 0, sdp: 1/1, 8800bb193000, conn: 880622b27000 port: 8: ddps: 1 ldps: 0, sdp: 1/1, 8800bb192800, conn: 880622049000 port: 0: ddps: 1 ldps: 0, sdp: 0/0, 8800bb192000, conn: (null) vcpi: 7 3 vcpi 0: 8 1 22 vcpi 1: 1 2 22 vcpi 2:unsed vcpi 3:unsed vcpi 4:unsed vcpi 5:unsed payload 0: 2, 1, 22 payload 1: 2, 23, 22 payload 2: 0, 45, 0 payload 3: 0, 45, 0 payload 4: 0, 45, 0 payload 5: 0, 45, 0 dpcd: 12 14 c4 01 01 01 01 81 02 00 06 00 00 00 00 faux/mst: 00 01 mst ctrl: 07 branch oui: 00e04c devid: Dp1.2 revision: hw: 0.0 sw: 0.0 payload table: 07 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 02 02 02 02 02 02 02 02 02 02 02 02 02 02 02 02 02 02 02 02 02 02 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 attrib 0: 4 22 attrib 1: 2 22 The two monitors that are being daisy-chained are Dell UltraSharp U2715H's. GPU is Radeon R9 290. I have tried doing: xrandr --output DisplayPort-0-1 --rate X where X = 59.9, 60, 49.9, 50, 39.9, 40 etc but it doesn't seem to change anything (and this is the extent of my debugging abilities). -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <https://lists.freedesktop.org/archives/dri-devel/attachments/20160324/2a4ce72b/attachment.html>
[PATCH 4/5] drm/vc4: Add DPI driver
Rob Herring writes: > On Fri, Mar 18, 2016 at 07:42:45PM -0700, Eric Anholt wrote: >> The DPI interface involves taking a ton of our GPIOs to be used as >> outputs, and routing display signals over them in parallel. >> >> Signed-off-by: Eric Anholt >> --- >> .../devicetree/bindings/display/brcm,bcm-vc4.txt | 67 +++ >> drivers/gpu/drm/vc4/Kconfig| 1 + >> drivers/gpu/drm/vc4/Makefile | 1 + >> drivers/gpu/drm/vc4/vc4_debugfs.c | 1 + >> drivers/gpu/drm/vc4/vc4_dpi.c | 518 >> + >> drivers/gpu/drm/vc4/vc4_drv.c | 1 + >> drivers/gpu/drm/vc4/vc4_drv.h | 5 + >> 7 files changed, 594 insertions(+) >> create mode 100644 drivers/gpu/drm/vc4/vc4_dpi.c >> >> diff --git a/Documentation/devicetree/bindings/display/brcm,bcm-vc4.txt >> b/Documentation/devicetree/bindings/display/brcm,bcm-vc4.txt >> index 56a961a..1782c3f 100644 >> --- a/Documentation/devicetree/bindings/display/brcm,bcm-vc4.txt >> +++ b/Documentation/devicetree/bindings/display/brcm,bcm-vc4.txt >> @@ -35,6 +35,44 @@ Optional properties for HDMI: >>as an interrupt/status bit in the HDMI controller >>itself). See bindings/pinctrl/brcm,bcm2835-gpio.txt >> >> +Required properties for DPI: >> +- compatible: Should be "brcm,bcm2835-dpi" >> +- reg: Physical base address and length of the >> registers >> +- clocks: a) core: The core clock the unit runs on >> +b) pixel: The pixel clock that feeds the pixelvalve >> +- port: Port node with a single endpoint connecting to >> the >> + panel device, as defined in [1] >> +- brcm,output-format: Output data format, must be one of: >> +0) disabled >> +1) rggb >> +2) 000r00gg000b >> +3) 00r000gg00b0 >> +4) 00rrggbb >> +5) 00rr00gg00bb >> +6) >> + >> +Optional properties for DPI: >> +- brcm,rgb-order: RGB reordering, must be one of: >> +0) RGB >> +1) BGR >> +2) GRB >> +3) BRG > >> +- brcm,hsync-disable: Disables the hsync signal >> +- brcm,vsync-disable: Disables the vsync signal >> +- brcm,output-enable-disable: Disables the output enable signal >> +- brcm,hsync-falling: Outputs the hsync signal on the falling >> clk edge >> +- brcm,vsync-falling: Outputs the vsync signal on the falling >> clk edge >> +- brcm,output-enable-falling: Outputs the output enable signal on the >> + falling clk edge >> +- brcm,output-enable-invert:Inverts the polarity of the output >> enable >> + signal >> +- brcm,pixel-clk-invert:Inverts the polarity of the pixel clk signal >> +- brcm,output-enable-mode: Sets output enable when (vsync | hsync) >> + instead of (hactive & vactive) > > These are all really properties of what the panel requires and we > already have video timings binding that would cover some of these. > > Also, do you have actual users? Some of these seem like they would be > rare or never. I've not seen panels caring about which clock edge the > sync signals are on. I was using output-format, rgb_order, output-enable-mode to get my panel to work. I'm suspicious that the !output_enable_mode is not useful, though (Note: I had documented it backwards: false is hsync|vsync, true is hactive&vactive). That just left me with output-format. I think .bus_format in the panel_desc can cover that, so I've now dropped all of these brcm properties. -- next part -- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 818 bytes Desc: not available URL: <https://lists.freedesktop.org/archives/dri-devel/attachments/20160324/c0f99da7/attachment.sig>
[PATCH 0/5 v4] drm: Add support of ARC PGU display controller
This series add support of ARC PGU display controller. ARC PGU is a quite simple byte streamer that gets data from the framebuffer and pushes it to hte connected encoder (DP or HDMI). It was tested on ARC SDP boards (axs101/103 in particular). Note following series that introduces drm_connector_register_all()/drm_connector_unregister_all() is a prerequisite now: https://lkml.org/lkml/2016/3/23/61 Changes v3 -> v4: * Main driver author is now set properly (thanks Carlos for all your efforts) * Implemented correct hsync and vsync setup (thanks Jose) * Dummy call-backs were removed (as suggested by Daniel) * Obsolete load()/unload() call-backs were removed (as suggested by Daniel) * With above in mind we were able to adopt recently introduced drm_connector_register_all()/drm_connector_unregister_all() * Implemented setup of properties (uncached) for FB user-pages * Minor clean-up in DT binding docs and axs10x_mb.dtsi Changes v2 -> v3: * Improved failure path if arcpgu_connector wasn't allocated. * Fixed driver building as module. * Implemented uncached mapping of user-space FB pages. * Again updated DT bindings docs. Changes v1 -> v2: * Clean-up of DT bindings documentation. * Added missing "pxlclk" clock in axs10x_mb.dtsi. Cc: David Airlie Cc: devicetree at vger.kernel.org Cc: dri-devel at lists.freedesktop.org Cc: Ian Campbell Cc: Kumar Gala Cc: linux-snps-arc at lists.infradead.org Cc: Mark Rutland Cc: Pawel Moll Cc: Rob Herring Cc: Vineet Gupta Cc: Jose Abreu Cc: Carlos Palminha Alexey Brodkin (4): drm: Add DT bindings documentation for ARC PGU display controller MAINTAINERS: Add maintainer for ARC PGU display controller arc: Add our own implementation of fb_pgprotect() arc: axs10x - add support of ARC PGU Carlos Palminha (1): drm: Add support of ARC PGU display controller .../devicetree/bindings/display/snps,arcpgu.txt| 71 ++ MAINTAINERS| 6 + arch/arc/boot/dts/axs10x_mb.dtsi | 61 + arch/arc/include/asm/fb.h | 19 ++ drivers/gpu/drm/Kconfig| 2 + drivers/gpu/drm/Makefile | 1 + drivers/gpu/drm/arc/Kconfig| 10 + drivers/gpu/drm/arc/Makefile | 2 + drivers/gpu/drm/arc/arcpgu.h | 50 drivers/gpu/drm/arc/arcpgu_crtc.c | 257 +++ drivers/gpu/drm/arc/arcpgu_drv.c | 282 + drivers/gpu/drm/arc/arcpgu_hdmi.c | 201 +++ drivers/gpu/drm/arc/arcpgu_regs.h | 40 +++ 13 files changed, 1002 insertions(+) create mode 100644 Documentation/devicetree/bindings/display/snps,arcpgu.txt create mode 100644 arch/arc/include/asm/fb.h create mode 100644 drivers/gpu/drm/arc/Kconfig create mode 100644 drivers/gpu/drm/arc/Makefile create mode 100644 drivers/gpu/drm/arc/arcpgu.h create mode 100644 drivers/gpu/drm/arc/arcpgu_crtc.c create mode 100644 drivers/gpu/drm/arc/arcpgu_drv.c create mode 100644 drivers/gpu/drm/arc/arcpgu_hdmi.c create mode 100644 drivers/gpu/drm/arc/arcpgu_regs.h -- 2.5.0
[PATCH 1/5 v4] drm: Add support of ARC PGU display controller
From: Carlos Palminha
ARC PGU could be found on some development boards from Synopsys.
This is a simple byte streamer that reads data from a framebuffer
and sends data to the single encoder.
Signed-off-by: Carlos Palminha
Signed-off-by: Alexey Brodkin
Cc: David Airlie
Cc: dri-devel at lists.freedesktop.org
Cc: linux-snps-arc at lists.infradead.org
---
Note following series that introduces
drm_connector_register_all()/drm_connector_unregister_all() is a prerequisite
now: https://lkml.org/lkml/2016/3/23/61
Changes v3 -> v4:
* The driver author is now set properly (thanks Carlos for all your efforts)
* Implemented correct hsync and vsync setup (thanks Jose)
* Dummy call-backs were removed (as suggested by Daniel)
* Obsolete load()/unload() call-backs were removed (as suggested by Daniel)
* With above in mind we were able to adopt recently introduced
drm_connector_register_all()/drm_connector_unregister_all()
Changes v2 -> v3:
* Improved failure path if arcpgu_connector wasn't allocated (thanks Jose).
* Fixed driver building as module (reported by 0-DAY kernel test infrastruct.)
* Implemented uncached mapping of user-space FB pages.
No changes v1 -> v2.
drivers/gpu/drm/Kconfig | 2 +
drivers/gpu/drm/Makefile | 1 +
drivers/gpu/drm/arc/Kconfig | 10 ++
drivers/gpu/drm/arc/Makefile | 2 +
drivers/gpu/drm/arc/arcpgu.h | 50 +++
drivers/gpu/drm/arc/arcpgu_crtc.c | 257 ++
drivers/gpu/drm/arc/arcpgu_drv.c | 282 ++
drivers/gpu/drm/arc/arcpgu_hdmi.c | 201 +++
drivers/gpu/drm/arc/arcpgu_regs.h | 40 ++
9 files changed, 845 insertions(+)
create mode 100644 drivers/gpu/drm/arc/Kconfig
create mode 100644 drivers/gpu/drm/arc/Makefile
create mode 100644 drivers/gpu/drm/arc/arcpgu.h
create mode 100644 drivers/gpu/drm/arc/arcpgu_crtc.c
create mode 100644 drivers/gpu/drm/arc/arcpgu_drv.c
create mode 100644 drivers/gpu/drm/arc/arcpgu_hdmi.c
create mode 100644 drivers/gpu/drm/arc/arcpgu_regs.h
diff --git a/drivers/gpu/drm/Kconfig b/drivers/gpu/drm/Kconfig
index f2a74d0..9e4f2f1 100644
--- a/drivers/gpu/drm/Kconfig
+++ b/drivers/gpu/drm/Kconfig
@@ -281,3 +281,5 @@ source "drivers/gpu/drm/imx/Kconfig"
source "drivers/gpu/drm/vc4/Kconfig"
source "drivers/gpu/drm/etnaviv/Kconfig"
+
+source "drivers/gpu/drm/arc/Kconfig"
diff --git a/drivers/gpu/drm/Makefile b/drivers/gpu/drm/Makefile
index 6eb94fc..c338d04 100644
--- a/drivers/gpu/drm/Makefile
+++ b/drivers/gpu/drm/Makefile
@@ -78,3 +78,4 @@ obj-y += panel/
obj-y += bridge/
obj-$(CONFIG_DRM_FSL_DCU) += fsl-dcu/
obj-$(CONFIG_DRM_ETNAVIV) += etnaviv/
+obj-$(CONFIG_DRM_ARCPGU)+= arc/
diff --git a/drivers/gpu/drm/arc/Kconfig b/drivers/gpu/drm/arc/Kconfig
new file mode 100644
index 000..f9a13b6
--- /dev/null
+++ b/drivers/gpu/drm/arc/Kconfig
@@ -0,0 +1,10 @@
+config DRM_ARCPGU
+ tristate "ARC PGU"
+ depends on DRM && OF
+ select DRM_KMS_CMA_HELPER
+ select DRM_KMS_FB_HELPER
+ select DRM_KMS_HELPER
+ help
+ Choose this option if you have an ARC PGU controller.
+
+ If M is selected the module will be called arcpgu.
diff --git a/drivers/gpu/drm/arc/Makefile b/drivers/gpu/drm/arc/Makefile
new file mode 100644
index 000..d48fda7
--- /dev/null
+++ b/drivers/gpu/drm/arc/Makefile
@@ -0,0 +1,2 @@
+arcpgu-y := arcpgu_crtc.o arcpgu_hdmi.o arcpgu_drv.o
+obj-$(CONFIG_DRM_ARCPGU) += arcpgu.o
diff --git a/drivers/gpu/drm/arc/arcpgu.h b/drivers/gpu/drm/arc/arcpgu.h
new file mode 100644
index 000..86574b6
--- /dev/null
+++ b/drivers/gpu/drm/arc/arcpgu.h
@@ -0,0 +1,50 @@
+/*
+ * ARC PGU DRM driver.
+ *
+ * Copyright (C) 2016 Synopsys, Inc. (www.synopsys.com)
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ *
+ */
+
+#ifndef _ARCPGU_H_
+#define _ARCPGU_H_
+
+struct arcpgu_drm_private {
+ void __iomem*regs;
+ struct clk *clk;
+ struct drm_fbdev_cma*fbdev;
+ struct drm_framebuffer *fb;
+ struct list_headevent_list;
+ struct drm_crtc crtc;
+ struct drm_plane*plane;
+};
+
+#define crtc_to_arcpgu_priv(x) container_of(x, struct arcpgu_drm_private, crtc)
+
+static inline void arc_pgu_write(struct arcpgu_drm_private *arcpgu,
+unsigned int reg, u32 value)
+{
+ iowrite32(value, arcpgu->regs + reg);
+}
+
+static inline u32 arc_pgu_read(struct arcpgu_drm_private *arcpgu,
+ unsigned int reg
[PATCH 2/5 v4] drm: Add DT bindings documentation for ARC PGU display controller
This add DT bindings documentation for ARC PGU display controller.
Signed-off-by: Alexey Brodkin
Cc: Rob Herring
Cc: Pawel Moll
Cc: Mark Rutland
Cc: Ian Campbell
Cc: Kumar Gala
Cc: devicetree at vger.kernel.org
Cc: linux-snps-arc at lists.infradead.org
---
Changes v3 -> v4: (addressing Rob's comments)
* Removed "encoder-slave" from required properties
* Removed "0x" from node names
Changes v2 -> v3:
* Reverted back to initial larger version of example
with minor fixes (thanks Rob for spotting those).
Changes v1 -> v2:
* Removed everything except PGU node itself.
.../devicetree/bindings/display/snps,arcpgu.txt| 71 ++
1 file changed, 71 insertions(+)
create mode 100644 Documentation/devicetree/bindings/display/snps,arcpgu.txt
diff --git a/Documentation/devicetree/bindings/display/snps,arcpgu.txt
b/Documentation/devicetree/bindings/display/snps,arcpgu.txt
new file mode 100644
index 000..b126577
--- /dev/null
+++ b/Documentation/devicetree/bindings/display/snps,arcpgu.txt
@@ -0,0 +1,71 @@
+ARC PGU
+
+This is a display controller found on several development boards produced
+by Synopsys. The ARC PGU is an RGB streamer that reads the data from a
+framebuffer and sends it to a single digital encoder (usually HDMI).
+
+Required properties:
+ - compatible: "snps,arcpgu"
+ - reg: Physical base address and length of the controller's registers.
+ - clocks: A list of phandle + clock-specifier pairs, one for each
+entry in 'clock-names'.
+ - clock-names: A list of clock names. For ARC PGU it should contain:
+ - "pxlclk" for the clock feeding the output PLL of the controller.
+
+Required sub-nodes:
+ - port: The PGU connection to an encoder chip.
+
+Example:
+
+/ {
+ ...
+
+ pgu at {
+ compatible = "snps,arcpgu";
+ reg = <0x 0x400>;
+ clocks = <&clock_node>;
+ clock-names = "pxlclk";
+ encoder-slave = <&encoder_node>;
+
+ port {
+ pgu_output: endpoint {
+ remote-endpoint = <&hdmi_enc_input>;
+ };
+ };
+ };
+
+ /* HDMI encoder on I2C bus */
+ i2c at {
+ compatible = "...";
+
+ encoder_node:hdmi at XX{
+ compatible="...";
+
+ ports {
+ port at 0 {
+ reg = <0>;
+ hdmi_enc_input:endpoint {
+ remote-endpoint = <&pgu_output>;
+ };
+ };
+
+ port at 1 {
+ reg = <1>;
+ hdmi_enc_output:endpoint {
+ remote-endpoint =
<&hdmi_connector_in>;
+ };
+ };
+ };
+ };
+ }
+
+ hdmi0: connector {
+ compatible = "hdmi-connector";
+
+ port {
+ hdmi_connector_in: endpoint {
+ remote-endpoint = <&hdmi_enc_output>;
+ };
+ };
+ };
+};
--
2.5.0
[PATCH 3/5 v4] MAINTAINERS: Add maintainer for ARC PGU display controller
This updates MAINTEINERS file with information about maintainer of ARC PGU display controller driver. Signed-off-by: Alexey Brodkin Cc: linux-snps-arc at lists.infradead.org --- No changes v3 -> v4. No changes v2 -> v3. No changes v1 -> v2. MAINTAINERS | 6 ++ 1 file changed, 6 insertions(+) diff --git a/MAINTAINERS b/MAINTAINERS index ea1d1de..0dcba67 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -827,6 +827,12 @@ S: Maintained F: drivers/net/arcnet/ F: include/uapi/linux/if_arcnet.h +ARC PGU DRM DRIVER +M: Alexey Brodkin +S: Supported +F: drivers/gpu/drm/arc/ +F: Documentation/devicetree/bindings/display/snps,arcpgu.txt + ARM HDLCD DRM DRIVER M: Liviu Dudau S: Supported -- 2.5.0
[PATCH 4/5 v4] arc: Add our own implementation of fb_pgprotect()
During mmaping of frame-buffer pages to user-space
fb_protect() is called to set proper page settings.
In case of ARC we need to mark pages that are mmaped to
user as uncached because of 2 reasons:
* Huge amount of data if passing through data cache will
thrash cache a lot making cache almost useless for other
less traffic hungry processes.
* Data written by user in FB will be immediately available for
hardware (such as PGU etc) without requirements to flush data
cache regularly.
Signed-off-by: Alexey Brodkin
Cc: linux-snps-arc at lists.infradead.org
---
Changes v3 -> v4:
* This change was introduced only in v4.
arch/arc/include/asm/fb.h | 19 +++
1 file changed, 19 insertions(+)
create mode 100644 arch/arc/include/asm/fb.h
diff --git a/arch/arc/include/asm/fb.h b/arch/arc/include/asm/fb.h
new file mode 100644
index 000..bd3f68c
--- /dev/null
+++ b/arch/arc/include/asm/fb.h
@@ -0,0 +1,19 @@
+#ifndef _ASM_FB_H_
+#define _ASM_FB_H_
+
+#include
+#include
+#include
+
+static inline void fb_pgprotect(struct file *file, struct vm_area_struct *vma,
+ unsigned long off)
+{
+ vma->vm_page_prot = pgprot_noncached(vma->vm_page_prot);
+}
+
+static inline int fb_is_primary_device(struct fb_info *info)
+{
+ return 0;
+}
+
+#endif /* _ASM_FB_H_ */
--
2.5.0
[PATCH 5/5 v4] arc: axs10x - add support of ARC PGU
Synopsys DesignWare ARC SDP boards sport ARC SDP display
controller attached to ADV7511 HDMI encoder.
That change adds desctiption of both ARC PGU and ADV7511 in
ARC SDP'd base-board Device Tree.
Signed-off-by: Alexey Brodkin
Cc: Rob Herring
Cc: Pawel Moll
Cc: Mark Rutland
Cc: Ian Campbell
Cc: Kumar Gala
Cc: Vineet Gupta
Cc: devicetree at vger.kernel.org
Cc: linux-snps-arc at lists.infradead.org
---
Changes v3 -> v4:
* Removed "0x" from node names (as suggested by Rob)
No changes v2 -> v3.
Changes v1 -> v2:
* Added missing "pxlclk" clock in axs10x_mb.dtsi
arch/arc/boot/dts/axs10x_mb.dtsi | 61
1 file changed, 61 insertions(+)
diff --git a/arch/arc/boot/dts/axs10x_mb.dtsi b/arch/arc/boot/dts/axs10x_mb.dtsi
index 44a578c..8fee596 100644
--- a/arch/arc/boot/dts/axs10x_mb.dtsi
+++ b/arch/arc/boot/dts/axs10x_mb.dtsi
@@ -34,6 +34,12 @@
clock-frequency = <5000>;
#clock-cells = <0>;
};
+
+ pguclk: pguclk {
+ #clock-cells = <0>;
+ compatible = "fixed-clock";
+ clock-frequency = <7444>;
+ };
};
ethernet at 0x18000 {
@@ -147,6 +153,37 @@
clocks = <&i2cclk>;
interrupts = <16>;
+ adv7511:adv7511 at 39{
+ compatible="adi,adv7511";
+ reg = <0x39>;
+ interrupts = <23>;
+ adi,input-depth = <8>;
+ adi,input-colorspace = "rgb";
+ adi,input-clock = "1x";
+ adi,clock-delay = <0x03>;
+
+ ports {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ /* RGB/YUV input */
+ port at 0 {
+ reg = <0>;
+ adv7511_input:endpoint {
+ remote-endpoint = <&pgu_output>;
+ };
+ };
+
+ /* HDMI output */
+ port at 1 {
+ reg = <1>;
+ adv7511_output: endpoint {
+ remote-endpoint =
<&hdmi_connector_in>;
+ };
+ };
+ };
+ };
+
eeprom at 0x54{
compatible = "24c01";
reg = <0x54>;
@@ -160,6 +197,16 @@
};
};
+ hdmi0: connector {
+ compatible = "hdmi-connector";
+ type = "a";
+ port {
+ hdmi_connector_in: endpoint {
+ remote-endpoint = <&adv7511_output>;
+ };
+ };
+ };
+
gpio0:gpio at 13000 {
compatible = "snps,dw-apb-gpio";
reg = <0x13000 0x1000>;
@@ -221,5 +268,19 @@
reg = <2>;
};
};
+
+ pgu at 17000 {
+ compatible = "snps,arcpgu";
+ reg = <0x17000 0x400>;
+ encoder-slave = <&adv7511>;
+ clocks = <&pguclk>;
+ clock-names = "pxlclk";
+
+ port {
+ pgu_output: endpoint {
+ remote-endpoint = <&adv7511_input>;
+ };
+ };
+ };
};
};
--
2.5.0
[PATCH 1/5 v4] drm: Add support of ARC PGU display controller
Hello, On Fri, 2016-03-25 at 01:37 +0800, kbuild test robot wrote: > Hi Carlos, > > [auto build test ERROR on drm/drm-next] > [also build test ERROR on v4.5 next-20160324] > [if your patch is applied to the wrong git tree, please drop us a note to > help improving the system] > > url:    > https://github.com/0day-ci/linux/commits/Alexey-Brodkin/drm-Add-support-of-ARC-PGU-display-controller/20160325 > -005345 > base:   git://people.freedesktop.org/~airlied/linux.git drm-next > config: i386-allmodconfig (attached as .config) > reproduce: >         # save the attached .config to linux build tree >         make ARCH=i386 > > All errors (new ones prefixed by >>): >   230 goto err_unload; >    231 >  > 232 ret = drm_connector_register_all(drm); ... >  > 254 drm_connector_unregister_all(drm); >    255 drm_dev_unregister(drm); That problem happens because that change relies on another series that yet to be accepted in DRM for 4.7 cycle, see https://lkml.org/lkml/2016/3/23/128 Based on Daniel's comment I would assume soon after 4.6-rc1 will be cut pending prerequisite will be applied to drm-next and that build failure will go away. -Alexey
[PATCH 0/5 v2] drm/vc4: DPI panel support
This is round 2 of the DPI panel support for vc4. This time the custom properties are dropped in favor of connector->display_info.bus_formats[]. Testable tree is at: https://github.com/anholt/linux/tree/drm-vc4-dpi-boot Eric Anholt (5): of: Add vendor prefix for On Tat Industrial Company. panel-simple: Add the 7" DPI panel from Adafruit. drm: Add an encoder and connector type enum for DPI. drm/vc4: Add DPI driver ARM: bcm2835: Add the DPI hardware to the device tree. .../devicetree/bindings/display/brcm,bcm-vc4.txt | 36 ++ .../bindings/display/panel/ontat,yx700wv03.txt | 7 + .../devicetree/bindings/vendor-prefixes.txt| 1 + arch/arm/boot/dts/bcm283x.dtsi | 11 + drivers/gpu/drm/drm_crtc.c | 2 + drivers/gpu/drm/panel/panel-simple.c | 35 ++ drivers/gpu/drm/vc4/Kconfig| 1 + drivers/gpu/drm/vc4/Makefile | 1 + drivers/gpu/drm/vc4/vc4_debugfs.c | 1 + drivers/gpu/drm/vc4/vc4_dpi.c | 520 + drivers/gpu/drm/vc4/vc4_drv.c | 1 + drivers/gpu/drm/vc4/vc4_drv.h | 5 + include/uapi/drm/drm_mode.h| 2 + 13 files changed, 623 insertions(+) create mode 100644 Documentation/devicetree/bindings/display/panel/ontat,yx700wv03.txt create mode 100644 drivers/gpu/drm/vc4/vc4_dpi.c -- 2.7.0
[PATCH 2/5] panel-simple: Add the 7" DPI panel from Adafruit.
This is a basic TFT panel with a 40-pin FPC connector on it. The
specification doesn't define timings, but the Adafruit instructions
were setting up 800x480 CVT.
v2: Add .bus_format and vsync/hsync flags.
Signed-off-by: Eric Anholt
Acked-by: Rob Herring
---
.../bindings/display/panel/ontat,yx700wv03.txt | 7 +
drivers/gpu/drm/panel/panel-simple.c | 35 ++
2 files changed, 42 insertions(+)
create mode 100644
Documentation/devicetree/bindings/display/panel/ontat,yx700wv03.txt
diff --git
a/Documentation/devicetree/bindings/display/panel/ontat,yx700wv03.txt
b/Documentation/devicetree/bindings/display/panel/ontat,yx700wv03.txt
new file mode 100644
index 000..3d8a5e0
--- /dev/null
+++ b/Documentation/devicetree/bindings/display/panel/ontat,yx700wv03.txt
@@ -0,0 +1,7 @@
+On Tat Industrial Company 7" DPI TFT panel.
+
+Required properties:
+- compatible: should be "ontat,yx700wv03"
+
+This binding is compatible with the simple-panel binding, which is specified
+in simple-panel.txt in this directory.
diff --git a/drivers/gpu/drm/panel/panel-simple.c
b/drivers/gpu/drm/panel/panel-simple.c
index f88a631..642c5ca 100644
--- a/drivers/gpu/drm/panel/panel-simple.c
+++ b/drivers/gpu/drm/panel/panel-simple.c
@@ -1176,6 +1176,38 @@ static const struct panel_desc shelly_sca07010_bfn_lnn =
{
.bus_format = MEDIA_BUS_FMT_RGB666_1X18,
};
+/* 800x480 CVT. The panel appears to be quite accepting, at least as
+ * far as pixel clocks, but this is the timing that was being used in
+ * the Adafruit installation instructions.
+ */
+static const struct drm_display_mode ontat_yx700wv03_mode = {
+ .clock = 29500,
+ .hdisplay = 800,
+ .hsync_start = 824,
+ .hsync_end = 896,
+ .htotal = 992,
+ .vdisplay = 480,
+ .vsync_start = 483,
+ .vsync_end = 493,
+ .vtotal = 500,
+ .vrefresh = 60,
+ .flags = DRM_MODE_FLAG_NVSYNC | DRM_MODE_FLAG_NHSYNC,
+};
+
+/* Specification at
+ * https://www.adafruit.com/images/product-files/2406/c3163.pdf
+ */
+static const struct panel_desc ontat_yx700wv03 = {
+ .modes = &ontat_yx700wv03_mode,
+ .num_modes = 1,
+ .bpc = 8,
+ .size = {
+ .width = 154,
+ .height = 83,
+ },
+ .bus_format = MEDIA_BUS_FMT_RGB888_1X24,
+};
+
static const struct of_device_id platform_of_match[] = {
{
.compatible = "ampire,am800480r3tmqwa1h",
@@ -1265,6 +1297,9 @@ static const struct of_device_id platform_of_match[] = {
.compatible = "okaya,rs800480t-7x0gp",
.data = &okaya_rs800480t_7x0gp,
}, {
+ .compatible = "ontat,yx700wv03",
+ .data = &ontat_yx700wv03,
+ }, {
.compatible = "ortustech,com43h4m85ulc",
.data = &ortustech_com43h4m85ulc,
}, {
--
2.7.0
[PATCH 3/5] drm: Add an encoder and connector type enum for DPI.
Right now exynos is exposing DPI as a TMDS encoder and VGA connector,
which seems rather misleading. This isn't just an internal detail,
since xrandr actually exposes "VGA" as the output name. Define some
new enums so that vc4's DPI can have a more informative name.
I considered other names for the connector as well. For VC4, the
Adafruit DPI kippah takes the 28 GPIO pins and routes them to a
standard-ish 40-pin FPC connector, but "40-pin FPC" doesn't uniquely
identify an ordering of pins (apparently some other orderings exist),
doesn't explain things as well for the user (who, if anything, knows
their product is a DPI kippah/panel combo), and actually doesn't have
to exist (one could connect the 28 GPIOs directly to something else).
Simply "DPI" seems like a good compromise name to distinguish from the
HDMI, DSI, and TV connectors .
Signed-off-by: Eric Anholt
---
drivers/gpu/drm/drm_crtc.c | 2 ++
include/uapi/drm/drm_mode.h | 2 ++
2 files changed, 4 insertions(+)
diff --git a/drivers/gpu/drm/drm_crtc.c b/drivers/gpu/drm/drm_crtc.c
index f619121..64bd954 100644
--- a/drivers/gpu/drm/drm_crtc.c
+++ b/drivers/gpu/drm/drm_crtc.c
@@ -168,6 +168,7 @@ static struct drm_conn_prop_enum_list
drm_connector_enum_list[] = {
{ DRM_MODE_CONNECTOR_eDP, "eDP" },
{ DRM_MODE_CONNECTOR_VIRTUAL, "Virtual" },
{ DRM_MODE_CONNECTOR_DSI, "DSI" },
+ { DRM_MODE_CONNECTOR_DPI, "DPI" },
};
static const struct drm_prop_enum_list drm_encoder_enum_list[] = {
@@ -179,6 +180,7 @@ static const struct drm_prop_enum_list
drm_encoder_enum_list[] = {
{ DRM_MODE_ENCODER_VIRTUAL, "Virtual" },
{ DRM_MODE_ENCODER_DSI, "DSI" },
{ DRM_MODE_ENCODER_DPMST, "DP MST" },
+ { DRM_MODE_ENCODER_DPI, "DPI" },
};
static const struct drm_prop_enum_list drm_subpixel_enum_list[] = {
diff --git a/include/uapi/drm/drm_mode.h b/include/uapi/drm/drm_mode.h
index 50adb46..1eb85f7 100644
--- a/include/uapi/drm/drm_mode.h
+++ b/include/uapi/drm/drm_mode.h
@@ -202,6 +202,7 @@ struct drm_mode_get_plane_res {
#define DRM_MODE_ENCODER_VIRTUAL 5
#define DRM_MODE_ENCODER_DSI 6
#define DRM_MODE_ENCODER_DPMST 7
+#define DRM_MODE_ENCODER_DPI 8
struct drm_mode_get_encoder {
__u32 encoder_id;
@@ -241,6 +242,7 @@ struct drm_mode_get_encoder {
#define DRM_MODE_CONNECTOR_eDP 14
#define DRM_MODE_CONNECTOR_VIRTUAL 15
#define DRM_MODE_CONNECTOR_DSI 16
+#define DRM_MODE_CONNECTOR_DPI 17
struct drm_mode_get_connector {
--
2.7.0
[PATCH 1/5] of: Add vendor prefix for On Tat Industrial Company.
This is the vendor for a 7" DPI panel sold by Adafruit which I'd like to describe in DT. Signed-off-by: Eric Anholt Acked-by: Rob Herring --- Documentation/devicetree/bindings/vendor-prefixes.txt | 1 + 1 file changed, 1 insertion(+) diff --git a/Documentation/devicetree/bindings/vendor-prefixes.txt b/Documentation/devicetree/bindings/vendor-prefixes.txt index 72e2c5a..b35b5f8 100644 --- a/Documentation/devicetree/bindings/vendor-prefixes.txt +++ b/Documentation/devicetree/bindings/vendor-prefixes.txt @@ -166,6 +166,7 @@ nxp NXP Semiconductors okaya Okaya Electric America, Inc. olimex OLIMEX Ltd. onnn ON Semiconductor Corp. +ontat On Tat Industrial Company opencores OpenCores.org option Option NV ortustech Ortus Technology Co., Ltd. -- 2.7.0
[PATCH 4/5] drm/vc4: Add DPI driver
The DPI interface involves taking a ton of our GPIOs to be used as
outputs, and routing display signals over them in parallel.
v2: Use display_info.bus_formats[] to replace our custom DT
properties.
Signed-off-by: Eric Anholt
---
.../devicetree/bindings/display/brcm,bcm-vc4.txt | 36 ++
drivers/gpu/drm/vc4/Kconfig| 1 +
drivers/gpu/drm/vc4/Makefile | 1 +
drivers/gpu/drm/vc4/vc4_debugfs.c | 1 +
drivers/gpu/drm/vc4/vc4_dpi.c | 520 +
drivers/gpu/drm/vc4/vc4_drv.c | 1 +
drivers/gpu/drm/vc4/vc4_drv.h | 5 +
7 files changed, 565 insertions(+)
create mode 100644 drivers/gpu/drm/vc4/vc4_dpi.c
diff --git a/Documentation/devicetree/bindings/display/brcm,bcm-vc4.txt
b/Documentation/devicetree/bindings/display/brcm,bcm-vc4.txt
index 56a961a..14c4fd5 100644
--- a/Documentation/devicetree/bindings/display/brcm,bcm-vc4.txt
+++ b/Documentation/devicetree/bindings/display/brcm,bcm-vc4.txt
@@ -35,6 +35,16 @@ Optional properties for HDMI:
as an interrupt/status bit in the HDMI controller
itself). See bindings/pinctrl/brcm,bcm2835-gpio.txt
+Required properties for DPI:
+- compatible: Should be "brcm,bcm2835-dpi"
+- reg: Physical base address and length of the registers
+- clocks: a) core: The core clock the unit runs on
+ b) pixel: The pixel clock that feeds the pixelvalve
+- port:Port node with a single endpoint connecting to
the
+ panel device, as defined in [1]
+
+[1] Documentation/devicetree/bindings/media/video-interfaces.txt
+
Example:
pixelvalve at 7e807000 {
compatible = "brcm,bcm2835-pixelvalve2";
@@ -60,6 +70,32 @@ hdmi: hdmi at 7e902000 {
clock-names = "pixel", "hdmi";
};
+dpi: dpi at 7e208000 {
+ compatible = "brcm,bcm2835-dpi";
+ reg = <0x7e208000 0x8c>;
+ clocks = <&clocks BCM2835_CLOCK_VPU>,
+<&clocks BCM2835_CLOCK_DPI>;
+ clock-names = "core", "pixel";
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ port {
+ dpi_out: endpoint at 0 {
+ remote-endpoint = <&panel_in>;
+ };
+ };
+};
+
vc4: gpu {
compatible = "brcm,bcm2835-vc4";
};
+
+panel: panel {
+ compatible = "ontat,yx700wv03", "simple-panel";
+
+ port {
+ panel_in: endpoint {
+ remote-endpoint = <&dpi_out>;
+ };
+ };
+};
diff --git a/drivers/gpu/drm/vc4/Kconfig b/drivers/gpu/drm/vc4/Kconfig
index 5848104..e53df59 100644
--- a/drivers/gpu/drm/vc4/Kconfig
+++ b/drivers/gpu/drm/vc4/Kconfig
@@ -5,6 +5,7 @@ config DRM_VC4
select DRM_KMS_HELPER
select DRM_KMS_CMA_HELPER
select DRM_GEM_CMA_HELPER
+ select DRM_PANEL
help
Choose this option if you have a system that has a Broadcom
VC4 GPU, such as the Raspberry Pi or other BCM2708/BCM2835.
diff --git a/drivers/gpu/drm/vc4/Makefile b/drivers/gpu/drm/vc4/Makefile
index 4c6a99f..fb77db7 100644
--- a/drivers/gpu/drm/vc4/Makefile
+++ b/drivers/gpu/drm/vc4/Makefile
@@ -7,6 +7,7 @@ vc4-y := \
vc4_bo.o \
vc4_crtc.o \
vc4_drv.o \
+ vc4_dpi.o \
vc4_kms.o \
vc4_gem.o \
vc4_hdmi.o \
diff --git a/drivers/gpu/drm/vc4/vc4_debugfs.c
b/drivers/gpu/drm/vc4/vc4_debugfs.c
index d76ad10..245115d 100644
--- a/drivers/gpu/drm/vc4/vc4_debugfs.c
+++ b/drivers/gpu/drm/vc4/vc4_debugfs.c
@@ -17,6 +17,7 @@
static const struct drm_info_list vc4_debugfs_list[] = {
{"bo_stats", vc4_bo_stats_debugfs, 0},
+ {"dpi_regs", vc4_dpi_debugfs_regs, 0},
{"hdmi_regs", vc4_hdmi_debugfs_regs, 0},
{"hvs_regs", vc4_hvs_debugfs_regs, 0},
{"crtc0_regs", vc4_crtc_debugfs_regs, 0, (void *)(uintptr_t)0},
diff --git a/drivers/gpu/drm/vc4/vc4_dpi.c b/drivers/gpu/drm/vc4/vc4_dpi.c
new file mode 100644
index 000..9817dbf
--- /dev/null
+++ b/drivers/gpu/drm/vc4/vc4_dpi.c
@@ -0,0 +1,520 @@
+/*
+ * Copyright (C) 2016 Broadcom Limited
+ *
+ * This program is free software; you can redistribute it and/or modify it
+ * under the terms of the GNU General Public License version 2 as published by
+ * the Free Software Foundation.
+ *
+ * This program is distributed in the hope that it will be useful, but WITHOUT
+ * ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or
+ * FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License for
+ * more details.
+ *
+ * You should have received a copy of the GNU General Public License along with
+ * this program. If not, see
[PATCH 5/5] ARM: bcm2835: Add the DPI hardware to the device tree.
It's currently marked disabled, as it's not useful without a panel
associated with it and the GPIO pins routed to ALT2.
Signed-off-by: Eric Anholt
---
arch/arm/boot/dts/bcm283x.dtsi | 11 +++
1 file changed, 11 insertions(+)
diff --git a/arch/arm/boot/dts/bcm283x.dtsi b/arch/arm/boot/dts/bcm283x.dtsi
index bbe4eab..d1e6340 100644
--- a/arch/arm/boot/dts/bcm283x.dtsi
+++ b/arch/arm/boot/dts/bcm283x.dtsi
@@ -166,6 +166,17 @@
interrupts = <2 14>; /* pwa1 */
};
+ dpi: dpi at 7e208000 {
+ compatible = "brcm,bcm2835-dpi";
+ reg = <0x7e208000 0x8c>;
+ clocks = <&clocks BCM2835_CLOCK_VPU>,
+<&clocks BCM2835_CLOCK_DPI>;
+ clock-names = "core", "pixel";
+ #address-cells = <1>;
+ #size-cells = <0>;
+ status = "disabled";
+ };
+
aux: aux at 0x7e215000 {
compatible = "brcm,bcm2835-aux";
#clock-cells = <1>;
--
2.7.0
[pull] radeon and amdgpu drm-next-4.6
Hi Dave, A few fixes for 4.6. The following changes since commit 568d7c764ae01f3706085ac8f0d8a8ac7e826bd7: drm/amdgpu: release_pages requires linux/pagemap.h (2016-03-21 13:22:52 +1000) are available in the git repository at: git://people.freedesktop.org/~agd5f/linux drm-next-4.6 for you to fetch changes up to 1135035d9275ef9aecad23fc715a69ff78904adf: drm/radeon/mst: cleanup code indentation (2016-03-22 16:05:23 -0400) Alex Deucher (1): drm/amdgpu: clean up path handling for powerplay Christian König (2): drm/amdgpu: Revert "remove the userptr rmn->lock" drm/amdgpu: add invalidate_page callback for userptrs Colin Ian King (1): drm/amd/powerplay: fix memory leak of tdp_table Dave Airlie (2): drm/radeon/mst: fix regression in lane/link handling. drm/radeon/mst: cleanup code indentation drivers/gpu/drm/amd/amdgpu/amdgpu_mn.c | 120 +++-- drivers/gpu/drm/amd/powerplay/Makefile | 14 +-- .../amd/powerplay/hwmgr/tonga_processpptables.c| 4 +- drivers/gpu/drm/radeon/radeon_dp_mst.c | 22 ++-- 4 files changed, 102 insertions(+), 58 deletions(-)
Porting GCN pre-1.2 parts from radeon to amdgpu kernel driver
As a follow up, I've been away for quite some time now (long overdue vacations), but I'm back home now. This will be my main project, so we may get something working if I'm lucky. I'll soon be posting a link to my repository where things will be worked on. Cheers. Alexandre Demers On 2016-01-20 20:21, Alexandre Demers wrote: > Thanks to all your feedback. Well, it seems achievable. I may ask some > questions here and there, but I think I'll give it a try. > > Alexandre Demers > > On 2016-01-19 07:58, Christian König wrote: >>> I think Graham summed it up pretty well :) >> Indeed, but there is a detail missing. The main problem for moving SI >> and CIK support from radeon to amdgpu is that we can't break existing >> userspace. >> >> Fortunately amdgpu wasn't designed from scratch, instead it's rather >> a evaluational successor of radeon. Because of that a lot of the >> internal interfaces are still the same. >> >> Additional to that I made the IOCTL numbers from Radeon and Amdgpu >> intentional disjoint. Amdgpu is using 0x00-0x12 and KMS on Radeon is >> using 0x1c-0x2d (we never supported UMS for SI/CIK). >> >> So in theory it would be possible that somebody implements a >> compatibility mode which provides the old Radeon IOCTLs for SI and >> CIK hardware generation in Amdgpu. >> >> This way we could support SI on Amdgpu as well and remove the support >> for SI and CIK from Radeon. >> >> The biggest differences are indeed in the multimedia area, e.g. UVD >> and VCE. But it's still mostly copying the Radeon code to Amdgpu (if >> somebody cares we could even move that into an independent module >> shared by both). >> >> Regards, >> Christian. >> >> Am 18.01.2016 um 23:19 schrieb Deucher, Alexander: -Original Message- From: Sellers, Graham Sent: Monday, January 18, 2016 10:38 AM To: alexandre.f.demers at gmail.com; Deucher, Alexander Cc: dri-devel Subject: RE: Porting GCN pre-1.2 parts from radeon to amdgpu kernel driver Hi Alexandre, Yes, your understanding is correct. Frankly, Alex or one of the other guys on the open source team would be best positioned to answer your questions as to what would specifically need to be done. However, yes, the gap we have here is in the amdgpu kernel driver. I pretty much only work on the user-mode side of things. Think "libVulkan.so" or "vulkan.dll" - the bit that applications link to. We talk to our kernel drivers through standard interfaces. It's the kernel driver that deals with a lot of the differences between different parts of hardware. amdgpu is a ground-up redesign of our kernel solution for Linux. The closed-source kernel driver that we were using in our Catalyst packages has been put out to pasture. For the amdgpu project, given the number of engineers we have, we have to make a tough decision between supporting interesting new features of new GPUs, or sticking with pretty basic support but backporting to older GPUs. The differences in the graphics core itself between SI, CI and VI are actually pretty minimal (as far as the kernel driver is concerned, anyway). Where there are bigger differences are in things like the multimedia (video) engines, display controller, power management and so on. The radeon KMD has full support for all SI and CI (and earlier) "un-core" parts of the GPU. amdgpu has VI product support and some minimal (albeit disabled) support for CI, and basically nothing from SI. Our user-mode Vulkan driver (and closed source OpenGL driver, for that matter) can talk to the amdgpu kernel driver, but not to the radeon kernel driver. The interfaces are quite different, and honestly, the radeon kernel interface isn't a great fit for Vulkan. We had considered trying to support radeon KMD in our Vulkan driver, but it doesn't seem practical. So, it seems that the options would be really to port the non-core support from radeon KMD into amdgpu, or somehow port the new KMD interfaces to radeon KMD, which would allow our Vulkan drivers to run on it, but seems like a bit of a backwards step. There are other complications - such as it being frowned upon to have two kernel drivers for the same piece of hardware, so you'd need to port SI and CI stuff from radeon to amdgpu, and then somehow disable (or remove it) in the radeon KMD such that there was still only one driver for the GPU. It's non-trivial, but not insurmountable. Also, even though the code is there and working in radeon KMD, there are enough differences in the infrastructure that the ported support would need to be re-validated and all that stuff. If
