[Bug 43829] Resuming my AMD A4-3300 based laptop leaves the screen black
https://bugs.freedesktop.org/show_bug.cgi?id=43829 --- Comment #39 from Jared Freeman --- Same issue with me. I have an HP with an A8-3550MX (6620G graphics). This issue as plagued me (and I am sure others) for quite some time. I have pretty much relegated myself to using the fglrx binary blob. -- 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/20131024/49d19429/attachment.html>
Intel Haswell kernel warning (3.11.2)
On 09/29/2013 05:12 PM, Daniel Vetter wrote: > Please boot with drm.debug=0xe, reproduce the WARN and then attach the > full dmesg. > This is a segfault on kernel 3.11.3. There's no X started yet, but one s2ram cycle. Attached is the complete dmesg with drm.debug=0xe or on http://pastebin.com/raw.php?i=dqh0RjVG . The surrounding messages: [ 39.192856] ACPI: Low-level resume complete [ 39.192887] PM: Restoring platform NVS memory [ 39.193638] Enabling non-boot CPUs ... [ 39.193720] smpboot: Booting Node 0 Processor 1 APIC 0x2 [ 39.207712] CPU1 is up [ 39.207755] smpboot: Booting Node 0 Processor 2 APIC 0x4 [ 39.221845] CPU2 is up [ 39.221893] smpboot: Booting Node 0 Processor 3 APIC 0x6 [ 39.235974] CPU3 is up [ 39.236021] smpboot: Booting Node 0 Processor 4 APIC 0x1 [ 39.250015] CPU4 is up [ 39.250065] smpboot: Booting Node 0 Processor 5 APIC 0x3 [ 39.264142] CPU5 is up [ 39.264203] smpboot: Booting Node 0 Processor 6 APIC 0x5 [ 39.278323] CPU6 is up [ 39.278378] smpboot: Booting Node 0 Processor 7 APIC 0x7 [ 39.292438] CPU7 is up [ 39.299252] ACPI: Waking up from system sleep state S3 [ 39.332134] ehci-pci :00:1a.0: System wakeup disabled by ACPI [ 39.343112] ehci-pci :00:1d.0: System wakeup disabled by ACPI [ 39.365174] PM: noirq resume of devices complete after 65.731 msecs [ 39.365234] PM: early resume of devices complete after 0.046 msecs [ 39.365246] i915 :00:02.0: setting latency timer to 64 [ 39.365251] e1000e :00:19.0: System wakeup disabled by ACPI [ 39.365257] e1000e :00:19.0: setting latency timer to 64 [ 39.365265] ahci :00:1f.2: setting latency timer to 64 [ 39.365290] e1000e :00:19.0: irq 44 for MSI/MSI-X [ 39.365304] ehci-pci :00:1a.0: setting latency timer to 64 [ 39.365310] pci :00:14.0: CONFIG_USB_XHCI_HCD is turned off, defaulting to EHCI. [ 39.365310] pci :00:14.0: USB 3.0 devices will work at USB 2.0 speeds. [ 39.365331] ehci-pci :00:1d.0: setting latency timer to 64 [ 39.365336] pci :00:14.0: CONFIG_USB_XHCI_HCD is turned off, defaulting to EHCI. [ 39.365336] pci :00:14.0: USB 3.0 devices will work at USB 2.0 speeds. [ 39.366127] [drm:i915_redisable_vga], Something enabled VGA plane, disabling it [ 39.366442] [drm:intel_opregion_setup], graphic opregion physical addr: 0xccafc018 [ 39.366449] [drm:intel_opregion_setup], Public ACPI methods supported [ 39.366449] [drm:intel_opregion_setup], SWSCI supported [ 39.366449] [drm:intel_opregion_setup], ASLE supported [ 39.404149] [drm:init_status_page], render ring hws offset: 0x [ 39.406086] [drm:init_pipe_control], render ring pipe control offset: 0x00021000 [ 39.406098] [drm:init_status_page], bsd ring hws offset: 0x00022000 [ 39.406239] [drm:init_status_page], blitter ring hws offset: 0x00043000 [ 39.406368] [drm:init_status_page], video enhancement ring hws offset: 0x00064000 [ 39.406572] [drm:intel_prepare_ddi_buffers], Initializing DDI buffers for port A in DP mode [ 39.406583] [drm:intel_prepare_ddi_buffers], Initializing DDI buffers for port B in DP mode [ 39.406594] [drm:intel_prepare_ddi_buffers], Initializing DDI buffers for port C in DP mode [ 39.406605] [drm:intel_prepare_ddi_buffers], Initializing DDI buffers for port D in DP mode [ 39.406617] [drm:intel_prepare_ddi_buffers], Initializing DDI buffers for port E in FDI mode [ 39.406662] [drm:intel_modeset_readout_hw_state], [CRTC:3] hw state readout: disabled [ 39.406665] [drm:intel_modeset_readout_hw_state], [CRTC:5] hw state readout: disabled [ 39.406668] [drm:intel_modeset_readout_hw_state], [CRTC:7] hw state readout: disabled [ 39.406673] [drm:intel_modeset_readout_hw_state], [ENCODER:10:DAC-10] hw state readout: disabled, pipe=0 [ 39.406677] [drm:intel_modeset_readout_hw_state], [ENCODER:11:TMDS-11] hw state readout: disabled, pipe=0 [ 39.406680] [drm:intel_modeset_readout_hw_state], [ENCODER:16:TMDS-16] hw state readout: disabled, pipe=0 [ 39.406682] [drm:intel_modeset_readout_hw_state], [ENCODER:19:TMDS-19] hw state readout: disabled, pipe=0 [ 39.406686] [drm:intel_modeset_readout_hw_state], [CONNECTOR:9:VGA-1] hw state readout: disabled [ 39.406690] [drm:intel_modeset_readout_hw_state], [CONNECTOR:12:DP-1] hw state readout: disabled [ 39.406693] [drm:intel_modeset_readout_hw_state], [CONNECTOR:15:HDMI-A-1] hw state readout: disabled [ 39.406696] [drm:intel_modeset_readout_hw_state], [CONNECTOR:17:DP-2] hw state readout: disabled [ 39.406699] [drm:intel_modeset_readout_hw_state], [CONNECTOR:18:HDMI-A-2] hw state readout: disabled [ 39.406701] [drm:intel_modeset_readout_hw_state], [CONNECTOR:20:DP-3] hw state readout: disabled [ 39.406704] [drm:intel_modeset_readout_hw_state], [CONNECTOR:21:HDMI-A-3] hw state readout: disabled [ 39.406708] [drm:intel_dump_pipe_config], [CRTC:3][setup_hw_state] config for pipe A [ 39.406710] [drm:intel_dump_pipe_config], cpu_transcoder: A [ 39.4067
[Bug 63391] Radeon RS880 doesn't resume from suspend with radeon dpm enabled
https://bugzilla.kernel.org/show_bug.cgi?id=63391 --- Comment #8 from Tasev Nikola --- Hi, I start the bisect yesterday between 3.12-rc1 and 3.12-rc2. I will report when i'm finish. -- You are receiving this mail because: You are watching the assignee of the bug.
[PATCH v2 12/26] drm/exynos: Split manager/display/subdrv
2013/10/23 Sean Paul : > On Wed, Oct 23, 2013 at 10:29 AM, Dave Airlie wrote: >>> As I mentioned earlier, display_ops is needed to have no any >>> dependency of drm framework directly like below, >>> >>> DRM Framework >>>| >>> Exynos DRM Framework >>> / | \ >>> Real device drivers >>> >>> In particular, in case of ARM based DRM drivers with separated >>> devices, I still tend to think it's better design than that device >>> drivers implement the connector callbacks directly, but I will try to >>> consider what is the better way. >>> >> >> I think we need to start considering a framework where subdrivers just >> add drm objects themselves, then the toplevel node is responsible for >> knowing that everything for the current configuration is loaded. >> > > It would be nice to specify the various pieces in dt, then have some > type of drm notifier to the toplevel node when everything has been > probed. Doing it in the dt would allow standalone drm_bridge/drm_panel > drivers to be transparent as far as the device's drm driver is > concerned. > Before that, I think we need to decide that drm driver should reuse lcd class based drivers, or just should copy the lcd class based drivers into drm framework. 1. in case that drm driver reuses the existing lcd class based drivers, - we would need a common layer across between Linux framebuffer and drm framework. In other words, the lcd class based drivers and drm driver should be able to include a header file to the common layer, and the header should provide some callbacks such as drm_panel structure, and also some functions to create a connector and a encoder. Actually, that is why Exynos drm framework has a wrapper to drm connector and encoder, and display_ops also. 2. in case that drm driver uses duplicated lcd driver, - we wouldn't need the common layer because a connector and a encoder can be created directly in the lcd driver so in this case, I think the wrapper to drm connector and display_ops wouldn't be needed anymore. And shouldn't the device tree related works be discussed after we select one of the above two cases? or should we consider all of the above two cases? > Sean > > >> I realise we may need to make changes to the core drm to allow this >> but we should probably start to create a strategy for fixing the API >> issues that this throws up. >> >> Note I'm not yet advocating for dynamic addition of nodes once the >> device is in use, or removing them. >> >> Dave. > ___ > dri-devel mailing list > dri-devel at lists.freedesktop.org > http://lists.freedesktop.org/mailman/listinfo/dri-devel
HPD flood warning since b8f102e8b
On Mon, 21 Oct 2013, Egbert Eich wrote: > > On Thu, 3 Oct 2013, Daniel Vetter wrote: > > > > > Can you please attach full dmesg from boot up to the first WARN with > > > drm.debug=0xe? This really shouldn't happen and indicates a bug > > > somewhere ... > > > > A bit difficult ... I originally thought that it was reliably > > reproducible, but now I didn't get it after 10 suspend/resume cycles. Will > > keep following it, and once it appears, will send you the dmesg. > > > Could you check if you get any messages regarding HPD storms after > suspend/resume ie messages like: > "[drm] HPD interrupt storm detected on connector HDMI-A-1" > but without the annouing warn messages? I have this: [357128.184113] [drm] HPD interrupt storm detected on connector DP-3: switching from hotplug detection to polling It appeared in the log approximately 5 seconds after resume has been completed. Thanks, -- Jiri Kosina SUSE Labs
[PATCH v2 12/26] drm/exynos: Split manager/display/subdrv
2013/10/23 Rob Clark :
> On Wed, Oct 23, 2013 at 9:18 AM, Inki Dae wrote:
>> Look at omapdrm, nouveau, and radeon drm drivers.
>
>
> btw, please don't look at omapdrm as a "good" example in this regard.
> The layering is really not a good idea and for a long time caused a
> lot of problems, which we essentially solved by bypassing parts of the
> layering. I still think omapdss and omapdrm should be flattened into
> a single drm driver, then net result would be a drop in # of lines of
It seems that you proper to use duplicated driver. I mean... do you
proper that omapdss driver is placed in drm framework? Otherwise, is
there any way that omapdss and omapdrm can be flattened into a single
drm driver without moving omapdss into drm framework? As I mentioned
earlier, we wanted to reuse the existing panel driver so Exynos drm
framework has the layer, wrappers to connector and encoder. Of course,
for this, we have TODO works yet, and I still think it's better way to
keep the wrapper if we should reuse the existing panel drivers.
The below would be one design for the case,
lcd panel drivers
\ | /
drm framework - drm_bridge
/ | \
crtc
drivers(display controller or hdmi)
A header file of drm_bridge includes drm_panel structure having some
callbacks related to connector, and some function to register crtc and
panel driver's requests to the drm_bridge object. And the header file
can be included in the existing panel drivers. In other words,
drm_bridge will connect drm driver and lcd class based panel drivers.
struct drm_bridge {
struct list_head list;
unsigned int type;
struct drm_device *drm_dev;
struct drm_panel *panel_ops;
...
int (*drm_create_enc_conn)();
};
A drm_bridge object has drm_panel ops and drm_create_enc_conn
callback. And once the crtc driver calls register function of the
drm_bridge with drm_create_enc_conn callback pointer, a drm_crtc is
created, and once the panel driver calls the register function with
drm_panel ops, a encoder and a connector are created. At this time,
drm_fb_helper_initial_config() can be called appropriately to connect
crtc and connector, and to display framebuffer on lcd panel.
The above is just my opinion for the case, and we are testing this way
implementing it internally.
Thanks,
Inki Dae
> code. I wish there were folks like the Sean and St?phane who cared
> enough to do this for omapdrm ;-)
>
> Other drivers have some modularity to separate code that is
> significantly different across genarations (but what form that takes
> differs depending on what how the hw differs across generations).
> This isn't a bad thing. But you need to look at the end result. For
> example how I split out the phy code for the mdp4 code in msm (hdmi
> and dsi phy differ between otherwise similar 28nm and 45nm parts, but
> the rest of the display controller blocks are basically the same).
>
> BR,
> -R
> ___
> dri-devel mailing list
> dri-devel at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/dri-devel
[RFR 2/2] drm/panel: Add simple panel support
Hi Tomi,
On Thursday 17 October 2013 15:32:29 Tomi Valkeinen wrote:
> On 17/10/13 15:17, Laurent Pinchart wrote:
> > On Thursday 17 October 2013 14:59:41 Tomi Valkeinen wrote:
> >> On 17/10/13 14:51, Laurent Pinchart wrote:
> >>>> I'm not sure if there's a specific need for the port or endpoint nodes
> >>>> in cases like the above. Even if we have common properties describing
> >>>> the endpoint, I guess they could just be in the parent node.
> >>>>
> >>>> panel {
> >>>> remote = <&dc>;
> >>>> common-video-property = ;
> >>>> };
> >>>>
> >>>> The above would imply one port and one endpoint. Would that work? If we
> >>>> had a function like parse_endpoint(node), we could just point it to
> >>>> either a real endpoint node, or to the device's node.
> >>>
> >>> You reference the display controller here, not a specific display
> >>> controller output. Don't most display controllers have several outputs ?
> >>
> >> Sure. Then the display controller could have more verbose description.
> >> But the panel could still have what I wrote above, except the 'remote'
> >> property would point to a real endpoint node inside the dispc node, not
> >> to the dispc node.
> >>
> >> This would, of course, need some extra code to handle the different
> >> cases, but just from DT point of view, I think all the relevant
> >> information is there.
> >
> > There's many ways to describe the same information in DT. While we could
> > have DT bindings that use different descriptions for different devices
> > and still support all of them in our code, why should we opt for that
> > option that will make the implementation much more complex when we can
> > describe connections in a simple and generic way ?
>
> My suggestion was simple and generic. I'm not proposing per-device
> custom bindings.
>
> My point was, if we can describe the connections as I described above,
> which to me sounds possible, we can simplify the panel DT data for 99.9%
> of the cases.
>
> To me, the first of these looks much nicer:
>
> panel {
> remote = <&remote-endpoint>;
> common-video-property = ;
> };
>
> panel {
> port {
> endpoint {
> remote = <&remote-endpoint>;
> common-video-property = ;
> };
> };
> };
Please note that the common video properties would be in the panel node, not
in the endpoint node (unless you have specific requirements to do so, which
isn't the common case).
> If that can be supported in the SW by adding complexity to a few functions,
> and it covers practically all the panels, isn't it worth it?
>
> Note that I have not tried this, so I don't know if there are issues.
> It's just a thought. Even if there's need for a endpoint node, perhaps
> the port node can be made optional.
It can be worth it, as long as we make sure that simplified bindings cover the
needs of the generic code.
We could assume that, if the port subnode isn't present, the device will have
a single port, with a single endpoint. However, isn't the number of endpoints
a system property rather than a device property ? If a port of a device is
connected to two remote ports it will require two endpoints. We could select
the simplified or full bindings based on the system topology though.
I've CC'ed Sylwester Nawrocki and Guennadi Liakhovetski, the V4L2 DT bindings
authors, as well as the linux-media list, to get their opinion on this.
--
Regards,
Laurent Pinchart
-- next part --
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 490 bytes
Desc: This is a digitally signed message part.
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20131024/357027a1/attachment.pgp>
[RFR 2/2] drm/panel: Add simple panel support
_simple(panel); > > > > > > > + int err; > > > > > > > + > > > > > > > + if (p->enabled) > > > > > > > + return; > > > > > > > + > > > > > > > + err = regulator_enable(p->supply); > > > > > > > + if (err < 0) > > > > > > > + dev_err(panel->dev, "failed to enable supply: %d\n", err); > > > > > > > > > > > > Is that really a non-fatal error ? Shouldn't the enable operation > > > > > > return an int ? > > > > > > > > > > There's no way to propagate this in DRM, so why go through the > > > > > trouble of returning the error? Furthermore, there's nothing that > > > > > the caller could do to remedy the situation anyway. > > > > > > > > That's a DRM issue, which could be fixed. While the caller can't > > > > remedy the situation, it should at least report the error to the > > > > application instead of silently ignoring it. > > > > > > Perhaps. It's not really relevant to the discussion and can always be > > > fixed in a subsequent patch. > > > > Most things can be fixed by a subsequent patch, that's not a good enough > > reason not to address the known problems before pushing the code to > > mainline (to clarify my point of view, there's no need to fix DRM to use > > the return value before pushing this patch set to mainline, but I'd like > > a v2 with an int return value). > > Why? What's the use of returning an error if you know up front that it > can't be used? This should be changed if or when we "fix" DRM to propagate > errors. Because not doing so now will require us to change (potentially) lots of panel drivers at that time. It's much easier to have each panel driver developer implement the required code in his/her driver than having a single developer refactoring the code later and have to touch all drivers. If your concern is that the error paths won't be testable at the moment, you could easily already add a WARN_ON() to the caller to catch problems. > > > > > > Instead of hardcoding the modes in the driver, which would then > > > > > > require to be updated for every new simple panel model (and we > > > > > > know there are lots of them), why don't you specify the modes in > > > > > > the panel DT node ? The simple panel driver would then become much > > > > > > more generic. It would also allow board designers to tweak h/v > > > > > > sync timings depending on the system requirements. > > > > > > > > > > Sigh... we keep second-guessing ourselves. Back at the time when > > > > > power sequences were designed (and NAKed at the last minute), we all > > > > > decided that the right thing to do would be to use specific > > > > > compatible values for individual panels, because that would allow us > > > > > to encode the power sequencing within the driver. And when we > > > > > already have the panel model encoded in the compatible value, we > > > > > might just as well encode the mode within the driver for that panel. > > > > > Otherwise we'll have to keep adding the same mode timings for every > > > > > board that uses the same panel. > > > > > > > > > > I do agree though that it might be useful to tweak the mode in case > > > > > the default one doesn't work. How about we provide a means to > > > > > override the mode encoded in the driver using one specified in the > > > > > DT? That's obviously a backwards-compatible change, so it could be > > > > > added if or when it becomes necessary. > > > > > > > > I share Tomi's point of view here. Your three panels use the same > > > > power sequence, so I believe we should have a generic panel compatible > > > > string that would use modes described in DT for the common case. Only > > > > if a panel required something more complex which can't (or which > > > > could, but won't for any reason) accurately be described in DT would > > > > you need to extend the driver. > > > > > > I don't see the point quite frankly. You seem to be assuming that every > > > panel will only be used in a single board. > > > > No, but in practice that's often the case, at least for boards with .dts > > files in the mainline kernel. > > > > > However what you're proposing will require the mode timings to be > > > repeated in every board's DT file, if the same panel is ever used on > > > more than a single board. > > > > Is that a problem ? You could #include a .dtsi for the panel that would > > specify the video mode if you want to avoid multiple copies. > > Yes, I don't think it's desirable to duplicate data needlessly in DT. It > also makes the binding more difficult to use. If I know that the panel > is one supported by the simple-panel binding, I can just go and add the > right compatible value without having to bother looking up the mode > timings and duplicating them. That way DT writers get to concern > themselves only with the variable data. I've had a quick chat with Dave Airlie and Hans de Goede yesterday about this. As most panels will use standard timings, Hans proposed adding a timings property that would reference the standard timings the panel uses (this could be a string or integer defined in include/dt-bindings/...). In most case DT would just have a single property to select the timings, and only in more complex cases where the system designer wants to use custom timings would the timings need to be manually defined. -- Regards, Laurent Pinchart -- next part -- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 490 bytes Desc: This is a digitally signed message part. URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20131024/8c2fc646/attachment-0001.pgp>
[PATCH] drm/omap: fix (un)registering irqs inside an irq handler
On Thu, Oct 24, 2013 at 2:50 AM, Tomi Valkeinen
wrote:
> omapdrm (un)registers irqs inside an irq handler. The problem is that
> the (un)register function uses dispc_runtime_get/put() to enable the
> clocks, and those functions are not irq safe by default.
>
> This was kind of fixed in 48664b21aeeffb40c5fa06843f18052e2c4ec9ef
> (OMAPDSS: DISPC: set irq_safe for runtime PM), which makes dispc's
> runtime calls irq-safe.
>
> However, using pm_runtime_irq_safe in dispc makes the parent of dispc,
> dss, always enabled, effectively preventing PM for the whole DSS module.
>
> This patch makes omapdrm behave better by adding new irq (un)register
> functions that do not use dispc_runtime_get/put, and using those
> functions in interrupt context. Thus we can make dispc again
> non-irq-safe, allowing proper PM.
Looks good
Reviewed-by: Rob Clark
>
> Signed-off-by: Tomi Valkeinen
> Cc: Rob Clark
> ---
> drivers/gpu/drm/omapdrm/omap_crtc.c | 6 +++---
> drivers/gpu/drm/omapdrm/omap_drv.h | 2 ++
> drivers/gpu/drm/omapdrm/omap_irq.c | 22 ++
> drivers/video/omap2/dss/dispc.c | 1 -
> 4 files changed, 23 insertions(+), 8 deletions(-)
>
> diff --git a/drivers/gpu/drm/omapdrm/omap_crtc.c
> b/drivers/gpu/drm/omapdrm/omap_crtc.c
> index 0fd2eb1..e6241c2 100644
> --- a/drivers/gpu/drm/omapdrm/omap_crtc.c
> +++ b/drivers/gpu/drm/omapdrm/omap_crtc.c
> @@ -411,7 +411,7 @@ static void omap_crtc_error_irq(struct omap_drm_irq *irq,
> uint32_t irqstatus)
> struct drm_crtc *crtc = &omap_crtc->base;
> DRM_ERROR("%s: errors: %08x\n", omap_crtc->name, irqstatus);
> /* avoid getting in a flood, unregister the irq until next vblank */
> - omap_irq_unregister(crtc->dev, &omap_crtc->error_irq);
> + __omap_irq_unregister(crtc->dev, &omap_crtc->error_irq);
> }
>
> static void omap_crtc_apply_irq(struct omap_drm_irq *irq, uint32_t irqstatus)
> @@ -421,13 +421,13 @@ static void omap_crtc_apply_irq(struct omap_drm_irq
> *irq, uint32_t irqstatus)
> struct drm_crtc *crtc = &omap_crtc->base;
>
> if (!omap_crtc->error_irq.registered)
> - omap_irq_register(crtc->dev, &omap_crtc->error_irq);
> + __omap_irq_register(crtc->dev, &omap_crtc->error_irq);
>
> if (!dispc_mgr_go_busy(omap_crtc->channel)) {
> struct omap_drm_private *priv =
> crtc->dev->dev_private;
> DBG("%s: apply done", omap_crtc->name);
> - omap_irq_unregister(crtc->dev, &omap_crtc->apply_irq);
> + __omap_irq_unregister(crtc->dev, &omap_crtc->apply_irq);
> queue_work(priv->wq, &omap_crtc->apply_work);
> }
> }
> diff --git a/drivers/gpu/drm/omapdrm/omap_drv.h
> b/drivers/gpu/drm/omapdrm/omap_drv.h
> index 30b95b7..cfb6c2e 100644
> --- a/drivers/gpu/drm/omapdrm/omap_drv.h
> +++ b/drivers/gpu/drm/omapdrm/omap_drv.h
> @@ -145,6 +145,8 @@ irqreturn_t omap_irq_handler(DRM_IRQ_ARGS);
> void omap_irq_preinstall(struct drm_device *dev);
> int omap_irq_postinstall(struct drm_device *dev);
> void omap_irq_uninstall(struct drm_device *dev);
> +void __omap_irq_register(struct drm_device *dev, struct omap_drm_irq *irq);
> +void __omap_irq_unregister(struct drm_device *dev, struct omap_drm_irq *irq);
> void omap_irq_register(struct drm_device *dev, struct omap_drm_irq *irq);
> void omap_irq_unregister(struct drm_device *dev, struct omap_drm_irq *irq);
> int omap_drm_irq_uninstall(struct drm_device *dev);
> diff --git a/drivers/gpu/drm/omapdrm/omap_irq.c
> b/drivers/gpu/drm/omapdrm/omap_irq.c
> index 9263db1..b08b902 100644
> --- a/drivers/gpu/drm/omapdrm/omap_irq.c
> +++ b/drivers/gpu/drm/omapdrm/omap_irq.c
> @@ -45,12 +45,11 @@ static void omap_irq_update(struct drm_device *dev)
> dispc_read_irqenable();/* flush posted write */
> }
>
> -void omap_irq_register(struct drm_device *dev, struct omap_drm_irq *irq)
> +void __omap_irq_register(struct drm_device *dev, struct omap_drm_irq *irq)
> {
> struct omap_drm_private *priv = dev->dev_private;
> unsigned long flags;
>
> - dispc_runtime_get();
> spin_lock_irqsave(&list_lock, flags);
>
> if (!WARN_ON(irq->registered)) {
> @@ -60,14 +59,21 @@ void omap_irq_register(struct drm_device *dev, struct
> omap_drm_irq *irq)
> }
>
> spin_unlock_irqrestore(&list_lock, flags);
> +}
> +
> +void omap_irq_register(struct drm_device *dev, struct omap_drm_irq *irq)
> +{
> + dispc_runtime_get();
> +
> + __omap_irq_register(dev, irq);
> +
> dispc_runtime_put();
> }
>
> -void omap_irq_unregister(struct drm_device *dev, struct omap_drm_irq *irq)
> +void __omap_irq_unregister(struct drm_device *dev, struct omap_drm_irq *irq)
> {
> unsigned long flags;
>
> - dispc_runtime_get();
> spin_lock_irqsave(&list_lock, flags);
>
> if (!WARN_ON(!irq->registered)) {
> @@ -77,6 +83,14 @@ void omap_irq_unregister(struct
[RFR 2/2] drm/panel: Add simple panel support
> > > There's no way to propagate this in DRM, so why go through the > > > > > > trouble of returning the error? Furthermore, there's nothing that > > > > > > the caller could do to remedy the situation anyway. > > > > > > > > > > That's a DRM issue, which could be fixed. While the caller can't > > > > > remedy the situation, it should at least report the error to the > > > > > application instead of silently ignoring it. > > > > > > > > Perhaps. It's not really relevant to the discussion and can always be > > > > fixed in a subsequent patch. > > > > > > Most things can be fixed by a subsequent patch, that's not a good enough > > > reason not to address the known problems before pushing the code to > > > mainline (to clarify my point of view, there's no need to fix DRM to use > > > the return value before pushing this patch set to mainline, but I'd like > > > a v2 with an int return value). > > > > Why? What's the use of returning an error if you know up front that it > > can't be used? This should be changed if or when we "fix" DRM to propagate > > errors. > > Because not doing so now will require us to change (potentially) lots of > panel > drivers at that time. It's much easier to have each panel driver developer > implement the required code in his/her driver than having a single developer > refactoring the code later and have to touch all drivers. If your concern is > that the error paths won't be testable at the moment, you could easily > already > add a WARN_ON() to the caller to catch problems. I don't mind fixing potentially many drivers. The conversion is pretty mechanical and therefore easy. We even have tools such as coccinelle to help with it. But we've probably spent more time arguing the point than it would take to make this simple change, so I'll just go and change the return value to an int and return an error. Perhaps if I'm in the mood I'll even write up a patch to propagate the error further. > > > > > > > Instead of hardcoding the modes in the driver, which would then > > > > > > > require to be updated for every new simple panel model (and we > > > > > > > know there are lots of them), why don't you specify the modes in > > > > > > > the panel DT node ? The simple panel driver would then become much > > > > > > > more generic. It would also allow board designers to tweak h/v > > > > > > > sync timings depending on the system requirements. > > > > > > > > > > > > Sigh... we keep second-guessing ourselves. Back at the time when > > > > > > power sequences were designed (and NAKed at the last minute), we all > > > > > > decided that the right thing to do would be to use specific > > > > > > compatible values for individual panels, because that would allow us > > > > > > to encode the power sequencing within the driver. And when we > > > > > > already have the panel model encoded in the compatible value, we > > > > > > might just as well encode the mode within the driver for that panel. > > > > > > Otherwise we'll have to keep adding the same mode timings for every > > > > > > board that uses the same panel. > > > > > > > > > > > > I do agree though that it might be useful to tweak the mode in case > > > > > > the default one doesn't work. How about we provide a means to > > > > > > override the mode encoded in the driver using one specified in the > > > > > > DT? That's obviously a backwards-compatible change, so it could be > > > > > > added if or when it becomes necessary. > > > > > > > > > > I share Tomi's point of view here. Your three panels use the same > > > > > power sequence, so I believe we should have a generic panel compatible > > > > > string that would use modes described in DT for the common case. Only > > > > > if a panel required something more complex which can't (or which > > > > > could, but won't for any reason) accurately be described in DT would > > > > > you need to extend the driver. > > > > > > > > I don't see the point quite frankly. You seem to be assuming that every > > > > panel will only be used in a single board. > > > > > > No, but in practice that's often the case, at least for boards with .dts > > > files in the mainline kernel. > > > > > > > However what you're proposing will require the mode timings to be > > > > repeated in every board's DT file, if the same panel is ever used on > > > > more than a single board. > > > > > > Is that a problem ? You could #include a .dtsi for the panel that would > > > specify the video mode if you want to avoid multiple copies. > > > > Yes, I don't think it's desirable to duplicate data needlessly in DT. It > > also makes the binding more difficult to use. If I know that the panel > > is one supported by the simple-panel binding, I can just go and add the > > right compatible value without having to bother looking up the mode > > timings and duplicating them. That way DT writers get to concern > > themselves only with the variable data. > > I've had a quick chat with Dave Airlie and Hans de Goede yesterday about > this. > As most panels will use standard timings, Hans proposed adding a timings > property that would reference the standard timings the panel uses (this could > be a string or integer defined in include/dt-bindings/...). In most case DT > would just have a single property to select the timings, and only in more > complex cases where the system designer wants to use custom timings would the > timings need to be manually defined. We can do the same thing within the kernel. We already have a list of standard EDID/HDMI/CEA display modes, so we could similarly add a new list of common display panel modes and make each driver reference that instead of defining a custom one. And that still enables us to add a property that would allow DT writers to override the display mode if they need to. 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/20131024/1183d002/attachment.pgp>
[Linaro-mm-sig] thoughts of looking at android fences
op 09-10-13 16:39, Maarten Lankhorst schreef:
> Hey,
>
> op 08-10-13 19:37, John Stultz schreef:
>> On Wed, Oct 2, 2013 at 11:13 AM, Erik Gilling wrote:
>>> On Wed, Oct 2, 2013 at 12:35 AM, Maarten Lankhorst
>>> wrote:
Depending on feedback I'll try reflashing my nexus 7 to stock android, and
work on trying to convert android
syncpoints to dma-fence, which I'll probably rename to syncpoints.
>>> I thought the plan decided at plumbers was to investigate backing
>>> dma_buf with the android sync solution not the other way around. It
>>> doesn't make sense to me to take a working, tested, end-to-end
>>> solution with a released compositing system built around it, throw it
>>> out, and replace it with new un-tested code to
>>> support a system which is not yet built.
>> Hey Erik,
>> Thanks for the clarifying points in your email, your insights and
>> feedback are critical, and I think having you and Maarten continue to
>> work out the details here will make this productive.
>>
>> My recollection from the discussion was that Rob was ok with trying to
>> pipe the sync arguments through the various interfaces in order to
>> support the explicit sync, but I think he did suggest having it backed
>> by the dma-buf fences underneath.
>>
>> I know this can be frustrating to watch things be reimplemented when
>> you have a pre-baked solution, but some compromise will be needed to
>> get things merged (and Maarten is taking the initiative here), but its
>> important to keep discussing this so the *right* compromises are made
>> that don't hurt performance, etc.
>>
>> My hope is Maarten's approach of getting the dma-fence core
>> integrated, and then moving the existing Android sync interface over
>> to the shared back-end, will allow for proper apples-to-apples
>> comparisons of the same interface. And if the functionality isn't
>> sufficient we can hold off on merging the sync interface conversion
>> until that gets resolved.
>>
> Yeah, I'm trying to understand the android side too. I think a unified
> interface would benefit both. I'm
> toying a bit with the sw_sync driver in staging because it's the easiest to
> try out on my desktop.
>
> The timeline stuff looks like it could be simplified. The main difference
> that there seems to be is that
> I didn't want to create a separate timeline struct for synchronization but
> let the drivers handle it.
>
> If you use rcu for reference lifetime management of timeline, the kref can be
> dropped. Signalling all
> syncpts on timeline destroy to a new destroyed state would kill the need for
> a destroyed member.
> The active list is unneeded and can be killed if only a linear progression of
> child_list is allowed.
>
> Which probably leaves this nice structure:
> struct sync_timeline {
> const struct sync_timeline_ops*ops;
> charname[32];
>
> struct list_headchild_list_head;
> spinlock_tchild_list_lock;
>
> struct list_headsync_timeline_list;
> };
>
> Where name, and sync_timeline_list are nice for debugging, but I guess not
> necessarily required. so that
> could be split out into a separate debugfs thing if required. I've moved the
> pointer to ops to the fence
> for dma-fence, which leaves this..
>
> struct sync_timeline {
> struct list_headchild_list_head;
> spinlock_tchild_list_lock;
>
> struct sync_timeline_debug {
> struct list_headsync_timeline_list;
> char name[32];
> };
> };
>
> Hm, this looks familiar, the drm drivers had some structure for protecting
> the active fence list that has
> an identical definition, but with a slightly different list offset..
>
> struct __wait_queue_head {
> spinlock_t lock;
> struct list_head task_list;
> };
>
> typedef struct __wait_queue_head wait_queue_head_t;
>
> This is nicer to convert the existing drm drivers, which already implement
> synchronous wait with a waitqueue.
> The default wait op is in fact
>
> Ok enough of this little excercise. I just wanted to see how different the 2
> are. I think even if the
> fence interface will end up being incompatible it wouldn't be too hard to
> convert android..
>
> Main difference is the ops, android has a lot more than what I used for
> dma-fence:
>
> struct fence_ops {
> bool (*enable_signaling)(struct fence *fence); // required, callback
> called with fence->lock held,
> // fence->lock is a pointer passed to __fence_init. Callback should
> make sure that the fence will
> // be signaled asap.
> bool (*signaled)(struct fence *fence); // optional, but if set to NULL
> fence_is_signaled is not
> // required to ever return true, unless enable_signaling is called,
> similar to has_signaled
> long (*wait)(struct fence *fence, bool intr, signed long timeout); //
> required, but it can be set
> // to the default fence_default_wait implementation which is
> recommended. It calls enable_signaling
> //
drm/i915: Avoid accessing the stolen address when it is unavailable
On Fri, Oct 25, 2013 at 12:33:47AM +0800, Chuansheng Liu wrote: > > In our platform, we hit the the stolen region initialization failure case, > such as below log: > [drm:i915_stolen_to_physical] *ERROR* conflict detected with stolen region: > [0x7b00] > > And it causes the dev_priv->mm.stolen_base is NULL, in this case, we should > avoid accessing it any more. > > Here is possible call trace: > intel_enable_gt_powersave -- > > valleyview_enable_rps -- > > valleyview_setup_pctx The two create_stolen routines are no-ops in that case so all that happens instead is that we read VLV_PCBR. However, really if i915_gem_object_create_stolen_for_preallocated() fails we should abort loading the driver as it means we have a hardware conflict and undefined behaviour. -Chris -- Chris Wilson, Intel Open Source Technology Centre
HPD flood warning since b8f102e8b
On Thu, 24 Oct 2013, Jiri Kosina wrote: > I have this: > > [357128.184113] [drm] HPD interrupt storm detected on connector DP-3: > switching from hotplug detection to polling > > It appeared in the log approximately 5 seconds after resume has been > completed. Okay, and it just happened during resume from RAM (it was a very long series of repeating the same trace, I am putting here just the last portion): [362634.813953] [ cut here ] [362634.813980] WARNING: CPU: 0 PID: 666 at drivers/gpu/drm/i915/i915_irq.c:1001 i965_irq_handler+0x492/0x680 [i915]() [362634.813981] Received HPD interrupt although disabled [362634.814021] Modules linked in: sr_mod cdrom dm_mod fuse af_packet tun iptable_mangle xt_DSCP nf_conntrack_ipv6 nf_defrag_ipv6 ip6table_filter ip6_tables xt_tcpudp nf_conntrack_ipv4 nf_defrag_ipv4 xt_state nf_conntrack iptable_filter ip_tables x_tables nls_cp1250 nls_cp437 vfat fat rfcomm bnep cpufreq_conservative cpufreq_userspace cpufreq_powersave iTCO_wdt iTCO_vendor_support snd_hda_codec_conexant kvm_intel kvm usb_storage snd_hda_intel iwldvm snd_hda_codec mac80211 snd_hwdep iwlwifi sg snd_pcm cfg80211 snd_seq btusb bluetooth snd_timer pcspkr snd_seq_device thinkpad_acpi lpc_ich rfkill mfd_core i2c_i801 tpm_tis ac tpm battery snd tpm_bios e1000e soundcore snd_page_alloc wmi acpi_cpufreq ehci_pci ptp pps_core autofs4 uhci_hcd ehci_hcd usbcore usb_common i915 drm_kms_helper drm i2c_algo_bit video button edd fan processor ata_generic thermal thermal_sys [362634.814028] CPU: 0 PID: 666 Comm: rs:main Q:Reg Tainted: GW 3.12.0-rc4-6-g162bdaf-dirty #1 [362634.814029] Hardware name: LENOVO 7470BN2/7470BN2, BIOS 6DET38WW (2.02 ) 12/19/2008 [362634.814033] 03e9 88007c203d18 81583863 88007c203d58 [362634.814035] 8104d297 88007c203d98 0010 0002 [362634.814038] 88003718 0005 88003718 88007c203db8 [362634.814039] Call Trace: [362634.814044][] dump_stack+0x7a/0x97 [362634.814048] [] warn_slowpath_common+0x87/0xb0 [362634.814051] [] warn_slowpath_fmt+0x41/0x50 [362634.814067] [] i965_irq_handler+0x492/0x680 [i915] [362634.814072] [] handle_irq_event_percpu+0xac/0x220 [362634.814074] [] handle_irq_event+0x49/0x70 [362634.814077] [] handle_edge_irq+0x7f/0x150 [362634.814080] [] handle_irq+0x59/0x150 [362634.814083] [] ? irq_enter+0x16/0x90 [362634.814085] [] do_IRQ+0x5b/0xe0 [362634.814089] [] common_interrupt+0x6f/0x6f [362634.814093][] ? lock_acquire+0x110/0x130 [362634.814096] [] ? notifier_call_chain+0xa0/0xa0 [362634.814098] [] __atomic_notifier_call_chain+0x6a/0xc0 [362634.814101] [] ? notifier_call_chain+0xa0/0xa0 [362634.814103] [] atomic_notifier_call_chain+0x11/0x20 [362634.814106] [] do_con_write+0x22f/0xa10 [362634.814109] [] ? mutex_lock_nested+0x2ef/0x370 [362634.814111] [] ? trace_hardirqs_on_caller+0x13d/0x1e0 [362634.814115] [] ? process_output_block+0x3d/0x1e0 [362634.814118] [] con_write+0x19/0x30 [362634.814120] [] process_output_block+0xd0/0x1e0 [362634.814123] [] n_tty_write+0x18b/0x370 [362634.814126] [] ? try_to_wake_up+0x240/0x240 [362634.814129] [] do_tty_write+0xbc/0x200 [362634.814131] [] ? n_tty_ioctl+0x110/0x110 [362634.814134] [] tty_write+0xc4/0xf0 [362634.814137] [] vfs_write+0xe7/0x190 [362634.814139] [] SyS_write+0x60/0xb0 [362634.814142] [] system_call_fastpath+0x16/0x1b [362634.814144] ---[ end trace f54ed427593b8ca0 ]--- [362634.894446] [ cut here ] [362634.894476] WARNING: CPU: 1 PID: 1 at drivers/gpu/drm/i915/i915_irq.c:1001 i965_irq_handler+0x492/0x680 [i915]() [362634.894479] Received HPD interrupt although disabled [362634.894481] Modules linked in: sr_mod cdrom dm_mod fuse af_packet tun iptable_mangle xt_DSCP nf_conntrack_ipv6 nf_defrag_ipv6 ip6table_filter ip6_tables xt_tcpudp nf_conntrack_ipv4 nf_defrag_ipv4 xt_state nf_conntrack iptable_filter ip_tables x_tables nls_cp1250 nls_cp437 vfat fat rfcomm bnep cpufreq_conservative cpufreq_userspace cpufreq_powersave iTCO_wdt iTCO_vendor_support snd_hda_codec_conexant kvm_intel kvm usb_storage snd_hda_intel iwldvm snd_hda_codec mac80211 snd_hwdep iwlwifi sg snd_pcm cfg80211 snd_seq btusb bluetooth snd_timer pcspkr snd_seq_device thinkpad_acpi lpc_ich rfkill mfd_core i2c_i801 tpm_tis ac tpm battery snd tpm_bios e1000e soundcore snd_page_alloc wmi acpi_cpufreq ehci_pci ptp pps_core autofs4 uhci_hcd ehci_hcd usbcore usb_common i915 drm_kms_helper drm i2c_algo_bit video button edd fan processor ata_generic thermal thermal_sys [362634.894562] CPU: 1 PID: 1 Comm: systemd Tainted: GW 3.12.0-rc4-6-g162bdaf-dirty #1 [362634.894564] Hardware name: LENOVO 7470BN2/7470BN2, BIOS 6DET38WW (2.02 ) 12/19/2008 [362634.894567] 03e9 88007c283d18 81583863 88007c283d58 [362634.894572] 8104d297 88007c283d98 0010 0002 [362634.894577]
HPD flood warning since b8f102e8b
Jiri Kosina writes: > On Mon, 21 Oct 2013, Egbert Eich wrote: > > > > On Thu, 3 Oct 2013, Daniel Vetter wrote: > > > > > > > Can you please attach full dmesg from boot up to the first WARN with > > > > drm.debug=0xe? This really shouldn't happen and indicates a bug > > > > somewhere ... > > > > > > A bit difficult ... I originally thought that it was reliably > > > reproducible, but now I didn't get it after 10 suspend/resume cycles. > > Will > > > keep following it, and once it appears, will send you the dmesg. > > > > > Could you check if you get any messages regarding HPD storms after > > suspend/resume ie messages like: > > "[drm] HPD interrupt storm detected on connector HDMI-A-1" > > but without the annouing warn messages? > > I have this: > > [357128.184113] [drm] HPD interrupt storm detected on connector DP-3: > switching from hotplug detection to polling > > It appeared in the log approximately 5 seconds after resume has been > completed. > :( You seem to get this on different connector. Any chance for a 'lspci -n' output? Cheers, Egbert.
HPD flood warning since b8f102e8b
On Thu, 24 Oct 2013, Egbert Eich wrote: > > > > > Can you please attach full dmesg from boot up to the first WARN with > > > > > drm.debug=0xe? This really shouldn't happen and indicates a bug > > > > > somewhere ... > > > > > > > > A bit difficult ... I originally thought that it was reliably > > > > reproducible, but now I didn't get it after 10 suspend/resume cycles. > Will > > > > keep following it, and once it appears, will send you the dmesg. > > > > > > > Could you check if you get any messages regarding HPD storms after > > > suspend/resume ie messages like: > > > "[drm] HPD interrupt storm detected on connector HDMI-A-1" > > > but without the annouing warn messages? > > > > I have this: > > > > [357128.184113] [drm] HPD interrupt storm detected on connector DP-3: > switching from hotplug detection to polling > > > > It appeared in the log approximately 5 seconds after resume has been > > completed. > > > > :( You seem to get this on different connector. > > Any chance for a 'lspci -n' output? 00:00.0 0600: 8086:2a40 (rev 07) 00:02.0 0300: 8086:2a42 (rev 07) 00:02.1 0380: 8086:2a43 (rev 07) 00:03.0 0780: 8086:2a44 (rev 07) 00:03.2 0101: 8086:2a46 (rev 07) 00:03.3 0700: 8086:2a47 (rev 07) 00:19.0 0200: 8086:10f5 (rev 03) 00:1a.0 0c03: 8086:2937 (rev 03) 00:1a.1 0c03: 8086:2938 (rev 03) 00:1a.2 0c03: 8086:2939 (rev 03) 00:1a.7 0c03: 8086:293c (rev 03) 00:1b.0 0403: 8086:293e (rev 03) 00:1c.0 0604: 8086:2940 (rev 03) 00:1c.1 0604: 8086:2942 (rev 03) 00:1c.3 0604: 8086:2946 (rev 03) 00:1d.0 0c03: 8086:2934 (rev 03) 00:1d.1 0c03: 8086:2935 (rev 03) 00:1d.2 0c03: 8086:2936 (rev 03) 00:1d.7 0c03: 8086:293a (rev 03) 00:1e.0 0604: 8086:2448 (rev 93) 00:1f.0 0601: 8086:2917 (rev 03) 00:1f.2 0106: 8086:2929 (rev 03) 00:1f.3 0c05: 8086:2930 (rev 03) 03:00.0 0280: 8086:4237 I (and the computer in question) am in Edinburgh till friday, in case someone wants to have a look. -- Jiri Kosina SUSE Labs
[PULL] drm-intel-next
Hi Dave, drm-intel-next-2013-10-18: - CRC support from Damien and He Shuang. Long term this should allow us to test an awful lot modesetting corner cases automatically. So for me as the maintainer this is really big. - HDMI audio fix from Jani. - VLV dpll computation code refactoring from Ville. - Fixups for the gpu booster from last time around (Chris). - Some cleanups in the context code from Ben. - More watermark work from Ville (we'll be getting there ...). - vblank timestamp improvements from Ville. - CONFIG_FB=n support, including drm core changes to make the fbdev helpers optional. - DP link training improvements (Jani). - mmio vtable from Ben, prep work for future hw. There shouldn't be a conflict with drm-next (but I haven't done an explicit test-merge). But there's quite a bit of fun with -fixes going on. Maybe we need some backmerge ... Cheers, Daniel The following changes since commit 967ad7f1489da7babbe0746f81c283458ecd3f84: Merge remote-tracking branch 'airlied/drm-next' into drm-intel-next (2013-10-10 12:44:43 +0200) are available in the git repository at: git://people.freedesktop.org/~danvet/drm-intel tags/drm-intel-next-2013-10-18 for you to fetch changes up to 6da7f10d296f4ac625f96b39eef22c41398727e3: drm/i915/dp: don't mention eDP bpp clamping if it doesn't affect bpp (2013-10-18 16:00:06 +0200) Artem Bityutskiy (1): drm/i915: preserve dispaly init order on ByT Ben Widawsky (12): drm/i915: Use the real cpu max frequency for ring scaling drm/i915: Prevent using uninitialized MMIO funcs drm/i915: Move edram detection early_sanitize drm/i915: Create MMIO virtual functions drm/i915: Extract common MMIO lines drm/i915: Create GEN specific read MMIO drm/i915: Create GEN specific write MMIO drm/i915: Remove gen specific checks in MMIO drm/i915: Do PCH and uncore init earlier drm/i915: Do a fuller init after reset drm/i915: cleanup context fini drm/i915: Replace has_bsd/blt/vebox with a mask Chon Ming Lee (1): drm/i915: Move some hdmi enable function name to vlv specific. Chris Wilson (7): drm/i915: Call io_schedule() whilst whilsting for the GPU drm/i915: Fix type mismatch and accounting in i915_gem_shrink drm/i915: Undo the PIPEA quirk for i845 drm/i915: Capture the initial error-state when kicking stuck rings drm/i915: Avoid tweaking RPS before it is enabled drm/i915: Add breadcrumbs for why the backlight is being set drm/i915: Disable all GEM timers and work on unload Damien Lespiau (16): drm/i915: Remove yet another unused define drm/i915: Keep the CRC values into a circular buffer drm/i915: Sample the frame counter instead of a timestamp for CRCs drm/i915: Make switching to the same CRC source a no-op drm/i915: Enforce going back to none before changing CRC source drm/i915: Empty the circular buffer when asked for a new source drm/i915: Dynamically allocate the CRC circular buffer drm/i915: Generalize the CRC command format for future work drm/i915: Rename i915_pipe_crc_ctl to i915_display_crc_ctl drm/i915: Warn if we receive an interrupt after freeing the buffer drm/i915: Add log messages when CRCs collection is started/stopped drm/i915: Move drm_add_fake_info_node() higher in the file drm/i915: Implement blocking read for pipe CRC files drm/i915: Only one open() allowed on pipe CRC result files drm/i915: Enable pipe CRCs drm/i915: Use pipe_name() instead of the pipe number Daniel Vetter (24): drm/i915: check that the i965g/gm 4G limit is really obeyed drm/i915: rip out gen2 reset code drm/i915: Keep intel_drv.h tidy drm/i915: Educate users in dmesg about reporting gpu hangs drm: Add separate Kconfig option for fbdev helpers drm/i915: Kconfig option to disable the legacy fbdev support drm/i915: rename intel_fb.c to intel_fbdev.c drm/i915: Add a control file for pipe CRCs drm/i915: static inline for dummy crc functions drm/i915: constify harder drm/i915: grab dev->struct_mutex around framebuffer_init drm/i915: prevent tiling changes on framebuffer backing storage drm/i915: Use unsigned long for obj->user_pin_count drm/i915: check gem bo size when creating framebuffers cpufreq: Add dummy cpufreq_cpu_get/put for CONFIG_CPU_FREQ=n drm/i915: don't Oops in debugfs for I915_FBDEV=n drm/i915: extract display_pipe_crc_update drm/i915: add CRC #defines for ilk/snb drm/i915: wire up CRC interrupt for ilk/snb drm/i915: use ->get_vblank_counter for the crc frame counter drm/i915: wait one vblank when disabling CRCs drm/i915: fix CRC debugfs setup drm/i915: crc support for hsw drm/i915: remove dead code in ironlake_crtc_mode_set Imre Deak (1):
[Bug 70227] OpenCL reaper-prime app crashes due to atomic_or unimplemented
https://bugs.freedesktop.org/show_bug.cgi?id=70227 --- Comment #1 from Alexey Shvetsov --- With recent llvm master branch build now it failes with Building kernel CalculateMultipliers Building kernel Sieve Building kernel Combine Building kernel Fermat LLVM ERROR: Cannot select: 0x7f638ce2c2d0: i32,ch = AtomicLoadAdd 0x7f638ce86840, 0x7f638ce25e60, 0x7f638ce25f60 [ORD=36] [ID=12] 0x7f638ce25e60: i32,ch = CopyFromReg 0x7f638ce86840, 0x7f638ce2b7c0 [ORD=36] [ID=8] 0x7f638ce2b7c0: i32 = Register %vreg4 [ID=2] 0x7f638ce25f60: i32 = Constant<1> [ID=1] In function: Combine -- 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/20131024/208a81a9/attachment.html>
[Bug 70227] OpenCL reaper-prime app crashes due to atomic_or unimplemented
https://bugs.freedesktop.org/show_bug.cgi?id=70227 --- Comment #2 from Alexey Shvetsov --- And sometimes again with old error Building kernel Combine Building kernel Fermat 0x7f19ac3e0a30: i32 = GlobalAddress 0 [ORD=104] Stack dump: 0. Running pass 'Function Pass Manager' on module 'radeon'. 1. Running pass 'AMDGPU DAG->DAG Pattern Instruction Selection' on function '@Sieve' -- 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/20131024/78e18dd6/attachment.html>
How to change radeon power state
On Wed, Oct 23, 2013 at 05:36:18PM -0400, Alex Deucher wrote: > On Sat, Oct 19, 2013 at 10:15 PM, Daniel Mota Leite > > to the current frequencies. In that app, the powerstate 1 is called > > battery and the powerstate 2 is called performance. > > > > I can switch the two and reflash, but to me seems logic that one > > can manually choose what powerstate to use if needed, just like the > > powerlevels (excluding the middle powerlevel problem) > > You'll need to fix the power state to be flagged as performance. Ok, i didn't do that already because the different powerstate names that the rbe and the dpm read from the firmware (battery and performance vs performance and "none" for powerstate 1 and 2 respectively ). Please note that i can change the powerstate values, but not their names. Can this be a bug in reading the powerstates? if not, i will reflash the firmware. Also, how about que question about the middle power level? how to force it? low and high works, but mid or middle do not. Thanks again higuita
[Intel-gfx] drm/i915: Avoid accessing the stolen address when it is unavailable
On Thu, Oct 24, 2013 at 01:17:06PM +0100, Chris Wilson wrote: > On Fri, Oct 25, 2013 at 12:33:47AM +0800, Chuansheng Liu wrote: > > > > In our platform, we hit the the stolen region initialization failure case, > > such as below log: > > [drm:i915_stolen_to_physical] *ERROR* conflict detected with stolen region: > > [0x7b00] > > > > And it causes the dev_priv->mm.stolen_base is NULL, in this case, we should > > avoid accessing it any more. > > > > Here is possible call trace: > > intel_enable_gt_powersave -- > > > valleyview_enable_rps -- > > > valleyview_setup_pctx > > The two create_stolen routines are no-ops in that case so all that > happens instead is that we read VLV_PCBR. However, really if > i915_gem_object_create_stolen_for_preallocated() fails we should abort > loading the driver as it means we have a hardware conflict and undefined > behaviour. > -Chris > > -- > Chris Wilson, Intel Open Source Technology Centre I agree. We should start treating these things as errors since no RPS/RC6 is essentially not what anyone wants. For another immediate solution it seems you can demote the DRM_ERROR to DRM_DEBUG_DRIVER, and add a check in valleyview_enable_rps for the pctx value. -- Ben Widawsky, Intel Open Source Technology Center
[Bug 70191] [r600g] White icons and font with compiz
https://bugs.freedesktop.org/show_bug.cgi?id=70191 --- Comment #1 from Harald Judt --- Created attachment 88090 --> https://bugs.freedesktop.org/attachment.cgi?id=88090&action=edit r600-debug-unset.png I finally got around to make screenshots. For this image, I had to use the camera of my mobile phone, otherwise the problem would not have been visible. Note the solid white icons, and the font looks a bit different (also white) from what it should look like, but that difference is hard to see in this picture. There are other corruptions on screen, like on the window decorations but that is not shown here. This is with R600_DEBUG="". -- 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/20131024/59ad8d78/attachment.html>
[Bug 70191] [r600g] White icons and font with compiz
https://bugs.freedesktop.org/show_bug.cgi?id=70191 --- Comment #2 from Harald Judt --- Created attachment 88091 --> https://bugs.freedesktop.org/attachment.cgi?id=88091&action=edit r600-debug-nosb.png For comparison, this is how it should really look like (except the wallpaper in the background didn't make it on the screenshot). R600_DEBUG=nosb -- 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/20131024/4f8eb07e/attachment.html>
[Bug 69341] [radeonsi] KDE 4.11 is EXTREMELY slow with Raster QT backend
https://bugs.freedesktop.org/show_bug.cgi?id=69341 --- Comment #19 from langkamp at tomblog.de --- Also have HD 7950 on kde 4.11 (opensuse factory+kernel 3.12 and graphical stack from git via pontostroy repo) - opengl + raster = very fast, seldom small graphical glitches - opengl + native = fast, no glitches so far - xrender + raster = very fast, no glitches so far - xrender + native = very fast, permanent huge glitches -- 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/20131024/fcb80b2a/attachment.html>
[RFCv2 10/13] drm: convert plane to properties/state
On Mon, Oct 14, 2013 at 01:26:45PM -0400, Rob Clark wrote:
> Break the mutable state of a plane out into a separate structure
> and use atomic properties mechanism to set plane attributes. This
> makes it easier to have some helpers for plane->set_property()
> and for checking for invalid params. The idea is that individual
> drivers can wrap the state struct in their own struct which adds
> driver specific parameters, for easy build-up of state across
> multiple set_property() calls and for easy atomic commit or roll-
> back.
>
> The same should be done for CRTC, encoder, and connector, but this
> patch only includes the first part (plane).
> ---
> drivers/gpu/drm/drm_atomic_helper.c | 137 +-
> drivers/gpu/drm/drm_crtc.c | 399
> +++-
> drivers/gpu/drm/drm_fb_helper.c | 17 +-
> drivers/gpu/drm/exynos/exynos_drm_crtc.c| 4 +-
> drivers/gpu/drm/exynos/exynos_drm_encoder.c | 6 +-
> drivers/gpu/drm/exynos/exynos_drm_plane.c | 13 +-
> drivers/gpu/drm/i915/intel_sprite.c | 19 +-
> drivers/gpu/drm/msm/mdp4/mdp4_crtc.c| 2 +-
> drivers/gpu/drm/msm/mdp4/mdp4_plane.c | 18 +-
> drivers/gpu/drm/omapdrm/omap_crtc.c | 4 +-
> drivers/gpu/drm/omapdrm/omap_drv.c | 2 +-
> drivers/gpu/drm/omapdrm/omap_plane.c| 30 ++-
> drivers/gpu/drm/rcar-du/rcar_du_plane.c | 5 +-
> drivers/gpu/drm/shmobile/shmob_drm_crtc.c | 2 +-
> drivers/gpu/drm/shmobile/shmob_drm_plane.c | 6 +-
> drivers/gpu/host1x/drm/dc.c | 16 +-
> include/drm/drm_atomic_helper.h | 37 ++-
> include/drm/drm_crtc.h | 88 +-
> 18 files changed, 615 insertions(+), 190 deletions(-)
>
> diff --git a/drivers/gpu/drm/drm_atomic_helper.c
> b/drivers/gpu/drm/drm_atomic_helper.c
> index 46c67b8..0618113 100644
> --- a/drivers/gpu/drm/drm_atomic_helper.c
> +++ b/drivers/gpu/drm/drm_atomic_helper.c
> @@ -39,10 +39,12 @@
> void *drm_atomic_helper_begin(struct drm_device *dev, uint32_t flags)
> {
> struct drm_atomic_helper_state *state;
> + int nplanes = dev->mode_config.num_plane;
> int sz;
> void *ptr;
>
> sz = sizeof(*state);
> + sz += (sizeof(state->planes) + sizeof(state->pstates)) * nplanes;
>
> ptr = kzalloc(sz, GFP_KERNEL);
>
> @@ -52,6 +54,13 @@ void *drm_atomic_helper_begin(struct drm_device *dev,
> uint32_t flags)
> kref_init(&state->refcount);
> state->dev = dev;
> state->flags = flags;
> +
> + state->planes = ptr;
> + ptr = &state->planes[nplanes];
> +
> + state->pstates = ptr;
> + ptr = &state->pstates[nplanes];
> +
> return state;
> }
> EXPORT_SYMBOL(drm_atomic_helper_begin);
> @@ -87,7 +96,19 @@ EXPORT_SYMBOL(drm_atomic_helper_set_event);
> */
> int drm_atomic_helper_check(struct drm_device *dev, void *state)
> {
> - return 0; /* for now */
> + struct drm_atomic_helper_state *a = state;
> + int nplanes = dev->mode_config.num_plane;
> + int i, ret = 0;
> +
> + for (i = 0; i < nplanes; i++) {
> + if (a->planes[i]) {
> + ret = drm_atomic_check_plane_state(a->planes[i],
> a->pstates[i]);
> + if (ret)
> + break;
> + }
> + }
> +
> + return ret;
> }
> EXPORT_SYMBOL(drm_atomic_helper_check);
>
> @@ -104,7 +125,19 @@ EXPORT_SYMBOL(drm_atomic_helper_check);
> */
> int drm_atomic_helper_commit(struct drm_device *dev, void *state)
> {
> - return 0; /* for now */
> + struct drm_atomic_helper_state *a = state;
> + int nplanes = dev->mode_config.num_plane;
> + int i, ret = 0;
> +
> + for (i = 0; i < nplanes; i++) {
> + if (a->planes[i]) {
> + ret = drm_atomic_commit_plane_state(a->planes[i],
> a->pstates[i]);
> + if (ret)
> + break;
> + }
> + }
> +
> + return ret;
> }
> EXPORT_SYMBOL(drm_atomic_helper_commit);
>
> @@ -125,11 +158,111 @@ void _drm_atomic_helper_state_free(struct kref *kref)
> {
> struct drm_atomic_helper_state *state =
> container_of(kref, struct drm_atomic_helper_state, refcount);
> + struct drm_device *dev = state->dev;
> + int nplanes = dev->mode_config.num_plane;
> + int i;
> +
> + for (i = 0; i < nplanes; i++) {
> + if (state->pstates[i]) {
> + state->planes[i]->state->state = NULL;
> + kfree(state->pstates[i]);
> + }
> + }
> +
> kfree(state);
> }
> EXPORT_SYMBOL(_drm_atomic_helper_state_free);
>
> +int drm_atomic_helper_plane_set_property(struct drm_plane *plane, void
> *state,
> + struct drm_property *property, uint64_t val, void *blob_data)
> +{
> + return drm_plane_set_property(plane,
> + drm_atomic_get_plane_state(plane, state),
> +
[Bug 34495] Selecting objects in Blender 2.56 slow with gallium r600 driver
https://bugs.freedesktop.org/show_bug.cgi?id=34495 --- Comment #70 from kao_chen --- I wonder if the fix has been committed? I am using Debian testing with the mesa 9.1-7 package provided in the testing repository, and the selections with Blender are still very slow. -- 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/20131024/c226e17c/attachment.html>
[RFCv2 10/13] drm: convert plane to properties/state
On Thu, Oct 24, 2013 at 5:48 PM, Matt Roper
wrote:
> On Mon, Oct 14, 2013 at 01:26:45PM -0400, Rob Clark wrote:
>> Break the mutable state of a plane out into a separate structure
>> and use atomic properties mechanism to set plane attributes. This
>> makes it easier to have some helpers for plane->set_property()
>> and for checking for invalid params. The idea is that individual
>> drivers can wrap the state struct in their own struct which adds
>> driver specific parameters, for easy build-up of state across
>> multiple set_property() calls and for easy atomic commit or roll-
>> back.
>>
>> The same should be done for CRTC, encoder, and connector, but this
>> patch only includes the first part (plane).
>> ---
>> drivers/gpu/drm/drm_atomic_helper.c | 137 +-
>> drivers/gpu/drm/drm_crtc.c | 399
>> +++-
>> drivers/gpu/drm/drm_fb_helper.c | 17 +-
>> drivers/gpu/drm/exynos/exynos_drm_crtc.c| 4 +-
>> drivers/gpu/drm/exynos/exynos_drm_encoder.c | 6 +-
>> drivers/gpu/drm/exynos/exynos_drm_plane.c | 13 +-
>> drivers/gpu/drm/i915/intel_sprite.c | 19 +-
>> drivers/gpu/drm/msm/mdp4/mdp4_crtc.c| 2 +-
>> drivers/gpu/drm/msm/mdp4/mdp4_plane.c | 18 +-
>> drivers/gpu/drm/omapdrm/omap_crtc.c | 4 +-
>> drivers/gpu/drm/omapdrm/omap_drv.c | 2 +-
>> drivers/gpu/drm/omapdrm/omap_plane.c| 30 ++-
>> drivers/gpu/drm/rcar-du/rcar_du_plane.c | 5 +-
>> drivers/gpu/drm/shmobile/shmob_drm_crtc.c | 2 +-
>> drivers/gpu/drm/shmobile/shmob_drm_plane.c | 6 +-
>> drivers/gpu/host1x/drm/dc.c | 16 +-
>> include/drm/drm_atomic_helper.h | 37 ++-
>> include/drm/drm_crtc.h | 88 +-
>> 18 files changed, 615 insertions(+), 190 deletions(-)
>>
>> diff --git a/drivers/gpu/drm/drm_atomic_helper.c
>> b/drivers/gpu/drm/drm_atomic_helper.c
>> index 46c67b8..0618113 100644
>> --- a/drivers/gpu/drm/drm_atomic_helper.c
>> +++ b/drivers/gpu/drm/drm_atomic_helper.c
>> @@ -39,10 +39,12 @@
>> void *drm_atomic_helper_begin(struct drm_device *dev, uint32_t flags)
>> {
>> struct drm_atomic_helper_state *state;
>> + int nplanes = dev->mode_config.num_plane;
>> int sz;
>> void *ptr;
>>
>> sz = sizeof(*state);
>> + sz += (sizeof(state->planes) + sizeof(state->pstates)) * nplanes;
>>
>> ptr = kzalloc(sz, GFP_KERNEL);
>>
>> @@ -52,6 +54,13 @@ void *drm_atomic_helper_begin(struct drm_device *dev,
>> uint32_t flags)
>> kref_init(&state->refcount);
>> state->dev = dev;
>> state->flags = flags;
>> +
>> + state->planes = ptr;
>> + ptr = &state->planes[nplanes];
>> +
>> + state->pstates = ptr;
>> + ptr = &state->pstates[nplanes];
>> +
>> return state;
>> }
>> EXPORT_SYMBOL(drm_atomic_helper_begin);
>> @@ -87,7 +96,19 @@ EXPORT_SYMBOL(drm_atomic_helper_set_event);
>> */
>> int drm_atomic_helper_check(struct drm_device *dev, void *state)
>> {
>> - return 0; /* for now */
>> + struct drm_atomic_helper_state *a = state;
>> + int nplanes = dev->mode_config.num_plane;
>> + int i, ret = 0;
>> +
>> + for (i = 0; i < nplanes; i++) {
>> + if (a->planes[i]) {
>> + ret = drm_atomic_check_plane_state(a->planes[i],
>> a->pstates[i]);
>> + if (ret)
>> + break;
>> + }
>> + }
>> +
>> + return ret;
>> }
>> EXPORT_SYMBOL(drm_atomic_helper_check);
>>
>> @@ -104,7 +125,19 @@ EXPORT_SYMBOL(drm_atomic_helper_check);
>> */
>> int drm_atomic_helper_commit(struct drm_device *dev, void *state)
>> {
>> - return 0; /* for now */
>> + struct drm_atomic_helper_state *a = state;
>> + int nplanes = dev->mode_config.num_plane;
>> + int i, ret = 0;
>> +
>> + for (i = 0; i < nplanes; i++) {
>> + if (a->planes[i]) {
>> + ret = drm_atomic_commit_plane_state(a->planes[i],
>> a->pstates[i]);
>> + if (ret)
>> + break;
>> + }
>> + }
>> +
>> + return ret;
>> }
>> EXPORT_SYMBOL(drm_atomic_helper_commit);
>>
>> @@ -125,11 +158,111 @@ void _drm_atomic_helper_state_free(struct kref *kref)
>> {
>> struct drm_atomic_helper_state *state =
>> container_of(kref, struct drm_atomic_helper_state, refcount);
>> + struct drm_device *dev = state->dev;
>> + int nplanes = dev->mode_config.num_plane;
>> + int i;
>> +
>> + for (i = 0; i < nplanes; i++) {
>> + if (state->pstates[i]) {
>> + state->planes[i]->state->state = NULL;
>> + kfree(state->pstates[i]);
>> + }
>> + }
>> +
>> kfree(state);
>> }
>> EXPORT_SYMBOL(_drm_atomic_helper_state_free);
>>
>> +int drm_atomic_helper_plane_set_property(struct drm_plane *plane, void
>> *state,
>> + struct drm_proper
[PATCH] drm/omap: fix (un)registering irqs inside an irq handler
omapdrm (un)registers irqs inside an irq handler. The problem is that
the (un)register function uses dispc_runtime_get/put() to enable the
clocks, and those functions are not irq safe by default.
This was kind of fixed in 48664b21aeeffb40c5fa06843f18052e2c4ec9ef
(OMAPDSS: DISPC: set irq_safe for runtime PM), which makes dispc's
runtime calls irq-safe.
However, using pm_runtime_irq_safe in dispc makes the parent of dispc,
dss, always enabled, effectively preventing PM for the whole DSS module.
This patch makes omapdrm behave better by adding new irq (un)register
functions that do not use dispc_runtime_get/put, and using those
functions in interrupt context. Thus we can make dispc again
non-irq-safe, allowing proper PM.
Signed-off-by: Tomi Valkeinen
Cc: Rob Clark
---
drivers/gpu/drm/omapdrm/omap_crtc.c | 6 +++---
drivers/gpu/drm/omapdrm/omap_drv.h | 2 ++
drivers/gpu/drm/omapdrm/omap_irq.c | 22 ++
drivers/video/omap2/dss/dispc.c | 1 -
4 files changed, 23 insertions(+), 8 deletions(-)
diff --git a/drivers/gpu/drm/omapdrm/omap_crtc.c
b/drivers/gpu/drm/omapdrm/omap_crtc.c
index 0fd2eb1..e6241c2 100644
--- a/drivers/gpu/drm/omapdrm/omap_crtc.c
+++ b/drivers/gpu/drm/omapdrm/omap_crtc.c
@@ -411,7 +411,7 @@ static void omap_crtc_error_irq(struct omap_drm_irq *irq,
uint32_t irqstatus)
struct drm_crtc *crtc = &omap_crtc->base;
DRM_ERROR("%s: errors: %08x\n", omap_crtc->name, irqstatus);
/* avoid getting in a flood, unregister the irq until next vblank */
- omap_irq_unregister(crtc->dev, &omap_crtc->error_irq);
+ __omap_irq_unregister(crtc->dev, &omap_crtc->error_irq);
}
static void omap_crtc_apply_irq(struct omap_drm_irq *irq, uint32_t irqstatus)
@@ -421,13 +421,13 @@ static void omap_crtc_apply_irq(struct omap_drm_irq *irq,
uint32_t irqstatus)
struct drm_crtc *crtc = &omap_crtc->base;
if (!omap_crtc->error_irq.registered)
- omap_irq_register(crtc->dev, &omap_crtc->error_irq);
+ __omap_irq_register(crtc->dev, &omap_crtc->error_irq);
if (!dispc_mgr_go_busy(omap_crtc->channel)) {
struct omap_drm_private *priv =
crtc->dev->dev_private;
DBG("%s: apply done", omap_crtc->name);
- omap_irq_unregister(crtc->dev, &omap_crtc->apply_irq);
+ __omap_irq_unregister(crtc->dev, &omap_crtc->apply_irq);
queue_work(priv->wq, &omap_crtc->apply_work);
}
}
diff --git a/drivers/gpu/drm/omapdrm/omap_drv.h
b/drivers/gpu/drm/omapdrm/omap_drv.h
index 30b95b7..cfb6c2e 100644
--- a/drivers/gpu/drm/omapdrm/omap_drv.h
+++ b/drivers/gpu/drm/omapdrm/omap_drv.h
@@ -145,6 +145,8 @@ irqreturn_t omap_irq_handler(DRM_IRQ_ARGS);
void omap_irq_preinstall(struct drm_device *dev);
int omap_irq_postinstall(struct drm_device *dev);
void omap_irq_uninstall(struct drm_device *dev);
+void __omap_irq_register(struct drm_device *dev, struct omap_drm_irq *irq);
+void __omap_irq_unregister(struct drm_device *dev, struct omap_drm_irq *irq);
void omap_irq_register(struct drm_device *dev, struct omap_drm_irq *irq);
void omap_irq_unregister(struct drm_device *dev, struct omap_drm_irq *irq);
int omap_drm_irq_uninstall(struct drm_device *dev);
diff --git a/drivers/gpu/drm/omapdrm/omap_irq.c
b/drivers/gpu/drm/omapdrm/omap_irq.c
index 9263db1..b08b902 100644
--- a/drivers/gpu/drm/omapdrm/omap_irq.c
+++ b/drivers/gpu/drm/omapdrm/omap_irq.c
@@ -45,12 +45,11 @@ static void omap_irq_update(struct drm_device *dev)
dispc_read_irqenable();/* flush posted write */
}
-void omap_irq_register(struct drm_device *dev, struct omap_drm_irq *irq)
+void __omap_irq_register(struct drm_device *dev, struct omap_drm_irq *irq)
{
struct omap_drm_private *priv = dev->dev_private;
unsigned long flags;
- dispc_runtime_get();
spin_lock_irqsave(&list_lock, flags);
if (!WARN_ON(irq->registered)) {
@@ -60,14 +59,21 @@ void omap_irq_register(struct drm_device *dev, struct
omap_drm_irq *irq)
}
spin_unlock_irqrestore(&list_lock, flags);
+}
+
+void omap_irq_register(struct drm_device *dev, struct omap_drm_irq *irq)
+{
+ dispc_runtime_get();
+
+ __omap_irq_register(dev, irq);
+
dispc_runtime_put();
}
-void omap_irq_unregister(struct drm_device *dev, struct omap_drm_irq *irq)
+void __omap_irq_unregister(struct drm_device *dev, struct omap_drm_irq *irq)
{
unsigned long flags;
- dispc_runtime_get();
spin_lock_irqsave(&list_lock, flags);
if (!WARN_ON(!irq->registered)) {
@@ -77,6 +83,14 @@ void omap_irq_unregister(struct drm_device *dev, struct
omap_drm_irq *irq)
}
spin_unlock_irqrestore(&list_lock, flags);
+}
+
+void omap_irq_unregister(struct drm_device *dev, struct omap_drm_irq *irq)
+{
+ dispc_runtime_get();
+
+ __omap_irq_unregister(dev, irq);
+
dispc_runtime_put();
}
diff --git a/dr
[PATCH] [trivial]treewide: Fix typo incomment in /gpu/drm/exynos
Correct spelling typo in drivers/gpu/drm/exynos
Signed-off-by: Masanari Iida
# Please enter the commit message for your changes. Lines starting
# with '#' will be kept; you may remove them yourself if you want to.
# An empty message aborts the commit.
# On branch exynos_typo
# Changes to be committed:
# modified: exynos_drm_crtc.c
# modified: exynos_drm_g2d.c
# modified: exynos_drm_gem.c
# modified: exynos_drm_gem.h
# modified: exynos_drm_ipp.c
# modified: exynos_drm_ipp.h
#
---
drivers/gpu/drm/exynos/exynos_drm_crtc.c | 4 ++--
drivers/gpu/drm/exynos/exynos_drm_g2d.c | 2 +-
drivers/gpu/drm/exynos/exynos_drm_gem.c | 2 +-
drivers/gpu/drm/exynos/exynos_drm_gem.h | 2 +-
drivers/gpu/drm/exynos/exynos_drm_ipp.c | 2 +-
drivers/gpu/drm/exynos/exynos_drm_ipp.h | 4 ++--
6 files changed, 8 insertions(+), 8 deletions(-)
diff --git a/drivers/gpu/drm/exynos/exynos_drm_crtc.c
b/drivers/gpu/drm/exynos/exynos_drm_crtc.c
index ebc0150..6f3400f 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_crtc.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_crtc.c
@@ -36,9 +36,9 @@ enum exynos_crtc_mode {
* @pipe: a crtc index created at load() with a new crtc object creation
* and the crtc object would be set to private->crtc array
* to get a crtc object corresponding to this pipe from private->crtc
- * array when irq interrupt occured. the reason of using this pipe is that
+ * array when irq interrupt occurred. the reason of using this pipe is that
* drm framework doesn't support multiple irq yet.
- * we can refer to the crtc to current hardware interrupt occured through
+ * we can refer to the crtc to current hardware interrupt occurred through
* this pipe value.
* @dpms: store the crtc dpms value
* @mode: store the crtc mode value
diff --git a/drivers/gpu/drm/exynos/exynos_drm_g2d.c
b/drivers/gpu/drm/exynos/exynos_drm_g2d.c
index 3271fd4..c97709c 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_g2d.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_g2d.c
@@ -1124,7 +1124,7 @@ int exynos_g2d_set_cmdlist_ioctl(struct drm_device
*drm_dev, void *data,
* G2D interrupt event once current command list execution is
* finished.
* Otherwise only ACF bit should be set to INTEN register so
-* that one interrupt is occured after all command lists
+* that one interrupt is occurred after all command lists
* have been completed.
*/
if (node->event) {
diff --git a/drivers/gpu/drm/exynos/exynos_drm_gem.c
b/drivers/gpu/drm/exynos/exynos_drm_gem.c
index 1ade191..be59d50 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_gem.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_gem.c
@@ -652,7 +652,7 @@ int exynos_drm_gem_dumb_create(struct drm_file *file_priv,
int ret;
/*
-* alocate memory to be used for framebuffer.
+* allocate memory to be used for framebuffer.
* - this callback would be called by user application
* with DRM_IOCTL_MODE_CREATE_DUMB command.
*/
diff --git a/drivers/gpu/drm/exynos/exynos_drm_gem.h
b/drivers/gpu/drm/exynos/exynos_drm_gem.h
index 702ec3a..b8c818b 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_gem.h
+++ b/drivers/gpu/drm/exynos/exynos_drm_gem.h
@@ -60,7 +60,7 @@ struct exynos_drm_gem_buf {
* @vma: a pointer to vm_area.
* @flags: indicate memory type to allocated buffer and cache attruibute.
*
- * P.S. this object would be transfered to user as kms_bo.handle so
+ * P.S. this object would be transferred to user as kms_bo.handle so
* user can access the buffer through kms_bo.handle.
*/
struct exynos_drm_gem_obj {
diff --git a/drivers/gpu/drm/exynos/exynos_drm_ipp.c
b/drivers/gpu/drm/exynos/exynos_drm_ipp.c
index 824e070..d519a4e 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_ipp.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_ipp.c
@@ -335,7 +335,7 @@ int exynos_drm_ipp_get_property(struct drm_device *drm_dev,
void *data,
} else {
/*
* Getting ippdrv capability by ipp_id.
-* some deivce not supported wb, output interface.
+* some device not supported wb, output interface.
* so, user application detect correct ipp driver
* using this ioctl.
*/
diff --git a/drivers/gpu/drm/exynos/exynos_drm_ipp.h
b/drivers/gpu/drm/exynos/exynos_drm_ipp.h
index 4cadbea..ab1634b 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_ipp.h
+++ b/drivers/gpu/drm/exynos/exynos_drm_ipp.h
@@ -48,7 +48,7 @@ struct drm_exynos_ipp_cmd_work {
/*
* A structure of command node.
*
- * @priv: IPP private infomation.
+ * @priv: IPP private information.
* @list: list head to command queue information.
* @event_list: list head of event.
* @mem_list: list head to source,destination memory queue information.
@@ -92,7 +92,7 @@ struct drm_exynos_ipp_buf_info {
};
/*
- * A structure of wb setting infomation.
+ * A stru
[PATCH v5 0/4] Fix Win8 backlight issue
On 10/16/2013 07:33 AM, Rafael J. Wysocki wrote:
> On Friday, October 11, 2013 09:27:42 PM Aaron Lu wrote:
>> v5:
>> 1 Introduce video.use_native_backlight module parameter and set its
>> value to false by default as suggested by Rafael. For Win8 systems
>> which have broken ACPI video backlight control, the parameter can be
>> set to 1 in kernel cmdline to skip registering ACPI video's backlight
>> interface. Due to this change, the acpi_video_verify_backlight_support
>> is moved from video_detect.c to video.c - patch 3/4;
>> 2 Rename bd_list_head and bd_list_mutex in backlight.c to
>> backlight_dev_list and backlight_dev_list_mutex as suggested by Rafael
>> - patch 1/4.
>>
>> v4:
>> Remove decleration and stub for acpi_video_unregister_backlight in
>> video.h of patch 2/4 since that function doesn't exist anymore in v3.
>>
>> v3:
>> 1 Add a new patch 4/4 to fix some problems in thinkpad-acpi module;
>> 2 Remove unnecessary function acpi_video_unregister_backlight introduced
>> in patch 2/4 as pointed out by Jani Nikula.
>>
>> v2:
>> v1 has the subject of "Rework ACPI video driver" and is posted here:
>> http://lkml.org/lkml/2013/9/9/74
>> Since the objective is really to fix Win8 backlight issues, I changed
>> the subject in this version, sorry about that.
>>
>> This patchset has four patches, the first introduced a new API named
>> backlight_device_registered in backlight layer that can be used for
>> backlight interface provider module to check if a specific type backlight
>> interface has been registered, see changelog for patch 1/4 for details.
>> Then patch 2/4 does the cleanup to sepeate the backlight control and
>> event delivery functionality in the ACPI video module and patch 3/4
>> solves some Win8 backlight control problems by avoiding register ACPI
>> video's backlight interface if:
>> 1 Kernel cmdline option acpi_backlight=video is not given;
>> 2 This is a Win8 system;
>> 3 Native backlight control interface exists.
>> Patch 4/4 fixes some problems in thinkpad-acpi module.
>>
>> Technically, patch 2/4 is not required to fix the issue here. So if you
>> think it is not necessary, I can remove it from the series.
>>
>> Aaron Lu (4):
>> backlight: introduce backlight_device_registered
>> ACPI / video: seperate backlight control and event interface
>> ACPI / video: Do not register backlight if win8 and native interface
>> exists
>> thinkpad-acpi: fix handle locate for video and query of _BCL
>>
>> drivers/acpi/internal.h | 4 +-
>> drivers/acpi/video.c | 457
>> ---
>> drivers/acpi/video_detect.c | 4 +-
>> drivers/platform/x86/thinkpad_acpi.c | 31 ++-
>> drivers/video/backlight/backlight.c | 31 +++
>> include/linux/backlight.h| 4 +
>> 6 files changed, 326 insertions(+), 205 deletions(-)
>
> I've added this series to my queue for 3.13.
>
> Since the next step will be to introduce a list of systems that need
> video.use_native_backlight=1 *and* don't break in that configuration, I don't
> see much point adding another Kconfig option for the default.
>
> Hopefully, in the future we'll be able to fix the problems causing
> video.use_native_backlight=1 to fail of the systems where it fails and then
> we'll be able to make that the default behavior and drop the option
> altogether.
I've prepared a patch(at the end of the mail) to set use_native_backlight
by default for some systems. There are 3 systems currently that I'm
kind of sure that should be added:
The ThinkPad T430s and X230 is:
Reported-by: Theodore Tso
Reported-and-tested-by: Peter Weber
Reported-by: Igor Gnatenko
Reference: https://bugzilla.kernel.org/show_bug.cgi?id=51231
The Lenovo Yoga is:
Reported-by: Lennart Poettering
Reference: https://lkml.org/lkml/2013/10/13/178
From: Aaron Lu
Subject: [PATCH] ACPI / video: Add systems that should favor native backlight
interface
Some system's ACPI video backlight control interface is broken and the
native backlight control interface should be used by default. This patch
sets the use_native_backlight parameter to true for those systems so
that video backlight control interface will not be created. To be
clear, the ThinkPad T430s/X230 and Lenovo Yoga 13 are added here.
Reported-by: Theodore Tso
Reported-and-tested-by: Peter Weber
Reported-by: Lennart Poettering
Reported-by: Igor Gnatenko
Signed-off-by: Aaron Lu
---
drivers/acpi/video.c | 30 ++
1 file changed, 30 insertions(+)
diff --git a/drivers/acpi/video.c b/drivers/acpi/video.c
index d020df5..9a80a94 100644
--- a/drivers/acpi/video.c
+++ b/drivers/acpi/video.c
@@ -412,6 +412,12 @@ static int video_ignore_initial_backlight(const struct
dmi_system_id *d)
return 0;
}
+static int __init video_set_use_native_backlight(const struct dmi_system_id *d)
+{
+ use_native_backlight = true;
+ return 0;
+}
+
static struct dmi_system_id video_dmi_table[] __initda
[RFR 2/2] drm/panel: Add simple panel support
On 24/10/13 13:40, Laurent Pinchart wrote:
>> panel {
>> remote = <&remote-endpoint>;
>> common-video-property = ;
>> };
>>
>> panel {
>> port {
>> endpoint {
>> remote = <&remote-endpoint>;
>> common-video-property = ;
>> };
>> };
>> };
>
> Please note that the common video properties would be in the panel node, not
> in the endpoint node (unless you have specific requirements to do so, which
> isn't the common case).
Hmm, well, the panel driver must look for its properties either in the
panel node, or in the endpoint node (I guess it could look them from
both, but that doesn't sound good).
If you write the panel driver, and in all your cases the properties work
fine in the panel node, does that mean they'll work fine with everybody?
I guess there are different kinds of properties. Something like a
regulator is obviously property of the panel. But anything related to
the video itself, like DPI's bus width, or perhaps even something like
"orientation" if the panel supports such, could need to be in the
endpoint node.
But yes, I understand what you mean. With "common-video-property" I
meant common properties like DPI bus width.
>> If that can be supported in the SW by adding complexity to a few functions,
>> and it covers practically all the panels, isn't it worth it?
>>
>> Note that I have not tried this, so I don't know if there are issues.
>> It's just a thought. Even if there's need for a endpoint node, perhaps
>> the port node can be made optional.
>
> It can be worth it, as long as we make sure that simplified bindings cover
> the
> needs of the generic code.
>
> We could assume that, if the port subnode isn't present, the device will have
> a single port, with a single endpoint. However, isn't the number of endpoints
Right.
> a system property rather than a device property ? If a port of a device is
Yes.
> connected to two remote ports it will require two endpoints. We could select
> the simplified or full bindings based on the system topology though.
The drivers should not know about simplified/normal bindings. They
should use CDF DT helper functions to get the port and endpoint
information. The helper functions would do the assuming.
Tomi
------ next part --
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 901 bytes
Desc: OpenPGP digital signature
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20131024/e003f000/attachment-0001.pgp>
3.12-rc6 nouveau oops
Hi, Booting 3.12-rc6 on my macbook quickly freezes after logging in to X. I was able to capture this oops. It's 100% consistent. 3.11 works perfectly fine, as did previous kernels. -- Jens Axboe -- next part -- A non-text attachment was scrubbed... Name: nouveau-oops.jpg Type: image/jpeg Size: 1083671 bytes Desc: not available URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20131024/78073692/attachment-0001.jpg>
[RFC 05/12] phy: use of_phy_simple_xlate for NULL xlate function
Hi, On Monday 21 October 2013 07:48 PM, Tomasz Stanislawski wrote: > Use default handler of_phy_simple_xlate() when NULL is passed as argument to > of_phy_provider_register(). > > Signed-off-by: Tomasz Stanislawski > --- > drivers/phy/phy-core.c |2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/drivers/phy/phy-core.c b/drivers/phy/phy-core.c > index 03cf8fb..c38ae1e7 100644 > --- a/drivers/phy/phy-core.c > +++ b/drivers/phy/phy-core.c > @@ -575,7 +575,7 @@ struct phy_provider *__of_phy_provider_register(struct > device *dev, > > phy_provider->dev = dev; > phy_provider->owner = owner; > - phy_provider->of_xlate = of_xlate; > + phy_provider->of_xlate = of_xlate ? of_xlate : of_phy_simple_xlate; Lets allow the phy provider to pass the correct of_xlate (of_phy_simple_xlate is exported anyway). Instead you can modify the patch to check for of_xlate and do a WARN if it is NULL. Thanks Kishon
[RFC 04/12] phy: Add simple-phy driver
Hi,
On Monday 21 October 2013 07:48 PM, Tomasz Stanislawski wrote:
> Add simple-phy driver to support a single register
> PHY interfaces present on Exynos4 SoC.
How are these PHY interfaces modelled in the SoC? Where does the register
actually reside?
>
> Signed-off-by: Tomasz Stanislawski
> ---
> drivers/phy/Kconfig |5 ++
> drivers/phy/Makefile |1 +
> drivers/phy/phy-simple.c | 128
> ++
> 3 files changed, 134 insertions(+)
> create mode 100644 drivers/phy/phy-simple.c
>
> diff --git a/drivers/phy/Kconfig b/drivers/phy/Kconfig
> index ac239ac..619c657 100644
> --- a/drivers/phy/Kconfig
> +++ b/drivers/phy/Kconfig
> @@ -38,4 +38,9 @@ config TWL4030_USB
> This transceiver supports high and full speed devices plus,
> in host mode, low speed.
>
> +config PHY_SIMPLE
> + tristate "Simple PHY driver"
This is too generic a name to be used. Lets name it something specific to what
it is used for (EXYNOS/HDMI.. ?).
> + help
> + Support for PHY controllers configured using single register.
> +
> endmenu
> diff --git a/drivers/phy/Makefile b/drivers/phy/Makefile
> index 0dd8a98..3d68e19 100644
> --- a/drivers/phy/Makefile
> +++ b/drivers/phy/Makefile
> @@ -5,3 +5,4 @@
> obj-$(CONFIG_GENERIC_PHY)+= phy-core.o
> obj-$(CONFIG_OMAP_USB2) += phy-omap-usb2.o
> obj-$(CONFIG_TWL4030_USB)+= phy-twl4030-usb.o
> +obj-$(CONFIG_PHY_SIMPLE) += phy-simple.o
> diff --git a/drivers/phy/phy-simple.c b/drivers/phy/phy-simple.c
> new file mode 100644
> index 000..4a28af7
> --- /dev/null
> +++ b/drivers/phy/phy-simple.c
> @@ -0,0 +1,128 @@
> +/*
> + * Simple PHY driver
> + *
> + * Copyright (C) 2013 Samsung Electronics Co., Ltd.
> + * Author: Tomasz Stanislawski
> + *
> + * This program is free software; you can redistribute it and/or modify
> + * it under the terms of the GNU General Public License version 2 as
> + * published by the Free Software Foundation.
> + */
> +
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +
> +struct simple_phy {
> + spinlock_t slock;
> + u32 on_value;
> + u32 off_value;
> + u32 mask;
> + void __iomem *regs;
> +};
> +
> +static int sphy_set(struct simple_phy *sphy, bool on)
> +{
> + u32 reg;
> +
> + spin_lock(&sphy->slock);
Lets add spin_lock only when it is absolutely necessary. When your PHY provider
implements only a single PHY, it is not needed. phy_power_on and phy_power_off
is already protected by the framework.
> +
> + reg = readl(sphy->regs);
> + reg &= ~sphy->mask;
> + reg |= sphy->mask & (on ? sphy->on_value : sphy->off_value);
> + writel(reg, sphy->regs);
> +
> + spin_unlock(&sphy->slock);
> +
> + return 0;
> +}
> +
> +static int simple_phy_power_on(struct phy *phy)
> +{
> + return sphy_set(phy_get_drvdata(phy), 1);
> +}
> +
> +static int simple_phy_power_off(struct phy *phy)
> +{
> + return sphy_set(phy_get_drvdata(phy), 0);
> +}
> +
> +static struct phy_ops simple_phy_ops = {
> + .power_on = simple_phy_power_on,
> + .power_off = simple_phy_power_off,
> + .owner = THIS_MODULE,
> +};
> +
> +static int simple_phy_probe(struct platform_device *pdev)
> +{
> + struct device *dev = &pdev->dev;
> + struct simple_phy *sphy;
> + struct resource *res;
> + struct phy_provider *phy_provider;
> + struct phy *phy;
> +
> + sphy = devm_kzalloc(dev, sizeof(*sphy), GFP_KERNEL);
> + if (!sphy)
> + return -ENOMEM;
> +
> + res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
> +
> + sphy->regs = devm_ioremap_resource(dev, res);
> + if (IS_ERR(sphy->regs)) {
> + dev_err(dev, "failed to ioremap registers\n");
> + return PTR_ERR(sphy->regs);
> + }
> +
> + spin_lock_init(&sphy->slock);
> +
> + phy_provider = devm_of_phy_provider_register(dev, NULL);
pass 'of_phy_simple_xlate' instead of NULL.
> + if (IS_ERR(phy_provider)) {
> + dev_err(dev, "failed to register PHY provider\n");
> + return PTR_ERR(phy_provider);
> + }
> +
> + phy = devm_phy_create(dev, &simple_phy_ops, NULL);
> + if (IS_ERR(phy)) {
> + dev_err(dev, "failed to create PHY\n");
> + return PTR_ERR(phy);
> + }
> +
> + sphy->mask = 1;
> + sphy->on_value = ~0;
> + sphy->off_value = 0;
> +
> + of_property_read_u32(dev->of_node, "mask", &sphy->mask);
This means your driver will depend on dt data to describe how the register
should look like. Not a good idea.
> + of_property_read_u32(dev->of_node, "on-value", &sphy->on_value);
> + of_property_read_u32(dev->of_node, "off-value", &sphy->off_value);
> +
> + phy_set_drvdata(phy, sphy);
> +
> + dev_info(dev, "probe successful\n");
Lets not make the boot noisy.
Thanks
Kishon
