RFC: DRM trivial tree
On 8 October 2015 at 01:15, Thierry Reding wrote: > Hi everyone, > > Lately I've noticed that a bunch of trivial patches have been posted > across all drivers. We've also encountered situations in the past where > (relatively trivial) subsystem-wide changes have been made but it ended > up being very difficult to get patches merged (often because they had > inter-dependencies and nobody felt responsible for merging them). Often > Dave has been the last resort for this kind of patches. A side-effect > has been that it often takes a lot of time for such patches to get > merged (if at all) and they usually don't end up in linux-next and > therefore see little testing before they are applied. > > To remedy that situation I'd like to propose the addition of a tree to > keep track of these kinds of patches. Note that the target here are > trivial patches, such as coding style fixes, fixes for build warnings > or errors, subsystem-wide API changes, etc. It also targets mostly the > drivers that don't have a branch that feeds into linux-next. Patches > against drivers that already feed into linux-next should go through the > corresponding trees. One reasonable exception for this, in my opinion, > are subsystem-wide changes, because applying them via different trees > usually ends up being messy. > > I pushed a branch[0] with a set of patches that I've picked up from > patchwork and which seemed to match the above criteria. I've also Cc'ed > a bunch of people (mostly a subset of what get_maintainer.pl reported > for the patches in the branch). > > Before going any further with this I'd like to get some feedback on the > idea. Dave, do you think this is a good idea and would you be willing to > give this a try? I'm not going to object, I'm not sure trivial covers a lot of these patches though. I generally don't go nuts picking up the trivial patches on a weekly basis, as I don't think they generally need that much attention, a number of the things in your tree for example are things I've merged into -fixes instead, or I'm waiting to see if driver maintainers pick them up themselves. It would be nice if more driver maintainers had trees feeding into drm-next or sent me drm-next pull requests no matter how small on a more regular basis esp after -rc2/3. So I probably wouldn't to a pull req from that tree, but it might be something I'd cherry-pick from if I remember instead of using patchwork. At least in theory I'm the last line of maintainer for the non-ARM drivers (i.e. qxl, mgag200, etc), I don't really want to be last person in line for SoC drivers as I'm not really knowledgeable enough, and for SoCs I'm pretty much at the stage where only pull requests from someone who cares will generally make me merge patches. but hey lets give this a go and see if it helps, if you have the time! Dave.
[Bug 92338] GtkPerf shows extremely low drawing performance for GtkDrawingArea - Lines and Circles tests on R390X
https://bugs.freedesktop.org/show_bug.cgi?id=92338 Michel Dänzer changed: What|Removed |Added Component|Drivers/Gallium/radeonsi|Driver/glamor Version|11.0|unspecified Assignee|dri-devel at lists.freedesktop |xorg-team at lists.x.org |.org| Product|Mesa|xorg QA Contact|dri-devel at lists.freedesktop |xorg-team at lists.x.org |.org| --- Comment #11 from Michel Dänzer --- This should be much better with glamor from a current version of xserver. -- 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/20151008/31e85e13/attachment.html>
[Bug 91540] slow rendering & fullscreen results in stale images
https://bugs.freedesktop.org/show_bug.cgi?id=91540 --- Comment #5 from Michel Dänzer --- (In reply to Bas Nieuwenhuizen from comment #4) > I tested this again with the agd5f/linux drm-next-4.3 branch and this bug > did not occur anymore. Is it really completely gone for you? I still seem to be seeing at least a mild variation of the problem after bootup, though sometimes it seems to disappear by itself after a while now. -- 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/20151008/1dec9ced/attachment.html>
[PULL] topic/drm-misc
Hi Dave, Another round of drm-misc. Unfortunately the DRM_UNLOCKED removal for DRIVER_MODESET isn't complete yet for lack of review on 1-2 patches. Otherwise just various stuff all over. Cheers, Daniel The following changes since commit 2d4df13c0f9ef56452b1d9a9016cb3946e17bfe5: Merge tag 'topic/drm-misc-2015-09-25' of git://anongit.freedesktop.org/drm-intel into drm-next (2015-09-30 08:35:45 +1000) are available in the git repository at: git://anongit.freedesktop.org/drm-intel tags/topic/drm-misc-2015-10-08 for you to fetch changes up to b44f84081b8db1b5830cbd30280ba1109cc1a084: drm: Stop using drm_vblank_count() as the hw frame counter (2015-10-07 16:13:52 +0200) Daniel Vetter (8): drm/doc: Update docs about device instance setup drm: Remove __OS_HAS_AGP drm: Define a drm_invalid_op ioctl implementation drm/drm_ioctl.c: kerneldoc drm/vmwgfx: Stop checking for DRM_UNLOCKED drm: Remove dummy agp ioctl wrappers drm/i915: Remove setparam ioctl drm: Hack around CONFIG_AGP=m build failures Joonas Lahtinen (2): drm: Add DRM_ROTATE_MASK and DRM_REFLECT_MASK drm: Use DRM_ROTATE_MASK and DRM_REFLECT_MASK Lukas Wunner (1): vga_switcheroo: Add missing locking Rasmus Villemoes (1): vgaarb: use kzalloc in vga_arbiter_add_pci_device() Thierry Reding (1): drm/irq: Use unsigned int pipe in public API Ville Syrjälä (2): drm: Don't zero vblank timestamps from the irq handler drm: Stop using drm_vblank_count() as the hw frame counter Documentation/DocBook/drm.tmpl | 100 +--- drivers/gpu/drm/Makefile| 5 +- drivers/gpu/drm/amd/amdgpu/amdgpu.h | 8 +- drivers/gpu/drm/amd/amdgpu/amdgpu_display.c | 9 ++- drivers/gpu/drm/amd/amdgpu/amdgpu_kms.c | 36 - drivers/gpu/drm/amd/amdgpu/amdgpu_mode.h| 9 +-- drivers/gpu/drm/armada/armada_drv.c | 10 +-- drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_dc.c| 8 +- drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_plane.c | 2 +- drivers/gpu/drm/drm_agpsupport.c| 4 - drivers/gpu/drm/drm_bufs.c | 6 +- drivers/gpu/drm/drm_crtc.c | 3 +- drivers/gpu/drm/drm_drv.c | 55 - drivers/gpu/drm/drm_ioc32.c | 6 +- drivers/gpu/drm/drm_ioctl.c | 83 ++-- drivers/gpu/drm/drm_irq.c | 26 +- drivers/gpu/drm/drm_memory.c| 6 +- drivers/gpu/drm/drm_pci.c | 11 +++ drivers/gpu/drm/drm_platform.c | 3 + drivers/gpu/drm/drm_rect.c | 4 +- drivers/gpu/drm/drm_vm.c| 8 +- drivers/gpu/drm/exynos/exynos_drm_crtc.c| 4 +- drivers/gpu/drm/exynos/exynos_drm_crtc.h| 4 +- drivers/gpu/drm/exynos/exynos_drm_drv.c | 2 +- drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_drv.c | 7 +- drivers/gpu/drm/gma500/psb_drv.h| 6 +- drivers/gpu/drm/gma500/psb_irq.c| 8 +- drivers/gpu/drm/gma500/psb_irq.h| 6 +- drivers/gpu/drm/i915/i915_debugfs.c | 1 - drivers/gpu/drm/i915/i915_dma.c | 33 +--- drivers/gpu/drm/i915/i915_drv.h | 1 - drivers/gpu/drm/i915/i915_gem_fence.c | 2 +- drivers/gpu/drm/i915/i915_irq.c | 34 drivers/gpu/drm/imx/imx-drm-core.c | 10 +-- drivers/gpu/drm/mga/mga_dma.c | 4 +- drivers/gpu/drm/mga/mga_drv.h | 6 +- drivers/gpu/drm/mga/mga_irq.c | 20 ++--- drivers/gpu/drm/msm/msm_drv.c | 14 ++-- drivers/gpu/drm/nouveau/nouveau_bo.c| 8 +- drivers/gpu/drm/nouveau/nouveau_display.c | 23 +++--- drivers/gpu/drm/nouveau/nouveau_display.h | 12 +-- drivers/gpu/drm/nouveau/nouveau_drm.c | 2 +- drivers/gpu/drm/omapdrm/omap_drv.c | 2 +- drivers/gpu/drm/omapdrm/omap_drv.h | 4 +- drivers/gpu/drm/omapdrm/omap_fb.c | 4 +- drivers/gpu/drm/omapdrm/omap_irq.c | 16 ++-- drivers/gpu/drm/omapdrm/omap_plane.c| 2 +- drivers/gpu/drm/qxl/qxl_drv.c | 7 +- drivers/gpu/drm/r128/r128_cce.c | 12 +-- drivers/gpu/drm/r128/r128_drv.h | 6 +- drivers/gpu/drm/r128/r128_irq.c | 16 ++-- drivers/gpu/drm/radeon/r600_cp.c| 14 ++-- drivers/gpu/drm/radeon/radeon_agp.c | 8 +- drivers/gpu/drm/radeon/radeon_cp.c | 16 ++-- drivers/gpu/drm/radeon/radeon_display.c | 25 +++--- drivers/gpu/drm/radeon/radeon_drv.c | 13 ++- drivers/gpu/drm/radeon/radeon_
RFC: DRM trivial tree
On Thu, Oct 08, 2015 at 09:04:06AM +1000, Dave Airlie wrote: > On 8 October 2015 at 01:15, Thierry Reding > wrote: > > Hi everyone, > > > > Lately I've noticed that a bunch of trivial patches have been posted > > across all drivers. We've also encountered situations in the past where > > (relatively trivial) subsystem-wide changes have been made but it ended > > up being very difficult to get patches merged (often because they had > > inter-dependencies and nobody felt responsible for merging them). Often > > Dave has been the last resort for this kind of patches. A side-effect > > has been that it often takes a lot of time for such patches to get > > merged (if at all) and they usually don't end up in linux-next and > > therefore see little testing before they are applied. > > > > To remedy that situation I'd like to propose the addition of a tree to > > keep track of these kinds of patches. Note that the target here are > > trivial patches, such as coding style fixes, fixes for build warnings > > or errors, subsystem-wide API changes, etc. It also targets mostly the > > drivers that don't have a branch that feeds into linux-next. Patches > > against drivers that already feed into linux-next should go through the > > corresponding trees. One reasonable exception for this, in my opinion, > > are subsystem-wide changes, because applying them via different trees > > usually ends up being messy. > > > > I pushed a branch[0] with a set of patches that I've picked up from > > patchwork and which seemed to match the above criteria. I've also Cc'ed > > a bunch of people (mostly a subset of what get_maintainer.pl reported > > for the patches in the branch). > > > > Before going any further with this I'd like to get some feedback on the > > idea. Dave, do you think this is a good idea and would you be willing to > > give this a try? > > I'm not going to object, I'm not sure trivial covers a lot of these > patches though. > > I generally don't go nuts picking up the trivial patches on a weekly basis, > as I > don't think they generally need that much attention, a number of the things > in your tree for example are things I've merged into -fixes instead, or I'm > waiting to see if driver maintainers pick them up themselves. > > It would be nice if more driver maintainers had trees feeding into drm-next > or sent me drm-next pull requests no matter how small on a more regular basis > esp after -rc2/3. > > So I probably wouldn't to a pull req from that tree, but it might be something > I'd cherry-pick from if I remember instead of using patchwork. > > At least in theory I'm the last line of maintainer for the non-ARM drivers > (i.e. qxl, mgag200, etc), I don't really want to be last person in line for > SoC > drivers as I'm not really knowledgeable enough, and for SoCs I'm pretty > much at the stage where only pull requests from someone who cares will > generally > make me merge patches. > > but hey lets give this a go and see if it helps, if you have the time! I think this tree could be useful as a welcoming ground for new folks who send in small fixes as their first patch. I think we have a few of those nowadays (besides the usual tree-wide style police), and I think making sure that their patches get an "ack, merged it to $branch" quickly would help a lot in motivating them to dig in more. So not about patches getting lost, but getting a quick thanks out there. I'm doing that for the core with drm-misc, but there's definitely a gap with armsoc infrastructure and random drivers. So maybe don't call it drm-trivial (since "hey your patch here is trivial" doesn't sound that awesome) but drm-misc-drivers. -Daniel -- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch
RFC: DRM trivial tree
is a go and see if it helps, if you have the time! Coordinating which patches go where is probably going to be the most difficult part. Any suggestions? Perhaps the simplest would be to base that tree onto drm-fixes and drm-next so that patches can automatically filter out with a rebase. But that means that it would need to be fairly often rebased for it to be effective. Maybe just using IRC, email or even patchwork would be equally effective. Thierry -- next part -- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: not available URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20151008/b28eca38/attachment.sig>
RFC: DRM trivial tree
On Thu, Oct 08, 2015 at 09:46:50AM +0200, Daniel Vetter wrote: > On Thu, Oct 08, 2015 at 09:04:06AM +1000, Dave Airlie wrote: > > On 8 October 2015 at 01:15, Thierry Reding > > wrote: > > > Hi everyone, > > > > > > Lately I've noticed that a bunch of trivial patches have been posted > > > across all drivers. We've also encountered situations in the past where > > > (relatively trivial) subsystem-wide changes have been made but it ended > > > up being very difficult to get patches merged (often because they had > > > inter-dependencies and nobody felt responsible for merging them). Often > > > Dave has been the last resort for this kind of patches. A side-effect > > > has been that it often takes a lot of time for such patches to get > > > merged (if at all) and they usually don't end up in linux-next and > > > therefore see little testing before they are applied. > > > > > > To remedy that situation I'd like to propose the addition of a tree to > > > keep track of these kinds of patches. Note that the target here are > > > trivial patches, such as coding style fixes, fixes for build warnings > > > or errors, subsystem-wide API changes, etc. It also targets mostly the > > > drivers that don't have a branch that feeds into linux-next. Patches > > > against drivers that already feed into linux-next should go through the > > > corresponding trees. One reasonable exception for this, in my opinion, > > > are subsystem-wide changes, because applying them via different trees > > > usually ends up being messy. > > > > > > I pushed a branch[0] with a set of patches that I've picked up from > > > patchwork and which seemed to match the above criteria. I've also Cc'ed > > > a bunch of people (mostly a subset of what get_maintainer.pl reported > > > for the patches in the branch). > > > > > > Before going any further with this I'd like to get some feedback on the > > > idea. Dave, do you think this is a good idea and would you be willing to > > > give this a try? > > > > I'm not going to object, I'm not sure trivial covers a lot of these > > patches though. > > > > I generally don't go nuts picking up the trivial patches on a weekly basis, > > as I > > don't think they generally need that much attention, a number of the things > > in your tree for example are things I've merged into -fixes instead, or I'm > > waiting to see if driver maintainers pick them up themselves. > > > > It would be nice if more driver maintainers had trees feeding into drm-next > > or sent me drm-next pull requests no matter how small on a more regular > > basis > > esp after -rc2/3. > > > > So I probably wouldn't to a pull req from that tree, but it might be > > something > > I'd cherry-pick from if I remember instead of using patchwork. > > > > At least in theory I'm the last line of maintainer for the non-ARM drivers > > (i.e. qxl, mgag200, etc), I don't really want to be last person in line for > > SoC > > drivers as I'm not really knowledgeable enough, and for SoCs I'm pretty > > much at the stage where only pull requests from someone who cares will > > generally > > make me merge patches. > > > > but hey lets give this a go and see if it helps, if you have the time! > > I think this tree could be useful as a welcoming ground for new folks who > send in small fixes as their first patch. I think we have a few of those > nowadays (besides the usual tree-wide style police), and I think making > sure that their patches get an "ack, merged it to $branch" quickly would > help a lot in motivating them to dig in more. So not about patches getting > lost, but getting a quick thanks out there. I'm doing that for the core > with drm-misc, but there's definitely a gap with armsoc infrastructure and > random drivers. > > So maybe don't call it drm-trivial (since "hey your patch here is trivial" > doesn't sound that awesome) but drm-misc-drivers. I'm afraid that this is going to encourage people to not properly maintain their drivers. The reason why I wanted to call it trivial was because the requirement would have to be that the patches should be small. I lack the knowledge about most SoC drivers to properly review patches that go beyond minor things like cleanup. That said, I guess it would be okay to pick up more complex patches if they had an Acked-by or Reviewed-by from a maintainer. Then again, if they already find the time to review patches it probably wouldn't be a lot more effort to apply them to their own tree. But that's all really speculation, so perhaps it'd be best to just try it out and see how it goes. If it isn't useful we can always drop it again. Thierry -- next part -- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: not available URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20151008/9b5efc9a/attachment-0001.sig>
[Intel-gfx] [PATCH] drm/i915/irq: Fix misspelled word register in kernel-doc
On Thu, Oct 08, 2015 at 09:57:49AM +0200, Javier Martinez Canillas wrote: > There is a typo in the function i915_handle_error() > kernel-doc and the word register is spelled wrongly. > > Signed-off-by: Javier Martinez Canillas Both kerneldoc patches applied, thanks. -Daniel > --- > > drivers/gpu/drm/i915/i915_irq.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/drivers/gpu/drm/i915/i915_irq.c b/drivers/gpu/drm/i915/i915_irq.c > index 0344a9181dac..38dadd23684d 100644 > --- a/drivers/gpu/drm/i915/i915_irq.c > +++ b/drivers/gpu/drm/i915/i915_irq.c > @@ -2571,7 +2571,7 @@ static void i915_report_and_clear_eir(struct drm_device > *dev) > * i915_handle_error - handle a gpu error > * @dev: drm device > * > - * Do some basic checking of regsiter state at error time and > + * Do some basic checking of register state at error time and > * dump it to the syslog. Also call i915_capture_error_state() to make > * sure we get a record and make it available in debugfs. Fire a uevent > * so userspace knows something bad happened (should trigger collection > -- > 2.4.3 > > ___ > Intel-gfx mailing list > Intel-gfx at lists.freedesktop.org > http://lists.freedesktop.org/mailman/listinfo/intel-gfx -- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch
[PATCH 3/3] drm: panel-simple: implement URT UMSH-8596MD-xT panel support
On Wed, Oct 07, 2015 at 11:02:20PM +0200, Maciej S. Szmigiero wrote: > This patch implements support for United Radiant Technology > UMSH-8596MD-xT 7.0" WVGA TFT LCD panels in DRM panel-simple > driver. > > Signed-off-by: Maciej Szmigiero > --- > This replaces "drm: panel-simple: add URT UMSH-8596MD-xT panel support" > submission. > > drivers/gpu/drm/panel/panel-simple.c | 54 > > 1 file changed, 54 insertions(+) Looks good to me. I'll wait for Rob or anyone else to ack the vendor prefix before merging this. Thierry -- next part -- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: not available URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20151008/be094202/attachment.sig>
[PATCH 2/3] of: add URT UMSH-8596MD-xT panel DT bindings
On Wed, Oct 07, 2015 at 11:00:51PM +0200, Maciej S. Szmigiero wrote: > This patch adds DT bindings for United Radiant Technology > UMSH-8596MD-xT 7.0" WVGA TFT LCD panels. > > Signed-off-by: Maciej Szmigiero > --- > Documentation/devicetree/bindings/panel/urt,umsh-8596md.txt | 12 > 1 file changed, 12 insertions(+) > create mode 100644 > Documentation/devicetree/bindings/panel/urt,umsh-8596md.txt > > diff --git a/Documentation/devicetree/bindings/panel/urt,umsh-8596md.txt > b/Documentation/devicetree/bindings/panel/urt,umsh-8596md.txt > new file mode 100644 > index 000..57c5fa4 > --- /dev/null > +++ b/Documentation/devicetree/bindings/panel/urt,umsh-8596md.txt > @@ -0,0 +1,12 @@ > +United Radiant Technology UMSH-8596MD-xT 7.0" WVGA TFT LCD panel > + > +Supported are LVDS versions (-11T, -19T) and parallel ones > +(-T, -1T, -7T, -20T). > + > +Required properties: > +- compatible: should be one of: > + "urt,umsh-8596md-t", "urt,umsh-8596md-1t", "urt,umsh-8596md-7t", > + "urt,umsh-8596md-11t", "urt,umsh-8596md-19t" or "urt,umsh-8596md-20t". I'd probably list each of these on a single line for slightly more clarity, but no need to respin because of that. Rob, I remember there was some discussion a while back on whether or not there should be a standard way of describing lists of compatible values, do you know if anything was ever concluded on that topic? Thierry -- next part -- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: not available URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20151008/18991027/attachment.sig>
[PATCH 10/12] drm: bridge/dw_hdmi: fix phy enable/disable handling
Oh, I haven't noticed that those patches already have been
merged into linux-next :-)
On 10/08/2015 03:17 AM, Russell King - ARM Linux wrote:
> On Wed, Oct 07, 2015 at 06:40:11PM +0800, Yakir Yang wrote:
>>
>> On 10/07/2015 05:48 PM, Russell King - ARM Linux wrote:
>>> On Wed, Oct 07, 2015 at 12:05:37PM +0800, Yakir Yang wrote:
On 08/09/2015 12:04 AM, Russell King wrote:
> The dw_hdmi enable/disable handling is particularly weak in several
> regards:
> * The hotplug interrupt could call hdmi_poweron() or hdmi_poweroff()
>while DRM is setting a mode, which could race with a mode being set.
> * Hotplug will always re-enable the phy whenever it detects an active
>hotplug signal, even if DRM has disabled the output.
>
> Resolve all of these by introducing a mutex to prevent races, and a
> state-tracking bool so we know whether DRM wishes the output to be
> enabled. We choose to use our own mutex rather than ->struct_mutex
> so that we can still process interrupts in a timely fashion.
>
> Signed-off-by: Russell King
> ---
> drivers/gpu/drm/bridge/dw_hdmi.c | 29 ++---
> 1 file changed, 22 insertions(+), 7 deletions(-)
>
> diff --git a/drivers/gpu/drm/bridge/dw_hdmi.c
> b/drivers/gpu/drm/bridge/dw_hdmi.c
> index 7b8a4e942a71..0ee188930d26 100644
> --- a/drivers/gpu/drm/bridge/dw_hdmi.c
> +++ b/drivers/gpu/drm/bridge/dw_hdmi.c
> @@ -125,6 +125,9 @@ struct dw_hdmi {
> bool sink_is_hdmi;
> bool sink_has_audio;
> + struct mutex mutex; /* for state below and previous_mode */
> + bool disabled; /* DRM has disabled our bridge */
> +
> spinlock_t audio_lock;
> struct mutex audio_mutex;
> unsigned int sample_rate;
> @@ -1389,8 +1392,12 @@ static void dw_hdmi_bridge_mode_set(struct
> drm_bridge *bridge,
> {
> struct dw_hdmi *hdmi = bridge->driver_private;
> + mutex_lock(&hdmi->mutex);
> +
> /* Store the display mode for plugin/DKMS poweron events */
> memcpy(&hdmi->previous_mode, mode, sizeof(hdmi->previous_mode));
> +
> + mutex_unlock(&hdmi->mutex);
> }
> static bool dw_hdmi_bridge_mode_fixup(struct drm_bridge *bridge,
> @@ -1404,14 +1411,20 @@ static void dw_hdmi_bridge_disable(struct
> drm_bridge *bridge)
> {
> struct dw_hdmi *hdmi = bridge->driver_private;
> + mutex_lock(&hdmi->mutex);
> + hdmi->disabled = true;
> dw_hdmi_poweroff(hdmi);
> + mutex_unlock(&hdmi->mutex);
> }
> static void dw_hdmi_bridge_enable(struct drm_bridge *bridge)
> {
> struct dw_hdmi *hdmi = bridge->driver_private;
> + mutex_lock(&hdmi->mutex);
> dw_hdmi_poweron(hdmi);
> + hdmi->disabled = false;
> + mutex_unlock(&hdmi->mutex);
> }
> static void dw_hdmi_bridge_nop(struct drm_bridge *bridge)
> @@ -1534,20 +1547,20 @@ static irqreturn_t dw_hdmi_irq(int irq, void
> *dev_id)
> phy_int_pol = hdmi_readb(hdmi, HDMI_PHY_POL0);
> if (intr_stat & HDMI_IH_PHY_STAT0_HPD) {
> + hdmi_modb(hdmi, ~phy_int_pol, HDMI_PHY_HPD, HDMI_PHY_POL0);
> + mutex_lock(&hdmi->mutex);
> if (phy_int_pol & HDMI_PHY_HPD) {
> dev_dbg(hdmi->dev, "EVENT=plugin\n");
> - hdmi_modb(hdmi, 0, HDMI_PHY_HPD, HDMI_PHY_POL0);
> -
> - dw_hdmi_poweron(hdmi);
> + if (!hdmi->disabled)
> + dw_hdmi_poweron(hdmi);
> } else {
> dev_dbg(hdmi->dev, "EVENT=plugout\n");
> - hdmi_modb(hdmi, HDMI_PHY_HPD, HDMI_PHY_HPD,
> - HDMI_PHY_POL0);
> -
> - dw_hdmi_poweroff(hdmi);
> + if (!hdmi->disabled)
> + dw_hdmi_poweroff(hdmi);
Just like my reply on 08/12, I thought this could be removed, so
poweron/poweroff would only be called with bridge->enable/
bridge->disable, them maybe no need mutex here.
>>> The bridge enable/disable methods do not get called on hotplug changes.
>>>
>>> [1.363011] dwhdmi-imx 12.hdmi: Detected HDMI controller
>>> 0x13:0xa:0xa0:0xc1
>>> [1.371341] dwhdmi-imx 12.hdmi: dw_hdmi_irq(I:RX,HPD
>>> P:RX3210,HPD S:RX,HPD)
>>> [1.381345] imx-drm display-subsystem: bound 12.hdmi (ops
>>> dw_hdmi_imx_ops)
>>> [1.448691] dwhdmi-imx 12.hdmi: dw_hdmi_bridge_disable()
>>> [1.450963] dwhdmi-imx 12.hdmi: dw_hdmi_bridge_enable()
>>>
>>> and then unplugging and re-plugging the HDMI cable:
>>>
>>> [ 68.307505] dwhdmi-imx 12.hdmi: dw_hdmi_irq(I:RX,HPD
>>> P:RX3210,--- S:RX,---)
>>> [ 73.813970] dwhdmi-imx
[PATCH 1/3] drm/edid: Fix up clock for CEA/HDMI modes specified via detailed timings
From: Ville Syrjälä
EDID detailed timings have a resolution of 10kHz for the pixel clock, so
they can't represent certain CEA/HDMI modes accurately. If we see a mode
coming in via detailed timings which otherwise matches one of the
CEA/HDMI modes except the clock is just a bit off, let's assume that the
intention was for that mode to be one of the CEA/HDMI modes and go ahead
and fix up the clock to match the CEA/HDMI spec exactly (well, as close
as we can get with the 1 kHz resolution we use).
This should help code that's looking for an exact clock match (eg. i915
audio N/CTS setup).
Cc: Adam Jackson
Cc: Clint Taylor
Cc: Libin Yang
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/drm_edid.c | 48 ++
1 file changed, 48 insertions(+)
diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c
index d895556..977915c 100644
--- a/drivers/gpu/drm/drm_edid.c
+++ b/drivers/gpu/drm/drm_edid.c
@@ -2418,6 +2418,8 @@ add_cvt_modes(struct drm_connector *connector, struct
edid *edid)
return closure.modes;
}
+static void fixup_detailed_cea_mode_clock(struct drm_display_mode *mode);
+
static void
do_detailed_mode(struct detailed_timing *timing, void *c)
{
@@ -2434,6 +2436,13 @@ do_detailed_mode(struct detailed_timing *timing, void *c)
if (closure->preferred)
newmode->type |= DRM_MODE_TYPE_PREFERRED;
+ /*
+* Detailed modes are limited to 10kHz pixel clock resolution,
+* so fix up anything that looks like CEA/HDMI mode, but the
clock
+* is just slightly off.
+*/
+ fixup_detailed_cea_mode_clock(newmode);
+
drm_mode_probed_add(closure->connector, newmode);
closure->modes++;
closure->preferred = 0;
@@ -3103,6 +3112,45 @@ add_cea_modes(struct drm_connector *connector, struct
edid *edid)
return modes;
}
+static void fixup_detailed_cea_mode_clock(struct drm_display_mode *mode)
+{
+ const struct drm_display_mode *cea_mode;
+ int clock1, clock2, clock;
+ u8 mode_idx;
+ const char *type;
+
+ mode_idx = drm_match_cea_mode(mode) - 1;
+ if (mode_idx < ARRAY_SIZE(edid_cea_modes)) {
+ type = "CEA";
+ cea_mode = &edid_cea_modes[mode_idx];
+ clock1 = cea_mode->clock;
+ clock2 = cea_mode_alternate_clock(cea_mode);
+ } else {
+ mode_idx = drm_match_hdmi_mode(mode) - 1;
+ if (mode_idx < ARRAY_SIZE(edid_4k_modes)) {
+ type = "HDMI";
+ cea_mode = &edid_4k_modes[mode_idx];
+ clock1 = cea_mode->clock;
+ clock2 = hdmi_mode_alternate_clock(cea_mode);
+ } else {
+ return;
+ }
+ }
+
+ /* pick whichever is closest */
+ if (abs(mode->clock - clock1) < abs(mode->clock - clock2))
+ clock = clock1;
+ else
+ clock = clock2;
+
+ if (mode->clock == clock)
+ return;
+
+ DRM_DEBUG("detailed mode matches %s VIC %d, adjusting clock %d -> %d\n",
+ type, mode_idx + 1, mode->clock, clock);
+ mode->clock = clock;
+}
+
static void
parse_hdmi_vsdb(struct drm_connector *connector, const u8 *db)
{
--
2.4.9
[PATCH 2/3] drm/edid: Round to closest when computing the CEA/HDMI alternate clock
From: Ville Syrjälä Rounding to the closest kHz seems like the better option that round down or up when computing the alternate clock for CEA/HDMI modes. It'll give us a slightly more accurate clock in some cases. Not sure why I went for the down+up approach originally. Perhaps I was thinking we can go back and forth betwen the two frequencies without introducing errors, but round to closest still maintains that property. Cc: Adam Jackson Cc: Clint Taylor Cc: Libin Yang Signed-off-by: Ville Syrjälä --- drivers/gpu/drm/drm_edid.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c index 977915c..d5d2c03 100644 --- a/drivers/gpu/drm/drm_edid.c +++ b/drivers/gpu/drm/drm_edid.c @@ -2538,9 +2538,9 @@ cea_mode_alternate_clock(const struct drm_display_mode *cea_mode) * and the 60Hz variant otherwise. */ if (cea_mode->vdisplay == 240 || cea_mode->vdisplay == 480) - clock = clock * 1001 / 1000; + clock = DIV_ROUND_CLOSEST(clock * 1001, 1000); else - clock = DIV_ROUND_UP(clock * 1000, 1001); + clock = DIV_ROUND_CLOSEST(clock * 1000, 1001); return clock; } -- 2.4.9
[PATCH 3/3] drm/i915: Use round to closest when computing the CEA 1.001 pixel clocks
From: Ville Syrjälä
drm_edid.c now computes the alternate CEA clocks using
DIV_ROUND_CLOSEST(), so follow suit in the N/CTS setup to make sure we
pick the right setting for the mode.
Unfortunately we can't actually use DIV_ROUND_CLOSEST() here due to the
({}) construct used, so just stick in raw numbers instead.
Cc: Clint Taylor
Cc: Libin Yang
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/intel_audio.c | 12 ++--
1 file changed, 6 insertions(+), 6 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_audio.c
b/drivers/gpu/drm/i915/intel_audio.c
index 56c2f54..4dccd9b 100644
--- a/drivers/gpu/drm/i915/intel_audio.c
+++ b/drivers/gpu/drm/i915/intel_audio.c
@@ -61,21 +61,21 @@ static const struct {
int clock;
u32 config;
} hdmi_audio_clock[] = {
- { DIV_ROUND_UP(25200 * 1000, 1001), AUD_CONFIG_PIXEL_CLOCK_HDMI_25175 },
+ { 25175, AUD_CONFIG_PIXEL_CLOCK_HDMI_25175 },
{ 25200, AUD_CONFIG_PIXEL_CLOCK_HDMI_25200 }, /* default per bspec */
{ 27000, AUD_CONFIG_PIXEL_CLOCK_HDMI_27000 },
- { 27000 * 1001 / 1000, AUD_CONFIG_PIXEL_CLOCK_HDMI_27027 },
+ { 27027, AUD_CONFIG_PIXEL_CLOCK_HDMI_27027 },
{ 54000, AUD_CONFIG_PIXEL_CLOCK_HDMI_54000 },
- { 54000 * 1001 / 1000, AUD_CONFIG_PIXEL_CLOCK_HDMI_54054 },
- { DIV_ROUND_UP(74250 * 1000, 1001), AUD_CONFIG_PIXEL_CLOCK_HDMI_74176 },
+ { 54054, AUD_CONFIG_PIXEL_CLOCK_HDMI_54054 },
+ { 74176, AUD_CONFIG_PIXEL_CLOCK_HDMI_74176 },
{ 74250, AUD_CONFIG_PIXEL_CLOCK_HDMI_74250 },
- { DIV_ROUND_UP(148500 * 1000, 1001), AUD_CONFIG_PIXEL_CLOCK_HDMI_148352
},
+ { 148352, AUD_CONFIG_PIXEL_CLOCK_HDMI_148352 },
{ 148500, AUD_CONFIG_PIXEL_CLOCK_HDMI_148500 },
};
/* HDMI N/CTS table */
#define TMDS_297M 297000
-#define TMDS_296M DIV_ROUND_UP(297000 * 1000, 1001)
+#define TMDS_296M 296703
static const struct {
int sample_rate;
int clock;
--
2.4.9
RFC: DRM trivial tree
On 10/08/2015 10:16 AM, Thierry Reding wrote: > On Thu, Oct 08, 2015 at 09:46:50AM +0200, Daniel Vetter wrote: >> On Thu, Oct 08, 2015 at 09:04:06AM +1000, Dave Airlie wrote: >>> On 8 October 2015 at 01:15, Thierry Reding >>> wrote: Hi everyone, Lately I've noticed that a bunch of trivial patches have been posted across all drivers. We've also encountered situations in the past where (relatively trivial) subsystem-wide changes have been made but it ended up being very difficult to get patches merged (often because they had inter-dependencies and nobody felt responsible for merging them). Often Dave has been the last resort for this kind of patches. A side-effect has been that it often takes a lot of time for such patches to get merged (if at all) and they usually don't end up in linux-next and therefore see little testing before they are applied. To remedy that situation I'd like to propose the addition of a tree to keep track of these kinds of patches. Note that the target here are trivial patches, such as coding style fixes, fixes for build warnings or errors, subsystem-wide API changes, etc. It also targets mostly the drivers that don't have a branch that feeds into linux-next. Patches against drivers that already feed into linux-next should go through the corresponding trees. One reasonable exception for this, in my opinion, are subsystem-wide changes, because applying them via different trees usually ends up being messy. I pushed a branch[0] with a set of patches that I've picked up from patchwork and which seemed to match the above criteria. I've also Cc'ed a bunch of people (mostly a subset of what get_maintainer.pl reported for the patches in the branch). Before going any further with this I'd like to get some feedback on the idea. Dave, do you think this is a good idea and would you be willing to give this a try? >>> >>> I'm not going to object, I'm not sure trivial covers a lot of these >>> patches though. >>> >>> I generally don't go nuts picking up the trivial patches on a weekly basis, >>> as I >>> don't think they generally need that much attention, a number of the things >>> in your tree for example are things I've merged into -fixes instead, or I'm >>> waiting to see if driver maintainers pick them up themselves. >>> >>> It would be nice if more driver maintainers had trees feeding into drm-next >>> or sent me drm-next pull requests no matter how small on a more regular >>> basis >>> esp after -rc2/3. >>> >>> So I probably wouldn't to a pull req from that tree, but it might be >>> something >>> I'd cherry-pick from if I remember instead of using patchwork. >>> >>> At least in theory I'm the last line of maintainer for the non-ARM drivers >>> (i.e. qxl, mgag200, etc), I don't really want to be last person in line for >>> SoC >>> drivers as I'm not really knowledgeable enough, and for SoCs I'm pretty >>> much at the stage where only pull requests from someone who cares will >>> generally >>> make me merge patches. >>> >>> but hey lets give this a go and see if it helps, if you have the time! >> >> I think this tree could be useful as a welcoming ground for new folks who >> send in small fixes as their first patch. I think we have a few of those >> nowadays (besides the usual tree-wide style police), and I think making >> sure that their patches get an "ack, merged it to $branch" quickly would >> help a lot in motivating them to dig in more. So not about patches getting >> lost, but getting a quick thanks out there. I'm doing that for the core >> with drm-misc, but there's definitely a gap with armsoc infrastructure and >> random drivers. >> >> So maybe don't call it drm-trivial (since "hey your patch here is trivial" >> doesn't sound that awesome) but drm-misc-drivers. > > I'm afraid that this is going to encourage people to not properly > maintain their drivers. The reason why I wanted to call it trivial was > because the requirement would have to be that the patches should be > small. I lack the knowledge about most SoC drivers to properly review > patches that go beyond minor things like cleanup. > My young maintainer experience make me ask this question: How maintainer can deal with some patch set that impacts many other drivers? And I think "drm-trivial" (or whatever the name) branch can answer the question. Indeed, it is dangerous to only pick the patch useful for their own driver and make a pull request (coherency is not insure). It will definitely lead to merge issue if same patches are in different tree. I understand the need of such "drm-trivial" but I wonder how patch set with impacts on different drivers were manage before this proposal? Vincent > That said, I guess it would be okay to pick up more complex patches if > they had an Acked-by or Reviewed-by from a maintainer. Then again, if > they already find the t
[Bug 99041] HDMI Audio not working after fixing HDMI.
https://bugzilla.kernel.org/show_bug.cgi?id=99041 --- Comment #2 from Thomas --- Alex Deucher: Any news on this? Currently I'm experiencing GPU stalls under heavy load (gaming, so far tested with Left 4 Dead 2 and Distance, both games need around 15 minutes of gameplay before screen freezes) and while I would love to debug this I can't as I'm pinned on the patched kernel (4.0.4) so I can't even test if a newer kernel would fix the issue (which came with a mesa update). -- You are receiving this mail because: You are watching the assignee of the bug.
[PATCH v3] drm/gma500: fix double freeing
We are allocating backing using psbfb_alloc() and so
backing->stolen is always true. So we were freeing backing two times.
Moreover if we follow the execution path then we should be freeing
backing after we have released the helper. So remove the one which frees
backing before the helper is released.
While at it the error labels are also renamed to give a meaningful
name.
Signed-off-by: Sudip Mukherjee
Reviewed-by: Patrik Jakobsson
---
drivers/gpu/drm/gma500/framebuffer.c | 13 -
1 file changed, 4 insertions(+), 9 deletions(-)
diff --git a/drivers/gpu/drm/gma500/framebuffer.c
b/drivers/gpu/drm/gma500/framebuffer.c
index 2eaf1b3..52e2bf3 100644
--- a/drivers/gpu/drm/gma500/framebuffer.c
+++ b/drivers/gpu/drm/gma500/framebuffer.c
@@ -411,7 +411,7 @@ static int psbfb_create(struct psb_fbdev *fbdev,
info = drm_fb_helper_alloc_fbi(&fbdev->psb_fb_helper);
if (IS_ERR(info)) {
ret = PTR_ERR(info);
- goto out_err1;
+ goto err_unlock;
}
info->par = fbdev;
@@ -419,7 +419,7 @@ static int psbfb_create(struct psb_fbdev *fbdev,
ret = psb_framebuffer_init(dev, psbfb, &mode_cmd, backing);
if (ret)
- goto out_unref;
+ goto err_release;
fb = &psbfb->base;
psbfb->fbdev = info;
@@ -465,14 +465,9 @@ static int psbfb_create(struct psb_fbdev *fbdev,
mutex_unlock(&dev->struct_mutex);
return 0;
-out_unref:
- if (backing->stolen)
- psb_gtt_free_range(dev, backing);
- else
- drm_gem_object_unreference(&backing->gem);
-
+err_release:
drm_fb_helper_release_fbi(&fbdev->psb_fb_helper);
-out_err1:
+err_unlock:
mutex_unlock(&dev->struct_mutex);
psb_gtt_free_range(dev, backing);
return ret;
--
1.9.1
[PATCH] drm/nouveau: fix memory leak
On Thu, Oct 01, 2015 at 04:40:59PM +1000, Ben Skeggs wrote: > On 09/25/2015 01:59 AM, Sudip Mukherjee wrote: > > On Fri, Sep 11, 2015 at 03:00:56PM +0530, Sudip Mukherjee wrote: > >> If pm_runtime_get_sync() we were going to "out" but we missed > >> freeing vma. > >> > >> Signed-off-by: Sudip Mukherjee --- > > Hi Ben, Another gentle ping for another patch. > Both patches are in my tree. Hi Ben, I am not seeing these in linux-next. regards sudip
[PATCH] drm,i915: Introduce drm_malloc_gfp()
I have instances where I want to use drm_malloc_ab() but with a custom
gfp mask. And with those, where I want a temporary allocation, I want to
try a high-order kmalloc() before using a vmalloc().
So refactor my usage into drm_malloc_gfp().
Signed-off-by: Chris Wilson
Cc: dri-devel at lists.freedesktop.org
Cc: Ville Syrjälä
---
drivers/gpu/drm/i915/i915_gem.c| 4 +---
drivers/gpu/drm/i915/i915_gem_execbuffer.c | 8 +++-
drivers/gpu/drm/i915/i915_gem_gtt.c| 5 +++--
drivers/gpu/drm/i915/i915_gem_userptr.c| 15 ---
include/drm/drm_mem_util.h | 19 +++
5 files changed, 30 insertions(+), 21 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
index fe672d4a4d73..c81127518083 100644
--- a/drivers/gpu/drm/i915/i915_gem.c
+++ b/drivers/gpu/drm/i915/i915_gem.c
@@ -2346,9 +2346,7 @@ void *i915_gem_object_pin_vmap(struct drm_i915_gem_object
*obj)
int n;
n = obj->base.size >> PAGE_SHIFT;
- pages = kmalloc(n*sizeof(*pages), GFP_TEMPORARY | __GFP_NOWARN);
- if (pages == NULL)
- pages = drm_malloc_ab(n, sizeof(*pages));
+ pages = drm_malloc_gfp(n, sizeof(*pages), GFP_TEMPORARY);
if (pages != NULL) {
n = 0;
for_each_sg_page(obj->pages->sgl, &sg_iter,
obj->pages->nents, 0)
diff --git a/drivers/gpu/drm/i915/i915_gem_execbuffer.c
b/drivers/gpu/drm/i915/i915_gem_execbuffer.c
index c35c9dc526e7..91fb7417efc0 100644
--- a/drivers/gpu/drm/i915/i915_gem_execbuffer.c
+++ b/drivers/gpu/drm/i915/i915_gem_execbuffer.c
@@ -1730,11 +1730,9 @@ i915_gem_execbuffer2(struct drm_device *dev, void *data,
return -EINVAL;
}
- exec2_list = kmalloc(sizeof(*exec2_list)*args->buffer_count,
-GFP_TEMPORARY | __GFP_NOWARN | __GFP_NORETRY);
- if (exec2_list == NULL)
- exec2_list = drm_malloc_ab(sizeof(*exec2_list),
- args->buffer_count);
+ exec2_list = drm_malloc_gfp(sizeof(*exec2_list),
+ args->buffer_count,
+ GFP_TEMPORARY);
if (exec2_list == NULL) {
DRM_DEBUG("Failed to allocate exec list for %d buffers\n",
args->buffer_count);
diff --git a/drivers/gpu/drm/i915/i915_gem_gtt.c
b/drivers/gpu/drm/i915/i915_gem_gtt.c
index 6e8c86d829d2..7820e8983136 100644
--- a/drivers/gpu/drm/i915/i915_gem_gtt.c
+++ b/drivers/gpu/drm/i915/i915_gem_gtt.c
@@ -3221,8 +3221,9 @@ intel_rotate_fb_obj_pages(struct i915_ggtt_view
*ggtt_view,
int ret = -ENOMEM;
/* Allocate a temporary list of source pages for random access. */
- page_addr_list = drm_malloc_ab(obj->base.size / PAGE_SIZE,
- sizeof(dma_addr_t));
+ page_addr_list = drm_malloc_gfp(obj->base.size / PAGE_SIZE,
+ sizeof(dma_addr_t),
+ GFP_TEMPORARY);
if (!page_addr_list)
return ERR_PTR(ret);
diff --git a/drivers/gpu/drm/i915/i915_gem_userptr.c
b/drivers/gpu/drm/i915/i915_gem_userptr.c
index afd4c2c4cc04..885605c38e7c 100644
--- a/drivers/gpu/drm/i915/i915_gem_userptr.c
+++ b/drivers/gpu/drm/i915/i915_gem_userptr.c
@@ -575,10 +575,7 @@ __i915_gem_userptr_get_pages_worker(struct work_struct
*_work)
ret = -ENOMEM;
pinned = 0;
- pvec = kmalloc(npages*sizeof(struct page *),
- GFP_TEMPORARY | __GFP_NOWARN | __GFP_NORETRY);
- if (pvec == NULL)
- pvec = drm_malloc_ab(npages, sizeof(struct page *));
+ pvec = drm_malloc_gfp(npages, sizeof(struct page *), GFP_TEMPORARY);
if (pvec != NULL) {
struct mm_struct *mm = obj->userptr.mm->mm;
@@ -715,14 +712,10 @@ i915_gem_userptr_get_pages(struct drm_i915_gem_object
*obj)
pvec = NULL;
pinned = 0;
if (obj->userptr.mm->mm == current->mm) {
- pvec = kmalloc(num_pages*sizeof(struct page *),
- GFP_TEMPORARY | __GFP_NOWARN | __GFP_NORETRY);
+ pvec = drm_malloc_gfp(num_pages, sizeof(struct page *),
GFP_TEMPORARY);
if (pvec == NULL) {
- pvec = drm_malloc_ab(num_pages, sizeof(struct page *));
- if (pvec == NULL) {
- __i915_gem_userptr_set_active(obj, false);
- return -ENOMEM;
- }
+ __i915_gem_userptr_set_active(obj, false);
+ return -ENOMEM;
}
pinned = __get_user_pages_fast(obj->userptr.ptr, num_pages,
diff --git a/include/drm/drm_mem_util.h b/include/drm/drm_mem_util.h
index e42495ad8136..741ce75a72b4 100644
--- a/i
[PATCH] drm,i915: Introduce drm_malloc_gfp()
On Thu, Oct 08, 2015 at 02:39:24PM +0100, Chris Wilson wrote:
> I have instances where I want to use drm_malloc_ab() but with a custom
> gfp mask. And with those, where I want a temporary allocation, I want to
> try a high-order kmalloc() before using a vmalloc().
>
> So refactor my usage into drm_malloc_gfp().
>
> Signed-off-by: Chris Wilson
> Cc: dri-devel at lists.freedesktop.org
> Cc: Ville Syrjälä
lgtm
Reviewed-by: Ville Syrjälä
> ---
> drivers/gpu/drm/i915/i915_gem.c| 4 +---
> drivers/gpu/drm/i915/i915_gem_execbuffer.c | 8 +++-
> drivers/gpu/drm/i915/i915_gem_gtt.c| 5 +++--
> drivers/gpu/drm/i915/i915_gem_userptr.c| 15 ---
> include/drm/drm_mem_util.h | 19 +++
> 5 files changed, 30 insertions(+), 21 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
> index fe672d4a4d73..c81127518083 100644
> --- a/drivers/gpu/drm/i915/i915_gem.c
> +++ b/drivers/gpu/drm/i915/i915_gem.c
> @@ -2346,9 +2346,7 @@ void *i915_gem_object_pin_vmap(struct
> drm_i915_gem_object *obj)
> int n;
>
> n = obj->base.size >> PAGE_SHIFT;
> - pages = kmalloc(n*sizeof(*pages), GFP_TEMPORARY | __GFP_NOWARN);
> - if (pages == NULL)
> - pages = drm_malloc_ab(n, sizeof(*pages));
> + pages = drm_malloc_gfp(n, sizeof(*pages), GFP_TEMPORARY);
> if (pages != NULL) {
> n = 0;
> for_each_sg_page(obj->pages->sgl, &sg_iter,
> obj->pages->nents, 0)
> diff --git a/drivers/gpu/drm/i915/i915_gem_execbuffer.c
> b/drivers/gpu/drm/i915/i915_gem_execbuffer.c
> index c35c9dc526e7..91fb7417efc0 100644
> --- a/drivers/gpu/drm/i915/i915_gem_execbuffer.c
> +++ b/drivers/gpu/drm/i915/i915_gem_execbuffer.c
> @@ -1730,11 +1730,9 @@ i915_gem_execbuffer2(struct drm_device *dev, void
> *data,
> return -EINVAL;
> }
>
> - exec2_list = kmalloc(sizeof(*exec2_list)*args->buffer_count,
> - GFP_TEMPORARY | __GFP_NOWARN | __GFP_NORETRY);
> - if (exec2_list == NULL)
> - exec2_list = drm_malloc_ab(sizeof(*exec2_list),
> -args->buffer_count);
> + exec2_list = drm_malloc_gfp(sizeof(*exec2_list),
> + args->buffer_count,
> + GFP_TEMPORARY);
> if (exec2_list == NULL) {
> DRM_DEBUG("Failed to allocate exec list for %d buffers\n",
> args->buffer_count);
> diff --git a/drivers/gpu/drm/i915/i915_gem_gtt.c
> b/drivers/gpu/drm/i915/i915_gem_gtt.c
> index 6e8c86d829d2..7820e8983136 100644
> --- a/drivers/gpu/drm/i915/i915_gem_gtt.c
> +++ b/drivers/gpu/drm/i915/i915_gem_gtt.c
> @@ -3221,8 +3221,9 @@ intel_rotate_fb_obj_pages(struct i915_ggtt_view
> *ggtt_view,
> int ret = -ENOMEM;
>
> /* Allocate a temporary list of source pages for random access. */
> - page_addr_list = drm_malloc_ab(obj->base.size / PAGE_SIZE,
> -sizeof(dma_addr_t));
> + page_addr_list = drm_malloc_gfp(obj->base.size / PAGE_SIZE,
> + sizeof(dma_addr_t),
> + GFP_TEMPORARY);
> if (!page_addr_list)
> return ERR_PTR(ret);
>
> diff --git a/drivers/gpu/drm/i915/i915_gem_userptr.c
> b/drivers/gpu/drm/i915/i915_gem_userptr.c
> index afd4c2c4cc04..885605c38e7c 100644
> --- a/drivers/gpu/drm/i915/i915_gem_userptr.c
> +++ b/drivers/gpu/drm/i915/i915_gem_userptr.c
> @@ -575,10 +575,7 @@ __i915_gem_userptr_get_pages_worker(struct work_struct
> *_work)
> ret = -ENOMEM;
> pinned = 0;
>
> - pvec = kmalloc(npages*sizeof(struct page *),
> -GFP_TEMPORARY | __GFP_NOWARN | __GFP_NORETRY);
> - if (pvec == NULL)
> - pvec = drm_malloc_ab(npages, sizeof(struct page *));
> + pvec = drm_malloc_gfp(npages, sizeof(struct page *), GFP_TEMPORARY);
> if (pvec != NULL) {
> struct mm_struct *mm = obj->userptr.mm->mm;
>
> @@ -715,14 +712,10 @@ i915_gem_userptr_get_pages(struct drm_i915_gem_object
> *obj)
> pvec = NULL;
> pinned = 0;
> if (obj->userptr.mm->mm == current->mm) {
> - pvec = kmalloc(num_pages*sizeof(struct page *),
> -GFP_TEMPORARY | __GFP_NOWARN | __GFP_NORETRY);
> + pvec = drm_malloc_gfp(num_pages, sizeof(struct page *),
> GFP_TEMPORARY);
> if (pvec == NULL) {
> - pvec = drm_malloc_ab(num_pages, sizeof(struct page *));
> - if (pvec == NULL) {
> - __i915_gem_userptr_set_active(obj, false);
> - return -ENOMEM;
> - }
> + __i915_gem_userptr_set_active(obj, false);
> + return -ENOME
[PATCH RESEND 1/3] drm/i915: use error path
Use goto to handle the error path to avoid duplicating the same code. In
the error path intel_dig_port is the last one to be released as it was
the first one to be allocated and ideally the error path should be the
reverse of the execution path.
Cc: Daniel Vetter
Cc: Jani Nikula
Signed-off-by: Sudip Mukherjee
---
Sent on 27/07/2015
drivers/gpu/drm/i915/intel_dp.c | 23 ++-
1 file changed, 14 insertions(+), 9 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
index 8d34ca7..18bcfbe 100644
--- a/drivers/gpu/drm/i915/intel_dp.c
+++ b/drivers/gpu/drm/i915/intel_dp.c
@@ -6168,10 +6168,8 @@ intel_dp_init(struct drm_device *dev, int output_reg,
enum port port)
return;
intel_connector = intel_connector_alloc();
- if (!intel_connector) {
- kfree(intel_dig_port);
- return;
- }
+ if (!intel_connector)
+ goto err_connector_alloc;
intel_encoder = &intel_dig_port->base;
encoder = &intel_encoder->base;
@@ -6219,11 +6217,18 @@ intel_dp_init(struct drm_device *dev, int output_reg,
enum port port)
intel_dig_port->hpd_pulse = intel_dp_hpd_pulse;
dev_priv->hotplug.irq_port[port] = intel_dig_port;
- if (!intel_dp_init_connector(intel_dig_port, intel_connector)) {
- drm_encoder_cleanup(encoder);
- kfree(intel_dig_port);
- kfree(intel_connector);
- }
+ if (!intel_dp_init_connector(intel_dig_port, intel_connector))
+ goto err_init_connector;
+
+ return;
+
+err_init_connector:
+ drm_encoder_cleanup(encoder);
+ kfree(intel_connector);
+err_connector_alloc:
+ kfree(intel_dig_port);
+
+ return;
}
void intel_dp_mst_suspend(struct drm_device *dev)
--
1.9.1
[PATCH RESEND 2/3] drm/i915: check for return value
We were not checking the return value of drm_encoder_init() which can fail. And if it fails then we will be working with an uninitialized encoder. Cc: Daniel Vetter Cc: Jani Nikula Signed-off-by: Sudip Mukherjee --- Sent on 27/07/2015 drivers/gpu/drm/i915/intel_dp.c | 6 -- 1 file changed, 4 insertions(+), 2 deletions(-) diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c index 18bcfbe..2a8b47e 100644 --- a/drivers/gpu/drm/i915/intel_dp.c +++ b/drivers/gpu/drm/i915/intel_dp.c @@ -6174,8 +6174,9 @@ intel_dp_init(struct drm_device *dev, int output_reg, enum port port) intel_encoder = &intel_dig_port->base; encoder = &intel_encoder->base; - drm_encoder_init(dev, &intel_encoder->base, &intel_dp_enc_funcs, -DRM_MODE_ENCODER_TMDS); + if (drm_encoder_init(dev, &intel_encoder->base, &intel_dp_enc_funcs, +DRM_MODE_ENCODER_TMDS)) + goto err_encoder_init; intel_encoder->compute_config = intel_dp_compute_config; intel_encoder->disable = intel_disable_dp; @@ -6224,6 +6225,7 @@ intel_dp_init(struct drm_device *dev, int output_reg, enum port port) err_init_connector: drm_encoder_cleanup(encoder); +err_encoder_init: kfree(intel_connector); err_connector_alloc: kfree(intel_dig_port); -- 1.9.1
[PATCH RESEND 3/3] drm/amdgpu: fix memory leak
If amdgpu_ib_get() fails we returned the error code but we missed
freeing ib.
Cc: "Christian König"
Cc: Jammy Zhou
Cc: Chunming Zhou
Cc: Alex Deucher
Cc: "monk.liu"
Signed-off-by: Sudip Mukherjee
---
Sent on 18/09/2015
drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c
b/drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c
index 1e14531..53d551f 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c
@@ -455,8 +455,10 @@ int amdgpu_vm_update_page_directory(struct amdgpu_device
*adev,
return -ENOMEM;
r = amdgpu_ib_get(ring, NULL, ndw * 4, ib);
- if (r)
+ if (r) {
+ kfree(ib);
return r;
+ }
ib->length_dw = 0;
/* walk over the address space and update the page directory */
--
1.9.1
[PATCH] drm: Correct arguments to list_tail_add in create blob ioctl
From: Maneet Singh From: Maneet Singh Arguments passed to list_add_tail were reversed resulting in deletion of old blob property everytime the new one is added. Signed-off-by: Maneet Singh [seanpaul tweaked commit subject a little] Signed-off-by: Sean Paul Reviewed-by: Daniel Stone --- drivers/gpu/drm/drm_crtc.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/gpu/drm/drm_crtc.c b/drivers/gpu/drm/drm_crtc.c index e600a5f..049c7b7 100644 --- a/drivers/gpu/drm/drm_crtc.c +++ b/drivers/gpu/drm/drm_crtc.c @@ -4454,7 +4454,7 @@ int drm_mode_createblob_ioctl(struct drm_device *dev, * not associated with any file_priv. */ mutex_lock(&dev->mode_config.blob_lock); out_resp->blob_id = blob->base.id; - list_add_tail(&file_priv->blobs, &blob->head_file); + list_add_tail(&blob->head_file, &file_priv->blobs); mutex_unlock(&dev->mode_config.blob_lock); return 0; -- 2.6.0.rc2.230.g3dd15c0
[PATCH] drm/nouveau: fix memory leak
On 8 October 2015 at 14:00, Sudip Mukherjee wrote: > On Thu, Oct 01, 2015 at 04:40:59PM +1000, Ben Skeggs wrote: >> On 09/25/2015 01:59 AM, Sudip Mukherjee wrote: >> > On Fri, Sep 11, 2015 at 03:00:56PM +0530, Sudip Mukherjee wrote: >> >> If pm_runtime_get_sync() we were going to "out" but we missed >> >> freeing vma. >> >> >> >> Signed-off-by: Sudip Mukherjee --- >> > Hi Ben, Another gentle ping for another patch. >> Both patches are in my tree. > > Hi Ben, > I am not seeing these in linux-next. > The nouveau tree does not merge into linux-next I'm afraid. Perhaps we should as Ben gets the chance/time. Regards, Emil
[PATCH RESEND 2/3] drm/i915: check for return value
On Thu, Oct 08, 2015 at 07:28:00PM +0530, Sudip Mukherjee wrote: > We were not checking the return value of drm_encoder_init() which can > fail. And if it fails then we will be working with an uninitialized > encoder. > > Cc: Daniel Vetter > Cc: Jani Nikula > Signed-off-by: Sudip Mukherjee Queued for -next, thanks for the patch. -Daniel > --- > > Sent on 27/07/2015 > > drivers/gpu/drm/i915/intel_dp.c | 6 -- > 1 file changed, 4 insertions(+), 2 deletions(-) > > diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c > index 18bcfbe..2a8b47e 100644 > --- a/drivers/gpu/drm/i915/intel_dp.c > +++ b/drivers/gpu/drm/i915/intel_dp.c > @@ -6174,8 +6174,9 @@ intel_dp_init(struct drm_device *dev, int output_reg, > enum port port) > intel_encoder = &intel_dig_port->base; > encoder = &intel_encoder->base; > > - drm_encoder_init(dev, &intel_encoder->base, &intel_dp_enc_funcs, > - DRM_MODE_ENCODER_TMDS); > + if (drm_encoder_init(dev, &intel_encoder->base, &intel_dp_enc_funcs, > + DRM_MODE_ENCODER_TMDS)) > + goto err_encoder_init; > > intel_encoder->compute_config = intel_dp_compute_config; > intel_encoder->disable = intel_disable_dp; > @@ -6224,6 +6225,7 @@ intel_dp_init(struct drm_device *dev, int output_reg, > enum port port) > > err_init_connector: > drm_encoder_cleanup(encoder); > +err_encoder_init: > kfree(intel_connector); > err_connector_alloc: > kfree(intel_dig_port); > -- > 1.9.1 > -- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch
[PATCH RESEND 1/3] drm/i915: use error path
On Thu, Oct 08, 2015 at 07:27:59PM +0530, Sudip Mukherjee wrote:
> Use goto to handle the error path to avoid duplicating the same code. In
> the error path intel_dig_port is the last one to be released as it was
> the first one to be allocated and ideally the error path should be the
> reverse of the execution path.
>
> Cc: Daniel Vetter
> Cc: Jani Nikula
> Signed-off-by: Sudip Mukherjee
Queued for -next, thanks for the patch.
-Daniel
> ---
>
> Sent on 27/07/2015
>
> drivers/gpu/drm/i915/intel_dp.c | 23 ++-
> 1 file changed, 14 insertions(+), 9 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
> index 8d34ca7..18bcfbe 100644
> --- a/drivers/gpu/drm/i915/intel_dp.c
> +++ b/drivers/gpu/drm/i915/intel_dp.c
> @@ -6168,10 +6168,8 @@ intel_dp_init(struct drm_device *dev, int output_reg,
> enum port port)
> return;
>
> intel_connector = intel_connector_alloc();
> - if (!intel_connector) {
> - kfree(intel_dig_port);
> - return;
> - }
> + if (!intel_connector)
> + goto err_connector_alloc;
>
> intel_encoder = &intel_dig_port->base;
> encoder = &intel_encoder->base;
> @@ -6219,11 +6217,18 @@ intel_dp_init(struct drm_device *dev, int output_reg,
> enum port port)
> intel_dig_port->hpd_pulse = intel_dp_hpd_pulse;
> dev_priv->hotplug.irq_port[port] = intel_dig_port;
>
> - if (!intel_dp_init_connector(intel_dig_port, intel_connector)) {
> - drm_encoder_cleanup(encoder);
> - kfree(intel_dig_port);
> - kfree(intel_connector);
> - }
> + if (!intel_dp_init_connector(intel_dig_port, intel_connector))
> + goto err_init_connector;
> +
> + return;
> +
> +err_init_connector:
> + drm_encoder_cleanup(encoder);
> + kfree(intel_connector);
> +err_connector_alloc:
> + kfree(intel_dig_port);
> +
> + return;
> }
>
> void intel_dp_mst_suspend(struct drm_device *dev)
> --
> 1.9.1
>
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
[Bug 105051] Radeon sets max_brightness to -1, breaking GNOME backlight control on Macbook Pro mid-2015 11,5
https://bugzilla.kernel.org/show_bug.cgi?id=105051 --- Comment #12 from Tim Sammut --- (In reply to Michel Dänzer from comment #8) > > That's an apple-gmux change, not a radeon driver change. Please reassign the > component of this bug report accordingly. Hi. I changed the component based on the output of scripts/get_maintainer.pl, but I do not appear to be able to reassign the bug. Is anyone watching this bug able to reassign it? -- You are receiving this mail because: You are watching the assignee of the bug.
[PATCH] drm: Correct arguments to list_tail_add in create blob ioctl
On Thu, 08 Oct 2015, Sean Paul wrote: > From: Maneet Singh > > From: Maneet Singh > > Arguments passed to list_add_tail were reversed resulting in deletion > of old blob property everytime the new one is added. > > Signed-off-by: Maneet Singh > [seanpaul tweaked commit subject a little] > Signed-off-by: Sean Paul > Reviewed-by: Daniel Stone Reviewed-by: Jani Nikula Fixes commit e2f5d2ea479b9b2619965d43db70939589afe43a Author: Daniel Stone Date: Fri May 22 13:34:51 2015 +0100 drm/mode: Add user blob-creation ioctl > --- > drivers/gpu/drm/drm_crtc.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/drivers/gpu/drm/drm_crtc.c b/drivers/gpu/drm/drm_crtc.c > index e600a5f..049c7b7 100644 > --- a/drivers/gpu/drm/drm_crtc.c > +++ b/drivers/gpu/drm/drm_crtc.c > @@ -4454,7 +4454,7 @@ int drm_mode_createblob_ioctl(struct drm_device *dev, >* not associated with any file_priv. */ > mutex_lock(&dev->mode_config.blob_lock); > out_resp->blob_id = blob->base.id; > - list_add_tail(&file_priv->blobs, &blob->head_file); > + list_add_tail(&blob->head_file, &file_priv->blobs); > mutex_unlock(&dev->mode_config.blob_lock); > > return 0; > -- > 2.6.0.rc2.230.g3dd15c0 > > ___ > 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
[PATCH v3 6/6] drm/radeon: Switch DDC when reading the EDID
Hi Alex, On Wed, Oct 07, 2015 at 11:14:43PM -0400, Alex Deucher wrote: > On Sat, Sep 12, 2015 at 3:44 AM, Lukas Wunner wrote: > > The pre-retina MacBook Pro uses an LVDS panel and a gmux controller > > to switch the panel between its two GPUs. The panel mode in VBIOS > > is notoriously bogus on these machines. > > > > Use drm_get_edid_switcheroo() in lieu of drm_get_edid() on LVDS. > > This allows us to retrieve the EDID if the outputs are currently > > muxed to the integrated GPU by temporarily switching the panel's > > DDC lines to the discrete GPU. > > > > This only enables EDID probing on the pre-retina MBP (2008 - 2013). > > The retina MBP (2012 - present) uses eDP and gmux is apparently not > > capable of switching AUX separately from the main link on these models. > > This will be addressed in later patches. > > > > List of pre-retina MBPs with dual GPUs, one of them AMD: > > [MBP 8,2 2011 intel SNB + amd turks pre-retina 15"] > > [MBP 8,3 2011 intel SNB + amd turks pre-retina 17"] > > > > Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=61115 > > Tested-by: William Brown > > [MBP 8,2 2011 intel SNB + amd turks pre-retina 15"] > > > > Signed-off-by: Lukas Wunner > > I'm not opposed to this series, but I have a few questions. > > 1. Has any of this been tested on non-Apple hybrid laptops to make > sure nothing has regressed? I think it would be good to verify that > since there are more of them in the wild. It hasn't been tested on such a machine because I don't have one and don't know anyone who has one. However I would be surprised if the series broke anything on non-Apple laptops since apple-gmux is the only handler declaring a ->switch_ddc callback. If that callback is not defined, the behaviour should be identical to just calling drm_get_edid(). (With the only exception that EDID reads are serialized on LVDS connectors due to the locking in vga_switcheroo. And that should be irrelevant since laptops usually have only *one* LVDS panel.) > 2. This only does the ddc switching for LVDS. Newer systems almost > certainly use DP (either eDP or DP to LVDS bridges). What about those > systems? As noted in the commit message above, the *retina* MacBook Pro uses eDP instead of LVDS and is not capable of switching AUX separately from the main link. I've gotten this to work by proxying the AUX communication via the currently active GPU, but the patches for this are still in a very experimental state. They will be submitted in a future series. The drivers will then be amended to call drm_get_edid_switcheroo() for eDP connectors, and drm_get_edid_switcheroo() will be amended by the proxying code. There will probably also be separate proxying-enabled helpers for drm_dp_dpcd_read() and _write() which the drivers need to call for eDP connectors (right now the proxying code is hacked directly into those two functions). > 3. Most muxed hybrid laptops also mux external displays connectors as > well (VGA, DVI, HDMI, DP, etc.). Do you have any plans to extend this > to those cases? As far as the MacBook Pro is concerned, only the earliest two generations support this (MacBookPro5 2008/09 with dual Nvidia GPUs and MacBookPro6 2010 with Intel/Nvidia). They have a single external switchable DP port. I was thinking about hardcoding the DMIs of these few laptops in the drivers and call drm_get_edid_switcheroo() for the DP port. But this is not a high priority item. I don't have a clear plan yet. > 4. Some desktop environments (GNOME IIRC, but possibly KDE as well) > rely on the fact that ddc doesn't work on one of the GPUs when it's > not selected. They don't know how to deal with muxes and can't deal > with the same port showing up as connected on two GPUs. I suspect > this patch set may break that. radeon has always been able to report > the panel information on hybrid laptops even when the mux is not > switched since the info is also stored in the vbios. At the behest of > those desktop environments there is actually code in the driver to not > report the edid for the unselected gpu on hybrid laptops even though > we could report it. I suspect this patch may break that. I assume you're referring to: http://lists.freedesktop.org/archives/dri-devel/2014-November/072032.html https://bugzilla.opensuse.org/show_bug.cgi?id=904417 After perusing the bug report at length I'm under the impression that it's not GNOME getting confused by two LVDS outputs, rather this seems like a runtime pm issue since radeon.runpm=0 seemed to fix it. Maybe gdm was triggering an ioctl() that didn't wake up the GPU? I've briefly looked at the code and noticed that radeon_compat_ioctl() doesn't call pm_runtime_get_sync(). Maybe the reporter of the bug had a 32 bit GNOME installed? Or maybe the GPU failed to wake up from D0 for some reason? There's no dmesg output attached to the bug report so it's impossible to tell. It's unfortunate that the actual root cause was not clearly
[Bug 105051] Radeon sets max_brightness to -1, breaking GNOME backlight control on Macbook Pro mid-2015 11,5
https://bugzilla.kernel.org/show_bug.cgi?id=105051 --- Comment #13 from Alex Deucher --- Only the original filer or an admin can change it as far as I know. -- You are receiving this mail because: You are watching the assignee of the bug.
[Intel-gfx] periodic wakeup from DPMS suspend
On Thu, Oct 08, 2015 at 12:44:09PM +0200, Johannes Stezenbach wrote: > On Wed, Oct 07, 2015 at 01:26:32PM +0200, Johannes Stezenbach wrote: > > On Tue, Oct 06, 2015 at 11:04:53PM -0400, Alex Deucher wrote: > > > On Tue, Oct 6, 2015 at 11:10 AM, Johannes Stezenbach > > > wrote: > > > > > > > > I have a NEC EA244WMi monitor connected to an Asus P8H77-V > > > > mainboard with Ivy Bridge Core i5-3550 via DVI. > > > > If DPMS suspend is enabled (by xscreensaver, or for testing by > > > > "xset dpms force off/suspend/standby"), the monitor > > > > enters standby mode but wakes up every 10...30 seconds for > > > > 6 seconds to display a "DVI-D: no signal" message. > > > > > > Some monitors periodically scan all of their inputs if they are not > > > actively being driven by anything to try and automatically switch to > > > the connected input. When the monitor scans the DVI input, it sees > > > load on the pins and turns on, only to realize it's not getting a > > > signal and then turns off. If your monitor has an option to turn off > > > input probing, that might help. > > > > It's not like I didn't try to twiddle just about every > > available menu item, and also used the monitor's > > "Reset to Factory Defaults" to no avail. > > However, while trying again I found a hidden menu item > > which is only available during the short time the > > "No Signal" message is displayed, where the left/right > > touch buttons open a "Scan Time" setting with "Normal" > > and "Slow" options. After I changed it, the issue was > > solved. I changed it back and the issue doesn't reproduce. > > So it looks some internal configuration of the monitor > > was messed up and is now fixed by twiddling the hidden > > menu item. "Scan Time" is not documented in the manual > > nor is there an indication in the "No Signal" popup. > > > > Case closed. > > And I just came back to see the monitor doing the > wakeup cycling again. To try something differerent > I unplugged the charger of the laptop sitting nearby > in suspend. Bingo! So it looks like an EMI issue. > I tried a few times and could reproduce twice and > then no more :-( Now the monitor wakes up once > every 5min or so... > > Which brings me back to a previous question: > > > maybe it is some floating signal line causing the > > monitor to misdetect activity? > > Does the Intel hardware have the capability to switch > the DVI signal lines from high-z to ground during DPMS > suspend, and if so, does the driver do the right thing? > Obviously I have no clue about DVI and intel-gfx, but > I thought to ask anyway. We have already known fun with EMI from laptop chargers: i915 hase a hotpug storm detection logic to combat badly-shielded boards. Could just be another form of that problem. Afaik there's nothing we can do in the driver about this (except trying to filter out bad noise, which we do already). -Daniel -- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch
[Bug 92214] Flightgear crashes during splashboot with R600 driver, LLVM 3.7.0 and mesa 11.0.2
https://bugs.freedesktop.org/show_bug.cgi?id=92214 Barto changed: What|Removed |Added Summary|Flightgear crashes during |Flightgear crashes during |splashboot with R600 driver |splashboot with R600 |and mesa 11.0.2 |driver, LLVM 3.7.0 and mesa ||11.0.2 -- 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/20151008/af05128e/attachment.html>
[PATCH 0/8] Add ASoC support for AMD APUs [v4]
This patch set implements support for i2s audio and new AMD GPUs. The i2s codec is fed by a DMA engine on the GPU. To handle this we create mfd cells which we hang the i2s codec and DMA engine on. Because of this, this patch set covers two subsystems: drm and alsa. The drm patches add support for the ACP hw block which provides the DMA engine for the i2s codec. The alsa patches add the ASoC driver for the i2s codec. Since the alsa changes depend on the drm changes in this patch set as well as some other drm changes queued for 4.3, I'd like to take the alsa patches in via the drm tree. V2 changes: - Use the MFD subsystem rather than adding our own bus - Squash all sub-feature patches together - fix comments mentioned in previous review V3 changes: - Update the designware driver to handle slave mode, amd specific features - Use the designware driver directly for i2s - Move the DMA handling from the GPU driver into the AMD ASoC driver - Change the license on the ASoC driver to GPL v4 changes: - patch "ASoC : dwc : support dw i2s in slave mode" accepted - Add a _dai_fmt() operation that checks to make sure that the mode we're setting corresponds to what we read back from the hardware. - Split specific quirks into separate patches - Set the specific quirks that apply to AMD chips in the acp driver Patch 7 adds the register headers for the ACP block which is a pretty big patch so I've excluded it from email. The entire patch set can be viewed here: http://cgit.freedesktop.org/~agd5f/linux/log/?h=acp-upstream5 Thanks, Alex Maruthi Bayyavarapu (1): drm/amd: add ACP driver support Maruthi Srinivas Bayyavarapu (7): ASoC : dwc : add check for master/slave format ASoC : dwc : add different playback/capture base ASoC : dwc : add quirk for dwc controller instances ASoC : dwc : add quirk for different register offset ASoC : dwc : reconfigure dwc in 'resume' from 'suspend' ASoC : AMD : add ACP 2.2 register headers ASoC: AMD: add AMD ASoC ACP-I2S driver drivers/gpu/drm/Kconfig |2 + drivers/gpu/drm/amd/acp/Kconfig | 10 + drivers/gpu/drm/amd/acp/Makefile |9 + drivers/gpu/drm/amd/acp/acp_hw.c | 127 ++ drivers/gpu/drm/amd/acp/include/acp_gfx_if.h | 49 + drivers/gpu/drm/amd/amdgpu/Makefile | 13 +- drivers/gpu/drm/amd/amdgpu/amdgpu.h | 12 + drivers/gpu/drm/amd/amdgpu/amdgpu_acp.c | 275 +++ drivers/gpu/drm/amd/amdgpu/amdgpu_acp.h | 41 + drivers/gpu/drm/amd/amdgpu/vi.c | 12 + drivers/gpu/drm/amd/include/amd_shared.h |1 + include/linux/mfd/amd_acp.h | 43 + include/sound/designware_i2s.h |6 + sound/soc/Kconfig|1 + sound/soc/Makefile |1 + sound/soc/amd/Kconfig|4 + sound/soc/amd/Makefile |3 + sound/soc/amd/acp-pcm-dma.c | 518 ++ sound/soc/amd/acp.c | 736 + sound/soc/amd/acp.h | 147 ++ sound/soc/amd/include/acp_2_2_d.h| 609 +++ sound/soc/amd/include/acp_2_2_enum.h | 1068 sound/soc/amd/include/acp_2_2_sh_mask.h | 2292 ++ sound/soc/dwc/designware_i2s.c | 206 ++- 24 files changed, 6121 insertions(+), 64 deletions(-) create mode 100644 drivers/gpu/drm/amd/acp/Kconfig create mode 100644 drivers/gpu/drm/amd/acp/Makefile create mode 100644 drivers/gpu/drm/amd/acp/acp_hw.c create mode 100644 drivers/gpu/drm/amd/acp/include/acp_gfx_if.h create mode 100644 drivers/gpu/drm/amd/amdgpu/amdgpu_acp.c create mode 100644 drivers/gpu/drm/amd/amdgpu/amdgpu_acp.h create mode 100644 include/linux/mfd/amd_acp.h create mode 100644 sound/soc/amd/Kconfig create mode 100644 sound/soc/amd/Makefile create mode 100644 sound/soc/amd/acp-pcm-dma.c create mode 100644 sound/soc/amd/acp.c create mode 100644 sound/soc/amd/acp.h create mode 100644 sound/soc/amd/include/acp_2_2_d.h create mode 100644 sound/soc/amd/include/acp_2_2_enum.h create mode 100644 sound/soc/amd/include/acp_2_2_sh_mask.h -- 1.8.3.1
[PATCH 1/8] ASoC : dwc : add check for master/slave format
From: Maruthi Srinivas Bayyavarapu
DW i2s controller's master/slave config can be read from a
read-only register. Machine driver can try to set a master/slave
format on cpu-dai using 'set_fmt' of dai ops. A check is added to
verify codec is master when dwc is slave and vice-versa.
Signed-off-by: Maruthi Bayyavarapu
---
sound/soc/dwc/designware_i2s.c | 31 +++
1 file changed, 31 insertions(+)
diff --git a/sound/soc/dwc/designware_i2s.c b/sound/soc/dwc/designware_i2s.c
index 3a52f82..f427325 100644
--- a/sound/soc/dwc/designware_i2s.c
+++ b/sound/soc/dwc/designware_i2s.c
@@ -341,12 +341,43 @@ static int dw_i2s_trigger(struct snd_pcm_substream
*substream,
return ret;
}
+static int dw_i2s_set_fmt(struct snd_soc_dai *cpu_dai, unsigned int fmt)
+{
+ struct dw_i2s_dev *dev = snd_soc_dai_get_drvdata(cpu_dai);
+ int ret = 0;
+
+ switch (fmt & SND_SOC_DAIFMT_MASTER_MASK) {
+ case SND_SOC_DAIFMT_CBM_CFM:
+ if (dev->capability & DW_I2S_SLAVE)
+ ret = 0;
+ else
+ ret = -EINVAL;
+ break;
+ case SND_SOC_DAIFMT_CBS_CFS:
+ if (dev->capability & DW_I2S_MASTER)
+ ret = 0;
+ else
+ ret = -EINVAL;
+ break;
+ case SND_SOC_DAIFMT_CBM_CFS:
+ case SND_SOC_DAIFMT_CBS_CFM:
+ ret = -EINVAL;
+ break;
+ default:
+ dev_dbg(dev->dev, "dwc : Invalid master/slave format\n");
+ ret = -EINVAL;
+ break;
+ }
+ return ret;
+}
+
static struct snd_soc_dai_ops dw_i2s_dai_ops = {
.startup= dw_i2s_startup,
.shutdown = dw_i2s_shutdown,
.hw_params = dw_i2s_hw_params,
.prepare= dw_i2s_prepare,
.trigger= dw_i2s_trigger,
+ .set_fmt= dw_i2s_set_fmt,
};
static const struct snd_soc_component_driver dw_i2s_component = {
--
1.8.3.1
[PATCH 2/8] ASoC : dwc : add different playback/capture base
From: Maruthi Srinivas Bayyavarapu
Some platforms (Ex: AMD CZ) can have separate dwc controllers with
different base address for playback and capture. This patch adds
necessary changes to support it. Platforms which make use of it can
supply a quirk in platform data to make use of this. By default,
playback and capture base addesses are assumed to be same.
Signed-off-by: Maruthi Bayyavarapu
---
sound/soc/dwc/designware_i2s.c | 93 ++
1 file changed, 48 insertions(+), 45 deletions(-)
diff --git a/sound/soc/dwc/designware_i2s.c b/sound/soc/dwc/designware_i2s.c
index f427325..374a83e 100644
--- a/sound/soc/dwc/designware_i2s.c
+++ b/sound/soc/dwc/designware_i2s.c
@@ -89,7 +89,8 @@ union dw_i2s_snd_dma_data {
};
struct dw_i2s_dev {
- void __iomem *i2s_base;
+ void __iomem *i2s_pbase;
+ void __iomem *i2s_cbase;
struct clk *clk;
int active;
unsigned int capability;
@@ -118,10 +119,10 @@ static inline void i2s_disable_channels(struct dw_i2s_dev
*dev, u32 stream)
if (stream == SNDRV_PCM_STREAM_PLAYBACK) {
for (i = 0; i < 4; i++)
- i2s_write_reg(dev->i2s_base, TER(i), 0);
+ i2s_write_reg(dev->i2s_pbase, TER(i), 0);
} else {
for (i = 0; i < 4; i++)
- i2s_write_reg(dev->i2s_base, RER(i), 0);
+ i2s_write_reg(dev->i2s_cbase, RER(i), 0);
}
}
@@ -131,25 +132,25 @@ static inline void i2s_clear_irqs(struct dw_i2s_dev *dev,
u32 stream)
if (stream == SNDRV_PCM_STREAM_PLAYBACK) {
for (i = 0; i < 4; i++)
- i2s_write_reg(dev->i2s_base, TOR(i), 0);
+ i2s_write_reg(dev->i2s_pbase, TOR(i), 0);
} else {
for (i = 0; i < 4; i++)
- i2s_write_reg(dev->i2s_base, ROR(i), 0);
+ i2s_write_reg(dev->i2s_cbase, ROR(i), 0);
}
}
static void i2s_start(struct dw_i2s_dev *dev,
struct snd_pcm_substream *substream)
{
-
- i2s_write_reg(dev->i2s_base, IER, 1);
-
- if (substream->stream == SNDRV_PCM_STREAM_PLAYBACK)
- i2s_write_reg(dev->i2s_base, ITER, 1);
- else
- i2s_write_reg(dev->i2s_base, IRER, 1);
-
- i2s_write_reg(dev->i2s_base, CER, 1);
+ if (substream->stream == SNDRV_PCM_STREAM_PLAYBACK) {
+ i2s_write_reg(dev->i2s_pbase, IER, 1);
+ i2s_write_reg(dev->i2s_pbase, ITER, 1);
+ i2s_write_reg(dev->i2s_pbase, CER, 1);
+ } else {
+ i2s_write_reg(dev->i2s_cbase, IER, 1);
+ i2s_write_reg(dev->i2s_cbase, IRER, 1);
+ i2s_write_reg(dev->i2s_cbase, CER, 1);
+ }
}
static void i2s_stop(struct dw_i2s_dev *dev,
@@ -159,24 +160,25 @@ static void i2s_stop(struct dw_i2s_dev *dev,
i2s_clear_irqs(dev, substream->stream);
if (substream->stream == SNDRV_PCM_STREAM_PLAYBACK) {
- i2s_write_reg(dev->i2s_base, ITER, 0);
-
+ i2s_write_reg(dev->i2s_pbase, ITER, 0);
for (i = 0; i < 4; i++) {
- irq = i2s_read_reg(dev->i2s_base, IMR(i));
- i2s_write_reg(dev->i2s_base, IMR(i), irq | 0x30);
+ irq = i2s_read_reg(dev->i2s_pbase, IMR(i));
+ i2s_write_reg(dev->i2s_pbase, IMR(i),
+ irq | 0x30);
}
} else {
- i2s_write_reg(dev->i2s_base, IRER, 0);
+ i2s_write_reg(dev->i2s_cbase, IRER, 0);
for (i = 0; i < 4; i++) {
- irq = i2s_read_reg(dev->i2s_base, IMR(i));
- i2s_write_reg(dev->i2s_base, IMR(i), irq | 0x03);
+ irq = i2s_read_reg(dev->i2s_cbase, IMR(i));
+ i2s_write_reg(dev->i2s_cbase, IMR(i),
+ irq | 0x03);
}
}
if (!dev->active) {
- i2s_write_reg(dev->i2s_base, CER, 0);
- i2s_write_reg(dev->i2s_base, IER, 0);
+ i2s_write_reg(dev->i2s_pbase, CER, 0);
+ i2s_write_reg(dev->i2s_pbase, IER, 0);
}
}
@@ -253,23 +255,23 @@ static int dw_i2s_hw_params(struct snd_pcm_substream
*substream,
for (ch_reg = 0; ch_reg < (config->chan_nr / 2); ch_reg++) {
if (substream->stream == SNDRV_PCM_STREAM_PLAYBACK) {
- i2s_write_reg(dev->i2s_base, TCR(ch_reg),
+ i2s_write_reg(dev->i2s_pbase, TCR(ch_reg),
xfer_resolution);
- i2s_write_reg(dev->i2s_base, TFCR(ch_reg), 0x02);
- irq = i2s_read_reg(dev->i2s_base, IMR(ch_reg));
- i2s_write_reg(dev->i2s_base, IMR(ch_reg), irq & ~0x30);
-
[PATCH 3/8] ASoC : dwc : add quirk for dwc controller instances
From: Maruthi Srinivas Bayyavarapu
Added a qurik to assign different base addresses for different
dwc controllers present on platform for playback and capture.
Signed-off-by: Maruthi Bayyavarapu
---
include/sound/designware_i2s.h | 3 +++
sound/soc/dwc/designware_i2s.c | 26 +++---
2 files changed, 26 insertions(+), 3 deletions(-)
diff --git a/include/sound/designware_i2s.h b/include/sound/designware_i2s.h
index 8966ba7..48c8210 100644
--- a/include/sound/designware_i2s.h
+++ b/include/sound/designware_i2s.h
@@ -45,6 +45,9 @@ struct i2s_platform_data {
u32 snd_fmts;
u32 snd_rates;
+ #define DW_I2S_QUIRK_MULTI_DWC (1 << 0)
+ unsigned int quirks;
+
void *play_dma_data;
void *capture_dma_data;
bool (*filter)(struct dma_chan *chan, void *slave);
diff --git a/sound/soc/dwc/designware_i2s.c b/sound/soc/dwc/designware_i2s.c
index 374a83e..fd18a0e 100644
--- a/sound/soc/dwc/designware_i2s.c
+++ b/sound/soc/dwc/designware_i2s.c
@@ -94,6 +94,7 @@ struct dw_i2s_dev {
struct clk *clk;
int active;
unsigned int capability;
+ unsigned int quirks;
struct device *dev;
/* data related to DMA transfers b/w i2s and DMAC */
@@ -176,9 +177,20 @@ static void i2s_stop(struct dw_i2s_dev *dev,
}
}
- if (!dev->active) {
- i2s_write_reg(dev->i2s_pbase, CER, 0);
- i2s_write_reg(dev->i2s_pbase, IER, 0);
+ if (dev->quirks & DW_I2S_QUIRK_MULTI_DWC) {
+ if (substream->stream == SNDRV_PCM_STREAM_PLAYBACK) {
+ i2s_write_reg(dev->i2s_pbase, CER, 0);
+ i2s_write_reg(dev->i2s_pbase, IER, 0);
+ } else {
+ i2s_write_reg(dev->i2s_cbase, CER, 0);
+ i2s_write_reg(dev->i2s_cbase, IER, 0);
+ }
+
+ } else {
+ if (!dev->active) {
+ i2s_write_reg(dev->i2s_pbase, CER, 0);
+ i2s_write_reg(dev->i2s_pbase, IER, 0);
+ }
}
}
@@ -599,6 +611,7 @@ static int dw_i2s_probe(struct platform_device *pdev)
if (pdata) {
dev->capability = pdata->cap;
+ dev->quirks = pdata->quirks;
clk_id = NULL;
ret = dw_configure_dai_by_pd(dev, dw_i2s_dai, res, pdata);
} else {
@@ -608,6 +621,13 @@ static int dw_i2s_probe(struct platform_device *pdev)
if (ret < 0)
return ret;
+ if (dev->quirks & DW_I2S_QUIRK_MULTI_DWC) {
+ res = platform_get_resource(pdev, IORESOURCE_MEM, 1);
+ dev->i2s_cbase = devm_ioremap_resource(&pdev->dev, res);
+ if (IS_ERR(dev->i2s_cbase))
+ return PTR_ERR(dev->i2s_cbase);
+ }
+
if (dev->capability & DW_I2S_MASTER) {
if (pdata) {
dev->i2s_clk_cfg = pdata->i2s_clk_cfg;
--
1.8.3.1
[PATCH 4/8] ASoC : dwc : add quirk for different register offset
From: Maruthi Srinivas Bayyavarapu
AMD CZ platform has different offsets for I2S_COMP_PARAM_* registers.
Added a quirk to support the same.
Signed-off-by: Maruthi Bayyavarapu
---
include/sound/designware_i2s.h | 5 -
sound/soc/dwc/designware_i2s.c | 17 +
2 files changed, 17 insertions(+), 5 deletions(-)
diff --git a/include/sound/designware_i2s.h b/include/sound/designware_i2s.h
index 48c8210..240ef5e 100644
--- a/include/sound/designware_i2s.h
+++ b/include/sound/designware_i2s.h
@@ -45,8 +45,11 @@ struct i2s_platform_data {
u32 snd_fmts;
u32 snd_rates;
- #define DW_I2S_QUIRK_MULTI_DWC (1 << 0)
+ #define DW_I2S_QUIRK_MULTI_DWC (1 << 0)
+ #define DW_I2S_QUIRK_COMP_REG_OFFSET(1 << 1)
unsigned int quirks;
+ unsigned int i2s_reg_comp1;
+ unsigned int i2s_reg_comp2;
void *play_dma_data;
void *capture_dma_data;
diff --git a/sound/soc/dwc/designware_i2s.c b/sound/soc/dwc/designware_i2s.c
index fd18a0e..a16b725 100644
--- a/sound/soc/dwc/designware_i2s.c
+++ b/sound/soc/dwc/designware_i2s.c
@@ -95,6 +95,8 @@ struct dw_i2s_dev {
int active;
unsigned int capability;
unsigned int quirks;
+ unsigned int i2s_reg_comp1;
+ unsigned int i2s_reg_comp2;
struct device *dev;
/* data related to DMA transfers b/w i2s and DMAC */
@@ -464,8 +466,8 @@ static int dw_configure_dai(struct dw_i2s_dev *dev,
* Read component parameter registers to extract
* the I2S block's configuration.
*/
- u32 comp1 = i2s_read_reg(dev->i2s_pbase, I2S_COMP_PARAM_1);
- u32 comp2 = i2s_read_reg(dev->i2s_pbase, I2S_COMP_PARAM_2);
+ u32 comp1 = i2s_read_reg(dev->i2s_pbase, dev->i2s_reg_comp1);
+ u32 comp2 = i2s_read_reg(dev->i2s_pbase, dev->i2s_reg_comp2);
u32 idx;
if (COMP1_TX_ENABLED(comp1)) {
@@ -508,7 +510,7 @@ static int dw_configure_dai_by_pd(struct dw_i2s_dev *dev,
struct resource *res,
const struct i2s_platform_data *pdata)
{
- u32 comp1 = i2s_read_reg(dev->i2s_pbase, I2S_COMP_PARAM_1);
+ u32 comp1 = i2s_read_reg(dev->i2s_pbase, dev->i2s_reg_comp1);
u32 idx = COMP1_APB_DATA_WIDTH(comp1);
int ret;
@@ -610,9 +612,16 @@ static int dw_i2s_probe(struct platform_device *pdev)
dev->i2s_cbase = dev->i2s_pbase;
if (pdata) {
+ clk_id = NULL;
dev->capability = pdata->cap;
dev->quirks = pdata->quirks;
- clk_id = NULL;
+ if (dev->quirks & DW_I2S_QUIRK_COMP_REG_OFFSET) {
+ dev->i2s_reg_comp1 = pdata->i2s_reg_comp1;
+ dev->i2s_reg_comp2 = pdata->i2s_reg_comp2;
+ } else {
+ dev->i2s_reg_comp1 = I2S_COMP_PARAM_1;
+ dev->i2s_reg_comp2 = I2S_COMP_PARAM_2;
+ }
ret = dw_configure_dai_by_pd(dev, dw_i2s_dai, res, pdata);
} else {
clk_id = "i2sclk";
--
1.8.3.1
[PATCH 5/8] ASoC : dwc : reconfigure dwc in 'resume' from 'suspend'
From: Maruthi Srinivas Bayyavarapu
dwc IP can be powered off during system suspend in some platforms
(Ex: AMD CZ) as per design. After system is resumed, dwc needs to be
programmed again to continue audio use case.
Signed-off-by: Maruthi Bayyavarapu
---
sound/soc/dwc/designware_i2s.c | 71 ++
1 file changed, 44 insertions(+), 27 deletions(-)
diff --git a/sound/soc/dwc/designware_i2s.c b/sound/soc/dwc/designware_i2s.c
index a16b725..f7f38cb 100644
--- a/sound/soc/dwc/designware_i2s.c
+++ b/sound/soc/dwc/designware_i2s.c
@@ -98,6 +98,8 @@ struct dw_i2s_dev {
unsigned int i2s_reg_comp1;
unsigned int i2s_reg_comp2;
struct device *dev;
+ u32 ccr;
+ u32 xfer_resolution;
/* data related to DMA transfers b/w i2s and DMAC */
union dw_i2s_snd_dma_data play_dma_data;
@@ -220,31 +222,58 @@ static int dw_i2s_startup(struct snd_pcm_substream
*substream,
return 0;
}
+static void dw_i2s_config(struct dw_i2s_dev *dev, int stream)
+{
+ u32 ch_reg, irq;
+ struct i2s_clk_config_data *config = &dev->config;
+
+
+ i2s_disable_channels(dev, stream);
+
+ for (ch_reg = 0; ch_reg < (config->chan_nr / 2); ch_reg++) {
+ if (stream == SNDRV_PCM_STREAM_PLAYBACK) {
+ i2s_write_reg(dev->i2s_pbase, TCR(ch_reg),
+ dev->xfer_resolution);
+ i2s_write_reg(dev->i2s_pbase, TFCR(ch_reg), 0x02);
+ irq = i2s_read_reg(dev->i2s_pbase, IMR(ch_reg));
+ i2s_write_reg(dev->i2s_pbase, IMR(ch_reg), irq & ~0x30);
+ i2s_write_reg(dev->i2s_pbase, TER(ch_reg), 1);
+ } else {
+ i2s_write_reg(dev->i2s_cbase, RCR(ch_reg),
+ dev->xfer_resolution);
+ i2s_write_reg(dev->i2s_cbase, RFCR(ch_reg), 0x07);
+ irq = i2s_read_reg(dev->i2s_cbase, IMR(ch_reg));
+ i2s_write_reg(dev->i2s_cbase, IMR(ch_reg), irq & ~0x03);
+ i2s_write_reg(dev->i2s_cbase, RER(ch_reg), 1);
+ }
+
+ }
+}
+
static int dw_i2s_hw_params(struct snd_pcm_substream *substream,
struct snd_pcm_hw_params *params, struct snd_soc_dai *dai)
{
struct dw_i2s_dev *dev = snd_soc_dai_get_drvdata(dai);
struct i2s_clk_config_data *config = &dev->config;
- u32 ccr, xfer_resolution, ch_reg, irq;
int ret;
switch (params_format(params)) {
case SNDRV_PCM_FORMAT_S16_LE:
config->data_width = 16;
- ccr = 0x00;
- xfer_resolution = 0x02;
+ dev->ccr = 0x00;
+ dev->xfer_resolution = 0x02;
break;
case SNDRV_PCM_FORMAT_S24_LE:
config->data_width = 24;
- ccr = 0x08;
- xfer_resolution = 0x04;
+ dev->ccr = 0x08;
+ dev->xfer_resolution = 0x04;
break;
case SNDRV_PCM_FORMAT_S32_LE:
config->data_width = 32;
- ccr = 0x10;
- xfer_resolution = 0x05;
+ dev->ccr = 0x10;
+ dev->xfer_resolution = 0x05;
break;
default:
@@ -265,27 +294,9 @@ static int dw_i2s_hw_params(struct snd_pcm_substream
*substream,
return -EINVAL;
}
- i2s_disable_channels(dev, substream->stream);
-
- for (ch_reg = 0; ch_reg < (config->chan_nr / 2); ch_reg++) {
- if (substream->stream == SNDRV_PCM_STREAM_PLAYBACK) {
- i2s_write_reg(dev->i2s_pbase, TCR(ch_reg),
- xfer_resolution);
- i2s_write_reg(dev->i2s_pbase, TFCR(ch_reg), 0x02);
- irq = i2s_read_reg(dev->i2s_pbase, IMR(ch_reg));
- i2s_write_reg(dev->i2s_pbase, IMR(ch_reg), irq & ~0x30);
- i2s_write_reg(dev->i2s_pbase, TER(ch_reg), 1);
- } else {
- i2s_write_reg(dev->i2s_cbase, RCR(ch_reg),
- xfer_resolution);
- i2s_write_reg(dev->i2s_cbase, RFCR(ch_reg), 0x07);
- irq = i2s_read_reg(dev->i2s_cbase, IMR(ch_reg));
- i2s_write_reg(dev->i2s_cbase, IMR(ch_reg), irq & ~0x03);
- i2s_write_reg(dev->i2s_cbase, RER(ch_reg), 1);
- }
- }
+ i2s_write_reg(dev->i2s_pbase, CCR, dev->ccr);
- i2s_write_reg(dev->i2s_pbase, CCR, ccr);
+ dw_i2s_config(dev, substream->stream);
config->sample_rate = params_rate(params);
@@ -417,6 +428,12 @@ static int dw_i2s_resume(struct snd_soc_dai *dai)
if (dev->capability & DW_I2S_MASTER)
clk_enable(dev->clk);
+
+ if (dai->playback_active)
+ dw_i2s_conf
[PATCH 6/8] drm/amd: add ACP driver support
From: Maruthi Bayyavarapu
This adds the ACP (Audio CoProcessor) IP driver and wires
it up to the amdgpu driver. The ACP block provides the DMA
engine for i2s based ALSA driver. This is required for audio
on APUs that utilize an i2s codec.
Reviewed-by: Jammy Zhou
Reviewed-by: Maruthi Bayyavarapu
Reviewed-by: Alex Deucher
Reviewed-by: Murali Krishna Vemuri
Signed-off-by: Maruthi Bayyavarapu
Signed-off-by: Chunming Zhou
Signed-off-by: Alex Deucher
---
v2: integrate i2s/az check patch
v3: s/amd_acp/amdgpu_acp/
v4: update copyright notice
v5: squash multiple patches, convert to mfd
v6: major changes as below :
1. Pass ACP register base to DMA and dw i2s drivers
as IORESOURCE_MEM resources.
2. add dw i2s as a new mfd cell.
v7: specify broken out dw quirks that apply to AMD hardware
drivers/gpu/drm/Kconfig | 2 +
drivers/gpu/drm/amd/acp/Kconfig | 10 +
drivers/gpu/drm/amd/acp/Makefile | 9 +
drivers/gpu/drm/amd/acp/acp_hw.c | 127 +
drivers/gpu/drm/amd/acp/include/acp_gfx_if.h | 49 +
drivers/gpu/drm/amd/amdgpu/Makefile | 13 +-
drivers/gpu/drm/amd/amdgpu/amdgpu.h | 12 ++
drivers/gpu/drm/amd/amdgpu/amdgpu_acp.c | 275 +++
drivers/gpu/drm/amd/amdgpu/amdgpu_acp.h | 41
drivers/gpu/drm/amd/amdgpu/vi.c | 12 ++
drivers/gpu/drm/amd/include/amd_shared.h | 1 +
include/linux/mfd/amd_acp.h | 43 +
12 files changed, 593 insertions(+), 1 deletion(-)
create mode 100644 drivers/gpu/drm/amd/acp/Kconfig
create mode 100644 drivers/gpu/drm/amd/acp/Makefile
create mode 100644 drivers/gpu/drm/amd/acp/acp_hw.c
create mode 100644 drivers/gpu/drm/amd/acp/include/acp_gfx_if.h
create mode 100644 drivers/gpu/drm/amd/amdgpu/amdgpu_acp.c
create mode 100644 drivers/gpu/drm/amd/amdgpu/amdgpu_acp.h
create mode 100644 include/linux/mfd/amd_acp.h
diff --git a/drivers/gpu/drm/Kconfig b/drivers/gpu/drm/Kconfig
index 1a0a8df..330e9fb 100644
--- a/drivers/gpu/drm/Kconfig
+++ b/drivers/gpu/drm/Kconfig
@@ -161,6 +161,8 @@ config DRM_AMDGPU
source "drivers/gpu/drm/amd/amdgpu/Kconfig"
+source "drivers/gpu/drm/amd/acp/Kconfig"
+
source "drivers/gpu/drm/nouveau/Kconfig"
config DRM_I810
diff --git a/drivers/gpu/drm/amd/acp/Kconfig b/drivers/gpu/drm/amd/acp/Kconfig
new file mode 100644
index 000..1de4fe7
--- /dev/null
+++ b/drivers/gpu/drm/amd/acp/Kconfig
@@ -0,0 +1,10 @@
+menu "ACP Configuration"
+
+config DRM_AMD_ACP
+ bool "Enable ACP IP support"
+ default y
+ depends on MFD_CORE
+ help
+ Choose this option to enable ACP IP support for AMD SOCs.
+
+endmenu
diff --git a/drivers/gpu/drm/amd/acp/Makefile b/drivers/gpu/drm/amd/acp/Makefile
new file mode 100644
index 000..c8c3303
--- /dev/null
+++ b/drivers/gpu/drm/amd/acp/Makefile
@@ -0,0 +1,9 @@
+#
+# Makefile for the ACP, which is a sub-component
+# of AMDSOC/AMDGPU drm driver.
+# It provides the HW control for ACP related functionalities.
+
+ccflags-y += -Idrivers/gpu/drm/amd/include/asic_reg/acp
+subdir-ccflags-y += -I$(AMDACPPATH)/ -I$(AMDACPPATH)/include
+
+AMD_ACP_FILES := $(AMDACPPATH)/acp_hw.o
diff --git a/drivers/gpu/drm/amd/acp/acp_hw.c b/drivers/gpu/drm/amd/acp/acp_hw.c
new file mode 100644
index 000..55220c3
--- /dev/null
+++ b/drivers/gpu/drm/amd/acp/acp_hw.c
@@ -0,0 +1,127 @@
+/*
+ * Copyright 2015 Advanced Micro Devices, Inc.
+ *
+ * Permission is hereby granted, free of charge, to any person obtaining a
+ * copy of this software and associated documentation files (the "Software"),
+ * to deal in the Software without restriction, including without limitation
+ * the rights to use, copy, modify, merge, publish, distribute, sublicense,
+ * and/or sell copies of the Software, and to permit persons to whom the
+ * Software is furnished to do so, subject to the following conditions:
+ *
+ * The above copyright notice and this permission notice shall be included in
+ * all copies or substantial portions of the Software.
+ *
+ * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
+ * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
+ * FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL
+ * THE COPYRIGHT HOLDER(S) OR AUTHOR(S) BE LIABLE FOR ANY CLAIM, DAMAGES OR
+ * OTHER LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE,
+ * ARISING FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR
+ * OTHER DEALINGS IN THE SOFTWARE.
+ *
+ */
+
+#include
+#include
+#include
+#include
+#include
+
+#include "acp_gfx_if.h"
+
+#define ACP_MODE_I2S 0
+#define ACP_MODE_AZ1
+
+#define VISLANDS30_IV_SRCID_ACP 0x00a2
+#define mmACP_AZALIA_I2S_SELECT 0x51d4
+
+static int irq_set_source(void *private_data, unsigned src_id, unsigned type,
+ int enabled)
+{
+ struct acp_irq_prv *idata = pri
[PATCH 8/8] ASoC: AMD: add AMD ASoC ACP-I2S driver
From: Maruthi Srinivas Bayyavarapu
ACP IP block consists of dedicated DMA and I2S blocks. The PCM driver
provides the platform DMA component to ALSA core.
Signed-off-by: Maruthi Bayyavarapu
Reviewed-by: Alex Deucher
Reviewed-by: Murali Krishna Vemuri
---
v2: squash in Kconfig fix
v3: squash additional commits, convert to mfd, drop rt286 changes
v4: add major changes as below:
1. remove i2s specific changes and add them to dwc i2s driver.
2. add ACP DMA logic to PCM driver.
sound/soc/Kconfig | 1 +
sound/soc/Makefile | 1 +
sound/soc/amd/Kconfig | 4 +
sound/soc/amd/Makefile | 3 +
sound/soc/amd/acp-pcm-dma.c | 518 +++
sound/soc/amd/acp.c | 736
sound/soc/amd/acp.h | 147 +
7 files changed, 1410 insertions(+)
create mode 100644 sound/soc/amd/Kconfig
create mode 100644 sound/soc/amd/Makefile
create mode 100644 sound/soc/amd/acp-pcm-dma.c
create mode 100644 sound/soc/amd/acp.c
create mode 100644 sound/soc/amd/acp.h
diff --git a/sound/soc/Kconfig b/sound/soc/Kconfig
index 225bfda..a278840 100644
--- a/sound/soc/Kconfig
+++ b/sound/soc/Kconfig
@@ -35,6 +35,7 @@ config SND_SOC_TOPOLOGY
# All the supported SoCs
source "sound/soc/adi/Kconfig"
+source "sound/soc/amd/Kconfig"
source "sound/soc/atmel/Kconfig"
source "sound/soc/au1x/Kconfig"
source "sound/soc/bcm/Kconfig"
diff --git a/sound/soc/Makefile b/sound/soc/Makefile
index 134aca1..5927544 100644
--- a/sound/soc/Makefile
+++ b/sound/soc/Makefile
@@ -17,6 +17,7 @@ obj-$(CONFIG_SND_SOC) += snd-soc-core.o
obj-$(CONFIG_SND_SOC) += codecs/
obj-$(CONFIG_SND_SOC) += generic/
obj-$(CONFIG_SND_SOC) += adi/
+obj-$(CONFIG_SND_SOC) += amd/
obj-$(CONFIG_SND_SOC) += atmel/
obj-$(CONFIG_SND_SOC) += au1x/
obj-$(CONFIG_SND_SOC) += bcm/
diff --git a/sound/soc/amd/Kconfig b/sound/soc/amd/Kconfig
new file mode 100644
index 000..78187eb
--- /dev/null
+++ b/sound/soc/amd/Kconfig
@@ -0,0 +1,4 @@
+config SND_SOC_AMD_ACP
+ tristate "AMD Audio Coprocessor support"
+ help
+This option enables ACP DMA support on AMD platform.
diff --git a/sound/soc/amd/Makefile b/sound/soc/amd/Makefile
new file mode 100644
index 000..62648cb
--- /dev/null
+++ b/sound/soc/amd/Makefile
@@ -0,0 +1,3 @@
+snd-soc-acp-pcm-objs := acp-pcm-dma.o acp.o
+
+obj-$(CONFIG_SND_SOC_AMD_ACP) += snd-soc-acp-pcm.o
diff --git a/sound/soc/amd/acp-pcm-dma.c b/sound/soc/amd/acp-pcm-dma.c
new file mode 100644
index 000..5044188
--- /dev/null
+++ b/sound/soc/amd/acp-pcm-dma.c
@@ -0,0 +1,518 @@
+/*
+ * AMD ALSA SoC PCM Driver
+ *
+ * Copyright 2014-2015 Advanced Micro Devices, Inc.
+ *
+ * This program is free software; you can redistribute it and/or modify it
+ * under the terms and conditions of the GNU General Public License,
+ * version 2, as published by the Free Software Foundation.
+ *
+ * This program is distributed in the hope it will be useful, but WITHOUT
+ * ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or
+ * FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License for
+ * more details.
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+#include
+#include
+#include
+
+#include "acp.h"
+
+#define PLAYBACK_MIN_NUM_PERIODS2
+#define PLAYBACK_MAX_NUM_PERIODS2
+#define PLAYBACK_MAX_PERIOD_SIZE16384
+#define PLAYBACK_MIN_PERIOD_SIZE1024
+#define CAPTURE_MIN_NUM_PERIODS 2
+#define CAPTURE_MAX_NUM_PERIODS 2
+#define CAPTURE_MAX_PERIOD_SIZE 16384
+#define CAPTURE_MIN_PERIOD_SIZE 1024
+
+#define NUM_DSCRS_PER_CHANNEL 2
+
+#define MAX_BUFFER (PLAYBACK_MAX_PERIOD_SIZE * PLAYBACK_MAX_NUM_PERIODS)
+#define MIN_BUFFER MAX_BUFFER
+
+static const struct snd_pcm_hardware acp_pcm_hardware_playback = {
+ .info = SNDRV_PCM_INFO_INTERLEAVED |
+ SNDRV_PCM_INFO_BLOCK_TRANSFER | SNDRV_PCM_INFO_MMAP |
+ SNDRV_PCM_INFO_MMAP_VALID | SNDRV_PCM_INFO_BATCH |
+ SNDRV_PCM_INFO_PAUSE | SNDRV_PCM_INFO_RESUME,
+ .formats = SNDRV_PCM_FMTBIT_S16_LE |
+ SNDRV_PCM_FMTBIT_S24_LE | SNDRV_PCM_FMTBIT_S32_LE,
+ .channels_min = 1,
+ .channels_max = 8,
+ .rates = SNDRV_PCM_RATE_8000_96000,
+ .rate_min = 8000,
+ .rate_max = 96000,
+ .buffer_bytes_max = PLAYBACK_MAX_NUM_PERIODS * PLAYBACK_MAX_PERIOD_SIZE,
+ .period_bytes_min = PLAYBACK_MIN_PERIOD_SIZE,
+ .period_bytes_max = PLAYBACK_MAX_PERIOD_SIZE,
+ .periods_min = PLAYBACK_MIN_NUM_PERIODS,
+ .periods_max = PLAYBACK_MAX_NUM_PERIODS,
+};
+
+static const struct snd_pcm_hardware acp_pcm_hardware_capture = {
+ .info = SNDRV_PCM_INFO_INTERLEAVED |
+ SNDRV_PCM_INFO_BLOCK_TRANSFER | SNDRV_PCM_INFO_MMAP |
+ SNDRV_PCM_INFO_MMAP_VALID | SNDRV_PCM_INFO_BATCH |
+ SNDRV_PCM_INFO_PAUSE | SNDRV_PCM_INFO_RE
[PATCH RESEND 3/3] drm/amdgpu: fix memory leak
On Thu, Oct 8, 2015 at 9:58 AM, Sudip Mukherjee
wrote:
> If amdgpu_ib_get() fails we returned the error code but we missed
> freeing ib.
>
> Cc: "Christian König"
> Cc: Jammy Zhou
> Cc: Chunming Zhou
> Cc: Alex Deucher
> Cc: "monk.liu"
> Signed-off-by: Sudip Mukherjee
> ---
>
> Sent on 18/09/2015
I somehow missed this before. Applied. Thanks!
Alex
>
> drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c | 4 +++-
> 1 file changed, 3 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c
> b/drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c
> index 1e14531..53d551f 100644
> --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c
> +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c
> @@ -455,8 +455,10 @@ int amdgpu_vm_update_page_directory(struct amdgpu_device
> *adev,
> return -ENOMEM;
>
> r = amdgpu_ib_get(ring, NULL, ndw * 4, ib);
> - if (r)
> + if (r) {
> + kfree(ib);
> return r;
> + }
> ib->length_dw = 0;
>
> /* walk over the address space and update the page directory */
> --
> 1.9.1
>
> ___
> dri-devel mailing list
> dri-devel at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 1/3] drm/edid: Fix up clock for CEA/HDMI modes specified via detailed timings
On Thu, 2015-10-08 at 11:43 +0300, ville.syrjala at linux.intel.com wrote: > From: Ville Syrjälä > > EDID detailed timings have a resolution of 10kHz for the pixel clock, so > they can't represent certain CEA/HDMI modes accurately. If we see a mode > coming in via detailed timings which otherwise matches one of the > CEA/HDMI modes except the clock is just a bit off, let's assume that the > intention was for that mode to be one of the CEA/HDMI modes and go ahead > and fix up the clock to match the CEA/HDMI spec exactly (well, as close > as we can get with the 1 kHz resolution we use). > > This should help code that's looking for an exact clock match (eg. i915 > audio N/CTS setup). Looks like a sane set of changes. Series is: Reviewed-by: Adam Jackson - ajax
[Bug 91865] [r600g] GPU hang in 'gsraytrace' - NI/Turks (6670)
https://bugs.freedesktop.org/show_bug.cgi?id=91865 --- Comment #5 from Barto --- same bug with an amd radeon HD4650 pcie and r600 driver, archlinux 64 bits, OpenGL renderer string: Gallium 0.4 on AMD RV730 (DRM 2.43.0, LLVM 3.6.2) OpenGL core profile version string: 3.3 (Core Profile) Mesa 11.0.2 OpenGL core profile shading language version string: 3.30 OpenGL version string: 3.0 Mesa 11.0.2 OpenGL shading language version string: 1.30 OpenGL ES profile version string: OpenGL ES 3.0 Mesa 11.0.2 OpenGL ES profile shading language version string: OpenGL ES GLSL ES 3.00 -- 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/20151008/731b04c3/attachment.html>
[PATCH v3 1/2] of: Add vendor prefix for QiaoDian Xianshi
On Thu, Oct 8, 2015 at 10:42 AM, Alexandre Belloni wrote: > Use "qiaodian" as the vendor prefix for QiaoDian Xianshi Corporation in > device tree compatible strings. > > Signed-off-by: Alexandre Belloni Acked-by: Rob Herring > --- > > Changes in v3: > -use qiaodian as the vendor prefix as preferred by Rob Herring > > Documentation/devicetree/bindings/vendor-prefixes.txt | 1 + > 1 file changed, 1 insertion(+) > > diff --git a/Documentation/devicetree/bindings/vendor-prefixes.txt > b/Documentation/devicetree/bindings/vendor-prefixes.txt > index ac5f0c34ae00..d6402753fd9f 100644 > --- a/Documentation/devicetree/bindings/vendor-prefixes.txt > +++ b/Documentation/devicetree/bindings/vendor-prefixes.txt > @@ -174,6 +174,7 @@ qca Qualcomm Atheros, Inc. > qcom Qualcomm Technologies, Inc > qemu QEMU, a generic and open source machine emulator and virtualizer > qi Qi Hardware > +qiaodian QiaoDian XianShi Corporation > qnap QNAP Systems, Inc. > radxa Radxa > raidsonic RaidSonic Technology GmbH > -- > 2.1.4 >
[Intel-gfx] [PATCH 1/3] drm/edid: Fix up clock for CEA/HDMI modes specified via detailed timings
On Thu, Oct 08, 2015 at 12:22:31PM -0400, Adam Jackson wrote: > On Thu, 2015-10-08 at 11:43 +0300, ville.syrjala at linux.intel.com wrote: > > From: Ville Syrjälä > > > > EDID detailed timings have a resolution of 10kHz for the pixel clock, so > > they can't represent certain CEA/HDMI modes accurately. If we see a mode > > coming in via detailed timings which otherwise matches one of the > > CEA/HDMI modes except the clock is just a bit off, let's assume that the > > intention was for that mode to be one of the CEA/HDMI modes and go ahead > > and fix up the clock to match the CEA/HDMI spec exactly (well, as close > > as we can get with the 1 kHz resolution we use). > > > > This should help code that's looking for an exact clock match (eg. i915 > > audio N/CTS setup). > > Looks like a sane set of changes. Series is: > > Reviewed-by: Adam Jackson Merged the first two patches to drm-misc (the later one has conflicts with the lack of drm-intel-next, so can pull it in only after a rebase). Thanks, Daniel -- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch
[Bug 92203] No longer rendering fine details and some terrain in Age of Wonders 3 on Radeon HD 7750.
https://bugs.freedesktop.org/show_bug.cgi?id=92203 --- Comment #4 from Kyle Siefring --- The issue seems to be fixed now that the fix for bug 92122 has landed. Sorry that I wasn't able to bisect or apply a patch. Didn't want to figure out how to do it. -- 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/20151008/a7eece0b/attachment.html>
[PATCH 00/11] Mixed bag of ioctl and agp cleanups
On Tue, Sep 08, 2015 at 02:58:52PM +0200, Christian König wrote: > Patches #1, #6, #7, #8 and #10 are Reviewed-by: Christian König > . > > That should be everything touching radeon/amdgpu if I missed something leave > me a note. Ok with an irc r-b from Chris and David I and yours here I pulled in the remaining patches from this series. Thanks, Daniel > > Regards, > Christian. > > On 08.09.2015 13:56, Daniel Vetter wrote: > >Hi all, > > > >Big thing for sure is deprecating DRM_UNLOCKED for DRIVER_MODESET (i.e. > >modern > >drivers) since all of them have their own locking. Besides that a few random > >things that kind where in the same area/files. > > > >Of course kerneldoc is updated too. > > > >Feedback highly welcome. > > > >Cheers, Daniel > > > >Daniel Vetter (11): > > drm: Remove __OS_HAS_AGP > > drm/i915: Kill cross-module option depencies > > drm/i915: Mark debug mod options as _unsafe > > drm/i915: Remove setparam ioctl > > drm/i915: Mark getparam ioctl as DRM_UNLOCKED > > drm: Define a drm_invalid_op ioctl implementation > > drm/drm_ioctl.c: kerneldoc > > drm: Enforce unlocked ioctl operation for kms driver ioctls > > drm/vmwgfx: Stop checking for DRM_UNLOCKED > > drm/: Drop DRM_UNLOCKED from modeset drivers > > drm: Remove dummy agp ioctl wrappers > > > > Documentation/DocBook/drm.tmpl | 5 +- > > drivers/gpu/drm/Makefile| 3 +- > > drivers/gpu/drm/amd/amdgpu/amdgpu_kms.c | 24 +++ > > drivers/gpu/drm/armada/armada_drv.c | 9 +-- > > drivers/gpu/drm/drm_agpsupport.c| 4 +- > > drivers/gpu/drm/drm_bufs.c | 6 +- > > drivers/gpu/drm/drm_ioc32.c | 6 +- > > drivers/gpu/drm/drm_ioctl.c | 89 +-- > > drivers/gpu/drm/drm_memory.c| 6 +- > > drivers/gpu/drm/drm_vm.c| 8 +-- > > drivers/gpu/drm/exynos/exynos_drm_drv.c | 20 +++--- > > drivers/gpu/drm/i915/i915_dma.c | 101 ++ > > drivers/gpu/drm/i915/i915_gem_gtt.c | 2 +- > > drivers/gpu/drm/i915/i915_params.c | 30 > > drivers/gpu/drm/i915/intel_lrc.c| 3 +- > > drivers/gpu/drm/mga/mga_dma.c | 4 +- > > drivers/gpu/drm/msm/msm_drv.c | 14 ++-- > > drivers/gpu/drm/nouveau/nouveau_bo.c| 8 +-- > > drivers/gpu/drm/nouveau/nouveau_drm.c | 24 +++ > > drivers/gpu/drm/omapdrm/omap_drv.c | 12 ++-- > > drivers/gpu/drm/qxl/qxl_ioctl.c | 14 ++-- > > drivers/gpu/drm/r128/r128_cce.c | 12 ++-- > > drivers/gpu/drm/radeon/r600_cp.c| 14 ++-- > > drivers/gpu/drm/radeon/radeon_agp.c | 8 +-- > > drivers/gpu/drm/radeon/radeon_cp.c | 16 ++--- > > drivers/gpu/drm/radeon/radeon_kms.c | 124 > > +++- > > drivers/gpu/drm/radeon/radeon_ttm.c | 10 +-- > > drivers/gpu/drm/tegra/drm.c | 28 > > drivers/gpu/drm/vmwgfx/vmwgfx_drv.c | 62 +++- > > include/drm/drmP.h | 2 + > > include/drm/drm_agpsupport.h| 54 +- > > 31 files changed, 321 insertions(+), 401 deletions(-) > > > -- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch
[Bug 92203] No longer rendering fine details and some terrain in Age of Wonders 3 on Radeon HD 7750.
https://bugs.freedesktop.org/show_bug.cgi?id=92203 Alex Deucher changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |DUPLICATE --- Comment #5 from Alex Deucher --- *** This bug has been marked as a duplicate of bug 92122 *** -- 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/20151008/dd4e2fcb/attachment.html>
[pull] radeon and amdgpu drm-fixes-4.3
Hi Dave, radeon and amdgpu fixes for 4.3. Highlights: - Move pm sysfs setup later in the driver init process to avoid problems with laptop scripts attempting to change pm settings before the driver has finished setting up the pm hardware. - Fix console restore if a drm app (e.g. X) is forcibly killed - Flag iceland support as experimental for now - Misc bug fixes The following changes since commit ccf03d6995fa4b784f5b987726ba98f4859bf326: drm/dp/mst: add some defines for logical/physical ports (2015-10-02 15:34:42 +1000) are available in the git repository at: git://people.freedesktop.org/~agd5f/linux drm-fixes-4.3 for you to fetch changes up to 7a574557e62dc3d2d7ed55fa0b99e7d5bb403878: drm/amdgpu: fix memory leak in amdgpu_vm_update_page_directory (2015-10-08 12:18:23 -0400) Alex Deucher (8): drm/radeon: add pm sysfs files late drm/amdgpu: add pm sysfs files late drm/radeon: add quirk for ASUS R7 370 drm/radeon: restore the fbdev mode in lastclose drm/amdgpu: restore the fbdev mode in lastclose drm/amdgpu: fix num_crtc on CZ drm/amdgpu: check before checking pci bridge registers drm/amdgpu: flag iceland as experimental Arnd Bergmann (1): drm/amdgpu: fix 32-bit compiler warning Sudip Mukherjee (1): drm/amdgpu: fix memory leak in amdgpu_vm_update_page_directory drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c | 6 +-- drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c | 10 ++--- drivers/gpu/drm/amd/amdgpu/amdgpu_fb.c | 16 drivers/gpu/drm/amd/amdgpu/amdgpu_kms.c | 5 ++- drivers/gpu/drm/amd/amdgpu/amdgpu_mode.h | 1 + drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c | 4 +- drivers/gpu/drm/amd/amdgpu/ci_dpm.c | 8 ++-- drivers/gpu/drm/amd/amdgpu/cik.c | 3 ++ drivers/gpu/drm/amd/amdgpu/cz_dpm.c | 10 +++-- drivers/gpu/drm/amd/amdgpu/dce_v11_0.c | 2 +- drivers/gpu/drm/amd/amdgpu/kv_dpm.c | 9 +++-- drivers/gpu/drm/amd/amdgpu/vi.c | 3 ++ drivers/gpu/drm/radeon/radeon_display.c | 14 +-- drivers/gpu/drm/radeon/radeon_fb.c | 16 drivers/gpu/drm/radeon/radeon_kms.c | 5 ++- drivers/gpu/drm/radeon/radeon_mode.h | 1 + drivers/gpu/drm/radeon/radeon_pm.c | 63 +++- drivers/gpu/drm/radeon/si_dpm.c | 1 + 18 files changed, 118 insertions(+), 59 deletions(-)
[Bug 92266] Unigine Valley benchmark hangs up in scene 9 with 3840x2160 resolution on R390X, while lower resolutions work
https://bugs.freedesktop.org/show_bug.cgi?id=92266 MC Return changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |WORKSFORME --- Comment #3 from MC Return --- A upgrade to X.Org X Server 1.17.1 fully fixed the problem for me. -- 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/20151008/9aa1620d/attachment.html>
[PATCH] drm/amdgpu: rework sdma structures
Rework the sdma structures in the driver to
consolidate all of the sdma info into a single
structure and allow for asics that may have
different numbers of sdma instances.
Signed-off-by: Alex Deucher
---
drivers/gpu/drm/amd/amdgpu/amdgpu.h | 22 +--
drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd_gfx_v7.c | 4 +-
drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd_gfx_v8.c | 4 +-
drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c| 7 +-
drivers/gpu/drm/amd/amdgpu/amdgpu_kms.c | 10 +-
drivers/gpu/drm/amd/amdgpu/amdgpu_ring.c | 4 +-
drivers/gpu/drm/amd/amdgpu/cik_sdma.c | 130 -
drivers/gpu/drm/amd/amdgpu/sdma_v2_4.c| 156 ++--
drivers/gpu/drm/amd/amdgpu/sdma_v3_0.c| 166 +++---
9 files changed, 245 insertions(+), 258 deletions(-)
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu.h
b/drivers/gpu/drm/amd/amdgpu/amdgpu.h
index 6647fb2..afc9848 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu.h
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu.h
@@ -1708,7 +1708,7 @@ struct amdgpu_vce {
/*
* SDMA
*/
-struct amdgpu_sdma {
+struct amdgpu_sdma_instance {
/* SDMA firmware */
const struct firmware *fw;
uint32_tfw_version;
@@ -1718,6 +1718,13 @@ struct amdgpu_sdma {
boolburst_nop;
};
+struct amdgpu_sdma {
+ struct amdgpu_sdma_instance instance[AMDGPU_MAX_SDMA_INSTANCES];
+ struct amdgpu_irq_src trap_irq;
+ struct amdgpu_irq_src illegal_inst_irq;
+ int num_instances;
+};
+
/*
* Firmware
*/
@@ -2064,9 +2071,7 @@ struct amdgpu_device {
struct amdgpu_gfx gfx;
/* sdma */
- struct amdgpu_sdma sdma[AMDGPU_MAX_SDMA_INSTANCES];
- struct amdgpu_irq_src sdma_trap_irq;
- struct amdgpu_irq_src sdma_illegal_inst_irq;
+ struct amdgpu_sdma sdma;
/* uvd */
boolhas_uvd;
@@ -2203,17 +2208,18 @@ static inline void amdgpu_ring_write(struct amdgpu_ring
*ring, uint32_t v)
ring->ring_free_dw--;
}
-static inline struct amdgpu_sdma * amdgpu_get_sdma_instance(struct amdgpu_ring
*ring)
+static inline struct amdgpu_sdma_instance *
+amdgpu_get_sdma_instance(struct amdgpu_ring *ring)
{
struct amdgpu_device *adev = ring->adev;
int i;
- for (i = 0; i < AMDGPU_MAX_SDMA_INSTANCES; i++)
- if (&adev->sdma[i].ring == ring)
+ for (i = 0; i < adev->sdma.num_instances; i++)
+ if (&adev->sdma.instance[i].ring == ring)
break;
if (i < AMDGPU_MAX_SDMA_INSTANCES)
- return &adev->sdma[i];
+ return &adev->sdma.instance[i];
else
return NULL;
}
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd_gfx_v7.c
b/drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd_gfx_v7.c
index dd2037b..0e13763 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd_gfx_v7.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd_gfx_v7.c
@@ -649,12 +649,12 @@ static uint16_t get_fw_version(struct kgd_dev *kgd, enum
kgd_engine_type type)
case KGD_ENGINE_SDMA1:
hdr = (const union amdgpu_firmware_header *)
- adev->sdma[0].fw->data;
+
adev->sdma.instance[0].fw->data;
break;
case KGD_ENGINE_SDMA2:
hdr = (const union amdgpu_firmware_header *)
- adev->sdma[1].fw->data;
+
adev->sdma.instance[1].fw->data;
break;
default:
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd_gfx_v8.c
b/drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd_gfx_v8.c
index dfd1d50..79fa5c7 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd_gfx_v8.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd_gfx_v8.c
@@ -523,12 +523,12 @@ static uint16_t get_fw_version(struct kgd_dev *kgd, enum
kgd_engine_type type)
case KGD_ENGINE_SDMA1:
hdr = (const union amdgpu_firmware_header *)
- adev->sdma[0].fw->data;
+
adev->sdma.instance[0].fw->data;
break;
case KGD_ENGINE_SDMA2:
hdr = (const union amdgpu_firmware_header *)
- adev->sdma[1].fw->data;
+
adev->sdma.instance[1].fw->data;
break;
default:
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c
b/drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c
index 749420f..29fc45c 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c
@@ -104,10 +104,11 @@ int
[PATCH v3 2/2] drm: panel: simple: add QiaoDian qd43003c0-40
On Thu, Oct 8, 2015 at 10:42 AM, Alexandre Belloni
wrote:
> From: Josh Wu
>
> The QiaoDian Xianshi QD43003C0-40 is a 4"3 TFT LCD panel.
>
> Timings from the OTA5180A document, ver 0.9, section
> 10.1.1:
> http://www.orientdisplay.com/pdf/OTA5180A.pdf
>
> Signed-off-by: Josh Wu
> Signed-off-by: Alexandre Belloni
> ---
> .../bindings/panel/qiaodian,qd43003c0-40.txt | 7 ++
Acked-by: Rob Herring
BTW, I'm moving bindings/panel/ to bindings/display/panel/ for 4.4.
It's fine to leave this, but if you do respin for some reason, can you
move this there.
Rob
> drivers/gpu/drm/panel/panel-simple.c | 27
> ++
> 2 files changed, 34 insertions(+)
> create mode 100644
> Documentation/devicetree/bindings/panel/qiaodian,qd43003c0-40.txt
>
> diff --git
> a/Documentation/devicetree/bindings/panel/qiaodian,qd43003c0-40.txt
> b/Documentation/devicetree/bindings/panel/qiaodian,qd43003c0-40.txt
> new file mode 100644
> index ..0fbdab89ac3d
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/panel/qiaodian,qd43003c0-40.txt
> @@ -0,0 +1,7 @@
> +QiaoDian XianShi Corporation 4"3 TFT LCD panel
> +
> +Required properties:
> +- compatible: should be "qiaodian,qd43003c0-40"
> +
> +This binding is compatible with the simple-panel binding, which is specified
> +in simple-panel.txt in this directory.
> diff --git a/drivers/gpu/drm/panel/panel-simple.c
> b/drivers/gpu/drm/panel/panel-simple.c
> index f97b73ec4713..c93ffa615005 100644
> --- a/drivers/gpu/drm/panel/panel-simple.c
> +++ b/drivers/gpu/drm/panel/panel-simple.c
> @@ -1027,6 +1027,30 @@ static const struct panel_desc ortustech_com43h4m85ulc
> = {
> .bus_format = MEDIA_BUS_FMT_RGB888_1X24,
> };
>
> +static const struct drm_display_mode qd43003c0_40_mode = {
> + .clock = 9000,
> + .hdisplay = 480,
> + .hsync_start = 480 + 8,
> + .hsync_end = 480 + 8 + 4,
> + .htotal = 480 + 8 + 4 + 39,
> + .vdisplay = 272,
> + .vsync_start = 272 + 4,
> + .vsync_end = 272 + 4 + 10,
> + .vtotal = 272 + 4 + 10 + 2,
> + .vrefresh = 60,
> +};
> +
> +static const struct panel_desc qd43003c0_40 = {
> + .modes = &qd43003c0_40_mode,
> + .num_modes = 1,
> + .bpc = 8,
> + .size = {
> + .width = 95,
> + .height = 53,
> + },
> + .bus_format = MEDIA_BUS_FMT_RGB888_1X24,
> +};
> +
> static const struct drm_display_mode samsung_ltn101nt05_mode = {
> .clock = 54030,
> .hdisplay = 1024,
> @@ -1182,6 +1206,9 @@ static const struct of_device_id platform_of_match[] = {
> .compatible = "ortustech,com43h4m85ulc",
> .data = &ortustech_com43h4m85ulc,
> }, {
> + .compatible = "qiaodian,qd43003c0-40",
> + .data = &qd43003c0_40,
> + }, {
> .compatible = "samsung,ltn101nt05",
> .data = &samsung_ltn101nt05,
> }, {
> --
> 2.1.4
>
[PATCH v3 1/2] of: Add vendor prefix for QiaoDian Xianshi
Use "qiaodian" as the vendor prefix for QiaoDian Xianshi Corporation in device tree compatible strings. Signed-off-by: Alexandre Belloni --- Changes in v3: -use qiaodian as the vendor prefix as preferred by Rob Herring Documentation/devicetree/bindings/vendor-prefixes.txt | 1 + 1 file changed, 1 insertion(+) diff --git a/Documentation/devicetree/bindings/vendor-prefixes.txt b/Documentation/devicetree/bindings/vendor-prefixes.txt index ac5f0c34ae00..d6402753fd9f 100644 --- a/Documentation/devicetree/bindings/vendor-prefixes.txt +++ b/Documentation/devicetree/bindings/vendor-prefixes.txt @@ -174,6 +174,7 @@ qca Qualcomm Atheros, Inc. qcom Qualcomm Technologies, Inc qemu QEMU, a generic and open source machine emulator and virtualizer qi Qi Hardware +qiaodian QiaoDian XianShi Corporation qnap QNAP Systems, Inc. radxa Radxa raidsonic RaidSonic Technology GmbH -- 2.1.4
[PATCH] drm/i915/irq: Fix kernel-doc warnings
Add the dev parameter for the functions i915_enable_asle_pipestat() and
i915_reset_and_wakeup() to the kernel-doc to fix the following warnings:
.//drivers/gpu/drm/i915/i915_irq.c:586: warning: No description found for
parameter 'dev'
.//drivers/gpu/drm/i915/i915_irq.c:2400: warning: No description found for
parameter 'dev'
Signed-off-by: Javier Martinez Canillas
---
drivers/gpu/drm/i915/i915_irq.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/gpu/drm/i915/i915_irq.c b/drivers/gpu/drm/i915/i915_irq.c
index 8ca772deabdb..0344a9181dac 100644
--- a/drivers/gpu/drm/i915/i915_irq.c
+++ b/drivers/gpu/drm/i915/i915_irq.c
@@ -581,6 +581,7 @@ i915_disable_pipestat(struct drm_i915_private *dev_priv,
enum pipe pipe,
/**
* i915_enable_asle_pipestat - enable ASLE pipestat for OpRegion
+ * @dev: drm device
*/
static void i915_enable_asle_pipestat(struct drm_device *dev)
{
@@ -2392,6 +2393,7 @@ static void i915_error_wake_up(struct drm_i915_private
*dev_priv,
/**
* i915_reset_and_wakeup - do process context error handling work
+ * @dev: drm device
*
* Fire an error uevent so userspace can see that a hang or error
* was detected.
--
2.4.3
[PATCH] drm/i915/irq: Fix misspelled word register in kernel-doc
There is a typo in the function i915_handle_error() kernel-doc and the word register is spelled wrongly. Signed-off-by: Javier Martinez Canillas --- drivers/gpu/drm/i915/i915_irq.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/gpu/drm/i915/i915_irq.c b/drivers/gpu/drm/i915/i915_irq.c index 0344a9181dac..38dadd23684d 100644 --- a/drivers/gpu/drm/i915/i915_irq.c +++ b/drivers/gpu/drm/i915/i915_irq.c @@ -2571,7 +2571,7 @@ static void i915_report_and_clear_eir(struct drm_device *dev) * i915_handle_error - handle a gpu error * @dev: drm device * - * Do some basic checking of regsiter state at error time and + * Do some basic checking of register state at error time and * dump it to the syslog. Also call i915_capture_error_state() to make * sure we get a record and make it available in debugfs. Fire a uevent * so userspace knows something bad happened (should trigger collection -- 2.4.3
periodic wakeup from DPMS suspend
On Wed, Oct 07, 2015 at 01:26:32PM +0200, Johannes Stezenbach wrote: > On Tue, Oct 06, 2015 at 11:04:53PM -0400, Alex Deucher wrote: > > On Tue, Oct 6, 2015 at 11:10 AM, Johannes Stezenbach > > wrote: > > > > > > I have a NEC EA244WMi monitor connected to an Asus P8H77-V > > > mainboard with Ivy Bridge Core i5-3550 via DVI. > > > If DPMS suspend is enabled (by xscreensaver, or for testing by > > > "xset dpms force off/suspend/standby"), the monitor > > > enters standby mode but wakes up every 10...30 seconds for > > > 6 seconds to display a "DVI-D: no signal" message. > > > > Some monitors periodically scan all of their inputs if they are not > > actively being driven by anything to try and automatically switch to > > the connected input. When the monitor scans the DVI input, it sees > > load on the pins and turns on, only to realize it's not getting a > > signal and then turns off. If your monitor has an option to turn off > > input probing, that might help. > > It's not like I didn't try to twiddle just about every > available menu item, and also used the monitor's > "Reset to Factory Defaults" to no avail. > However, while trying again I found a hidden menu item > which is only available during the short time the > "No Signal" message is displayed, where the left/right > touch buttons open a "Scan Time" setting with "Normal" > and "Slow" options. After I changed it, the issue was > solved. I changed it back and the issue doesn't reproduce. > So it looks some internal configuration of the monitor > was messed up and is now fixed by twiddling the hidden > menu item. "Scan Time" is not documented in the manual > nor is there an indication in the "No Signal" popup. > > Case closed. And I just came back to see the monitor doing the wakeup cycling again. To try something differerent I unplugged the charger of the laptop sitting nearby in suspend. Bingo! So it looks like an EMI issue. I tried a few times and could reproduce twice and then no more :-( Now the monitor wakes up once every 5min or so... Which brings me back to a previous question: > maybe it is some floating signal line causing the > monitor to misdetect activity? Does the Intel hardware have the capability to switch the DVI signal lines from high-z to ground during DPMS suspend, and if so, does the driver do the right thing? Obviously I have no clue about DVI and intel-gfx, but I thought to ask anyway. Johannes
i.mx6 video out in mainline
On Tue, Oct 6, 2015 at 8:07 PM, Fabio Estevam wrote: > On Tue, Oct 6, 2015 at 8:02 PM, Pushpal Sidhu wrote: > >> When I took your patch and adapted it for imx6qdl-gw54xx.dtsi, I found >> that HDMI video out was slightly shifted to the left and resolution >> remained at 1024x768p. >> >> I also found that when I disabled DRM_IMX_LDB, HDMI out stopped >> working altogether, though if I stripped out the ldb section in device >> tree, the resolution comes back at 1080p (regardless of setting >> DRM_IMX_LDB or not). There is definitely some strange interdependency >> between lvds and hdmi here. Do you have an idea of where I should >> start looking for this problem? > > I thought we have already fixed that. Does this issue still happen with > 4.3-rc4? > > I would suggest turning on debug in drivers/gpu/ipu-v3/ipu-di.c and > see the DI frequencies you are getting for the HDMI and LDB ports. I moved to 4.3-rc4, and found that HDMI and LVDS DI freq's are different (with your patch to move LVDS's parent clock to OTG. HDMI: imx-ipuv3 240.ipu: Clocks: IPU 26400Hz DI 6500Hz Needed 6500Hz LVDS: imx-ipuv3 240.ipu: Clocks: IPU 26400Hz DI 68571429Hz Needed 6500Hz However, if I have both HDMI and LVDS hooked into the system at the same time, the HDMI's EDID block 0 is always invalid. $ cat /proc/cmdline console=ttymxc1,115200 root=ubi0:rootfs ubi.mtd=2 rootfstype=ubifs debug video=HDMI-A-1,1920x1080M at 60 $ dmesg | grep "ipu\|drm\|hdmi\|lvds" [1.983369] [drm] Initialized drm 1.1.0 20060810 [1.990533] imx-ipuv3 240.ipu: IPUv3H probed [1.996823] [drm] Supports vblank timestamp caching Rev 2 (21.10.2013). [2.004000] [drm] No driver support for vblank timestamp query. [2.010539] imx-drm display-subsystem: bound imx-ipuv3-crtc.0 (ops ipu_crtc_ops) [2.018549] imx-drm display-subsystem: bound imx-ipuv3-crtc.1 (ops ipu_crtc_ops) [2.026575] imx-drm display-subsystem: bound imx-ipuv3-crtc.4 (ops ipu_crtc_ops) [2.034608] imx-drm display-subsystem: bound imx-ipuv3-crtc.5 (ops ipu_crtc_ops) [2.043253] dwhdmi-imx 12.hdmi: Detected HDMI controller 0x13:0xa:0xa0:0xc1 [2.057862] imx-drm display-subsystem: bound 12.hdmi (ops dw_hdmi_imx_ops) [2.072465] imx-drm display-subsystem: bound 200.aips-bus:ldb at 020e0008 (ops imx_ldb_ops) [2.097335] [drm:drm_edid_block_valid] *ERROR* EDID checksum is invalid, remainder is 81 [2.169323] [drm:drm_edid_block_valid] *ERROR* EDID checksum is invalid, remainder is 81 [2.241300] [drm:drm_edid_block_valid] *ERROR* EDID checksum is invalid, remainder is 81 [2.313291] [drm:drm_edid_block_valid] *ERROR* EDID checksum is invalid, remainder is 81 [2.369763] imx-drm display-subsystem: HDMI-A-1: EDID block 0 invalid. [2.416797] imx-drm display-subsystem: fb0: frame buffer device [2.460575] [drm] Initialized imx-drm 1.0.0 20120507 on minor 0 [2.466766] imx-ipuv3 280.ipu: IPUv3H probed [ 28.270558] imx-ipuv3 240.ipu: Timeout waiting for DMFC FIFOs to clear This causes the HDMI monitor to get a signal, and within a second, think that a signal no longer exists. Also, it seems that LVDS (even connected by itself), appears to work. The backlight comes on, but nothing gets drawn to the display. I then tried the following: $ cat /proc/cmdline console=ttymxc1,115200 root=ubi0:rootfs ubi.mtd=2 rootfstype=ubifs debug video=HDMI-A-1:d video=LVDS-1:e That is, forcing HDMI off and LVDS on. I verified that the kernel saw this (e.g. [drm] forcing HDMI-A-1 connector OFF) and found an interesting result. The LVDS backlight still turns on, but the HDMI had the image painted onto it while being colorspace converted for the LVDS monitor (white showed up as a light blue, green was blue, red was green etc). It looks like when only LVDS is connected, signals still get sent to the HDMI monitor, which would explain why it appears that LVDS doesn't work. Comparing the imx6qdl-gw54xx.dtsi and imx6qdl-sabersd.dtsi, I couldn't see too many differences between HDMI and LVDS, so I'm a little surprised you don't see this exact same behavior there. Note that I've tried this with the patch for changing the LVDS's parent clock in the imx6qdl-gw54xx.dtsi file. - Pushpal
radeonsi - crash with 7870 Tahiti - Bad Active CU detection?
Hi!
I've never been able to run the open source drm driver on my 7870
Tahiti card. The console kms works but it crashes as soon as X is
started. There have been many mentions of it in bug reports, but none
of the attempts at fixes worked.
https://bugs.freedesktop.org/show_bug.cgi?id=71689 is currently open
https://bugs.freedesktop.org/show_bug.cgi?id=60879 was about a few
different issues, including this one, but none of the proposed fixes
worked on my 7870
I decided to debug this on my own, and though I am a total noob at
driver development, I think I made some progress at understanding the
issue.
The 7870 Tahiti is a "harvested" chip, which means some CUs are
disabled. 25% of them in this case. The code handling this is in
si.c, in the function is si_setup_spi(). The idea seems to be that a
bit mask telling which CUs are truly available must be set in the
SPI_STATIC_THREAD_MGMT_3 register. But the algorithm to build that
mask seems fuzzy to me. It walks the bits of active_cu until it finds
an active one, and stop there to build its make.
data = RREG32(SPI_STATIC_THREAD_MGMT_3);
active_cu = si_get_cu_enabled(rdev, cu_per_sh);
mask = 1;
for (k = 0; k < 16; k++) {
mask <<= k;
if (active_cu & mask) {
data &= ~mask;
WREG32(SPI_STATIC_THREAD_MGMT_3, data);
break;
}
}
However, from the little I understand that doesn't cover all cases,
but only works if the disabled CUs are in the lower bits. For my card,
the active_cu results are:
Decimal - Binary
252 - 1100
252 - 1100
207 - 1100
252 - 1100
As you can see the 3rd group has its disabled CUs straight in the
middle of it, but the algorithm probably thinks that they are all good
since the first bit is 1 and it stops right there. So I guess it tries
to use bad CUs at runtime and fails miserably
I tried to change the way the register data is computed by I just
can't figure the logic of it (and I couldn't find much details in
AMD's doc). Assuming it generates the right thing for active_cu ==
1100, I get data == 0111.
So I have 2 disabled units, but only a single 0 in the mask?
Pretending to have more disabled units, active_cu == , that
generates data == 1011. Again, single 0. Is that right?
What would be the bit pattern required for active_cu == 1100 ?
I might be way off track in my investigation, so please enlighten me!
Thanks for your help,
Alexandre
[PATCH v5 0/17] Add Analogix Core Display Port Driver
Hi Javier, On 10/07/2015 07:25 PM, Javier Martinez Canillas wrote: > Hello Yakir, > > On 10/07/2015 01:05 PM, Yakir Yang wrote: >> Hi Javier, >> >> On 10/07/2015 05:26 PM, Javier Martinez Canillas wrote: >>> Hello Yakir, >>> >>> On 10/07/2015 11:02 AM, Yakir Yang wrote: Hi Javier, On 10/07/2015 04:46 PM, Javier Martinez Canillas wrote: > Hello Yakir, > > On 10/07/2015 08:25 AM, Yakir Yang wrote: >> Hi all, >> >> Friendly ping. :) >> >> >> Best regards, >> - Yakir >> >> > Do you have a tree that I can use to test these patches? Wow, thanks a lot, I do have a tree on github [https://github.com/yakir-Yang/linux/tree/analogix_dp], crossing my finger, wish things works..;) >>> I tried your analogix_dp branch on an Exynos5800 Peach Pi Chromebook >>> but the machine didn't boot. Unfortunately I need to do some soldering >>> to have a serial console on this board so don't have a kernel boot log. >>> >>> I'll let you know if I can get more info about this issue. >> Whoops, sorry for the failed, much appreciated for your works. >> >> Besides, I thought maybe I can find a Peach Pit Chromebook in my side, >> I remember that some of our guys have brought one, but previously I >> thought that mainline kernel wouldn't run on Peach Pit directly. >> > Great, mainline works correctly on all Exynos based Chromebooks. > >> Maybe you can email me the method the run mainline kernel on Peach >> Pit, so I can debug the analogix_dp driver at the same time, that would >> be great. > I wrote a little blog post explaining how to run mainline on these boards: > > http://blogs.s-osg.org/install-linux-mainline-kernel-distro-exynos-chromebooks/ > > That explains the simplest setup though so if you need a different one > (i.e: chain loading a non verified u-boot) or if you have any questions, > feel free to contact me in private and I can help you with the setup. > Ah, thanks, gonna to step-by-step. - Yakir >>> Also, there is Kconfig recursive dependency that you may want to fix: >>> >>> $ make exynos_defconfig >>> drivers/video/fbdev/Kconfig:5:error: recursive dependency detected! >>> drivers/video/fbdev/Kconfig:5: symbol FB is selected by DRM_KMS_FB_HELPER >>> drivers/gpu/drm/Kconfig:34: symbol DRM_KMS_FB_HELPER depends on >>> DRM_KMS_HELPER >>> drivers/gpu/drm/Kconfig:28: symbol DRM_KMS_HELPER is selected by >>> DRM_ANALOGIX_DP >>> drivers/gpu/drm/bridge/analogix/Kconfig:1: symbol DRM_ANALOGIX_DP is >>> selected by DRM_EXYNOS_DP >>> drivers/gpu/drm/exynos/Kconfig:57: symbol DRM_EXYNOS_DP depends on >>> DRM_EXYNOS_FIMD >>> drivers/gpu/drm/exynos/Kconfig:19: symbol DRM_EXYNOS_FIMD depends on FB_S3C >>> drivers/video/fbdev/Kconfig:2023: symbol FB_S3C depends on FB >>> >> Yeah, recursive dependency detected, guess I should remove the >> "DRM_KMS_HELPER" from bridge analogix_dp Kconfig file, thanks >> for your remind. >> >> --- a/drivers/gpu/drm/bridge/analogix/Kconfig >> +++ b/drivers/gpu/drm/bridge/analogix/Kconfig >> @@ -1,4 +1,3 @@ >> config DRM_ANALOGIX_DP >> tristate >> depends on DRM >> - select DRM_KMS_HELPER >> >> > That fixes the recursive dependency issue indeed. Thanks. > >> Thanks, >> - Yakir > Best regards,
i.mx6 video out in mainline
On Tue, Oct 6, 2015 at 11:45 PM, Lucas Stach wrote:
> Am Dienstag, den 06.10.2015, 16:02 -0700 schrieb Pushpal Sidhu:
>> On Tue, Oct 6, 2015 at 3:16 PM, Fabio Estevam
>> wrote:
>> > On Tue, Oct 6, 2015 at 6:52 PM, Pushpal Sidhu > > > wrote:
>> > > Hi All,
>> > >
>> > > I'm attempting to use a standard fb console (using the
>> > > imx6qdl-gw54xx.dtsi), but I find that it only draws to the
>> > > 1024x768p
>> > > portion of the screen. This is also true when running the
>> > > userspace
>> > > tool fb-test.
>> >
>> > Looking at imx6qdl-gw54xx.dtsi I see you have a LVDS panel with
>> > 1024x768 resolution.
>> >
>> > I sent a patch that allows LDB and HDMI to work simultaneously:
>> > https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/com
>> > mit/arch/arm/boot/dts/imx6qdl
>> > -sabresd.dtsi?id=d28be499c45e6e16d7a042ce280eb872dc06952b
>> >
>> > Can you try to adapt it for imx6qdl-gw54xx.dtsi?
>> >
>> > If this still does not help your HDMI output, please try disabling
>> > the LVDS.
>>
>> When I took your patch and adapted it for imx6qdl-gw54xx.dtsi, I
>> found
>> that HDMI video out was slightly shifted to the left and resolution
>> remained at 1024x768p.
>>
>> I also found that when I disabled DRM_IMX_LDB, HDMI out stopped
>> working altogether, though if I stripped out the ldb section in
>> device
>> tree, the resolution comes back at 1080p (regardless of setting
>> DRM_IMX_LDB or not). There is definitely some strange interdependency
>> between lvds and hdmi here. Do you have an idea of where I should
>> start looking for this problem?
>>
> This isn't strange, but actually really simple to explain:
>
> 1. The DRM driver is a componentized driver that needs all of its
> components to come up before it registers the DRM device. So if you
> have the LDB enabled in your DT you also need the LDB driver, otherwise
> you won't get any video out. If you don't want to have LDB, don't
> disable the driver alone, but also add a status = "disabled" in the DT
> LDB node.
>
> 2. The kernels framebuffer emulation layer will try to put the
> framebuffer on both displays. So if you have a smaller LVDS display
> connected the framebuffer will only have the size of the smaller
> display. Solution is to not depend on the kernels frambuffer emulation,
> but actually set a mode from userspace and work with the KMS interface
> directly.
Ah, that makes total sense then. Do you know of any userspace
application that works using the KMS interface, other than using
x11/wayland (in other words, something extremely simple like fbset)?
I've gotten too used to using the downstream vendor kernel way of
using sysfs to set the modes per display so I'm trying to learn the
"right" way of doing things.
About sysfs, why is it that the seemingly obsolete
/sys/class/graphics/fbX/{mode,modes} still exist in the kernel when
they seem to serve no function? Is that just some cleanup that hasn't
occurred yet?
- Pushpal
[PATCH v3 2/2] drm: panel: simple: add QiaoDian qd43003c0-40
From: Josh Wu
The QiaoDian Xianshi QD43003C0-40 is a 4"3 TFT LCD panel.
Timings from the OTA5180A document, ver 0.9, section
10.1.1:
http://www.orientdisplay.com/pdf/OTA5180A.pdf
Signed-off-by: Josh Wu
Signed-off-by: Alexandre Belloni
---
.../bindings/panel/qiaodian,qd43003c0-40.txt | 7 ++
drivers/gpu/drm/panel/panel-simple.c | 27 ++
2 files changed, 34 insertions(+)
create mode 100644
Documentation/devicetree/bindings/panel/qiaodian,qd43003c0-40.txt
diff --git a/Documentation/devicetree/bindings/panel/qiaodian,qd43003c0-40.txt
b/Documentation/devicetree/bindings/panel/qiaodian,qd43003c0-40.txt
new file mode 100644
index ..0fbdab89ac3d
--- /dev/null
+++ b/Documentation/devicetree/bindings/panel/qiaodian,qd43003c0-40.txt
@@ -0,0 +1,7 @@
+QiaoDian XianShi Corporation 4"3 TFT LCD panel
+
+Required properties:
+- compatible: should be "qiaodian,qd43003c0-40"
+
+This binding is compatible with the simple-panel binding, which is specified
+in simple-panel.txt in this directory.
diff --git a/drivers/gpu/drm/panel/panel-simple.c
b/drivers/gpu/drm/panel/panel-simple.c
index f97b73ec4713..c93ffa615005 100644
--- a/drivers/gpu/drm/panel/panel-simple.c
+++ b/drivers/gpu/drm/panel/panel-simple.c
@@ -1027,6 +1027,30 @@ static const struct panel_desc ortustech_com43h4m85ulc =
{
.bus_format = MEDIA_BUS_FMT_RGB888_1X24,
};
+static const struct drm_display_mode qd43003c0_40_mode = {
+ .clock = 9000,
+ .hdisplay = 480,
+ .hsync_start = 480 + 8,
+ .hsync_end = 480 + 8 + 4,
+ .htotal = 480 + 8 + 4 + 39,
+ .vdisplay = 272,
+ .vsync_start = 272 + 4,
+ .vsync_end = 272 + 4 + 10,
+ .vtotal = 272 + 4 + 10 + 2,
+ .vrefresh = 60,
+};
+
+static const struct panel_desc qd43003c0_40 = {
+ .modes = &qd43003c0_40_mode,
+ .num_modes = 1,
+ .bpc = 8,
+ .size = {
+ .width = 95,
+ .height = 53,
+ },
+ .bus_format = MEDIA_BUS_FMT_RGB888_1X24,
+};
+
static const struct drm_display_mode samsung_ltn101nt05_mode = {
.clock = 54030,
.hdisplay = 1024,
@@ -1182,6 +1206,9 @@ static const struct of_device_id platform_of_match[] = {
.compatible = "ortustech,com43h4m85ulc",
.data = &ortustech_com43h4m85ulc,
}, {
+ .compatible = "qiaodian,qd43003c0-40",
+ .data = &qd43003c0_40,
+ }, {
.compatible = "samsung,ltn101nt05",
.data = &samsung_ltn101nt05,
}, {
--
2.1.4
As of kernel 4.3-rc1 system will not stay in S3 suspend [REGRESSION][BISECTED]
Hi, This started somewhere between Kernel 4.2 and 4.3-rc1, but I only noticed it a day ago. The first S3 suspend after a fresh boot works fine. Thereafter, suspends simply resume again immediately. I get the following errors on my console: [ 152.697247] i915 :00:02.0: GEM idle failed, resume might fail [ 152.697258] pci_pm_suspend(): i915_pm_suspend+0x0/0x50 [i915] returns -11 [ 152.697262] dpm_run_callback(): pci_pm_suspend+0x0/0x140 returns -11 [ 152.697264] PM: Device :00:02.0 failed to suspend async: error -11 [ 152.697306] PM: Some devices failed to suspend, or early wake event detected The issue is not limited to my normal way of doing suspend, using "pm-suspend". It also happens using the "echo mem > /sys/power/state" method. The kernel was bisected, and the result was double checked by clean compiles of the first bad commit and the immediately preceding commit. Bisect results copied below: $ git bisect good dc4be6071a24f0d2da6af8ce16c19f276ac4d7a2 is the first bad commit commit dc4be6071a24f0d2da6af8ce16c19f276ac4d7a2 Author: John Harrison Date: Fri May 29 17:43:39 2015 +0100 drm/i915: Add explicit request management to i915_gem_init_hw() Now that a single per ring loop is being done for all the different intialisation steps in i915_gem_init_hw(), it is possible to add proper request management as well. The last remaining issue is that the context enable call eventually ends up within *_render_state_init() and this does its own private _i915_add_request() call. This patch adds explicit request creation and submission to the top level loop and removes the add_request() from deep within the sub-functions. v2: Updated for removal of batch_obj from add_request call in previous patch. For: VIZ-5115 Signed-off-by: John Harrison Reviewed-by: Tomas Elf Signed-off-by: Daniel Vetter :04 04 789c630ff3f5f07238a5df1bde79187c6c1251d0 2da3f7e20e2642d8eebd9f72528923c2ac53a8cb M drivers
