[PATCH] drm/exynos: fix nested calls to lock mutex in drm resume
add Mr. Dae On Thu, May 22, 2014 at 11:16 PM, Rahul Sharma wrote: > Hi Inki, > > This is another one which has not got reviewed. Please review. > > Regards, > Rahul Sharma > > On 30 April 2014 19:11, Rahul Sharma wrote: >> From: Rahul Sharma >> >> While testing S2R on exynos board, system is hanging and >> rebooting due to nested mutex_lock calls in exynos drm >> resume callback. Changing the order of the calls is fixing >> the issue. >> >> Signed-off-by: Rahul Sharma >> --- >> Based on exynos-drm-next branch in Inki Dae's tree. >> drivers/gpu/drm/exynos/exynos_drm_drv.c |2 +- >> 1 file changed, 1 insertion(+), 1 deletion(-) >> >> diff --git a/drivers/gpu/drm/exynos/exynos_drm_drv.c >> b/drivers/gpu/drm/exynos/exynos_drm_drv.c >> index bb7dfee..2bb6233 100644 >> --- a/drivers/gpu/drm/exynos/exynos_drm_drv.c >> +++ b/drivers/gpu/drm/exynos/exynos_drm_drv.c >> @@ -184,8 +184,8 @@ static int exynos_drm_resume(struct drm_device *dev) >> connector->funcs->dpms(connector, connector->dpms); >> } >> >> - drm_helper_resume_force_mode(dev); >> drm_modeset_unlock_all(dev); >> + drm_helper_resume_force_mode(dev); >> >> return 0; >> } >> -- >> 1.7.9.5 >> > ___ > dri-devel mailing list > dri-devel at lists.freedesktop.org > http://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 2/6] drm: Refactor setplane to allow internal use (v3)
On Thu, May 22, 2014 at 6:33 PM, Matt Roper wrote: > v3: > - Move integer overflow checking from setplane_internal to setplane >ioctl. The upcoming legacy cursor support via universal planes needs >to maintain current cursor ioctl semantics and not return error for >these extreme values (found via intel-gpu-tools kms_cursor_crc test). Imo that's just the test being silly. I think it's valid to reject such nonsense with -EINVAL and limit the random-walk range of our testcase a bit. The igt testcases are just guidelines for what our ABI is, but not the hard rules. And clarifying the ABI in such cases is imo the right approach. That random-walk testcase just was meant to test correctly clamping. E.g. on hardware with just 12bit for the cursor placement we'd wrap around and show a cursor again that should be off. So as long as you still test that you can restrict the range of the test a bit. -Daniel -- Daniel Vetter Software Engineer, Intel Corporation +41 (0) 79 365 57 48 - http://blog.ffwll.ch
[PATCH v3 3/4] drm: Document how to register devices without struct drm_bus
On Thu, May 22, 2014 at 12:21:23PM +0200, Thierry Reding wrote: > From: Thierry Reding > > With the recent addition of the drm_set_unique() function, devices can > now be registered without requiring a drm_bus. Add a brief description > to the DRM docbook to show how that can be achieved. > > Signed-off-by: Thierry Reding Reviewed-by: Daniel Vetter > --- > Changes in v3: > - replace drm_dev_put() recommendation by explicit drm_dev_unregister() > followed by drm_dev_unref() > - use !E in DocBook to insert kernel-doc for all exported symbols > > Documentation/DocBook/drm.tmpl | 26 ++ > 1 file changed, 26 insertions(+) > > diff --git a/Documentation/DocBook/drm.tmpl b/Documentation/DocBook/drm.tmpl > index 438edcd566b5..09f8788fec3f 100644 > --- a/Documentation/DocBook/drm.tmpl > +++ b/Documentation/DocBook/drm.tmpl > @@ -142,6 +142,12 @@ >to register it with the DRM subsystem. > > > + Newer drivers that no longer require a drm_bus > + structure can alternatively use the low-level device initialization and > + registration functions such as drm_dev_alloc() and > + drm_dev_register() directly. > + > + >The drm_driver structure contains static >information that describes the driver and features it supports, and >pointers to methods that the DRM core will call to implement the DRM > API. > @@ -290,6 +296,26 @@ char *date; > !Edrivers/gpu/drm/drm_pci.c > !Edrivers/gpu/drm/drm_usb.c > !Edrivers/gpu/drm/drm_platform.c > + > +New drivers that no longer rely on the services provided by the > +drm_bus structure can call the low-level > +device registration functions directly. The > +drm_dev_alloc() function can be used to allocate > +and initialize a new drm_device structure. > +Drivers will typically want to perform some additional setup on this > +structure, such as allocating driver-specific data and storing a > +pointer to it in the DRM device's > dev_private > +field. Drivers should also set the device's unique name using the > +drm_dev_set_unique() function. After it has been > +set up a device can be registered with the DRM subsystem by calling > +drm_dev_register(). This will cause the device > to > +be exposed to userspace and will call the driver's > +.load() implementation. When a device is > +removed, the DRM device can safely be unregistered and freed by > calling > +drm_dev_unregister() followed by a call to > +drm_dev_unref(). > + > +!Edrivers/gpu/drm/drm_stub.c > > >Driver Load > -- > 1.9.2 > -- Daniel Vetter Software Engineer, Intel Corporation +41 (0) 79 365 57 48 - http://blog.ffwll.ch
[PATCH v3 2/4] drm: Add device registration documentation
On Thu, May 22, 2014 at 12:21:22PM +0200, Thierry Reding wrote:
> From: Thierry Reding
>
> Describe how devices are registered using the drm_*_init() functions.
> Adding this to docbook requires a largish set of changes to the comments
> in drm_{pci,usb,platform}.c since they are doxygen-style rather than
> proper kernel-doc and therefore mess with the docbook generation.
>
> While at it, mark usage of drm_put_dev() as discouraged in favour of
> calling drm_dev_unregister() and drm_dev_unref() directly.
>
> Signed-off-by: Thierry Reding
tbh not sure how much value this really provides, since most of these
should either be ripped out, moved somewhere else (e.g. the pcie speed cap
thing) or deprecated. Otoh pretty docs rarely hurt, so
Acked-by: Daniel Vetter
since I didn't bother to review in-depth.
-Daniel
> ---
> Changes in v3:
> - add note that drm_put_dev() should not be used in new drivers
> - use !E to include all exported functions in DocBook
>
> Documentation/DocBook/drm.tmpl | 10 ++
> drivers/gpu/drm/drm_pci.c | 80
> --
> drivers/gpu/drm/drm_platform.c | 15
> drivers/gpu/drm/drm_stub.c | 22 ++--
> drivers/gpu/drm/drm_usb.c | 20 ++-
> 5 files changed, 85 insertions(+), 62 deletions(-)
>
> diff --git a/Documentation/DocBook/drm.tmpl b/Documentation/DocBook/drm.tmpl
> index ec81c20a17db..438edcd566b5 100644
> --- a/Documentation/DocBook/drm.tmpl
> +++ b/Documentation/DocBook/drm.tmpl
> @@ -282,6 +282,16 @@ char *date;
>
>
>
> + Device Registration
> +
> +A number of functions are provided to help with device registration.
> +The functions deal with PCI, USB and platform devices, respectively.
> +
> +!Edrivers/gpu/drm/drm_pci.c
> +!Edrivers/gpu/drm/drm_usb.c
> +!Edrivers/gpu/drm/drm_platform.c
> +
> +
>Driver Load
>
> The load method is the driver and device
> diff --git a/drivers/gpu/drm/drm_pci.c b/drivers/gpu/drm/drm_pci.c
> index d237de36a07a..020cfd934854 100644
> --- a/drivers/gpu/drm/drm_pci.c
> +++ b/drivers/gpu/drm/drm_pci.c
> @@ -1,17 +1,3 @@
> -/* drm_pci.h -- PCI DMA memory management wrappers for DRM -*- linux-c -*- */
> -/**
> - * \file drm_pci.c
> - * \brief Functions and ioctls to manage PCI memory
> - *
> - * \warning These interfaces aren't stable yet.
> - *
> - * \todo Implement the remaining ioctl's for the PCI pools.
> - * \todo The wrappers here are so thin that they would be better off
> inlined..
> - *
> - * \author Jos? Fonseca
> - * \author Leif Delgass
> - */
> -
> /*
> * Copyright 2003 Jos? Fonseca.
> * Copyright 2003 Leif Delgass.
> @@ -42,12 +28,14 @@
> #include
> #include
>
> -/**/
> -/** \name PCI memory */
> -/*@{*/
> -
> /**
> - * \brief Allocate a PCI consistent memory block, for DMA.
> + * drm_pci_alloc - Allocate a PCI consistent memory block, for DMA.
> + * @dev: DRM device
> + * @size: size of block to allocate
> + * @align: alignment of block
> + *
> + * Return: A handle to the allocated memory block on success or NULL on
> + * failure.
> */
> drm_dma_handle_t *drm_pci_alloc(struct drm_device * dev, size_t size, size_t
> align)
> {
> @@ -88,8 +76,8 @@ drm_dma_handle_t *drm_pci_alloc(struct drm_device * dev,
> size_t size, size_t ali
>
> EXPORT_SYMBOL(drm_pci_alloc);
>
> -/**
> - * \brief Free a PCI consistent memory block without freeing its descriptor.
> +/*
> + * Free a PCI consistent memory block without freeing its descriptor.
> *
> * This function is for internal use in the Linux-specific DRM core code.
> */
> @@ -111,7 +99,9 @@ void __drm_pci_free(struct drm_device * dev,
> drm_dma_handle_t * dmah)
> }
>
> /**
> - * \brief Free a PCI consistent memory block
> + * drm_pci_free - Free a PCI consistent memory block
> + * @dev: DRM device
> + * @dmah: handle to memory block
> */
> void drm_pci_free(struct drm_device * dev, drm_dma_handle_t * dmah)
> {
> @@ -226,17 +216,16 @@ static int drm_pci_irq_by_busid(struct drm_device *dev,
> struct drm_irq_busid *p)
> }
>
> /**
> - * Get interrupt from bus id.
> - *
> - * \param inode device inode.
> - * \param file_priv DRM file private.
> - * \param cmd command.
> - * \param arg user argument, pointing to a drm_irq_busid structure.
> - * \return zero on success or a negative number on failure.
> + * drm_irq_by_busid - Get interrupt from bus ID
> + * @dev: DRM device
> + * @data: IOCTL parameter pointing to a drm_irq_busid structure
> + * @file_priv: DRM file private.
> *
> * Finds the PCI device with the specified bus id and gets its IRQ number.
> * This IOCTL is deprecated, and will now return EINVAL for any busid not
> equal
> * to that of the device that this DRM instance attached to.
> + *
> + * Return: 0 on success or a negative error code on failure.
> */
> int drm_irq_by_busid(struct drm_device *dev, void
[PATCH 2/6] drm: Refactor setplane to allow internal use (v3)
On Thu, May 22, 2014 at 03:48:16PM -0700, Matt Roper wrote: > On Fri, May 23, 2014 at 12:37:52AM +0200, Daniel Vetter wrote: > > On Thu, May 22, 2014 at 6:33 PM, Matt Roper > > wrote: > > > v3: > > > - Move integer overflow checking from setplane_internal to setplane > > >ioctl. The upcoming legacy cursor support via universal planes needs > > >to maintain current cursor ioctl semantics and not return error for > > >these extreme values (found via intel-gpu-tools kms_cursor_crc test). > > > > Imo that's just the test being silly. I think it's valid to reject > > such nonsense with -EINVAL and limit the random-walk range of our > > testcase a bit. The igt testcases are just guidelines for what our ABI > > is, but not the hard rules. And clarifying the ABI in such cases is > > imo the right approach. > > > > That random-walk testcase just was meant to test correctly clamping. > > E.g. on hardware with just 12bit for the cursor placement we'd wrap > > around and show a cursor again that should be off. So as long as you > > still test that you can restrict the range of the test a bit. > > -Daniel > > I was a bit torn on this. Since we accept offscreen plane positions, > I'm not sure it makes sense to really treat "offscreen" differently than > "really, really offscreen." The legacy cursor ioctls have never cared > about this in the past so I didn't want to add in artificial range > limiting just because the setplane ioctl has had it for a while. > > There's actually an i-g-t test that specifically tries to program > specifically at INT_MAX (not just the random walk test that might get > lucky and go out of bounds), so I figured the best course was just to > preserve the current behavior; I can't really see any downsides to not > range-limiting the cursors. Ok, if you think this won't create an unnecessary fuss in the code then I'm ok with this, too. After all most hw has limited offset fields, so drivers must clamp anyway. So dunno really how much sense that limit check makes in set_plane. But we have it, so doesn't hurt too much really. A different consideration though is that with the igt_kms library the plan is to just switch to atomic modeset eventually, which also means using universal planes for cursors and primary planes. Which means as soon as we do that we'll likely hit that restriction again. Not sure what to do now here. -Daniel -- Daniel Vetter Software Engineer, Intel Corporation +41 (0) 79 365 57 48 - http://blog.ffwll.ch
[Bug 73528] Deferred lighting in Second Life causes system hiccups and screen flickering
https://bugs.freedesktop.org/show_bug.cgi?id=73528 --- Comment #6 from MirceaKitsune --- I compiled latest MESA GIT today and tried the SL viewer out once more. The issue still exists! I have however at least found a way to test it, that doesn't appear to crash my computer (have no prims in view and therefore rendered, have a command ready to instantly kill the viewer process). I shall see if I can test with different settings, in case it's a combination of factors. One thing I noticed additionally: I have Radeon DPM enabled, despite my Kernel requiring a boot parameter for that as that's not yet default. When the issue takes place, the fan on my video card also reach maximum RPM. Something clearly floods the video card and GPU beyond what they can handle. -- 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/20140523/618a1d27/attachment-0001.html>
Frame buffer and plane difference
Hello, Can someone help me understand the basic difference between a plane and a frame buffer. Regards, Anand -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20140523/f3a81bb6/attachment-0001.html>
[PATCH] drm/exynos: fix nested calls to lock mutex in drm resume
On 22 May 2014 23:26, Sachin Kamat wrote: > Hi Rahul, > > On 22 May 2014 19:46, Rahul Sharma wrote: >> Hi Inki, >> >> This is another one which has not got reviewed. Please review. > > Inki has applied a similar patch from Takashi [1]. Thanks Sachin, Good that solution is merged. @ Inki, sorry for raising concern. It went unnoticed. Regards, Rahul Sharma. > > [1] https://lkml.org/lkml/2014/5/9/24 > > -- > With warm regards, > Sachin
[PATCH 3/3] drm/i915: Add aspect ratio property for HDMI
Adding dri-devel..
On May-22-2014 4:50 PM, Kannan, Vandana wrote:
> Create and attach the drm property to set aspect ratio. If there is no user
> specified value, then PAR_NONE/Automatic option is set by default. User can
> select aspect ratio 4:3 or 16:9. The aspect ratio selected by user would
> come into effect with a mode set.
>
> Signed-off-by: Vandana Kannan
> ---
> drivers/gpu/drm/i915/i915_drv.h | 5 +
> drivers/gpu/drm/i915/intel_drv.h | 1 +
> drivers/gpu/drm/i915/intel_hdmi.c | 31 +++
> 3 files changed, 37 insertions(+)
>
> diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
> index 13495a4..8dc5f59 100644
> --- a/drivers/gpu/drm/i915/i915_drv.h
> +++ b/drivers/gpu/drm/i915/i915_drv.h
> @@ -2691,6 +2691,11 @@ int vlv_freq_opcode(struct drm_i915_private *dev_priv,
> int val);
> #define INTEL_BROADCAST_RGB_FULL 1
> #define INTEL_BROADCAST_RGB_LIMITED 2
>
> +/* Aspect ratio property */
> +#define INTEL_ASPECT_RATIO_AUTO 0
> +#define INTEL_ASPECT_RATIO_4_3 1
> +#define INTEL_ASPECT_RATIO_16_9 2
> +
> static inline uint32_t i915_vgacntrl_reg(struct drm_device *dev)
> {
> if (HAS_PCH_SPLIT(dev))
> diff --git a/drivers/gpu/drm/i915/intel_drv.h
> b/drivers/gpu/drm/i915/intel_drv.h
> index 287b89e..f9f19b6 100644
> --- a/drivers/gpu/drm/i915/intel_drv.h
> +++ b/drivers/gpu/drm/i915/intel_drv.h
> @@ -488,6 +488,7 @@ struct intel_hdmi {
> bool has_audio;
> enum hdmi_force_audio force_audio;
> bool rgb_quant_range_selectable;
> + enum hdmi_picture_aspect aspect_ratio;
> void (*write_infoframe)(struct drm_encoder *encoder,
> enum hdmi_infoframe_type type,
> const void *frame, ssize_t len);
> diff --git a/drivers/gpu/drm/i915/intel_hdmi.c
> b/drivers/gpu/drm/i915/intel_hdmi.c
> index 171d0dd..2c6aa76 100644
> --- a/drivers/gpu/drm/i915/intel_hdmi.c
> +++ b/drivers/gpu/drm/i915/intel_hdmi.c
> @@ -367,6 +367,9 @@ static void intel_hdmi_set_avi_infoframe(struct
> drm_encoder *encoder,
> union hdmi_infoframe frame;
> int ret;
>
> + /* Set user selected PAR to incoming mode's member */
> + adjusted_mode->picture_aspect_ratio = intel_hdmi->aspect_ratio;
> +
> ret = drm_hdmi_avi_infoframe_from_display_mode(&frame.avi,
> adjusted_mode);
> if (ret < 0) {
> @@ -1124,6 +1127,23 @@ intel_hdmi_set_property(struct drm_connector
> *connector,
> goto done;
> }
>
> + if (property == connector->dev->mode_config.aspect_ratio_property) {
> + switch (val) {
> + case INTEL_ASPECT_RATIO_AUTO:
> + intel_hdmi->aspect_ratio = HDMI_PICTURE_ASPECT_NONE;
> + break;
> + case INTEL_ASPECT_RATIO_4_3:
> + intel_hdmi->aspect_ratio = HDMI_PICTURE_ASPECT_4_3;
> + break;
> + case INTEL_ASPECT_RATIO_16_9:
> + intel_hdmi->aspect_ratio = HDMI_PICTURE_ASPECT_16_9;
> + break;
> + default:
> + return -EINVAL;
> + }
> + goto done;
> + }
> +
> return -EINVAL;
>
> done:
> @@ -1416,11 +1436,22 @@ static const struct drm_encoder_funcs
> intel_hdmi_enc_funcs = {
> };
>
> static void
> +intel_attach_aspect_ratio_property(struct drm_connector *connector)
> +{
> + drm_mode_create_aspect_ratio_property(connector->dev);
> + drm_object_attach_property(&connector->base,
> + connector->dev->mode_config.aspect_ratio_property,
> + HDMI_PICTURE_ASPECT_NONE);
> +}
> +
> +static void
> intel_hdmi_add_properties(struct intel_hdmi *intel_hdmi, struct
> drm_connector *connector)
> {
> intel_attach_force_audio_property(connector);
> intel_attach_broadcast_rgb_property(connector);
> intel_hdmi->color_range_auto = true;
> + intel_attach_aspect_ratio_property(connector);
> + intel_hdmi->aspect_ratio = HDMI_PICTURE_ASPECT_NONE;
> }
>
> void intel_hdmi_init_connector(struct intel_digital_port *intel_dig_port,
>
[PATCH] drm/ttm: fix kerneldoc of ttm_bo_create
The kerneldoc header of ttm_bo_create() was referring to another (nonexisting) function and had a few obsolete or incorrect arguments. Signed-off-by: Alexandre Courbot --- include/drm/ttm/ttm_bo_api.h | 5 ++--- 1 file changed, 2 insertions(+), 3 deletions(-) diff --git a/include/drm/ttm/ttm_bo_api.h b/include/drm/ttm/ttm_bo_api.h index ee127ec33c60..7526c5bf5610 100644 --- a/include/drm/ttm/ttm_bo_api.h +++ b/include/drm/ttm/ttm_bo_api.h @@ -485,13 +485,12 @@ extern int ttm_bo_init(struct ttm_bo_device *bdev, void (*destroy) (struct ttm_buffer_object *)); /** - * ttm_bo_synccpu_object_init + * ttm_bo_create * * @bdev: Pointer to a ttm_bo_device struct. - * @bo: Pointer to a ttm_buffer_object to be initialized. * @size: Requested size of buffer object. * @type: Requested type of buffer object. - * @flags: Initial placement flags. + * @placement: Initial placement. * @page_alignment: Data alignment in pages. * @interruptible: If needing to sleep while waiting for GPU resources, * sleep interruptible. -- 1.9.2
[PATCH RESEND] drm/ttm: remove declaration of ttm_tt_cache_flush
ttm_tt_cache_flush's implementation was removed in 2009 by commit c9c97b8c, but its declaration has been hiding in ttm_bo_driver.h since then. It has been surviving in the dark for too long now ; give it the mercy blow. Signed-off-by: Alexandre Courbot Reviewed-by: Thierry Reding --- include/drm/ttm/ttm_bo_driver.h | 12 1 file changed, 12 deletions(-) diff --git a/include/drm/ttm/ttm_bo_driver.h b/include/drm/ttm/ttm_bo_driver.h index a5183da3ef92..e3f8c99a8a9d 100644 --- a/include/drm/ttm/ttm_bo_driver.h +++ b/include/drm/ttm/ttm_bo_driver.h @@ -653,18 +653,6 @@ extern void ttm_tt_unbind(struct ttm_tt *ttm); extern int ttm_tt_swapin(struct ttm_tt *ttm); /** - * ttm_tt_cache_flush: - * - * @pages: An array of pointers to struct page:s to flush. - * @num_pages: Number of pages to flush. - * - * Flush the data of the indicated pages from the cpu caches. - * This is used when changing caching attributes of the pages from - * cache-coherent. - */ -extern void ttm_tt_cache_flush(struct page *pages[], unsigned long num_pages); - -/** * ttm_tt_set_placement_caching: * * @ttm A struct ttm_tt the backing pages of which will change caching policy. -- 1.9.2
[PATCH resend 1/4] nouveau: Don't check acpi_video_backlight_support() before registering backlight
On Thu, May 22, 2014 at 9:30 AM, Rafael J. Wysocki wrote:
> On Wednesday, May 21, 2014 03:39:53 PM Hans de Goede wrote:
>> acpi_video_backlight_support() is supposed to be called by other (vendor
>> specific) firmware backlight controls, not by native / raw backlight controls
>> like nv_backlight.
>>
>> Userspace will normally prefer firmware interfaces over raw interfaces, so
>> if acpi_video backlight support is present it will use that even if
>> nv_backlight is registered as well.
>>
>> Except when video.use_native_backlight is present on the kernel cmdline
>> (or enabled through a dmi based quirk). As the name indicates the goal here
>> is to make only the raw interface available to userspace so that it will use
>> that (it only does this when it sees a win8 compliant bios).
>>
>> This is done by:
>> 1) Not registering any acpi_video# backlight devices; and
>> 2) Making acpi_video_backlight_support() return true so that other firmware
>> drivers, ie acer_wmi, thinkpad_acpi, dell_laptop, etc. Don't register their
>> own vender specific interfaces.
>>
>> Currently nouveau breaks this setup, as when acpi_video_backlight_support()
>> returns true, it does not register itself, resulting in no backlight control
>> at all.
>>
>> This is esp. going to be a problem with 3.16 which will default to
>> video.use_native_backlight=1, and thus nouveau based laptops with a win8 bios
>> will get no backlight control at all.
>>
>> This also likely explains why the previous attempt to make
>> video.use_native_backlight=1 the default was not a success, as without this
>> patch having a default of video.use_native_backlight=1 will cause
>> regressions.
>>
>> Note this effectively reverts commit 5bead799
>>
>> Also see: https://bugzilla.redhat.com/show_bug.cgi?id=1093171
>>
>> Signed-off-by: Hans de Goede
>
> It would be good to have an ACK from the nouveau people for this one.
Acked-by: Ben Skeggs
;)
>
>> ---
>> drivers/gpu/drm/nouveau/nouveau_backlight.c | 9 -
>> 1 file changed, 9 deletions(-)
>>
>> diff --git a/drivers/gpu/drm/nouveau/nouveau_backlight.c
>> b/drivers/gpu/drm/nouveau/nouveau_backlight.c
>> index 630f6e8..2c1e4aa 100644
>> --- a/drivers/gpu/drm/nouveau/nouveau_backlight.c
>> +++ b/drivers/gpu/drm/nouveau/nouveau_backlight.c
>> @@ -31,7 +31,6 @@
>> */
>>
>> #include
>> -#include
>>
>> #include "nouveau_drm.h"
>> #include "nouveau_reg.h"
>> @@ -222,14 +221,6 @@ nouveau_backlight_init(struct drm_device *dev)
>> struct nouveau_device *device = nv_device(drm->device);
>> struct drm_connector *connector;
>>
>> -#ifdef CONFIG_ACPI
>> - if (acpi_video_backlight_support()) {
>> - NV_INFO(drm, "ACPI backlight interface available, "
>> - "not registering our own\n");
>> - return 0;
>> - }
>> -#endif
>> -
>> list_for_each_entry(connector, &dev->mode_config.connector_list, head)
>> {
>> if (connector->connector_type != DRM_MODE_CONNECTOR_LVDS &&
>> connector->connector_type != DRM_MODE_CONNECTOR_eDP)
>>
>
> --
> I speak only for myself.
> Rafael J. Wysocki, Intel Open Source Technology Center.
> ___
> dri-devel mailing list
> dri-devel at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 79100] New: r600 context creation failure on kaveri
https://bugs.freedesktop.org/show_bug.cgi?id=79100 Priority: medium Bug ID: 79100 Assignee: dri-devel at lists.freedesktop.org Summary: r600 context creation failure on kaveri Severity: normal Classification: Unclassified OS: Linux (All) Reporter: joshua.r.marshall.1991 at gmail.com Hardware: x86-64 (AMD64) Status: NEW Version: 10.1 Component: Drivers/Gallium/r600 Product: Mesa Created attachment 99606 --> https://bugs.freedesktop.org/attachment.cgi?id=99606&action=edit Xorg log EE r600_pipe.c:258 r600_create_context - Unsupported chip class 9. When some lower level operation is performed (I have no idea what) X quits because of something driver side. This often occurs with flash player, and always when calling the Mathematica function Plot3D. I have attatched gratuitous system information. -- 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/20140523/ebf04ca0/attachment.html>
[Bug 79100] r600 context creation failure on kaveri
https://bugs.freedesktop.org/show_bug.cgi?id=79100 --- Comment #1 from joshua.r.marshall.1991 at gmail.com --- Created attachment 99607 --> https://bugs.freedesktop.org/attachment.cgi?id=99607&action=edit xorg driver config -- 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/20140523/2b1b57dd/attachment.html>
[Bug 79100] r600 context creation failure on kaveri
https://bugs.freedesktop.org/show_bug.cgi?id=79100 --- Comment #2 from joshua.r.marshall.1991 at gmail.com --- Created attachment 99608 --> https://bugs.freedesktop.org/attachment.cgi?id=99608&action=edit glxinfo -v -t -- 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/20140523/9a2e3ffb/attachment.html>
[Bug 79100] r600 context creation failure on kaveri
https://bugs.freedesktop.org/show_bug.cgi?id=79100 --- Comment #3 from joshua.r.marshall.1991 at gmail.com --- Created attachment 99609 --> https://bugs.freedesktop.org/attachment.cgi?id=99609&action=edit lshw -- 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/20140523/3fe99ed3/attachment.html>
[Bug 79100] r600 context creation failure on kaveri
https://bugs.freedesktop.org/show_bug.cgi?id=79100 --- Comment #4 from joshua.r.marshall.1991 at gmail.com --- Created attachment 99610 --> https://bugs.freedesktop.org/attachment.cgi?id=99610&action=edit Detailed package information -- 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/20140523/70fff2d2/attachment.html>
[Bug 79100] r600 context creation failure on kaveri
https://bugs.freedesktop.org/show_bug.cgi?id=79100 --- Comment #5 from joshua.r.marshall.1991 at gmail.com --- Created attachment 99611 --> https://bugs.freedesktop.org/attachment.cgi?id=99611&action=edit Installed packages -- 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/20140523/3ea381e6/attachment.html>
[Bug 79100] r600 context creation failure on kaveri
https://bugs.freedesktop.org/show_bug.cgi?id=79100 --- Comment #6 from joshua.r.marshall.1991 at gmail.com --- Created attachment 99612 --> https://bugs.freedesktop.org/attachment.cgi?id=99612&action=edit Unsanitized System Log Has extra info, sorry for the extra text. -- 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/20140523/bcfa6237/attachment.html>
[PATCH 2/6] drm: Refactor setplane to allow internal use (v3)
On Fri, May 23, 2014 at 12:57 AM, Matt Roper wrote: > When we switch to atomic modeset in i-g-t, everything will be coming in > via the propertyset interface, right? Since the range limiting check is > in the setplane ioctl code now, I'd expect us to bypass it completely. Yeah, I guess we can look at that again when it happens. -Daniel -- Daniel Vetter Software Engineer, Intel Corporation +41 (0) 79 365 57 48 - http://blog.ffwll.ch
[PATCH 01/11] drm/dp_helper: add defines for DP 1.2 and MST support.
On Wednesday, May 21, 2014 11:55 AM, Dave Airlie wrote: > > From: Dave Airlie > > This just adds the defines from the DP 1.2 spec, which we > will use later. > > Signed-off-by: Dave Airlie I checked this patch by using DP 1.2 spec. These definitions are correct. Thank you. Reviewed-by: Jingoo Han Best regards, Jingoo Han > --- > include/drm/drm_dp_helper.h | 78 > + > 1 file changed, 78 insertions(+) > > diff --git a/include/drm/drm_dp_helper.h b/include/drm/drm_dp_helper.h > index cfcacec..879836d 100644 > --- a/include/drm/drm_dp_helper.h > +++ b/include/drm/drm_dp_helper.h > @@ -37,6 +37,7 @@ > * eDP: Embedded DisplayPort version 1 > * DPI: DisplayPort Interoperability Guideline v1.1a > * 1.2: DisplayPort 1.2 > + * MST: Multistream Transport - part of DP 1.2a > * > * 1.2 formally includes both eDP and DPI definitions. > */ > @@ -103,9 +104,14 @@ > #define DP_TRAINING_AUX_RD_INTERVAL 0x00e /* XXX 1.2? */ > > /* Multiple stream transport */ > +#define DP_FAUX_CAP 0x020 /* 1.2 */ > +# define DP_FAUX_CAP_1 (1 << 0) > + > #define DP_MSTM_CAP 0x021 /* 1.2 */ > # define DP_MST_CAP (1 << 0) > > +#define DP_GUID 0x030 /* 1.2 */ > + > #define DP_PSR_SUPPORT 0x070 /* XXX 1.2? */ > # define DP_PSR_IS_SUPPORTED1 > #define DP_PSR_CAPS 0x071 /* XXX 1.2? */ > @@ -221,6 +227,16 @@ > # define DP_PSR_CRC_VERIFICATION (1 << 2) > # define DP_PSR_FRAME_CAPTURE(1 << 3) > > +#define DP_ADAPTER_CTRL 0x1a0 > +# define DP_ADAPTER_CTRL_FORCE_LOAD_SENSE (1 << 0) > + > +#define DP_BRANCH_DEVICE_CTRL0x1a1 > +# define DP_BRANCH_DEVICE_IRQ_HPD(1 << 0) > + > +#define DP_PAYLOAD_ALLOCATE_SET 0x1c0 > +#define DP_PAYLOAD_ALLOCATE_START_TIME_SLOT 0x1c1 > +#define DP_PAYLOAD_ALLOCATE_TIME_SLOT_COUNT 0x1c2 > + > #define DP_SINK_COUNT0x200 > /* prior to 1.2 bit 7 was reserved mbz */ > # define DP_GET_SINK_COUNT(x)x) & 0x80) >> 1) | ((x) > & 0x3f)) > @@ -230,6 +246,9 @@ > # define DP_REMOTE_CONTROL_COMMAND_PENDING (1 << 0) > # define DP_AUTOMATED_TEST_REQUEST (1 << 1) > # define DP_CP_IRQ (1 << 2) > +# define DP_MCCS_IRQ (1 << 3) > +# define DP_DOWN_REP_MSG_RDY (1 << 4) /* DP MST */ > +# define DP_UP_REQ_MSG_RDY (1 << 5) /* DP MST */ > # define DP_SINK_SPECIFIC_IRQ(1 << 6) > > #define DP_LANE0_1_STATUS0x202 > @@ -294,6 +313,13 @@ > #define DP_TEST_SINK 0x270 > #define DP_TEST_SINK_START (1 << 0) > > +#define DP_PAYLOAD_TABLE_UPDATE_STATUS 0x2c0 /* 1.2 MST */ > +# define DP_PAYLOAD_TABLE_UPDATED (1 << 0) > +# define DP_PAYLOAD_ACT_HANDLED (1 << 1) > + > +#define DP_VC_PAYLOAD_ID_SLOT_1 0x2c1 /* 1.2 MST */ > +/* up to ID_SLOT_63 at 0x2ff */ > + > #define DP_SOURCE_OUI0x300 > #define DP_SINK_OUI 0x400 > #define DP_BRANCH_OUI0x500 > @@ -303,6 +329,21 @@ > # define DP_SET_POWER_D30x2 > # define DP_SET_POWER_MASK 0x3 > > +#define DP_SIDEBAND_MSG_DOWN_REQ_BASE0x1000 /* 1.2 MST */ > +#define DP_SIDEBAND_MSG_UP_REP_BASE 0x1200 /* 1.2 MST */ > +#define DP_SIDEBAND_MSG_DOWN_REP_BASE0x1400 /* 1.2 MST */ > +#define DP_SIDEBAND_MSG_UP_REQ_BASE 0x1600 /* 1.2 MST */ > + > +#define DP_SINK_COUNT_ESI0x2002 /* 1.2 */ > +/* 0-5 sink count */ > +# define DP_SINK_COUNT_CP_READY (1 << 6) > + > +#define DP_DEVICE_SERVICE_IRQ_VECTOR_ESI0 0x2003 /* 1.2 */ > + > +#define DP_DEVICE_SERVICE_IRQ_VECTOR_ESI1 0x2004 /* 1.2 */ > + > +#define DP_LINK_SERVICE_IRQ_VECTOR_ESI0 0x2005 /* 1.2 */ > + > #define DP_PSR_ERROR_STATUS 0x2006 /* XXX 1.2? */ > # define DP_PSR_LINK_CRC_ERROR (1 << 0) > # define DP_PSR_RFB_STORAGE_ERROR (1 << 1) > @@ -319,6 +360,43 @@ > # define DP_PSR_SINK_INTERNAL_ERROR 7 > # define DP_PSR_SINK_STATE_MASK 0x07 > > +/* DP 1.2 Sideband message defines */ > +/* peer device type - DP 1.2a Table 2-92 */ > +#define DP_PEER_DEVICE_NONE 0x0 > +#define DP_PEER_DEVICE_SOURCE_OR_SST 0x1 > +#define DP_PEER_DEVICE_MST_BRANCHING 0x2 > +#define DP_PEER_DEVICE_SST_SINK 0x3 > +#define DP_PEER_DEVICE_DP_LEGACY_CONV0x4 > + > +/* DP 1.2 MST sideband request names DP 1.2a Table 2-80 */ > +#define DP_LINK_ADDRESS 0x01 > +#define DP_CONNECTION_STATUS_NOTIFY 0x02 > +#define DP_ENUM_PATH_RESOURCES 0x10 > +#define DP_ALLOCATE_PAYLOAD
[PATCH 2/4] drm/ttm: introduce dma cache sync helpers
On Fri, May 23, 2014 at 02:49:40PM +0900, Alexandre Courbot wrote: > On Mon, May 19, 2014 at 5:33 PM, Thierry Reding > wrote: > > On Mon, May 19, 2014 at 04:10:56PM +0900, Alexandre Courbot wrote: > >> From: Lucas Stach > >> > >> On arches with non-coherent PCI, > > > > I guess since this applies to gk20a > > > >> we need to flush caches ourselfes at > > > > "ourselves". Or perhaps even reword to something like: "..., caches need > > to be flushed and invalidated explicitly", since dma_sync_for_cpu() does > > invalidate rather than flush. > > Rephrased as "On arches for which access to GPU memory is non-coherent, caches > need to be flushed and invalidated explicitly at the appropriate places." Nit: s/arches/architectures/ Thierry -- next part -- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 836 bytes Desc: not available URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20140523/c29d6755/attachment.sig>
[PATCH v4] drm/exynos: enable fimd clocks in probe before accessing fimd registers
Hi Rahul,
On 05/23/2014 04:19 AM, Rahul Sharma wrote:
> From: Rahul Sharma
>
> Fimd probe is accessing fimd Registers without enabling the fimd
> gate clocks. If FIMD clocks are kept disabled in Uboot or disbaled
> during kernel boottime, the system hangs during boottime.
>
> This issue got surfaced when verifying with sysmmu enabled. Probe of
> fimd Sysmmu enables the master clock before accessing sysmmu regs and
> then disables. Later fimd probe tries to read the register without
> enabling the clock which is wrong and hangs the system.
>
> Signed-off-by: Rahul Sharma
> ---
> v4:
> 1) Added clk_disable for prev clock when clk_enable fails.
> v3:
> 1) Added checks for clk_enable.
> v2:
> Rebase.
>
> drivers/gpu/drm/exynos/exynos_drm_fimd.c | 18 +-
> 1 file changed, 17 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/exynos/exynos_drm_fimd.c
> b/drivers/gpu/drm/exynos/exynos_drm_fimd.c
> index bd30d0c..30ccd67 100644
> --- a/drivers/gpu/drm/exynos/exynos_drm_fimd.c
> +++ b/drivers/gpu/drm/exynos/exynos_drm_fimd.c
> @@ -898,16 +898,32 @@ static int fimd_bind(struct device *dev, struct device
> *master, void *data)
> {
> struct fimd_context *ctx = fimd_manager.ctx;
> struct drm_device *drm_dev = data;
> - int win;
> + int win, ret;
>
> fimd_mgr_initialize(&fimd_manager, drm_dev);
> exynos_drm_crtc_create(&fimd_manager);
> if (ctx->display)
> exynos_drm_create_enc_conn(drm_dev, ctx->display);
>
> + ret = clk_prepare_enable(ctx->bus_clk);
> + if (ret) {
> + dev_err(dev, "bus clock enable failed.\n");
> + return ret;
> + }
> +
> + ret = clk_prepare_enable(ctx->lcd_clk);
> + if (ret) {
> + dev_err(dev, "lcd clock enable failed.\n");
> + clk_disable_unprepare(ctx->bus_clk);
> + return ret;
> + }
> +
> for (win = 0; win < WINDOWS_NR; win++)
> fimd_clear_win(ctx, win);
>
> + clk_disable_unprepare(ctx->lcd_clk);
> + clk_disable_unprepare(ctx->bus_clk);
> +
> return 0;
If you want to access fimd registers I guess pm_runtime_get_sync should
be called as well, to wake up display pm domain.
Regards
Andrzej
>
> }
>
[PATCH 2/3] drm/exynos: Remove duplicate inclusion of i2c.h
Hi Sachin, On 05/22/2014 07:02 AM, Sachin Kamat wrote: > i2c.h was included twice. > > Signed-off-by: Sachin Kamat > --- > drivers/gpu/drm/exynos/exynos_hdmi.c |1 - > 1 file changed, 1 deletion(-) > > diff --git a/drivers/gpu/drm/exynos/exynos_hdmi.c > b/drivers/gpu/drm/exynos/exynos_hdmi.c > index ed6176e..d3f9684 100644 > --- a/drivers/gpu/drm/exynos/exynos_hdmi.c > +++ b/drivers/gpu/drm/exynos/exynos_hdmi.c > @@ -34,7 +34,6 @@ > #include > #include > #include > -#include > #include > #include > #include > It would be also good to order headers alphabetically. Regards Andrzej
[RFC] drm/nouveau: disable caching for VRAM BOs on ARM
Am Freitag, den 23.05.2014, 16:10 +0900 schrieb Alexandre Courbot: > On Mon, May 19, 2014 at 7:16 PM, Lucas Stach > wrote: > > Am Montag, den 19.05.2014, 19:06 +0900 schrieb Alexandre Courbot: > >> On 05/19/2014 06:57 PM, Lucas Stach wrote: > >> > Am Montag, den 19.05.2014, 18:46 +0900 schrieb Alexandre Courbot: > >> >> This patch is not meant to be merged, but rather to try and understand > >> >> why this is needed and what a more suitable solution could be. > >> >> > >> >> Allowing BOs to be write-cached results in the following happening when > >> >> trying to run any program on Tegra/GK20A: > >> >> > >> >> Unhandled fault: external abort on non-linefetch (0x1008) at 0xf0036010 > >> >> ... > >> >> (nouveau_bo_rd32) from [] (nouveau_fence_update+0x5c/0x80) > >> >> (nouveau_fence_update) from [] (nouveau_fence_done+0x1c/0x38) > >> >> (nouveau_fence_done) from [] (ttm_bo_wait+0xec/0x168) > >> >> (ttm_bo_wait) from [] (nouveau_gem_ioctl_cpu_prep+0x44/0x100) > >> >> (nouveau_gem_ioctl_cpu_prep) from [] (drm_ioctl+0x1d8/0x4f4) > >> >> (drm_ioctl) from [] (nouveau_drm_ioctl+0x54/0x80) > >> >> (nouveau_drm_ioctl) from [] (do_vfs_ioctl+0x3dc/0x5a0) > >> >> (do_vfs_ioctl) from [] (SyS_ioctl+0x34/0x5c) > >> >> (SyS_ioctl) from [] (ret_fast_syscall+0x0/0x30 > >> >> > >> >> The offending nouveau_bo_rd32 is done over an IO-mapped BO, e.g. a BO > >> >> mapped through the BAR. > >> >> > >> > Um wait, this memory is behind an already mapped bar? I think ioremap on > >> > ARM defaults to uncached mappings, so if you want to access the memory > >> > behind this bar as WC you need to map the BAR as a whole as WC by using > >> > ioremap_wc. > >> > >> Tried mapping the BAR using ioremap_wc(), but to no avail. On the other > >> hand, could it be that VRAM BOs end up creating a mapping over an > >> already-mapped region? I seem to remember that ARM might not like it... > > > > Multiple mapping are generally allowed, as long as they have the same > > caching state. It's conflicting mappings (uncached vs cached, or cached > > vs wc), that are documented to yield undefined results. > > Sorry about the confusion. The BAR is *not* mapped to the kernel yet > (it is BAR1, there is no BAR3 on GK20A) and an ioremap_*() is > performed in ttm_bo_ioremap() to make the part of the BAR where the > buffer is mapped visible. It seems that doing an ioremap_wc() on the > BAR area on Tegra is what leads to these errors. ioremap() or > ioremap_nocache() (which are in effect the same on ARM) do not cause > this issue. > It would be cool if you could ask HW, or the blob developers, if this is a general issue. The external abort is clearly the GPUs AXI client responding with an error to the read request, though I'm not clear where a WC read differs from an uncached one. > The best way to solve this issue would be to not use the BAR at all > since the memory behind these objects can be directly accessed by the > CPU. As such it would better be mapped using ttm_bo_kmap_ttm() > instead. But right now this is clearly not how nouveau_bo.c is written > and it does not look like this can easily be done. :/ Yeah, it sounds like we want this shortcut for stolen VRAM implementations. Regards, Lucas -- Pengutronix e.K. | Lucas Stach | Industrial Linux Solutions | http://www.pengutronix.de/ |
[RFC] drm/nouveau: disable caching for VRAM BOs on ARM
On 05/23/2014 06:24 PM, Lucas Stach wrote: > Am Freitag, den 23.05.2014, 16:10 +0900 schrieb Alexandre Courbot: >> On Mon, May 19, 2014 at 7:16 PM, Lucas Stach >> wrote: >>> Am Montag, den 19.05.2014, 19:06 +0900 schrieb Alexandre Courbot: On 05/19/2014 06:57 PM, Lucas Stach wrote: > Am Montag, den 19.05.2014, 18:46 +0900 schrieb Alexandre Courbot: >> This patch is not meant to be merged, but rather to try and understand >> why this is needed and what a more suitable solution could be. >> >> Allowing BOs to be write-cached results in the following happening when >> trying to run any program on Tegra/GK20A: >> >> Unhandled fault: external abort on non-linefetch (0x1008) at 0xf0036010 >> ... >> (nouveau_bo_rd32) from [] (nouveau_fence_update+0x5c/0x80) >> (nouveau_fence_update) from [] (nouveau_fence_done+0x1c/0x38) >> (nouveau_fence_done) from [] (ttm_bo_wait+0xec/0x168) >> (ttm_bo_wait) from [] (nouveau_gem_ioctl_cpu_prep+0x44/0x100) >> (nouveau_gem_ioctl_cpu_prep) from [] (drm_ioctl+0x1d8/0x4f4) >> (drm_ioctl) from [] (nouveau_drm_ioctl+0x54/0x80) >> (nouveau_drm_ioctl) from [] (do_vfs_ioctl+0x3dc/0x5a0) >> (do_vfs_ioctl) from [] (SyS_ioctl+0x34/0x5c) >> (SyS_ioctl) from [] (ret_fast_syscall+0x0/0x30 >> >> The offending nouveau_bo_rd32 is done over an IO-mapped BO, e.g. a BO >> mapped through the BAR. >> > Um wait, this memory is behind an already mapped bar? I think ioremap on > ARM defaults to uncached mappings, so if you want to access the memory > behind this bar as WC you need to map the BAR as a whole as WC by using > ioremap_wc. Tried mapping the BAR using ioremap_wc(), but to no avail. On the other hand, could it be that VRAM BOs end up creating a mapping over an already-mapped region? I seem to remember that ARM might not like it... >>> >>> Multiple mapping are generally allowed, as long as they have the same >>> caching state. It's conflicting mappings (uncached vs cached, or cached >>> vs wc), that are documented to yield undefined results. >> >> Sorry about the confusion. The BAR is *not* mapped to the kernel yet >> (it is BAR1, there is no BAR3 on GK20A) and an ioremap_*() is >> performed in ttm_bo_ioremap() to make the part of the BAR where the >> buffer is mapped visible. It seems that doing an ioremap_wc() on the >> BAR area on Tegra is what leads to these errors. ioremap() or >> ioremap_nocache() (which are in effect the same on ARM) do not cause >> this issue. >> > It would be cool if you could ask HW, or the blob developers, if this is > a general issue. The external abort is clearly the GPUs AXI client > responding with an error to the read request, though I'm not clear where > a WC read differs from an uncached one. Will check that. > >> The best way to solve this issue would be to not use the BAR at all >> since the memory behind these objects can be directly accessed by the >> CPU. As such it would better be mapped using ttm_bo_kmap_ttm() >> instead. But right now this is clearly not how nouveau_bo.c is written >> and it does not look like this can easily be done. :/ > > Yeah, it sounds like we want this shortcut for stolen VRAM > implementations. Actually, isn't it the case that we do not want to use TTM at all for stolen VRAM (UMA) devices? I am trying to wrap my head around this since a while already, and could not think of a way to use the current TTM-based nouveau_bo optimally for GK20A. Because we cannot do without the idea of VRAM and GART, we will always have to "move" objects from one location to another, or deal with constraints that do not make sense for UMA devices (like in the current case, accessing VRAM objects through the BAR). I am currently contemplating the idea of writing an alternative non-TTM implementation of nouveau_bo for UMA devices, that would (hopefully) be much simpler and would spare us a lot of stunts. On the other hand, this sounds like a considerable work and I would like to make sure that my lack of understanding of TTM is not driving me to the wrong solution. Thoughts? Thanks, Alex.
[RFC] drm/nouveau: disable caching for VRAM BOs on ARM
Am Freitag, den 23.05.2014, 18:43 +0900 schrieb Alexandre Courbot: > On 05/23/2014 06:24 PM, Lucas Stach wrote: > > Am Freitag, den 23.05.2014, 16:10 +0900 schrieb Alexandre Courbot: > >> On Mon, May 19, 2014 at 7:16 PM, Lucas Stach > >> wrote: > >>> Am Montag, den 19.05.2014, 19:06 +0900 schrieb Alexandre Courbot: > On 05/19/2014 06:57 PM, Lucas Stach wrote: > > Am Montag, den 19.05.2014, 18:46 +0900 schrieb Alexandre Courbot: > >> This patch is not meant to be merged, but rather to try and understand > >> why this is needed and what a more suitable solution could be. > >> > >> Allowing BOs to be write-cached results in the following happening when > >> trying to run any program on Tegra/GK20A: > >> > >> Unhandled fault: external abort on non-linefetch (0x1008) at 0xf0036010 > >> ... > >> (nouveau_bo_rd32) from [] (nouveau_fence_update+0x5c/0x80) > >> (nouveau_fence_update) from [] (nouveau_fence_done+0x1c/0x38) > >> (nouveau_fence_done) from [] (ttm_bo_wait+0xec/0x168) > >> (ttm_bo_wait) from [] (nouveau_gem_ioctl_cpu_prep+0x44/0x100) > >> (nouveau_gem_ioctl_cpu_prep) from [] (drm_ioctl+0x1d8/0x4f4) > >> (drm_ioctl) from [] (nouveau_drm_ioctl+0x54/0x80) > >> (nouveau_drm_ioctl) from [] (do_vfs_ioctl+0x3dc/0x5a0) > >> (do_vfs_ioctl) from [] (SyS_ioctl+0x34/0x5c) > >> (SyS_ioctl) from [] (ret_fast_syscall+0x0/0x30 > >> > >> The offending nouveau_bo_rd32 is done over an IO-mapped BO, e.g. a BO > >> mapped through the BAR. > >> > > Um wait, this memory is behind an already mapped bar? I think ioremap on > > ARM defaults to uncached mappings, so if you want to access the memory > > behind this bar as WC you need to map the BAR as a whole as WC by using > > ioremap_wc. > > Tried mapping the BAR using ioremap_wc(), but to no avail. On the other > hand, could it be that VRAM BOs end up creating a mapping over an > already-mapped region? I seem to remember that ARM might not like it... > >>> > >>> Multiple mapping are generally allowed, as long as they have the same > >>> caching state. It's conflicting mappings (uncached vs cached, or cached > >>> vs wc), that are documented to yield undefined results. > >> > >> Sorry about the confusion. The BAR is *not* mapped to the kernel yet > >> (it is BAR1, there is no BAR3 on GK20A) and an ioremap_*() is > >> performed in ttm_bo_ioremap() to make the part of the BAR where the > >> buffer is mapped visible. It seems that doing an ioremap_wc() on the > >> BAR area on Tegra is what leads to these errors. ioremap() or > >> ioremap_nocache() (which are in effect the same on ARM) do not cause > >> this issue. > >> > > It would be cool if you could ask HW, or the blob developers, if this is > > a general issue. The external abort is clearly the GPUs AXI client > > responding with an error to the read request, though I'm not clear where > > a WC read differs from an uncached one. > > Will check that. > > > > >> The best way to solve this issue would be to not use the BAR at all > >> since the memory behind these objects can be directly accessed by the > >> CPU. As such it would better be mapped using ttm_bo_kmap_ttm() > >> instead. But right now this is clearly not how nouveau_bo.c is written > >> and it does not look like this can easily be done. :/ > > > > Yeah, it sounds like we want this shortcut for stolen VRAM > > implementations. > > Actually, isn't it the case that we do not want to use TTM at all for > stolen VRAM (UMA) devices? > > I am trying to wrap my head around this since a while already, and could > not think of a way to use the current TTM-based nouveau_bo optimally for > GK20A. Because we cannot do without the idea of VRAM and GART, we will > always have to "move" objects from one location to another, or deal with > constraints that do not make sense for UMA devices (like in the current > case, accessing VRAM objects through the BAR). > > I am currently contemplating the idea of writing an alternative non-TTM > implementation of nouveau_bo for UMA devices, that would (hopefully) be > much simpler and would spare us a lot of stunts. > > On the other hand, this sounds like a considerable work and I would like > to make sure that my lack of understanding of TTM is not driving me to > the wrong solution. Thoughts? > You may want to make yourself aware of all the quirks required for sharing memory between the GPU and CPU on an ARM host. I think there are far more involved than what you see now and writing an replacement for TTM will not be an easy task. Doing away with the concept of two memory areas will not get you to a single unified address space. You would have to deal with things like not being able to change the caching state of pages in the systems lowmem yourself. You will still have to deal with remapping pages that aren't currently visible to the CPU (ok this is not an issue on Jetson right now as it only has
[PATCH 1/3] drm/crtc: Add property for aspect ratio
On May-22-2014 5:08 PM, Thierry Reding wrote:
> On Thu, May 22, 2014 at 04:50:48PM +0530, Vandana Kannan wrote:
>> Added a property to enable user space to set aspect ratio.
>> This patch contains declaration of the property and code to create the
>> property.
>>
>> Signed-off-by: Vandana Kannan
>> Cc: dri-devel at lists.freedesktop.org
>> ---
>> drivers/gpu/drm/drm_crtc.c | 31 +++
>> include/drm/drm_crtc.h | 2 ++
>> 2 files changed, 33 insertions(+)
>>
>> diff --git a/drivers/gpu/drm/drm_crtc.c b/drivers/gpu/drm/drm_crtc.c
>> index 37a3e07..84d359e 100644
>> --- a/drivers/gpu/drm/drm_crtc.c
>> +++ b/drivers/gpu/drm/drm_crtc.c
>> @@ -139,6 +139,12 @@ static const struct drm_prop_enum_list
>> drm_scaling_mode_enum_list[] =
>> { DRM_MODE_SCALE_ASPECT, "Full aspect" },
>> };
>>
>> +static const struct drm_prop_enum_list drm_aspect_ratio_enum_list[] = {
>> +{ HDMI_PICTURE_ASPECT_NONE, "Automatic" },
>> +{ HDMI_PICTURE_ASPECT_4_3, "4:3" },
>> +{ HDMI_PICTURE_ASPECT_16_9, "16:9" },
>> +};
>
> This seems like it should be either an HDMI specific property, since it
> uses values defined by HDMI/CEA. Alternatively we could introduce some
> new generic enumeration and translate that to the HDMI/CEA equivalent in
> the AVI infoframe helpers.
>
> Doing so would allow us to add aspect ratios different from what HDMI or
> CEA define.
>
>> /*
>> * Non-global properties, but "required" for certain connectors.
>> */
>> @@ -1344,6 +1350,31 @@ int drm_mode_create_scaling_mode_property(struct
>> drm_device *dev)
>> EXPORT_SYMBOL(drm_mode_create_scaling_mode_property);
>>
>> /**
>> + * drm_mode_create_aspect_ratio_property - create aspect ratio property
>> + * @dev: DRM device
>> + *
>> + * Called by a driver the first time it's needed, must be attached to
>> desired
>> + * connectors.
>> + */
>> +int drm_mode_create_aspect_ratio_property(struct drm_device *dev)
>> +{
>> +struct drm_property *aspect_ratio;
>> +
>> +if (dev->mode_config.aspect_ratio_property)
>> +return 0;
>> +
>> +aspect_ratio =
>> +drm_property_create_enum(dev, 0, "aspect ratio",
>> +drm_aspect_ratio_enum_list,
>> +ARRAY_SIZE(drm_aspect_ratio_enum_list));
>> +
>> +dev->mode_config.aspect_ratio_property = aspect_ratio;
>
> I don't think you need the temporary aspect_ratio variable here. Can't
> you directly assign the new property to .aspect_ratio_property?
>
> Thierry
>
Thanks for your inputs.
I will make the following changes and resend the patch..
- Make the enum generic and translate that to the HDMI/CEA equivalent
for AVI IF.
- Remove the temporary aspect_ratio variable.
Thanks,
Vandana
[PATCH 2/3] drm/edid: Check for user aspect ratio input
On May-22-2014 5:12 PM, Thierry Reding wrote: > On Thu, May 22, 2014 at 04:50:49PM +0530, Vandana Kannan wrote: >> In case user has specified an input for aspect ratio through the property, >> then the user space value for PAR would take preference over the value from >> CEA mode list. >> >> Signed-off-by: Vandana Kannan >> Cc: dri-devel at lists.freedesktop.org >> --- >> drivers/gpu/drm/drm_edid.c | 9 +++-- >> 1 file changed, 7 insertions(+), 2 deletions(-) >> >> diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c >> index 7a4fd2e..05db619 100644 >> --- a/drivers/gpu/drm/drm_edid.c >> +++ b/drivers/gpu/drm/drm_edid.c >> @@ -3657,8 +3657,13 @@ drm_hdmi_avi_infoframe_from_display_mode(struct >> hdmi_avi_infoframe *frame, >> >> frame->picture_aspect = HDMI_PICTURE_ASPECT_NONE; >> >> -/* Populate picture aspect ratio from CEA mode list */ >> -if (frame->video_code > 0) >> +/* Populate picture aspect ratio from either CEA mode list or >> + * user input >> +*/ > > This comment is mangled, it should look like this: > > /* >* Populate... >*/ > > And perhaps to clarify that user input takes precedence over CEA you > could list it first in the comment, like so for example: > > /* >* Populate picture aspect ratio from either user input (if specified) >* or from the CEA mode. >*/ > Sure, I will modify this comment > Also can you please resend patch 3/3 to dri-devel at lists.freedesktop.org > as well so we can see how this is used in a driver? > > Thierry > I have resent this patch including dri-devel at lists.freedesktop.org Thanks, Vandana
[Intel-gfx] [PATCH 1/3] drm/crtc: Add property for aspect ratio
On May-22-2014 5:46 PM, Daniel Vetter wrote:
> On Thu, May 22, 2014 at 04:50:48PM +0530, Vandana Kannan wrote:
>> Added a property to enable user space to set aspect ratio.
>> This patch contains declaration of the property and code to create the
>> property.
>>
>> Signed-off-by: Vandana Kannan
>> Cc: dri-devel at lists.freedesktop.org
>
> Documentation update is missing. Also for such patch series I recommend to
> post the entire patch series to dri-devel and intel-gfx. Otherwise people
> on dri-devel don't see how the new code is used and so can't really review
> it properly.
> -Daniel
>
Thanks for your inputs.
I will send the Documentation change along with the rest of the patches
(when I resend them).
Resent patch 3 adding dri-devel..
Thanks,
Vandana
>> ---
>> drivers/gpu/drm/drm_crtc.c | 31 +++
>> include/drm/drm_crtc.h | 2 ++
>> 2 files changed, 33 insertions(+)
>>
>> diff --git a/drivers/gpu/drm/drm_crtc.c b/drivers/gpu/drm/drm_crtc.c
>> index 37a3e07..84d359e 100644
>> --- a/drivers/gpu/drm/drm_crtc.c
>> +++ b/drivers/gpu/drm/drm_crtc.c
>> @@ -139,6 +139,12 @@ static const struct drm_prop_enum_list
>> drm_scaling_mode_enum_list[] =
>> { DRM_MODE_SCALE_ASPECT, "Full aspect" },
>> };
>>
>> +static const struct drm_prop_enum_list drm_aspect_ratio_enum_list[] = {
>> +{ HDMI_PICTURE_ASPECT_NONE, "Automatic" },
>> +{ HDMI_PICTURE_ASPECT_4_3, "4:3" },
>> +{ HDMI_PICTURE_ASPECT_16_9, "16:9" },
>> +};
>> +
>> /*
>> * Non-global properties, but "required" for certain connectors.
>> */
>> @@ -1344,6 +1350,31 @@ int drm_mode_create_scaling_mode_property(struct
>> drm_device *dev)
>> EXPORT_SYMBOL(drm_mode_create_scaling_mode_property);
>>
>> /**
>> + * drm_mode_create_aspect_ratio_property - create aspect ratio property
>> + * @dev: DRM device
>> + *
>> + * Called by a driver the first time it's needed, must be attached to
>> desired
>> + * connectors.
>> + */
>> +int drm_mode_create_aspect_ratio_property(struct drm_device *dev)
>> +{
>> +struct drm_property *aspect_ratio;
>> +
>> +if (dev->mode_config.aspect_ratio_property)
>> +return 0;
>> +
>> +aspect_ratio =
>> +drm_property_create_enum(dev, 0, "aspect ratio",
>> +drm_aspect_ratio_enum_list,
>> +ARRAY_SIZE(drm_aspect_ratio_enum_list));
>> +
>> +dev->mode_config.aspect_ratio_property = aspect_ratio;
>> +
>> +return 0;
>> +}
>> +EXPORT_SYMBOL(drm_mode_create_aspect_ratio_property);
>> +
>> +/**
>> * drm_mode_create_dirty_property - create dirty property
>> * @dev: DRM device
>> *
>> diff --git a/include/drm/drm_crtc.h b/include/drm/drm_crtc.h
>> index 5c1c31c..1149617 100644
>> --- a/include/drm/drm_crtc.h
>> +++ b/include/drm/drm_crtc.h
>> @@ -801,6 +801,7 @@ struct drm_mode_config {
>>
>> /* Optional properties */
>> struct drm_property *scaling_mode_property;
>> +struct drm_property *aspect_ratio_property;
>> struct drm_property *dirty_info_property;
>>
>> /* dumb ioctl parameters */
>> @@ -971,6 +972,7 @@ extern int drm_mode_create_dvi_i_properties(struct
>> drm_device *dev);
>> extern int drm_mode_create_tv_properties(struct drm_device *dev, int
>> num_formats,
>> char *formats[]);
>> extern int drm_mode_create_scaling_mode_property(struct drm_device *dev);
>> +extern int drm_mode_create_aspect_ratio_property(struct drm_device *dev);
>> extern int drm_mode_create_dirty_info_property(struct drm_device *dev);
>> extern const char *drm_get_encoder_name(const struct drm_encoder *encoder);
>>
>> --
>> 1.9.3
>>
>> ___
>> Intel-gfx mailing list
>> Intel-gfx at lists.freedesktop.org
>> http://lists.freedesktop.org/mailman/listinfo/intel-gfx
>
[PATCH] drm/exynos: remove redundant mutex_unlock
The patch fixes unlocking in exynos_drm_component_del.
Signed-off-by: Andrzej Hajda
---
Hi Inki,
This patch is based on exynos_drm_next branch.
Regards
Andrzej
---
drivers/gpu/drm/exynos/exynos_drm_drv.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/drivers/gpu/drm/exynos/exynos_drm_drv.c
b/drivers/gpu/drm/exynos/exynos_drm_drv.c
index 4cef88f..c5a401ae 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_drv.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_drv.c
@@ -417,7 +417,6 @@ void exynos_drm_component_del(struct device *dev,
if (dev == cdev->dev) {
list_del(&cdev->list);
kfree(cdev);
- mutex_unlock(&drm_component_lock);
break;
}
}
--
1.9.1
[PATCH] drm/exynos/fimd: allow multiplatform configuration
The patch removes dependency on !ARCH_MULTIPLATFORM. This dependency seems to be not longer valid. Signed-off-by: Andrzej Hajda --- drivers/gpu/drm/exynos/Kconfig | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/gpu/drm/exynos/Kconfig b/drivers/gpu/drm/exynos/Kconfig index c8c9510..e0d73fb 100644 --- a/drivers/gpu/drm/exynos/Kconfig +++ b/drivers/gpu/drm/exynos/Kconfig @@ -26,7 +26,7 @@ config DRM_EXYNOS_DMABUF config DRM_EXYNOS_FIMD bool "Exynos DRM FIMD" - depends on DRM_EXYNOS && !FB_S3C && !ARCH_MULTIPLATFORM + depends on DRM_EXYNOS && !FB_S3C select FB_MODE_HELPERS help Choose this option if you want to use Exynos FIMD for DRM. -- 1.9.1
[PATCH] drm/exynos: add fimd dependency to fimd related encoders
DPI, DSI and DP drivers will not work without FIMD. The patch adds appropriate dependencies in Kconfig. Signed-off-by: Andrzej Hajda --- drivers/gpu/drm/exynos/Kconfig | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/drivers/gpu/drm/exynos/Kconfig b/drivers/gpu/drm/exynos/Kconfig index e0d73fb..178d2a9 100644 --- a/drivers/gpu/drm/exynos/Kconfig +++ b/drivers/gpu/drm/exynos/Kconfig @@ -33,7 +33,7 @@ config DRM_EXYNOS_FIMD config DRM_EXYNOS_DPI bool "EXYNOS DRM parallel output support" - depends on DRM_EXYNOS + depends on DRM_EXYNOS_FIMD select DRM_PANEL default n help @@ -41,7 +41,7 @@ config DRM_EXYNOS_DPI config DRM_EXYNOS_DSI bool "EXYNOS DRM MIPI-DSI driver support" - depends on DRM_EXYNOS + depends on DRM_EXYNOS_FIMD select DRM_MIPI_DSI select DRM_PANEL default n @@ -50,7 +50,7 @@ config DRM_EXYNOS_DSI config DRM_EXYNOS_DP bool "EXYNOS DRM DP driver support" - depends on DRM_EXYNOS && ARCH_EXYNOS && (DRM_PTN3460=n || DRM_PTN3460=y || DRM_PTN3460=DRM_EXYNOS) + depends on DRM_EXYNOS_FIMD && ARCH_EXYNOS && (DRM_PTN3460=n || DRM_PTN3460=y || DRM_PTN3460=DRM_EXYNOS) default DRM_EXYNOS help This enables support for DP device. -- 1.9.1
[PATCH v4] drm/exynos: enable fimd clocks in probe before accessing fimd registers
Hi Andrej, On 23 May 2014 13:13, Andrzej Hajda wrote: > Hi Rahul, > > [snip] >> + clk_disable_unprepare(ctx->lcd_clk); >> + clk_disable_unprepare(ctx->bus_clk); >> + >> return 0; > > If you want to access fimd registers I guess pm_runtime_get_sync should > be called as well, to wake up display pm domain. > You are right. I have added pm runtime get sync and put sync. Regards, Rahul Sharma. > > Regards > Andrzej > > >> >> } >> >
[Bug 73528] Deferred lighting in Second Life causes system hiccups and screen flickering
https://bugs.freedesktop.org/show_bug.cgi?id=73528 --- Comment #7 from MirceaKitsune --- I brought this up on IRC last night, and was advised to do a GIT bisect or an apitrace. Since I have no idea when the issue started happening and I can't risk crashing my machine dozens of times, I can't try GIT bisect myself. I was however able to do an apitrace, which also produces the crash when played back. As requested, I packed it as an xz archive and uploaded it. This should allow anyone who can't try the Second Life viewer themselves to reproduce the crash. http://www.sendspace.com/file/oixqur Unpack that somewhere, then run the command "glretrace ./do-not-directly-run-kokua-bin.trace" from the same directory. Be prepared for a system freeze, and only do this on a machine where it's safe! Also, post a comment here if that link stops working, so I can re-post the trace file if needed. I crashed my machine 5 times in order to record this. So I'd appreciate it if someone could make the effort worth it and please test this more in depth, to see where the issue really takes place in the MESA code. -- 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/20140523/9ea32f2b/attachment.html>
[Bug 79100] r600 context creation failure on kaveri
https://bugs.freedesktop.org/show_bug.cgi?id=79100 Alex Deucher changed: What|Removed |Added Component|Drivers/Gallium/r600|Drivers/Gallium/radeonsi --- Comment #7 from Alex Deucher --- kaveri is supported by the radeonsi driver, not r600. Make sure you don't have the VDPAU_DRIVER=r600 set as an env var. You don't need to set that env var. The correct driver will automatically loaded automatically. -- 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/20140523/644ebd86/attachment.html>
Frame buffer and plane difference
See: http://people.freedesktop.org/~danvet/drm/drm-mode-setting.html#idp57325824 although the docbook probably should be updated (now that we have primary-planes) to read something more like: "...that provide a source of pixels to scanout to a plane" (since a plane is basically the part of display controller block that reads in the pixel data from the fb) On Thu, May 22, 2014 at 6:30 PM, Anand Sinha wrote: > Hello, > > Can someone help me understand the basic difference between a plane and a > frame buffer. > > Regards, > Anand > > > ___ > dri-devel mailing list > dri-devel at lists.freedesktop.org > http://lists.freedesktop.org/mailman/listinfo/dri-devel >
[PATCH] drm/exynos: add fimd dependency to fimd related encoders
On 2014? 05? 23? 19:59, Andrzej Hajda wrote: > DPI, DSI and DP drivers will not work without FIMD. > The patch adds appropriate dependencies in Kconfig. Applied. Thanks, Inki Dae > > Signed-off-by: Andrzej Hajda > --- > drivers/gpu/drm/exynos/Kconfig | 6 +++--- > 1 file changed, 3 insertions(+), 3 deletions(-) > > diff --git a/drivers/gpu/drm/exynos/Kconfig b/drivers/gpu/drm/exynos/Kconfig > index e0d73fb..178d2a9 100644 > --- a/drivers/gpu/drm/exynos/Kconfig > +++ b/drivers/gpu/drm/exynos/Kconfig > @@ -33,7 +33,7 @@ config DRM_EXYNOS_FIMD > > config DRM_EXYNOS_DPI > bool "EXYNOS DRM parallel output support" > - depends on DRM_EXYNOS > + depends on DRM_EXYNOS_FIMD > select DRM_PANEL > default n > help > @@ -41,7 +41,7 @@ config DRM_EXYNOS_DPI > > config DRM_EXYNOS_DSI > bool "EXYNOS DRM MIPI-DSI driver support" > - depends on DRM_EXYNOS > + depends on DRM_EXYNOS_FIMD > select DRM_MIPI_DSI > select DRM_PANEL > default n > @@ -50,7 +50,7 @@ config DRM_EXYNOS_DSI > > config DRM_EXYNOS_DP > bool "EXYNOS DRM DP driver support" > - depends on DRM_EXYNOS && ARCH_EXYNOS && (DRM_PTN3460=n || DRM_PTN3460=y > || DRM_PTN3460=DRM_EXYNOS) > + depends on DRM_EXYNOS_FIMD && ARCH_EXYNOS && (DRM_PTN3460=n || > DRM_PTN3460=y || DRM_PTN3460=DRM_EXYNOS) > default DRM_EXYNOS > help > This enables support for DP device. >
[PATCH] drm/exynos: remove redundant mutex_unlock
On 2014? 05? 23? 19:57, Andrzej Hajda wrote:
> The patch fixes unlocking in exynos_drm_component_del.
Applied.
Thanks,
Inki Dae
>
> Signed-off-by: Andrzej Hajda
> ---
> Hi Inki,
>
> This patch is based on exynos_drm_next branch.
>
> Regards
> Andrzej
> ---
> drivers/gpu/drm/exynos/exynos_drm_drv.c | 1 -
> 1 file changed, 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/exynos/exynos_drm_drv.c
> b/drivers/gpu/drm/exynos/exynos_drm_drv.c
> index 4cef88f..c5a401ae 100644
> --- a/drivers/gpu/drm/exynos/exynos_drm_drv.c
> +++ b/drivers/gpu/drm/exynos/exynos_drm_drv.c
> @@ -417,7 +417,6 @@ void exynos_drm_component_del(struct device *dev,
> if (dev == cdev->dev) {
> list_del(&cdev->list);
> kfree(cdev);
> - mutex_unlock(&drm_component_lock);
> break;
> }
> }
>
[RFC] drm/nouveau: disable caching for VRAM BOs on ARM
On 05/23/2014 06:59 PM, Lucas Stach wrote: > Am Freitag, den 23.05.2014, 18:43 +0900 schrieb Alexandre Courbot: >> On 05/23/2014 06:24 PM, Lucas Stach wrote: >>> Am Freitag, den 23.05.2014, 16:10 +0900 schrieb Alexandre Courbot: On Mon, May 19, 2014 at 7:16 PM, Lucas Stach wrote: > Am Montag, den 19.05.2014, 19:06 +0900 schrieb Alexandre Courbot: >> On 05/19/2014 06:57 PM, Lucas Stach wrote: >>> Am Montag, den 19.05.2014, 18:46 +0900 schrieb Alexandre Courbot: This patch is not meant to be merged, but rather to try and understand why this is needed and what a more suitable solution could be. Allowing BOs to be write-cached results in the following happening when trying to run any program on Tegra/GK20A: Unhandled fault: external abort on non-linefetch (0x1008) at 0xf0036010 ... (nouveau_bo_rd32) from [] (nouveau_fence_update+0x5c/0x80) (nouveau_fence_update) from [] (nouveau_fence_done+0x1c/0x38) (nouveau_fence_done) from [] (ttm_bo_wait+0xec/0x168) (ttm_bo_wait) from [] (nouveau_gem_ioctl_cpu_prep+0x44/0x100) (nouveau_gem_ioctl_cpu_prep) from [] (drm_ioctl+0x1d8/0x4f4) (drm_ioctl) from [] (nouveau_drm_ioctl+0x54/0x80) (nouveau_drm_ioctl) from [] (do_vfs_ioctl+0x3dc/0x5a0) (do_vfs_ioctl) from [] (SyS_ioctl+0x34/0x5c) (SyS_ioctl) from [] (ret_fast_syscall+0x0/0x30 The offending nouveau_bo_rd32 is done over an IO-mapped BO, e.g. a BO mapped through the BAR. >>> Um wait, this memory is behind an already mapped bar? I think ioremap on >>> ARM defaults to uncached mappings, so if you want to access the memory >>> behind this bar as WC you need to map the BAR as a whole as WC by using >>> ioremap_wc. >> >> Tried mapping the BAR using ioremap_wc(), but to no avail. On the other >> hand, could it be that VRAM BOs end up creating a mapping over an >> already-mapped region? I seem to remember that ARM might not like it... > > Multiple mapping are generally allowed, as long as they have the same > caching state. It's conflicting mappings (uncached vs cached, or cached > vs wc), that are documented to yield undefined results. Sorry about the confusion. The BAR is *not* mapped to the kernel yet (it is BAR1, there is no BAR3 on GK20A) and an ioremap_*() is performed in ttm_bo_ioremap() to make the part of the BAR where the buffer is mapped visible. It seems that doing an ioremap_wc() on the BAR area on Tegra is what leads to these errors. ioremap() or ioremap_nocache() (which are in effect the same on ARM) do not cause this issue. >>> It would be cool if you could ask HW, or the blob developers, if this is >>> a general issue. The external abort is clearly the GPUs AXI client >>> responding with an error to the read request, though I'm not clear where >>> a WC read differs from an uncached one. >> >> Will check that. So after checking with more knowledgeable people, it turns out this is the expected behavior on ARM and BAR regions should be mapped uncached on GK20A. All the more reasons to avoid using the BAR at all. >> >>> The best way to solve this issue would be to not use the BAR at all since the memory behind these objects can be directly accessed by the CPU. As such it would better be mapped using ttm_bo_kmap_ttm() instead. But right now this is clearly not how nouveau_bo.c is written and it does not look like this can easily be done. :/ >>> >>> Yeah, it sounds like we want this shortcut for stolen VRAM >>> implementations. >> >> Actually, isn't it the case that we do not want to use TTM at all for >> stolen VRAM (UMA) devices? >> >> I am trying to wrap my head around this since a while already, and could >> not think of a way to use the current TTM-based nouveau_bo optimally for >> GK20A. Because we cannot do without the idea of VRAM and GART, we will >> always have to "move" objects from one location to another, or deal with >> constraints that do not make sense for UMA devices (like in the current >> case, accessing VRAM objects through the BAR). >> >> I am currently contemplating the idea of writing an alternative non-TTM >> implementation of nouveau_bo for UMA devices, that would (hopefully) be >> much simpler and would spare us a lot of stunts. >> >> On the other hand, this sounds like a considerable work and I would like >> to make sure that my lack of understanding of TTM is not driving me to >> the wrong solution. Thoughts? >> > You may want to make yourself aware of all the quirks required for > sharing memory between the GPU and CPU on an ARM host. I think there are > far more involved than what you see now and writing an replacement for > TTM will not be an easy task. > > Doing away with the concept of two memory areas will not get you to a > single unified address space. Y
[PATCH] radeon: Remove useless quirk for zx1/FireGL X1 combo introduced with fdo #7770
On Thu, May 22, 2014 at 5:39 PM, ?meric MASCHINO
wrote:
> Removes useless quirk a7f465f73363fce409870f62173d518b1bc02ae6 introduced with
> fdo #7770 as a failed attempt to minimize stability issues with hp zx1
> chipset/
> ATI FireGL X1 graphics adapter configuration
> (see http://marc.info/?l=linux-ia64&m=140077543819871&w=2 for details/reason)
>
> Signed-off-by: ?meric MASCHINO
Your patch was mangled, but I was able to apply it manually. Please
fix your git email setup. Thanks!
Alex
> ---
>
> diff --git a/drivers/gpu/drm/radeon/radeon_agp.c
> b/drivers/gpu/drm/radeon/radeon_agp.c
> index 4243334..a9297b2 100644
> --- a/drivers/gpu/drm/radeon/radeon_agp.c
> +++ b/drivers/gpu/drm/radeon/radeon_agp.c
> @@ -117,9 +117,6 @@ static struct radeon_agpmode_quirk
> radeon_agpmode_quirk_list[] = {
> /* ATI Host Bridge / RV280 [M9+] Needs AGPMode 1 (phoronix forum) */
> { PCI_VENDOR_ID_ATI, 0xcbb2, PCI_VENDOR_ID_ATI, 0x5c61,
> PCI_VENDOR_ID_SONY, 0x8175, 1},
> -/* HP Host Bridge / R300 [FireGL X1] Needs AGPMode 2 (fdo #7770) */
> -{ PCI_VENDOR_ID_HP, 0x122e, PCI_VENDOR_ID_ATI, 0x4e47,
> -PCI_VENDOR_ID_ATI, 0x0152, 2},
> { 0, 0, 0, 0, 0, 0, 0 },
> };
> #endif
>
> 2014-05-22 23:37 GMT+02:00 ?meric MASCHINO :
>> Oops,
>>
>> Sorry for the double-post, but the bounce from the sourceforge address
>> let me think that the old list was completely disabled. Well, it seems
>> that mailing to the sourceforge address are forwarded to fdo.
>>
>> Furthermore, it seems that submitting a patch as an attachment to a
>> message, as outlined in the "Submitting patches" section of the dri/
>> GettingStarted page is not the correct way to do [1]:
>>
>> "Submit a patch by posting it to the dri-devel mailing list as an
>> attachment to a message. Make sure you explain clearly what your patch
>> is for."
>>
>> I'll thus repost my patch as clear text in another message.
>>
>> ?meric
>>
>>
>> [1] http://dri.freedesktop.org/wiki/GettingStarted/
> ___
> dri-devel mailing list
> dri-devel at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 78453] [HAWAII] Get acceleration working
https://bugs.freedesktop.org/show_bug.cgi?id=78453 --- Comment #61 from vincent --- Created attachment 99652 --> https://bugs.freedesktop.org/attachment.cgi?id=99652&action=edit dmesg kernel 3.12+ test=2 Sorry I forget test=2 case, dmesg attached, radeon_fence_info is : --- ring 0 --- Last signaled fence 0x0001 Last emitted0x0003 Last sync to ring 1 0x Last sync to ring 2 0x Last sync to ring 3 0x Last sync to ring 4 0x Last sync to ring 5 0x --- ring 1 --- Last signaled fence 0x0003 Last emitted0x0003 Last sync to ring 0 0x Last sync to ring 2 0x Last sync to ring 3 0x Last sync to ring 4 0x Last sync to ring 5 0x --- ring 2 --- Last signaled fence 0x0001 Last emitted0x0001 Last sync to ring 0 0x Last sync to ring 1 0x Last sync to ring 3 0x Last sync to ring 4 0x Last sync to ring 5 0x --- ring 3 --- Last signaled fence 0x0001 Last emitted0x0001 Last sync to ring 0 0x Last sync to ring 1 0x Last sync to ring 2 0x Last sync to ring 4 0x Last sync to ring 5 0x --- ring 4 --- Last signaled fence 0x0001 Last emitted0x0001 Last sync to ring 0 0x Last sync to ring 1 0x Last sync to ring 2 0x Last sync to ring 3 0x Last sync to ring 5 0x --- ring 5 --- Last signaled fence 0x0002 Last emitted0x0002 Last sync to ring 0 0x Last sync to ring 1 0x Last sync to ring 2 0x Last sync to ring 3 0x Last sync to ring 4 0x -- 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/20140523/23af95de/attachment.html>
[Bug 78453] [HAWAII] Get acceleration working
https://bugs.freedesktop.org/show_bug.cgi?id=78453 --- Comment #62 from vincent --- What are rings 1 and rings 2 ? I suspect one of the ring is the constant engine but I'm not sure if it's currently supported or not. I've read that hawaii has something a gfx/compute command queue and 7 compute only command queue, does they use the same ring ? -- 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/20140523/26cd2cc5/attachment-0001.html>
[Bug 78453] [HAWAII] Get acceleration working
https://bugs.freedesktop.org/show_bug.cgi?id=78453 --- Comment #63 from Alex Deucher --- (In reply to comment #62) > What are rings 1 and rings 2 ? I suspect one of the ring is the constant > engine but I'm not sure if it's currently supported or not. > 1 and 2 are compute rings. The constant engine is part of the gfx ring. > I've read that hawaii has something a gfx/compute command queue and 7 > compute only command queue, does they use the same ring ? The gfx ring can execute gfx or compute work. There are many compute rings on CI hardware, but we currently only expose two. -- 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/20140523/ffdddbae/attachment.html>
[PATCH] drm/exynos: add phy settings for exynos5420
This patch adds phy settings of the below
mentioned pixel clocks in Exynos5420:
85.5 MHz- 1366x768 at 60Hz
162 MHz - 1600x1200 at 60Hz
Signed-off-by: Shirish S
---
drivers/gpu/drm/exynos/exynos_hdmi.c | 18 ++
1 file changed, 18 insertions(+)
diff --git a/drivers/gpu/drm/exynos/exynos_hdmi.c
b/drivers/gpu/drm/exynos/exynos_hdmi.c
index e05c86a..07ba387 100644
--- a/drivers/gpu/drm/exynos/exynos_hdmi.c
+++ b/drivers/gpu/drm/exynos/exynos_hdmi.c
@@ -523,6 +523,15 @@ static const struct hdmiphy_config hdmiphy_5420_configs[]
= {
},
},
{
+ .pixel_clock = 8550,
+ .conf = {
+ 0x01, 0xd1, 0x24, 0x11, 0x40, 0x40, 0xd0, 0xc8,
+ 0x84, 0xe8, 0xd6, 0xd8, 0x45, 0xa0, 0xac, 0x80,
+ 0x08, 0x80, 0x09, 0x84, 0x05, 0x02, 0x24, 0x86,
+ 0x54, 0x90, 0x24, 0x01, 0x00, 0x00, 0x01, 0x80,
+ },
+ },
+ {
.pixel_clock = 8875,
.conf = {
0x01, 0xD1, 0x25, 0x11, 0x40, 0x18, 0xFF, 0xC8,
@@ -576,6 +585,15 @@ static const struct hdmiphy_config hdmiphy_5420_configs[]
= {
0x54, 0x4B, 0x25, 0x03, 0x00, 0x80, 0x01, 0x80,
},
},
+ {
+ .pixel_clock = 16200,
+ .conf = {
+ 0x01, 0x54, 0x87, 0x05, 0x40, 0x01, 0x00, 0xc8,
+ 0x82, 0xc8, 0xcb, 0xd8, 0x45, 0xa0, 0xac, 0x80,
+ 0x08, 0x80, 0x09, 0x84, 0x05, 0x02, 0x24, 0x86,
+ 0x54, 0x4c, 0x24, 0x01, 0x00, 0x00, 0x01, 0x80,
+ },
+ },
};
static struct hdmi_driver_data exynos5420_hdmi_driver_data = {
--
1.7.9.5
[PATCH] drm/exynos/fimd: allow multiplatform configuration
On 23 May 2014 16:28, Andrzej Hajda wrote: > The patch removes dependency on !ARCH_MULTIPLATFORM. > This dependency seems to be not longer valid. > > Signed-off-by: Andrzej Hajda Reviewed-by: Sachin Kamat -- With warm regards, Sachin
[PATCH 3/4] drm/nouveau: hook up cache sync functions
On Mon, May 19, 2014 at 5:46 PM, Thierry Reding
wrote:
> On Mon, May 19, 2014 at 04:10:57PM +0900, Alexandre Courbot wrote:
>> From: Lucas Stach
>>
>> Signed-off-by: Lucas Stach
>> [acourbot at nvidia.com: make conditional and platform-friendly]
>> Signed-off-by: Alexandre Courbot
>
> Perhaps having a propery commit message here would be good.
>
>> diff --git a/drivers/gpu/drm/nouveau/nouveau_bo.c
>> b/drivers/gpu/drm/nouveau/nouveau_bo.c
> [...]
>> +#ifdef NOUVEAU_NEED_CACHE_SYNC
>> +void
>> +nouveau_bo_sync_for_cpu(struct nouveau_bo *nvbo)
>> +{
>> + struct nouveau_device *device;
>> + struct ttm_tt *ttm = nvbo->bo.ttm;
>> +
>> + device = nouveau_dev(nouveau_bdev(ttm->bdev)->dev);
>> +
>> + if (nvbo->bo.ttm && nvbo->bo.ttm->caching_state == tt_cached)
>> + ttm_dma_tt_cache_sync_for_cpu((struct ttm_dma_tt
>> *)nvbo->bo.ttm,
>> + nv_device_base(device));
>
> Can we be certain at this point that the struct ttm_tt is in fact a
> struct ttm_dma_tt?
>
>> diff --git a/drivers/gpu/drm/nouveau/nouveau_bo.h
>> b/drivers/gpu/drm/nouveau/nouveau_bo.h
> [...]
>> +#if IS_ENABLED(CONFIG_ARCH_TEGRA)
>> +#define NOUVEAU_NEED_CACHE_SYNC
>> +#endif
>
> I know I gave this as an example myself when we discussed this offline,
> but I'm now thinking that this might actually be better off in Kconfig.
>
>> +#ifdef NOUVEAU_NEED_CACHE_SYNC
>> +void nouveau_bo_sync_for_cpu(struct nouveau_bo *);
>> +void nouveau_bo_sync_for_device(struct nouveau_bo *);
>> +#else
>> +static inline void
>> +nouveau_bo_sync_for_cpu(struct nouveau_bo *)
>> +{
>> +}
>> +
>> +static inline void
>> +nouveau_bo_sync_for_device(struct nouveau_bo *)
>> +{
>> +}
>> +#endif
>> +
>> +
>
> There's a gratuituous blank line here.
Fixed.
>
>> diff --git a/drivers/gpu/drm/nouveau/nouveau_gem.c
>> b/drivers/gpu/drm/nouveau/nouveau_gem.c
>> index c90c0dc0afe8..b7e42fdc9634 100644
>> --- a/drivers/gpu/drm/nouveau/nouveau_gem.c
>> +++ b/drivers/gpu/drm/nouveau/nouveau_gem.c
>> @@ -897,7 +897,13 @@ nouveau_gem_ioctl_cpu_prep(struct drm_device *dev, void
>> *data,
>> ret = ttm_bo_wait(&nvbo->bo, true, true, no_wait);
>> spin_unlock(&nvbo->bo.bdev->fence_lock);
>> drm_gem_object_unreference_unlocked(gem);
>> - return ret;
>> +
>> + if (ret)
>> + return ret;
>> +
>> + nouveau_bo_sync_for_cpu(nvbo);
>> +
>> + return 0;
>> }
>
> This could be rewritten as:
>
> if (!ret)
> nouveau_bo_sync_for_cpu(nvbo);
>
> return ret;
>
> Which would be slightly shorter.
I prefer to have a clear, easy to read code flow here by keeping
error-handling within conditions (and not the other way round). This
kind of optimization is very well done by the compiler.
>
> On second thought, perhaps part of nouveau_gem_ioctl_cpu_prep() could be
> refactored into a separate function to make this more symmetric. If we
> put that in nouveau_bo.c and name it nouveau_bo_wait() for example, the
> dummies can go away and both nouveau_bo_sync_for_{cpu,device}() can be
> made static. I also think that's cleaner because it has both variants of
> the nouveau_bo_sync_for_*() calls in the same file.
Yep, agreed. I will give it a try in the next version of the series.
Thanks,
Alex.
[PATCH 3/4] drm/nouveau: hook up cache sync functions
On Mon, May 19, 2014 at 6:31 PM, Lucas Stach wrote:
> Am Montag, den 19.05.2014, 16:10 +0900 schrieb Alexandre Courbot:
>> From: Lucas Stach
>>
>> Signed-off-by: Lucas Stach
>> [acourbot at nvidia.com: make conditional and platform-friendly]
>> Signed-off-by: Alexandre Courbot
>> ---
>> drivers/gpu/drm/nouveau/nouveau_bo.c | 32
>> drivers/gpu/drm/nouveau/nouveau_bo.h | 20
>> drivers/gpu/drm/nouveau/nouveau_gem.c | 8 +++-
>> 3 files changed, 59 insertions(+), 1 deletion(-)
>>
>> diff --git a/drivers/gpu/drm/nouveau/nouveau_bo.c
>> b/drivers/gpu/drm/nouveau/nouveau_bo.c
>> index b6dc85c614be..0886f47e5244 100644
>> --- a/drivers/gpu/drm/nouveau/nouveau_bo.c
>> +++ b/drivers/gpu/drm/nouveau/nouveau_bo.c
>> @@ -407,6 +407,8 @@ nouveau_bo_validate(struct nouveau_bo *nvbo, bool
>> interruptible,
>> {
>> int ret;
>>
>> + nouveau_bo_sync_for_device(nvbo);
>> +
>> ret = ttm_bo_validate(&nvbo->bo, &nvbo->placement,
>> interruptible, no_wait_gpu);
>> if (ret)
>> @@ -487,6 +489,36 @@ nouveau_bo_invalidate_caches(struct ttm_bo_device
>> *bdev, uint32_t flags)
>> return 0;
>> }
>>
>> +#ifdef NOUVEAU_NEED_CACHE_SYNC
>
> I don't like this ifdef at all. I know calling this functions will add a
> little overhead to x86 where it isn't strictly required, but I think
> it's negligible.
>
> When I looked at them the dma_sync_single_for_[device|cpu] functions
> which are called here map out to just a drain of the PCI store buffer on
> x86, which should be fast enough to be done unconditionally. They won't
> so any time-consuming cache synchronization on PCI coherent arches.
If Ben agrees with it I am also perfectly fine with getting rid of this #ifdef.
[PATCH 4/4] drm/nouveau: introduce CPU cache flushing macro
On Mon, May 19, 2014 at 7:03 PM, Thierry Reding
wrote:
> On Mon, May 19, 2014 at 11:22:11AM +0200, Lucas Stach wrote:
>> Am Montag, den 19.05.2014, 11:02 +0200 schrieb Thierry Reding:
>> > On Mon, May 19, 2014 at 04:10:58PM +0900, Alexandre Courbot wrote:
>> > > Some architectures (e.g. ARM) need the CPU buffers to be explicitely
>> > > flushed for a memory write to take effect. Not doing so results in
>> > > synchronization issues, especially after writing to BOs.
>> >
>> > It seems to me that the above is generally true for all architectures,
>> > not just ARM.
>> >
>> No, on PCI coherent arches, like x86 and some PowerPCs, the GPU will
>> snoop the CPU caches and therefore an explicit cache flush is not
>> required.
>
> I was criticizing the wording in the commit message. Perhaps it could be
> enhanced with what you just said.
>
>> > > diff --git a/drivers/gpu/drm/nouveau/nouveau_bo.c
>> > > b/drivers/gpu/drm/nouveau/nouveau_bo.c
>> > [...]
>> > > index 0886f47e5244..b9c9729c5733 100644
>> > > --- a/drivers/gpu/drm/nouveau/nouveau_bo.c
>> > > +++ b/drivers/gpu/drm/nouveau/nouveau_bo.c
>> > > @@ -437,8 +437,10 @@ nouveau_bo_wr16(struct nouveau_bo *nvbo, unsigned
>> > > index, u16 val)
>> > > mem = &mem[index];
>> > > if (is_iomem)
>> > > iowrite16_native(val, (void __force __iomem *)mem);
>> > > - else
>> > > + else {
>> > > *mem = val;
>> > > + nv_cpu_cache_flush_area(mem, 2);
>> > > + }
>> > > }
>> > >
>> > > u32
>> > > @@ -461,8 +463,10 @@ nouveau_bo_wr32(struct nouveau_bo *nvbo, unsigned
>> > > index, u32 val)
>> > > mem = &mem[index];
>> > > if (is_iomem)
>> > > iowrite32_native(val, (void __force __iomem *)mem);
>> > > - else
>> > > + else {
>> > > *mem = val;
>> > > + nv_cpu_cache_flush_area(mem, 4);
>> > > + }
>> >
>> > This looks rather like a sledgehammer to me. Effectively this turns nvbo
>> > into an uncached buffer. With additional overhead of constantly flushing
>> > caches. Wouldn't it make more sense to locate the places where these are
>> > called and flush the cache after all the writes have completed?
>> >
>> I don't think the explicit flushing for those things makes sense. I
>> think it is a lot more effective to just map the BOs write-combined on
>> PCI non-coherent arches. This way any writes will be buffered. Reads
>> will be slow, but I don't think nouveau is reading back a lot from those
>> buffers.
>> Using the write-combining buffer doesn't need any additional
>> synchronization as it will get flushed on pushbuf kickoff anyways.
>
> Sounds good to me.
I will need to wrap my head around TTM some more to understand how to
do this the right way, but it is true that brute-forcing in-memory BO
mappings to be WC make the addition of nv_cpu_cache_flush_area()
unneeded. Is that the direction we want to take with this?
[RFC] drm/nouveau: disable caching for VRAM BOs on ARM
On Mon, May 19, 2014 at 7:16 PM, Lucas Stach wrote: > Am Montag, den 19.05.2014, 19:06 +0900 schrieb Alexandre Courbot: >> On 05/19/2014 06:57 PM, Lucas Stach wrote: >> > Am Montag, den 19.05.2014, 18:46 +0900 schrieb Alexandre Courbot: >> >> This patch is not meant to be merged, but rather to try and understand >> >> why this is needed and what a more suitable solution could be. >> >> >> >> Allowing BOs to be write-cached results in the following happening when >> >> trying to run any program on Tegra/GK20A: >> >> >> >> Unhandled fault: external abort on non-linefetch (0x1008) at 0xf0036010 >> >> ... >> >> (nouveau_bo_rd32) from [] (nouveau_fence_update+0x5c/0x80) >> >> (nouveau_fence_update) from [] (nouveau_fence_done+0x1c/0x38) >> >> (nouveau_fence_done) from [] (ttm_bo_wait+0xec/0x168) >> >> (ttm_bo_wait) from [] (nouveau_gem_ioctl_cpu_prep+0x44/0x100) >> >> (nouveau_gem_ioctl_cpu_prep) from [] (drm_ioctl+0x1d8/0x4f4) >> >> (drm_ioctl) from [] (nouveau_drm_ioctl+0x54/0x80) >> >> (nouveau_drm_ioctl) from [] (do_vfs_ioctl+0x3dc/0x5a0) >> >> (do_vfs_ioctl) from [] (SyS_ioctl+0x34/0x5c) >> >> (SyS_ioctl) from [] (ret_fast_syscall+0x0/0x30 >> >> >> >> The offending nouveau_bo_rd32 is done over an IO-mapped BO, e.g. a BO >> >> mapped through the BAR. >> >> >> > Um wait, this memory is behind an already mapped bar? I think ioremap on >> > ARM defaults to uncached mappings, so if you want to access the memory >> > behind this bar as WC you need to map the BAR as a whole as WC by using >> > ioremap_wc. >> >> Tried mapping the BAR using ioremap_wc(), but to no avail. On the other >> hand, could it be that VRAM BOs end up creating a mapping over an >> already-mapped region? I seem to remember that ARM might not like it... > > Multiple mapping are generally allowed, as long as they have the same > caching state. It's conflicting mappings (uncached vs cached, or cached > vs wc), that are documented to yield undefined results. Sorry about the confusion. The BAR is *not* mapped to the kernel yet (it is BAR1, there is no BAR3 on GK20A) and an ioremap_*() is performed in ttm_bo_ioremap() to make the part of the BAR where the buffer is mapped visible. It seems that doing an ioremap_wc() on the BAR area on Tegra is what leads to these errors. ioremap() or ioremap_nocache() (which are in effect the same on ARM) do not cause this issue. The best way to solve this issue would be to not use the BAR at all since the memory behind these objects can be directly accessed by the CPU. As such it would better be mapped using ttm_bo_kmap_ttm() instead. But right now this is clearly not how nouveau_bo.c is written and it does not look like this can easily be done. :/
[PATCH 2/5] ARM: tegra: of: add GK20A device tree binding
On Tue, May 20, 2014 at 6:14 AM, Stephen Warren
wrote:
> On 05/19/2014 03:24 AM, Alexandre Courbot wrote:
>> Add the device tree binding documentation for the GK20A GPU used in
>> Tegra K1 SoCs.
>
> A few minor nits, but otherwise,
> Acked-by: Stephen Warren
>
>> diff --git a/Documentation/devicetree/bindings/gpu/nvidia,gk20a.txt
>> b/Documentation/devicetree/bindings/gpu/nvidia,gk20a.txt
>
>> +Required properties:
>> +- compatible: "nvidia,-"
>> + Currently recognized values:
>> + - nvidia,tegra124-gk20a
>> +- reg: Physical base address and length of the controller's registers.
>> + Must contain two entries:
>> + - first entry for bar0
>> + - second entry for bar1
>> +- interrupts: The interrupt outputs from the controller.
>
> To be consistent with the clocks and resets properties, it'd be nice to
> reword that as:
>
> interrupts: Must contain an entry for each entry in interrupt-names.
>
>> +- interrupt-names: Must include the following entries:
>
> ... and add the following here:
>
> See ../interrupt-controller/interrupts.txt
>
>> +/ {
>
> No need to wrap a root node around this in the example.
>
>> + gpu at 0,5700 {
> ...
>> + };
>> +
>
> Extra blank line here.
>
>> +};
>
All fixed and acked-by added to the commit log.
Thanks,
Alex.
[PATCH 2/3] drm/exynos: Remove duplicate inclusion of i2c.h
Hi Andrzej, On 23 May 2014 13:17, Andrzej Hajda wrote: > Hi Sachin, > > On 05/22/2014 07:02 AM, Sachin Kamat wrote: >> i2c.h was included twice. >> >> Signed-off-by: Sachin Kamat >> --- >> drivers/gpu/drm/exynos/exynos_hdmi.c |1 - >> 1 file changed, 1 deletion(-) >> >> diff --git a/drivers/gpu/drm/exynos/exynos_hdmi.c >> b/drivers/gpu/drm/exynos/exynos_hdmi.c >> index ed6176e..d3f9684 100644 >> --- a/drivers/gpu/drm/exynos/exynos_hdmi.c >> +++ b/drivers/gpu/drm/exynos/exynos_hdmi.c >> @@ -34,7 +34,6 @@ >> #include >> #include >> #include >> -#include >> #include >> #include >> #include >> > > It would be also good to order headers alphabetically. That is outside the scope of this patch and can be taken up separately if needed. -- With warm regards, Sachin
[PATCH] drm/exynos: remove redundant mutex_unlock
Hi Andrzej,
On 23 May 2014 16:27, Andrzej Hajda wrote:
> The patch fixes unlocking in exynos_drm_component_del.
This patch actually removes multiple unlocking issue.
>
> Signed-off-by: Andrzej Hajda
> ---
> Hi Inki,
>
> This patch is based on exynos_drm_next branch.
>
> Regards
> Andrzej
> ---
> drivers/gpu/drm/exynos/exynos_drm_drv.c | 1 -
> 1 file changed, 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/exynos/exynos_drm_drv.c
> b/drivers/gpu/drm/exynos/exynos_drm_drv.c
> index 4cef88f..c5a401ae 100644
> --- a/drivers/gpu/drm/exynos/exynos_drm_drv.c
> +++ b/drivers/gpu/drm/exynos/exynos_drm_drv.c
> @@ -417,7 +417,6 @@ void exynos_drm_component_del(struct device *dev,
> if (dev == cdev->dev) {
> list_del(&cdev->list);
> kfree(cdev);
> - mutex_unlock(&drm_component_lock);
> break;
> }
> }
> --
> 1.9.1
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc"
> in
> the body of a message to majordomo at vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
--
With warm regards,
Sachin
[RESEND PATCH] drm: Add 800x600 (SVGA) screen resolution to the built-in EDIDs
The 800x600 (SVGA) screen resolution was lacking in the set of built-in selectable EDID screen resolutions that can be used to repair misbehaving monitor firmware. This patch adds the related data set and expands the documentation. Note that the SVGA bit occupies a different byte to all the existing users of the established timing bits forcing a rework of the ESTABLISHED_TIMINGS_BITS macro. Tested new EDID on an aged (and misbehaving) industrial LCD panel; existing EDIDs still pass edid-decode's checksum checks. Signed-off-by: Daniel Thompson Cc: Randy Dunlap Cc: David Airlie Cc: Carsten Emde Cc: linux-doc at vger.kernel.org Cc: dri-devel at lists.freedesktop.org Reviewed-by: Alex Deucher --- Documentation/EDID/1024x768.S | 2 +- Documentation/EDID/1280x1024.S | 2 +- Documentation/EDID/1600x1200.S | 2 +- Documentation/EDID/1680x1050.S | 2 +- Documentation/EDID/1920x1080.S | 2 +- Documentation/EDID/800x600.S| 41 + Documentation/EDID/HOWTO.txt| 2 +- Documentation/EDID/edid.S | 17 ++--- drivers/gpu/drm/drm_edid_load.c | 21 - 9 files changed, 81 insertions(+), 10 deletions(-) create mode 100644 Documentation/EDID/800x600.S diff --git a/Documentation/EDID/1024x768.S b/Documentation/EDID/1024x768.S index 4b486fe..6f3e4b7 100644 --- a/Documentation/EDID/1024x768.S +++ b/Documentation/EDID/1024x768.S @@ -36,7 +36,7 @@ #define DPI 72 #define VFREQ 60 /* Hz */ #define TIMING_NAME "Linux XGA" -#define ESTABLISHED_TIMINGS_BITS 0x08 /* Bit 3 -> 1024x768 @60 Hz */ +#define ESTABLISHED_TIMING2_BITS 0x08 /* Bit 3 -> 1024x768 @60 Hz */ #define HSYNC_POL 0 #define VSYNC_POL 0 #define CRC 0x55 diff --git a/Documentation/EDID/1280x1024.S b/Documentation/EDID/1280x1024.S index a2799fe..bd9bef2 100644 --- a/Documentation/EDID/1280x1024.S +++ b/Documentation/EDID/1280x1024.S @@ -36,7 +36,7 @@ #define DPI 72 #define VFREQ 60 /* Hz */ #define TIMING_NAME "Linux SXGA" -#define ESTABLISHED_TIMINGS_BITS 0x00 /* none */ +/* No ESTABLISHED_TIMINGx_BITS */ #define HSYNC_POL 1 #define VSYNC_POL 1 #define CRC 0xa0 diff --git a/Documentation/EDID/1600x1200.S b/Documentation/EDID/1600x1200.S index 0ded64c..a45101c 100644 --- a/Documentation/EDID/1600x1200.S +++ b/Documentation/EDID/1600x1200.S @@ -36,7 +36,7 @@ #define DPI 72 #define VFREQ 60 /* Hz */ #define TIMING_NAME "Linux UXGA" -#define ESTABLISHED_TIMINGS_BITS 0x00 /* none */ +/* No ESTABLISHED_TIMINGx_BITS */ #define HSYNC_POL 1 #define VSYNC_POL 1 #define CRC 0x9d diff --git a/Documentation/EDID/1680x1050.S b/Documentation/EDID/1680x1050.S index 96f67ca..b0d7c69 100644 --- a/Documentation/EDID/1680x1050.S +++ b/Documentation/EDID/1680x1050.S @@ -36,7 +36,7 @@ #define DPI 96 #define VFREQ 60 /* Hz */ #define TIMING_NAME "Linux WSXGA" -#define ESTABLISHED_TIMINGS_BITS 0x00 /* none */ +/* No ESTABLISHED_TIMINGx_BITS */ #define HSYNC_POL 1 #define VSYNC_POL 1 #define CRC 0x26 diff --git a/Documentation/EDID/1920x1080.S b/Documentation/EDID/1920x1080.S index 36ed5d5..3084355e 100644 --- a/Documentation/EDID/1920x1080.S +++ b/Documentation/EDID/1920x1080.S @@ -36,7 +36,7 @@ #define DPI 96 #define VFREQ 60 /* Hz */ #define TIMING_NAME "Linux FHD" -#define ESTABLISHED_TIMINGS_BITS 0x00 /* none */ +/* No ESTABLISHED_TIMINGx_BITS */ #define HSYNC_POL 1 #define VSYNC_POL 1 #define CRC 0x05 diff --git a/Documentation/EDID/800x600.S b/Documentation/EDID/800x600.S new file mode 100644 index 000..6644e26 --- /dev/null +++ b/Documentation/EDID/800x600.S @@ -0,0 +1,41 @@ +/* + 800x600.S: EDID data set for standard 800x600 60 Hz monitor + + Copyright (C) 2011 Carsten Emde + Copyright (C) 2014 Linaro Limited + + This program is free software; you can redistribute it and/or + modify it under the terms of the GNU General Public License + as published by the Free Software Foundation; either version 2 + of the License, or (at your option) any later version. + + This program is distributed in the hope that it will be useful, + but WITHOUT ANY WARRANTY; without even the implied warranty of + MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the + GNU General Public License for more details. +*/ + +/* EDID */ +#define VERSION 1 +#define REVISION 3 + +/* Display */ +#define CLOCK 4 /* kHz */ +#define XPIX 800 +#define YPIX 600 +#define XY_RATIO XY_RATIO_4_3 +#define XBLANK 256 +#define YBLANK 28 +#define XOFFSET 40 +#define XPULSE 128 +#define YOFFSET (63+1) +#define YPULSE (63+4) +#define DPI 72 +#define VFREQ 60 /* Hz */ +#define TIMING_NAME "Linux SVGA" +#define ESTABLISHED_TIMING1_BITS 0x01 /* Bit 0: 800x600 @ 60Hz */ +#define HSYNC_POL 1 +#define VSYNC_POL 1 +#define CRC 0xc2 + +#include "edid.S" diff --git a/Documentation/EDID/HOWTO.txt b/Documentation/EDID/HOWTO.txt index 7146db1..835db33 100644 --- a/Documentation/EDID/HOWTO.txt +++ b/Documentation/EDID/HOWTO.txt @@ -18,7 +18,7 @@ CONFIG_DRM_LOAD_EDID_FIRMWARE was int
[PATCH v4] drm/exynos: enable fimd clocks in probe before accessing fimd registers
From: Rahul Sharma
Fimd probe is accessing fimd Registers without enabling the fimd
gate clocks. If FIMD clocks are kept disabled in Uboot or disbaled
during kernel boottime, the system hangs during boottime.
This issue got surfaced when verifying with sysmmu enabled. Probe of
fimd Sysmmu enables the master clock before accessing sysmmu regs and
then disables. Later fimd probe tries to read the register without
enabling the clock which is wrong and hangs the system.
Signed-off-by: Rahul Sharma
---
v4:
1) Added clk_disable for prev clock when clk_enable fails.
v3:
1) Added checks for clk_enable.
v2:
Rebase.
drivers/gpu/drm/exynos/exynos_drm_fimd.c | 18 +-
1 file changed, 17 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/exynos/exynos_drm_fimd.c
b/drivers/gpu/drm/exynos/exynos_drm_fimd.c
index bd30d0c..30ccd67 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_fimd.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_fimd.c
@@ -898,16 +898,32 @@ static int fimd_bind(struct device *dev, struct device
*master, void *data)
{
struct fimd_context *ctx = fimd_manager.ctx;
struct drm_device *drm_dev = data;
- int win;
+ int win, ret;
fimd_mgr_initialize(&fimd_manager, drm_dev);
exynos_drm_crtc_create(&fimd_manager);
if (ctx->display)
exynos_drm_create_enc_conn(drm_dev, ctx->display);
+ ret = clk_prepare_enable(ctx->bus_clk);
+ if (ret) {
+ dev_err(dev, "bus clock enable failed.\n");
+ return ret;
+ }
+
+ ret = clk_prepare_enable(ctx->lcd_clk);
+ if (ret) {
+ dev_err(dev, "lcd clock enable failed.\n");
+ clk_disable_unprepare(ctx->bus_clk);
+ return ret;
+ }
+
for (win = 0; win < WINDOWS_NR; win++)
fimd_clear_win(ctx, win);
+ clk_disable_unprepare(ctx->lcd_clk);
+ clk_disable_unprepare(ctx->bus_clk);
+
return 0;
}
--
1.7.9.5
[PATCH v5] drm/exynos: enable fimd clocks in probe before accessing fimd registers
From: Rahul Sharma
Fimd probe is accessing fimd Registers without enabling the fimd
gate clocks. If FIMD clocks are kept disabled in Uboot or disbaled
during kernel boottime, the system hangs during boottime.
This issue got surfaced when verifying with sysmmu enabled. Probe of
fimd Sysmmu enables the master clock before accessing sysmmu regs and
then disables. Later fimd probe tries to read the register without
enabling the clock which is wrong and hangs the system.
Signed-off-by: Rahul Sharma
---
v5:
1) Added pm_runtime_get_sync to enable the Display power domain.
v4:
1) Added clk_disable for prev clock when clk_enable fails.
v3:
1) Added checks for clk_enable.
v2:
Rebase.
drivers/gpu/drm/exynos/exynos_drm_fimd.c | 35 +-
1 file changed, 34 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/exynos/exynos_drm_fimd.c
b/drivers/gpu/drm/exynos/exynos_drm_fimd.c
index bd30d0c..6a30415 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_fimd.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_fimd.c
@@ -898,18 +898,51 @@ static int fimd_bind(struct device *dev, struct device
*master, void *data)
{
struct fimd_context *ctx = fimd_manager.ctx;
struct drm_device *drm_dev = data;
- int win;
+ int win, ret;
fimd_mgr_initialize(&fimd_manager, drm_dev);
exynos_drm_crtc_create(&fimd_manager);
if (ctx->display)
exynos_drm_create_enc_conn(drm_dev, ctx->display);
+ ret = pm_runtime_get_sync(ctx->dev);
+ if (ret) {
+ dev_err(dev, "pm runtime get has failed.\n");
+ return ret;
+ }
+
+ ret = clk_prepare_enable(ctx->bus_clk);
+ if (ret) {
+ dev_err(dev, "bus clock enable failed.\n");
+ goto bus_clk_err;
+ }
+
+ ret = clk_prepare_enable(ctx->lcd_clk);
+ if (ret) {
+ dev_err(dev, "lcd clock enable failed.\n");
+ goto lcd_clk_err;
+ }
+
for (win = 0; win < WINDOWS_NR; win++)
fimd_clear_win(ctx, win);
+ clk_disable_unprepare(ctx->lcd_clk);
+ clk_disable_unprepare(ctx->bus_clk);
+
+ ret = pm_runtime_put_sync(ctx->dev);
+ if (ret) {
+ dev_err(dev, "pm runtime put has failed.\n");
+ goto pm_put_err;
+ }
+
return 0;
+lcd_clk_err:
+ clk_disable_unprepare(ctx->bus_clk);
+bus_clk_err:
+ pm_runtime_put_sync(ctx->dev);
+pm_put_err:
+ return ret;
}
static void fimd_unbind(struct device *dev, struct device *master,
--
1.7.9.5
[PATCH 2/4] drm/ttm: introduce dma cache sync helpers
On Mon, May 19, 2014 at 5:33 PM, Thierry Reding
wrote:
> On Mon, May 19, 2014 at 04:10:56PM +0900, Alexandre Courbot wrote:
>> From: Lucas Stach
>>
>> On arches with non-coherent PCI,
>
> I guess since this applies to gk20a
>
>> we need to flush caches ourselfes at
>
> "ourselves". Or perhaps even reword to something like: "..., caches need
> to be flushed and invalidated explicitly", since dma_sync_for_cpu() does
> invalidate rather than flush.
Rephrased as "On arches for which access to GPU memory is non-coherent, caches
need to be flushed and invalidated explicitly at the appropriate places."
>
>> the appropriate places. Introduce two small helpers to make things easy
>> for TTM based drivers.
>>
>> Signed-off-by: Lucas Stach
>> Signed-off-by: Alexandre Courbot
>> ---
>> drivers/gpu/drm/ttm/ttm_tt.c| 25 +
>> include/drm/ttm/ttm_bo_driver.h | 28
>> 2 files changed, 53 insertions(+)
>>
>> diff --git a/drivers/gpu/drm/ttm/ttm_tt.c b/drivers/gpu/drm/ttm/ttm_tt.c
> [...]
>> +void ttm_dma_tt_cache_sync_for_device(struct ttm_dma_tt *ttm_dma,
>> + struct device *dev)
>> +{
>> + int i;
>
> This should probably be unsigned long to match the type of
> ttm_dma->ttm.num_pages.
Fixed.
Thanks,
Alex.
[Bug 75241] radeon_compute_pll_avivo broken in 3.15-rc3
https://bugzilla.kernel.org/show_bug.cgi?id=75241 --- Comment #23 from Tasev Nikola --- With ref_div_max 114 everything works fine for me. -- You are receiving this mail because: You are watching the assignee of the bug.
[Bug 79100] r600 context creation failure on kaveri
https://bugs.freedesktop.org/show_bug.cgi?id=79100 joshua.r.marshall.1991 at gmail.com changed: What|Removed |Added Status|NEW |NEEDINFO --- Comment #8 from joshua.r.marshall.1991 at gmail.com --- Graphics are happy, but not there appears to be a new problem -- my ethernet port went down as a result. The reason you are reading this is because I have a backup card. I'm going to reboot and see if this persists. If so, who/where might I go who has the expertise to look at this? -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20140523/9171a2e3/attachment.html>
[Bug 79100] r600 context creation failure on kaveri
https://bugs.freedesktop.org/show_bug.cgi?id=79100 Alex Deucher changed: What|Removed |Added Status|NEEDINFO|RESOLVED Resolution|--- |NOTABUG --- Comment #9 from Alex Deucher --- (In reply to comment #8) > I'm going to reboot and see if this persists. If so, who/where might I go > who has the expertise to look at this? Probably a configuration or desktop environment problem. Try your distro or desktop environment (gnome/kde/etc.) channels. -- 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/20140523/a24859a2/attachment-0001.html>
[Bug 79100] r600 context creation failure on kaveri
https://bugs.freedesktop.org/show_bug.cgi?id=79100 joshua.r.marshall.1991 at gmail.com changed: What|Removed |Added Resolution|NOTABUG |WORKSFORME --- Comment #10 from joshua.r.marshall.1991 at gmail.com --- There's likely a small bug in that I needed to reboot to reset devicemapping, but all seems well now. I'm marking the bug as fixed. Thanks for your poignant observation. -- 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/20140523/37f5c1c4/attachment.html>
[PATCH v2 0/7] drm/tegra: Convert to master/component framework
On Thu, May 22, 2014 at 11:56:23AM +0200, Thierry Reding wrote: > On Tue, May 13, 2014 at 05:30:43PM +0200, Thierry Reding wrote: > > From: Thierry Reding > > > > Hi, > > > > This series converts the Tegra DRM driver to the master/component > > framework. The length of the series and the list of people in Cc is > > mostly due to the fact that Tegra has some special requirements as > > opposed to other drivers and therefore requires some changes outside > > of DRM. > > > > Patch 1 introduces a helper function that can be used by new DRM drivers > > that don't rely on legacy userspace ABIs. It allows them to register DRM > > devices much more easily and without much of the midlayer that currently > > exists in the DRM subsystem. > > > > Patches 2 and 3 make some changes to the master/component framework > > which are necessary to convert Tegra DRM to use it. All current users of > > the API have been converted as part of this patch. Note that at the same > > time the drivers are converted to no longer use drm_platform_init() in > > favour of the drm_set_unique() from patch 1 in conjunction with > > drm_dev_alloc() and drm_dev_register(). I would've liked to avoid such > > invasive changes in a single patch, but unfortunately I couldn't think > > of a way how to do that. I'm open to suggestions. > > > > Patch 4 adds a new interface framework that supplements the master/ > > component framework and can be used in situations where there is no > > struct device * that a driver can bind to. > > > > The Tegra DRM driver is converted to using the master/component > > framework in patch 5 using the above four patches. > > > > Finally patches 6 and 7 add some documentation about the new way of > > registering DRM devices that don't need legacy support. > > > > Each patch has a somewhat more elaborate description of why it is needed > > or what problem it solves. The patchset applies on top of linux-next. > > > > I welcome any questions or comments you might have. > > > > Thierry > > > > Thierry Reding (7): > > drm: Introduce drm_set_unique() > > drivers/base: Allow driver-data to be attached to a master > > drivers/base: Allow multiple masters per device > > drivers/base: Add interface framework > > drm/tegra: Convert to master/component framework > > drm: Add device registration documentation > > drm: Document how to register devices without struct drm_bus > > Greg, Russell, > > Any comments on this? I've been blocking a bunch of patches in the hopes > of getting this merged since it allows the Tegra DRM driver to be > cleaned up a great deal, but if nobody's going to look at or comment on > this I'll abandon this series and keep using the custom solution we've > had for a while now. I'd like Russell to comment on this, as he just added some driver core work to do drm device work that seems to me to be much the same here. There's also the work that the media developers are working on to handle power management issues that seem to also be hitting the same area. Due to all of that, I really don't want to add yet-another-driver-core addition for just one drm driver, all of them should be able to use it. thanks, greg k-h
[Bug 79154] New: [Tesseract Game] 4xMSAA Causes Visible Wireframes
https://bugs.freedesktop.org/show_bug.cgi?id=79154 Priority: medium Bug ID: 79154 Assignee: dri-devel at lists.freedesktop.org Summary: [Tesseract Game] 4xMSAA Causes Visible Wireframes Severity: normal Classification: Unclassified OS: All Reporter: mmstickman at gmail.com Hardware: Other Status: NEW Version: git Component: Drivers/Gallium/radeonsi Product: Mesa Created attachment 99678 --> https://bugs.freedesktop.org/attachment.cgi?id=99678&action=edit Screenshot of the wireframes Currently running the latest mesa git with a Radeon HD 7950. Simply set MSAA to 4x to experience this bug. -- 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/20140523/b5760f6d/attachment.html>
[Bug 79154] [Tesseract Game] 4xMSAA Causes Visible Wireframes
https://bugs.freedesktop.org/show_bug.cgi?id=79154 Ilia Mirkin changed: What|Removed |Added Attachment #99678|text/plain |image/jpeg mime type|| -- 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/20140523/6c6abbb4/attachment.html>
[Bug 79155] New: [Tesseract Game] Global Illumination: Medium Causes Color Distortion
https://bugs.freedesktop.org/show_bug.cgi?id=79155 Priority: medium Bug ID: 79155 Assignee: dri-devel at lists.freedesktop.org Summary: [Tesseract Game] Global Illumination: Medium Causes Color Distortion Severity: normal Classification: Unclassified OS: Linux (All) Reporter: mmstickman at gmail.com Hardware: x86-64 (AMD64) Status: NEW Version: git Component: Drivers/Gallium/radeonsi Product: Mesa Created attachment 99679 --> https://bugs.freedesktop.org/attachment.cgi?id=99679&action=edit Screenshot of graphical error Currently using a Radeon HD 7950 with the latest git of mesa. Setting Global Illumination to Medium or above causes graphical corruption. -- 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/20140523/543e14b1/attachment.html>
[Bug 79155] [Tesseract Game] Global Illumination: Medium Causes Color Distortion
https://bugs.freedesktop.org/show_bug.cgi?id=79155 Ilia Mirkin changed: What|Removed |Added Attachment #99679|text/plain |image/jpeg mime type|| -- 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/20140523/0d9eaa6b/attachment.html>
[Bug 79154] [Tesseract Game] 4xMSAA Causes Visible Wireframes
https://bugs.freedesktop.org/show_bug.cgi?id=79154 --- Comment #1 from mmstickman at gmail.com --- After testing on a Radeon HD 6850 and 4870 machine, this bug exists on r600 as well. -- 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/20140523/16482dcd/attachment.html>
[Bug 79154] [Tesseract Game] 4xMSAA Causes Visible Wireframes
https://bugs.freedesktop.org/show_bug.cgi?id=79154 mmstickman at gmail.com changed: What|Removed |Added Hardware|Other |x86-64 (AMD64) OS|All |Linux (All) -- 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/20140523/3ab5c616/attachment.html>
[Bug 79155] [Tesseract Game] Global Illumination: Medium Causes Color Distortion
https://bugs.freedesktop.org/show_bug.cgi?id=79155 --- Comment #1 from mmstickman at gmail.com --- This bug does not occur on my Radeon HD 6850 or 4870 machines. -- 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/20140523/70779786/attachment.html>
[Bug 79157] New: [Tesseract Game] Grainy SSAO on RadeonSI
https://bugs.freedesktop.org/show_bug.cgi?id=79157 Priority: medium Bug ID: 79157 Assignee: dri-devel at lists.freedesktop.org Summary: [Tesseract Game] Grainy SSAO on RadeonSI Severity: normal Classification: Unclassified OS: Linux (All) Reporter: mmstickman at gmail.com Hardware: x86-64 (AMD64) Status: NEW Version: git Component: Drivers/Gallium/radeonsi Product: Mesa Created attachment 99680 --> https://bugs.freedesktop.org/attachment.cgi?id=99680&action=edit Screenshot of grain After testing on my Radeon HD 4870, 6850, 7950, and R9 270X machines, when enabling SSAO in Tesseract on the RadeonSI machines, the SSAO produces a very grainy visual effect while R600-based machines renders fine, besides TGSI bugs being spit out to the terminal. -- 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/20140523/dfb64146/attachment-0001.html>
[Bug 79157] [Tesseract Game] Grainy SSAO on RadeonSI
https://bugs.freedesktop.org/show_bug.cgi?id=79157 mmstickman at gmail.com changed: What|Removed |Added Attachment #99680|text/plain |image/jpeg mime type|| -- 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/20140523/c946c87f/attachment.html>
[Bug 76761] radeon DPM breaks suspend to disk and resume from RAM in 3.14
https://bugzilla.kernel.org/show_bug.cgi?id=76761 --- Comment #3 from Vitaliy Filippov --- OK I did bisect. The result is: 6c7bccea390853bdec5b76fe31fc50f3b36f75d5 is the first bad commit commit 6c7bccea390853bdec5b76fe31fc50f3b36f75d5 Author: Alex Deucher Date: Wed Dec 18 14:07:14 2013 -0500 drm/radeon/pm: move pm handling into the asic specific code We need more control over the ordering of dpm init with respect to the rest of the asic. Specifically, the SMC has to be initialized before the rlc and cg/pg. The pm code currently initializes late in the driver, but we need it to happen much earlier so move pm handling into the asic specific callbacks. This makes dpm more reliable and makes clockgating work properly on CIK parts and should help on SI parts as well. Signed-off-by: Alex Deucher -- You are receiving this mail because: You are watching the assignee of the bug.
[PATCH 1/3] drm/tegra: Align FB pitch
The display controller doesn't handle non-256 byte aligned buffer pitches. If you give it an unaligned buffer, it will stop after the first line and will report underflows in the debug registers (DC_WINBUF_UFLOW_STATUS and friends). So let's make sure that all our framebuffer pitches are 256-byte aligned. Signed-off-by: St?phane Marchesin --- drivers/gpu/drm/tegra/drm.h | 2 ++ drivers/gpu/drm/tegra/fb.c | 3 ++- drivers/gpu/drm/tegra/gem.c | 2 ++ 3 files changed, 6 insertions(+), 1 deletion(-) diff --git a/drivers/gpu/drm/tegra/drm.h b/drivers/gpu/drm/tegra/drm.h index 126332c..6753598 100644 --- a/drivers/gpu/drm/tegra/drm.h +++ b/drivers/gpu/drm/tegra/drm.h @@ -251,6 +251,8 @@ static inline int tegra_output_check_mode(struct tegra_output *output, return output ? -ENOSYS : -EINVAL; } +#define DC_PITCH_ALIGNMENT 256 + /* from bus.c */ int drm_host1x_init(struct drm_driver *driver, struct host1x_device *device); void drm_host1x_exit(struct drm_driver *driver, struct host1x_device *device); diff --git a/drivers/gpu/drm/tegra/fb.c b/drivers/gpu/drm/tegra/fb.c index f7fca09..691e83e 100644 --- a/drivers/gpu/drm/tegra/fb.c +++ b/drivers/gpu/drm/tegra/fb.c @@ -207,7 +207,8 @@ static int tegra_fbdev_probe(struct drm_fb_helper *helper, cmd.width = sizes->surface_width; cmd.height = sizes->surface_height; - cmd.pitches[0] = sizes->surface_width * bytes_per_pixel; + cmd.pitches[0] = round_up(sizes->surface_width * bytes_per_pixel, + DC_PITCH_ALIGNMENT); cmd.pixel_format = drm_mode_legacy_fb_format(sizes->surface_bpp, sizes->surface_depth); diff --git a/drivers/gpu/drm/tegra/gem.c b/drivers/gpu/drm/tegra/gem.c index bcf9895..9a92a9b 100644 --- a/drivers/gpu/drm/tegra/gem.c +++ b/drivers/gpu/drm/tegra/gem.c @@ -16,6 +16,7 @@ #include #include +#include "drm.h" #include "gem.h" static inline struct tegra_bo *host1x_to_tegra_bo(struct host1x_bo *bo) @@ -260,6 +261,7 @@ int tegra_bo_dumb_create(struct drm_file *file, struct drm_device *drm, int min_pitch = DIV_ROUND_UP(args->width * args->bpp, 8); struct tegra_bo *bo; + min_pitch = round_up(min_pitch, DC_PITCH_ALIGNMENT); if (args->pitch < min_pitch) args->pitch = min_pitch; -- 1.9.1.423.g4596e3a
[PATCH 3/3] drm/tegra: Don't hardcode link parameters
The currently hardcoded link parameters don't work on my eDP display,
however the android driver has code to compute the parameters. This is
a port of this code to the drm driver which allows the drm driver to
compute the link parameters correctly.
Note that we still hardcode the bpp, this will be taken care of in
another patch.
Signed-off-by: St?phane Marchesin
---
drivers/gpu/drm/tegra/sor.c | 199 ++--
1 file changed, 190 insertions(+), 9 deletions(-)
diff --git a/drivers/gpu/drm/tegra/sor.c b/drivers/gpu/drm/tegra/sor.c
index 23fb9b1..1fbb488 100644
--- a/drivers/gpu/drm/tegra/sor.c
+++ b/drivers/gpu/drm/tegra/sor.c
@@ -289,12 +289,175 @@ static int tegra_sor_power_up(struct tegra_sor *sor,
unsigned long timeout)
return -ETIMEDOUT;
}
+struct tegra_sor_dp_link {
+ u32 bits_per_pixel;
+
+ u32 activepolarity;
+ u32 active_count;
+ u32 tu_size;
+ u32 active_frac;
+ u32 watermark;
+};
+
+static int tegra_sor_calc_config(struct tegra_sor *sor,
+struct drm_display_mode *mode,
+struct tegra_sor_dp_link *tegra_link,
+struct drm_dp_link *link)
+{
+ const u32 link_rate = link->rate * 1000;
+ const u64 f = 10; /* precision factor */
+ const int pclk = mode->clock * 1000;
+
+ u32 num_linkclk_line; /* Number of link clocks per line */
+ u64 ratio_f; /* Ratio of incoming to outgoing data rate */
+ u64 frac_f;
+ u64 activesym_f; /* Activesym per TU */
+ u64 activecount_f;
+ u32 activecount;
+ u32 activepolarity;
+ u64 approx_value_f;
+ u32 activefrac = 0;
+ u64 accumulated_error_f = 0;
+ u32 lowest_neg_activecount = 0;
+ u32 lowest_neg_activepolarity = 0;
+ u32 lowest_neg_tusize = 64;
+ u32 num_symbols_per_line;
+ u64 lowest_neg_activefrac = 0;
+ u64 lowest_neg_error_f = 64 * f;
+ u64 watermark_f;
+
+ int i;
+ bool neg;
+
+ if (!link_rate || !link->num_lanes || !pclk ||
+ !tegra_link->bits_per_pixel)
+ return -1;
+
+ if ((u64)pclk * tegra_link->bits_per_pixel >=
+ (u64)link_rate * 8 * link->num_lanes)
+ return -1;
+
+ num_linkclk_line = div_u64((u64)link_rate * mode->hdisplay, pclk);
+
+ ratio_f = (u64)pclk * tegra_link->bits_per_pixel * f;
+ ratio_f /= 8;
+ ratio_f = div_u64(ratio_f, link_rate * link->num_lanes);
+
+ for (i = 64; i >= 32; --i) {
+ activesym_f = ratio_f * i;
+ activecount_f = div_u64(activesym_f, (u32)f) * f;
+ frac_f = activesym_f - activecount_f;
+ activecount = (u32)div_u64(activecount_f, (u32)f);
+
+ if (frac_f < (f / 2)) /* fraction < 0.5 */
+ activepolarity = 0;
+ else {
+ activepolarity = 1;
+ frac_f = f - frac_f;
+ }
+
+ if (frac_f != 0) {
+ frac_f = div_u64((f * f), frac_f); /* 1/fraction */
+ if (frac_f > (15 * f))
+ activefrac = activepolarity ? 1 : 15;
+ else
+ activefrac = activepolarity ?
+ (u32)div_u64(frac_f, (u32)f) + 1 :
+ (u32)div_u64(frac_f, (u32)f);
+ }
+
+ if (activefrac == 1)
+ activepolarity = 0;
+
+ if (activepolarity == 1)
+ approx_value_f = activefrac ? div_u64(
+ activecount_f + (activefrac * f - f) * f,
+ (activefrac * f)) :
+ activecount_f + f;
+ else
+ approx_value_f = activefrac ?
+ activecount_f + div_u64(f, activefrac) :
+ activecount_f;
+
+ if (activesym_f < approx_value_f) {
+ accumulated_error_f = num_linkclk_line *
+ div_u64(approx_value_f - activesym_f, i);
+ neg = true;
+ } else {
+ accumulated_error_f = num_linkclk_line *
+ div_u64(activesym_f - approx_value_f, i);
+ neg = false;
+ }
+
+ if ((neg && (lowest_neg_error_f > accumulated_error_f)) ||
+ (accumulated_error_f == 0)) {
+ lowest_neg_error_f = accumulated_error_f;
+ lowest_neg_tusize = i;
+ lowest_neg_activecount = activecount;
+ lowest_neg_activepolarity = activepolarity;
+ lowest_neg_activefrac = activefrac;
+
+
[PATCH 2/3] drm/tegra: Support setting the EMC clock
The current code doesn't enable the EMC clock, without which the
display cannot function, so let's enable this clock. We also need a
bit of code to pick the right frequency for the EMC clock depending
on the current video mode settings.
Signed-off-by: St?phane Marchesin
---
drivers/gpu/drm/tegra/dc.c | 61 -
drivers/gpu/drm/tegra/drm.h | 1 +
2 files changed, 61 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/tegra/dc.c b/drivers/gpu/drm/tegra/dc.c
index edb871d..f398dfb 100644
--- a/drivers/gpu/drm/tegra/dc.c
+++ b/drivers/gpu/drm/tegra/dc.c
@@ -325,6 +325,9 @@ static void tegra_crtc_disable(struct drm_crtc *crtc)
}
drm_vblank_off(drm, dc->pipe);
+
+ if (dc->emc_clk)
+ clk_set_rate(dc->emc_clk, 0);
}
static bool tegra_crtc_mode_fixup(struct drm_crtc *crtc,
@@ -640,6 +643,50 @@ unsigned int tegra_dc_format(uint32_t format)
return WIN_COLOR_DEPTH_B8G8R8A8;
}
+static unsigned long tegra_emc_bw_to_freq_req(unsigned long bw)
+{
+ int bytes_per_emc_clock;
+
+ if (of_machine_is_compatible("nvidia,tegra124"))
+ bytes_per_emc_clock = 16;
+ else
+ bytes_per_emc_clock = 8;
+
+ return (bw + bytes_per_emc_clock - 1) / bytes_per_emc_clock;
+}
+
+#define EMC_FREQ_CUTOFF_USE_130_PERCENT 1UL
+#define EMC_FREQ_CUTOFF_USE_140_PERCENT 5000UL
+
+static int tegra_dc_program_bandwidth(struct tegra_dc *dc,
+ struct drm_display_mode *mode,
+ struct tegra_dc_window *window)
+{
+ unsigned long bandwidth = mode->clock * window->bits_per_pixel / 8;
+ unsigned long freq;
+ struct clk *emc_master;
+
+ if (!dc->emc_clk)
+ return 0;
+
+ emc_master = clk_get_parent(dc->emc_clk);
+ freq = tegra_emc_bw_to_freq_req(bandwidth) * 1000;
+ freq = clk_round_rate(emc_master, freq);
+
+ /* XXX: Add safety margins for DVFS */
+
+ if (freq < EMC_FREQ_CUTOFF_USE_140_PERCENT)
+ bandwidth += 4 * bandwidth / 10;
+ else if (freq < EMC_FREQ_CUTOFF_USE_130_PERCENT)
+ bandwidth += 3 * bandwidth / 10;
+ else
+ bandwidth += bandwidth / 10;
+
+ freq = tegra_emc_bw_to_freq_req(bandwidth) * 1000;
+
+ return clk_set_rate(dc->emc_clk, freq);
+}
+
static int tegra_crtc_mode_set(struct drm_crtc *crtc,
struct drm_display_mode *mode,
struct drm_display_mode *adjusted,
@@ -691,7 +738,11 @@ static int tegra_crtc_mode_set(struct drm_crtc *crtc,
if (err < 0)
dev_err(dc->dev, "failed to enable root plane\n");
- return 0;
+ err = tegra_dc_program_bandwidth(dc, mode, &window);
+ if (err)
+ dev_err(dc->dev, "failed to program the EMC clock\n");
+
+ return err;
}
static int tegra_crtc_mode_set_base(struct drm_crtc *crtc, int x, int y,
@@ -1260,6 +1311,12 @@ static int tegra_dc_probe(struct platform_device *pdev)
if (err < 0)
return err;
+ dc->emc_clk = devm_clk_get(&pdev->dev, "emc");
+ if (IS_ERR(dc->emc_clk))
+ dc->emc_clk = NULL;
+ else
+ clk_prepare_enable(dc->emc_clk);
+
regs = platform_get_resource(pdev, IORESOURCE_MEM, 0);
dc->regs = devm_ioremap_resource(&pdev->dev, regs);
if (IS_ERR(dc->regs))
@@ -1312,6 +1369,8 @@ static int tegra_dc_remove(struct platform_device *pdev)
}
clk_disable_unprepare(dc->clk);
+ if (dc->emc_clk)
+ clk_disable_unprepare(dc->emc_clk);
return 0;
}
diff --git a/drivers/gpu/drm/tegra/drm.h b/drivers/gpu/drm/tegra/drm.h
index 6753598..30d91c0 100644
--- a/drivers/gpu/drm/tegra/drm.h
+++ b/drivers/gpu/drm/tegra/drm.h
@@ -101,6 +101,7 @@ struct tegra_dc {
struct clk *clk;
struct reset_control *rst;
+ struct clk *emc_clk;
void __iomem *regs;
int irq;
--
1.9.1.423.g4596e3a
[PATCH] drm/panel: add support for AUO B133XTN01 panel
This panel is used by nyan-big and supported by the simple-panel
driver.
Signed-off-by: St?phane Marchesin
---
drivers/gpu/drm/panel/panel-simple.c | 25 +
1 file changed, 25 insertions(+)
diff --git a/drivers/gpu/drm/panel/panel-simple.c
b/drivers/gpu/drm/panel/panel-simple.c
index 309f29e..3072638b 100644
--- a/drivers/gpu/drm/panel/panel-simple.c
+++ b/drivers/gpu/drm/panel/panel-simple.c
@@ -284,6 +284,28 @@ static const struct panel_desc auo_b101aw03 = {
},
};
+static const struct drm_display_mode auo_b133xtn01_mode = {
+ .clock = 69500,
+ .hdisplay = 1366,
+ .hsync_start = 1366 + 48,
+ .hsync_end = 1366 + 48 + 32,
+ .htotal = 1366 + 48 + 32 + 20,
+ .vdisplay = 768,
+ .vsync_start = 768 + 3,
+ .vsync_end = 768 + 3 + 6,
+ .vtotal = 768 + 3 + 6 + 13,
+ .vrefresh = 60,
+};
+
+static const struct panel_desc auo_b133xtn01 = {
+ .modes = &auo_b133xtn01_mode,
+ .num_modes = 1,
+ .size = {
+ .width = 293,
+ .height = 165,
+ },
+};
+
static const struct drm_display_mode chunghwa_claa101wa01a_mode = {
.clock = 72070,
.hdisplay = 1366,
@@ -377,6 +399,9 @@ static const struct of_device_id platform_of_match[] = {
.compatible = "auo,b101aw03",
.data = &auo_b101aw03,
}, {
+ .compatible = "auo,b133xtn01.2", "auo,b133xtn01.0",
+ .data = &auo_b133xtn01,
+ }, {
.compatible = "chunghwa,claa101wa01a",
.data = &chunghwa_claa101wa01a
}, {
--
1.9.1.423.g4596e3a
[PATCH] drm/panel: add support for AUO B133XTN01 panel
On Thu, May 22, 2014 at 4:02 AM, Thierry Reding wrote:
> On Tue, May 20, 2014 at 04:36:48PM -0700, St?phane Marchesin wrote:
> > This panel is used by my tegra board and supported by the simple-panel
> > driver.
>
> One thing I like to have is some indication in the commit message about
> which board this panel is used on. Of course if you can't disclose that
> yet I'll still take the patch, but perhaps you can be a little more
> specific than "my Tegra board".
>
> There also seem to be different variants of this panel. I've come across
> datasheets for B133XTN01.0 and B133XTN01.2. The 1.0 seems to be native
> LVDS whereas it looks as if the 1.2 comes with an additional module to
> connect it to eDP. Which one is it that you use? I guess independent of
> the specific model the timings will still work, but device tree mandates
> that the compatible for the most specific model be used. Perhaps this
> panel should be:
>
>
I'm using the B133XTN01.2. The panel specs are not exactly the same (the
1.2 has a single clock, 69.5MHz while the 1.0 does 60-80MHz), but the fixed
timing that I put in the DT will work on both.
St?phane
> compatible = "auo,b133xtn01.2", "auo,b133xtn01", "simple-panel";
>
> That would allow the panel-simple driver to match on "auo,b133xtn01" and
> pick up the timing that presumably works for both.
>
> One other nit below:
>
> > diff --git a/drivers/gpu/drm/panel/panel-simple.c
> b/drivers/gpu/drm/panel/panel-simple.c
> [...]
> > +static const struct panel_desc auo_b133xtn01 = {
> > + .modes = &auo_b133xtn01_mode,
> > + .num_modes = 1,
> > + .size = {
> > + .width = 293,
> > + .height = 164,
>
> According to the datasheet I found this is 164.97 mm, in which case I
> think it may be better to round up to get a more accurate value of the
> DPI.
>
> Thierry
>
> ___
> dri-devel mailing list
> dri-devel at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/dri-devel
>
>
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140523/0f552ed4/attachment-0001.html>
