[PATCH RFC 26/46] drivers/base: provide an infrastructure for componentised subsystems
Hi Russell,
Time for me to jump in. The more, the merrier I suppose.
On Wednesday 26 February 2014 22:19:39 Russell King - ARM Linux wrote:
> On Wed, Feb 26, 2014 at 10:00:25PM +0100, Guennadi Liakhovetski wrote:
> > Hi Russell
> >
> > (I suspect this my email will be rejected by ALKML too like other my
> > recent emails, but at least other MLs will pick it up and individual CCs
> > too, so, if replying, maybe it would be good to keep my entire reply, all
> > the more that it's going to be very short)
> >
> > On Thu, 2 Jan 2014, Russell King wrote:
> > > Subsystems such as ALSA, DRM and others require a single card-level
> > > device structure to represent a subsystem. However, firmware tends to
> > > describe the individual devices and the connections between them.
> > >
> > > Therefore, we need a way to gather up the individual component devices
> > > together, and indicate when we have all the component devices.
> > >
> > > We do this in DT by providing a "superdevice" node which specifies
> > > the components, eg:
> > > imx-drm {
> > > compatible = "fsl,drm";
> > > crtcs = <&ipu1>;
> > > connectors = <&hdmi>;
> > > };
> >
> > It is a pity linux-media wasn't CC'ed and apparently V4L developers didn't
> > notice this and other related patches in a "clean up" series, and now this
> > patch is already in the mainline. But at least I'd like to ask whether the
> > bindings, defined in
> > Documentation/devicetree/bindings/media/video-interfaces.txt and
> > implemented in drivers/media/v4l2-core/v4l2-of.c have been considered for
> > this job, and - if so - why have they been found unsuitable? Wouldn't it
> > have been better to use and - if needed - extend them to cover any
> > deficiencies? Even though the implementation is currently located under
> > drivers/media/v4l2-code/ it's pretty generic and should be easily
> > transferable to a more generic location.
>
> The component helpers have nothing to do with DT apart from solving
> the problem of how to deal with subsystems which expect a single device,
> but we have a group of devices and their individual drivers to cope with.
> Subsystems like DRM and ALSA.
(and V4L2)
Point duly taken. First of all I want to mention that your proposal is
greatly appreciated. This is a problem that crosses subsystem boundaries, and
should thus be addressed centrally.
However, we (as in the V4L2 community, and me personally) would have
appreciated to be CC'ed on the proposal. As you might know we already had a
solution for this problem, albeit V4L2-specific, in drivers/media/v4l2-
core/v4l2-async.c. Whether or not this solution should have been made generic
instead of coming up with a new separate implementation would of course have
been debatable, but the most important point would have been to make sure that
v4l2-async could easily be implemented on top of the common component
architecture.
The topic is particularly hot given that a similar solution was also proposed
as part of the now defunct (or at least hibernating) common display framework.
If I had replied to this mail thread without sleeping on it first I might not
have known better and have got half-paranoid, wondereding whether there had
been a deliberate attempt to fast-track this API before the V4L2 developers
noticed. To be perfectly clear, there is *NO* implicit or explicit such
accusation here, as I know better.
Let's all take this as a positive opportunity to cooperate more closely, media
devices still need a huge effort to be cleanly supported on modern hardware,
and we'll need all the development power we can get.
Accordingly, I would like to comment on the component API, despite the fact
that it has been merged in mainline already. The first thing that I believe is
missing is documentation. Do you have any pending patch for that, either as
kerneldoc or as a text file for Documentation/ ? As I've read the code to
understand it I might have missed so design goals, so please bear with the
stupid questions that may follow.
I'll first provide a brief comparison of the two models to make the rest of
the comments easier to understand.
v4l2-async calls the component master object v4l2_async_notifier. The base
component child object is a v4l2_subdev instance instead of being a plain
device. v4l2_subdev instances are stored in v4l2-async lists similarly to how
the component framework stores objects, except that the list head is directly
embedded inside the v4l2_subdev structure instead of being part of a separate
structure allocated by the framework.
The notifier has three callback functions, bound, complete and unbind. The
bound function is called when one component has been bound to the master.
Similarly the unbind function is called when one component is about to be
unbound from the master. The complete function is called when all components
have been bound, and is thus equivalent to the bind function of the component
framework.
[RFC PATCH v4 3/8] staging: imx-drm: Document updated imx-drm device tree bindings
On Thursday 27 February 2014 16:10:41 Tomi Valkeinen wrote: > On 27/02/14 15:43, Russell King - ARM Linux wrote: > > That may be - but the problem with CDF solving this problem is that it's > > wrong. It's fixing what is in actual fact a *generic* problem in a much > > too specific way. To put it another way, it's forcing everyone to fix > > the same problem in their own separate ways because no one is willing to > > take a step back and look at the larger picture. > > > > We can see that because ASoC has exactly the same problem - it has to > > wait until all devices (DMA, CPU DAIs, codecs etc) are present before it > > can initialise, just like DRM. Can you re-use the CDF solution for ASoC? > > No. Can it be re-used elsewhere in non-display subsystems? No. > > > > Therefore, CDF is yet another implementation specific solution to a > > generic problem which can't be re-used. > > > > Yes, I realise that CDF may do other stuff, but because of the above, it's > > a broken solution. > > What? Because CDF didn't fix a particular subproblem for everyone, it's > broken solution? Or did I miss your point? Furthermore CDF was an RFC, a proof of concept implementation of the various components involved to solve the problems at hand. It was in no way meant to be merged as-is, and I would certainly have made the asynchronous registration code generic had I been requested to do so specifically. Unfortunately and sadly miscommunication lead to CDF being rejected in one block with a fuzzy message on how to proceed. We won't rewrite the past, but let's move forward in the right direction. > The main point of CDF is not solving the initialization issue. If that > was the point, it would've been Common Initialization Framework. > > The main point of CDF is to allow us to have encoder and panel drivers > that can be used by all platforms, in complex display pipeline setups. > It just also has to have some solution for the initialization problem to > get things working. > > In fact, Laurent's CDF version has a solution for init problem which, I > my memory serves me right, is very much similar to yours. It just wasn't > generic. I don't remember if Laurent had a specific master node defined, > but the LCD controller was very much like it. It would be trivial to > change it to use the component helpers. That's correct. The CDF composite device model was based on the V4L2 composite device model, implemented in drivers/media/v4l2-core/v4l2-async.c. Both are very similar in purpose to the component framework. The reason why it wasn't generic in the first place was that I wanted to implement a full solution as a proof of concept first between polishing each part independently. That turned out not to be the best decision ever. > My solution is different, because I don't like the idea of requiring all > the display components to be up and running to use any of the displays. > In fact, it's not a solution at all for me, as it would prevent displays > working on boards that do not have all the display components installed, > or if the user didn't compile all the drivers. As mentioned in my reply to Russell's component framework patch, I would like to base v4l2-async on top of the component framework. For this to be possible we need support for partial bind in the component framework, which would make it possible to support your use cases. Let's discuss how to achieve that in the other mail thread. -- Regards, Laurent Pinchart
[RFC] drm: add kernel-log renderer
Hi On Thu, Mar 6, 2014 at 10:56 PM, Bruno Pr?mont wrote: > Hi David, > > On Thu, 06 March 2014 David Herrmann wrote: >> On modern linux user-space, the VT subsystem is no longer needed for >> system consoles. Although most DEs will fail if VTs are disabled, there >> are several gfx-systems that support this mode. Especially the lower >> system stack has been extended to work without VTs. >> >> However, there is one major drawback if VTs are disabled: You don't get >> oops/panic-screens nor early boot-debugging. The VT subsystem registers a >> console-driver, thus displays the kernel log and oops/panic screens in >> those situations. This patch introduces a fallback for CONFIG_VT=n. >> >> A new DRM-Log core is added. At its heart, DRM-Log maintains a log-buffer >> of kernel-log messages. It registers a console-driver and pushes new >> messages into this buffer whenever they appear. The size of the log-buffer >> can be changed via drm_log_ensure_size(). Initially, a suitable buffer is >> chosen, but whenever drivers register high-res CRTCs, they ought to >> increase that buffer to guarantee there's always enough data to render the >> whole screen. >> This log-buffer is managed at the character-level, not pixel-level. It is >> shared across all users, supports parallel, atomic readers and writers and >> supports seamless resizing. > > Does it make sense to express drm_log_ensure_size() with pixel arguments > and have the buffer below operated in characters? Shouldn't the pixel->char > calculation be done at a higher level? (see also below regarding high-DPI) I don't want to expose "character" sizes. Any external API should be dealing with pixels and only pixels. There is no reason to let them deal with glyphs and text.. Regarding DPI, see below. >> Additionally to the log-buffer handling, a generic software renderer is >> introduced. drm_log_draw() renders the current log-buffer into any >> memory-mapped framebuffer you want. Note that it supports splitting lines >> in case your framebuffer is smaller than the log-buffer, but also merging >> continuation lines in case your framebuffer is wider. This allows >> rendering an 80x25 log-buffer in full-width on high-res displays. On the >> other hand, 800x250 log-buffers can be rendered without information loss >> (apart from a shorter backlog) on low-res displays. > > Would it be possible to pass the dlog_font to drm_log_draw() so that > DRM driver or high-level code could choose a larger font on high-DPI > monitors (think retina-like)? > > Without that option kernel would need to be built specifically for a > given DPI range and not be able to provide readable debug output on > multiple CRTCs with (very) different DPIs. First of all, I won't support any fancy high-DPI features, that's just wrong for debugging stuff. What I can do (and what we do in fallback consoles in user-space) is to add an "dpi" or "scale" argument to drm_log_draw() which does _integer_ scaling of glyphs. This allows you to render glyphs 2x or 3x .. as big as usual. I don't think it makes sense to modify drm_log_ensure_size(). I mean, the worst that can happen is that the *text*-backlog is twice as big as required. But if you have a high-dpi display, you already require like 10x as much space for each framebuffer than for the entire log-buffer. The log-buffer requires 1 byte per *char*. The frambuffer requires at least 8*16*4=512 bytes per char. Anyhow, integer-scaling should be fairly easy to get done. Thanks David
[git pull] drm fixes
Hi Linus, mostly intel and radeon fixes, one tda998x, one kconfig dep fix and two more MAINTAINERS updates, All pretty run of the mill for this stage, Dave. The following changes since commit 0414855fdc4a40da05221fc6062cccbc0c30f169: Linux 3.14-rc5 (2014-03-02 18:56:16 -0800) are available in the git repository at: git://people.freedesktop.org/~airlied/linux drm-fixes for you to fetch changes up to 45db98e54242f3ae94bdcfbfe754e743252eb168: Merge branch 'drm-fixes-3.14' of git://people.freedesktop.org/~agd5f/linux into drm-fixes (2014-03-07 09:27:22 +1000) Akash Goel (1): drm/i915: Resolving the memory region conflict for Stolen area Alex Deucher (4): drm/radeon: resume old pm late drm/radeon/cik: fix typo in documentation drm/radeon/dpm: fix typo in EVERGREEN_SMC_FIRMWARE_HEADER_softRegisters drm/radeon/atom: select the proper number of lanes in transmitter setup Dave Airlie (5): MAINTAINERS: update AGP tree to point at drm tree Merge tag 'drm-intel-fixes-2014-03-04' of ssh://git.freedesktop.org/git/drm-intel into drm-fixes Merge branch 'drm-fixes-3.14' of git://people.freedesktop.org/~agd5f/linux into drm-fixes Merge branch 'drm-armada-fixes' of git://ftp.arm.linux.org.uk/~rmk/linux-cubox into drm-fixes Merge branch 'drm-fixes-3.14' of git://people.freedesktop.org/~agd5f/linux into drm-fixes Gerd Hoffmann (1): drm: fix bochs kconfig dependencies Imre Deak (2): drm/i915: fix pch pci device enumeration drm/i915: vlv: reserve GT power context early Jani Nikula (1): drm/i915: use backlight legacy combination mode also for i915gm/i945gm Lauri Kasanen (1): drm/radeon: TTM must be init with cpu-visible VRAM, v2 Paul Bolle (1): drm/radeon: silence GCC warning on 32 bit Paulo Zanoni (1): drm/i915: fix assert_cursor on BDW Russell King (2): DRM: armada: fix use of kfifo_put() MAINTAINERS: add maintainer entry for TDA998x driver Ville Syrj?l? (1): drm/i915: Reject >165MHz modes w/ DVI monitors MAINTAINERS| 8 +++- drivers/gpu/drm/armada/armada_drv.c| 10 +- drivers/gpu/drm/bochs/Kconfig | 1 + drivers/gpu/drm/i915/i915_drv.c| 23 +-- drivers/gpu/drm/i915/i915_gem_stolen.c | 19 --- drivers/gpu/drm/i915/intel_display.c | 8 drivers/gpu/drm/i915/intel_hdmi.c | 6 +++--- drivers/gpu/drm/i915/intel_panel.c | 4 ++-- drivers/gpu/drm/i915/intel_pm.c| 6 -- drivers/gpu/drm/radeon/atombios_encoders.c | 2 +- drivers/gpu/drm/radeon/cik.c | 5 +++-- drivers/gpu/drm/radeon/evergreen.c | 3 ++- drivers/gpu/drm/radeon/evergreen_smc.h | 2 +- drivers/gpu/drm/radeon/ni.c| 3 ++- drivers/gpu/drm/radeon/r100.c | 2 -- drivers/gpu/drm/radeon/r300.c | 2 -- drivers/gpu/drm/radeon/r420.c | 2 -- drivers/gpu/drm/radeon/r520.c | 2 -- drivers/gpu/drm/radeon/r600.c | 3 ++- drivers/gpu/drm/radeon/radeon_device.c | 5 - drivers/gpu/drm/radeon/radeon_ttm.c| 5 - drivers/gpu/drm/radeon/rs400.c | 2 -- drivers/gpu/drm/radeon/rs600.c | 2 -- drivers/gpu/drm/radeon/rs690.c | 2 -- drivers/gpu/drm/radeon/rv515.c | 2 -- drivers/gpu/drm/radeon/rv770.c | 3 ++- drivers/gpu/drm/radeon/si.c| 3 ++- 27 files changed, 70 insertions(+), 65 deletions(-)
[Bug 75234] UVD initialization fails while dGPU is powered on by DRI_PRIME
https://bugs.freedesktop.org/show_bug.cgi?id=75234 --- Comment #5 from Hohahiu --- Created attachment 95277 --> https://bugs.freedesktop.org/attachment.cgi?id=95277&action=edit dmesg Kernel 3.14-rc5. The bug is still there. See attached dmesg. -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20140307/7d25574c/attachment.html>
[Bug 74868] r600g: Diablo III Crashes After a few minutes
https://bugs.freedesktop.org/show_bug.cgi?id=74868 --- Comment #12 from Nick Tenney --- Commands used: $ apitrace32 wine Diablo\ III.exe $ valgrind --leak-check=full --trace-children=yes --vex-iropt-register-updates=allregs-at-mem-access --workaround-gcc296-bugs=yes --log-file=d3-valgrind-debug_v2 --suppressions=$HOME/valgrind-suppressions apitrace replay d3debug_v2.trace Realized I didn't have an apitrace on here, so I grabbed a new one for posting. Dropbox link is as follows: https://www.dropbox.com/s/1zlzceaho5ym5pa/d3-trace.tar.bz2 sha256sum: f60ded613d5a9dd71629ec75ad2cc3b1f7c93ed80b22f92aeadd0f94f97ade19 My valgrind output was a bit above the limit too: https://www.dropbox.com/s/uyqzxsf1ma5sqds/d3-valgrind-debug_v2 sha256sum: ffb4a35cfd714c78b228bfa0219445648190430324020924c8d04d3ce217a5dc -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20140307/4627bf6d/attachment.html>
[Bug 69723] GPU lockups with kernel 3.11.0 / 3.12-rc1 when dpm=1 on r600g (Cayman)
https://bugs.freedesktop.org/show_bug.cgi?id=69723 --- Comment #106 from Alexandre Demers --- Alex Deucher, should we try https://bugzilla.kernel.org/attachment.cgi?id=128321 as proposed in other bugs? -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20140307/ab1fcd6a/attachment.html>
[Bug 60523] Radeon DPM not working with 2 monitors attached to Radeon HD5770 (Juniper)
https://bugzilla.kernel.org/show_bug.cgi?id=60523 --- Comment #50 from Tobias Droste --- Unfortunately not here. It's still: # echo auto > power_dpm_force_performance_level bash: echo: write error: Invalid argument # echo low > power_dpm_force_performance_level bash: echo: write error: Invalid argument # echo high > power_dpm_force_performance_level bash: echo: write error: Invalid argument -- You are receiving this mail because: You are watching the assignee of the bug.
[RFC] drm: add kernel-log renderer
Hi David, On Fri, 7 Mar 2014 00:41:05 +0100 David Herrmann wrote: > On Thu, Mar 6, 2014 at 10:56 PM, Bruno Pr?mont wrote: > > On Thu, 06 March 2014 David Herrmann wrote: > >> On modern linux user-space, the VT subsystem is no longer needed for > >> system consoles. Although most DEs will fail if VTs are disabled, there > >> are several gfx-systems that support this mode. Especially the lower > >> system stack has been extended to work without VTs. > >> > >> However, there is one major drawback if VTs are disabled: You don't get > >> oops/panic-screens nor early boot-debugging. The VT subsystem registers a > >> console-driver, thus displays the kernel log and oops/panic screens in > >> those situations. This patch introduces a fallback for CONFIG_VT=n. > >> > >> A new DRM-Log core is added. At its heart, DRM-Log maintains a log-buffer > >> of kernel-log messages. It registers a console-driver and pushes new > >> messages into this buffer whenever they appear. The size of the log-buffer > >> can be changed via drm_log_ensure_size(). Initially, a suitable buffer is > >> chosen, but whenever drivers register high-res CRTCs, they ought to > >> increase that buffer to guarantee there's always enough data to render the > >> whole screen. > >> This log-buffer is managed at the character-level, not pixel-level. It is > >> shared across all users, supports parallel, atomic readers and writers and > >> supports seamless resizing. > > > > Does it make sense to express drm_log_ensure_size() with pixel arguments > > and have the buffer below operated in characters? Shouldn't the pixel->char > > calculation be done at a higher level? (see also below regarding high-DPI) > > I don't want to expose "character" sizes. Any external API should be > dealing with pixels and only pixels. There is no reason to let them > deal with glyphs and text.. Regarding DPI, see below. > > >> Additionally to the log-buffer handling, a generic software renderer is > >> introduced. drm_log_draw() renders the current log-buffer into any > >> memory-mapped framebuffer you want. Note that it supports splitting lines > >> in case your framebuffer is smaller than the log-buffer, but also merging > >> continuation lines in case your framebuffer is wider. This allows > >> rendering an 80x25 log-buffer in full-width on high-res displays. On the > >> other hand, 800x250 log-buffers can be rendered without information loss > >> (apart from a shorter backlog) on low-res displays. > > > > Would it be possible to pass the dlog_font to drm_log_draw() so that > > DRM driver or high-level code could choose a larger font on high-DPI > > monitors (think retina-like)? > > > > Without that option kernel would need to be built specifically for a > > given DPI range and not be able to provide readable debug output on > > multiple CRTCs with (very) different DPIs. > > First of all, I won't support any fancy high-DPI features, that's just > wrong for debugging stuff. What I can do (and what we do in fallback > consoles in user-space) is to add an "dpi" or "scale" argument to > drm_log_draw() which does _integer_ scaling of glyphs. This allows you > to render glyphs 2x or 3x .. as big as usual. Integer scaling would do as well. Just some way to avoid tiny glyphs on high-DPI monitors (so that it can be applied per-CRTC) is needed. > I don't think it makes sense to modify drm_log_ensure_size(). I mean, > the worst that can happen is that the *text*-backlog is twice as big > as required. But if you have a high-dpi display, you already require > like 10x as much space for each framebuffer than for the entire > log-buffer. The log-buffer requires 1 byte per *char*. The frambuffer > requires at least 8*16*4=512 bytes per char. That's fair, especially as drm_log_ensure_size() is grow-only. > Anyhow, integer-scaling should be fairly easy to get done. I thought providing the font to drm_log_draw() and express drm_log_ensure_size() in chars - or pass font to it as well - would be easier than scaling. Bruno > Thanks > David
[Bug 60523] Radeon DPM not working with 2 monitors attached to Radeon HD5770 (Juniper)
https://bugzilla.kernel.org/show_bug.cgi?id=60523 --- Comment #51 from Alex Belykh --- And not here. Applying this patch on top of latest drm-next (786a7828bc74b9b1466e83abb200b75f80f94121) resulted in the same kind of lockups ending with reboot. -- You are receiving this mail because: You are watching the assignee of the bug.
[RFC] drm: add kernel-log renderer
Hi >> I don't think it makes sense to modify drm_log_ensure_size(). I mean, >> the worst that can happen is that the *text*-backlog is twice as big >> as required. But if you have a high-dpi display, you already require >> like 10x as much space for each framebuffer than for the entire >> log-buffer. The log-buffer requires 1 byte per *char*. The frambuffer >> requires at least 8*16*4=512 bytes per char. > > That's fair, especially as drm_log_ensure_size() is grow-only. > >> Anyhow, integer-scaling should be fairly easy to get done. > > I thought providing the font to drm_log_draw() and express > drm_log_ensure_size() in chars - or pass font to it as well - would be > easier than scaling. There are no real high-res fonts in ./lib/fonts/ so I don't think that's an option. Besides, we don't want high-res fonts, we just want bigger fonts so scaling seems fine. Thanks David
[Bug 75223] 3840x2160 HDMI 30Hz fails on XFX r7-240a-clh4 and r7-250a-lzh4
https://bugs.freedesktop.org/show_bug.cgi?id=75223 --- Comment #2 from Adam J. Richter --- I confirm that applying your patch to linux-3.13.0 resulted in both XFX Radeon video cards working (r7-240a-clh4 and r7-250a-zlh4). Thank you, Alex! Great work! -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20140307/ff92771c/attachment.html>
[Bug 75223] 3840x2160 HDMI 30Hz fails on XFX r7-240a-clh4 and r7-250a-lzh4
https://bugs.freedesktop.org/show_bug.cgi?id=75223 --- Comment #3 from Adam J. Richter --- Just to clarify, I confirm that that patch made both video cards successfully output 3840x2160 over HDMI to a Seiki se39uy04 television. -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20140307/69271d0e/attachment.html>
[PATCH] drm/fb-helper: Do the mode_set.connectors ZERO_SIZE_PTR check
On Thu, 06 Mar 2014, Xiubo Li wrote: > Since we cannot make sure the 'max_conn_count' will always be none > zero from the users, and then if max_conn_count equals to zero, the > kcalloc() will return ZERO_SIZE_PTR, which equals to ((void *)16). > > So this patch fix this via doing the zero pionter check of it. Please just add a check for max_conn_count == 0 up front and handle it. BR, Jani. > > Signed-off-by: Xiubo Li > --- > drivers/gpu/drm/drm_fb_helper.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/drivers/gpu/drm/drm_fb_helper.c b/drivers/gpu/drm/drm_fb_helper.c > index 3d13ca6e2..c6680ef 100644 > --- a/drivers/gpu/drm/drm_fb_helper.c > +++ b/drivers/gpu/drm/drm_fb_helper.c > @@ -536,7 +536,7 @@ int drm_fb_helper_init(struct drm_device *dev, > sizeof(struct drm_connector *), > GFP_KERNEL); > > - if (!fb_helper->crtc_info[i].mode_set.connectors) > + if > (ZERO_OR_NULL_PTR(fb_helper->crtc_info[i].mode_set.connectors)) > goto out_free; > fb_helper->crtc_info[i].mode_set.num_connectors = 0; > } > -- > 1.8.4 > > > ___ > dri-devel mailing list > dri-devel at lists.freedesktop.org > http://lists.freedesktop.org/mailman/listinfo/dri-devel -- Jani Nikula, Intel Open Source Technology Center
[RFC 3/4] drm: add generic blob properties for image enhancement
On Thu, Mar 06, 2014 at 11:42:13AM +0530, Rahul Sharma wrote:
> Add generic KMS blob properties to core drm framework. These
> are writable blob properties which can be used to set Image
> Enhancement parameters. The properties which are added here
> are meant for color reproduction, color saturation and edge
> enhancement.
>
> Signed-off-by: Rahul Sharma
> ---
> drivers/gpu/drm/drm_crtc.c | 115
> +++
> include/drm/drm_crtc.h | 13 +
> include/uapi/drm/drm_mode.h | 41 +++
> 3 files changed, 169 insertions(+)
>
> diff --git a/drivers/gpu/drm/drm_crtc.c b/drivers/gpu/drm/drm_crtc.c
> index a2b87a5..8771abf 100644
> --- a/drivers/gpu/drm/drm_crtc.c
> +++ b/drivers/gpu/drm/drm_crtc.c
> @@ -1260,6 +1260,121 @@ int drm_mode_create_dirty_info_property(struct
> drm_device *dev)
> }
> EXPORT_SYMBOL(drm_mode_create_dirty_info_property);
>
> +/**
> + * drm_mode_create_color_saturation_property - create property for color
> saturation
> + * @dev: DRM device
> + *
> + */
> +int drm_mode_create_color_saturation_property(
> + struct drm_device *dev)
> +{
> + struct drm_mode_color_saturation *params;
> + struct drm_property *prop;
> + char prop_name[] = "color saturation";
> +
> + if (dev->mode_config.color_saturation_property ||
> + dev->mode_config.color_saturation_blob_ptr)
> + return -EEXIST;
> +
> + prop = drm_property_create(dev, DRM_MODE_PROP_BLOB,
> + prop_name, 0);
> + if (!prop) {
> + DRM_ERROR("fail to create %s property.\n", prop_name);
> + return -ENOMEM;
> + }
> +
> + dev->mode_config.color_saturation_blob_ptr =
> + drm_property_create_blob(dev, sizeof(*params),
> + NULL);
> + if (!dev->mode_config.color_saturation_blob_ptr) {
> + DRM_ERROR("failed to allocate blob for %s.\n", prop_name);
> + drm_property_destroy(dev, prop);
> + return -ENOMEM;
> + }
> +
> + dev->mode_config.color_saturation_property = prop;
> +
> + return 0;
> +}
> +EXPORT_SYMBOL(drm_mode_create_color_saturation_property);
> +
> +/**
> + * drm_mode_create_color_reproduction_property - create property for color
> reproduction
> + * @dev: DRM device
> + *
> + */
> +int drm_mode_create_color_reproduction_property(
> + struct drm_device *dev)
> +{
> + struct drm_mode_color_reproduction *params;
> + struct drm_property *prop;
> + char prop_name[] = "color reproduction";
> +
> + if (dev->mode_config.color_reproduction_property ||
> + dev->mode_config.color_reproduction_blob_ptr)
> + return -EEXIST;
> +
> + prop = drm_property_create(dev, DRM_MODE_PROP_BLOB,
> + prop_name, 0);
> + if (!prop) {
> + DRM_ERROR("fail to create %s property.\n", prop_name);
> + return -ENOMEM;
> + }
> +
> + dev->mode_config.color_reproduction_blob_ptr =
> + drm_property_create_blob(dev, sizeof(*params),
> + NULL);
> + if (!dev->mode_config.color_reproduction_blob_ptr) {
> + DRM_ERROR("failed to allocate blob for %s\n", prop_name);
> + drm_property_destroy(dev, prop);
> + return -ENOMEM;
> + }
> +
> + dev->mode_config.color_reproduction_property = prop;
> +
> + return 0;
> +}
> +EXPORT_SYMBOL(drm_mode_create_color_reproduction_property);
> +
> +
> +/**
> + * drm_mode_create_edge_enhancement_property - create property for edge
> enhancement
> + * @dev: DRM device
> + *
> + */
> +int drm_mode_create_edge_enhancement_property(
> + struct drm_device *dev)
> +{
> + struct drm_mode_edge_enhancement *params;
> + struct drm_property *prop;
> + char prop_name[] = "edge enhancement";
> +
> + if (dev->mode_config.edge_enhancement_property ||
> + dev->mode_config.edge_enhancement_blob_ptr)
> + return -EEXIST;
> +
> + prop = drm_property_create(dev, DRM_MODE_PROP_BLOB,
> + prop_name, 0);
> + if (!prop) {
> + DRM_ERROR("fail to create %s property.\n", prop_name);
> + return -ENOMEM;
> + }
> +
> + dev->mode_config.edge_enhancement_blob_ptr =
> + drm_property_create_blob(dev, sizeof(*params),
> + NULL);
> + if (!dev->mode_config.edge_enhancement_blob_ptr) {
> + DRM_ERROR("failed to allocate blob for %s\n", prop_name);
> + drm_property_destroy(dev, prop);
> + return -ENOMEM;
> + }
> +
> + dev->mode_config.edge_enhancement_property = prop;
> +
> + return 0;
> +}
> +EXPORT_SYMBOL(drm_mode_create_edge_enhancement_property);
> +
> static int drm_mode_group_init(struct drm_device *dev, struct drm_mode_group
> *group)
> {
> uint32_t total_objects = 0;
> diff --git a/include/drm/drm_crtc.h b/include/drm/
[RFC PATCH v2 00/21] Add DSI display support for Exynos based boards
On 03/05/2014 03:56 AM, Inki Dae wrote: > Hi Andrzej, > > Thanks for your contributions. > > 2014-02-12 20:31 GMT+09:00 Andrzej Hajda : >> Hi, >> >> This patchset adds drivers and bindings to the following devices: >> - Exynos DSI master, >> - S6E8AA0 DSI panel, >> - TC358764 DSI/LVDS bridge, >> - HV070WSA-100 LVDS panel. >> >> It adds also display support in DTS files for the following boards: >> - Exynos4210/Trats, >> - Exynos4412/Trats2, >> - Exynos5250/Arndale. >> >> Things worth mentioning: >> >> 1. I have implemented DSI/LVDS bridge using drm_panel framework, ie. >> the driver exposes drm_panel interface on DSI side, and interact with >> panels on LVDS side using drm_panel framework. This approach seems to >> me simpler and more natural than using drm_bridge. > Can you give me more details about why you think better to use panel > framework than using drm_bridge? "Simpler" and "more natural" are > ambiguous to me. In this particular case DSI master expects on the other end any device having DSI slave interface, it could be panel or bridge. So it seems natural that both types of slave devices should expose the same interface also on programming level. Another problem with drm_bridge is that it is not scalable - if some manufacturer will decide to add another block between the bridge and the panel there is no drm component which can be used for it. Using drm_panel the way I have used in toshiba bridge makes scalability possible, it will be only a matter of adding a driver for new block and making proper links in device tree, I see no easy way of doing it with drm_bridge approach. > > Using same drm_panel framework for LDVS bridge and real panel drivers > isn't reasonable to me as now because drm_panel framework would be for > real panel device even if the use of drm_panel framework looks like > suitable to LVDS bridge driver. I thought Sean's way, ptn3460 driver > using drm_bride stuff, is good enough, and that would be why > drm_bridge exists and why drm_encoder has drm_bridge. > > And I'm finding more generic way, how to handle LVDS bridge using > super node so that LVDS bridge driver isn't embedded to connector > drivers such as eDP and MIPI-DSI, and dt binding of LVDS bridge can be > done at top level of Exynos drm. Once the binding is done, encoder of > display bus driver will have drm_bridge object of LVDS bridge driver > so that display bus driver can handle LVDS bridge driver. Could you explain what you mean by "dt binding of LVDS bridge can be done at top level of Exynos drm" ? How it will look like if there will be more bridges, one for DSI, one for HDMI, etc... What if there will be two bridges in one chain. How it will cope with video pipeline bindings? > > Will review your patch series soon. Thanks in advance. Regards Andrzej
[RFC 3/4] drm: add generic blob properties for image enhancement
Hi Daniel,
On 7 March 2014 14:06, Daniel Vetter wrote:
> On Thu, Mar 06, 2014 at 11:42:13AM +0530, Rahul Sharma wrote:
>> Add generic KMS blob properties to core drm framework. These
>> are writable blob properties which can be used to set Image
>> Enhancement parameters. The properties which are added here
>> are meant for color reproduction, color saturation and edge
>> enhancement.
>>
>> Signed-off-by: Rahul Sharma
>> ---
>> drivers/gpu/drm/drm_crtc.c | 115
>> +++
>> include/drm/drm_crtc.h | 13 +
>> include/uapi/drm/drm_mode.h | 41 +++
>> 3 files changed, 169 insertions(+)
>>
>> diff --git a/drivers/gpu/drm/drm_crtc.c b/drivers/gpu/drm/drm_crtc.c
>> index a2b87a5..8771abf 100644
>> --- a/drivers/gpu/drm/drm_crtc.c
>> +++ b/drivers/gpu/drm/drm_crtc.c
>> @@ -1260,6 +1260,121 @@ int drm_mode_create_dirty_info_property(struct
>> drm_device *dev)
>> }
>> EXPORT_SYMBOL(drm_mode_create_dirty_info_property);
>>
>> +/**
>> + * drm_mode_create_color_saturation_property - create property for color
>> saturation
>> + * @dev: DRM device
>> + *
>> + */
>> +int drm_mode_create_color_saturation_property(
>> + struct drm_device *dev)
>> +{
>> + struct drm_mode_color_saturation *params;
>> + struct drm_property *prop;
>> + char prop_name[] = "color saturation";
>> +
>> + if (dev->mode_config.color_saturation_property ||
>> + dev->mode_config.color_saturation_blob_ptr)
>> + return -EEXIST;
>> +
>> + prop = drm_property_create(dev, DRM_MODE_PROP_BLOB,
>> + prop_name, 0);
>> + if (!prop) {
>> + DRM_ERROR("fail to create %s property.\n", prop_name);
>> + return -ENOMEM;
>> + }
>> +
>> + dev->mode_config.color_saturation_blob_ptr =
>> + drm_property_create_blob(dev, sizeof(*params),
>> + NULL);
>> + if (!dev->mode_config.color_saturation_blob_ptr) {
>> + DRM_ERROR("failed to allocate blob for %s.\n", prop_name);
>> + drm_property_destroy(dev, prop);
>> + return -ENOMEM;
>> + }
>> +
>> + dev->mode_config.color_saturation_property = prop;
>> +
>> + return 0;
>> +}
>> +EXPORT_SYMBOL(drm_mode_create_color_saturation_property);
>> +
>> +/**
>> + * drm_mode_create_color_reproduction_property - create property for color
>> reproduction
>> + * @dev: DRM device
>> + *
>> + */
>> +int drm_mode_create_color_reproduction_property(
>> + struct drm_device *dev)
>> +{
>> + struct drm_mode_color_reproduction *params;
>> + struct drm_property *prop;
>> + char prop_name[] = "color reproduction";
>> +
>> + if (dev->mode_config.color_reproduction_property ||
>> + dev->mode_config.color_reproduction_blob_ptr)
>> + return -EEXIST;
>> +
>> + prop = drm_property_create(dev, DRM_MODE_PROP_BLOB,
>> + prop_name, 0);
>> + if (!prop) {
>> + DRM_ERROR("fail to create %s property.\n", prop_name);
>> + return -ENOMEM;
>> + }
>> +
>> + dev->mode_config.color_reproduction_blob_ptr =
>> + drm_property_create_blob(dev, sizeof(*params),
>> + NULL);
>> + if (!dev->mode_config.color_reproduction_blob_ptr) {
>> + DRM_ERROR("failed to allocate blob for %s\n", prop_name);
>> + drm_property_destroy(dev, prop);
>> + return -ENOMEM;
>> + }
>> +
>> + dev->mode_config.color_reproduction_property = prop;
>> +
>> + return 0;
>> +}
>> +EXPORT_SYMBOL(drm_mode_create_color_reproduction_property);
>> +
>> +
>> +/**
>> + * drm_mode_create_edge_enhancement_property - create property for edge
>> enhancement
>> + * @dev: DRM device
>> + *
>> + */
>> +int drm_mode_create_edge_enhancement_property(
>> + struct drm_device *dev)
>> +{
>> + struct drm_mode_edge_enhancement *params;
>> + struct drm_property *prop;
>> + char prop_name[] = "edge enhancement";
>> +
>> + if (dev->mode_config.edge_enhancement_property ||
>> + dev->mode_config.edge_enhancement_blob_ptr)
>> + return -EEXIST;
>> +
>> + prop = drm_property_create(dev, DRM_MODE_PROP_BLOB,
>> + prop_name, 0);
>> + if (!prop) {
>> + DRM_ERROR("fail to create %s property.\n", prop_name);
>> + return -ENOMEM;
>> + }
>> +
>> + dev->mode_config.edge_enhancement_blob_ptr =
>> + drm_property_create_blob(dev, sizeof(*params),
>> + NULL);
>> + if (!dev->mode_config.edge_enhancement_blob_ptr) {
>> + DRM_ERROR("failed to allocate blob for %s\n", prop_name);
>> + drm_property_destroy(dev, prop);
>> + return -ENOMEM;
>> + }
>> +
>> + dev->mode_config.edge_enhancement_property = prop;
>> +
>> + return 0;
>> +}
>> +EXPORT_SYMBOL(drm_mode_create_edge_enhancement_prop
[RFC PATCH v2 08/21] drm/panel: add TC358764 driver
Hi Inki,
Thanks for the review.
On 03/05/2014 07:46 AM, Inki Dae wrote:
> 2014-02-12 20:31 GMT+09:00 Andrzej Hajda :
>> The patch adds driver for Toshiba DSI/LVDS TC358764 bridge.
>> Driver registers itself as mipi_dsi_driver. It is exposed to the
>> system via drm_panel interface, it uses also drm_panel framework
>> to interact with LVDS panel connected to it.
>> Driver supports only DT bindings.
>>
>> Signed-off-by: Andrzej Hajda
>> ---
>> drivers/gpu/drm/panel/Kconfig | 7 +
>> drivers/gpu/drm/panel/Makefile | 1 +
>> drivers/gpu/drm/panel/panel-tc358764.c | 505
>> +
>> 3 files changed, 513 insertions(+)
>> create mode 100644 drivers/gpu/drm/panel/panel-tc358764.c
>>
>> diff --git a/drivers/gpu/drm/panel/Kconfig b/drivers/gpu/drm/panel/Kconfig
>> index 7527557..b98a485 100644
>> --- a/drivers/gpu/drm/panel/Kconfig
>> +++ b/drivers/gpu/drm/panel/Kconfig
>> @@ -23,4 +23,11 @@ config DRM_PANEL_S6E8AA0
>> select DRM_MIPI_DSI
>> select VIDEOMODE_HELPERS
>>
>> +config DRM_PANEL_TC358764
>> + tristate "TC358764 DSI/LVDS bridge"
>> + depends on DRM && DRM_PANEL
>> + depends on OF
>> + select DRM_MIPI_DSI
>> + select VIDEOMODE_HELPERS
>> +
>> endmenu
>> diff --git a/drivers/gpu/drm/panel/Makefile b/drivers/gpu/drm/panel/Makefile
>> index 181265b..7cbb0cf 100644
>> --- a/drivers/gpu/drm/panel/Makefile
>> +++ b/drivers/gpu/drm/panel/Makefile
>> @@ -1,2 +1,3 @@
>> obj-$(CONFIG_DRM_PANEL_SIMPLE) += panel-simple.o
>> obj-$(CONFIG_DRM_PANEL_S6E8AA0) += panel-s6e8aa0.o
>> +obj-$(CONFIG_DRM_PANEL_TC358764) += panel-tc358764.o
>> diff --git a/drivers/gpu/drm/panel/panel-tc358764.c
>> b/drivers/gpu/drm/panel/panel-tc358764.c
>> new file mode 100644
>> index 000..f9c1289
>> --- /dev/null
>> +++ b/drivers/gpu/drm/panel/panel-tc358764.c
>> @@ -0,0 +1,505 @@
>> +/*
>> + * TC358764 MIPI-DSI to LVDS bridge panel driver.
>> + *
>> + * Copyright (c) 2013 Samsung Electronics Co., Ltd
>> + *
>> + * Andrzej Hajda
>> + *
>> + * 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.
>> +*/
>> +
>> +#include
>> +#include
>> +#include
> ...
>> +/* of_* functions will be removed after acceptance of of_graph patches */
>> +static struct device_node *
>> +of_get_child_by_name_reg(struct device_node *parent, const char *name, u32
>> reg)
>> +{
>> + struct device_node *np;
>> +
>> + for_each_child_of_node(parent, np) {
>> + u32 r;
>> +
>> + if (!np->name || of_node_cmp(np->name, name))
>> + continue;
>> +
>> + if (of_property_read_u32(np, "reg", &r) < 0)
>> + r = 0;
>> +
>> + if (reg == r)
>> + break;
>> + }
>> +
>> + return np;
>> +}
>> +
>> +static struct device_node *of_graph_get_port_by_reg(struct device_node
>> *parent,
>> + u32 reg)
>> +{
>> + struct device_node *ports, *port;
>> +
>> + ports = of_get_child_by_name(parent, "ports");
>> + if (ports) {
>> + port = of_get_child_by_name_reg(ports, "port", reg);
>> + of_node_put(ports);
>> + } else {
>> + port = of_get_child_by_name_reg(parent, "port", reg);
>> + }
>> + return port;
>> +}
>> +
>> +static struct device_node *
>> +of_graph_get_endpoint_by_reg(struct device_node *port, u32 reg)
>> +{
>> + return of_get_child_by_name_reg(port, "endpoint", reg);
>> +}
>> +
>> +static struct device_node *
>> +of_graph_get_remote_port_parent(const struct device_node *node)
>> +{
>> + struct device_node *np;
>> + unsigned int depth;
>> +
>> + /* Get remote endpoint node. */
>> + np = of_parse_phandle(node, "remote-endpoint", 0);
>> +
>> + /* Walk 3 levels up only if there is 'ports' node. */
>> + for (depth = 3; depth && np; depth--) {
>> + np = of_get_next_parent(np);
>> + if (depth == 2 && of_node_cmp(np->name, "ports"))
>> + break;
>> + }
>> + return np;
>> +}
>> +
>> +static struct device_node *tc358764_of_find_panel_node(struct device *dev)
>> +{
>> + struct device_node *np, *ep;
>> +
>> + np = of_graph_get_port_by_reg(dev->of_node, 1);
>> + if (!np)
>> + return NULL;
>> +
>> + ep = of_graph_get_endpoint_by_reg(np, 0);
>> + of_node_put(np);
>> + if (!ep)
>> + return NULL;
>> +
>> + np = of_graph_get_remote_port_parent(ep);
>> + of_node_put(ep);
>> +
>> + return np;
>> +}
>> +
>> +static int tc358764_parse_dt(struct tc358764 *ctx)
>> +{
>> + struct device *dev = ctx->dev;
>> + struct device_node *np = dev->of_node;
>> + struct device_node *lvds;
>> +
>> + ctx->reset_g
[PATCH] drm/cma: Use dma_mmap_writecombine() to mmap buffer
On Sun, Mar 2, 2014 at 8:09 PM, Laurent Pinchart wrote: > The GEM CMA helpers uses a custom mmap implementation based on > remap_pfn_range(). While this works when the buffer DMA and physical > addresses are identical, it fails to take IOMMU into account and tries > to mmap the buffer to userspace using the DMA virtual address instead of > the physical address. This results in mapping random physical pages when > the device is behind an IOMMU. > > Use the DMA mapping dma_mmap_writecombine() function instead. > > Signed-off-by: Laurent Pinchart Tested-by: Philipp Zabel regards Philipp
[RFC PATCH v2 03/21] exynos/dsim: add DT bindings
On 03/05/2014 06:56 AM, Inki Dae wrote:
> 2014-02-12 20:31 GMT+09:00 Andrzej Hajda :
>> The patch adds DT bindings for Exynos DSI Master. DSIM follows rules
>> for DSI bus host bindings [1].
>> Properties describes its resources: memory, interrupt, clocks,
>> phy, regulators and frequencies of clocks.
>>
>> [1]: Documentation/devicetree/bindings/mipi/dsi/mipi-dsi-bus.txt
>>
>> Signed-off-by: Andrzej Hajda
>> ---
>> v2
>> - added burst and esc clock frequency properties
>> - add samsung prefix to all frequency props
>> ---
>> .../devicetree/bindings/video/exynos_dsim.txt | 53
>> ++
>> 1 file changed, 53 insertions(+)
>> create mode 100644 Documentation/devicetree/bindings/video/exynos_dsim.txt
>>
>> diff --git a/Documentation/devicetree/bindings/video/exynos_dsim.txt
>> b/Documentation/devicetree/bindings/video/exynos_dsim.txt
>> new file mode 100644
>> index 000..2a49704
>> --- /dev/null
>> +++ b/Documentation/devicetree/bindings/video/exynos_dsim.txt
>> @@ -0,0 +1,53 @@
>> +Exynos MIPI DSI Master
>> +
>> +Required properties:
>> + - compatible: "samsung,exynos4210-mipi-dsi"
>> + - reg: physical base address and length of the registers set for the
>> device
>> + - interrupts: should contain DSI interrupt
>> + - clocks: list of clock specifiers, must contain an entry for each
>> required
>> +entry in clock-names
>> + - clock-names: should include "bus_clk"and "pll_clk" entries
>> + - phys: list of phy specifiers, must contain an entry for each required
>> +entry in phy-names
>> + - phy-names: should include "dsim" entry
>> + - vddcore-supply: MIPI DSIM Core voltage supply (e.g. 1.1V)
>> + - vddio-supply: MIPI DSIM I/O and PLL voltage supply (e.g. 1.8V)
>> + - samsung,pll-clock-frequency: specifies frequency of the "pll_clk" clock
>> + - samsung,burst-clock-frequency: specifies DSI frequency in high-speed
>> burst
>> +mode
>> + - samsung,esc-clock-frequency: specifies DSI frequency in escape mode
>> + - #address-cells, #size-cells: should be set respectively to <1> and <0>
>> +according to DSI host bindings (see MIPI DSI bindings [1])
>> +
>> +Optional properties:
>> + - samsung,power-domain: a phandle to DSIM power domain node
>> +
>> +Child nodes:
>> + Should contain DSI peripheral nodes (see DSI bindings [1])
>> +
>> +[1]: Documentation/devicetree/bindings/mipi/dsi/mipi-dsi-bus.txt
>> +
>> +Example:
>> +
>> + dsi at 11C8 {
>> + compatible = "samsung,exynos4210-mipi-dsi";
>> + reg = <0x11C8 0x1>;
>> + interrupts = <0 79 0>;
>> + clocks = <&clock 286>, <&clock 143>;
>> + clock-names = "bus_clk", "pll_clk";
>> + phys = <&mipi_phy 1>;
>> + phy-names = "dsim";
>> + vddcore-supply = <&vusb_reg>;
>> + vddio-supply = <&vmipi_reg>;
>> + samsung,power-domain = <&pd_lcd0>;
>> + #address-cells = <1>;
>> + #size-cells = <0>;
>> + samsung,pll-clock-frequency = <2400>;
>> + samsung,burst-clock-frequency = <5>;
>> + samsung,esc-clock-frequency = <2000>;
> Isn't a property indicating cpu or video mode needed for the future
> even though now DSI driver doesn't support CPU interface yet? Which
> mode is used would depend on machine.
Mode is determined by panel, ie. by dsi slave.
Regards
Andrzej
>
>> +
>> + panel at 0 {
>> + reg = <0>;
>> + ...
>> + };
>> + };
>> --
>> 1.8.3.2
>>
>> ___
>> dri-devel mailing list
>> dri-devel at lists.freedesktop.org
>> http://lists.freedesktop.org/mailman/listinfo/dri-devel
nouveau crash due to missing channel (WAS: Re: [ANNOUNCE] 3.12.12-rt19)
op 07-03-14 12:18, Sebastian Andrzej Siewior schreef:
> * Fernando Lopez-Lezcano | 2014-03-01 17:48:29 [-0800]:
>
>> On 02/23/2014 10:47 AM, Sebastian Andrzej Siewior wrote:
>>> Dear RT folks!
>>>
>>> I'm pleased to announce the v3.12.12-rt19 patch set.
>> Just hit this Oops in my desktop at home:
>>
>> [22328.388996] BUG: unable to handle kernel NULL pointer dereference
>> at 0008
>> [22328.389013] IP: []
>> nouveau_fence_wait_uevent.isra.2+0x22/0x440 [nouveau]
> This is
>
> | static int
> | nouveau_fence_wait_uevent(struct nouveau_fence *fence, bool intr)
> |
> | {
> | struct nouveau_channel *chan = fence->channel;
> | struct nouveau_fifo *pfifo = nouveau_fifo(chan->drm->device);
>
> and chan is NULL.
>
>> [22328.389046] RAX: RBX: 8807a68f8fa8 RCX:
>>
>> [22328.389046] RDX: 0001 RSI: 8807a68f8fb0 RDI:
>> 8807a68f8fa8
>> [22328.389047] RBP: 8807c09bdca0 R08: 045e R09:
>> e200
>> [22328.389047] R10: a0157d80 R11: 8807c09bdde0 R12:
>> 0001
>> [22328.389047] R13: R14: 8807d8493a80 R15:
>> 8807a68f8fb0
>> [22328.389053] Call Trace:
>> [22328.389069] [] nouveau_fence_wait+0x86/0x1a0 [nouveau]
>> [22328.389081] [] nouveau_bo_fence_wait+0x15/0x20
>> [nouveau]
>> [22328.389084] [] ttm_bo_wait+0x96/0x1a0 [ttm]
>> [22328.389095] []
>> nouveau_gem_ioctl_cpu_prep+0x5c/0xf0 [nouveau]
>> [22328.389101] [] drm_ioctl+0x502/0x630 [drm]
>> [22328.389114] [] nouveau_drm_ioctl+0x51/0x90 [nouveau]
> I can't find any kind of locking so my question is what ensures that chan is
> not set to NULL between nouveau_fence_done() and
> nouveau_fence_wait_uevent()? There are just a few opcodes in between but
> nothing that pauses nouveau_fence_signal().
Absolutely nothing. :-) Worse still, there's no guarantee that channel isn't
freed, but hopefully that is less likely to be an issue.
~Maarten
[RFC PATCH v2 19/21] ARM: dts: exynos5250-arndale: add dsi and panel nodes
On 03/05/2014 01:06 PM, Inki Dae wrote:
> Sorry for interrupting,
>
>
> 2014-03-04 21:00 GMT+09:00 Andrzej Hajda :
>> On 02/28/2014 02:39 PM, Tomi Valkeinen wrote:
>>> On 28/02/14 15:31, Tomi Valkeinen wrote:
>>>
Compared to what I've done on OMAP, you don't seem to specify the video
inputs for the tc358764 at all. In this case it's obvious, as the chip
is a child of the DSI master. But the chip could as well be controlled
via i2c, and so be placed as a child of the i2c nodes.
So even if the driver doesn't use it, maybe it would be more future
proof to have both input and output endpoints for the tc358764?
>>> Oh, and one addition: how me and Laurent see the DSI case (and other
>>> similar ones), the child/parent relationship gives the control bus path,
>>> and the video ports give the video data path.
>>>
>>> So both are always needed. A DSI panel may be controlled via DSI, i2c,
>>> spi, but the video path will always go from DSI master to the panel.
>> I have made video path binding optional, in case of video bus
>> if the specific video path is not present driver uses the bus it is
>> connected to.
> You mean the case that video path isn't wrote in dt file for some
> machine? If so, shouldn't we always write video patch in the dt file
> correctly? I'm not sure the optional binding is needed because which
> bus and which panel are used depends on machine.
>
> And If I understood correctly the video interfaces document, it seems
> that you don't deal with the document.
I have followed the document, I have even specified it in bridge bindings.
I have just made those bindings optional in case control bus is the same
as video bus - DSI master/slave case.
>
> The below is simple dt binding I think in case that video path goes
> from MIPI-DSI to LVDS bridge, and then from LVDS bridge to LCD Panel,
>
> panel {
> ...
> port {
> ...
> panel_0: endpoint {
> remote-endpoint=<&lvds_1>;
> };
> };
> };
>
> lvds {
>...
>port at 1 {
>...
>lvds_0: endpoint {
>remote-endpoint=<&dsi_0>;
>};
>};
>port at 2 {
> ...
> lvds_1: endpoint {
>remote-endpoint=<&panel_0>;
> };
>};
> };
>
> dsi {
> ...
> port {
> dsi_0: endpoint {
> remote-endpoint=<&lvds_0>;
> };
> };
> };
>
I think we should even extend the bindings to fimd:
dsi {
port at 0 {
dsi_0: endpoint {
remote-endpoint=<&fimd_0>;
}
}
port at 1 {
dsi_1: endpoint {
remote-endpoint=<&lvds_0>;
}
}
}
fimd {
port at 0 {
fimd_0: endpoint {
remote-endpoint=<&dsi_0>;
}
}
}
> panel and lvds node could be a child of other masters, maybe i2c or spi.
As I mentioned earlier, in such cases bindings should be specified
explicitly.
My proposition of omitting obvious bindings was made to simplify a bit
dts files,
but as I stated earlier it is not something I want to die for :)
Regards
Andrzej
[PATCH 00/11] SimpleDRM & Sysfb
Hi On Fri, Mar 7, 2014 at 1:44 PM, Tomi Valkeinen wrote: > On 06/03/14 14:16, David Herrmann wrote: >> Hi Tomi >> >> On Mon, Mar 3, 2014 at 12:22 PM, Tomi Valkeinen >> wrote: >>> On 03/03/14 13:09, David Herrmann wrote: >>> > What do you think, would it be possible to keep the sysfb stuff in > arch/x86, and still be able to do the rest of the stuff here? And then > move the sysfs from arch/x86 to drivers/video later? I don't think there's any need for that. Linus does conflict resolution all day long, so a short hint in Dave's pull-request (plus an example merge) should be enough. Same is true for -next, I think. >>> >>> True, but, well, the conflict with this one is not a few lines. "git >>> diff |wc -l" gives 2494 lines for the conflict. It's not really complex >>> to resolve that one, though, as it's really about copying all the stuff >>> into its new place. >>> >>> So I'm not sure if that makes Linus think "this is simple one, 30 secs >>> and done" or "who the f*** sends me this crap" ;). Especially for two >>> reasons: >>> >>> - The fb-reogranization is not very critical, and often clean-ups are >>> not worth it (although I think this one is good one, of course). >>> - Conflicting fbdev changes coming from another tree >>> And this is really just a mechanical thing, nothing hard to do. But of course, it's your decision. However, keeping the code in x86 is the wrong thing to do. As discussed with Ingo, the patch that extends >>> >>> Yes, I didn't mean keeping the code in x86 for good, but just for one >>> kernel version to make merging easier. >>> x86/sysfb is only provided for easier backporting. The followup patch immediately removes it again and adds proper video/sysfb. I'd dislike splitting these just to avoid merge conflicts. I can also maintain a merge-fixup branch in my tree, if anyone wants that. >>> >>> You can have a try at merging. If you think it's trivial, maybe it is >>> and we can just let Linus handle it: >>> >>> git://git.kernel.org/pub/scm/linux/kernel/git/tomba/linux.git >>> work/fb-reorder >> >> Ok, I'm fine with delaying this one more merge-window. However, to >> make things easier, could you pick up the two fbdev cleanups? These >> are: >> fbdev: efifb: add dev->remove() callback >> fbdev: vesafb: add dev->remove() callback >> >> They only add ->remove() callbacks which are never triggered currently >> except with my sysfb series. But I'd like to drop both to make the >> series smaller. > > Yes, I can take them if they work fine without the rest of the patches. > > I could also take all the patches up to patch #6 via fbdev tree. Some of > the patches are for arch x86, but they seem to be still about > framebuffers. But maybe that causes conflicts with x86 tree, then =). > > Then again, maybe we should just go forward and let Linus handle the > conflict. I'm planning to send the "normal" fbdev changes and the > fbdev-reorg separately (just in case Linus doesn't like the reorg), and > that already causes conflicts, very similar to what this series causes. > > So in any case Linus has to handle that conflict, or use a resolution > offered by me. So if fbdev changes and this series are merged in > relatively early phase, I can then send the reorg series a bit later and > offer a conflict resolution that solves the conflicts for both series. > > That way this series doesn't get delayed needlessly in the case that > Linus rejects the reorg series. If you can take these two patches, that's fine. They're not strictly needed by the series and I'd be happy to see them upstream. The other sysfb patches should be merged together, so I don't think there's much gain in applying them through fbdev. The DRM tree is usually merged late, anyway, so I'll see whether we will merge simpledrm through drm-next or not. If not, it'll be 3.16 then. If you can get the fbdev merge in early, that should be enough for us to figure it out and provide a conflict-resolution. Btw., do you want the generic sysfb-helper in drivers/video/ or driver/video/fbdev? It's not limited to fbdev, so I'd put it in drivers/video/. Thanks David
[RFC PATCH v2 19/21] ARM: dts: exynos5250-arndale: add dsi and panel nodes
On 03/07/2014 01:32 PM, Tomi Valkeinen wrote:
> On 07/03/14 14:22, Andrzej Hajda wrote:
>
>> I think we should even extend the bindings to fimd:
>> dsi {
>> port at 0 {
>> dsi_0: endpoint {
>> remote-endpoint=<&fimd_0>;
>> }
>> }
>> port at 1 {
>> dsi_1: endpoint {
>> remote-endpoint=<&lvds_0>;
>> }
>> }
>> }
>>
>> fimd {
>> port at 0 {
>> fimd_0: endpoint {
>> remote-endpoint=<&dsi_0>;
>> }
>> }
>> }
> If both fimd and dsi are SoC components, I don't see any strict need for
> that. I think the ports/endpoints are only important when dealing with
> external components, which can be used on any platform. For SoC internal
> components you can have relevant data directly in the drivers, as it is
> fixed (for that SoC).
>
> Of course, if using ports for SoC internal components makes things
> easier for you, I don't see any problems with it either.
There are many possible connections from FIMD, some of them:
FIMD ---> RGB panel, external
FIMD ---> DSI, on SoC
FIMD ---> eDP, on SoC
FIMD ---> ImageEnhacer, on SoC
In the first case port should be created.
In other cases connection could be determined by presence/absence
of specific nodes, so in fact the port can be optional, almost like in
my proposal :)
>
> For OMAP, the SoC's display blocks are all inside one bigger DSS
> "container", so I have not seen need to represent the connections
> between the internal components in the DT data.
How do you deal with situation when IPs in SoC can be connected in
different ways ?
Andrzej
> If the display components were truly independent IPs on the SoC, then
> using ports might make things easier.
>
> Tomi
>
>
[PATCH] drm/nouveau/fb: mark ramfuc_reg() noinline
Paul Bolle schreef op vr 10-01-2014 om 11:37 [+0100]:
> Building ramnve0.o triggers a GCC warning on 32 bits x86:
> drivers/gpu/drm/nouveau/core/subdev/fb/ramnve0.c: In function
> 'nve0_ram_ctor':
> drivers/gpu/drm/nouveau/core/subdev/fb/ramnve0.c:1253:1: warning: the
> frame size of 1496 bytes is larger than 1024 bytes [-Wframe-larger-than=]
>
> This warning is caused by ramfuc_reg(), which is inlined 74 times in
> nve0_ram_ctor(). Mark it noinline to silence this warning.
>
> Signed-off-by: Paul Bolle
> ---
> Compile tested (on 32 bits x86) only. I've no Nvidia cards at hand, so I
> can't really test it.
>
> This assumes this function - a constructor, apparently - isn't called
Here "this function" refers to nve0_ram_ctor().
> often, so the overhead calling of 74 functions is acceptable. (The same
> goes for the similar functions in [...]/ramnva3.c and in
> [...]/ramnvc0.c, though these call ramfuc_reg() not quite as often.)
> Perhaps there are other downsides to not inlining this function too. So
And here it refers to ramfuc_reg(). So my writing was a bit confusing.
> proper testing will probably be needed.
Building v3.14-rc5 on 32 bit x86 still triggers this warning. Has anyone
tried to review or test this patch?
Paul Bolle
> drivers/gpu/drm/nouveau/core/subdev/fb/ramfuc.h | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/nouveau/core/subdev/fb/ramfuc.h
> b/drivers/gpu/drm/nouveau/core/subdev/fb/ramfuc.h
> index 0f57fcf..04e3849 100644
> --- a/drivers/gpu/drm/nouveau/core/subdev/fb/ramfuc.h
> +++ b/drivers/gpu/drm/nouveau/core/subdev/fb/ramfuc.h
> @@ -26,7 +26,7 @@ ramfuc_reg2(u32 addr1, u32 addr2)
> };
> }
>
> -static inline struct ramfuc_reg
> +static noinline struct ramfuc_reg
> ramfuc_reg(u32 addr)
> {
> return ramfuc_reg2(addr, addr);
915: [drm] stuck on render ring
: 00a3f000 0001ff40 : 1301 0001ff44 : 00c4 0001ff48 : 0001ff4c : 0001ff50 : 1101 0001ff54 : 2044 0001ff58 : 000a5f39 0001ff5c : 0001ff60 : 1101 0001ff64 : 00012040 0001ff68 : 000a5f39 0001ff6c : 0001ff70 : 1081 0001ff74 : 0080 0001ff78 : 000a5f39 0001ff7c : 0100 0001ff80 : 13244001 0001ff84 : 00c4 0001ff88 : 0001ff8c : 0001ff90 : 18800100 0001ff94 : 00a2d000 0001ff98 : 1301 0001ff9c : 00c4 0001ffa0 : 0001ffa4 : 0001ffa8 : 1101 0001ffac : 2044 0001ffb0 : 000a5f3b 0001ffb4 : 0001ffb8 : 1101 0001ffbc : 00012040 0001ffc0 : 000a5f3b 0001ffc4 : 0001ffc8 : 1081 0001ffcc : 0080 0001ffd0 : 000a5f3b 0001ffd4 : 0100 0001ffd8 : 13244001 0001ffdc : 00c4 0001ffe0 : 0001ffe4 : 0001ffe8 : 18800100 0001ffec : 00a3a000 0001fff0 : 1301 0001fff4 : 00c4 0001fff8 : 0001fffc : Num Pipes: 2 Pipe [0]: SRC: 063f0383 Plane [0]: CNTR: 58004000 STRIDE: 1a40 ADDR: SURF: 00072000 TILEOFF: Cursor [0]: CNTR: POS: 018001fb BASE: Pipe [1]: SRC: 068f0419 Plane [1]: CNTR: d8004400 STRIDE: 1c00 ADDR: SURF: 01a4e000 TILEOFF: Cursor [1]: CNTR: 0427 POS: 00d80441 BASE: 00a35000 CPU transcoder: A CONF: 0050 HTOTAL: 07d9063f HBLANK: 07d9063f HSYNC: 06a9067f VTOTAL: 038f0383 VBLANK: 038f0383 VSYNC: 03890386 CPU transcoder: B CONF: c000 HTOTAL: 072f068f HBLANK: 072f068f HSYNC: 06df06bf VTOTAL: 04370419 VBLANK: 04370419 VSYNC: 0422041c -- next part -- A non-text attachment was scrubbed... Name: error-first-1000-lines.txt.sig Type: application/pgp-signature Size: 96 bytes Desc: not available URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20140307/b8397aee/attachment-0001.pgp>
915: [drm] stuck on render ring
On Fri, Mar 07, 2014 at 02:42:56PM +0100, Toralf F?rster wrote: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA256 > > > At a ThinkPad T420 with i915 and kernel 3.12.13 my watchdog scripts > told me : > > Mar 6 18:45:02 n22 kernel: [drm] stuck on render ring > Mar 6 18:45:02 n22 kernel: [drm] stuck on blitter ring > Mar 6 18:45:02 n22 kernel: [drm] capturing error event; look for more > information in /sys/class/drm/card0/error > > > The content of the first 1000 lines of /sys/class/drm/card0/error is > attached. That's not the first 1000 lines... It should compress very well with xz or just plain old gzip. -Chris -- Chris Wilson, Intel Open Source Technology Centre
915: [drm] stuck on render ring
On Fri, Mar 07, 2014 at 02:59:23PM +0100, Toralf F?rster wrote: > ick, attached full compressed file It's the infamous https://bugs.freedesktop.org/show_bug.cgi?id=54226 -Chris -- Chris Wilson, Intel Open Source Technology Centre
[PATCH 00/11] SimpleDRM & Sysfb
Hi Tomi On Fri, Mar 7, 2014 at 2:52 PM, Tomi Valkeinen wrote: > On 07/03/14 15:05, David Herrmann wrote: > >> If you can take these two patches, that's fine. They're not strictly >> needed by the series and I'd be happy to see them upstream. The other >> sysfb patches should be merged together, so I don't think there's much >> gain in applying them through fbdev. > > Ok, I've applied them to fbdev tree. Thanks! >> The DRM tree is usually merged late, anyway, so I'll see whether we >> will merge simpledrm through drm-next or not. If not, it'll be 3.16 >> then. If you can get the fbdev merge in early, that should be enough >> for us to figure it out and provide a conflict-resolution. Btw., do >> you want the generic sysfb-helper in drivers/video/ or >> driver/video/fbdev? It's not limited to fbdev, so I'd put it in >> drivers/video/. > > With a quick glance, it doesn't seem to depend on fbdev in any way, > right? That makes me think drivers/video/. Right! I will keep them in drivers/video/ then. Thanks David
[Bug 75223] 3840x2160 HDMI 30Hz fails on XFX r7-240a-clh4 and r7-250a-lzh4
https://bugs.freedesktop.org/show_bug.cgi?id=75223 Alex Deucher changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #4 from Alex Deucher --- Great. Patch is sent upstream and should show up in the stable series as well soon. -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20140307/3dcbcbee/attachment.html>
Request for feedback : [RFC] Added a new 'window size' property for connector
[ccing dri-devel so other people can see what we're cooking...] On Fri, Mar 07, 2014 at 01:49:18PM +, Goel, Akash wrote: > > In my ideal solution the panel fitter output will be hdisplay/vdisplay > > +/- the border (depending on which way we define it), and the panel > > +fitter > > input size will be defined as a new crtc property. > > Please could you kindly clarify, so as to avoid any ambiguity/confusion on > our side, that by 'hdisplay/vdisplay', are you referring to values programmed > in PIPESRC or 'HACTIVE/VACTIVE' (pipe timings) ? > As per our understanding that border info shall be applied on the > 'HACTIVE/VACTIVE', i.e. (HACTIVE - Left border - Right Border) x (VACTIVE > - Top Border - Bottom border) will be the output rectangle on screen. I mean what's there in the mode structure. So if we define the border as something that reduces hactive/vactice, we'd program the pfit output size as hactive-left_border-right_border x vactive-top_border-bottom_border. > > Please also confirm for the border info, you prefer a new property or an > update of the 'drm_mode_modeinfo' structure ? We can't change the already existing structure, so if we want to update it we'd need drm_mode_modeinfo2 or something and a new set ioctls. My sense of aestethics would prefer that, but from a practical point of view properties seem like the easier choice. > If the panel fitter input size is defined as a new crtc property, then once > User modifies the input size through this property, PIPESRC shall also be > updated with it at that time. But actually change in PIPESRC programming > alone, could also require a reprogramming of the Panel fitter in some cases. Yeah. Before the atomic modeset API is introduced, userspace might want to first disable the crtc, then change the properties, and then set a new mode. That would make it appear atomic and it can avoid problems where the intermediate state isn't exactly valid. > > Best Regards > Akash > > -Original Message- > From: Ville Syrj?l? [mailto:ville.syrjala at linux.intel.com] > Sent: Friday, March 07, 2014 6:31 PM > To: Goel, Akash > Cc: Chris Wilson; intel-gfx at lists.freedesktop.org; G, Pallavi; > Purushothaman, Vijay A > Subject: Re: Request for feedback : [RFC] Added a new 'window size' property > for connector > > On Fri, Mar 07, 2014 at 12:45:26PM +, Goel, Akash wrote: > > Thanks for your feedback. > > > > > No, fb_id is passed through setcrtc (or soon through setplane, I hope). > > Actually mentioned 'fb_id' also, because if PIPESRC programming is also > > being updated (as Panel fitter input), then the 'fb' already attached to > > 'crtc' may not be aligned with it. So there could be a momentary corruption > > caused when internal modeset is done by Driver (to change the Panel fitter > > setting), which will last till the next page flip (or setplane). > > > > > > No, we need both the border and the PIPESRC information. > > > hdisplay/vdisplays isn't enough since the user facing mode structure > > > doesn't have vblank_start/end fields. Hence we can't specify borders. > > > If we don't want to extend the display mode, we should add border > > > properties of some sort. I know some drivers have added something like > > > that to the connectors, but again since the mode is applied to the crtc, > > > ideally these properties should also be on the crtc. > > > > Sorry but it's not quite clear. This is what is my understanding so far, > > please kindly correct wherever wrong. > > > > 1. We need border info for the output of Panel fitter, which will > > determine the display window. Using the border info we will manipulate the > > hblank/vblank start/end fields. > > 2. Currently the values of 'hdisplay/vdisplay' fields sent in > > 'drm_mode_modeinfo' structure gets programmed in PIPESRC. So if we are > > adding border info to the same structure, then we can use the > > 'hdisplay/vdisplay' fields only for > > PIPESRC. But if we are defining a new property, to convey the border > > info, then we need the PIPESRC information also along with it. > > > > Please confirm that should we add a new a 'blob' type property for 'crtc' ? > > In my ideal solution the panel fitter output will be hdisplay/vdisplay > +/- the border (depending on which way we define it), and the panel > +fitter > input size will be defined as a new crtc property. > > -- > Ville Syrj?l? > Intel OTC -- Ville Syrj?l? Intel OTC
[Bug 69723] GPU lockups with kernel 3.11.0 / 3.12-rc1 when dpm=1 on r600g (Cayman)
https://bugs.freedesktop.org/show_bug.cgi?id=69723 --- Comment #107 from Alex Deucher --- (In reply to comment #106) > Alex Deucher, should we try > https://bugzilla.kernel.org/attachment.cgi?id=128321 as proposed in other > bugs? No, that patch only applies to evergreen and BTC parts. -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20140307/ed7ec680/attachment.html>
[PATCH 3/9] Doc/DT: Add DT binding documentation for DVI Connector
Hi, Am Donnerstag, den 06.03.2014, 10:52 +0200 schrieb Tomi Valkeinen: > On 06/03/14 10:39, Geert Uytterhoeven wrote: > > On Wed, Mar 5, 2014 at 9:41 AM, Tomi Valkeinen > > wrote: > >> On 28/02/14 18:23, Russell King - ARM Linux wrote: > >> > >>> That's rather a lot of compatible strings. Another possibility is: > >>> > >>> compatible = "dvi-connector"; > >>> analog; > >>> digital; > >>> single-link; > >>> dual-link; > >> > >> I made the following changes compared to the posted version. I decided > >> to leave the "single-link" out, as it's implied if "digital" is set. > >> > >> Tomi > >> > >> @@ -6,11 +6,16 @@ Required properties: > >> > >> Optional properties: > >> - label: a symbolic name for the connector > >> -- i2c-bus: phandle to the i2c bus that is connected to DVI DDC > >> +- ddc-i2c-bus: phandle to the i2c bus that is connected to DVI DDC > >> +- analog: the connector has DVI analog pins > >> +- digital: the connector has DVI digital pins > >> +- dual-link: the connector has pins for DVI dual-link > >> > >> Required nodes: > >> - Video port for DVI input > >> > >> +Note: One (or both) of 'analog' or 'digital' must be set. > > > > So dual-link needs both "digital" and "dual-link"? > > Yes. It is extra, but it felt clearer to me to have 'digital' as a > matching property for 'analog'. > > Alternatively we could have three options: > > analog; > digital-single-link; > digital-dual-link; > > My reasoning to the format I chose was basically that when a connector > supports 'digital', it contains TMDS clock and TMDS data for link 1. > Adding dual link to that adds only TMDS data for link 2, so the second > data link is kind of an additional feature, marked with a flag. > > Not a very big argument, and I'm fine with other format suggestions. I'd prefer the analog / digital / dual-link variant for aesthetic reasons. But looking at other connector types, I wonder if this should be generalized even more: For HDMI/DVI (digital) single-link means one clock pair and 3 TMDS data pairs, dual-link means one clock pair and 6 data pairs. On LVDS connectors, there usually are one clock pair and three (18-bit) or four (24-bit) LVDS data pairs, in dual channel configuration two clock pairs and 6 or 8 data pairs are used. For DisplayPort there is no separate clock pair, but 1 to 4 data pairs, and MIPI DSI again has one clock pair and a one or more data pairs. There are already optional endpoint configuration properties 'data-lanes' and 'clock-lanes' for MIPI CSI-2 defined in Documentation/devicetree/bindings/media/video-interfaces.txt. Could/should this be aligned with the same? regards Philipp
[RFC PATCH v2 19/21] ARM: dts: exynos5250-arndale: add dsi and panel nodes
On 03/07/2014 02:28 PM, Tomi Valkeinen wrote: (...) > There are many possible connections from FIMD, some of them: > FIMD ---> RGB panel, external > FIMD ---> DSI, on SoC > FIMD ---> eDP, on SoC > FIMD ---> ImageEnhacer, on SoC > This sounds similar to OMAP, at least roughly. > >> In the first case port should be created. >> In other cases connection could be determined by presence/absence >> of specific nodes, so in fact the port can be optional, almost like in >> my proposal :) > Well, I think not. > > In the external encoder case, the ports are there, and they are used. > You just didn't specify them, and thus make the driver deduce them from > the DT. > > In the FIMD case, if the the RGB port is needed, you need to specify it > in the DT data, and it's used. If you only need, say, DSI, the RGB port > is not used and thus it doesn't need to be present in the DT data. > > It's fine to leave the port definition out if it is not used at all. On Exynos, DSI is in fact RGB/DSI encoder (or I80/DSI). DSI and RGB pins are connected to the same FIMD output. So from FIMD point of view RGB port is used in both cases. > >>> For OMAP, the SoC's display blocks are all inside one bigger DSS >>> "container", so I have not seen need to represent the connections >>> between the internal components in the DT data. >> How do you deal with situation when IPs in SoC can be connected in >> different ways ? > Basically so that (using exynos terms) if, say DSI panel is to be > enabled, the DSI panel driver will reserve the DSI master for itself, > and the DSI master will reserve the FIMD for itself, presuming FIMD has > not already been reserved. When the DSI panel is disabled, FIMD is freed. > > Tomi > >
[PATCH 2/2] imx-drm: imx-ldb: Use OF graph to find connected panel
On Thu, Mar 06, 2014 at 02:54:40PM +0100, Philipp Zabel wrote: > @@ -566,9 +566,18 @@ static int imx_ldb_bind(struct device *dev, struct > device *master, void *data) > return -EINVAL; > } > > - panel_node = of_parse_phandle(child, "fsl,panel", 0); > - if (panel_node) > - channel->panel = of_drm_find_panel(panel_node); > + /* The output port is port at 4 with mux or port at 1 without > mux */ > + port = of_graph_get_port_by_id(child, imx_ldb->lvds_mux ? 4 : > 1); I guess we're holding off on these two patches while the last bits of the of-graph get sorted - the above function doesn't currently exist so causes a build failure. Thanks. -- FTTC broadband for 0.8mile line: now at 9.7Mbps down 460kbps up... slowly improving, and getting towards what was expected from it.
[PATCH 1/2] imx-drm: imx-ldb: Add drm_panel support
On Thu, Mar 06, 2014 at 02:54:39PM +0100, Philipp Zabel wrote: > This patch allows to optionally attach the lvds-channel to a panel > supported by a drm_panel driver instead of supplying the modes via > device tree. Hmm, I think something may be missing in this patch... you're introducing calls into the drm panel code, but there's nothign which ensures that code gets built alongside imx-ldb.c. With imx-ldb built as a module, I get: ERROR: "drm_panel_attach" [drivers/staging/imx-drm/imx-ldb.ko] undefined! ERROR: "of_drm_find_panel" [drivers/staging/imx-drm/imx-ldb.ko] undefined! -- FTTC broadband for 0.8mile line: now at 9.7Mbps down 460kbps up... slowly improving, and getting towards what was expected from it.
[PATCH 1/2] imx-drm: imx-ldb: Add drm_panel support
Hi Russell, Am Freitag, den 07.03.2014, 17:22 + schrieb Russell King - ARM Linux: > On Thu, Mar 06, 2014 at 02:54:39PM +0100, Philipp Zabel wrote: > > This patch allows to optionally attach the lvds-channel to a panel > > supported by a drm_panel driver instead of supplying the modes via > > device tree. > > Hmm, I think something may be missing in this patch... you're introducing > calls into the drm panel code, but there's nothign which ensures that > code gets built alongside imx-ldb.c. With imx-ldb built as a module, > I get: > > ERROR: "drm_panel_attach" [drivers/staging/imx-drm/imx-ldb.ko] undefined! > ERROR: "of_drm_find_panel" [drivers/staging/imx-drm/imx-ldb.ko] undefined! Thanks for testing. Yes, this Kconfig change is missing from patch 1: diff --git a/drivers/staging/imx-drm/Kconfig b/drivers/staging/imx-drm/Kconfig index 82fb758..8e5b7e9 100644 --- a/drivers/staging/imx-drm/Kconfig +++ b/drivers/staging/imx-drm/Kconfig @@ -35,6 +35,7 @@ config DRM_IMX_TVE config DRM_IMX_LDB tristate "Support for LVDS displays" depends on DRM_IMX && MFD_SYSCON + select DRM_PANEL help Choose this to enable the internal LVDS Display Bridge (LDB) found on i.MX53 and i.MX6 processors. I haven't noticed because I've enabled the parallel display driver, which does correctly select DRM_PANEL. regards Philipp
[PATCH v5 00/11] imx-drm dt bindings
On Wed, Mar 05, 2014 at 10:20:51AM +0100, Philipp Zabel wrote: > Hi, > > this latest version of the imx-drm DT binding patches applies > on top of staging-next and also depends on the OF graph binding > patchset that moves the v4l2_of helpers to drivers/of. > Currently, the two patchsets are also available at: > git://git.pengutronix.de/git/pza/linux.git topic/of-graph > git://git.pengutronix.de/git/pza/linux.git topic/imx-drm-dt Okay, having looked at the second tree, pulling that will result in pulling in all of the staging tree here, which I'd rather not do. Unless there's any objection, I'd like to take these as patches on top of the imx-drm stuff which I sent to Greg plus the of-graph stuff which they depend upon. In other words, exactly how I've been testing it today. Any objections? -- FTTC broadband for 0.8mile line: now at 9.7Mbps down 460kbps up... slowly improving, and getting towards what was expected from it.
[Bug 68571] GPU lockup on AMD Radeon HD6850 with DPM=1
https://bugzilla.kernel.org/show_bug.cgi?id=68571 --- Comment #34 from Mihai Coman --- Is there a compiled kernel available for ubuntu that includes this patch? -- You are receiving this mail because: You are watching the assignee of the bug.
[PATCH v5 00/11] imx-drm dt bindings
On Fri, Mar 07, 2014 at 05:56:12PM +, Russell King - ARM Linux wrote: > On Wed, Mar 05, 2014 at 10:20:51AM +0100, Philipp Zabel wrote: > > Hi, > > > > this latest version of the imx-drm DT binding patches applies > > on top of staging-next and also depends on the OF graph binding > > patchset that moves the v4l2_of helpers to drivers/of. > > Currently, the two patchsets are also available at: > > git://git.pengutronix.de/git/pza/linux.git topic/of-graph > > git://git.pengutronix.de/git/pza/linux.git topic/imx-drm-dt > > Okay, having looked at the second tree, pulling that will result in > pulling in all of the staging tree here, which I'd rather not do. Unless > there's any objection, I'd like to take these as patches on top of the > imx-drm stuff which I sent to Greg plus the of-graph stuff which they > depend upon. In other words, exactly how I've been testing it today. > > Any objections? None from me! :)
[PATCH v5 00/11] imx-drm dt bindings
[Added Shawn to Cc:] On Fri, Mar 7, 2014 at 7:28 PM, Greg Kroah-Hartman wrote: > On Fri, Mar 07, 2014 at 05:56:12PM +, Russell King - ARM Linux wrote: >> On Wed, Mar 05, 2014 at 10:20:51AM +0100, Philipp Zabel wrote: >> > Hi, >> > >> > this latest version of the imx-drm DT binding patches applies >> > on top of staging-next and also depends on the OF graph binding >> > patchset that moves the v4l2_of helpers to drivers/of. >> > Currently, the two patchsets are also available at: >> > git://git.pengutronix.de/git/pza/linux.git topic/of-graph >> > git://git.pengutronix.de/git/pza/linux.git topic/imx-drm-dt >> >> Okay, having looked at the second tree, pulling that will result in >> pulling in all of the staging tree here, which I'd rather not do. Unless >> there's any objection, I'd like to take these as patches on top of the >> imx-drm stuff which I sent to Greg plus the of-graph stuff which they >> depend upon. In other words, exactly how I've been testing it today. >> >> Any objections? > > None from me! :) Nor from me. But I'd like to point out that there already is one merge issue with Shawn's for-next branch in arch/arm/boot/dts/imx53-qsb.dts between d5eb195 "ARM: dts: i.MX53: move common QSB nodes to new file" and these two patches: 17b5001 "imx-drm: convert to componentised device support". "ARM: dts: imx53: Add IPU DI ports and endpoints, move imx-drm node to dtsi" The first one already is in staging-next. regards Philipp
[PATCH v5 00/11] imx-drm dt bindings
On Fri, Mar 07, 2014 at 07:57:51PM +0100, Philipp Zabel wrote: > [Added Shawn to Cc:] > > On Fri, Mar 7, 2014 at 7:28 PM, Greg Kroah-Hartman > wrote: > > On Fri, Mar 07, 2014 at 05:56:12PM +, Russell King - ARM Linux wrote: > >> On Wed, Mar 05, 2014 at 10:20:51AM +0100, Philipp Zabel wrote: > >> > Hi, > >> > > >> > this latest version of the imx-drm DT binding patches applies > >> > on top of staging-next and also depends on the OF graph binding > >> > patchset that moves the v4l2_of helpers to drivers/of. > >> > Currently, the two patchsets are also available at: > >> > git://git.pengutronix.de/git/pza/linux.git topic/of-graph > >> > git://git.pengutronix.de/git/pza/linux.git topic/imx-drm-dt > >> > >> Okay, having looked at the second tree, pulling that will result in > >> pulling in all of the staging tree here, which I'd rather not do. Unless > >> there's any objection, I'd like to take these as patches on top of the > >> imx-drm stuff which I sent to Greg plus the of-graph stuff which they > >> depend upon. In other words, exactly how I've been testing it today. > >> > >> Any objections? > > > > None from me! :) > > Nor from me. But I'd like to point out that there already is one merge issue > with Shawn's for-next branch in arch/arm/boot/dts/imx53-qsb.dts between > d5eb195 "ARM: dts: i.MX53: move common QSB nodes to new file" > and these two patches: > 17b5001 "imx-drm: convert to componentised device support". > "ARM: dts: imx53: Add IPU DI ports and endpoints, move imx-drm node to > dtsi" > The first one already is in staging-next. Yes, I'm aware of that (since I've been encountering it when creating the build tree for my autobuilder.) Thanks. -- FTTC broadband for 0.8mile line: now at 9.7Mbps down 460kbps up... slowly improving, and getting towards what was expected from it.
nouveau crash due to missing channel (WAS: Re: [ANNOUNCE] 3.12.12-rt19)
* Fernando Lopez-Lezcano | 2014-03-01 17:48:29 [-0800]:
>On 02/23/2014 10:47 AM, Sebastian Andrzej Siewior wrote:
>>Dear RT folks!
>>
>>I'm pleased to announce the v3.12.12-rt19 patch set.
>
>Just hit this Oops in my desktop at home:
>
>[22328.388996] BUG: unable to handle kernel NULL pointer dereference
>at 0008
>[22328.389013] IP: []
>nouveau_fence_wait_uevent.isra.2+0x22/0x440 [nouveau]
This is
| static int
| nouveau_fence_wait_uevent(struct nouveau_fence *fence, bool intr)
|
| {
| struct nouveau_channel *chan = fence->channel;
| struct nouveau_fifo *pfifo = nouveau_fifo(chan->drm->device);
and chan is NULL.
>[22328.389046] RAX: RBX: 8807a68f8fa8 RCX:
>
>[22328.389046] RDX: 0001 RSI: 8807a68f8fb0 RDI:
>8807a68f8fa8
>[22328.389047] RBP: 8807c09bdca0 R08: 045e R09:
>e200
>[22328.389047] R10: a0157d80 R11: 8807c09bdde0 R12:
>0001
>[22328.389047] R13: R14: 8807d8493a80 R15:
>8807a68f8fb0
>[22328.389053] Call Trace:
>[22328.389069] [] nouveau_fence_wait+0x86/0x1a0 [nouveau]
>[22328.389081] [] nouveau_bo_fence_wait+0x15/0x20
>[nouveau]
>[22328.389084] [] ttm_bo_wait+0x96/0x1a0 [ttm]
>[22328.389095] []
>nouveau_gem_ioctl_cpu_prep+0x5c/0xf0 [nouveau]
>[22328.389101] [] drm_ioctl+0x502/0x630 [drm]
>[22328.389114] [] nouveau_drm_ioctl+0x51/0x90 [nouveau]
I can't find any kind of locking so my question is what ensures that chan is
not set to NULL between nouveau_fence_done() and
nouveau_fence_wait_uevent()? There are just a few opcodes in between but
nothing that pauses nouveau_fence_signal().
Fernando, can you please check the patch below and test if the warning
or the crash appears?
diff --git a/drivers/gpu/drm/nouveau/nouveau_fence.c
b/drivers/gpu/drm/nouveau/nouveau_fence.c
--- a/drivers/gpu/drm/nouveau/nouveau_fence.c
+++ b/drivers/gpu/drm/nouveau/nouveau_fence.c
@@ -184,14 +184,20 @@ nouveau_fence_wait_uevent(struct nouveau_fence *fence,
bool intr)
{
struct nouveau_channel *chan = fence->channel;
- struct nouveau_fifo *pfifo = nouveau_fifo(chan->drm->device);
- struct nouveau_fence_priv *priv = chan->drm->fence;
+ struct nouveau_fifo *pfifo;
+ struct nouveau_fence_priv *priv;
struct nouveau_fence_uevent uevent = {
.handler.func = nouveau_fence_wait_uevent_handler,
- .priv = priv,
};
int ret = 0;
+ if (WARN_ON_ONCE(!chan))
+ return 0;
+
+ pfifo = nouveau_fifo(chan->drm->device);
+ priv = chan->drm->fence;
+ uevent.priv = priv;
+
nouveau_event_get(pfifo->uevent, 0, &uevent.handler);
if (fence->timeout) {
>-- Fernando
Sebastian
[RFC PATCH v2 19/21] ARM: dts: exynos5250-arndale: add dsi and panel nodes
On 07/03/14 14:22, Andrzej Hajda wrote:
> I think we should even extend the bindings to fimd:
> dsi {
> port at 0 {
> dsi_0: endpoint {
> remote-endpoint=<&fimd_0>;
> }
> }
> port at 1 {
> dsi_1: endpoint {
> remote-endpoint=<&lvds_0>;
> }
> }
> }
>
> fimd {
> port at 0 {
> fimd_0: endpoint {
> remote-endpoint=<&dsi_0>;
> }
> }
> }
If both fimd and dsi are SoC components, I don't see any strict need for
that. I think the ports/endpoints are only important when dealing with
external components, which can be used on any platform. For SoC internal
components you can have relevant data directly in the drivers, as it is
fixed (for that SoC).
Of course, if using ports for SoC internal components makes things
easier for you, I don't see any problems with it either.
For OMAP, the SoC's display blocks are all inside one bigger DSS
"container", so I have not seen need to represent the connections
between the internal components in the DT data.
If the display components were truly independent IPs on the SoC, then
using ports might make things easier.
Tomi
-- next part --
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 901 bytes
Desc: OpenPGP digital signature
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140307/f540b7b8/attachment.pgp>
[RFC] drm: add kernel-log renderer
> - The renderer supports *any* RGB target, from 8bit to 32bit with >big-endian and little-endian support. The related pixel-renderer will >probably never win a beauty-contest, but it works.. Again, who cares >for debug-log rendering speed? Debug log writing performance is extremely important when you are using the log for debugging work rather than for panic display. I don't think that is a show stopper because having a logger makes sense and someone can write a better render engine if they care. Supporting any target is also going to be useful but you do need to support non linear framebuffers. A GMA500 with something like an X display in use for example does not have a linear mapping of the framebuffer memory. I don't believe its exactly unique in this. What I am more dubious about is tying it to DRM. Yes it uses DRM constants but it doesn't appear functionally to have a single tie to either DRM or even framebuffer. It's potentially useful in cases where neither framebuffer or DRM are compiled into the system. Alan
nouveau crash due to missing channel (WAS: Re: [ANNOUNCE] 3.12.12-rt19)
* Maarten Lankhorst | 2014-03-07 12:36:13 [+0100]: >>I can't find any kind of locking so my question is what ensures that chan is >>not set to NULL between nouveau_fence_done() and >>nouveau_fence_wait_uevent()? There are just a few opcodes in between but >>nothing that pauses nouveau_fence_signal(). >Absolutely nothing. :-) Worse still, there's no guarantee that channel isn't >freed, but hopefully that is less likely to be an issue. Okay, so I hit the correct spot. What do we do here? Do you want the patch I posted without the WARN_ON() or do you prefer to fix this in an other way? >~Maarten Sebastian
[PATCH 00/11] SimpleDRM & Sysfb
On 06/03/14 14:16, David Herrmann wrote: > Hi Tomi > > On Mon, Mar 3, 2014 at 12:22 PM, Tomi Valkeinen > wrote: >> On 03/03/14 13:09, David Herrmann wrote: >> >>>> What do you think, would it be possible to keep the sysfb stuff in >>>> arch/x86, and still be able to do the rest of the stuff here? And then >>>> move the sysfs from arch/x86 to drivers/video later? >>> >>> I don't think there's any need for that. Linus does conflict >>> resolution all day long, so a short hint in Dave's pull-request (plus >>> an example merge) should be enough. Same is true for -next, I think. >> >> True, but, well, the conflict with this one is not a few lines. "git >> diff |wc -l" gives 2494 lines for the conflict. It's not really complex >> to resolve that one, though, as it's really about copying all the stuff >> into its new place. >> >> So I'm not sure if that makes Linus think "this is simple one, 30 secs >> and done" or "who the f*** sends me this crap" ;). Especially for two >> reasons: >> >> - The fb-reogranization is not very critical, and often clean-ups are >> not worth it (although I think this one is good one, of course). >> - Conflicting fbdev changes coming from another tree >> >>> And this is really just a mechanical thing, nothing hard to do. But of >>> course, it's your decision. However, keeping the code in x86 is the >>> wrong thing to do. As discussed with Ingo, the patch that extends >> >> Yes, I didn't mean keeping the code in x86 for good, but just for one >> kernel version to make merging easier. >> >>> x86/sysfb is only provided for easier backporting. The followup patch >>> immediately removes it again and adds proper video/sysfb. I'd dislike >>> splitting these just to avoid merge conflicts. I can also maintain a >>> merge-fixup branch in my tree, if anyone wants that. >> >> You can have a try at merging. If you think it's trivial, maybe it is >> and we can just let Linus handle it: >> >> git://git.kernel.org/pub/scm/linux/kernel/git/tomba/linux.git >> work/fb-reorder > > Ok, I'm fine with delaying this one more merge-window. However, to > make things easier, could you pick up the two fbdev cleanups? These > are: > fbdev: efifb: add dev->remove() callback > fbdev: vesafb: add dev->remove() callback > > They only add ->remove() callbacks which are never triggered currently > except with my sysfb series. But I'd like to drop both to make the > series smaller. Yes, I can take them if they work fine without the rest of the patches. I could also take all the patches up to patch #6 via fbdev tree. Some of the patches are for arch x86, but they seem to be still about framebuffers. But maybe that causes conflicts with x86 tree, then =). Then again, maybe we should just go forward and let Linus handle the conflict. I'm planning to send the "normal" fbdev changes and the fbdev-reorg separately (just in case Linus doesn't like the reorg), and that already causes conflicts, very similar to what this series causes. So in any case Linus has to handle that conflict, or use a resolution offered by me. So if fbdev changes and this series are merged in relatively early phase, I can then send the reorg series a bit later and offer a conflict resolution that solves the conflicts for both series. That way this series doesn't get delayed needlessly in the case that Linus rejects the reorg series. Tomi -- next part -- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 901 bytes Desc: OpenPGP digital signature URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20140307/cf6449eb/attachment-0001.pgp>
[PATCH 0/9] Doc/DT: DT bindings for various display components
On 03/03/14 10:04, Tomi Valkeinen wrote: > Hi Rob, Pawel, Mark, Ian, Kumar, Ping, Any hints on how to continue with this? > On 28/02/14 18:56, Russell King - ARM Linux wrote: >> On Fri, Feb 28, 2014 at 06:48:35PM +0200, Tomi Valkeinen wrote: >>> This is totally unclear to me. How does it become a public standard? >>> What's the forum for this? >> >> Me too. That's where I'd hope someone on devicetree-discuss will be >> able to help us work out what's the right approach here. :) > > The story briefly so far: I've implemented DT support for OMAP display, > and created bindings for various (non-OMAP) display components, > including generic connector bindings for DVI, HDMI and analog-tv. > > Russell's point was that these connector bindings are very generic, i.e. > they are not for any particular chip from a particular vendor, but for > any connector for DVI, HDMI or analog-tv. And he's worried that maybe we > shouldn't define such generic bindings without consulting the whole > device-tree community (i.e including non-linux users). > > So the question is, is there such a community and a forum to bring up > this kind of things? If yes, should we bring this up there? If yes, what > kind of things in general should be brought into the attention of > non-linux users? > > What I wonder here is that while a thing like DVI connector is, of > course, more generic than, say, "ti,tfp410" encoder chip, but isn't the > case still the same: we're defining global bindings for hardware that > should work for everyone, not only Linux users? > > Tomi > > -- next part -- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 901 bytes Desc: OpenPGP digital signature URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20140307/490977c1/attachment.pgp>
[RFC PATCH v2 19/21] ARM: dts: exynos5250-arndale: add dsi and panel nodes
On 07/03/14 15:07, Andrzej Hajda wrote:
> On 03/07/2014 01:32 PM, Tomi Valkeinen wrote:
>> On 07/03/14 14:22, Andrzej Hajda wrote:
>>
>>> I think we should even extend the bindings to fimd:
>>> dsi {
>>> port at 0 {
>>> dsi_0: endpoint {
>>> remote-endpoint=<&fimd_0>;
>>> }
>>> }
>>> port at 1 {
>>> dsi_1: endpoint {
>>> remote-endpoint=<&lvds_0>;
>>> }
>>> }
>>> }
>>>
>>> fimd {
>>> port at 0 {
>>> fimd_0: endpoint {
>>> remote-endpoint=<&dsi_0>;
>>> }
>>> }
>>> }
>> If both fimd and dsi are SoC components, I don't see any strict need for
>> that. I think the ports/endpoints are only important when dealing with
>> external components, which can be used on any platform. For SoC internal
>> components you can have relevant data directly in the drivers, as it is
>> fixed (for that SoC).
>>
>> Of course, if using ports for SoC internal components makes things
>> easier for you, I don't see any problems with it either.
> There are many possible connections from FIMD, some of them:
> FIMD ---> RGB panel, external
> FIMD ---> DSI, on SoC
> FIMD ---> eDP, on SoC
> FIMD ---> ImageEnhacer, on SoC
This sounds similar to OMAP, at least roughly.
> In the first case port should be created.
> In other cases connection could be determined by presence/absence
> of specific nodes, so in fact the port can be optional, almost like in
> my proposal :)
Well, I think not.
In the external encoder case, the ports are there, and they are used.
You just didn't specify them, and thus make the driver deduce them from
the DT.
In the FIMD case, if the the RGB port is needed, you need to specify it
in the DT data, and it's used. If you only need, say, DSI, the RGB port
is not used and thus it doesn't need to be present in the DT data.
It's fine to leave the port definition out if it is not used at all.
>> For OMAP, the SoC's display blocks are all inside one bigger DSS
>> "container", so I have not seen need to represent the connections
>> between the internal components in the DT data.
> How do you deal with situation when IPs in SoC can be connected in
> different ways ?
Basically so that (using exynos terms) if, say DSI panel is to be
enabled, the DSI panel driver will reserve the DSI master for itself,
and the DSI master will reserve the FIMD for itself, presuming FIMD has
not already been reserved. When the DSI panel is disabled, FIMD is freed.
Tomi
-- next part --
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 901 bytes
Desc: OpenPGP digital signature
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140307/2e4c70e6/attachment.pgp>
[PATCH 00/11] SimpleDRM & Sysfb
On 07/03/14 15:05, David Herrmann wrote: > If you can take these two patches, that's fine. They're not strictly > needed by the series and I'd be happy to see them upstream. The other > sysfb patches should be merged together, so I don't think there's much > gain in applying them through fbdev. Ok, I've applied them to fbdev tree. > The DRM tree is usually merged late, anyway, so I'll see whether we > will merge simpledrm through drm-next or not. If not, it'll be 3.16 > then. If you can get the fbdev merge in early, that should be enough > for us to figure it out and provide a conflict-resolution. Btw., do > you want the generic sysfb-helper in drivers/video/ or > driver/video/fbdev? It's not limited to fbdev, so I'd put it in > drivers/video/. With a quick glance, it doesn't seem to depend on fbdev in any way, right? That makes me think drivers/video/. Tomi -- next part -- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 901 bytes Desc: OpenPGP digital signature URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20140307/6207b43b/attachment.pgp>
[RFC PATCH v2 19/21] ARM: dts: exynos5250-arndale: add dsi and panel nodes
On 07/03/14 16:17, Andrzej Hajda wrote: > On 03/07/2014 02:28 PM, Tomi Valkeinen wrote: > (...) >> There are many possible connections from FIMD, some of them: >> FIMD ---> RGB panel, external >> FIMD ---> DSI, on SoC >> FIMD ---> eDP, on SoC >> FIMD ---> ImageEnhacer, on SoC >> This sounds similar to OMAP, at least roughly. >> >>> In the first case port should be created. >>> In other cases connection could be determined by presence/absence >>> of specific nodes, so in fact the port can be optional, almost like in >>> my proposal :) >> Well, I think not. >> >> In the external encoder case, the ports are there, and they are used. >> You just didn't specify them, and thus make the driver deduce them from >> the DT. >> >> In the FIMD case, if the the RGB port is needed, you need to specify it >> in the DT data, and it's used. If you only need, say, DSI, the RGB port >> is not used and thus it doesn't need to be present in the DT data. >> >> It's fine to leave the port definition out if it is not used at all. > On Exynos, DSI is in fact RGB/DSI encoder (or I80/DSI). DSI and RGB pins > are connected to the same FIMD output. So from FIMD point of view > RGB port is used in both cases. I guessed as much, as it's the same on OMAP. But I think it's still fine to have a port only for RGB panel. For the RGB panel, you have pins on the SoC to which the RGB data goes to. The RGB port in DT represents these pins. You don't have pins for the FIMD->DSI case. But as I said, it's fine to use ports for internal connections also if it works for you. I still don't like the idea of having the port as optional in DT for cases where the port comes from the parent device. Sure, it removes some lines from the DT, but I think it makes it more confusing. Especially as I think it's a very rare case where you could use that optional format, as usually you will have some properties in the endpoint node. Tomi -- next part -- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 901 bytes Desc: OpenPGP digital signature URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20140307/94af5287/attachment.pgp>
Request for feedback : [RFC] Added a new 'window size' property for connector
> I mean what's there in the mode structure. So if we define the border as > something that reduces hactive/vactice, we'd program the pfit output size as > hactive-left_border-right_border x vactive-top_border-bottom_border. > We can't change the already existing structure, so if we want to update it > we'd need drm_mode_modeinfo2 or something and a new set ioctls. My sense of > aestethics would prefer that, but from a practical point of view properties > seem > like the easier choice. As per the discussion so far, we will define a new drm property for both the border info and Src size, but just to get more clarity upfront please also suggest that 1.Should we define 2 new properties of type DRM_MODE_PROP_RANGE. The border info (Left, Top) & Src width/height can be provided by user in a packed form (16.16) ? 2.Should we define a new property of type DRM_MODE_PROP_BLOB. The User can pass the above info through a structure ? > Yeah. Before the atomic modeset API is introduced, userspace might want to > first disable the crtc, then change the properties, and then set a new mode. > That would make it appear atomic and it can avoid problems where the > intermediate state isn't exactly valid. Ok so till the advent of atomic modeset API, we could assume that onus will be on the user space to handle the intermediate state with due diligence. Best Regards Akash -Original Message- From: Ville Syrj?l? [mailto:ville.syrj...@linux.intel.com] Sent: Friday, March 07, 2014 7:41 PM To: Goel, Akash Cc: Chris Wilson; intel-gfx at lists.freedesktop.org; G, Pallavi; Purushothaman, Vijay A; Barstow, Jason; dri-devel at lists.freedesktop.org Subject: Re: Request for feedback : [RFC] Added a new 'window size' property for connector [ccing dri-devel so other people can see what we're cooking...] On Fri, Mar 07, 2014 at 01:49:18PM +, Goel, Akash wrote: > > In my ideal solution the panel fitter output will be > > hdisplay/vdisplay > > +/- the border (depending on which way we define it), and the panel > > +fitter > > input size will be defined as a new crtc property. > > Please could you kindly clarify, so as to avoid any ambiguity/confusion on > our side, that by 'hdisplay/vdisplay', are you referring to values programmed > in PIPESRC or 'HACTIVE/VACTIVE' (pipe timings) ? > As per our understanding that border info shall be applied on the > 'HACTIVE/VACTIVE', i.e. (HACTIVE - Left border - Right Border) x (VACTIVE > - Top Border - Bottom border) will be the output rectangle on screen. I mean what's there in the mode structure. So if we define the border as something that reduces hactive/vactice, we'd program the pfit output size as hactive-left_border-right_border x vactive-top_border-bottom_border. > > Please also confirm for the border info, you prefer a new property or an > update of the 'drm_mode_modeinfo' structure ? We can't change the already existing structure, so if we want to update it we'd need drm_mode_modeinfo2 or something and a new set ioctls. My sense of aestethics would prefer that, but from a practical point of view properties seem like the easier choice. > If the panel fitter input size is defined as a new crtc property, then once > User modifies the input size through this property, PIPESRC shall also be > updated with it at that time. But actually change in PIPESRC programming > alone, could also require a reprogramming of the Panel fitter in some cases. Yeah. Before the atomic modeset API is introduced, userspace might want to first disable the crtc, then change the properties, and then set a new mode. That would make it appear atomic and it can avoid problems where the intermediate state isn't exactly valid. > > Best Regards > Akash > > -Original Message- > From: Ville Syrj?l? [mailto:ville.syrjala at linux.intel.com] > Sent: Friday, March 07, 2014 6:31 PM > To: Goel, Akash > Cc: Chris Wilson; intel-gfx at lists.freedesktop.org; G, Pallavi; > Purushothaman, Vijay A > Subject: Re: Request for feedback : [RFC] Added a new 'window size' > property for connector > > On Fri, Mar 07, 2014 at 12:45:26PM +, Goel, Akash wrote: > > Thanks for your feedback. > > > > > No, fb_id is passed through setcrtc (or soon through setplane, I hope). > > Actually mentioned 'fb_id' also, because if PIPESRC programming is also > > being updated (as Panel fitter input), then the 'fb' already attached to > > 'crtc' may not be aligned with it. So there could be a momentary corruption > > caused when internal modeset is done by Driver (to change the Panel fitter > > setting), which will last till the next page flip (or setplane). > > > > > > No, we need both the border and the PIPESRC information. > > > hdisplay/vdisplays isn't enough since the user facing mode structure > > > doesn't have vblank_start/end fields. Hence we can't specify borders. > > > If we don't want to extend the display mode, we should add border > > > properties
[RFCv2 01/10] drm: Add support for multiple plane types
The DRM core currently only tracks "overlay"-style planes. Start
refactoring the plane handling to allow other plane types (primary and
cursor) to also be placed on the DRM plane list.
Signed-off-by: Matt Roper
---
drivers/gpu/drm/drm_crtc.c | 21 -
drivers/gpu/drm/drm_fb_helper.c | 3 ++-
include/drm/drm_crtc.h | 19 ++-
3 files changed, 36 insertions(+), 7 deletions(-)
diff --git a/drivers/gpu/drm/drm_crtc.c b/drivers/gpu/drm/drm_crtc.c
index 35ea15d..71c7fdc 100644
--- a/drivers/gpu/drm/drm_crtc.c
+++ b/drivers/gpu/drm/drm_crtc.c
@@ -964,6 +964,7 @@ int drm_plane_init(struct drm_device *dev, struct drm_plane
*plane,
memcpy(plane->format_types, formats, format_count * sizeof(uint32_t));
plane->format_count = format_count;
plane->possible_crtcs = possible_crtcs;
+ plane->type = DRM_PLANE_TYPE_OVERLAY;
/* private planes are not exposed to userspace, but depending on
* display hardware, might be convenient to allow sharing programming
@@ -971,7 +972,9 @@ int drm_plane_init(struct drm_device *dev, struct drm_plane
*plane,
*/
if (!priv) {
list_add_tail(&plane->head, &dev->mode_config.plane_list);
- dev->mode_config.num_plane++;
+ dev->mode_config.num_total_plane++;
+ if (plane->type == DRM_PLANE_TYPE_OVERLAY)
+ dev->mode_config.num_overlay_plane++;
} else {
INIT_LIST_HEAD(&plane->head);
}
@@ -1001,7 +1004,9 @@ void drm_plane_cleanup(struct drm_plane *plane)
/* if not added to a list, it must be a private plane */
if (!list_empty(&plane->head)) {
list_del(&plane->head);
- dev->mode_config.num_plane--;
+ dev->mode_config.num_total_plane--;
+ if (plane->type == DRM_PLANE_TYPE_OVERLAY)
+ dev->mode_config.num_overlay_plane--;
}
drm_modeset_unlock_all(dev);
}
@@ -1849,11 +1854,15 @@ int drm_mode_getplane_res(struct drm_device *dev, void
*data,
* This ioctl is called twice, once to determine how much space is
* needed, and the 2nd time to fill it.
*/
- if (config->num_plane &&
- (plane_resp->count_planes >= config->num_plane)) {
+ if (config->num_overlay_plane &&
+ (plane_resp->count_planes >= config->num_overlay_plane)) {
plane_ptr = (uint32_t __user *)(unsigned
long)plane_resp->plane_id_ptr;
list_for_each_entry(plane, &config->plane_list, head) {
+ /* Only advertise overlays to userspace for now. */
+ if (plane->type != DRM_PLANE_TYPE_OVERLAY)
+ continue;
+
if (put_user(plane->base.id, plane_ptr + copied)) {
ret = -EFAULT;
goto out;
@@ -1861,7 +1870,7 @@ int drm_mode_getplane_res(struct drm_device *dev, void
*data,
copied++;
}
}
- plane_resp->count_planes = config->num_plane;
+ plane_resp->count_planes = config->num_overlay_plane;
out:
drm_modeset_unlock_all(dev);
@@ -4060,6 +4069,8 @@ void drm_mode_config_init(struct drm_device *dev)
dev->mode_config.num_connector = 0;
dev->mode_config.num_crtc = 0;
dev->mode_config.num_encoder = 0;
+ dev->mode_config.num_overlay_plane = 0;
+ dev->mode_config.num_total_plane = 0;
}
EXPORT_SYMBOL(drm_mode_config_init);
diff --git a/drivers/gpu/drm/drm_fb_helper.c b/drivers/gpu/drm/drm_fb_helper.c
index d99df15..fee5759 100644
--- a/drivers/gpu/drm/drm_fb_helper.c
+++ b/drivers/gpu/drm/drm_fb_helper.c
@@ -291,7 +291,8 @@ bool drm_fb_helper_restore_fbdev_mode(struct drm_fb_helper
*fb_helper)
drm_warn_on_modeset_not_all_locked(dev);
list_for_each_entry(plane, &dev->mode_config.plane_list, head)
- drm_plane_force_disable(plane);
+ if (plane->type != DRM_PLANE_TYPE_PRIMARY)
+ drm_plane_force_disable(plane);
for (i = 0; i < fb_helper->crtc_count; i++) {
struct drm_mode_set *mode_set =
&fb_helper->crtc_info[i].mode_set;
diff --git a/include/drm/drm_crtc.h b/include/drm/drm_crtc.h
index f764654..80ea77f 100644
--- a/include/drm/drm_crtc.h
+++ b/include/drm/drm_crtc.h
@@ -665,6 +665,12 @@ struct drm_plane_funcs {
struct drm_property *property, uint64_t val);
};
+enum drm_plane_type {
+ DRM_PLANE_TYPE_OVERLAY,
+ DRM_PLANE_TYPE_PRIMARY,
+ DRM_PLANE_TYPE_CURSOR,
+};
+
/**
* drm_plane - central DRM plane control structure
* @dev: DRM device this plane belongs to
@@ -677,6 +683,7 @@ struct drm_plane_funcs {
* @fb: currently bound fb
* @funcs: helper functions
* @properties: property tracking for this plane
+ * @type: type of plane (overlay, pri
[RFCv2 04/10] drm/i915: Restrict plane loops to only operate on overlay planes
Before we add additional types of planes to the DRM plane list, ensure
that existing loops over all planes continue to operate only on
"overlay" planes and ignore primary & cursor planes.
Cc: Intel Graphics Development
Signed-off-by: Matt Roper
---
drivers/gpu/drm/i915/intel_display.c | 6 ++
drivers/gpu/drm/i915/intel_pm.c | 3 +++
2 files changed, 9 insertions(+)
diff --git a/drivers/gpu/drm/i915/intel_display.c
b/drivers/gpu/drm/i915/intel_display.c
index 6f15627..53f7c9c 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -3421,6 +3421,9 @@ static void intel_enable_planes(struct drm_crtc *crtc)
struct intel_plane *intel_plane;
list_for_each_entry(intel_plane, &dev->mode_config.plane_list,
base.head)
+ if (intel_plane->base.type != DRM_PLANE_TYPE_OVERLAY)
+ continue;
+
if (intel_plane->pipe == pipe)
intel_plane_restore(&intel_plane->base);
}
@@ -3432,6 +3435,9 @@ static void intel_disable_planes(struct drm_crtc *crtc)
struct intel_plane *intel_plane;
list_for_each_entry(intel_plane, &dev->mode_config.plane_list,
base.head)
+ if (intel_plane->base.type != DRM_PLANE_TYPE_OVERLAY)
+ continue;
+
if (intel_plane->pipe == pipe)
intel_plane_disable(&intel_plane->base);
}
diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i915/intel_pm.c
index c8347ae..4a534c4 100644
--- a/drivers/gpu/drm/i915/intel_pm.c
+++ b/drivers/gpu/drm/i915/intel_pm.c
@@ -2129,6 +2129,9 @@ static void ilk_compute_wm_parameters(struct drm_crtc
*crtc,
list_for_each_entry(plane, &dev->mode_config.plane_list, head) {
struct intel_plane *intel_plane = to_intel_plane(plane);
+ if (plane->type != DRM_PLANE_TYPE_OVERLAY)
+ continue;
+
if (intel_plane->pipe == pipe)
p->spr = intel_plane->wm;
--
1.8.5.1
[RFCv2 06/10] drm: Specify primary plane at CRTC initialization
Add primary plane as a parameter to drm_crtc_init() and update all
existing DRM drivers to use a helper-provided primary plane.
Signed-off-by: Matt Roper
---
drivers/gpu/drm/armada/armada_crtc.c | 4 +++-
drivers/gpu/drm/ast/ast_mode.c | 4 +++-
drivers/gpu/drm/bochs/bochs_kms.c | 4 +++-
drivers/gpu/drm/cirrus/cirrus_mode.c | 4 +++-
drivers/gpu/drm/drm_crtc.c | 8 +++-
drivers/gpu/drm/exynos/exynos_drm_crtc.c | 4 +++-
drivers/gpu/drm/gma500/psb_intel_display.c | 4 +++-
drivers/gpu/drm/i915/intel_display.c | 4 +++-
drivers/gpu/drm/mgag200/mgag200_mode.c | 4 +++-
drivers/gpu/drm/msm/mdp/mdp4/mdp4_crtc.c | 4 +++-
drivers/gpu/drm/msm/mdp/mdp5/mdp5_crtc.c | 4 +++-
drivers/gpu/drm/nouveau/dispnv04/crtc.c| 4 +++-
drivers/gpu/drm/nouveau/nv50_display.c | 4 +++-
drivers/gpu/drm/omapdrm/omap_crtc.c| 4 +++-
drivers/gpu/drm/qxl/qxl_display.c | 4 +++-
drivers/gpu/drm/radeon/radeon_display.c| 4 +++-
drivers/gpu/drm/rcar-du/rcar_du_crtc.c | 4 +++-
drivers/gpu/drm/shmobile/shmob_drm_crtc.c | 3 ++-
drivers/gpu/drm/tegra/dc.c | 4 +++-
drivers/gpu/drm/tilcdc/tilcdc_crtc.c | 4 +++-
drivers/gpu/drm/udl/udl_modeset.c | 4 +++-
drivers/gpu/drm/vmwgfx/vmwgfx_ldu.c| 4 +++-
drivers/gpu/drm/vmwgfx/vmwgfx_scrn.c | 4 +++-
drivers/staging/imx-drm/imx-drm-core.c | 4 +++-
include/drm/drm_crtc.h | 4
25 files changed, 79 insertions(+), 24 deletions(-)
diff --git a/drivers/gpu/drm/armada/armada_crtc.c
b/drivers/gpu/drm/armada/armada_crtc.c
index d8e3982..0a14d24 100644
--- a/drivers/gpu/drm/armada/armada_crtc.c
+++ b/drivers/gpu/drm/armada/armada_crtc.c
@@ -1030,6 +1030,7 @@ int armada_drm_crtc_create(struct drm_device *dev,
unsigned num,
{
struct armada_private *priv = dev->dev_private;
struct armada_crtc *dcrtc;
+ struct drm_plane *primary;
void __iomem *base;
int ret;
@@ -1086,7 +1087,8 @@ int armada_drm_crtc_create(struct drm_device *dev,
unsigned num,
priv->dcrtc[dcrtc->num] = dcrtc;
- drm_crtc_init(dev, &dcrtc->crtc, &armada_crtc_funcs);
+ primary = drm_primary_helper_create_plane(dev);
+ drm_crtc_init(dev, &dcrtc->crtc, primary, &armada_crtc_funcs);
drm_crtc_helper_add(&dcrtc->crtc, &armada_crtc_helper_funcs);
drm_object_attach_property(&dcrtc->crtc.base, priv->csc_yuv_prop,
diff --git a/drivers/gpu/drm/ast/ast_mode.c b/drivers/gpu/drm/ast/ast_mode.c
index cca063b..44f0d32 100644
--- a/drivers/gpu/drm/ast/ast_mode.c
+++ b/drivers/gpu/drm/ast/ast_mode.c
@@ -626,13 +626,15 @@ static const struct drm_crtc_funcs ast_crtc_funcs = {
static int ast_crtc_init(struct drm_device *dev)
{
struct ast_crtc *crtc;
+ struct drm_plane *primary;
int i;
crtc = kzalloc(sizeof(struct ast_crtc), GFP_KERNEL);
if (!crtc)
return -ENOMEM;
- drm_crtc_init(dev, &crtc->base, &ast_crtc_funcs);
+ primary = drm_primary_helper_create_plane(dev);
+ drm_crtc_init(dev, &crtc->base, primary, &ast_crtc_funcs);
drm_mode_crtc_set_gamma_size(&crtc->base, 256);
drm_crtc_helper_add(&crtc->base, &ast_crtc_helper_funcs);
diff --git a/drivers/gpu/drm/bochs/bochs_kms.c
b/drivers/gpu/drm/bochs/bochs_kms.c
index 62ec7d4..182f5c9 100644
--- a/drivers/gpu/drm/bochs/bochs_kms.c
+++ b/drivers/gpu/drm/bochs/bochs_kms.c
@@ -129,8 +129,10 @@ static void bochs_crtc_init(struct drm_device *dev)
{
struct bochs_device *bochs = dev->dev_private;
struct drm_crtc *crtc = &bochs->crtc;
+ struct drm_plane *primary;
- drm_crtc_init(dev, crtc, &bochs_crtc_funcs);
+ primary = drm_primary_helper_create_plane(dev);
+ drm_crtc_init(dev, crtc, primary, &bochs_crtc_funcs);
drm_mode_crtc_set_gamma_size(crtc, 256);
drm_crtc_helper_add(crtc, &bochs_helper_funcs);
}
diff --git a/drivers/gpu/drm/cirrus/cirrus_mode.c
b/drivers/gpu/drm/cirrus/cirrus_mode.c
index 530f78f..449246f 100644
--- a/drivers/gpu/drm/cirrus/cirrus_mode.c
+++ b/drivers/gpu/drm/cirrus/cirrus_mode.c
@@ -381,6 +381,7 @@ static void cirrus_crtc_init(struct drm_device *dev)
{
struct cirrus_device *cdev = dev->dev_private;
struct cirrus_crtc *cirrus_crtc;
+ struct drm_plane *primary;
int i;
cirrus_crtc = kzalloc(sizeof(struct cirrus_crtc) +
@@ -390,7 +391,8 @@ static void cirrus_crtc_init(struct drm_device *dev)
if (cirrus_crtc == NULL)
return;
- drm_crtc_init(dev, &cirrus_crtc->base, &cirrus_crtc_funcs);
+ primary = drm_primary_helper_create_plane(dev);
+ drm_crtc_init(dev, &cirrus_crtc->base, primary, &cirrus_crtc_funcs);
drm_mode_crtc_set_gamma_size(&cirrus_crtc->base, CIRRUS_LUT_SIZE);
cdev->mode_info.crtc = cirrus_crtc;
diff --git a/drivers/gpu/drm/drm_crtc.c b/drivers/gpu/drm/drm_crtc.c
index 5b9b512..35e7
[RFCv2 10/10] drm/i915: Intel-specific primary plane handling
Intel hardware allows the primary plane to be disabled independently of
the CRTC. Provide custom primary plane handling to allow this.
Cc: Intel Graphics Development
Signed-off-by: Matt Roper
---
drivers/gpu/drm/i915/intel_display.c | 132 ++-
drivers/gpu/drm/i915/intel_drv.h | 1 +
2 files changed, 130 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_display.c
b/drivers/gpu/drm/i915/intel_display.c
index 7c09d41..2b9807a 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -39,6 +39,7 @@
#include "i915_trace.h"
#include
#include
+#include
#include
static void intel_increase_pllclock(struct drm_crtc *crtc);
@@ -10280,19 +10281,144 @@ static void intel_shared_dpll_init(struct drm_device
*dev)
BUG_ON(dev_priv->num_shared_dpll > I915_NUM_PLLS);
}
+static int
+intel_primary_plane_setplane(struct drm_plane *plane, struct drm_crtc *crtc,
+struct drm_framebuffer *fb, int crtc_x, int crtc_y,
+unsigned int crtc_w, unsigned int crtc_h,
+uint32_t src_x, uint32_t src_y,
+uint32_t src_w, uint32_t src_h)
+{
+ struct drm_device *dev = crtc->dev;
+ struct drm_i915_private *dev_priv = dev->dev_private;
+ struct intel_crtc *intel_crtc = to_intel_crtc(crtc);
+ struct drm_framebuffer *tmpfb;
+ struct drm_rect dest = {
+ .x1 = crtc_x,
+ .y1 = crtc_y,
+ .x2 = crtc_x + crtc_w,
+ .y2 = crtc_y + crtc_h,
+ };
+ struct drm_rect clip = {
+ .x2 = crtc->mode.hdisplay,
+ .y2 = crtc->mode.vdisplay,
+ };
+ int ret;
+
+ /* setplane API takes shifted source rectangle values; unshift them */
+ src_x >>= 16;
+ src_y >>= 16;
+ src_w >>= 16;
+ src_h >>= 16;
+
+ /*
+* Current hardware can't reposition the primary plane or scale it
+* (although this could change in the future).
+*/
+ drm_rect_intersect(&dest, &clip);
+ if (dest.x1 != 0 || dest.y1 != 0 ||
+ dest.x2 != crtc->mode.hdisplay || dest.y2 != crtc->mode.vdisplay) {
+ DRM_DEBUG_KMS("Primary plane must cover entire CRTC\n");
+ return -EINVAL;
+ }
+
+ if (crtc_w != src_w || crtc_h != src_h) {
+ DRM_DEBUG_KMS("Can't scale primary plane\n");
+ return -EINVAL;
+ }
+
+ /*
+* pipe_set_base() adjusts crtc->primary->fb; however the DRM setplane
+* code that called us expects to handle the framebuffer update and
+* reference counting; save and restore the current fb before
+* calling it.
+*/
+ tmpfb = plane->fb;
+ ret = intel_pipe_set_base(crtc, src_x, src_y, fb);
+ if (ret)
+ return ret;
+ plane->fb = tmpfb;
+
+ if (!intel_crtc->primary_enabled)
+ intel_enable_primary_hw_plane(dev_priv, intel_crtc->plane,
+ intel_crtc->pipe);
+
+ return 0;
+}
+
+static int
+intel_primary_plane_disable(struct drm_plane *plane)
+{
+ struct drm_device *dev = plane->dev;
+ drm_i915_private_t *dev_priv = dev->dev_private;
+ struct intel_plane *intel_plane = to_intel_plane(plane);
+ struct intel_crtc *intel_crtc;
+
+ if (!plane->fb)
+ return 0;
+
+ if (WARN_ON(!plane->crtc))
+ return -EINVAL;
+
+ intel_crtc = to_intel_crtc(plane->crtc);
+ if (intel_crtc->primary_enabled)
+ intel_disable_primary_hw_plane(dev_priv, intel_plane->plane,
+ intel_plane->pipe);
+
+ return 0;
+}
+
+static void intel_primary_plane_destroy(struct drm_plane *plane)
+{
+ struct intel_plane *intel_plane = to_intel_plane(plane);
+ intel_primary_plane_disable(plane);
+ drm_plane_cleanup(plane);
+ kfree(intel_plane);
+}
+
+static const struct drm_plane_funcs intel_primary_plane_funcs = {
+ .update_plane = intel_primary_plane_setplane,
+ .disable_plane = intel_primary_plane_disable,
+ .destroy = intel_primary_plane_destroy,
+};
+
+static struct drm_plane *intel_primary_plane_create(struct drm_device *dev,
+ int pipe)
+{
+ struct intel_plane *primary;
+
+ primary = kzalloc(sizeof(*primary), GFP_KERNEL);
+ if (primary == NULL)
+ return NULL;
+
+ primary->can_scale = false;
+ primary->pipe = pipe;
+ primary->plane = pipe;
+
+ drm_plane_init(dev, &primary->base, 0,
+ &intel_primary_plane_funcs, legacy_modeset_formats,
+ ARRAY_SIZE(legacy_modeset_formats),
+ DRM_PLANE_TYPE_PRIMARY);
+ return &primary->base;
+}
+
static void intel_
[RFCv2 08/10] drm: Allow userspace to ask for full plane list (universal planes)
Userspace clients which wish to receive all DRM planes (primary and
cursor planes in addition to the traditional overlay planes) may set the
DRM_CLIENT_CAP_UNIVERSAL_PLANES capability.
Signed-off-by: Matt Roper
---
drivers/gpu/drm/drm_crtc.c | 20 +++-
drivers/gpu/drm/drm_ioctl.c | 5 +
include/drm/drmP.h | 5 +
include/uapi/drm/drm.h | 8
4 files changed, 33 insertions(+), 5 deletions(-)
diff --git a/drivers/gpu/drm/drm_crtc.c b/drivers/gpu/drm/drm_crtc.c
index cdfa61a..5504c4d 100644
--- a/drivers/gpu/drm/drm_crtc.c
+++ b/drivers/gpu/drm/drm_crtc.c
@@ -2106,6 +2106,7 @@ int drm_mode_getplane_res(struct drm_device *dev, void
*data,
struct drm_plane *plane;
uint32_t __user *plane_ptr;
int copied = 0, ret = 0;
+ unsigned num_planes;
if (!drm_core_check_feature(dev, DRIVER_MODESET))
return -EINVAL;
@@ -2113,17 +2114,26 @@ int drm_mode_getplane_res(struct drm_device *dev, void
*data,
drm_modeset_lock_all(dev);
config = &dev->mode_config;
+ if (file_priv->universal_planes)
+ num_planes = config->num_total_plane;
+ else
+ num_planes = config->num_overlay_plane;
+
/*
* This ioctl is called twice, once to determine how much space is
* needed, and the 2nd time to fill it.
*/
- if (config->num_overlay_plane &&
- (plane_resp->count_planes >= config->num_overlay_plane)) {
+ if (num_planes &&
+ (plane_resp->count_planes >= num_planes)) {
plane_ptr = (uint32_t __user *)(unsigned
long)plane_resp->plane_id_ptr;
list_for_each_entry(plane, &config->plane_list, head) {
- /* Only advertise overlays to userspace for now. */
- if (plane->type != DRM_PLANE_TYPE_OVERLAY)
+ /*
+* Unless userspace set the 'universal planes'
+* capability bit, only advertise overlays.
+*/
+ if (plane->type != DRM_PLANE_TYPE_OVERLAY &&
+ !file_priv->universal_planes)
continue;
if (put_user(plane->base.id, plane_ptr + copied)) {
@@ -2133,7 +2143,7 @@ int drm_mode_getplane_res(struct drm_device *dev, void
*data,
copied++;
}
}
- plane_resp->count_planes = config->num_overlay_plane;
+ plane_resp->count_planes = num_planes;
out:
drm_modeset_unlock_all(dev);
diff --git a/drivers/gpu/drm/drm_ioctl.c b/drivers/gpu/drm/drm_ioctl.c
index f4dc9b7..5eb92b6 100644
--- a/drivers/gpu/drm/drm_ioctl.c
+++ b/drivers/gpu/drm/drm_ioctl.c
@@ -328,6 +328,11 @@ drm_setclientcap(struct drm_device *dev, void *data,
struct drm_file *file_priv)
return -EINVAL;
file_priv->stereo_allowed = req->value;
break;
+ case DRM_CLIENT_CAP_UNIVERSAL_PLANES:
+ if (req->value > 1)
+ return -EINVAL;
+ file_priv->universal_planes = req->value;
+ break;
default:
return -EINVAL;
}
diff --git a/include/drm/drmP.h b/include/drm/drmP.h
index 04a7f31..f103d69 100644
--- a/include/drm/drmP.h
+++ b/include/drm/drmP.h
@@ -437,6 +437,11 @@ struct drm_file {
unsigned is_master :1; /* this file private is a master for a minor */
/* true when the client has asked us to expose stereo 3D mode flags */
unsigned stereo_allowed :1;
+ /*
+* true if client understands CRTC primary planes and cursor planes
+* in the plane list
+*/
+ unsigned universal_planes:1;
struct pid *pid;
kuid_t uid;
diff --git a/include/uapi/drm/drm.h b/include/uapi/drm/drm.h
index b06c8ed..6e4952b 100644
--- a/include/uapi/drm/drm.h
+++ b/include/uapi/drm/drm.h
@@ -637,6 +637,14 @@ struct drm_get_cap {
*/
#define DRM_CLIENT_CAP_STEREO_3D 1
+/**
+ * DRM_CLIENT_CAP_UNIVERSAL_PLANES
+ *
+ * If set to 1, the DRM core will expose all planes (overlay, primary, and
+ * cursor) to userspace.
+ */
+#define DRM_CLIENT_CAP_UNIVERSAL_PLANES 2
+
/** DRM_IOCTL_SET_CLIENT_CAP ioctl argument type */
struct drm_set_client_cap {
__u64 capability;
--
1.8.5.1
[RFCv2 03/10] drm/exynos: Restrict plane loops to only operate on overlay planes
Before we add additional types of planes to the DRM plane list, ensure
that existing loops over all planes continue to operate only on
"overlay" planes and ignore primary & cursor planes.
Cc: Inki Dae
Signed-off-by: Matt Roper
---
drivers/gpu/drm/exynos/exynos_drm_encoder.c | 6 ++
1 file changed, 6 insertions(+)
diff --git a/drivers/gpu/drm/exynos/exynos_drm_encoder.c
b/drivers/gpu/drm/exynos/exynos_drm_encoder.c
index 06f1b2a..2fa2685 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_encoder.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_encoder.c
@@ -127,6 +127,9 @@ static void disable_plane_to_crtc(struct drm_device *dev,
* (encoder->crtc)
*/
list_for_each_entry(plane, &dev->mode_config.plane_list, head) {
+ if (plane->type != DRM_PLANE_TYPE_OVERLAY)
+ continue;
+
if (plane->crtc == old_crtc) {
/*
* do not change below call order.
@@ -247,6 +250,9 @@ static void exynos_drm_encoder_disable(struct drm_encoder
*encoder)
/* all planes connected to this encoder should be also disabled. */
list_for_each_entry(plane, &dev->mode_config.plane_list, head) {
+ if (plane->type != DRM_PLANE_TYPE_OVERLAY)
+ continue;
+
if (plane->crtc == encoder->crtc)
plane->funcs->disable_plane(plane);
}
--
1.8.5.1
[RFCv2 05/10] drm: Add plane type property
Add a plane type property to allow userspace to distinguish plane types.
The type of the plane will now be established at drm_plane_init() time
(replacing the 'priv' parameter previously used).
Signed-off-by: Matt Roper
---
drivers/gpu/drm/armada/armada_overlay.c| 3 +-
drivers/gpu/drm/drm_crtc.c | 65 --
drivers/gpu/drm/exynos/exynos_drm_plane.c | 4 +-
drivers/gpu/drm/i915/intel_sprite.c| 2 +-
drivers/gpu/drm/msm/mdp/mdp4/mdp4_plane.c | 4 +-
drivers/gpu/drm/msm/mdp/mdp5/mdp5_plane.c | 3 +-
drivers/gpu/drm/nouveau/dispnv04/overlay.c | 4 +-
drivers/gpu/drm/omapdrm/omap_plane.c | 4 +-
drivers/gpu/drm/rcar-du/rcar_du_plane.c| 3 +-
drivers/gpu/drm/shmobile/shmob_drm_plane.c | 2 +-
drivers/gpu/drm/tegra/dc.c | 3 +-
drivers/staging/imx-drm/ipuv3-plane.c | 4 +-
include/drm/drm_crtc.h | 3 +-
13 files changed, 69 insertions(+), 35 deletions(-)
diff --git a/drivers/gpu/drm/armada/armada_overlay.c
b/drivers/gpu/drm/armada/armada_overlay.c
index c5b06fd..ef68c42 100644
--- a/drivers/gpu/drm/armada/armada_overlay.c
+++ b/drivers/gpu/drm/armada/armada_overlay.c
@@ -444,7 +444,8 @@ int armada_overlay_plane_create(struct drm_device *dev,
unsigned long crtcs)
dplane);
drm_plane_init(dev, &dplane->base, crtcs, &armada_plane_funcs,
- armada_formats, ARRAY_SIZE(armada_formats), false);
+ armada_formats, ARRAY_SIZE(armada_formats),
+ DRM_PLANE_TYPE_OVERLAY);
dplane->prop.colorkey_yr = 0xfefefe00;
dplane->prop.colorkey_ug = 0x01010100;
diff --git a/drivers/gpu/drm/drm_crtc.c b/drivers/gpu/drm/drm_crtc.c
index 93fc2dd..5b9b512 100644
--- a/drivers/gpu/drm/drm_crtc.c
+++ b/drivers/gpu/drm/drm_crtc.c
@@ -114,6 +114,15 @@ static const struct drm_prop_enum_list
drm_dpms_enum_list[] =
DRM_ENUM_NAME_FN(drm_get_dpms_name, drm_dpms_enum_list)
+static const struct drm_prop_enum_list drm_plane_type_enum_list[] =
+{
+ { DRM_PLANE_TYPE_OVERLAY, "Overlay" },
+ { DRM_PLANE_TYPE_PRIMARY, "Primary" },
+ { DRM_PLANE_TYPE_CURSOR, "Cursor" },
+};
+
+DRM_ENUM_NAME_FN(drm_get_plane_type, drm_plane_type_enum_list)
+
/*
* Optional properties
*/
@@ -928,7 +937,7 @@ EXPORT_SYMBOL(drm_encoder_cleanup);
* @funcs: callbacks for the new plane
* @formats: array of supported formats (%DRM_FORMAT_*)
* @format_count: number of elements in @formats
- * @priv: plane is private (hidden from userspace)?
+ * @type: type of plane (overlay, primary, cursor)
*
* Inits a new object created as base part of a driver plane object.
*
@@ -939,7 +948,7 @@ int drm_plane_init(struct drm_device *dev, struct drm_plane
*plane,
unsigned long possible_crtcs,
const struct drm_plane_funcs *funcs,
const uint32_t *formats, uint32_t format_count,
- bool priv)
+ enum drm_plane_type type)
{
int ret;
@@ -964,20 +973,16 @@ int drm_plane_init(struct drm_device *dev, struct
drm_plane *plane,
memcpy(plane->format_types, formats, format_count * sizeof(uint32_t));
plane->format_count = format_count;
plane->possible_crtcs = possible_crtcs;
- plane->type = DRM_PLANE_TYPE_OVERLAY;
+ plane->type = type;
- /* private planes are not exposed to userspace, but depending on
-* display hardware, might be convenient to allow sharing programming
-* for the scanout engine with the crtc implementation.
-*/
- if (!priv) {
- list_add_tail(&plane->head, &dev->mode_config.plane_list);
- dev->mode_config.num_total_plane++;
- if (plane->type == DRM_PLANE_TYPE_OVERLAY)
- dev->mode_config.num_overlay_plane++;
- } else {
- INIT_LIST_HEAD(&plane->head);
- }
+ list_add_tail(&plane->head, &dev->mode_config.plane_list);
+ dev->mode_config.num_total_plane++;
+ if (plane->type == DRM_PLANE_TYPE_OVERLAY)
+ dev->mode_config.num_overlay_plane++;
+
+ drm_object_attach_property(&plane->base,
+ dev->mode_config.plane_type_property,
+ plane->type);
out:
drm_modeset_unlock_all(dev);
@@ -1001,13 +1006,13 @@ void drm_plane_cleanup(struct drm_plane *plane)
drm_modeset_lock_all(dev);
kfree(plane->format_types);
drm_mode_object_put(dev, &plane->base);
- /* if not added to a list, it must be a private plane */
- if (!list_empty(&plane->head)) {
- list_del(&plane->head);
- dev->mode_config.num_total_plane--;
- if (plane->type == DRM_PLANE_TYPE_OVERLAY)
- dev->mode_config.num_overlay_plane--;
- }
+
+ BUG_ON(list_empty(&plane->head));
+
+ list_del(&plane->h
[RFCv2 09/10] drm/i915: Rename similar plane functions to avoid confusion
The name 'update_plane' was used both for the primary plane functions in
intel_display.c and the sprite/overlay functions in intel_sprite.c.
Rename the primary plane functions to 'update_primary_plane' to avoid
confusion.
On a similar note, intel_display.c already had a function called
intel_disable_primary_plane() that programs the hardware to disable a
pipe's primary plane. When we hook up primary planes through the DRM
plane interface, one of the natural handler names will be
intel_primary_plane_disable(), which is very similar. To avoid
confusion, rename the existing intel_disable_primary_plane() to
intel_disable_primary_hw_plane() to make the two names a little more
distinct.
Cc: Intel Graphics Development
Signed-off-by: Matt Roper
---
drivers/gpu/drm/i915/i915_drv.h | 5 +--
drivers/gpu/drm/i915/intel_display.c | 60
2 files changed, 36 insertions(+), 29 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 05cfcc1..0e043d4 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -450,8 +450,9 @@ struct drm_i915_display_funcs {
struct drm_framebuffer *fb,
struct drm_i915_gem_object *obj,
uint32_t flags);
- int (*update_plane)(struct drm_crtc *crtc, struct drm_framebuffer *fb,
- int x, int y);
+ int (*update_primary_plane)(struct drm_crtc *crtc,
+ struct drm_framebuffer *fb,
+ int x, int y);
void (*hpd_irq_setup)(struct drm_device *dev);
/* clock updates for mode set */
/* cursor updates */
diff --git a/drivers/gpu/drm/i915/intel_display.c
b/drivers/gpu/drm/i915/intel_display.c
index 42cf4b4..7c09d41 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -1872,15 +1872,15 @@ void intel_flush_primary_plane(struct drm_i915_private
*dev_priv,
}
/**
- * intel_enable_primary_plane - enable the primary plane on a given pipe
+ * intel_enable_primary_hw_plane - enable the primary plane on a given pipe
* @dev_priv: i915 private structure
* @plane: plane to enable
* @pipe: pipe being fed
*
* Enable @plane on @pipe, making sure that @pipe is running first.
*/
-static void intel_enable_primary_plane(struct drm_i915_private *dev_priv,
- enum plane plane, enum pipe pipe)
+static void intel_enable_primary_hw_plane(struct drm_i915_private *dev_priv,
+ enum plane plane, enum pipe pipe)
{
struct intel_crtc *intel_crtc =
to_intel_crtc(dev_priv->pipe_to_crtc_mapping[pipe]);
@@ -1905,15 +1905,15 @@ static void intel_enable_primary_plane(struct
drm_i915_private *dev_priv,
}
/**
- * intel_disable_primary_plane - disable the primary plane
+ * intel_disable_primary_hw_plane - disable the primary hardware plane
* @dev_priv: i915 private structure
* @plane: plane to disable
* @pipe: pipe consuming the data
*
* Disable @plane; should be an independent operation.
*/
-static void intel_disable_primary_plane(struct drm_i915_private *dev_priv,
- enum plane plane, enum pipe pipe)
+static void intel_disable_primary_hw_plane(struct drm_i915_private *dev_priv,
+ enum plane plane, enum pipe pipe)
{
struct intel_crtc *intel_crtc =
to_intel_crtc(dev_priv->pipe_to_crtc_mapping[pipe]);
@@ -2047,8 +2047,9 @@ unsigned long intel_gen4_compute_page_offset(int *x, int
*y,
}
}
-static int i9xx_update_plane(struct drm_crtc *crtc, struct drm_framebuffer *fb,
-int x, int y)
+static int i9xx_update_primary_plane(struct drm_crtc *crtc,
+struct drm_framebuffer *fb,
+int x, int y)
{
struct drm_device *dev = crtc->dev;
struct drm_i915_private *dev_priv = dev->dev_private;
@@ -2147,8 +2148,9 @@ static int i9xx_update_plane(struct drm_crtc *crtc,
struct drm_framebuffer *fb,
return 0;
}
-static int ironlake_update_plane(struct drm_crtc *crtc,
-struct drm_framebuffer *fb, int x, int y)
+static int ironlake_update_primary_plane(struct drm_crtc *crtc,
+struct drm_framebuffer *fb,
+int x, int y)
{
struct drm_device *dev = crtc->dev;
struct drm_i915_private *dev_priv = dev->dev_private;
@@ -2252,7 +2254,7 @@ intel_pipe_set_base_atomic(struct drm_crtc *crtc, struct
drm_framebuffer *fb,
dev_priv->display.disable_fbc(dev);
intel_increase_pllclock(crtc);
- return dev_priv->display.update_plane(crtc, fb, x, y);
+ return dev_priv->display.update_primary_plane(crtc, fb,
[RFCv2 07/10] drm: Replace crtc fb with primary plane fb
Now that CRTC's have a primary plane, there's no need to track the
framebuffer in the CRTC. Replace all references to the CRTC fb
with the primary plane's fb.
Also note that this simplifies framebuffer removal slightly; we no
longer need to scan all CRTC's and disable the ones that were using the
framebuffer since the existing loop over all planes will take care
of disabling the primary plane (and on most hardware, the CRTC by
extension).
Signed-off-by: Matt Roper
---
drivers/gpu/drm/drm_crtc.c | 56 -
drivers/gpu/drm/drm_crtc_helper.c | 21 +--
drivers/gpu/drm/drm_fb_helper.c | 6 ++--
drivers/gpu/drm/i915/i915_debugfs.c | 4 +--
drivers/gpu/drm/i915/i915_irq.c | 4 +--
drivers/gpu/drm/i915/intel_display.c| 56 +++--
drivers/gpu/drm/i915/intel_dp.c | 5 +--
drivers/gpu/drm/i915/intel_overlay.c| 4 +--
drivers/gpu/drm/i915/intel_pm.c | 36 +--
drivers/gpu/drm/nouveau/dispnv04/crtc.c | 20 +--
drivers/gpu/drm/nouveau/dispnv04/dfp.c | 2 +-
drivers/gpu/drm/nouveau/nouveau_display.c | 8 ++---
drivers/gpu/drm/nouveau/nv50_display.c | 17 -
drivers/gpu/drm/radeon/atombios_crtc.c | 20 +--
drivers/gpu/drm/radeon/r100.c | 4 +--
drivers/gpu/drm/radeon/radeon_connectors.c | 2 +-
drivers/gpu/drm/radeon/radeon_device.c | 3 +-
drivers/gpu/drm/radeon/radeon_display.c | 4 +--
drivers/gpu/drm/radeon/radeon_legacy_crtc.c | 16 -
include/drm/drm_crtc.h | 3 --
20 files changed, 141 insertions(+), 150 deletions(-)
diff --git a/drivers/gpu/drm/drm_crtc.c b/drivers/gpu/drm/drm_crtc.c
index 35e78a4..cdfa61a 100644
--- a/drivers/gpu/drm/drm_crtc.c
+++ b/drivers/gpu/drm/drm_crtc.c
@@ -586,7 +586,7 @@ EXPORT_SYMBOL(drm_framebuffer_cleanup);
* drm_framebuffer_remove - remove and unreference a framebuffer object
* @fb: framebuffer to remove
*
- * Scans all the CRTCs and planes in @dev's mode_config. If they're
+ * Scans all the planes in @dev's mode_config. If they're
* using @fb, removes it, setting it to NULL. Then drops the reference to the
* passed-in framebuffer. Might take the modeset locks.
*
@@ -597,10 +597,7 @@ EXPORT_SYMBOL(drm_framebuffer_cleanup);
void drm_framebuffer_remove(struct drm_framebuffer *fb)
{
struct drm_device *dev = fb->dev;
- struct drm_crtc *crtc;
struct drm_plane *plane;
- struct drm_mode_set set;
- int ret;
WARN_ON(!list_empty(&fb->filp_head));
@@ -621,19 +618,7 @@ void drm_framebuffer_remove(struct drm_framebuffer *fb)
*/
if (atomic_read(&fb->refcount.refcount) > 1) {
drm_modeset_lock_all(dev);
- /* remove from any CRTC */
- list_for_each_entry(crtc, &dev->mode_config.crtc_list, head) {
- if (crtc->fb == fb) {
- /* should turn off the crtc */
- memset(&set, 0, sizeof(struct drm_mode_set));
- set.crtc = crtc;
- set.fb = NULL;
- ret = drm_mode_set_config_internal(&set);
- if (ret)
- DRM_ERROR("failed to reset crtc %p when
fb was deleted\n", crtc);
- }
- }
-
+ /* remove from any plane */
list_for_each_entry(plane, &dev->mode_config.plane_list, head) {
if (plane->fb == fb)
drm_plane_force_disable(plane);
@@ -1894,8 +1879,8 @@ int drm_mode_getcrtc(struct drm_device *dev,
crtc_resp->x = crtc->x;
crtc_resp->y = crtc->y;
crtc_resp->gamma_size = crtc->gamma_size;
- if (crtc->fb)
- crtc_resp->fb_id = crtc->fb->base.id;
+ if (crtc->primary->fb)
+ crtc_resp->fb_id = crtc->primary->fb->base.id;
else
crtc_resp->fb_id = 0;
@@ -2374,7 +2359,7 @@ int drm_mode_set_config_internal(struct drm_mode_set *set)
* crtcs. Atomic modeset will have saner semantics ...
*/
list_for_each_entry(tmp, &crtc->dev->mode_config.crtc_list, head)
- tmp->old_fb = tmp->fb;
+ tmp->old_fb = tmp->primary->fb;
fb = set->fb;
@@ -2382,13 +2367,16 @@ int drm_mode_set_config_internal(struct drm_mode_set
*set)
if (ret == 0) {
crtc->primary->crtc = crtc;
- /* crtc->fb must be updated by ->set_config, enforces this. */
- WARN_ON(fb != crtc->fb);
+ /*
+* crtc->primary->fb must be updated by ->set_config,
+* enforces this.
+*/
+ WARN_ON(fb != crtc->primary->fb);
}
list_for_each_entry(tmp, &crtc->
[RFCv2 02/10] drm: Add primary plane helpers
When we expose non-overlay planes to userspace, they will become
accessible via standard userspace plane API's. We should be able to
handle the standard plane operations against primary planes in a generic
way via the page flip handler and modeset handler.
Drivers that can program primary planes more efficiently, that want to
use their own primary plane structure to track additional information,
or that don't have the limitations assumed by the helpers are free to
provide their own implementation of some or all of these handlers.
Signed-off-by: Matt Roper
---
drivers/gpu/drm/drm_crtc.c | 293 +++--
include/drm/drm_crtc.h | 81 +
2 files changed, 335 insertions(+), 39 deletions(-)
diff --git a/drivers/gpu/drm/drm_crtc.c b/drivers/gpu/drm/drm_crtc.c
index 71c7fdc..93fc2dd 100644
--- a/drivers/gpu/drm/drm_crtc.c
+++ b/drivers/gpu/drm/drm_crtc.c
@@ -1038,6 +1038,260 @@ void drm_plane_force_disable(struct drm_plane *plane)
}
EXPORT_SYMBOL(drm_plane_force_disable);
+/*
+ * Checks that the framebuffer is big enough for the CRTC viewport
+ * (x, y, hdisplay, vdisplay)
+ */
+static int drm_crtc_check_viewport(const struct drm_crtc *crtc,
+ int x, int y,
+ const struct drm_display_mode *mode,
+ const struct drm_framebuffer *fb)
+
+{
+ int hdisplay, vdisplay;
+
+ hdisplay = mode->hdisplay;
+ vdisplay = mode->vdisplay;
+
+ if (drm_mode_is_stereo(mode)) {
+ struct drm_display_mode adjusted = *mode;
+
+ drm_mode_set_crtcinfo(&adjusted, CRTC_STEREO_DOUBLE);
+ hdisplay = adjusted.crtc_hdisplay;
+ vdisplay = adjusted.crtc_vdisplay;
+ }
+
+ if (crtc->invert_dimensions)
+ swap(hdisplay, vdisplay);
+
+ if (hdisplay > fb->width ||
+ vdisplay > fb->height ||
+ x > fb->width - hdisplay ||
+ y > fb->height - vdisplay) {
+ DRM_DEBUG_KMS("Invalid fb size %ux%u for CRTC viewport
%ux%u+%d+%d%s.\n",
+ fb->width, fb->height, hdisplay, vdisplay, x, y,
+ crtc->invert_dimensions ? " (inverted)" : "");
+ return -ENOSPC;
+ }
+
+ return 0;
+}
+
+/*
+ * Returns the connectors currently associated with a CRTC. This function
+ * should be called twice: once with a NULL connector list to retrieve
+ * the list size, and once with the properly allocated list to be filled in.
+ */
+static int get_connectors_for_crtc(struct drm_crtc *crtc,
+ struct drm_connector **connector_list,
+ int num_connectors)
+{
+ struct drm_device *dev = crtc->dev;
+ struct drm_connector *connector;
+ int count = 0;
+
+ list_for_each_entry(connector, &dev->mode_config.connector_list, head)
+ if (connector->encoder && connector->encoder->crtc == crtc) {
+ if (connector_list != NULL && count < num_connectors)
+ *(connector_list++) = connector;
+
+ count++;
+ }
+
+ return count;
+}
+
+/**
+ * drm_primary_helper_update() - Helper for primary plane update
+ * @plane: plane object to update
+ * @crtc: owning CRTC of owning plane
+ * @fb: framebuffer to flip onto plane
+ * @crtc_x: x offset of primary plane on crtc
+ * @crtc_y: y offset of primary plane on crtc
+ * @crtc_w: width of primary plane rectangle on crtc
+ * @crtc_h: height of primary plane rectangle on crtc
+ * @src_x: x offset of @fb for panning
+ * @src_y: y offset of @fb for panning
+ * @src_w: width of source rectangle in @fb
+ * @src_h: height of source rectangle in @fb
+ *
+ * Provides a default plane update handler for primary planes. This is handler
+ * is called in response to a userspace SetPlane operation on the plane with a
+ * non-NULL framebuffer. We call the driver's pageflip handler to update the
+ * framebuffer.
+ *
+ * SetPlane() on a primary plane of a disabled CRTC is not supported, and will
+ * return an error.
+ *
+ * Note that we assume most hardware can't reposition or scale the primary
+ * plane, so we require that crtc_x = crtc_y = 0 and that src_w/src_h match the
+ * current mode. Drivers for hardware that don't have these restrictions can
+ * provide their own implementation rather than using this helper.
+ *
+ * RETURNS:
+ * Zero on success, error code on failure
+ */
+int drm_primary_helper_update(struct drm_plane *plane, struct drm_crtc *crtc,
+ struct drm_framebuffer *fb,
+ int crtc_x, int crtc_y,
+ unsigned int crtc_w, unsigned int crtc_h,
+ uint32_t src_x, uint32_t src_y,
+ uint32_t src_w, uint32_t src_h)
+{
+ struct drm_mode_set set = {
+
[RFCv2 00/10] Universal plane support
One of the stepping stones on the way to atomic/nuclear operation is to expose all types of hardware planes to userspace via a consistent interface. Until now, the DRM plane interface has only operated on planes that drivers consider "overlay" or "sprite" planes; primary planes were simply represented by extra state hanging off the CRTC, and cursor planes had no direct representation in userspace, but were manipulated via separate ioctl's. This patch set begins the process of unifying the various plane types into a single, consistent interface. With this patchset, userspace clients that set a DRM_CLIENT_CAP_UNIVERSAL_PLANES client capability bit will receive a full list of all hardware planes, including primary planes and cursor planes, not just the overlay/sprite planes that have historically been returned. Userspace should be able to make drmModeSetPlane() calls against any type of plane and have them operate as expected (to the extent supported by the underlying hardware). This benefits of this unified interface will be most evident once driver state is fully property-ized as part of the upcoming atomic modeset / nuclear pageflip work. However there are a few benefits that may be achieved even before then: * Drivers for hardware with scaling-capable primary planes may honor userspace scaling requests for the primary plane made with the drmModeSetPlane() call. Previously there was no interface that allowed userspace to specify desired scaling on primary planes. * Drivers for hardware that may disable primary planes independently from the underlying CRTC may now do so when userspace passes a NULL framebuffer to the drmModeSetPlane() interface. This patchset is organized as follows: - Patch 1 updates the DRM core with the general concept of multiple plane types and prepares for there to be multiple types of planes on the DRM plane list. - Patch 2 adds a set of primary plane helper functions that drivers may use to quickly support plane operations against primary planes. These helpers implement plane update operations by calling into the driver's modeset interface. These helpers are optional; drivers are free to provide their own implementation. - Patches 3 and 4 update loops over the DRM plane list in the exynos and i915 drivers to ignore non-overlay planes. This ensures that the behavior of these loops will not change when new plane types show up on the DRM plane list in future patches. - Patch 5 adds a "plane type" property that allows userspace to identify the types of the planes it receives. Note that we replace the 'priv' parameter to drm_plane_init() with the type that should be used for this property; in doing so, we create the first opportunity for non-overlay planes to appear on the DRM plane list for some drivers ( msm, omap, and imx), although they will not be visible to userspace at this time. - Patch 6 updates all drivers to call drm_primary_helper_create_plane() before CRTC creation and then pass the resulting plane to drm_crtc_init(). This will create a primary plane via the primary plane helper and add it to the DRM plane list. Note that this is the first time that *all* drivers will have non-overlay planes on their plane list (msm, omap, and imx had their previously-private planes show up in the plane list in patch 5). These non-overlay planes still cannot be exposed to userspace. - Patch 7 drops the 'fb' field from drm_crtc and switches everything to using crtc->primary->fb instead. - Patch 8 adds the client capability bit which allows userspace to request the full plane list rather than just the overlay list. This is the first patch that may have a userspace-visible effect. - Patch 9 is a simple function name update in i915 to avoid confusion. - Patch 10 replaces the primary plane helper usage in i915 with a custom implementation of primary planes. On Intel hardware, we can disable the primary plane without disabling the entire CRTC; the custom implementation here allows us to avoid that limitation assumed by the helpers. This patch set is still a work in progress. Specific work that still needs to be done: * Update msm, omap, and imx to properly associate their primary planes with the appropriate CRTC (and stop creating a separate dummy primary plane). At the moment the formerly "private" planes that these drivers use are created as primary planes, but they're never specifically associated with the correct CRTC (i.e., passed at drm_crtc_init()). I think this should be pretty straightforward, but I just haven't had enough time to look through how those drivers are structured yet to make the change. [suggested by Rob Clark] * Add cursor plane implementation. The general infrastructure necessary to support cursors is present, but no default helpers exist yet and no driver actually registers any cursor planes. * Add extra re
[RFC 3/4] drm: add generic blob properties for image enhancement
On Fri, Mar 07, 2014 at 03:50:54PM +0530, Rahul Sharma wrote:
> Hi Daniel,
>
> On 7 March 2014 14:06, Daniel Vetter wrote:
> > On Thu, Mar 06, 2014 at 11:42:13AM +0530, Rahul Sharma wrote:
> >> Add generic KMS blob properties to core drm framework. These
> >> are writable blob properties which can be used to set Image
> >> Enhancement parameters. The properties which are added here
> >> are meant for color reproduction, color saturation and edge
> >> enhancement.
> >>
> >> Signed-off-by: Rahul Sharma
...
> > Tbh I don't really understand why we can't use normal properties for this.
> > We might want to add a new RBG type of property (or YUV fwiw, both with
> > and without alpha) to make this standardized (maybe with some fixed point
> > value for non-normalizes).
>
> I dropped Normal properties (the ones which accepts 64 bit data)
> because there will be too many of them. As you can see the
> count is going upto 24 parameters, means 24 such properties, as
> each can carry one parameter. This is too much of overhead.
> Please correct me if you mean something different.
>
> I am not sure what are RGB type properties? I know only about 64-bit
> normal properties which are too compact to carry above structures. Are
> you talking about set_gamma type of ioctls. Each "set_gamma" type
> ioctl needs a addition in callbacks till down the layer which looks bit
> unnecessary, while writable blob properties are using same set_property
> and get_property infrastructure.
>
> >
> > If the only reason you group them is to atomically commit them, then the
> > only thing we need is the atomic ioctl, which can shovel entire groups of
> > properties over the wire at once.
>
> Atomic commit is not an explicit requirement. But splitting them to
> many small pieces (in case of normal properties) are resulting into
> many user-kernel switching overhead, which seems avoidable.
The idea with atomic modeset / nuclear pageflip is that you collect a
whole bunch of individual property updates into a "property set"
container in userspace (libdrm). When you're done setting all the
values you want and "commit" the property set, all of the values that
you collected get passed to the kernel in one go via a new ioctl (and
are then updated in an atomic manner by the DRM driver). So performing
your 24 different property updates via the upcoming atomic API's
shouldn't be a problem and shouldn't add any unnecessary overhead.
The kernel-side of atomic modeset / nuclear pageflip is still a WIP, so
it isn't upstream yet, but you can see the userspace-facing API in Rob
Clark's repo here:
https://github.com/robclark/libdrm/blob/atomic/xf86drmMode.h
Note the drmModePropertySet{Alloc,Add,Commit,Free}() functions near the
bottom.
Matt
--
Matt Roper
Graphics Software Engineer
ISG Platform Enabling & Development
Intel Corporation
(916) 356-2795
