CDF meeting @FOSDEM report
Hello,
We've hosted a CDF meeting at the FOSDEM on Sunday morning. Here's a summary
of the discussions.
I would like to start with a big thank to UrLab, the ULB university hacker
space, for providing us with a meeting room.
The meeting would of course not have been successful without the wide range of
participants, so I also want to thank all the people who woke up on Sunday
morning to attend the meeting :-)
(The CC list is pretty long, please let me know - by private e-mail in order
not to spam the list - if you would like not to receive future CDF-related e-
mails directly)
0. Abbreviations
DBI - Display Bus Interface, a parallel video control and data bus that
transmits data using parallel data, read/write, chip select and address
signals, similarly to 8051-style microcontroller parallel busses. This is a
mixed video control and data bus.
DPI - Display Pixel Interface, a parallel video data bus that transmits data
using parallel data, h/v sync and clock signals. This is a video data bus
only.
DSI - Display Serial Interface, a serial video control and data bus that
transmits data using one or more differential serial lines. This is a mixed
video control and data bus.
DT - Device Tree, a representation of a hardware system as a tree of physical
devices with associated properties.
SFI - Simple Firmware Interface, a lightweight method for firmware to export
static tables to the operating system. Those tables can contain display device
topology information.
VBT - Video BIOS Table, a block of data residing in the video BIOS that can
contain display device topology information.
1. Goals
The meeting started with a brief discussion about the CDF goals.
Tomi Valkeinin and Tomasz Figa have sent RFC patches to show their views of
what CDF could/should be. Many others have provided very valuable feedback.
Given the early development stage propositions were sometimes contradictory,
and focused on different areas of interest. We have thus started the meeting
with a discussion about what CDF should try to achieve, and what it shouldn't.
CDF has two main purposes. The original goal was to support display panels in
a platform- and subsystem-independent way. While mostly useful for embedded
systems, the emergence of platforms such as Intel Medfield and ARM-based PCs
that blends the embedded and PC worlds makes panel support useful for the PC
world as well.
The second purpose is to provide a cross-subsystem interface to support video
encoders. The idea originally came from a generalisation of the original RFC
that supported panels only. While encoder support is considered as lower
priority than display panel support by developers focussed on display
controller driver (Intel, Renesas, ST Ericsson, TI), companies that produce
video encoders (Analog Devices, and likely others) don't share that point of
view and would like to provide a single encoder driver that can be used in
both KMS and V4L2 drivers.
Both display panels and encoders are thus the target of a lot of attention,
depending on the audience. As long as none of them is forgotten in CDF, the
overall agreement was that focussing on panels first is acceptable. Care shall
be taken in that case to avoid any architecture that would make encoders
support difficult or impossible.
2. Subsystems
-
Display panels are used in conjunction with FBDEV and KMS drivers. There was
to the audience knowledge no V4L2 driver that needs to explicitly handle
display panels. Even though at least one V4L2 output drivers (omap_vout) can
output video to a display panel, it does so in conjunction with the KMS and/or
FBDEV APIs that handle panel configuration. Panels are thus not exposed to
V4L2 drivers.
Encoders, on the other hand, are widely used in the V4L2 subsystem. Many V4L2
devices output video in either analog (Composite, S-Video, VGA) or digital
(DVI, HDMI) way.
Display panel drivers don't need to be shared with the V4L2 subsystem.
Furthermore, as the general opinion during the meeting was that the FBDEV
subsystem should be considered as legacy and deprecate in the future,
restricting panel support to KMS hasn't been considered by anyone as an issue.
KMS will thus be the main target of display panel support in CDF, and FBDEV
will be supported if that doesn't bring any drawback from an architecture
point of view.
Encoder drivers need to be shared with the V4L2 subsystem. Similarly to panel
drivers, excluding FBDEV support from CDF isn't considered as an issue.
3. KMS Extensions
-
The usefulness of V4L2 for output devices was questioned, and the possibility
of using KMS for complex video devices usually associated with V4L2 was
raised. The TI DaVinci 8xxx family is an example of chips that could benefit
from KMS support.
The KMS API is lacking support for deep-pipelining ("framebuffers" that are
sourced from a data stream instead of a memory buffer) today.
[PATCH] drm/fb-helper: improve kerneldoc
Now that the fbdev helper interface for drivers is trimmed down,
update the kerneldoc for all the remaining exported functions.
I've tried to beat the DocBook a bit by reordering the function
references a bit into a more sensible ordering. But that didn't work
out at all. Hence just extend the in-code DOC: section a bit.
Also remove the LOCKING: sections - especially for the setup functions
they're totally bogus. But that's not a documentation problem, but
simply an artifact of the current rather hazardous locking around drm
init and even more so around fbdev setup ...
v2: Some further improvements:
- Also add documentation for drm_fb_helper_single_add_all_connectors,
Dave Airlie didn't want me to kill this one from the fb helper
interface.
- Update docs for drm_fb_helper_fill_var/fix - they should be used
from the driver's ->fb_probe callback to setup the fbdev info
structure.
- Clarify what the ->fb_probe callback should all do - it needs to
setup both the fbdev info and allocate the drm framebuffer used as
backing storage.
- Add basic documentaation for the drm_fb_helper_funcs driver callback
vfunc.
v3: Implement clarifications Lauren Pinchart suggested in his review.
Cc: Laurent Pinchart
Signed-off-by: Daniel Vetter
---
Documentation/DocBook/drm.tmpl |1 +
drivers/gpu/drm/drm_fb_helper.c | 148 +++
include/drm/drm_fb_helper.h | 12
3 files changed, 146 insertions(+), 15 deletions(-)
diff --git a/Documentation/DocBook/drm.tmpl b/Documentation/DocBook/drm.tmpl
index 6c11d77..14ad829 100644
--- a/Documentation/DocBook/drm.tmpl
+++ b/Documentation/DocBook/drm.tmpl
@@ -2139,6 +2139,7 @@ void intel_crt_init(struct drm_device *dev)
fbdev Helper Functions Reference
!Pdrivers/gpu/drm/drm_fb_helper.c fbdev helpers
!Edrivers/gpu/drm/drm_fb_helper.c
+!Iinclude/drm/drm_fb_helper.h
Display Port Helper Functions Reference
diff --git a/drivers/gpu/drm/drm_fb_helper.c b/drivers/gpu/drm/drm_fb_helper.c
index 5a92470..b4cbef3 100644
--- a/drivers/gpu/drm/drm_fb_helper.c
+++ b/drivers/gpu/drm/drm_fb_helper.c
@@ -52,9 +52,36 @@ static LIST_HEAD(kernel_fb_helper_list);
* mode setting driver. They can be used mostly independantely from the crtc
* helper functions used by many drivers to implement the kernel mode setting
* interfaces.
+ *
+ * Initialization is done as a three-step process with drm_fb_helper_init(),
+ * drm_fb_helper_single_add_all_connectors() and
drm_fb_helper_initial_config().
+ * Drivers with fancier requirements than the default beheviour can override
the
+ * second step with their own code. Teardown is done with
drm_fb_helper_fini().
+ *
+ * At runtime drivers should restore the fbdev console by calling
+ * drm_fb_helper_restore_fbdev_mode() from their ->lastclose callback. They
+ * should also notify the fb helper code from updates to the output
+ * configuration by calling drm_fb_helper_hotplug_event(). For easier
+ * integration with the output polling code in drm_crtc_helper.c the modeset
+ * code proves a ->output_poll_changed callback.
+ *
+ * All other functions exported by the fb helper library can be used to
+ * implement the fbdev driver interface by the driver.
*/
-/* simple single crtc case helper function */
+/**
+ * drm_fb_helper_single_add_all_connectors() - add all connectors to fbdev
+ *emulation helper
+ * @fb_helper: fbdev initialized with drm_fb_helper_init
+ *
+ * This functions adds all the available connectors for use with the given
+ * fb_helper. This is a separate step to allow drivers to freely assign
+ * connectors to the fbdev, e.g. if some are reserved for special purposes or
+ * not adequate to be used for the fbcon.
+ *
+ * Since this is part of the initial setup before the fbdev is published, no
+ * locking is required.
+ */
int drm_fb_helper_single_add_all_connectors(struct drm_fb_helper *fb_helper)
{
struct drm_device *dev = fb_helper->dev;
@@ -163,6 +190,10 @@ static void drm_fb_helper_restore_lut_atomic(struct
drm_crtc *crtc)
crtc->funcs->gamma_set(crtc, r_base, g_base, b_base, 0,
crtc->gamma_size);
}
+/**
+ * drm_fb_helper_debug_enter - implementation for ->fb_debug_enter
+ * @info: fbdev registered by the helper
+ */
int drm_fb_helper_debug_enter(struct fb_info *info)
{
struct drm_fb_helper *helper = info->par;
@@ -208,6 +239,10 @@ static struct drm_framebuffer *drm_mode_config_fb(struct
drm_crtc *crtc)
return NULL;
}
+/**
+ * drm_fb_helper_debug_leave - implementation for ->fb_debug_leave
+ * @info: fbdev registered by the helper
+ */
int drm_fb_helper_debug_leave(struct fb_info *info)
{
struct drm_fb_helper *helper = info->par;
@@ -243,9 +278,9 @@ EXPORT_SYMBOL(drm_fb_helper_debug_leave);
* drm_fb_helper_restore_fbdev_mode - restore fbdev configuration
* @fb_helper: fbcon to restore
*
- * This should be called from driver's drm->lastclose callback
[PATCH] drm/fb-helper: improve kerneldoc
On Fri, Feb 01, 2013 at 01:21:29PM +0100, Laurent Pinchart wrote: > Hi Daniel, > > Thanks for improving the documentation :-) > > On Sunday 27 January 2013 18:42:16 Daniel Vetter wrote: > > Now that the fbdev helper interface for drivers is trimmed down, > > update the kerneldoc for all the remaining exported functions. > > > > I've tried to beat the DocBook a bit by reordering the function > > references a bit into a more sensible ordering. But that didn't work > > out at all. Hence just extend the in-code DOC: section a bit. > > > > Also remove the LOCKING: sections - especially for the setup functions > > they're totally bogus. But that's not a documentation problem, but > > simply an artifact of the current rather hazardous locking around drm > > init and even more so around fbdev setup ... > > Please see below for comments (I've reflowed the text to ease review). > > > v2: Some further improvements: > > - Also add documentation for drm_fb_helper_single_add_all_connectors, > > Dave Airlie didn't want me to kill this one from the fb helper > > interface. > > - Update docs for drm_fb_helper_fill_var/fix - they should be used > > from the driver's ->fb_probe callback to setup the fbdev info > > structure. > > - Clarify what the ->fb_probe callback should all do - it needs to > > setup both the fbdev info and allocate the drm framebuffer used as > > backing storage. > > - Add basic documentaation for the drm_fb_helper_funcs driver callback > > vfunc. > > > > Signed-off-by: Daniel Vetter > > > > moar kerneldoc > > --- > > Documentation/DocBook/drm.tmpl |1 + > > drivers/gpu/drm/drm_fb_helper.c | 146 > > include/drm/drm_fb_helper.h | 11 +++ > > 3 files changed, 143 insertions(+), 15 deletions(-) > > > > diff --git a/Documentation/DocBook/drm.tmpl b/Documentation/DocBook/drm.tmpl > > index 6c11d77..14ad829 100644 > > --- a/Documentation/DocBook/drm.tmpl > > +++ b/Documentation/DocBook/drm.tmpl > > @@ -2139,6 +2139,7 @@ void intel_crt_init(struct drm_device *dev) > >fbdev Helper Functions Reference > > !Pdrivers/gpu/drm/drm_fb_helper.c fbdev helpers > > !Edrivers/gpu/drm/drm_fb_helper.c > > +!Iinclude/drm/drm_fb_helper.h > > > > > >Display Port Helper Functions Reference > > diff --git a/drivers/gpu/drm/drm_fb_helper.c > > b/drivers/gpu/drm/drm_fb_helper.c index 5a92470..a7538cc 100644 > > --- a/drivers/gpu/drm/drm_fb_helper.c > > +++ b/drivers/gpu/drm/drm_fb_helper.c > > @@ -52,9 +52,34 @@ static LIST_HEAD(kernel_fb_helper_list); > > * mode setting driver. They can be used mostly independantely from the > > Now that you have removed one of the dependencies on the crtc helpers in your > "drm/fb-helper: don't disable everything in initial_config" patch, are there > others ? If not you can s/mostly //. It's getting better, but a few of the driver callbacks used by the fb helper are still in the crtc helper function tables. And there's the fb helper private way to safe/restore gamma tables. But at least semantically there's no dependency any longer after these patches I think. > > > * crtc helper functions used by many drivers to implement the kernel mode > > * setting interfaces. > > + * > > + * Initialization is done as a three-step process with > > + * drm_fb_helper_init(), drm_fb_helper_single_add_all_connectors() and > > + * drm_fb_helper_initial_config(). Drivers with fancier requirements than > > + * the default beheviour can override the second step with their own code. > > + * Teardown is done with drm_fb_helper_fini(). > > + * > > + * At runtime drivers should restore the fbdev console by calling > > + * drm_fb_helper_restore_fbdev_mode() from their ->lastclose callback. They > > + * can also notify the fb helper code from updates to the output > > Is it "can" or "must" ? If "can", in what conditions should they call > drm_fb_helper_restore_fbdev_mode() and in what conditions shouldn't they ? I've figured that hpd support is optional, hence no "must". I've opted for a should instead. Also added a bit of text to suggest a good place to put this call. > > > + * configuration by calling drm_fb_helper_hotplug_event(). > > + * > > + * All other functions exported by the fb helper library can be used to > > + * implement the fbdev driver interface by the driver. > > */ > > > > -/* simple single crtc case helper function */ > > +/** > > + * drm_fb_helper_single_add_all_connectors() - add all connectors to fbdev > > + *emulation helper > > + * @fb_helper: fbdev initialized with drm_fb_helper_init > > + * > > + * This functions adds all the available connectors for use with the given > > + * fb_helper. This is a separate step to allow drivers to freely assign or > > + * connectors to the fbdev, e.g. if some are reserved for special purposes > > + * not adequate to be used for the fbcon. > > + * > > + * Since this is part of the initial
答复: [PATCH]Siliconmotion initial patch
On Tue, Feb 05, 2013 at 03:51:55PM +0800, Aaron.Chen ??? wrote: > This is an initial patch for Siliconmotion Graphics chips. It add SM750 > chip support with 2d accelerate and hw curser support. It is a complete > new driver. So the patch is a little bit big. Is it OK for review? Adding a new fbdev driver while established consensus pretty much boils down to fbdev being a dead subsystem which should only be used for legacy applications and drivers: Not good. You should implement this as a drm modesetting driver, and if required base your 2d acceleration on top of the drm fb helpers. Or just implement a drm/gem driver to expose this. Additionally you should include the appropriate mailing lists, which is linux-fbdev for fbdev drivers. On a very quick read the patch has serious issues: - checkpatch.pl: total: 2 errors, 779 warnings, 7961 lines checked NOTE: whitespace errors detected, you may wish to use scripts/cleanpatch or scripts/cleanfile - Remants of hungarian notation (dunno whether checkpatch checks for those, too much other stuff flying by, but it really stuck out). - Not using the linux i2c layer in the ddk750_hwi2c.c file. - Reimplementing i2c bit-banging code in the ddk750_swi2c.c - Adding a new implementation of a sil 164 dvi driver, we already have at least two in drivers/gpu/drm/i2c/sil164_drv.c and drivers/gpu/drm/i915/dvo_sil164.c. This should be unified and probably use the drm encoder slave framework. At that point I've given up on further review, since there's clearly a lot of work left to do. Please review SubmittingPatches from the kernel documentation carefully. Also cc'ing our dear staging maintainer, he should be able to point you at further useful resources for getting this going. Cheers, Daniel -- Daniel Vetter Software Engineer, Intel Corporation +41 (0) 79 365 57 48 - http://blog.ffwll.ch
[Bug 59332] Problems building 32bit Mesa
https://bugs.freedesktop.org/show_bug.cgi?id=59332 Matt Turner changed: What|Removed |Added Blocks|59304 | -- 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/20130205/256e6c3f/attachment-0001.html>
[Bug 59332] Problems building 32bit Mesa
https://bugs.freedesktop.org/show_bug.cgi?id=59332 Mike Lothian changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |INVALID --- Comment #11 from Mike Lothian --- Seems I had a rogue /usr/lib32/libstdc++.so causing problems with my 32bit builds Everything is working fine now with LLVM enabled -- 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/20130205/a7886ed0/attachment.html>
[Bug 26891] Radeon KMS fails with inaccessible AtomBIOS on systems with (U)EFI boot
https://bugs.freedesktop.org/show_bug.cgi?id=26891 --- Comment #53 from Benjamin Lee --- I can also confirm that Radeon KMS works on my MacBookPro8,2 with kernel version 3.8-rc6 and EFI stub boot. I also needed to add a device section to my xorg.conf. I don't see any video BIOS in /dev/mem so I guess it is loading from ACPI instead. Out of curiosity, I tried to load fglrx and it failed to find a valid VBIOS so fglrx must not have the ACPI loading method. blee at supra ~ $ sudo dd if=/dev/mem of=/dev/stdout bs=65536 skip=12 count=1 2>/dev/null | hexdump 000 * 001 [2.589927] [drm] Initialized drm 1.1.0 20060810 [2.589966] [drm] radeon defaulting to kernel modesetting. [2.589969] [drm] radeon kernel modesetting enabled. [2.590189] [drm] initializing kernel modesetting (TURKS 0x1002:0x6741 0x106B :0x00E2). [2.590226] [drm] register mmio base: 0xB080 [2.590229] [drm] register mmio size: 131072 [2.590253] ATOM BIOS: Apple [2.590264] [drm] GPU not posted. posting now... [2.599466] radeon :01:00.0: VRAM: 1024M 0x - 0x3 FFF (1024M used) [2.599472] radeon :01:00.0: GTT: 512M 0x4000 - 0x5FF F [2.604787] [drm] Detected VRAM RAM=1024M, BAR=256M [2.604793] [drm] RAM width 128bits DDR [2.604843] [TTM] Zone kernel: Available graphics memory: 4042710 kiB [2.604846] [TTM] Zone dma32: Available graphics memory: 2097152 kiB [2.604849] [TTM] Initializing pool allocator [2.604858] [TTM] Initializing DMA pool allocator [2.604893] [drm] radeon: 1024M of VRAM memory ready [2.604896] [drm] radeon: 512M of GTT memory ready. [2.604917] [drm] Supports vblank timestamp caching Rev 1 (10.10.2010). [2.604920] [drm] Driver supports precise vblank timestamp query. [2.604982] radeon :01:00.0: irq 45 for MSI/MSI-X [2.604993] radeon :01:00.0: radeon: using MSI. [2.605028] [drm] radeon: irq initialized. [2.605033] [drm] GART: num cpu pages 131072, num gpu pages 131072 [2.605463] [drm] probing gen 2 caps for device 8086:101 = 2/0 [2.605470] [drm] PCIE gen 2 link speeds already enabled [2.605534] [drm] Loading TURKS Microcode -- 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/20130205/65281a80/attachment.html>
[Bug 43751] [TTM] Out of kernel memory
https://bugzilla.kernel.org/show_bug.cgi?id=43751 --- Comment #9 from cyberbat 2013-02-05 20:11:50 --- Created an attachment (id=92571) --> (https://bugzilla.kernel.org/attachment.cgi?id=92571) Config of working linux-3.7.4 Tried a kernel 3.7.4 for some days and it seems to work with config attached. -- Configure bugmail: https://bugzilla.kernel.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are watching the assignee of the bug.
[PATCH v3 1/3] drm/exynos: Get HDMI version from device tree
On 02/05/2013 05:56 PM, Sean Paul wrote:
> On Tue, Feb 5, 2013 at 4:42 PM, Stephen Warren
> wrote:
>> On 02/05/2013 05:37 PM, Sean Paul wrote:
>>> On Tue, Feb 5, 2013 at 4:22 PM, Stephen Warren
>>> wrote:
n 02/05/2013 04:42 PM, Sean Paul wrote:
> Use the compatible string in the device tree to determine which
> registers/functions to use in the HDMI driver. Also changes the
> references from v13 to 4210 and v14 to 4212 to reflect the IP
> block version instead of the HDMI version.
> diff --git a/Documentation/devicetree/bindings/drm/exynos/hdmi.txt
> b/Documentation/devicetree/bindings/drm/exynos/hdmi.txt
Binding looks sane to me.
> diff --git a/drivers/gpu/drm/exynos/exynos_hdmi.c
> b/drivers/gpu/drm/exynos/exynos_hdmi.c
> #ifdef CONFIG_OF
> static struct of_device_id hdmi_match_types[] = {
> {
> - .compatible = "samsung,exynos5-hdmi",
> - .data = (void *)HDMI_TYPE14,
> + .compatible = "samsung,exynos4-hdmi",
> }, {
> /* end node */
> }
Why not fill in all the "base" compatible values there (I think you need
this anyway so that DTs don't all have to be compatible with
samsung,exynos4-hdmi), with .data containing the HDMI_VER_EXYNOS*
values, then ...
>>>
>>> At the moment, all DTs have to be compatible with exynos4-hdmi since
>>> it provides the base for the current driver. The driver uses 4210 and
>>> 4212 to differentiate between different register addresses and
>>> features, but most things are just exynos4-hdmi compatible.
>>
>> The DT nodes should include only the compatible values that the HW is
>> actually compatible with. If the HW isn't compatible with exynos4-hdmi,
>> that value shouldn't be in the compatible property, but instead whatever
>> the "base" value that the HW really is compatible with. The driver can
>> support multiple "base" compatible values from this table.
>
> All devices that use this driver are compatible, at some level, with
> exynos4-hdmi, so I think its usage is correct here.
But can a driver that only knows about the original exynos4-hdmi operate
any of the HW correctly without any additional knowledge? If not, the
new HW isn't compatible with the old.
> @@ -2218,17 +2217,18 @@ static int hdmi_probe(struct platform_device
> *pdev)
> +
> + if (of_device_is_compatible(dev->of_node,
> "samsung,exynos4210-hdmi"))
> + hdata->version |= HDMI_VER_EXYNOS4210;
> + if (of_device_is_compatible(dev->of_node,
> "samsung,exynos4212-hdmi"))
> + hdata->version |= HDMI_VER_EXYNOS4212;
> + if (of_device_is_compatible(dev->of_node,
> "samsung,exynos5250-hdmi"))
> + hdata->version |= HDMI_VER_EXYNOS5250;
Instead of that, do roughly:
match = of_match_device(hdmi_match_types, >dev);
if (match)
hdata->version |= (int)match->data;
That way, it's all table-based. Any future additions to
hdmi_match_types[] won't require another if statement to be added to
probe().
>>>
>>> I don't think it's that easy. of_match_device returns the first match
>>> from the device table, so I'd still need to iterate through the
>>> matches. I could still break this out into a table, but I don't think
>>> of_match_device is the right way to probe it.
>>
>> You shouldn't have to iterate over multiple matches. of_match_device()
>> is supposed to return the match for the first entry in the compatible
>> property, then if there was no match, move on to looking at the next
>> entry in the compatible property, etc. In practice, I think it's still
>> not implemented quite correctly for this, but you can make it work by
>> putting the newest compatible value first in the match table.
>
> I think the only way that works is if you hardcode the compatible
> versions in the driver, like this:
>
> static struct of_device_id hdmi_match_types[] = {
> {
> .compatible = "samsung,exynos5250-hdmi",
> .data = (void *)(HDMI_VER_EXYNOS5250 | HDMI_VER_EXYNOS4212);
> }, {
> .compatible = "samsung,exynos4212-hdmi",
> .data = (void *)HDMI_VER_EXYNOS4212;
> }, {
> .compatible = "samsung,exynos4210-hdmi",
> .data = (void *)HDMI_VER_EXYNOS4210;
> }, {
> /* end node */
> }
> };
>
> In that case, it eliminates the benefit of using device tree to
> determine the compatible bits. I hope I'm just being thick and missing
> something.
The table above looks /almost/ exactly correct to me, although I'm
unsure why samsung,exynos5250-hdmi has *two* version values; surely
there's a 1:1 mapping between the compatible values and the HW
compatibility they represent? That's certainly the intent.
Perhaps the "two values" think is because
[PATCH v17 4/7] fbmon: add videomode helpers
Hi! On Fri, Feb 01, 2013 at 06:29:50PM +0900, Jingoo Han wrote: > On Friday, January 25, 2013 6:02 PM, Steffen Trumtrar wrote > > > > + fbmode->sync = 0; > > + fbmode->vmode = 0; > > + if (vm->dmt_flags & VESA_DMT_HSYNC_HIGH) > > + fbmode->sync |= FB_SYNC_HOR_HIGH_ACT; > > + if (vm->dmt_flags & VESA_DMT_HSYNC_HIGH) > > Um, it seems to be a type. 'H'SYNC -> 'V'SYNC > Thus, it would be changed as below: > > VESA_DMT_HSYNC_HIGH -> VESA_DMT_VSYNC_HIGH Damn. You are right, that is a typo. But I guess some maintainer (Dave) really, really wants to take the series now and this can wait for an -rc. No?! ;-) Thanks, Steffen > > > + fbmode->sync |= FB_SYNC_VERT_HIGH_ACT; > > + if (vm->data_flags & DISPLAY_FLAGS_INTERLACED) > > + fbmode->vmode |= FB_VMODE_INTERLACED; > > + if (vm->data_flags & DISPLAY_FLAGS_DOUBLESCAN) > > + fbmode->vmode |= FB_VMODE_DOUBLE; > > + fbmode->flag = 0; > > + -- Pengutronix e.K. | | Industrial Linux Solutions | http://www.pengutronix.de/ | Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0| Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917- |
[PATCH v3 1/3] drm/exynos: Get HDMI version from device tree
On 02/05/2013 05:37 PM, Sean Paul wrote:
> On Tue, Feb 5, 2013 at 4:22 PM, Stephen Warren
> wrote:
>> n 02/05/2013 04:42 PM, Sean Paul wrote:
>>> Use the compatible string in the device tree to determine which
>>> registers/functions to use in the HDMI driver. Also changes the
>>> references from v13 to 4210 and v14 to 4212 to reflect the IP
>>> block version instead of the HDMI version.
>>
>>> diff --git a/Documentation/devicetree/bindings/drm/exynos/hdmi.txt
>>> b/Documentation/devicetree/bindings/drm/exynos/hdmi.txt
>>
>> Binding looks sane to me.
>>
>>> diff --git a/drivers/gpu/drm/exynos/exynos_hdmi.c
>>> b/drivers/gpu/drm/exynos/exynos_hdmi.c
>>
>>> #ifdef CONFIG_OF
>>> static struct of_device_id hdmi_match_types[] = {
>>> {
>>> - .compatible = "samsung,exynos5-hdmi",
>>> - .data = (void *)HDMI_TYPE14,
>>> + .compatible = "samsung,exynos4-hdmi",
>>> }, {
>>> /* end node */
>>> }
>>
>> Why not fill in all the "base" compatible values there (I think you need
>> this anyway so that DTs don't all have to be compatible with
>> samsung,exynos4-hdmi), with .data containing the HDMI_VER_EXYNOS*
>> values, then ...
>>
>
> At the moment, all DTs have to be compatible with exynos4-hdmi since
> it provides the base for the current driver. The driver uses 4210 and
> 4212 to differentiate between different register addresses and
> features, but most things are just exynos4-hdmi compatible.
The DT nodes should include only the compatible values that the HW is
actually compatible with. If the HW isn't compatible with exynos4-hdmi,
that value shouldn't be in the compatible property, but instead whatever
the "base" value that the HW really is compatible with. The driver can
support multiple "base" compatible values from this table.
>>> @@ -2218,17 +2217,18 @@ static int hdmi_probe(struct platform_device *pdev)
>>
>>> +
>>> + if (of_device_is_compatible(dev->of_node, "samsung,exynos4210-hdmi"))
>>> + hdata->version |= HDMI_VER_EXYNOS4210;
>>> + if (of_device_is_compatible(dev->of_node, "samsung,exynos4212-hdmi"))
>>> + hdata->version |= HDMI_VER_EXYNOS4212;
>>> + if (of_device_is_compatible(dev->of_node, "samsung,exynos5250-hdmi"))
>>> + hdata->version |= HDMI_VER_EXYNOS5250;
>>
>> Instead of that, do roughly:
>>
>> match = of_match_device(hdmi_match_types, >dev);
>> if (match)
>> hdata->version |= (int)match->data;
>>
>> That way, it's all table-based. Any future additions to
>> hdmi_match_types[] won't require another if statement to be added to
>> probe().
>
> I don't think it's that easy. of_match_device returns the first match
> from the device table, so I'd still need to iterate through the
> matches. I could still break this out into a table, but I don't think
> of_match_device is the right way to probe it.
You shouldn't have to iterate over multiple matches. of_match_device()
is supposed to return the match for the first entry in the compatible
property, then if there was no match, move on to looking at the next
entry in the compatible property, etc. In practice, I think it's still
not implemented quite correctly for this, but you can make it work by
putting the newest compatible value first in the match table.
[PATCH 2/2] drm/exynos: Add device tree based discovery support for G2D
On 02/05/2013 12:03 PM, Inki Dae wrote: > 2013/2/4 Sachin Kamat : >> On 1 February 2013 18:28, Inki Dae wrote: >>> >>> >>> >>> 2013. 2. 1. ?? 8:52 Inki Dae ??: >>> > -Original Message- > From: linux-media-owner at vger.kernel.org [mailto:linux-media- > owner at vger.kernel.org] On Behalf Of Sachin Kamat > Sent: Friday, February 01, 2013 8:40 PM > To: Inki Dae > Cc: Sylwester Nawrocki; Kukjin Kim; Sylwester Nawrocki; linux- > media at vger.kernel.org; dri-devel at lists.freedesktop.org; devicetree- > discuss at lists.ozlabs.org; patches at linaro.org > Subject: Re: [PATCH 2/2] drm/exynos: Add device tree based discovery > support for G2D > > On 1 February 2013 17:02, Inki Dae wrote: >> How about using like below? >>Compatible = ""samsung,exynos4x12-fimg-2d" /* for Exynos4212, >> Exynos4412 */ >> It looks odd to use "samsung,exynos4212-fimg-2d" saying that this ip is > for >> exynos4212 and exynos4412. > AFAIK, compatible strings are not supposed to have any wildcard characters. > Compatible string should suggest the first SoC that contained this IP. > Hence IMO 4212 is OK. > >>> Oops, one more thing. AFAIK Exynos4210 also has fimg-2d ip. In this case, >>> we should use "samsung,exynos4210-fimg-2d" as comparible string and add it >>> to exynos4210.dtsi? >> Exynos4210 has same g2d IP (v3.0) as C110 or V210; so the same >> comptible string will be used for this one too. >> >>> And please check if exynos4212 and 4412 SoCs have same fimg-2d ip. If it's >>> different, we might need to add ip version property or compatible string to >>> each dtsi file to identify the ip version. >> AFAIK, they both have the same IP (v4.1). >> > Ok, let's use the below, > > For exynos4210 SoC, > compatible = "samsung,exynos4210-g2d" > > For exynos4x12 SoCs, > compatible = "samsung,exynos4212-g2d" > > For exynos5250, 5410 (In case of Exynos5440, I'm not sure that the SoC > has same ip) > compatible = "samsung,exynos5250-g2d" > > To other guys, > The device tree is used by not only v4l2 side but also drm side so we > should reach an arrangement. So please give me ack if you agree to my > opinion. Otherwise please, give me your opinions. I like this compatible, also we can use rule like this to HDMI of drm/exynos. > > Thanks, > Inki Dae > > >>> Sorry but give me your opinions. >>> >>> Thanks, >>> Inki Dae >>> >>> Got it. Please post it again. > -- > With warm regards, > Sachin > -- > To unsubscribe from this list: send the line "unsubscribe linux-media" in > the body of a message to majordomo at vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html ___ dri-devel mailing list dri-devel at lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel >> >> >> -- >> With warm regards, >> Sachin > ___ > dri-devel mailing list > dri-devel at lists.freedesktop.org > http://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v3 1/3] drm/exynos: Get HDMI version from device tree
n 02/05/2013 04:42 PM, Sean Paul wrote:
> Use the compatible string in the device tree to determine which
> registers/functions to use in the HDMI driver. Also changes the
> references from v13 to 4210 and v14 to 4212 to reflect the IP
> block version instead of the HDMI version.
> diff --git a/Documentation/devicetree/bindings/drm/exynos/hdmi.txt
> b/Documentation/devicetree/bindings/drm/exynos/hdmi.txt
Binding looks sane to me.
> diff --git a/drivers/gpu/drm/exynos/exynos_hdmi.c
> b/drivers/gpu/drm/exynos/exynos_hdmi.c
> #ifdef CONFIG_OF
> static struct of_device_id hdmi_match_types[] = {
> {
> - .compatible = "samsung,exynos5-hdmi",
> - .data = (void *)HDMI_TYPE14,
> + .compatible = "samsung,exynos4-hdmi",
> }, {
> /* end node */
> }
Why not fill in all the "base" compatible values there (I think you need
this anyway so that DTs don't all have to be compatible with
samsung,exynos4-hdmi), with .data containing the HDMI_VER_EXYNOS*
values, then ...
> @@ -2218,17 +2217,18 @@ static int hdmi_probe(struct platform_device *pdev)
> +
> + if (of_device_is_compatible(dev->of_node, "samsung,exynos4210-hdmi"))
> + hdata->version |= HDMI_VER_EXYNOS4210;
> + if (of_device_is_compatible(dev->of_node, "samsung,exynos4212-hdmi"))
> + hdata->version |= HDMI_VER_EXYNOS4212;
> + if (of_device_is_compatible(dev->of_node, "samsung,exynos5250-hdmi"))
> + hdata->version |= HDMI_VER_EXYNOS5250;
Instead of that, do roughly:
match = of_match_device(hdmi_match_types, >dev);
if (match)
hdata->version |= (int)match->data;
That way, it's all table-based. Any future additions to
hdmi_match_types[] won't require another if statement to be added to
probe().
[PATCH v2] drm/nouveau: always select ACPI_VIDEO if ACPI is enabled.
On Tue, Feb 05, 2013 at 04:38:35PM +0100, Maarten Lankhorst wrote: > Argh, next attempt, based on i915's Kconfig. > > It seems that not only I have to select ACPI_VIDEO, I also have to select all > the dependencies. > Is this a Kconfig bug or working as intended? i915 seems to have a > workaround, so I copied it from > there. Except it's currently missing select THERMAL, so I guess it didn't get > updated when that got > added. > > >8 > Having nouveau builtin would still allow ACPI_VIDEO to be used as external > module > if some of the deps for acpi_video have not been met, which would result in a > linking > failure. Solve this by selecting all dependencies as well. > > Signed-off-by: Maarten Lankhorst Yep, this takes care of all deps, Tested-by: Borislav Petkov Thanks. -- Regards/Gruss, Boris. Sent from a fat crate under my desk. Formatting is fine. --
[Bug 60236] corruption of text and bottom of screen in xonotic menus since 325422c49449acdd8df1eb2ca8ed81f7696c38cc
https://bugs.freedesktop.org/show_bug.cgi?id=60236 --- Comment #10 from Paul Heldens --- Yes for me this effect varies also if I open , say a browser with a complex webpage, and then start xonotic again the text may be garbled the 2nd start its as if video memory or some caches get corrupted -- 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/20130205/59e6f7ad/attachment.html>
[Bug 60236] corruption of text and bottom of screen in xonotic menus since 325422c49449acdd8df1eb2ca8ed81f7696c38cc
https://bugs.freedesktop.org/show_bug.cgi?id=60236 --- Comment #9 from Andy Furniss --- (In reply to comment #0) > bisected to this commit > > 325422c49449acdd8df1eb2ca8ed81f7696c38cc is the first bad commit > commit 325422c49449acdd8df1eb2ca8ed81f7696c38cc > Author: Jerome Glisse > Date: Mon Jan 7 17:45:59 2013 -0500 > > r600g: add async for staging buffer upload v2 > > v2: Add virtual address to dma src/dst offset for cayman > > Signed-off-by: Jerome Glisse > > :04 04 4ef6e784f3acb7f21da0c5e1923810c78917d16d > 55f0ce7d9793ce04d392fc7943059545053a9d79 Msrc Looks correct to me on rv790. I get nothing like the corruption in the screens, for me it's just the band at the bottom of the screen and it's not always there (but seems to be reliable first test after boot from power off). I tested a couple of cycles with mesa reset just before this commit and couldn't see the problem. With mesa on this commit I can see it. Kernel is drm-fixes. -- 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/20130205/7f328719/attachment.html>
[PATCH v3 1/3] drm/exynos: Get HDMI version from device tree
On Tue, Feb 5, 2013 at 4:42 PM, Stephen Warren wrote:
> On 02/05/2013 05:37 PM, Sean Paul wrote:
>> On Tue, Feb 5, 2013 at 4:22 PM, Stephen Warren
>> wrote:
>>> n 02/05/2013 04:42 PM, Sean Paul wrote:
Use the compatible string in the device tree to determine which
registers/functions to use in the HDMI driver. Also changes the
references from v13 to 4210 and v14 to 4212 to reflect the IP
block version instead of the HDMI version.
>>>
diff --git a/Documentation/devicetree/bindings/drm/exynos/hdmi.txt
b/Documentation/devicetree/bindings/drm/exynos/hdmi.txt
>>>
>>> Binding looks sane to me.
>>>
diff --git a/drivers/gpu/drm/exynos/exynos_hdmi.c
b/drivers/gpu/drm/exynos/exynos_hdmi.c
>>>
#ifdef CONFIG_OF
static struct of_device_id hdmi_match_types[] = {
{
- .compatible = "samsung,exynos5-hdmi",
- .data = (void *)HDMI_TYPE14,
+ .compatible = "samsung,exynos4-hdmi",
}, {
/* end node */
}
>>>
>>> Why not fill in all the "base" compatible values there (I think you need
>>> this anyway so that DTs don't all have to be compatible with
>>> samsung,exynos4-hdmi), with .data containing the HDMI_VER_EXYNOS*
>>> values, then ...
>>>
>>
>> At the moment, all DTs have to be compatible with exynos4-hdmi since
>> it provides the base for the current driver. The driver uses 4210 and
>> 4212 to differentiate between different register addresses and
>> features, but most things are just exynos4-hdmi compatible.
>
> The DT nodes should include only the compatible values that the HW is
> actually compatible with. If the HW isn't compatible with exynos4-hdmi,
> that value shouldn't be in the compatible property, but instead whatever
> the "base" value that the HW really is compatible with. The driver can
> support multiple "base" compatible values from this table.
>
All devices that use this driver are compatible, at some level, with
exynos4-hdmi, so I think its usage is correct here.
@@ -2218,17 +2217,18 @@ static int hdmi_probe(struct platform_device *pdev)
>>>
+
+ if (of_device_is_compatible(dev->of_node, "samsung,exynos4210-hdmi"))
+ hdata->version |= HDMI_VER_EXYNOS4210;
+ if (of_device_is_compatible(dev->of_node, "samsung,exynos4212-hdmi"))
+ hdata->version |= HDMI_VER_EXYNOS4212;
+ if (of_device_is_compatible(dev->of_node, "samsung,exynos5250-hdmi"))
+ hdata->version |= HDMI_VER_EXYNOS5250;
>>>
>>> Instead of that, do roughly:
>>>
>>> match = of_match_device(hdmi_match_types, >dev);
>>> if (match)
>>> hdata->version |= (int)match->data;
>>>
>>> That way, it's all table-based. Any future additions to
>>> hdmi_match_types[] won't require another if statement to be added to
>>> probe().
>>
>> I don't think it's that easy. of_match_device returns the first match
>> from the device table, so I'd still need to iterate through the
>> matches. I could still break this out into a table, but I don't think
>> of_match_device is the right way to probe it.
>
> You shouldn't have to iterate over multiple matches. of_match_device()
> is supposed to return the match for the first entry in the compatible
> property, then if there was no match, move on to looking at the next
> entry in the compatible property, etc. In practice, I think it's still
> not implemented quite correctly for this, but you can make it work by
> putting the newest compatible value first in the match table.
I think the only way that works is if you hardcode the compatible
versions in the driver, like this:
static struct of_device_id hdmi_match_types[] = {
{
.compatible = "samsung,exynos5250-hdmi",
.data = (void *)(HDMI_VER_EXYNOS5250 | HDMI_VER_EXYNOS4212);
}, {
.compatible = "samsung,exynos4212-hdmi",
.data = (void *)HDMI_VER_EXYNOS4212;
}, {
.compatible = "samsung,exynos4210-hdmi",
.data = (void *)HDMI_VER_EXYNOS4210;
}, {
/* end node */
}
};
In that case, it eliminates the benefit of using device tree to
determine the compatible bits. I hope I'm just being thick and missing
something.
Sean
[PATCH 2/2] drm/exynos: Add device tree based discovery support for G2D
Hi Inki, On 2013? 02? 05? 12:03, Inki Dae wrote: > 2013/2/4 Sachin Kamat : >> On 1 February 2013 18:28, Inki Dae wrote: >>> >>> >>> >>> >>> 2013. 2. 1. ?? 8:52 Inki Dae ??: >>> > -Original Message- > From: linux-media-owner at vger.kernel.org [mailto:linux-media- > owner at vger.kernel.org] On Behalf Of Sachin Kamat > Sent: Friday, February 01, 2013 8:40 PM > To: Inki Dae > Cc: Sylwester Nawrocki; Kukjin Kim; Sylwester Nawrocki; linux- > media at vger.kernel.org; dri-devel at lists.freedesktop.org; devicetree- > discuss at lists.ozlabs.org; patches at linaro.org > Subject: Re: [PATCH 2/2] drm/exynos: Add device tree based discovery > support for G2D > > On 1 February 2013 17:02, Inki Dae wrote: >> >> How about using like below? >>Compatible = ""samsung,exynos4x12-fimg-2d" /* for Exynos4212, >> Exynos4412 */ >> It looks odd to use "samsung,exynos4212-fimg-2d" saying that this ip is > for >> exynos4212 and exynos4412. > > AFAIK, compatible strings are not supposed to have any wildcard characters. > Compatible string should suggest the first SoC that contained this IP. > Hence IMO 4212 is OK. > >>> >>> Oops, one more thing. AFAIK Exynos4210 also has fimg-2d ip. In this case, >>> we should use "samsung,exynos4210-fimg-2d" as comparible string and add it >>> to exynos4210.dtsi? >> >> Exynos4210 has same g2d IP (v3.0) as C110 or V210; so the same >> comptible string will be used for this one too. >> >>> And please check if exynos4212 and 4412 SoCs have same fimg-2d ip. If it's >>> different, we might need to add ip version property or compatible string to >>> each dtsi file to identify the ip version. >> >> AFAIK, they both have the same IP (v4.1). >> > > Ok, let's use the below, > > For exynos4210 SoC, > compatible = "samsung,exynos4210-g2d" > > For exynos4x12 SoCs, > compatible = "samsung,exynos4212-g2d" > > For exynos5250, 5410 (In case of Exynos5440, I'm not sure that the SoC > has same ip) > compatible = "samsung,exynos5250-g2d" > > To other guys, > The device tree is used by not only v4l2 side but also drm side so we > should reach an arrangement. So please give me ack if you agree to my > opinion. Otherwise please, give me your opinions. This seems good to me. Best Regards, - Seung-Woo Kim > > Thanks, > Inki Dae > > >>> >>> Sorry but give me your opinions. >>> >>> Thanks, >>> Inki Dae >>> >>> Got it. Please post it again. > > -- > With warm regards, > Sachin > -- > To unsubscribe from this list: send the line "unsubscribe linux-media" in > the body of a message to majordomo at vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html ___ dri-devel mailing list dri-devel at lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel >> >> >> >> -- >> With warm regards, >> Sachin > ___ > dri-devel mailing list > dri-devel at lists.freedesktop.org > http://lists.freedesktop.org/mailman/listinfo/dri-devel > -- Seung-Woo Kim Samsung Software R Center --
[PATCH v2] drm/nouveau: always select ACPI_VIDEO if ACPI is enabled.
Op 05-02-13 15:52, Borislav Petkov schreef: > On Mon, Feb 04, 2013 at 04:41:22PM +0100, Maarten Lankhorst wrote: >> Hey, >> >> Op 04-02-13 16:23, Borislav Petkov schreef: >>> Hi, >>> >>> I'm guessing someone has already triggered this on latest Linus' tree >>> and has a fix? >>> >>> drivers/built-in.o: In function `nouveau_acpi_edid': >>> /w/kernel/linux/drivers/gpu/drm/nouveau/nouveau_acpi.c:420: undefined >>> reference to `acpi_video_get_edid' >>> make: *** [vmlinux] Error 1 >>> >>> Btw, I got CONFIG_ACPI_VIDEO=m while CONFIG_DRM_NOUVEAU=y and this is >>> probably the reason for the vmlinux link error. >>> >>> Thanks. >>> >> Does this fix things? >> >> -->8 >> Having nouveau builtin would still allow ACPI_VIDEO to be used as external >> module if some of the deps for acpi_video >> have not been met, which would result in a linking failure. Solve this by >> only requiring ACPI && X86 to select ACPI_VIDEO. >> >> Signed-off-by: Maarten Lankhorst >> >> --- >> diff --git a/drivers/gpu/drm/nouveau/Kconfig >> b/drivers/gpu/drm/nouveau/Kconfig >> index 8a55bee..f08b9b6 100644 >> --- a/drivers/gpu/drm/nouveau/Kconfig >> +++ b/drivers/gpu/drm/nouveau/Kconfig >> @@ -10,7 +10,7 @@ config DRM_NOUVEAU >> select FB >> select FRAMEBUFFER_CONSOLE if !EXPERT >> select FB_BACKLIGHT if DRM_NOUVEAU_BACKLIGHT >> -select ACPI_VIDEO if ACPI && X86 && BACKLIGHT_CLASS_DEVICE && >> VIDEO_OUTPUT_CONTROL && INPUT >> +select ACPI_VIDEO if ACPI && X86 >> select ACPI_WMI if ACPI >> select MXM_WMI if ACPI >> select POWER_SUPPLY > Not really. > > drivers/built-in.o: In function `acpi_video_bus_put_one_device': > /root/kernel/linux/drivers/acpi/video.c:1407: undefined reference to > `thermal_cooling_device_unregister' > drivers/built-in.o: In function `acpi_video_device_find_cap': > /root/kernel/linux/drivers/acpi/video.c:842: undefined reference to > `thermal_cooling_device_register' > make: *** [vmlinux] Error 1 > > It is CONFIG_THERMAL=m this time. > > Thanks. > Argh, next attempt, based on i915's Kconfig. It seems that not only I have to select ACPI_VIDEO, I also have to select all the dependencies. Is this a Kconfig bug or working as intended? i915 seems to have a workaround, so I copied it from there. Except it's currently missing select THERMAL, so I guess it didn't get updated when that got added. >8 Having nouveau builtin would still allow ACPI_VIDEO to be used as external module if some of the deps for acpi_video have not been met, which would result in a linking failure. Solve this by selecting all dependencies as well. Signed-off-by: Maarten Lankhorst --- diff --git a/drivers/gpu/drm/nouveau/Kconfig b/drivers/gpu/drm/nouveau/Kconfig index 8a55bee..e84763a 100644 --- a/drivers/gpu/drm/nouveau/Kconfig +++ b/drivers/gpu/drm/nouveau/Kconfig @@ -10,10 +10,16 @@ config DRM_NOUVEAU select FB select FRAMEBUFFER_CONSOLE if !EXPERT select FB_BACKLIGHT if DRM_NOUVEAU_BACKLIGHT - select ACPI_VIDEO if ACPI && X86 && BACKLIGHT_CLASS_DEVICE && VIDEO_OUTPUT_CONTROL && INPUT select ACPI_WMI if ACPI select MXM_WMI if ACPI select POWER_SUPPLY + # Similar to i915, we need to select ACPI_VIDEO and it's dependencies + select BACKLIGHT_LCD_SUPPORT if ACPI && X86 + select BACKLIGHT_CLASS_DEVICE if ACPI && X86 + select VIDEO_OUTPUT_CONTROL if ACPI && X86 + select INPUT if ACPI && X86 + select THERMAL if ACPI && X86 + select ACPI_VIDEO if ACPI && X86 help Choose this option for open-source nVidia support.
[PATCH v3 1/3] drm/exynos: Get HDMI version from device tree
On Tue, Feb 5, 2013 at 4:22 PM, Stephen Warren wrote:
> n 02/05/2013 04:42 PM, Sean Paul wrote:
>> Use the compatible string in the device tree to determine which
>> registers/functions to use in the HDMI driver. Also changes the
>> references from v13 to 4210 and v14 to 4212 to reflect the IP
>> block version instead of the HDMI version.
>
>> diff --git a/Documentation/devicetree/bindings/drm/exynos/hdmi.txt
>> b/Documentation/devicetree/bindings/drm/exynos/hdmi.txt
>
> Binding looks sane to me.
>
>> diff --git a/drivers/gpu/drm/exynos/exynos_hdmi.c
>> b/drivers/gpu/drm/exynos/exynos_hdmi.c
>
>> #ifdef CONFIG_OF
>> static struct of_device_id hdmi_match_types[] = {
>> {
>> - .compatible = "samsung,exynos5-hdmi",
>> - .data = (void *)HDMI_TYPE14,
>> + .compatible = "samsung,exynos4-hdmi",
>> }, {
>> /* end node */
>> }
>
> Why not fill in all the "base" compatible values there (I think you need
> this anyway so that DTs don't all have to be compatible with
> samsung,exynos4-hdmi), with .data containing the HDMI_VER_EXYNOS*
> values, then ...
>
At the moment, all DTs have to be compatible with exynos4-hdmi since
it provides the base for the current driver. The driver uses 4210 and
4212 to differentiate between different register addresses and
features, but most things are just exynos4-hdmi compatible.
>> @@ -2218,17 +2217,18 @@ static int hdmi_probe(struct platform_device *pdev)
>
>> +
>> + if (of_device_is_compatible(dev->of_node, "samsung,exynos4210-hdmi"))
>> + hdata->version |= HDMI_VER_EXYNOS4210;
>> + if (of_device_is_compatible(dev->of_node, "samsung,exynos4212-hdmi"))
>> + hdata->version |= HDMI_VER_EXYNOS4212;
>> + if (of_device_is_compatible(dev->of_node, "samsung,exynos5250-hdmi"))
>> + hdata->version |= HDMI_VER_EXYNOS5250;
>
> Instead of that, do roughly:
>
> match = of_match_device(hdmi_match_types, >dev);
> if (match)
> hdata->version |= (int)match->data;
>
> That way, it's all table-based. Any future additions to
> hdmi_match_types[] won't require another if statement to be added to
> probe().
I don't think it's that easy. of_match_device returns the first match
from the device table, so I'd still need to iterate through the
matches. I could still break this out into a table, but I don't think
of_match_device is the right way to probe it.
Sean
[Bug 60236] corruption of text and bottom of screen in xonotic menus since 325422c49449acdd8df1eb2ca8ed81f7696c38cc
https://bugs.freedesktop.org/show_bug.cgi?id=60236 --- Comment #8 from Paul Heldens --- OpenGL renderer string: Gallium 0.4 on AMD RV730 -- 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/20130205/45787ec5/attachment.html>
[Bug 60236] corruption of text and bottom of screen in xonotic menus since 325422c49449acdd8df1eb2ca8ed81f7696c38cc
https://bugs.freedesktop.org/show_bug.cgi?id=60236 --- Comment #7 from Jerome Glisse --- And what GPU is this ? Because here it works ... -- 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/20130205/02806332/attachment.html>
[Bug 60236] corruption of text and bottom of screen in xonotic menus since 325422c49449acdd8df1eb2ca8ed81f7696c38cc
https://bugs.freedesktop.org/show_bug.cgi?id=60236 --- Comment #6 from Paul Heldens --- Tested it again to be sure Linux borgir 3.7.6 does NOT have the problem, pardon the mistake. -- 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/20130205/3b1d63da/attachment.html>
[PATCH] drm/nouveau: always select ACPI_VIDEO if ACPI is enabled.
On Mon, Feb 04, 2013 at 04:41:22PM +0100, Maarten Lankhorst wrote: > Hey, > > Op 04-02-13 16:23, Borislav Petkov schreef: > > Hi, > > > > I'm guessing someone has already triggered this on latest Linus' tree > > and has a fix? > > > > drivers/built-in.o: In function `nouveau_acpi_edid': > > /w/kernel/linux/drivers/gpu/drm/nouveau/nouveau_acpi.c:420: undefined > > reference to `acpi_video_get_edid' > > make: *** [vmlinux] Error 1 > > > > Btw, I got CONFIG_ACPI_VIDEO=m while CONFIG_DRM_NOUVEAU=y and this is > > probably the reason for the vmlinux link error. > > > > Thanks. > > > Does this fix things? > > -->8 > Having nouveau builtin would still allow ACPI_VIDEO to be used as external > module if some of the deps for acpi_video > have not been met, which would result in a linking failure. Solve this by > only requiring ACPI && X86 to select ACPI_VIDEO. > > Signed-off-by: Maarten Lankhorst > > --- > diff --git a/drivers/gpu/drm/nouveau/Kconfig b/drivers/gpu/drm/nouveau/Kconfig > index 8a55bee..f08b9b6 100644 > --- a/drivers/gpu/drm/nouveau/Kconfig > +++ b/drivers/gpu/drm/nouveau/Kconfig > @@ -10,7 +10,7 @@ config DRM_NOUVEAU > select FB > select FRAMEBUFFER_CONSOLE if !EXPERT > select FB_BACKLIGHT if DRM_NOUVEAU_BACKLIGHT > - select ACPI_VIDEO if ACPI && X86 && BACKLIGHT_CLASS_DEVICE && > VIDEO_OUTPUT_CONTROL && INPUT > + select ACPI_VIDEO if ACPI && X86 > select ACPI_WMI if ACPI > select MXM_WMI if ACPI > select POWER_SUPPLY Not really. drivers/built-in.o: In function `acpi_video_bus_put_one_device': /root/kernel/linux/drivers/acpi/video.c:1407: undefined reference to `thermal_cooling_device_unregister' drivers/built-in.o: In function `acpi_video_device_find_cap': /root/kernel/linux/drivers/acpi/video.c:842: undefined reference to `thermal_cooling_device_register' make: *** [vmlinux] Error 1 It is CONFIG_THERMAL=m this time. Thanks. -- Regards/Gruss, Boris. Sent from a fat crate under my desk. Formatting is fine. --
答复: [PATCH]Siliconmotion initial patch
This is an initial patch for Siliconmotion Graphics chips. It add SM750 chip support with 2d accelerate and hw curser support. It is a complete new driver. So the patch is a little bit big. Is it OK for review? Here is what we changed. drivers/video/Kconfig | 13 + drivers/video/Makefile|1 + drivers/video/lynxfb/Makefile | 63 ++ drivers/video/lynxfb/ddk750.h | 31 + drivers/video/lynxfb/ddk750_chip.c| 586 drivers/video/lynxfb/ddk750_chip.h| 97 ++ drivers/video/lynxfb/ddk750_display.c | 295 ++ drivers/video/lynxfb/ddk750_display.h | 124 +++ drivers/video/lynxfb/ddk750_dvi.c | 114 +++ drivers/video/lynxfb/ddk750_dvi.h | 84 ++ drivers/video/lynxfb/ddk750_help.c| 37 + drivers/video/lynxfb/ddk750_help.h| 42 + drivers/video/lynxfb/ddk750_hwi2c.c | 290 ++ drivers/video/lynxfb/ddk750_hwi2c.h | 28 + drivers/video/lynxfb/ddk750_mode.c| 213 + drivers/video/lynxfb/ddk750_mode.h| 59 ++ drivers/video/lynxfb/ddk750_power.c | 243 + drivers/video/lynxfb/ddk750_power.h | 85 ++ drivers/video/lynxfb/ddk750_reg.h | 362 +++ drivers/video/lynxfb/ddk750_sii164.c | 435 + drivers/video/lynxfb/ddk750_sii164.h | 187 drivers/video/lynxfb/ddk750_swi2c.c | 522 ++ drivers/video/lynxfb/ddk750_swi2c.h | 98 ++ drivers/video/lynxfb/lynx_accel.c | 417 drivers/video/lynxfb/lynx_accel.h | 161 drivers/video/lynxfb/lynx_cursor.c| 223 + drivers/video/lynxfb/lynx_cursor.h| 36 + drivers/video/lynxfb/lynx_drv.c | 1688 + drivers/video/lynxfb/lynx_drv.h | 271 ++ drivers/video/lynxfb/lynx_help.h | 115 +++ drivers/video/lynxfb/lynx_hw750.c | 633 + drivers/video/lynxfb/lynx_hw750.h | 120 +++ drivers/video/lynxfb/modedb.c | 238 + drivers/video/lynxfb/ver.h| 38 + 34 files changed, 7949 insertions(+) create mode 100644 drivers/video/lynxfb/Makefile create mode 100644 drivers/video/lynxfb/ddk750.h create mode 100644 drivers/video/lynxfb/ddk750_chip.c create mode 100644 drivers/video/lynxfb/ddk750_chip.h create mode 100644 drivers/video/lynxfb/ddk750_display.c create mode 100644 drivers/video/lynxfb/ddk750_display.h create mode 100644 drivers/video/lynxfb/ddk750_dvi.c create mode 100644 drivers/video/lynxfb/ddk750_dvi.h create mode 100644 drivers/video/lynxfb/ddk750_help.c create mode 100644 drivers/video/lynxfb/ddk750_help.h create mode 100644 drivers/video/lynxfb/ddk750_hwi2c.c create mode 100644 drivers/video/lynxfb/ddk750_hwi2c.h create mode 100644 drivers/video/lynxfb/ddk750_mode.c create mode 100644 drivers/video/lynxfb/ddk750_mode.h create mode 100644 drivers/video/lynxfb/ddk750_power.c create mode 100644 drivers/video/lynxfb/ddk750_power.h create mode 100644 drivers/video/lynxfb/ddk750_reg.h create mode 100644 drivers/video/lynxfb/ddk750_sii164.c create mode 100644 drivers/video/lynxfb/ddk750_sii164.h create mode 100644 drivers/video/lynxfb/ddk750_swi2c.c create mode 100644 drivers/video/lynxfb/ddk750_swi2c.h create mode 100644 drivers/video/lynxfb/lynx_accel.c create mode 100644 drivers/video/lynxfb/lynx_accel.h create mode 100644 drivers/video/lynxfb/lynx_cursor.c create mode 100644 drivers/video/lynxfb/lynx_cursor.h create mode 100644 drivers/video/lynxfb/lynx_drv.c create mode 100644 drivers/video/lynxfb/lynx_drv.h create mode 100644 drivers/video/lynxfb/lynx_help.h create mode 100644 drivers/video/lynxfb/lynx_hw750.c create mode 100644 drivers/video/lynxfb/lynx_hw750.h create mode 100644 drivers/video/lynxfb/modedb.c create mode 100644 drivers/video/lynxfb/ver.h -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20130205/54b694b9/attachment-0001.html> -- next part -- A non-text attachment was scrubbed... Name: 0001-Siliconmotion-initial-patch.patch Type: application/octet-stream Size: 256151 bytes Desc: 0001-Siliconmotion-initial-patch.patch URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20130205/54b694b9/attachment-0001.obj>
[PATCH v3 2/3] ARM: Change exynos5-hdmi references to exynos4-hdmi
With the change "drm/exynos: Get HDMI version from device tree",
exynos5-hdmi is no longer relevant. Update references to exynos4-hdmi
and update the hdmi compatibility string to accurately reflect the hdmi
driver.
Signed-off-by: Sean Paul
---
arch/arm/boot/dts/exynos5250.dtsi |3 ++-
arch/arm/mach-exynos/clock-exynos5.c |4 ++--
arch/arm/mach-exynos/mach-exynos5-dt.c |4 ++--
3 files changed, 6 insertions(+), 5 deletions(-)
diff --git a/arch/arm/boot/dts/exynos5250.dtsi
b/arch/arm/boot/dts/exynos5250.dtsi
index 3acf594..70464bf 100644
--- a/arch/arm/boot/dts/exynos5250.dtsi
+++ b/arch/arm/boot/dts/exynos5250.dtsi
@@ -573,7 +573,8 @@
};
hdmi {
- compatible = "samsung,exynos5-hdmi";
+ compatible = "samsung,exynos5250-hdmi",
+"samsung,exynos4212-hdmi", "samsung,exynos4-hdmi";
reg = <0x1453 0x7>;
interrupts = <0 95 0>;
};
diff --git a/arch/arm/mach-exynos/clock-exynos5.c
b/arch/arm/mach-exynos/clock-exynos5.c
index e9d7b80..6eae39d 100644
--- a/arch/arm/mach-exynos/clock-exynos5.c
+++ b/arch/arm/mach-exynos/clock-exynos5.c
@@ -686,12 +686,12 @@ static struct clk exynos5_init_clocks_off[] = {
.ctrlbit= (1 << 0),
}, {
.name = "hdmi",
- .devname= "exynos5-hdmi",
+ .devname= "exynos4-hdmi",
.enable = exynos5_clk_ip_disp1_ctrl,
.ctrlbit= (1 << 6),
}, {
.name = "hdmiphy",
- .devname= "exynos5-hdmi",
+ .devname= "exynos4-hdmi",
.enable = exynos5_clk_hdmiphy_ctrl,
.ctrlbit= (1 << 0),
}, {
diff --git a/arch/arm/mach-exynos/mach-exynos5-dt.c
b/arch/arm/mach-exynos/mach-exynos5-dt.c
index e99d3d8..0ccda72 100644
--- a/arch/arm/mach-exynos/mach-exynos5-dt.c
+++ b/arch/arm/mach-exynos/mach-exynos5-dt.c
@@ -97,8 +97,8 @@ static const struct of_dev_auxdata
exynos5250_auxdata_lookup[] __initconst = {
"exynos-gsc.2", NULL),
OF_DEV_AUXDATA("samsung,exynos5-gsc", EXYNOS5_PA_GSC3,
"exynos-gsc.3", NULL),
- OF_DEV_AUXDATA("samsung,exynos5-hdmi", 0x1453,
- "exynos5-hdmi", NULL),
+ OF_DEV_AUXDATA("samsung,exynos4-hdmi", 0x1453,
+ "exynos4-hdmi", NULL),
OF_DEV_AUXDATA("samsung,exynos5-mixer", 0x1445,
"exynos5-mixer", NULL),
OF_DEV_AUXDATA("samsung,mfc-v6", 0x1100, "s5p-mfc-v6", NULL),
--
1.7.7.3
[PATCH v3 1/3] drm/exynos: Get HDMI version from device tree
Use the compatible string in the device tree to determine which
registers/functions to use in the HDMI driver. Also changes the
references from v13 to 4210 and v14 to 4212 to reflect the IP
block version instead of the HDMI version.
Signed-off-by: Sean Paul
---
.../devicetree/bindings/drm/exynos/hdmi.txt|9 +-
drivers/gpu/drm/exynos/exynos_hdmi.c | 354 ++--
drivers/gpu/drm/exynos/regs-hdmi.h | 78 +++---
3 files changed, 223 insertions(+), 218 deletions(-)
diff --git a/Documentation/devicetree/bindings/drm/exynos/hdmi.txt
b/Documentation/devicetree/bindings/drm/exynos/hdmi.txt
index 589edee..781b6bc 100644
--- a/Documentation/devicetree/bindings/drm/exynos/hdmi.txt
+++ b/Documentation/devicetree/bindings/drm/exynos/hdmi.txt
@@ -1,7 +1,11 @@
Device-Tree bindings for drm hdmi driver
Required properties:
-- compatible: value should be "samsung,exynos5-hdmi".
+- compatible: suitable values are:
+ - "samsung,exynos5250-hdmi"
+ - "samsung,exynos4212-hdmi"
+ - "samsung,exynos4210-hdmi"
+ - "samsung,exynos4-hdmi"
- reg: physical base address of the hdmi and length of memory mapped
region.
- interrupts: interrupt number to the cpu.
@@ -15,7 +19,8 @@ Required properties:
Example:
hdmi {
- compatible = "samsung,exynos5-hdmi";
+ compatible = "samsung,exynos5250-hdmi",
+"samsung,exynos4212-hdmi", "samsung,exynos4-hdmi";
reg = <0x1453 0x10>;
interrupts = <0 95 0>;
hpd-gpio = < 7 0xf 1 3>;
diff --git a/drivers/gpu/drm/exynos/exynos_hdmi.c
b/drivers/gpu/drm/exynos/exynos_hdmi.c
index 9e3c2ad..622637f 100644
--- a/drivers/gpu/drm/exynos/exynos_hdmi.c
+++ b/drivers/gpu/drm/exynos/exynos_hdmi.c
@@ -73,9 +73,10 @@ enum HDMI_PACKET_TYPE {
HDMI_PACKET_TYPE_AUI = HDMI_PACKET_TYPE_INFOFRAME + 4
};
-enum hdmi_type {
- HDMI_TYPE13,
- HDMI_TYPE14,
+enum hdmi_version {
+ HDMI_VER_EXYNOS4210 = 1 << 0,
+ HDMI_VER_EXYNOS4212 = 1 << 1,
+ HDMI_VER_EXYNOS5250 = 1 << 2,
};
struct hdmi_resources {
@@ -148,7 +149,7 @@ struct hdmi_core_regs {
u8 vact_space_6[2];
};
-struct hdmi_v14_conf {
+struct hdmi_4212_conf {
int pixel_clock;
struct hdmi_core_regs core;
struct hdmi_tg_regs tg;
@@ -173,52 +174,51 @@ struct hdmi_context {
/* current hdmiphy conf index */
int cur_conf;
- struct hdmi_v14_confmode_conf;
+ struct hdmi_4212_conf mode_conf;
struct hdmi_resources res;
int hpd_gpio;
- enum hdmi_type type;
+ int version;
};
-/* HDMI Version 1.3 */
-static const u8 hdmiphy_v13_conf27[32] = {
+static const u8 hdmiphy_4210_conf27[32] = {
0x01, 0x05, 0x00, 0xD8, 0x10, 0x1C, 0x30, 0x40,
0x6B, 0x10, 0x02, 0x51, 0xDF, 0xF2, 0x54, 0x87,
0x84, 0x00, 0x30, 0x38, 0x00, 0x08, 0x10, 0xE0,
0x22, 0x40, 0xE3, 0x26, 0x00, 0x00, 0x00, 0x00,
};
-static const u8 hdmiphy_v13_conf27_027[32] = {
+static const u8 hdmiphy_4210_conf27_027[32] = {
0x01, 0x05, 0x00, 0xD4, 0x10, 0x9C, 0x09, 0x64,
0x6B, 0x10, 0x02, 0x51, 0xDF, 0xF2, 0x54, 0x87,
0x84, 0x00, 0x30, 0x38, 0x00, 0x08, 0x10, 0xE0,
0x22, 0x40, 0xE3, 0x26, 0x00, 0x00, 0x00, 0x00,
};
-static const u8 hdmiphy_v13_conf74_175[32] = {
+static const u8 hdmiphy_4210_conf74_175[32] = {
0x01, 0x05, 0x00, 0xD8, 0x10, 0x9C, 0xef, 0x5B,
0x6D, 0x10, 0x01, 0x51, 0xef, 0xF3, 0x54, 0xb9,
0x84, 0x00, 0x30, 0x38, 0x00, 0x08, 0x10, 0xE0,
0x22, 0x40, 0xa5, 0x26, 0x01, 0x00, 0x00, 0x00,
};
-static const u8 hdmiphy_v13_conf74_25[32] = {
+static const u8 hdmiphy_4210_conf74_25[32] = {
0x01, 0x05, 0x00, 0xd8, 0x10, 0x9c, 0xf8, 0x40,
0x6a, 0x10, 0x01, 0x51, 0xff, 0xf1, 0x54, 0xba,
0x84, 0x00, 0x10, 0x38, 0x00, 0x08, 0x10, 0xe0,
0x22, 0x40, 0xa4, 0x26, 0x01, 0x00, 0x00, 0x00,
};
-static const u8 hdmiphy_v13_conf148_5[32] = {
+static const u8 hdmiphy_4210_conf148_5[32] = {
0x01, 0x05, 0x00, 0xD8, 0x10, 0x9C, 0xf8, 0x40,
0x6A, 0x18, 0x00, 0x51, 0xff, 0xF1, 0x54, 0xba,
0x84, 0x00, 0x10, 0x38, 0x00, 0x08, 0x10, 0xE0,
0x22, 0x40, 0xa4, 0x26, 0x02, 0x00, 0x00, 0x00,
};
-struct hdmi_v13_tg_regs {
+struct hdmi_4210_tg_regs {
u8 cmd;
u8 h_fsz_l;
u8 h_fsz_h;
@@ -250,7 +250,7 @@ struct hdmi_v13_tg_regs {
u8 field_bot_hdmi_h;
};
-struct hdmi_v13_core_regs {
+struct hdmi_4210_core_regs {
u8 h_blank[2];
u8 v_blank[3];
u8 h_v_line[3];
@@ -263,22 +263,22 @@ struct hdmi_v13_core_regs {
u8 v_sync_gen3[3];
};
-struct hdmi_v13_preset_conf {
- struct hdmi_v13_core_regs core;
- struct hdmi_v13_tg_regs tg;
+struct hdmi_4210_preset_conf {
+
[PATCH v3 0/2] Get the HDMI IP block version from device tree
This set changes the hdmi device tree node to properly represent the version of the IP block. The first patch changes the drm hdmi driver to use the compatible field to determine which registers/functions to call, and removes the unfortunate v1.3/v1.4 naming convention. The second patch updates the arch- specific bits for exynos5. Changes in v3: - Use compatible field in device tree instead of hdmi-version field - Change hdmi driver's naming to use IP version instead of hdmi version Sean Paul (2): drm/exynos: Get HDMI version from device tree ARM: Change exynos5-hdmi references to exynos4-hdmi .../devicetree/bindings/drm/exynos/hdmi.txt|9 +- arch/arm/boot/dts/exynos5250.dtsi |3 +- arch/arm/mach-exynos/clock-exynos5.c |4 +- arch/arm/mach-exynos/mach-exynos5-dt.c |4 +- drivers/gpu/drm/exynos/exynos_hdmi.c | 354 ++-- drivers/gpu/drm/exynos/regs-hdmi.h | 78 +++--- 6 files changed, 229 insertions(+), 223 deletions(-) -- 1.7.7.3
[Bug 60294] [LLVM] Flashplayer crashing
https://bugs.freedesktop.org/show_bug.cgi?id=60294 Michel D?nzer changed: What|Removed |Added Summary|Flashplayer crashing|[LLVM] Flashplayer crashing -- 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/20130205/2dee58f8/attachment.html>
[ANNOUNCE] libdrm 2.4.42
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Alex Deucher (2): radeon: add OLAND family radeon: add OLAND pci ids David Herrmann (1): man: fix manpage build instructions Jesse Barnes (1): intel: add more VLV PCI IDs Maarten Lankhorst (3): nouveau: use @PACKAGE_VERSION@ in libdrm_nouveau.pc libdrm: remove DISTCHECK_CONFIGURE_FLAGS configure.ac: bump version to 2.4.42 for release Michel D?nzer (1): radeon: Fix 1D tiling layout on SI. Thierry Reding (1): man: Fix typo and use $() for make expressions git tag: libdrm-2.4.42 http://dri.freedesktop.org/libdrm/libdrm-2.4.42.tar.bz2 MD5: a6e2e26951bcc920b2049b65e86a659f libdrm-2.4.42.tar.bz2 SHA1: 7004899b6a80b2ee50f35f883cc14804c3e24188 libdrm-2.4.42.tar.bz2 SHA256: e0671082a77871c8474d3c0f09dbf5ff82d2429cd248088a691f7b484cbc76e1 libdrm-2.4.42.tar.bz2 http://dri.freedesktop.org/libdrm/libdrm-2.4.42.tar.gz MD5: 5f430bab316083378a12b10d0e0fe1a3 libdrm-2.4.42.tar.gz SHA1: bf767be78ce7048e9a2e8fd3d7a79edea982ee4f libdrm-2.4.42.tar.gz SHA256: acb2a694071eb048328cd6b868265dc5de9ef27cab08f516f7a5740f2b15a0af libdrm-2.4.42.tar.gz -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) iQIcBAEBAgAGBQJREQZMAAoJEP5VjHKmcBPD3h8P/2ihE/OLOPHvMGNgcoPnCeFf xUz1UMHwSNwjffi4OgijBRdqcoKIees79ZgdIvbD9bvd4lMAOiNx4e2jWHmk+1Ps cvfoAmyrOP3iEi/m6yaMCbIkvKrmobDDSqpgMbNIK92lK+6Gb2mOcncJ6JFYydV2 AwNTvSsw3EqJMf/xkGXhNbRMkWfDRPE5IJg6uohYszTPyusLj7UHgc6IUotFoP+A MVwwcB+DK/rbFBKjt3Q6f4me35Fw4Y2rTwrF+OL24RzpxRczqeo93ni32pI4MzTA GX/WOFKN4R0x1BVXd9LTa7LCRzTzuFUupyNaOA8lqsFtsmgoU3b70FkXnGnHPiXs 7kWX0/lSP9gMYCpYGjY2i/b9BCDTPvOajxIWPRgFrk6W+eoQVvaeaaB3E6GX9em5 kcSLpuOZURMyLofN+bwRmWdHlp3FHM7wAL5KZK0s6YJiZhP/vRCdgf/s0XgnKfG2 oR9Q0fimScdeRMm2VNwbwZ/5AxCOZ2AjicppHh9lsscTXUQcPZwVPF3JL1PVsJOG r+DHdVsRRWzMPDfcfbkDYxTt1s8wRmd7Muk895lAvuqvX0nFidA1w3tdYF6/8dEB EKSGV5y/QMMdmK70Q9Nw8ueK/rSzL1n94qzQliXimxPwQ7GmTcd95bsMgqZuOqVx cseyBzhI+fHcAdEBuJxu =1nxZ -END PGP SIGNATURE-
[Bug 60294] Flashplayer crashing
https://bugs.freedesktop.org/show_bug.cgi?id=60294 --- Comment #12 from Ren? Blokland --- (In reply to comment #9) > Does setting the environment variable R600_LLVM=0 or building Mesa without > --enable-r600-llvm-compiler work around the problem? without --enable-r600-llvm-compiler there is no change but R600_LLVM=0 solves everything. Thanks -- 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/20130205/05ffba2f/attachment.html>
[Bug 60294] Flashplayer crashing
https://bugs.freedesktop.org/show_bug.cgi?id=60294 --- Comment #11 from Ren? Blokland --- (In reply to comment #8) > It's not that I am a dev or something, but you should first consider > upgrading the kernel. Releases from 3.8-rc2 to 3.8-rc6 include lot of fixes > and maybe it could solve your problems. I am running rc6 now and the same problems. -- 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/20130205/750e59fe/attachment-0001.html>
[Bug 60236] corruption of text and bottom of screen in xonotic menus since 325422c49449acdd8df1eb2ca8ed81f7696c38cc
https://bugs.freedesktop.org/show_bug.cgi?id=60236 smoki changed: What|Removed |Added Attachment #74238|text/plain |image/png 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/20130205/98387751/attachment.html>
[Bug 60294] Flashplayer crashing
https://bugs.freedesktop.org/show_bug.cgi?id=60294 --- Comment #10 from Ren? Blokland --- Created attachment 74247 --> https://bugs.freedesktop.org/attachment.cgi?id=74247=edit my current 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/20130205/3f94b384/attachment.html>
[Bug 60236] corruption of text and bottom of screen in xonotic menus since 325422c49449acdd8df1eb2ca8ed81f7696c38cc
https://bugs.freedesktop.org/show_bug.cgi?id=60236 --- Comment #5 from Alex Deucher --- (In reply to comment #1) > linux 3.8-rc63.7.4 had it also 325422c49449acdd8df1eb2ca8ed81f7696c38cc (r600g: add async for staging buffer upload v2) only takes affect on 3.8 kernels. Previous kernels didn't support the DMA rings. So if you are seeing the same issue on multiple kernels, it's either something else or you are seeing two issues. It may be the same issue as bug 58042. -- 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/20130205/b8e5e7e4/attachment.html>
[PATCH 2/2] drm/exynos: Add device tree based discovery support for G2D
On Tue, Feb 5, 2013 at 12:03 PM, Inki Dae wrote: > 2013/2/4 Sachin Kamat : >> On 1 February 2013 18:28, Inki Dae wrote: >>> >>> >>> >>> >>> 2013. 2. 1. ?? 8:52 Inki Dae ??: >>> > -Original Message- > From: linux-media-owner at vger.kernel.org [mailto:linux-media- > owner at vger.kernel.org] On Behalf Of Sachin Kamat > Sent: Friday, February 01, 2013 8:40 PM > To: Inki Dae > Cc: Sylwester Nawrocki; Kukjin Kim; Sylwester Nawrocki; linux- > media at vger.kernel.org; dri-devel at lists.freedesktop.org; devicetree- > discuss at lists.ozlabs.org; patches at linaro.org > Subject: Re: [PATCH 2/2] drm/exynos: Add device tree based discovery > support for G2D > > On 1 February 2013 17:02, Inki Dae wrote: >> >> How about using like below? >>Compatible = ""samsung,exynos4x12-fimg-2d" /* for Exynos4212, >> Exynos4412 */ >> It looks odd to use "samsung,exynos4212-fimg-2d" saying that this ip is > for >> exynos4212 and exynos4412. > > AFAIK, compatible strings are not supposed to have any wildcard characters. > Compatible string should suggest the first SoC that contained this IP. > Hence IMO 4212 is OK. > >>> >>> Oops, one more thing. AFAIK Exynos4210 also has fimg-2d ip. In this case, >>> we should use "samsung,exynos4210-fimg-2d" as comparible string and add it >>> to exynos4210.dtsi? >> >> Exynos4210 has same g2d IP (v3.0) as C110 or V210; so the same >> comptible string will be used for this one too. >> >>> And please check if exynos4212 and 4412 SoCs have same fimg-2d ip. If it's >>> different, we might need to add ip version property or compatible string to >>> each dtsi file to identify the ip version. >> >> AFAIK, they both have the same IP (v4.1). >> > > Ok, let's use the below, > > For exynos4210 SoC, > compatible = "samsung,exynos4210-g2d" > > For exynos4x12 SoCs, > compatible = "samsung,exynos4212-g2d" Even though 4212 is exist, I can't see 4212 board support at mainline. so I prefer exynos4412-g2d instead of 4212-g2d. > > For exynos5250, 5410 (In case of Exynos5440, I'm not sure that the SoC > has same ip) > compatible = "samsung,exynos5250-g2d" Acked-by: Kyungmin Park > > To other guys, > The device tree is used by not only v4l2 side but also drm side so we > should reach an arrangement. So please give me ack if you agree to my > opinion. Otherwise please, give me your opinions. > > Thanks, > Inki Dae > > >>> >>> Sorry but give me your opinions. >>> >>> Thanks, >>> Inki Dae >>> >>> Got it. Please post it again. > > -- > With warm regards, > Sachin > -- > To unsubscribe from this list: send the line "unsubscribe linux-media" in > the body of a message to majordomo at vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html ___ dri-devel mailing list dri-devel at lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel >> >> >> >> -- >> With warm regards, >> Sachin > ___ > dri-devel mailing list > dri-devel at lists.freedesktop.org > http://lists.freedesktop.org/mailman/listinfo/dri-devel
答复: [PATCH]Siliconmotion initial patch
On Tue, Feb 05, 2013 at 10:04:27PM +0100, Daniel Vetter wrote: > On Tue, Feb 05, 2013 at 03:51:55PM +0800, Aaron.Chen ??? wrote: > > This is an initial patch for Siliconmotion Graphics chips. It add SM750 > > chip support with 2d accelerate and hw curser support. It is a complete > > new driver. So the patch is a little bit big. Is it OK for review? > > Adding a new fbdev driver while established consensus pretty much boils > down to fbdev being a dead subsystem which should only be used for legacy > applications and drivers: Not good. You should implement this as a drm > modesetting driver, and if required base your 2d acceleration on top of > the drm fb helpers. Or just implement a drm/gem driver to expose this. > > Additionally you should include the appropriate mailing lists, which is > linux-fbdev for fbdev drivers. > > On a very quick read the patch has serious issues: > > - checkpatch.pl: > > total: 2 errors, 779 warnings, 7961 lines checked > > NOTE: whitespace errors detected, you may wish to use scripts/cleanpatch or > scripts/cleanfile > > - Remants of hungarian notation (dunno whether checkpatch checks for > those, too much other stuff flying by, but it really stuck out). > > - Not using the linux i2c layer in the ddk750_hwi2c.c file. > > - Reimplementing i2c bit-banging code in the ddk750_swi2c.c > > - Adding a new implementation of a sil 164 dvi driver, we already have at > least two in drivers/gpu/drm/i2c/sil164_drv.c and > drivers/gpu/drm/i915/dvo_sil164.c. This should be unified and probably > use the drm encoder slave framework. > > At that point I've given up on further review, since there's clearly a lot > of work left to do. Please review SubmittingPatches from the kernel > documentation carefully. Also cc'ing our dear staging maintainer, he > should be able to point you at further useful resources for getting this > going. If you wish to put this in the drivers/staging/ directory and do the cleanup there before it moves to the "real" part of the kernel, I have no objection to that. thanks, greg k-h
[PATCH 2/2] drm: Use C8 instead of RGB332 when determining the format from depth/bpp
On Tue, Feb 5, 2013 at 12:55 AM, Daniel Vetter wrote: > On Thu, Jan 31, 2013 at 07:43:38PM +0200, ville.syrjala at linux.intel.com > wrote: >> From: Ville Syrj?l? >> >> Support for real RGB332 is a rarity, most hardware only really support >> C8. So use C8 instead of RGB332 when determining the format based on >> depth/bpp. >> >> This fixes 8bpp fbcon on i915, since i915 will only accept C8 and not >> RGB332. >> >> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=59572 >> Signed-off-by: Ville Syrj?l? > > Tested-by: mlsemon35 at gmail.com > > Dave, can you please consider including these two patches into -fixes? The > fix a black screen regression when users opt for 8bpp console ... These are for next, considering what Linus said about -fixes not unless they are big. so I'll stick a stable cc onto it in next. Dave.
[Bug 60302] piglit failures r600g radeon hd 6850
https://bugs.freedesktop.org/show_bug.cgi?id=60302 --- Comment #2 from Corey Richardson --- Good to know, thank you -- 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/20130205/5c913bbe/attachment.html>
[PATCH 2/2] drm/exynos: Add device tree based discovery support for G2D
2013/2/4 Sachin Kamat : > On 1 February 2013 18:28, Inki Dae wrote: >> >> >> >> >> 2013. 2. 1. ?? 8:52 Inki Dae ??: >> >>> >>> -Original Message- From: linux-media-owner at vger.kernel.org [mailto:linux-media- owner at vger.kernel.org] On Behalf Of Sachin Kamat Sent: Friday, February 01, 2013 8:40 PM To: Inki Dae Cc: Sylwester Nawrocki; Kukjin Kim; Sylwester Nawrocki; linux- media at vger.kernel.org; dri-devel at lists.freedesktop.org; devicetree- discuss at lists.ozlabs.org; patches at linaro.org Subject: Re: [PATCH 2/2] drm/exynos: Add device tree based discovery support for G2D On 1 February 2013 17:02, Inki Dae wrote: > > How about using like below? >Compatible = ""samsung,exynos4x12-fimg-2d" /* for Exynos4212, > Exynos4412 */ > It looks odd to use "samsung,exynos4212-fimg-2d" saying that this ip is for > exynos4212 and exynos4412. AFAIK, compatible strings are not supposed to have any wildcard >>> characters. Compatible string should suggest the first SoC that contained this IP. Hence IMO 4212 is OK. >> >> Oops, one more thing. AFAIK Exynos4210 also has fimg-2d ip. In this case, we >> should use "samsung,exynos4210-fimg-2d" as comparible string and add it to >> exynos4210.dtsi? > > Exynos4210 has same g2d IP (v3.0) as C110 or V210; so the same > comptible string will be used for this one too. > >> And please check if exynos4212 and 4412 SoCs have same fimg-2d ip. If it's >> different, we might need to add ip version property or compatible string to >> each dtsi file to identify the ip version. > > AFAIK, they both have the same IP (v4.1). > Ok, let's use the below, For exynos4210 SoC, compatible = "samsung,exynos4210-g2d" For exynos4x12 SoCs, compatible = "samsung,exynos4212-g2d" For exynos5250, 5410 (In case of Exynos5440, I'm not sure that the SoC has same ip) compatible = "samsung,exynos5250-g2d" To other guys, The device tree is used by not only v4l2 side but also drm side so we should reach an arrangement. So please give me ack if you agree to my opinion. Otherwise please, give me your opinions. Thanks, Inki Dae >> >> Sorry but give me your opinions. >> >> Thanks, >> Inki Dae >> >> >>> >>> Got it. Please post it again. >>> -- With warm regards, Sachin -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majordomo at vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html >>> >>> ___ >>> dri-devel mailing list >>> dri-devel at lists.freedesktop.org >>> http://lists.freedesktop.org/mailman/listinfo/dri-devel > > > > -- > With warm regards, > Sachin
[pull] drm-intel-next for 3.9
Hi Dave,
Probably the last feature pull for 3.9, there's some fixes outstanding
thought that I'd like to sneak in. And maybe 3.8 takes a bit longer ...
Anyway, highlights of this pull:
- Kill the horrible IS_DISPLAYREG hack to handle the mmio offset movements
on vlv, big thanks to Ville.
- Dynamic power well support for Haswell, shaves away a bit when only
using the eDP port on pipe A (Paulo). Plus unclaimed register fixes
uncovered by this.
- Clarifications of the gpu hang/reset state transitions, hopefully fixing
a few spurious -EIO deaths in userspace.
- Haswell ELD fixes.
- Some more (pp)gtt cleanups from Ben.
- A few smaller things all over.
Plus all the stuff from the previous rather small pull request:
- Broadcast RBG improvements and reduced color range fixes from Ville.
- Ben is on a "kill legacy gtt code for good" spree, first pile of patches
included.
- No-relocs and bo lut improvements for faster execbuf from Chris.
- Some refactorings from Imre.
QA filed tons of bugs this cycle, all due to us finally enabling all the
really anal timestamp and vblank counter checks in kms_flip, now that the
locking is fixed and EDID reads don't cause stalls any more. In short, our
vblank code seems to be ridiculously racy and broken :( Otoh that's not
really news.
Cheers, Daniel
The following changes since commit b5cc6c0387b2f8d269c1df1e68c97c958dd22fed:
Merge tag 'drm-intel-next-2012-12-21' of
git://people.freedesktop.org/~danvet/drm-intel into drm-next (2013-01-17
20:34:08 +1000)
are available in the git repository at:
git://people.freedesktop.org/~danvet/drm-intel tags/drm-intel-next-2013-02-01
for you to fetch changes up to 7d37beaaf3dbc6ff16f4d32a4dd6f8c557c6ab50:
GPU/i915: Fix acpi_bus_get_device() check in
drivers/gpu/drm/i915/intel_opregion.c (2013-02-01 11:01:50 +0100)
Ben Widawsky (16):
drm/i915: Kill gtt_end
drm/i915: Mappable_end can't ever be > end
drm/i915: Remove gtt_mappable_total
drm/i915: Create a gtt structure
drm/i915: Remove use on gma_bus_addr on gen6+
drm/i915: Remove use of gtt_mappable_entries
drm/i915: Cut out the infamous ILK w/a from AGP layer
drm/i915: Remove scratch page from shared
drm/i915: Needs_dmar, not
agp/intel: Add gma_bus_addr
drm/i915: Implement WaVSRefCountFullforceMissDisable
drm/i915: Error state should print /sys/kernel/debug
drm/i915: Add probe and remove to the gtt ops
drm/i915: remove intel_gtt structure
drm/i915: Reclaim GTT space for failed PPGTT
drm/i915: Fix CAGF for HSW
Changlong Xie (1):
drm/i915: gen6_gmch_remove can be static
Chris Wilson (9):
drm/i915: Add a debug interface to forcibly evict and shrink our object
caches
drm/i915: Bail if we attempt to allocate pages for a purged object
drm/i915: Mark a temporary allocation for copy-from-user as such
drm/i915: Take the handle idr spinlock once for looking up the exec
objects
drm/i915: Move the execbuffer objects list from the stack into the tracker
drm/i915: Use the reloc.handle as an index into the execbuffer array
drm/i915: Only insert the mb() before updating the fence parameter
drm/i915: Only apply the mb() when flushing the GTT domain during a finish
drm/i915: Only run idle processing from i915_gem_retire_requests_worker
Daniel Vetter (21):
drm/i915: wake up all pageflip waiters
drm/i915: Allow userspace to hint that the relocations were known
drm/i915: move dev_priv->mm out of line
drm/i915: extract hangcheck/reset/error_state state into substruct
drm/i915: move wedged to the other gpu error handling stuff
drm/i915: fix reset handling in the throttle ioctl
drm/i915: clear up wedged transitions
drm/i915: create a race-free reset detection
drm/i915: clarify concurrent hang detect/gpu reset consistency
drm/i915: fixup sbi_read/write locking
drm/i915: move modeset checks out of save/restore_modeset_reg
drm/i915: extract ums suspend/resume into i915_ums.c
drm/i915: dont save/restore VGA state for kms
drm/i915: move DP save/restore into i915_ums.c
drm/i915: vfuncs for gtt_clear_range/insert_entries
drm/i915: vfuncs for ppgtt
drm/i915: pte_encode is gen6+
drm/i915: extract hw ppgtt setup/cleanup code
drm/i915: kill cargo-culted locking from power well code
drm/i915: don't run hsw power well code on !hsw
drm/i915: dynamic Haswell display power well support
Egbert Eich (1):
drm/i915: Remove pch_rq_mask from struct drm_i915_private.
Imre Deak (3):
drm/i915: merge get_gtt_alignment/get_unfenced_gtt_alignment()
drm/i915: merge {i965, sandybridge}_write_fence_reg()
drm/i915: use gtt_get_size() instead of open coding it
Jani Nikula (3):
drm/i915: add quirk to invert brightness on eMachines G725
[Bug 60236] corruption of text and bottom of screen in xonotic menus since 325422c49449acdd8df1eb2ca8ed81f7696c38cc
https://bugs.freedesktop.org/show_bug.cgi?id=60236 Paul Heldens changed: What|Removed |Added Attachment #74238|0 |1 is obsolete|| --- Comment #4 from Paul Heldens --- Created attachment 74239 --> https://bugs.freedesktop.org/attachment.cgi?id=74239=edit screen shot Xonotic -- 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/20130205/be6eb4dc/attachment.html>
[Bug 60236] corruption of text and bottom of screen in xonotic menus since 325422c49449acdd8df1eb2ca8ed81f7696c38cc
https://bugs.freedesktop.org/show_bug.cgi?id=60236 --- Comment #3 from Paul Heldens --- Created attachment 74238 --> https://bugs.freedesktop.org/attachment.cgi?id=74238=edit screen shot Xonotic -- 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/20130205/76184584/attachment.html>
[PATCH] drm/nouveau: fix lockdep splat in display
Add a flag NVOBJ_FLAG_CREAT_EXCL, which will make sure that only 1 engctx will
be created.
This removes the need of having multiple
Fixes the following lockdep splat:
=
[ INFO: possible recursive locking detected ]
3.8.0-rc6-ninja+ #1 Not tainted
-
modprobe/585 is trying to acquire lock:
(>mutex){+.+.+.}, at: []
nouveau_instobj_create_+0x43/0x90 [nouveau]
but task is already holding lock:
(>mutex){+.+.+.}, at: []
nv50_disp_data_ctor+0x5d/0xd0 [nouveau]
other info that might help us debug this:
Possible unsafe locking scenario:
CPU0
lock(>mutex);
lock(>mutex);
*** DEADLOCK ***
May be due to missing lock nesting notation
4 locks held by modprobe/585:
#0: (&__lockdep_no_validate__){..}, at: []
__driver_attach+0x53/0xb0
#1: (&__lockdep_no_validate__){..}, at: []
__driver_attach+0x61/0xb0
#2: (drm_global_mutex){+.+.+.}, at: []
drm_get_pci_dev+0xbc/0x2b0
#3: (>mutex){+.+.+.}, at: []
nv50_disp_data_ctor+0x5d/0xd0 [nouveau]
stack backtrace:
Pid: 585, comm: modprobe Not tainted 3.8.0-rc6-expert+ #1
Call Trace:
[] validate_chain.isra.33+0xd72/0x10d0
[] ? __kernel_text_address+0x58/0x80
[] ? print_context_stack+0x5d/0xd0
[] __lock_acquire+0x3a1/0xb60
[] ? __lock_is_held+0x54/0x80
[] lock_acquire+0x5a/0x70
[] ? nouveau_instobj_create_+0x43/0x90 [nouveau]
[] mutex_lock_nested+0x69/0x340
[] ? nouveau_instobj_create_+0x43/0x90 [nouveau]
[] ? nouveau_object_create_+0x60/0xa0 [nouveau]
[] nouveau_instobj_create_+0x43/0x90 [nouveau]
[] nv50_instobj_ctor+0x4c/0xf0 [nouveau]
[] nouveau_object_ctor+0x33/0xc0 [nouveau]
[] nv50_instmem_alloc+0x21/0x30 [nouveau]
[] nouveau_gpuobj_create_+0x247/0x2f0 [nouveau]
[] ? _raw_spin_unlock_irqrestore+0x3a/0x70
[] ? trace_hardirqs_on_caller+0x10d/0x1a0
[] nouveau_engctx_create_+0x25c/0x2a0 [nouveau]
[] nv50_disp_data_ctor+0xc1/0xd0 [nouveau]
[] ? nouveau_subdev_reset+0x52/0x60 [nouveau]
[] nouveau_object_ctor+0x33/0xc0 [nouveau]
[] nouveau_object_new+0x112/0x240 [nouveau]
[] nv50_display_create+0x18d/0x860 [nouveau]
[] ? __cancel_work_timer+0x6d/0xc0
[] nouveau_display_create+0x3cb/0x670 [nouveau]
[] nouveau_drm_load+0x26f/0x590 [nouveau]
[] ? device_register+0x19/0x20
[] ? drm_sysfs_device_add+0x81/0xb0
[] drm_get_pci_dev+0x17e/0x2b0
[] ? __pci_set_master+0x26/0x80
[] nouveau_drm_probe+0x25a/0x2a0 [nouveau]
[] local_pci_probe+0x46/0x80
[] pci_device_probe+0x101/0x110
[] driver_probe_device+0x76/0x240
[] __driver_attach+0xa3/0xb0
[] ? driver_probe_device+0x240/0x240
[] bus_for_each_dev+0x4d/0x90
[] driver_attach+0x19/0x20
[] bus_add_driver+0x1a0/0x270
[] ? 0xa023cfff
[] driver_register+0x72/0x170
[] ? 0xa023cfff
[] __pci_register_driver+0x5f/0x70
[] drm_pci_init+0x115/0x130
[] ? 0xa023cfff
[] ? 0xa023cfff
[] nouveau_drm_init+0x4d/0x1000 [nouveau]
[] do_one_initcall+0x11a/0x170
[] load_module+0xe84/0x1470
[] ? in_lock_functions+0x20/0x20
[] ? trace_hardirqs_on_thunk+0x3a/0x3f
[] sys_init_module+0xb7/0xe0
[] system_call_fastpath+0x1a/0x1f
Reported-by: Arend van Spriel
Reported-by: Peter Hurley
Reported-by: Daniel J Blueman
Signed-off-by: Maarten Lankhorst
---
XXX: Add Cc: stable at kernel.org if it applies to 3.7 ?
diff --git a/drivers/gpu/drm/nouveau/core/core/engctx.c
b/drivers/gpu/drm/nouveau/core/core/engctx.c
index 84c71fa..4a0ab2b 100644
--- a/drivers/gpu/drm/nouveau/core/core/engctx.c
+++ b/drivers/gpu/drm/nouveau/core/core/engctx.c
@@ -31,12 +31,15 @@
#include
static inline int
-nouveau_engctx_exists(struct nouveau_object *parent,
+nouveau_engctx_exists(struct nouveau_object *parent, u32 flags,
struct nouveau_engine *engine, void **pobject)
{
struct nouveau_engctx *engctx;
struct nouveau_object *parctx;
+ if ((flags & NVOBJ_FLAG_CREAT_EXCL) && !list_empty(>contexts))
+ return -EBUSY;
+
list_for_each_entry(engctx, >contexts, head) {
parctx = nv_pclass(nv_object(engctx), NV_PARENT_CLASS);
if (parctx == parent) {
@@ -67,7 +70,7 @@ nouveau_engctx_create_(struct nouveau_object *parent,
* and reference it instead of creating a new one
*/
spin_lock_irqsave(>lock, save);
- ret = nouveau_engctx_exists(parent, engine, pobject);
+ ret = nouveau_engctx_exists(parent, flags, engine, pobject);
spin_unlock_irqrestore(>lock, save);
if (ret)
return ret;
@@ -94,7 +97,7 @@ nouveau_engctx_create_(struct nouveau_object *parent,
* it's not possible to allocate the object with it held.
*/
spin_lock_irqsave(>lock, save);
- ret = nouveau_engctx_exists(parent, engine, pobject);
+ ret = nouveau_engctx_exists(parent, flags, engine, pobject);
if (ret) {
spin_unlock_irqrestore(>lock, save);
nouveau_object_ref(NULL, );
diff --git
[PATCH v4 1/1] video: drm: exynos: Adds display-timing node parsing using video helper function
This patch adds display-timing node parsing using video helper function
Signed-off-by: Leela Krishna Amudala
Signed-off-by: Vikas Sajjan
---
drivers/gpu/drm/exynos/exynos_drm_fimd.c | 41 +++---
1 file changed, 37 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/exynos/exynos_drm_fimd.c
b/drivers/gpu/drm/exynos/exynos_drm_fimd.c
index bf0d9ba..978e866 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_fimd.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_fimd.c
@@ -19,6 +19,7 @@
#include
#include
#include
+#include
#include
#include
@@ -905,16 +906,48 @@ static int __devinit fimd_probe(struct platform_device
*pdev)
struct exynos_drm_subdrv *subdrv;
struct exynos_drm_fimd_pdata *pdata;
struct exynos_drm_panel_info *panel;
+ struct fb_videomode *fbmode;
+ struct pinctrl *pctrl;
struct resource *res;
int win;
int ret = -EINVAL;
DRM_DEBUG_KMS("%s\n", __FILE__);
- pdata = pdev->dev.platform_data;
- if (!pdata) {
- dev_err(dev, "no platform data specified\n");
- return -EINVAL;
+ if (pdev->dev.of_node) {
+ pdata = devm_kzalloc(dev, sizeof(*pdata), GFP_KERNEL);
+ if (!pdata) {
+ DRM_ERROR("memory allocation for pdata failed\n");
+ return -ENOMEM;
+ }
+
+ fbmode = devm_kzalloc(dev, sizeof(*fbmode), GFP_KERNEL);
+ if (!fbmode) {
+ DRM_ERROR("memory allocation for fbmode failed\n");
+ return -ENOMEM;
+ }
+
+ ret = of_get_fb_videomode(dev->of_node, fbmode, -1);
+ if (ret) {
+ DRM_ERROR("failed: of_get_fb_videomode() :"
+ "return value: %d\n", ret);
+ return ret;
+ }
+ pdata->panel.timing = (struct fb_videomode) *fbmode;
+
+ pctrl = devm_pinctrl_get_select_default(dev);
+ if (IS_ERR_OR_NULL(pctrl)) {
+ DRM_ERROR("failed: devm_pinctrl_get_select_default()"
+ "return value: %d\n", PTR_RET(pctrl));
+ return PTR_RET(pctrl);
+ }
+
+ } else {
+ pdata = pdev->dev.platform_data;
+ if (!pdata) {
+ DRM_ERROR("no platform data specified\n");
+ return -EINVAL;
+ }
}
panel = >panel;
--
1.7.9.5
[PATCH v4 0/1] Adds display-timing node parsing to exynos drm fimd
This patch adds display-timing node parsing to drm fimd, this depends on the display helper patchset at http://lists.freedesktop.org/archives/dri-devel/2013-January/033998.html It also adds pinctrl support for drm fimd. changes since v3: - addressed comments from Sean Paul , to modify the return values and print messages. changes since v2: - moved 'devm_pinctrl_get_select_default' function call under 'if (pdev->dev.of_node)', this makes NON-DT code unchanged. (reported by: Rahul Sharma ) changes since v1: - addressed comments from Sean Paul Vikas Sajjan (1): video: drm: exynos: Adds display-timing node parsing using video helper function drivers/gpu/drm/exynos/exynos_drm_fimd.c | 41 +++--- 1 file changed, 37 insertions(+), 4 deletions(-) -- 1.7.9.5
[PATCHv5,RESEND 8/8] drm: tegra: Add gr2d device
struct drm_device *drm,
> >> + struct drm_file *file_priv)
> >> +{
> >> + struct host1x_job *job;
> >> + int num_cmdbufs = args->num_cmdbufs;
> >> + int num_relocs = args->num_relocs;
> >> + int num_waitchks = args->num_waitchks;
> >> + struct tegra_drm_cmdbuf __user *cmdbufs =
> >> + (void * __user)(uintptr_t)args->cmdbufs;
> >> + struct tegra_drm_reloc __user *relocs =
> >> + (void * __user)(uintptr_t)args->relocs;
> >> + struct tegra_drm_waitchk __user *waitchks =
> >> + (void * __user)(uintptr_t)args->waitchks;
> >
> > No need for all the uintptr_t casts.
>
> Will try to remove - but I do remember getting compiler warnings without
> them.
I think you shouldn't even have to cast to void * first. Just cast to
the target type directly. I don't see why the compiler should complain.
> (...)
> > Most of this looks very generic. Can't it be split out into separate
> > functions and reused in other (gr3d) modules?
>
> That's actually how most of this is downstream. I thought to make
> everything really simple and make it all 2D specific in the first patch
> set, and split into generic when we add support for another device.
Okay, that's fine then.
> >> +static int gr2d_is_addr_reg(struct platform_device *dev, u32 class, u32
> >> reg)
> >> +{
> >> + int ret;
> >> +
> >> + if (class == NV_HOST1X_CLASS_ID)
> >> + ret = reg == 0x2b;
> >> + else
> >> + switch (reg) {
> >> + case 0x1a:
> >> + case 0x1b:
> >> + case 0x26:
> >> + case 0x2b:
> >> + case 0x2c:
> >> + case 0x2d:
> >> + case 0x31:
> >> + case 0x32:
> >> + case 0x48:
> >> + case 0x49:
> >> + case 0x4a:
> >> + case 0x4b:
> >> + case 0x4c:
> >> + ret = 1;
> >> + break;
> >> + default:
> >> + ret = 0;
> >> + break;
> >> + }
> >> +
> >> + return ret;
> >> +}
> >
> > I should probably bite the bullet and read through the (still) huge
> > patch 3 to understand exactly why this is needed.
>
> That's the security firewall. It walks through each submit, and ensures
> that each register write that writes an address, goes through the host1x
> reloc mechanism. This way user space cannot ask 2D to write to arbitrary
> memory locations.
I see. Can this be made more generic? Perhaps adding a table of valid
registers to the device and use a generic function to iterate over that
instead of having to provide the same function for each client.
> >> +static int __exit gr2d_remove(struct platform_device *dev)
> >> +{
> >> + struct host1x *host1x =
> >> + host1x_get_drm_data(to_platform_device(dev->dev.parent));
> >> + struct gr2d *gr2d = platform_get_drvdata(dev);
> >> + int err;
> >> +
> >> + err = host1x_unregister_client(host1x, >client);
> >> + if (err < 0) {
> >> + dev_err(>dev, "failed to unregister host1x client:
> >> %d\n",
> >> + err);
> >> + return err;
> >> + }
> >> +
> >> + host1x_syncpt_free(gr2d->syncpt);
> >> + return 0;
> >> +}
> >
> > Isn't this missing a host1x_channel_put() or host1x_free_channel()?
>
> All references should be handled in gr2d_open_channel() and
> gr2d_close_channel(). I think we'd need to ensure all contexts are
> closed at this point.
Yes, that'd work as well. Actually I would assume that all contexts
associated with a given file should be freed when the file is closed.
That way all of this should work pretty much automatically.
> >> +struct tegra_drm_syncpt_wait_args {
> >> + __u32 id;
> >> + __u32 thresh;
> >> + __s32 timeout;
> >> + __u32 value;
> >> +};
> >> +
> >> +#define DRM_TEGRA_NO_TIMEOUT (-1)
> >
> > Is this the only reason why timeout is signed? If so maybe a better
> > choice would be __u32 and DRM_TEGRA_NO_TIMEOUT 0x.
>
> I believe it is so. In fact we'd need to rename it to something like
> INFINITE_TIMEOUT, because we also have a case of timeout=0, which
> returns immediately, i.e. doesn't have a timeout either.
For timeout == 0 I don't think we need a symbolic name. It is pretty
common for 0 to mean no timeout. But yes, DRM_TEGRA_INFINITE_TIMEOUT
should be okay.
> >> +struct tegra_drm_syncpt_incr {
> >> + __u32 syncpt_id;
> >> + __u32 syncpt_incrs;
> >> +};
> >
> > Maybe the fields would be better named id and incrs. Though I also
> > notice that incrs is never used. I guess that's supposed to be used in
> > the future to allow increments by more than a single value. If so,
> > perhaps value would be a better name.
>
> It's actually used in the dreaded patch 3, as part of tegra_drm_submit_args.
Okay. The superfluous syncpt_ prefixes should still go away.
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/20130205/1443dce9/attachment.pgp>
[PATCH v4 1/1] video: drm: exynos: Adds display-timing node parsing using video helper function
Dear Vikas,
thank you for the patch. Please send a fifth iteration with the
following changes to the commit message.
Am Dienstag, den 05.02.2013, 11:02 +0530 schrieb Vikas Sajjan:
The summary should not implicitly assume ?patch? written before it. So
do not add third person s to ?Add?.
video: drm: exynos: Add display-timing node parsing using video helper
function
> This patch adds display-timing node parsing using video helper function
As this is the same as the summary you should leave it out. Also it is
good style not to use ?This/The patch? in the commit message.
Please use the commit message to explain your change. For example the if
statement. Why is the original code put into the else branch and is not
needed if the first condition is true?
> Signed-off-by: Leela Krishna Amudala
> Signed-off-by: Vikas Sajjan
> ---
> drivers/gpu/drm/exynos/exynos_drm_fimd.c | 41
> +++---
> 1 file changed, 37 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/gpu/drm/exynos/exynos_drm_fimd.c
> b/drivers/gpu/drm/exynos/exynos_drm_fimd.c
> index bf0d9ba..978e866 100644
> --- a/drivers/gpu/drm/exynos/exynos_drm_fimd.c
> +++ b/drivers/gpu/drm/exynos/exynos_drm_fimd.c
> @@ -19,6 +19,7 @@
> #include
> #include
> #include
> +#include
>
> #include
> #include
> @@ -905,16 +906,48 @@ static int __devinit fimd_probe(struct platform_device
> *pdev)
> struct exynos_drm_subdrv *subdrv;
> struct exynos_drm_fimd_pdata *pdata;
> struct exynos_drm_panel_info *panel;
> + struct fb_videomode *fbmode;
> + struct pinctrl *pctrl;
> struct resource *res;
> int win;
> int ret = -EINVAL;
>
> DRM_DEBUG_KMS("%s\n", __FILE__);
>
> - pdata = pdev->dev.platform_data;
> - if (!pdata) {
> - dev_err(dev, "no platform data specified\n");
> - return -EINVAL;
> + if (pdev->dev.of_node) {
> + pdata = devm_kzalloc(dev, sizeof(*pdata), GFP_KERNEL);
> + if (!pdata) {
> + DRM_ERROR("memory allocation for pdata failed\n");
> + return -ENOMEM;
> + }
> +
> + fbmode = devm_kzalloc(dev, sizeof(*fbmode), GFP_KERNEL);
> + if (!fbmode) {
> + DRM_ERROR("memory allocation for fbmode failed\n");
> + return -ENOMEM;
> + }
> +
> + ret = of_get_fb_videomode(dev->of_node, fbmode, -1);
> + if (ret) {
> + DRM_ERROR("failed: of_get_fb_videomode() :"
> + "return value: %d\n", ret);
> + return ret;
> + }
> + pdata->panel.timing = (struct fb_videomode) *fbmode;
> +
> + pctrl = devm_pinctrl_get_select_default(dev);
> + if (IS_ERR_OR_NULL(pctrl)) {
> + DRM_ERROR("failed: devm_pinctrl_get_select_default()"
> + "return value: %d\n", PTR_RET(pctrl));
> + return PTR_RET(pctrl);
> + }
> +
> + } else {
> + pdata = pdev->dev.platform_data;
> + if (!pdata) {
> + DRM_ERROR("no platform data specified\n");
> + return -EINVAL;
> + }
> }
>
> panel = >panel;
Thanks,
Paul
-- next part --
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20130205/2e7004c1/attachment.pgp>
[PATCH 2/2] drm/exynos: Add device tree based discovery support for G2D
On 02/05/2013 04:03 AM, Inki Dae wrote: [...] >> Exynos4210 has same g2d IP (v3.0) as C110 or V210; so the same >> comptible string will be used for this one too. >> >>> And please check if exynos4212 and 4412 SoCs have same fimg-2d ip. >>> If it's different, we might need to add ip version property or compatible >>> string to each dtsi file to identify the ip version. >> >> AFAIK, they both have the same IP (v4.1). >> > > Ok, let's use the below, > > For exynos4210 SoC, > compatible = "samsung,exynos4210-g2d" Since S5PV210 (Exynos3110 ??) seems to have same G2D IP, I guess something like "samsung,s5pv210-g2d" could be used for both S5PV210 (S5PC110) and Exynos4210 (S5PC210, S5PV310) ? I'm fine with using "samsung,exynos4210-g2d" for Exynos4210 though. For instance for tegra SoCs a conventions like "nvidia,tegra-", is used (e.g. "nvidia,tegra20-gr2d"). > For exynos4x12 SoCs, > compatible = "samsung,exynos4212-g2d" I'm not sure how well exynos4212 is going to be supported in the kernel. As Mr Park pointed out, if it is going to be nearly not existent then we could perhaps go with "samsung,exynos4412-g2d" for Exynos4412 and "samsung,exynos4212-g2d" for Exynos4212 (as needed). Anyway, I fine with using "samsung,exynos4212-g2d" for both. I'd like to hear Mr Kim's opinion on this as well though. > For exynos5250, 5410 (In case of Exynos5440, I'm not sure that the SoC > has same ip) > compatible = "samsung,exynos5250-g2d" > > To other guys, > The device tree is used by not only v4l2 side but also drm side so we > should reach an arrangement. So please give me ack if you agree to my > opinion. Otherwise please, give me your opinions. It looks good to me, please just see the two remarks above. -- Regards, Sylwester
[PATCHv5,RESEND 5/8] drm: tegra: Move drm to live under host1x
On Mon, Feb 04, 2013 at 08:45:36PM -0800, Terje Bergstr?m wrote: > On 04.02.2013 03:08, Thierry Reding wrote: > > * PGP Signed by an unknown key > > > > On Tue, Jan 15, 2013 at 01:44:01PM +0200, Terje Bergstrom wrote: > > [...] > >> diff --git a/drivers/gpu/host1x/Makefile b/drivers/gpu/host1x/Makefile > >> index 697d49a..ffc8bf1 100644 > >> --- a/drivers/gpu/host1x/Makefile > >> +++ b/drivers/gpu/host1x/Makefile > >> @@ -12,4 +12,10 @@ host1x-y = \ > >>hw/host1x01.o > >> > >> host1x-$(CONFIG_TEGRA_HOST1X_CMA) += cma.o > >> + > >> +ccflags-y += -Iinclude/drm > >> +ccflags-$(CONFIG_DRM_TEGRA_DEBUG) += -DDEBUG > >> + > >> +host1x-$(CONFIG_DRM_TEGRA) += drm/drm.o drm/fb.o drm/dc.o drm/host1x.o > >> +host1x-$(CONFIG_DRM_TEGRA) += drm/output.o drm/rgb.o drm/hdmi.o > >> obj-$(CONFIG_TEGRA_HOST1X) += host1x.o > > > > Can this be moved into a separate Makefile in the drm subdirectory? > > I tried, and kernel build helpfully created two .ko files. As having > cyclic dependencies between two modules isn't nice, I merged them to > same module and that seemed to force merging Makefile. > > If anybody has an idea on how to do it otherwise, I'd be happy to keep > the Makefiles separate. Okay, I'll take a look. 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/20130205/96da5929/attachment.pgp>
[PATCHv5,RESEND 4/8] gpu: host1x: Add debug support
el data structures but would have to rely on the data itself
for diagnostics. IOMMU virtual addresses won't be available and so on.
> >> +static void host1x_debug_show_channel_cdma(struct host1x *m,
> >> + struct host1x_channel *ch, struct output *o, int chid)
> >> +{
> > [...]
> >> + switch (cbstat) {
> >> + case 0x00010008:
> >
> > Again, symbolic names would be nice.
>
> I propose I remove the decoding from kernel, and save 200 lines.
I think it could be more than 200 lines. If all we provide in the kernel
is some statistics about syncpoint usage or channel state that should be
a lot less code than we have now.
However that would make it necessary to provide userspace tools that can
provide the same quality of diagnostics, so I'm not sure if it's doable
without access to the in-kernel data structures.
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/20130205/ca8a97e8/attachment.pgp>
[PATCHv5,RESEND 2/8] gpu: host1x: Add syncpoint wait and interrupts
locate memory
in host1x_syncpt_wait() directly instead of going through the wrapper.
> >> +void host1x_intr_put_ref(struct host1x_intr *intr, u32 id, void *ref)
> >
> > Here again, you pass in the waiter via a void *. Why's that?
>
> host1x_waitlist is hidden inside intr.c.
I don't think that's necessary here. I'd rather have the compiler check
for types rather than hide the structure.
> >> +int host1x_intr_init(struct host1x_intr *intr, u32 irq_sync)
> >
> > Maybe you should keep the type of the irq_sync here so that it properly
> > propagates to the call to devm_request_irq().
>
> I'm not sure what you mean. Do you mean that I should use unsigned int,
> as that's the type used in devm_request_irq()?
Yes.
> >> +void host1x_intr_stop(struct host1x_intr *intr)
> >> +{
> >> + unsigned int id;
> >> + struct host1x *host1x = intr_to_host1x(intr);
> >> + struct host1x_intr_syncpt *syncpt;
> >> + u32 nb_pts = host1x_syncpt_nb_pts(intr_to_host1x(intr));
> >> +
> >> + mutex_lock(>mutex);
> >> +
> >> + host1x->intr_op.disable_all_syncpt_intrs(intr);
> >
> > I haven't commented on this everywhere, but I think this could benefit
> > from a wrapper that forwards this to the intr_op. The same goes for the
> > sync_op.
>
> You mean something like "host1x_disable_all_syncpt_intrs"?
Yes. I think that'd be useful for each of the op functions. Perhaps you
could even pass in a struct host1x * to make calls more uniform.
> >> +/*
> >> + * Main entrypoint for syncpoint value waits.
> >> + */
> >> +int host1x_syncpt_wait(struct host1x_syncpt *sp,
> >> + u32 thresh, long timeout, u32 *value)
> >> +{
> > [...]
> >> +}
> >> +EXPORT_SYMBOL(host1x_syncpt_wait);
> >
> > This doesn't only seem to be the main entrypoint, but it's basically the
> > only way to currently wait for syncpoints. One actual use-case where
> > this might turn out to be a problem is video capturing. The problem is
> > that using this API you can't very well asynchronously capture frames.
> > So eventually I think we need a way to allow a generic handler to be
> > attached to syncpoints so that you can have this handler continuously
> > invoked after each frame is captured and just pass the buffer back to
> > userspace.
>
> Yep, so far all asynchronous waits have been done in user space. We
> would probably allow attaching a handler to a syncpt value, so that we'd
> call that handler once a value is reached. In effect, similar to a
> wake_up event that is now added via host1x_intr_add_action, but simpler.
> That'd mean that the handler needs to be re-added after each frame.
>
> We could also add the handler as persistent if re-adding would be a
> problem. That'd require some new wiring and I'll have to think how to
> implement that.
Yes, that sounds like what I had in mind. Again, no need to worry about
it now. We can cross that bridge when we come to it.
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/20130205/e1507241/attachment-0001.pgp>
[Bug 60294] Flashplayer crashing
https://bugs.freedesktop.org/show_bug.cgi?id=60294 Michel D?nzer changed: What|Removed |Added Assignee|mesa-dev at lists.freedesktop. |dri-devel at lists.freedesktop |org |.org Component|Other |Drivers/Gallium/r600 --- Comment #9 from Michel D?nzer --- Does setting the environment variable R600_LLVM=0 or building Mesa without --enable-r600-llvm-compiler work around the problem? -- 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/20130205/b02ccf44/attachment.html>
[Bug 60302] piglit failures r600g radeon hd 6850
https://bugs.freedesktop.org/show_bug.cgi?id=60302 Michel D?nzer changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |WONTFIX --- Comment #1 from Michel D?nzer --- It's unrealistic to expect all piglit tests to pass, so I'm afraid this report isn't useful. Piglit is mostly useful in two ways: * Regression testing, i.e. when a certain test used to pass but now fails, it's good to try and get to the bottom of that and fix it. * Specific tests reproducing failures which also affect real world apps. It's usually easier to fix problems by investigating piglit tests than more complex apps. In both cases though, individual bugs should be reported for specific tests, not a single one for all results as a whole. -- 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/20130205/1d9137e4/attachment.html>
[PATCHv5,RESEND 1/8] gpu: host1x: Add host1x driver
because host1x tracks the range of sync point > increments that hardware is still going to do, so min is the lower > boundary of the range. > > max tells what the sync point is expected to reach for hardware to be > considered idle. > > host1x will f.ex. nop out waits for sync point values outside the range, > because hardware isn't good at handling syncpt value wrapping. Maybe the function should be called host1x_syncpt_load() if there is no equivalent way to load the maximum value (since there is no register to read from). > > Also the syncpoint is not actually allocated here, so maybe > > host1x_syncpt_request() would be a better name. As a nice side-effect it > > makes the naming more similar to the IRQ API and might be easier to work > > with. > > I'm not entirely sure about the difference, but isn't the number to be > allocated usually passed to a function ending in _request? Allocate > would just allocate the next available - as host1x_syncpt_allocate does. That's certainly true for interrupts. However, if you look at the DMA subsystem for example, you can also request an unnamed resource. The difference is sufficiently subtle that host1x_syncpt_allocate() would work for me too, though. I just have a slight preference for host1x_syncpt_request(). 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/20130205/9e8c64e1/attachment-0001.pgp>
[Bug 60302] New: piglit failures r600g radeon hd 6850
https://bugs.freedesktop.org/show_bug.cgi?id=60302 Priority: medium Bug ID: 60302 Assignee: dri-devel at lists.freedesktop.org Summary: piglit failures r600g radeon hd 6850 Severity: normal Classification: Unclassified OS: Linux (All) Reporter: corey at octayn.net Hardware: x86-64 (AMD64) Status: NEW Version: git Component: Drivers/Gallium/r600 Product: Mesa Ran piglet (d2250db) on the 9.1 branch (1003652). Kernel 3.8-rc5 Results available at: http://octayn.net/9.1-piglit Any additional information I can provide, let me know (should I run it on 9.0 stable to provide baseline maybe?) -- 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/20130205/525a2158/attachment-0001.html>
[Bug 59672] Problems initializing Radeon driver: lockup during IB test
https://bugs.freedesktop.org/show_bug.cgi?id=59672 Alex Deucher changed: What|Removed |Added Status|REOPENED|RESOLVED Resolution|--- |FIXED -- 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/20130205/ef51c59f/attachment.html>
[Bug 59672] Problems initializing Radeon driver: lockup during IB test
https://bugs.freedesktop.org/show_bug.cgi?id=59672 Florian Mickler changed: What|Removed |Added CC||florian at mickler.org --- Comment #11 from Florian Mickler --- A patch referencing this bug report has been merged in Linux v3.8-rc6: commit b3dfcb207e550dffb8680cab7afaf6b4fb6eae33 Author: Michel D??nzer Date: Thu Jan 24 19:02:01 2013 +0100 drm/radeon: Enable DMA_IB_SWAP_ENABLE on big endian hosts. -- 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/20130205/45cc455f/attachment.html>
Re: [PATCHv5,RESEND 1/8] gpu: host1x: Add host1x driver
On Mon, Feb 04, 2013 at 07:30:08PM -0800, Terje Bergström wrote:
On 04.02.2013 01:09, Thierry Reding wrote:
On Tue, Jan 15, 2013 at 01:43:57PM +0200, Terje Bergstrom wrote:
Add host1x, the driver for host1x and its client unit 2D.
Maybe this could be a bit more verbose. Perhaps describe what host1x is.
Sure. I could just steal the paragraph from Stephen:
The Tegra host1x module is the DMA engine for register access to Tegra's
graphics- and multimedia-related modules. The modules served by host1x
are referred to as clients. host1x includes some other functionality,
such as synchronization.
Yes, that sound good.
+ err = host1x_syncpt_init(host);
+ if (err)
+ return err;
[...]
+ host1x_syncpt_reset(host);
Why separate host1x_syncpt_reset() from host1x_syncpt_init()? I see why
it might be useful to have host1x_syncpt_reset() as a separate function
but couldn't it be called as part of host1x_syncpt_init()?
host1x_syncpt_init() is used for initializing the syncpt structures, and
is called in probe. host1x_syncpt_reset() should be called whenever we
think hardware state is lost, for example if VDD_CORE was rail gated due
to system suspend.
My point was that you could include the call to host1x_syncpt_reset()
within host1x_syncpt_init(). That will keep unneeded code out of the
host1x_probe() function. Also you don't want to use the syncpoints
uninitialized, right?
+#include hw/syncpt_hw.c
Why include the source file here? Can't you compile it separately
instead?
It's because we need to compile with the hardware headers of that host1x
version, because we haven't been good at keeping compatibility. So
host1x01.c #includes version 01 headers, and syncpt_hw.c in this
compilation unit gets compiled with that. 02 would include 02 headers,
and syncpt_hw.c would get compiled with its register definitions etc.
Okay, fair enough.
+ */
+static u32 syncpt_load_min(struct host1x_syncpt *sp)
+{
+ struct host1x *dev = sp-dev;
+ u32 old, live;
+
+ do {
+ old = host1x_syncpt_read_min(sp);
+ live = host1x_sync_readl(dev,
+ HOST1X_SYNC_SYNCPT_0 + sp-id * 4);
+ } while ((u32)atomic_cmpxchg(sp-min_val, old, live) != old);
I think this warrants a comment.
Sure. It just loops in case there's a race writing to min_val.
Oh, I see. That'd make a good comment. Is the cast to (u32) really
necessary?
+/*
+ * Resets syncpoint and waitbase values to sw shadows
+ */
+void host1x_syncpt_reset(struct host1x *dev)
Maybe host1x_syncpt_flush() would be a better name given the above
description? Reset does have this hardware reset connotation so my first
intuition had been that this would reset the syncpt value to 0.
Right, it actually reloads values stored in shadow registers back to
host1x. Flush doesn't feel like it's conveying the meaning. Would
host1x_syncpt_restore() work? That'd match with host1x_syncpt_save(),
which just updates all shadow registers from hardware and is used just
before host1x loses power.
Save/restore has the disadvantage of the direction not being implicit.
Save could mean save to hardware or save to software. The same is true
for restore. However if the direction is clearly defined, save and
restore work for me.
Maybe the comment could be changed to be more explicit. Something like:
/*
* Write cached syncpoint and waitbase values to hardware.
*/
And for host1x_syncpt_save():
/*
* For client-managed registers, update the cached syncpoint and
* waitbase values by reading from the registers.
*/
+/*
+ * Updates the last value read from hardware.
+ */
+u32 host1x_syncpt_load_min(struct host1x_syncpt *sp)
+{
+ u32 val;
+ val = sp-dev-syncpt_op.load_min(sp);
+ trace_host1x_syncpt_load_min(sp-id, val);
+
+ return val;
+}
I don't know I understand what this means exactly. Does it read the
value that hardware last incremented? Perhaps this will become clearer
when you add a comment to the syncpt_load_min() implementation.
It just loads the current syncpt value to shadow register. The shadow
register is called min, because host1x tracks the range of sync point
increments that hardware is still going to do, so min is the lower
boundary of the range.
max tells what the sync point is expected to reach for hardware to be
considered idle.
host1x will f.ex. nop out waits for sync point values outside the range,
because hardware isn't good at handling syncpt value wrapping.
Maybe the function should be called host1x_syncpt_load() if there is no
equivalent way to load the maximum value (since there is no register to
read from).
Also the syncpoint is not actually allocated here, so maybe
host1x_syncpt_request() would be a better name. As a nice side-effect it
makes the naming more similar to the
Re: [PATCH 2/2] drm/exynos: Add device tree based discovery support for G2D
Hi Inki, On 2013년 02월 05일 12:03, Inki Dae wrote: 2013/2/4 Sachin Kamat sachin.ka...@linaro.org: On 1 February 2013 18:28, Inki Dae daei...@gmail.com wrote: 2013. 2. 1. 오후 8:52 Inki Dae inki@samsung.com 작성: -Original Message- From: linux-media-ow...@vger.kernel.org [mailto:linux-media- ow...@vger.kernel.org] On Behalf Of Sachin Kamat Sent: Friday, February 01, 2013 8:40 PM To: Inki Dae Cc: Sylwester Nawrocki; Kukjin Kim; Sylwester Nawrocki; linux- me...@vger.kernel.org; dri-devel@lists.freedesktop.org; devicetree- disc...@lists.ozlabs.org; patc...@linaro.org Subject: Re: [PATCH 2/2] drm/exynos: Add device tree based discovery support for G2D On 1 February 2013 17:02, Inki Dae inki@samsung.com wrote: How about using like below? Compatible = samsung,exynos4x12-fimg-2d /* for Exynos4212, Exynos4412 */ It looks odd to use samsung,exynos4212-fimg-2d saying that this ip is for exynos4212 and exynos4412. AFAIK, compatible strings are not supposed to have any wildcard characters. Compatible string should suggest the first SoC that contained this IP. Hence IMO 4212 is OK. Oops, one more thing. AFAIK Exynos4210 also has fimg-2d ip. In this case, we should use samsung,exynos4210-fimg-2d as comparible string and add it to exynos4210.dtsi? Exynos4210 has same g2d IP (v3.0) as C110 or V210; so the same comptible string will be used for this one too. And please check if exynos4212 and 4412 SoCs have same fimg-2d ip. If it's different, we might need to add ip version property or compatible string to each dtsi file to identify the ip version. AFAIK, they both have the same IP (v4.1). Ok, let's use the below, For exynos4210 SoC, compatible = samsung,exynos4210-g2d For exynos4x12 SoCs, compatible = samsung,exynos4212-g2d For exynos5250, 5410 (In case of Exynos5440, I'm not sure that the SoC has same ip) compatible = samsung,exynos5250-g2d To other guys, The device tree is used by not only v4l2 side but also drm side so we should reach an arrangement. So please give me ack if you agree to my opinion. Otherwise please, give me your opinions. This seems good to me. Best Regards, - Seung-Woo Kim Thanks, Inki Dae Sorry but give me your opinions. Thanks, Inki Dae Got it. Please post it again. -- With warm regards, Sachin -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel -- With warm regards, Sachin ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel -- Seung-Woo Kim Samsung Software RD Center -- ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 2/2] drm/exynos: Add device tree based discovery support for G2D
On 02/05/2013 12:03 PM, Inki Dae wrote: 2013/2/4 Sachin Kamat sachin.ka...@linaro.org: On 1 February 2013 18:28, Inki Dae daei...@gmail.com wrote: 2013. 2. 1. 오후 8:52 Inki Dae inki@samsung.com 작성: -Original Message- From: linux-media-ow...@vger.kernel.org [mailto:linux-media- ow...@vger.kernel.org] On Behalf Of Sachin Kamat Sent: Friday, February 01, 2013 8:40 PM To: Inki Dae Cc: Sylwester Nawrocki; Kukjin Kim; Sylwester Nawrocki; linux- me...@vger.kernel.org; dri-devel@lists.freedesktop.org; devicetree- disc...@lists.ozlabs.org; patc...@linaro.org Subject: Re: [PATCH 2/2] drm/exynos: Add device tree based discovery support for G2D On 1 February 2013 17:02, Inki Dae inki@samsung.com wrote: How about using like below? Compatible = samsung,exynos4x12-fimg-2d /* for Exynos4212, Exynos4412 */ It looks odd to use samsung,exynos4212-fimg-2d saying that this ip is for exynos4212 and exynos4412. AFAIK, compatible strings are not supposed to have any wildcard characters. Compatible string should suggest the first SoC that contained this IP. Hence IMO 4212 is OK. Oops, one more thing. AFAIK Exynos4210 also has fimg-2d ip. In this case, we should use samsung,exynos4210-fimg-2d as comparible string and add it to exynos4210.dtsi? Exynos4210 has same g2d IP (v3.0) as C110 or V210; so the same comptible string will be used for this one too. And please check if exynos4212 and 4412 SoCs have same fimg-2d ip. If it's different, we might need to add ip version property or compatible string to each dtsi file to identify the ip version. AFAIK, they both have the same IP (v4.1). Ok, let's use the below, For exynos4210 SoC, compatible = samsung,exynos4210-g2d For exynos4x12 SoCs, compatible = samsung,exynos4212-g2d For exynos5250, 5410 (In case of Exynos5440, I'm not sure that the SoC has same ip) compatible = samsung,exynos5250-g2d To other guys, The device tree is used by not only v4l2 side but also drm side so we should reach an arrangement. So please give me ack if you agree to my opinion. Otherwise please, give me your opinions. I like this compatible, also we can use rule like this to HDMI of drm/exynos. Thanks, Inki Dae Sorry but give me your opinions. Thanks, Inki Dae Got it. Please post it again. -- With warm regards, Sachin -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel -- With warm regards, Sachin ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCHv5,RESEND 2/8] gpu: host1x: Add syncpoint wait and interrupts
On Mon, Feb 04, 2013 at 08:29:08PM -0800, Terje Bergström wrote:
On 04.02.2013 02:30, Thierry Reding wrote:
diff --git a/drivers/gpu/host1x/dev.h b/drivers/gpu/host1x/dev.h
index d8f5979..8376092 100644
--- a/drivers/gpu/host1x/dev.h
+++ b/drivers/gpu/host1x/dev.h
@@ -17,11 +17,12 @@
#ifndef HOST1X_DEV_H
#define HOST1X_DEV_H
+#include linux/platform_device.h
#include syncpt.h
+#include intr.h
struct host1x;
struct host1x_syncpt;
-struct platform_device;
Why include platform_device.h here?
host1x_get_host() actually needs that, so this #include should've also
been in previous patch.
No need to if you pass struct device * instead. You might need
linux/device.h instead, though.
+ void (*set_syncpt_threshold)(
+ struct host1x_intr *, u32 id, u32 thresh);
+ void (*enable_syncpt_intr)(struct host1x_intr *, u32 id);
+ void (*disable_syncpt_intr)(struct host1x_intr *, u32 id);
+ void (*disable_all_syncpt_intrs)(struct host1x_intr *);
Can disable_all_syncpt_intrs() not be implemented generically using the
number of syncpoints as exposed by host1x_device_info and the
.disable_syncpt_intr() function?
disable_all_syncpt_intrs() disables all interrupts in one write (or one
per 32 sync points), so it's more efficient.
Yes, I noticed that and failed to remove this comment.
+{
+ struct host1x_intr_syncpt *sp =
+ container_of(work, struct host1x_intr_syncpt, work);
+ host1x_syncpt_thresh_fn(sp);
Couldn't we inline the host1x_syncpt_thresh_fn() implementation here?
Why do we need to go through an external function declaration?
If I move syncpt_thresh_work() to intr.c from intr_hw.c, I could do
that. That'd simplify the interrupt path.
I like simplification. =)
+static irqreturn_t syncpt_thresh_cascade_isr(int irq, void *dev_id)
+{
+ struct host1x *host1x = dev_id;
+ struct host1x_intr *intr = host1x-intr;
+ unsigned long reg;
+ int i, id;
+
+ for (i = 0; i host1x-info.nb_pts / BITS_PER_LONG; i++) {
+ reg = host1x_sync_readl(host1x,
+ HOST1X_SYNC_SYNCPT_THRESH_CPU0_INT_STATUS +
+ i * REGISTER_STRIDE);
+ for_each_set_bit(id, reg, BITS_PER_LONG) {
+ struct host1x_intr_syncpt *sp =
+ intr-syncpt + (i * BITS_PER_LONG + id);
+ host1x_intr_syncpt_thresh_isr(sp);
Have you considered mimicking the IRQ API and name this something like
host1x_intr_syncpt_thresh_handle() and name the actual ISR just
syncpt_thresh_isr()? Not so important but it makes things a bit clearer
in my opinion.
This gets a bit confusing, because we have an ISR that calls a function
that is also called ISR. I've kept isr in names of both to emphasize
that this is running in interrupt context. I'm open to renaming these to
make it clearer.
Did you refer to chained IRQ handler in linux/irq.h when you mentioned
IRQ API as reference for naming?
What I had in mind was more along the lines of kernel/irq/chip.c, which
has a bunch of handlers for various types of interrupts, such as
handle_nested_irq() or handle_simple_irq().
Hence my proposal to rename host1x_intr_syncpt_thresh_isr() to
host1x_intr_syncpt_handle() because it handles the interrupt from a
single syncpoint and syncpt_thresh_cascade_isr() to syncpt_thresh_isr()
to keep it shorter.
Another variant would be host1x_syncpt_irq() for the top-level handler
and something host1x_handle_syncpt() to handle individual syncpoints. I
like this one best, but this is pure bike-shedding and there's nothing
technically wrong with the names you chose, so I can't really object if
you want to stick to them.
+ queue_work(intr-wq, sp-work);
Should the call to queue_work() perhaps be moved into
host1x_intr_syncpt_thresh_isr().
I'm not sure, either way would be ok to me. The current structure allows
host1x_intr_syncpt_thresh_isr() to only take one parameter
(host1x_intr_syncpt). If we move queue_work, we'd also need to pass
host1x_intr.
I think I'd still prefer to have all the code in one function because it
make subsequent modification easier and less error-prone.
+static void host1x_intr_init_host_sync(struct host1x_intr *intr)
+{
+ struct host1x *host1x = intr_to_host1x(intr);
+ int i, err;
+
+ host1x_sync_writel(host1x, 0xUL,
+ HOST1X_SYNC_SYNCPT_THRESH_INT_DISABLE);
+ host1x_sync_writel(host1x, 0xUL,
+ HOST1X_SYNC_SYNCPT_THRESH_CPU0_INT_STATUS);
+
+ for (i = 0; i host1x-info.nb_pts; i++)
+ INIT_WORK(intr-syncpt[i].work, syncpt_thresh_cascade_fn);
+
+ err = devm_request_irq(host1x-dev-dev, intr-syncpt_irq,
+ syncpt_thresh_cascade_isr,
+ IRQF_SHARED, host1x_syncpt,
[Bug 60302] piglit failures r600g radeon hd 6850
https://bugs.freedesktop.org/show_bug.cgi?id=60302 Michel Dänzer mic...@daenzer.net changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |WONTFIX --- Comment #1 from Michel Dänzer mic...@daenzer.net --- It's unrealistic to expect all piglit tests to pass, so I'm afraid this report isn't useful. Piglit is mostly useful in two ways: * Regression testing, i.e. when a certain test used to pass but now fails, it's good to try and get to the bottom of that and fix it. * Specific tests reproducing failures which also affect real world apps. It's usually easier to fix problems by investigating piglit tests than more complex apps. In both cases though, individual bugs should be reported for specific tests, not a single one for all results as a whole. -- You are receiving this mail because: You are the assignee for the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCHv5,RESEND 4/8] gpu: host1x: Add debug support
On Mon, Feb 04, 2013 at 08:41:25PM -0800, Terje Bergström wrote:
On 04.02.2013 03:03, Thierry Reding wrote:
On Tue, Jan 15, 2013 at 01:44:00PM +0200, Terje Bergstrom wrote:
diff --git a/drivers/gpu/host1x/debug.h b/drivers/gpu/host1x/debug.h
[...]
+struct output {
+ void (*fn)(void *ctx, const char *str, size_t len);
+ void *ctx;
+ char buf[256];
+};
Do we really need this kind of abstraction? There really should be only
one location where debug information is obtained, so I don't see a need
for this.
This is used by debugfs code to direct to debugfs, and
nvhost_debug_dump() to send via printk.
Yes, that was precisely my point. Why bother providing the same data via
several output methods. debugfs is good for showing large amounts of
data such as register dumps or a tabular representation of syncpoints
for instance.
If, however, you want to interactively show debug information using
printk the same format isn't very useful and something more reduced is
often better.
diff --git a/drivers/gpu/host1x/hw/debug_hw.c
b/drivers/gpu/host1x/hw/debug_hw.c
+static int show_channel_command(struct output *o, u32 addr, u32 val, int
*count)
+{
+ unsigned mask;
+ unsigned subop;
+
+ switch (val 28) {
+ case 0x0:
These can easily be derived by looking at the debug output, but it may
still make sense to assign symbolic names to them.
I have another suggestion. In downstream I removed the decoding part and
I just print out a string of hex. That removes quite a bit bunch of code
from kernel. It makes the debug output also more compact.
It's much easier to write a user space program to decode than maintain
it in kernel.
I don't know. I think if you use in-kernel debugging facilities such as
debugfs or printk, then the output should be self-explanatory. However I
do see the usefulness of having a binary dump that can be decoded in
userspace. But I think if we want to go that way we should make that a
separate interface. USB provides something like that, which can then be
fed to libpcap or wireshark to capture and analyze USB traffic. If done
properly you get replay functionality for free. I don't know what infra-
structure exists to help with implementing something similar.
So I think having debugfs output some data about syncpoints or the state
of channels might be useful to quickly diagnose a certain set of
problems but for anything more involved maybe a complete binary dump may
be better.
I'm not sure whether doing this would be acceptable though. Maybe Dave
or somebody else on the lists can answer that. An alternative way to
achieve the same would be to hook ioctl() from userspace and not do any
of it in kernel space.
+static void show_channel_word(struct output *o, int *state, int *count,
+ u32 addr, u32 val, struct host1x_cdma *cdma)
+{
+ static int start_count, dont_print;
What if two processes read debug information at the same time?
show_channels() acquires cdma.lock, so that shouldn't happen.
Okay. Another solution would be to pass around a debug context which
keeps track of the variables. But if we opt for a more involved dump
interface as discussed above this will no longer be relevant.
+static void do_show_channel_gather(struct output *o,
+ phys_addr_t phys_addr,
+ u32 words, struct host1x_cdma *cdma,
+ phys_addr_t pin_addr, u32 *map_addr)
+{
+ /* Map dmaget cursor to corresponding mem handle */
+ u32 offset;
+ int state, count, i;
+
+ offset = phys_addr - pin_addr;
+ /*
+ * Sometimes we're given different hardware address to the same
+ * page - in these cases the offset will get an invalid number and
+ * we just have to bail out.
+ */
Why's that?
Because of a race - memory might've been unpinned and unmapped from
IOMMU and when we re-map (pin), we are given a new address.
But, I think this comment is a bit stale - we used to dump also old
gathers. The latest code only dumps jobs in sync queue, so the race
shouldn't happen.
Okay. In the context of a channel dump interface this may not be
relevant anymore. Can you think of any issue that wouldn't be detectable
or debuggable by analyzing a binary dump of the data within a channel?
I'm asking because at that point we wouldn't be able to access any of
the in-kernel data structures but would have to rely on the data itself
for diagnostics. IOMMU virtual addresses won't be available and so on.
+static void host1x_debug_show_channel_cdma(struct host1x *m,
+ struct host1x_channel *ch, struct output *o, int chid)
+{
[...]
+ switch (cbstat) {
+ case 0x00010008:
Again, symbolic names would be nice.
I propose I remove the decoding from kernel, and save 200 lines.
I think it could be more than 200 lines. If all we provide in the kernel
is some statistics about syncpoint usage or channel state that should be
a lot less code than we have now.
However that
[Bug 60294] Flashplayer crashing
https://bugs.freedesktop.org/show_bug.cgi?id=60294 Michel Dänzer mic...@daenzer.net changed: What|Removed |Added Assignee|mesa-dev@lists.freedesktop. |dri-devel@lists.freedesktop |org |.org Component|Other |Drivers/Gallium/r600 --- Comment #9 from Michel Dänzer mic...@daenzer.net --- Does setting the environment variable R600_LLVM=0 or building Mesa without --enable-r600-llvm-compiler work around the problem? -- You are receiving this mail because: You are the assignee for the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCHv5,RESEND 5/8] drm: tegra: Move drm to live under host1x
On Mon, Feb 04, 2013 at 08:45:36PM -0800, Terje Bergström wrote: On 04.02.2013 03:08, Thierry Reding wrote: * PGP Signed by an unknown key On Tue, Jan 15, 2013 at 01:44:01PM +0200, Terje Bergstrom wrote: [...] diff --git a/drivers/gpu/host1x/Makefile b/drivers/gpu/host1x/Makefile index 697d49a..ffc8bf1 100644 --- a/drivers/gpu/host1x/Makefile +++ b/drivers/gpu/host1x/Makefile @@ -12,4 +12,10 @@ host1x-y = \ hw/host1x01.o host1x-$(CONFIG_TEGRA_HOST1X_CMA) += cma.o + +ccflags-y += -Iinclude/drm +ccflags-$(CONFIG_DRM_TEGRA_DEBUG) += -DDEBUG + +host1x-$(CONFIG_DRM_TEGRA) += drm/drm.o drm/fb.o drm/dc.o drm/host1x.o +host1x-$(CONFIG_DRM_TEGRA) += drm/output.o drm/rgb.o drm/hdmi.o obj-$(CONFIG_TEGRA_HOST1X) += host1x.o Can this be moved into a separate Makefile in the drm subdirectory? I tried, and kernel build helpfully created two .ko files. As having cyclic dependencies between two modules isn't nice, I merged them to same module and that seemed to force merging Makefile. If anybody has an idea on how to do it otherwise, I'd be happy to keep the Makefiles separate. Okay, I'll take a look. Thierry pgpb41eYJssaV.pgp Description: PGP signature ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 2/2] drm/exynos: Add device tree based discovery support for G2D
On 02/05/2013 04:03 AM, Inki Dae wrote: [...] Exynos4210 has same g2d IP (v3.0) as C110 or V210; so the same comptible string will be used for this one too. And please check if exynos4212 and 4412 SoCs have same fimg-2d ip. If it's different, we might need to add ip version property or compatible string to each dtsi file to identify the ip version. AFAIK, they both have the same IP (v4.1). Ok, let's use the below, For exynos4210 SoC, compatible = samsung,exynos4210-g2d Since S5PV210 (Exynos3110 ??) seems to have same G2D IP, I guess something like samsung,s5pv210-g2d could be used for both S5PV210 (S5PC110) and Exynos4210 (S5PC210, S5PV310) ? I'm fine with using samsung,exynos4210-g2d for Exynos4210 though. For instance for tegra SoCs a conventions like nvidia,tegrachip-ip, is used (e.g. nvidia,tegra20-gr2d). For exynos4x12 SoCs, compatible = samsung,exynos4212-g2d I'm not sure how well exynos4212 is going to be supported in the kernel. As Mr Park pointed out, if it is going to be nearly not existent then we could perhaps go with samsung,exynos4412-g2d for Exynos4412 and samsung,exynos4212-g2d for Exynos4212 (as needed). Anyway, I fine with using samsung,exynos4212-g2d for both. I'd like to hear Mr Kim's opinion on this as well though. For exynos5250, 5410 (In case of Exynos5440, I'm not sure that the SoC has same ip) compatible = samsung,exynos5250-g2d To other guys, The device tree is used by not only v4l2 side but also drm side so we should reach an arrangement. So please give me ack if you agree to my opinion. Otherwise please, give me your opinions. It looks good to me, please just see the two remarks above. -- Regards, Sylwester ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v4 1/1] video: drm: exynos: Adds display-timing node parsing using video helper function
Dear Vikas,
thank you for the patch. Please send a fifth iteration with the
following changes to the commit message.
Am Dienstag, den 05.02.2013, 11:02 +0530 schrieb Vikas Sajjan:
The summary should not implicitly assume »patch« written before it. So
do not add third person s to »Add«.
video: drm: exynos: Add display-timing node parsing using video helper
function
This patch adds display-timing node parsing using video helper function
As this is the same as the summary you should leave it out. Also it is
good style not to use »This/The patch« in the commit message.
Please use the commit message to explain your change. For example the if
statement. Why is the original code put into the else branch and is not
needed if the first condition is true?
Signed-off-by: Leela Krishna Amudala l.kris...@samsung.com
Signed-off-by: Vikas Sajjan vikas.saj...@linaro.org
---
drivers/gpu/drm/exynos/exynos_drm_fimd.c | 41
+++---
1 file changed, 37 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/exynos/exynos_drm_fimd.c
b/drivers/gpu/drm/exynos/exynos_drm_fimd.c
index bf0d9ba..978e866 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_fimd.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_fimd.c
@@ -19,6 +19,7 @@
#include linux/clk.h
#include linux/of_device.h
#include linux/pm_runtime.h
+#include linux/pinctrl/consumer.h
#include video/samsung_fimd.h
#include drm/exynos_drm.h
@@ -905,16 +906,48 @@ static int __devinit fimd_probe(struct platform_device
*pdev)
struct exynos_drm_subdrv *subdrv;
struct exynos_drm_fimd_pdata *pdata;
struct exynos_drm_panel_info *panel;
+ struct fb_videomode *fbmode;
+ struct pinctrl *pctrl;
struct resource *res;
int win;
int ret = -EINVAL;
DRM_DEBUG_KMS(%s\n, __FILE__);
- pdata = pdev-dev.platform_data;
- if (!pdata) {
- dev_err(dev, no platform data specified\n);
- return -EINVAL;
+ if (pdev-dev.of_node) {
+ pdata = devm_kzalloc(dev, sizeof(*pdata), GFP_KERNEL);
+ if (!pdata) {
+ DRM_ERROR(memory allocation for pdata failed\n);
+ return -ENOMEM;
+ }
+
+ fbmode = devm_kzalloc(dev, sizeof(*fbmode), GFP_KERNEL);
+ if (!fbmode) {
+ DRM_ERROR(memory allocation for fbmode failed\n);
+ return -ENOMEM;
+ }
+
+ ret = of_get_fb_videomode(dev-of_node, fbmode, -1);
+ if (ret) {
+ DRM_ERROR(failed: of_get_fb_videomode() :
+ return value: %d\n, ret);
+ return ret;
+ }
+ pdata-panel.timing = (struct fb_videomode) *fbmode;
+
+ pctrl = devm_pinctrl_get_select_default(dev);
+ if (IS_ERR_OR_NULL(pctrl)) {
+ DRM_ERROR(failed: devm_pinctrl_get_select_default()
+ return value: %d\n, PTR_RET(pctrl));
+ return PTR_RET(pctrl);
+ }
+
+ } else {
+ pdata = pdev-dev.platform_data;
+ if (!pdata) {
+ DRM_ERROR(no platform data specified\n);
+ return -EINVAL;
+ }
}
panel = pdata-panel;
Thanks,
Paul
signature.asc
Description: This is a digitally signed message part
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCHv5,RESEND 8/8] drm: tegra: Add gr2d device
On Mon, Feb 04, 2013 at 09:17:45PM -0800, Terje Bergström wrote:
On 04.02.2013 04:56, Thierry Reding wrote:
On Tue, Jan 15, 2013 at 01:44:04PM +0200, Terje Bergstrom wrote:
+{
+ struct host1x *host1x = drm-dev_private;
+ struct tegra_drm_syncpt_read_args *args = data;
+ struct host1x_syncpt *sp =
+ host1x_syncpt_get_bydev(host1x-dev, args-id);
I don't know if we need this, except maybe to work around the problem
that we have two different structures named host1x. The _bydev() suffix
is misleading because all you really do here is obtain the syncpt from
the host1x.
Yeah, it's actually working around the host1x duplicate naming.
host1x_syncpt_get takes struct host1x as parameter, but that's different
host1x than in this code.
So maybe a better way would be to rename the DRM host1x after all. If it
avoids the need for workarounds such as this I think it justifies the
additional churn.
Also, how useful is it to create a context? Looking at the gr2d
implementation for .open_channel(), it will return the same channel to
whichever userspace process requests them. Can you explain why it is
necessary at all? From the name I would have expected some kind of
context switching to take place when different applications submit
requests to the same client, but that doesn't seem to be the case.
Hardware context switching will be a later submit, and it'll actually
create a new structure. Hardware context might live longer than the
process that created it, so they'll need to be separate.
Why would it live longer than the process? Isn't the whole purpose of
the context to keep per-process state? What use is that state if the
process dies?
We've used the context as a place for storing flags and the reference to
hardware context. It'd allow also opening channels to multiple devices,
and context would be used in submit to find out the target device. But
as hardware context switching is not implemented in this patch set, and
neither is support for anything but 2D, it's difficult to justify it.
Perhaps the justification is that this way we can keep the kernel API
stable even when we add support for hardware contexts and other clients.
We don't need a stable kernel API. But I guess it is fine to keep it if
for no other reason to fill the context returned in the ioctl() with
meaningful data.
diff --git a/drivers/gpu/host1x/drm/drm.h b/drivers/gpu/host1x/drm/drm.h
[...]
+struct host1x_drm_fpriv {
+ struct list_head contexts;
};
Maybe name this host1x_drm_file. fpriv isn't very specific.
host1x_drm_file sounds a bit odd, because it's not really a file, but a
private data pointer stored in driver_priv.
The same is true for struct drm_file, which is stored in struct file's
.private_data field. I find it to be very intuitive if the inheritance
is reflected in the structure name. struct host1x_drm_file is host1x'
driver-specific part of struct drm_file.
+static u32 handle_cma_to_host1x(struct drm_device *drm,
+ struct drm_file *file_priv, u32 gem_handle)
+{
+ struct drm_gem_object *obj;
+ struct drm_gem_cma_object *cma_obj;
+ u32 host1x_handle;
+
+ obj = drm_gem_object_lookup(drm, file_priv, gem_handle);
+ if (!obj)
+ return 0;
+
+ cma_obj = to_drm_gem_cma_obj(obj);
+ host1x_handle = host1x_memmgr_host1x_id(mem_mgr_type_cma,
(u32)cma_obj);
+ drm_gem_object_unreference(obj);
+
+ return host1x_handle;
+}
I though we had settled in previous reviews on only having a single
allocator and not do the conversion between various types?
I'll need to agree with Lucas on how to handle this. He intended to make
a patch to fix this, but he hasn't had time to do that.
But, I'd still like to keep the possibility open to add dma_buf as
memory handle type, and fit that into the same API, so there's still a
need to have the mem_mgr_type abstraction.
I fail to see how dma_buf would require a separate mem_mgr_type. Can we
perhaps postpone this to a later point and just go with CMA as the only
alternative for now until we have an actual working implementation that
we can use this for?
+static int gr2d_submit(struct host1x_drm_context *context,
+ struct tegra_drm_submit_args *args,
+ struct drm_device *drm,
+ struct drm_file *file_priv)
+{
+ struct host1x_job *job;
+ int num_cmdbufs = args-num_cmdbufs;
+ int num_relocs = args-num_relocs;
+ int num_waitchks = args-num_waitchks;
+ struct tegra_drm_cmdbuf __user *cmdbufs =
+ (void * __user)(uintptr_t)args-cmdbufs;
+ struct tegra_drm_reloc __user *relocs =
+ (void * __user)(uintptr_t)args-relocs;
+ struct tegra_drm_waitchk __user *waitchks =
+ (void * __user)(uintptr_t)args-waitchks;
No need for all the uintptr_t casts.
Will try to remove -
[PATCH] drm/nouveau: fix lockdep splat in display
Add a flag NVOBJ_FLAG_CREAT_EXCL, which will make sure that only 1 engctx will
be created.
This removes the need of having multiple
Fixes the following lockdep splat:
=
[ INFO: possible recursive locking detected ]
3.8.0-rc6-ninja+ #1 Not tainted
-
modprobe/585 is trying to acquire lock:
(subdev-mutex){+.+.+.}, at: [a016c323]
nouveau_instobj_create_+0x43/0x90 [nouveau]
but task is already holding lock:
(subdev-mutex){+.+.+.}, at: [a017672d]
nv50_disp_data_ctor+0x5d/0xd0 [nouveau]
other info that might help us debug this:
Possible unsafe locking scenario:
CPU0
lock(subdev-mutex);
lock(subdev-mutex);
*** DEADLOCK ***
May be due to missing lock nesting notation
4 locks held by modprobe/585:
#0: (__lockdep_no_validate__){..}, at: [813075f3]
__driver_attach+0x53/0xb0
#1: (__lockdep_no_validate__){..}, at: [81307601]
__driver_attach+0x61/0xb0
#2: (drm_global_mutex){+.+.+.}, at: [812ee59c]
drm_get_pci_dev+0xbc/0x2b0
#3: (subdev-mutex){+.+.+.}, at: [a017672d]
nv50_disp_data_ctor+0x5d/0xd0 [nouveau]
stack backtrace:
Pid: 585, comm: modprobe Not tainted 3.8.0-rc6-expert+ #1
Call Trace:
[8108fde2] validate_chain.isra.33+0xd72/0x10d0
[8105fa08] ? __kernel_text_address+0x58/0x80
[8100575d] ? print_context_stack+0x5d/0xd0
[81090bc1] __lock_acquire+0x3a1/0xb60
[8108d504] ? __lock_is_held+0x54/0x80
[8109184a] lock_acquire+0x5a/0x70
[a016c323] ? nouveau_instobj_create_+0x43/0x90 [nouveau]
[81558739] mutex_lock_nested+0x69/0x340
[a016c323] ? nouveau_instobj_create_+0x43/0x90 [nouveau]
[a0152370] ? nouveau_object_create_+0x60/0xa0 [nouveau]
[a016c323] nouveau_instobj_create_+0x43/0x90 [nouveau]
[a016cf8c] nv50_instobj_ctor+0x4c/0xf0 [nouveau]
[a0152163] nouveau_object_ctor+0x33/0xc0 [nouveau]
[a016cd51] nv50_instmem_alloc+0x21/0x30 [nouveau]
[a0150917] nouveau_gpuobj_create_+0x247/0x2f0 [nouveau]
[8155b35a] ? _raw_spin_unlock_irqrestore+0x3a/0x70
[810921fd] ? trace_hardirqs_on_caller+0x10d/0x1a0
[a014f4bc] nouveau_engctx_create_+0x25c/0x2a0 [nouveau]
[a0176791] nv50_disp_data_ctor+0xc1/0xd0 [nouveau]
[a0153722] ? nouveau_subdev_reset+0x52/0x60 [nouveau]
[a0152163] nouveau_object_ctor+0x33/0xc0 [nouveau]
[a0152a42] nouveau_object_new+0x112/0x240 [nouveau]
[a01f4b1d] nv50_display_create+0x18d/0x860 [nouveau]
[8105cb5d] ? __cancel_work_timer+0x6d/0xc0
[a01db8eb] nouveau_display_create+0x3cb/0x670 [nouveau]
[a01cb1bf] nouveau_drm_load+0x26f/0x590 [nouveau]
[81304c99] ? device_register+0x19/0x20
[812efe91] ? drm_sysfs_device_add+0x81/0xb0
[812ee65e] drm_get_pci_dev+0x17e/0x2b0
[81245e56] ? __pci_set_master+0x26/0x80
[a01cab2a] nouveau_drm_probe+0x25a/0x2a0 [nouveau]
[8124a386] local_pci_probe+0x46/0x80
[8124ac11] pci_device_probe+0x101/0x110
[813073d6] driver_probe_device+0x76/0x240
[81307643] __driver_attach+0xa3/0xb0
[813075a0] ? driver_probe_device+0x240/0x240
[8130564d] bus_for_each_dev+0x4d/0x90
[81306f39] driver_attach+0x19/0x20
[81306af0] bus_add_driver+0x1a0/0x270
[a023d000] ? 0xa023cfff
[81307cd2] driver_register+0x72/0x170
[a023d000] ? 0xa023cfff
[8124ad0f] __pci_register_driver+0x5f/0x70
[812ee8a5] drm_pci_init+0x115/0x130
[a023d000] ? 0xa023cfff
[a023d000] ? 0xa023cfff
[a023d04d] nouveau_drm_init+0x4d/0x1000 [nouveau]
[810002da] do_one_initcall+0x11a/0x170
[8109d044] load_module+0xe84/0x1470
[81098c30] ? in_lock_functions+0x20/0x20
[8122c22e] ? trace_hardirqs_on_thunk+0x3a/0x3f
[8109d6e7] sys_init_module+0xb7/0xe0
[8155c156] system_call_fastpath+0x1a/0x1f
Reported-by: Arend van Spriel ar...@broadcom.com
Reported-by: Peter Hurley pe...@hurleysoftware.com
Reported-by: Daniel J Blueman dan...@quora.org
Signed-off-by: Maarten Lankhorst maarten.lankho...@canonical.com
---
XXX: Add Cc: sta...@kernel.org if it applies to 3.7 ?
diff --git a/drivers/gpu/drm/nouveau/core/core/engctx.c
b/drivers/gpu/drm/nouveau/core/core/engctx.c
index 84c71fa..4a0ab2b 100644
--- a/drivers/gpu/drm/nouveau/core/core/engctx.c
+++ b/drivers/gpu/drm/nouveau/core/core/engctx.c
@@ -31,12 +31,15 @@
#include subdev/vm.h
static inline int
-nouveau_engctx_exists(struct nouveau_object *parent,
+nouveau_engctx_exists(struct nouveau_object *parent, u32 flags,
struct nouveau_engine *engine, void **pobject)
{
struct nouveau_engctx *engctx;
struct nouveau_object *parctx;
+ if ((flags NVOBJ_FLAG_CREAT_EXCL)
[pull] drm-intel-next for 3.9
Hi Dave,
Probably the last feature pull for 3.9, there's some fixes outstanding
thought that I'd like to sneak in. And maybe 3.8 takes a bit longer ...
Anyway, highlights of this pull:
- Kill the horrible IS_DISPLAYREG hack to handle the mmio offset movements
on vlv, big thanks to Ville.
- Dynamic power well support for Haswell, shaves away a bit when only
using the eDP port on pipe A (Paulo). Plus unclaimed register fixes
uncovered by this.
- Clarifications of the gpu hang/reset state transitions, hopefully fixing
a few spurious -EIO deaths in userspace.
- Haswell ELD fixes.
- Some more (pp)gtt cleanups from Ben.
- A few smaller things all over.
Plus all the stuff from the previous rather small pull request:
- Broadcast RBG improvements and reduced color range fixes from Ville.
- Ben is on a kill legacy gtt code for good spree, first pile of patches
included.
- No-relocs and bo lut improvements for faster execbuf from Chris.
- Some refactorings from Imre.
QA filed tons of bugs this cycle, all due to us finally enabling all the
really anal timestamp and vblank counter checks in kms_flip, now that the
locking is fixed and EDID reads don't cause stalls any more. In short, our
vblank code seems to be ridiculously racy and broken :( Otoh that's not
really news.
Cheers, Daniel
The following changes since commit b5cc6c0387b2f8d269c1df1e68c97c958dd22fed:
Merge tag 'drm-intel-next-2012-12-21' of
git://people.freedesktop.org/~danvet/drm-intel into drm-next (2013-01-17
20:34:08 +1000)
are available in the git repository at:
git://people.freedesktop.org/~danvet/drm-intel tags/drm-intel-next-2013-02-01
for you to fetch changes up to 7d37beaaf3dbc6ff16f4d32a4dd6f8c557c6ab50:
GPU/i915: Fix acpi_bus_get_device() check in
drivers/gpu/drm/i915/intel_opregion.c (2013-02-01 11:01:50 +0100)
Ben Widawsky (16):
drm/i915: Kill gtt_end
drm/i915: Mappable_end can't ever be end
drm/i915: Remove gtt_mappable_total
drm/i915: Create a gtt structure
drm/i915: Remove use on gma_bus_addr on gen6+
drm/i915: Remove use of gtt_mappable_entries
drm/i915: Cut out the infamous ILK w/a from AGP layer
drm/i915: Remove scratch page from shared
drm/i915: Needs_dmar, not
agp/intel: Add gma_bus_addr
drm/i915: Implement WaVSRefCountFullforceMissDisable
drm/i915: Error state should print /sys/kernel/debug
drm/i915: Add probe and remove to the gtt ops
drm/i915: remove intel_gtt structure
drm/i915: Reclaim GTT space for failed PPGTT
drm/i915: Fix CAGF for HSW
Changlong Xie (1):
drm/i915: gen6_gmch_remove can be static
Chris Wilson (9):
drm/i915: Add a debug interface to forcibly evict and shrink our object
caches
drm/i915: Bail if we attempt to allocate pages for a purged object
drm/i915: Mark a temporary allocation for copy-from-user as such
drm/i915: Take the handle idr spinlock once for looking up the exec
objects
drm/i915: Move the execbuffer objects list from the stack into the tracker
drm/i915: Use the reloc.handle as an index into the execbuffer array
drm/i915: Only insert the mb() before updating the fence parameter
drm/i915: Only apply the mb() when flushing the GTT domain during a finish
drm/i915: Only run idle processing from i915_gem_retire_requests_worker
Daniel Vetter (21):
drm/i915: wake up all pageflip waiters
drm/i915: Allow userspace to hint that the relocations were known
drm/i915: move dev_priv-mm out of line
drm/i915: extract hangcheck/reset/error_state state into substruct
drm/i915: move wedged to the other gpu error handling stuff
drm/i915: fix reset handling in the throttle ioctl
drm/i915: clear up wedged transitions
drm/i915: create a race-free reset detection
drm/i915: clarify concurrent hang detect/gpu reset consistency
drm/i915: fixup sbi_read/write locking
drm/i915: move modeset checks out of save/restore_modeset_reg
drm/i915: extract ums suspend/resume into i915_ums.c
drm/i915: dont save/restore VGA state for kms
drm/i915: move DP save/restore into i915_ums.c
drm/i915: vfuncs for gtt_clear_range/insert_entries
drm/i915: vfuncs for ppgtt
drm/i915: pte_encode is gen6+
drm/i915: extract hw ppgtt setup/cleanup code
drm/i915: kill cargo-culted locking from power well code
drm/i915: don't run hsw power well code on !hsw
drm/i915: dynamic Haswell display power well support
Egbert Eich (1):
drm/i915: Remove pch_rq_mask from struct drm_i915_private.
Imre Deak (3):
drm/i915: merge get_gtt_alignment/get_unfenced_gtt_alignment()
drm/i915: merge {i965, sandybridge}_write_fence_reg()
drm/i915: use gtt_get_size() instead of open coding it
Jani Nikula (3):
drm/i915: add quirk to invert brightness on eMachines G725
[Bug 60236] corruption of text and bottom of screen in xonotic menus since 325422c49449acdd8df1eb2ca8ed81f7696c38cc
https://bugs.freedesktop.org/show_bug.cgi?id=60236 --- Comment #3 from Paul Heldens pheld...@ziggo.nl --- Created attachment 74238 -- https://bugs.freedesktop.org/attachment.cgi?id=74238action=edit screen shot Xonotic -- You are receiving this mail because: You are the assignee for the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 60236] corruption of text and bottom of screen in xonotic menus since 325422c49449acdd8df1eb2ca8ed81f7696c38cc
https://bugs.freedesktop.org/show_bug.cgi?id=60236 Paul Heldens pheld...@ziggo.nl changed: What|Removed |Added Attachment #74238|0 |1 is obsolete|| --- Comment #4 from Paul Heldens pheld...@ziggo.nl --- Created attachment 74239 -- https://bugs.freedesktop.org/attachment.cgi?id=74239action=edit screen shot Xonotic -- You are receiving this mail because: You are the assignee for the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 60302] piglit failures r600g radeon hd 6850
https://bugs.freedesktop.org/show_bug.cgi?id=60302 --- Comment #2 from Corey Richardson co...@octayn.net --- Good to know, thank you -- You are receiving this mail because: You are the assignee for the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[ANNOUNCE] libdrm 2.4.42
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Alex Deucher (2): radeon: add OLAND family radeon: add OLAND pci ids David Herrmann (1): man: fix manpage build instructions Jesse Barnes (1): intel: add more VLV PCI IDs Maarten Lankhorst (3): nouveau: use @PACKAGE_VERSION@ in libdrm_nouveau.pc libdrm: remove DISTCHECK_CONFIGURE_FLAGS configure.ac: bump version to 2.4.42 for release Michel Dänzer (1): radeon: Fix 1D tiling layout on SI. Thierry Reding (1): man: Fix typo and use $() for make expressions git tag: libdrm-2.4.42 http://dri.freedesktop.org/libdrm/libdrm-2.4.42.tar.bz2 MD5: a6e2e26951bcc920b2049b65e86a659f libdrm-2.4.42.tar.bz2 SHA1: 7004899b6a80b2ee50f35f883cc14804c3e24188 libdrm-2.4.42.tar.bz2 SHA256: e0671082a77871c8474d3c0f09dbf5ff82d2429cd248088a691f7b484cbc76e1 libdrm-2.4.42.tar.bz2 http://dri.freedesktop.org/libdrm/libdrm-2.4.42.tar.gz MD5: 5f430bab316083378a12b10d0e0fe1a3 libdrm-2.4.42.tar.gz SHA1: bf767be78ce7048e9a2e8fd3d7a79edea982ee4f libdrm-2.4.42.tar.gz SHA256: acb2a694071eb048328cd6b868265dc5de9ef27cab08f516f7a5740f2b15a0af libdrm-2.4.42.tar.gz -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) iQIcBAEBAgAGBQJREQZMAAoJEP5VjHKmcBPD3h8P/2ihE/OLOPHvMGNgcoPnCeFf xUz1UMHwSNwjffi4OgijBRdqcoKIees79ZgdIvbD9bvd4lMAOiNx4e2jWHmk+1Ps cvfoAmyrOP3iEi/m6yaMCbIkvKrmobDDSqpgMbNIK92lK+6Gb2mOcncJ6JFYydV2 AwNTvSsw3EqJMf/xkGXhNbRMkWfDRPE5IJg6uohYszTPyusLj7UHgc6IUotFoP+A MVwwcB+DK/rbFBKjt3Q6f4me35Fw4Y2rTwrF+OL24RzpxRczqeo93ni32pI4MzTA GX/WOFKN4R0x1BVXd9LTa7LCRzTzuFUupyNaOA8lqsFtsmgoU3b70FkXnGnHPiXs 7kWX0/lSP9gMYCpYGjY2i/b9BCDTPvOajxIWPRgFrk6W+eoQVvaeaaB3E6GX9em5 kcSLpuOZURMyLofN+bwRmWdHlp3FHM7wAL5KZK0s6YJiZhP/vRCdgf/s0XgnKfG2 oR9Q0fimScdeRMm2VNwbwZ/5AxCOZ2AjicppHh9lsscTXUQcPZwVPF3JL1PVsJOG r+DHdVsRRWzMPDfcfbkDYxTt1s8wRmd7Muk895lAvuqvX0nFidA1w3tdYF6/8dEB EKSGV5y/QMMdmK70Q9Nw8ueK/rSzL1n94qzQliXimxPwQ7GmTcd95bsMgqZuOqVx cseyBzhI+fHcAdEBuJxu =1nxZ -END PGP SIGNATURE- ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 60236] corruption of text and bottom of screen in xonotic menus since 325422c49449acdd8df1eb2ca8ed81f7696c38cc
https://bugs.freedesktop.org/show_bug.cgi?id=60236 --- Comment #5 from Alex Deucher ag...@yahoo.com --- (In reply to comment #1) linux 3.8-rc63.7.4 had it also 325422c49449acdd8df1eb2ca8ed81f7696c38cc (r600g: add async for staging buffer upload v2) only takes affect on 3.8 kernels. Previous kernels didn't support the DMA rings. So if you are seeing the same issue on multiple kernels, it's either something else or you are seeing two issues. It may be the same issue as bug 58042. -- You are receiving this mail because: You are the assignee for the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 60294] Flashplayer crashing
https://bugs.freedesktop.org/show_bug.cgi?id=60294 --- Comment #10 from René Blokland pe1...@gmail.com --- Created attachment 74247 -- https://bugs.freedesktop.org/attachment.cgi?id=74247action=edit my current config -- You are receiving this mail because: You are the assignee for the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 60236] corruption of text and bottom of screen in xonotic menus since 325422c49449acdd8df1eb2ca8ed81f7696c38cc
https://bugs.freedesktop.org/show_bug.cgi?id=60236 smoki smoki00...@gmail.com changed: What|Removed |Added Attachment #74238|text/plain |image/png mime type|| -- You are receiving this mail because: You are the assignee for the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 60294] Flashplayer crashing
https://bugs.freedesktop.org/show_bug.cgi?id=60294 --- Comment #11 from René Blokland pe1...@gmail.com --- (In reply to comment #8) It's not that I am a dev or something, but you should first consider upgrading the kernel. Releases from 3.8-rc2 to 3.8-rc6 include lot of fixes and maybe it could solve your problems. I am running rc6 now and the same problems. -- You are receiving this mail because: You are the assignee for the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 60294] Flashplayer crashing
https://bugs.freedesktop.org/show_bug.cgi?id=60294 --- Comment #12 from René Blokland pe1...@gmail.com --- (In reply to comment #9) Does setting the environment variable R600_LLVM=0 or building Mesa without --enable-r600-llvm-compiler work around the problem? without --enable-r600-llvm-compiler there is no change but R600_LLVM=0 solves everything. Thanks -- You are receiving this mail because: You are the assignee for the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 60294] [LLVM] Flashplayer crashing
https://bugs.freedesktop.org/show_bug.cgi?id=60294 Michel Dänzer mic...@daenzer.net changed: What|Removed |Added Summary|Flashplayer crashing|[LLVM] Flashplayer crashing -- You are receiving this mail because: You are the assignee for the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm/nouveau: always select ACPI_VIDEO if ACPI is enabled.
On Mon, Feb 04, 2013 at 04:41:22PM +0100, Maarten Lankhorst wrote: Hey, Op 04-02-13 16:23, Borislav Petkov schreef: Hi, I'm guessing someone has already triggered this on latest Linus' tree and has a fix? drivers/built-in.o: In function `nouveau_acpi_edid': /w/kernel/linux/drivers/gpu/drm/nouveau/nouveau_acpi.c:420: undefined reference to `acpi_video_get_edid' make: *** [vmlinux] Error 1 Btw, I got CONFIG_ACPI_VIDEO=m while CONFIG_DRM_NOUVEAU=y and this is probably the reason for the vmlinux link error. Thanks. Does this fix things? --8 Having nouveau builtin would still allow ACPI_VIDEO to be used as external module if some of the deps for acpi_video have not been met, which would result in a linking failure. Solve this by only requiring ACPI X86 to select ACPI_VIDEO. Signed-off-by: Maarten Lankhorst maarten.lankho...@canonical.com --- diff --git a/drivers/gpu/drm/nouveau/Kconfig b/drivers/gpu/drm/nouveau/Kconfig index 8a55bee..f08b9b6 100644 --- a/drivers/gpu/drm/nouveau/Kconfig +++ b/drivers/gpu/drm/nouveau/Kconfig @@ -10,7 +10,7 @@ config DRM_NOUVEAU select FB select FRAMEBUFFER_CONSOLE if !EXPERT select FB_BACKLIGHT if DRM_NOUVEAU_BACKLIGHT - select ACPI_VIDEO if ACPI X86 BACKLIGHT_CLASS_DEVICE VIDEO_OUTPUT_CONTROL INPUT + select ACPI_VIDEO if ACPI X86 select ACPI_WMI if ACPI select MXM_WMI if ACPI select POWER_SUPPLY Not really. drivers/built-in.o: In function `acpi_video_bus_put_one_device': /root/kernel/linux/drivers/acpi/video.c:1407: undefined reference to `thermal_cooling_device_unregister' drivers/built-in.o: In function `acpi_video_device_find_cap': /root/kernel/linux/drivers/acpi/video.c:842: undefined reference to `thermal_cooling_device_register' make: *** [vmlinux] Error 1 It is CONFIG_THERMAL=m this time. Thanks. -- Regards/Gruss, Boris. Sent from a fat crate under my desk. Formatting is fine. -- ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v2] drm/nouveau: always select ACPI_VIDEO if ACPI is enabled.
Op 05-02-13 15:52, Borislav Petkov schreef: On Mon, Feb 04, 2013 at 04:41:22PM +0100, Maarten Lankhorst wrote: Hey, Op 04-02-13 16:23, Borislav Petkov schreef: Hi, I'm guessing someone has already triggered this on latest Linus' tree and has a fix? drivers/built-in.o: In function `nouveau_acpi_edid': /w/kernel/linux/drivers/gpu/drm/nouveau/nouveau_acpi.c:420: undefined reference to `acpi_video_get_edid' make: *** [vmlinux] Error 1 Btw, I got CONFIG_ACPI_VIDEO=m while CONFIG_DRM_NOUVEAU=y and this is probably the reason for the vmlinux link error. Thanks. Does this fix things? --8 Having nouveau builtin would still allow ACPI_VIDEO to be used as external module if some of the deps for acpi_video have not been met, which would result in a linking failure. Solve this by only requiring ACPI X86 to select ACPI_VIDEO. Signed-off-by: Maarten Lankhorst maarten.lankho...@canonical.com --- diff --git a/drivers/gpu/drm/nouveau/Kconfig b/drivers/gpu/drm/nouveau/Kconfig index 8a55bee..f08b9b6 100644 --- a/drivers/gpu/drm/nouveau/Kconfig +++ b/drivers/gpu/drm/nouveau/Kconfig @@ -10,7 +10,7 @@ config DRM_NOUVEAU select FB select FRAMEBUFFER_CONSOLE if !EXPERT select FB_BACKLIGHT if DRM_NOUVEAU_BACKLIGHT -select ACPI_VIDEO if ACPI X86 BACKLIGHT_CLASS_DEVICE VIDEO_OUTPUT_CONTROL INPUT +select ACPI_VIDEO if ACPI X86 select ACPI_WMI if ACPI select MXM_WMI if ACPI select POWER_SUPPLY Not really. drivers/built-in.o: In function `acpi_video_bus_put_one_device': /root/kernel/linux/drivers/acpi/video.c:1407: undefined reference to `thermal_cooling_device_unregister' drivers/built-in.o: In function `acpi_video_device_find_cap': /root/kernel/linux/drivers/acpi/video.c:842: undefined reference to `thermal_cooling_device_register' make: *** [vmlinux] Error 1 It is CONFIG_THERMAL=m this time. Thanks. Argh, next attempt, based on i915's Kconfig. It seems that not only I have to select ACPI_VIDEO, I also have to select all the dependencies. Is this a Kconfig bug or working as intended? i915 seems to have a workaround, so I copied it from there. Except it's currently missing select THERMAL, so I guess it didn't get updated when that got added. 8 Having nouveau builtin would still allow ACPI_VIDEO to be used as external module if some of the deps for acpi_video have not been met, which would result in a linking failure. Solve this by selecting all dependencies as well. Signed-off-by: Maarten Lankhorst maarten.lankho...@canonical.com --- diff --git a/drivers/gpu/drm/nouveau/Kconfig b/drivers/gpu/drm/nouveau/Kconfig index 8a55bee..e84763a 100644 --- a/drivers/gpu/drm/nouveau/Kconfig +++ b/drivers/gpu/drm/nouveau/Kconfig @@ -10,10 +10,16 @@ config DRM_NOUVEAU select FB select FRAMEBUFFER_CONSOLE if !EXPERT select FB_BACKLIGHT if DRM_NOUVEAU_BACKLIGHT - select ACPI_VIDEO if ACPI X86 BACKLIGHT_CLASS_DEVICE VIDEO_OUTPUT_CONTROL INPUT select ACPI_WMI if ACPI select MXM_WMI if ACPI select POWER_SUPPLY + # Similar to i915, we need to select ACPI_VIDEO and it's dependencies + select BACKLIGHT_LCD_SUPPORT if ACPI X86 + select BACKLIGHT_CLASS_DEVICE if ACPI X86 + select VIDEO_OUTPUT_CONTROL if ACPI X86 + select INPUT if ACPI X86 + select THERMAL if ACPI X86 + select ACPI_VIDEO if ACPI X86 help Choose this option for open-source nVidia support. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 60236] corruption of text and bottom of screen in xonotic menus since 325422c49449acdd8df1eb2ca8ed81f7696c38cc
https://bugs.freedesktop.org/show_bug.cgi?id=60236 --- Comment #6 from Paul Heldens pheld...@ziggo.nl --- Tested it again to be sure Linux borgir 3.7.6 does NOT have the problem, pardon the mistake. -- You are receiving this mail because: You are the assignee for the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 60236] corruption of text and bottom of screen in xonotic menus since 325422c49449acdd8df1eb2ca8ed81f7696c38cc
https://bugs.freedesktop.org/show_bug.cgi?id=60236 --- Comment #7 from Jerome Glisse gli...@freedesktop.org --- And what GPU is this ? Because here it works ... -- You are receiving this mail because: You are the assignee for the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2] drm/nouveau: always select ACPI_VIDEO if ACPI is enabled.
On Tue, Feb 05, 2013 at 04:38:35PM +0100, Maarten Lankhorst wrote: Argh, next attempt, based on i915's Kconfig. It seems that not only I have to select ACPI_VIDEO, I also have to select all the dependencies. Is this a Kconfig bug or working as intended? i915 seems to have a workaround, so I copied it from there. Except it's currently missing select THERMAL, so I guess it didn't get updated when that got added. 8 Having nouveau builtin would still allow ACPI_VIDEO to be used as external module if some of the deps for acpi_video have not been met, which would result in a linking failure. Solve this by selecting all dependencies as well. Signed-off-by: Maarten Lankhorst maarten.lankho...@canonical.com Yep, this takes care of all deps, Tested-by: Borislav Petkov b...@suse.de Thanks. -- Regards/Gruss, Boris. Sent from a fat crate under my desk. Formatting is fine. -- ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 60236] corruption of text and bottom of screen in xonotic menus since 325422c49449acdd8df1eb2ca8ed81f7696c38cc
https://bugs.freedesktop.org/show_bug.cgi?id=60236 --- Comment #8 from Paul Heldens pheld...@ziggo.nl --- OpenGL renderer string: Gallium 0.4 on AMD RV730 -- You are receiving this mail because: You are the assignee for the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 60236] corruption of text and bottom of screen in xonotic menus since 325422c49449acdd8df1eb2ca8ed81f7696c38cc
https://bugs.freedesktop.org/show_bug.cgi?id=60236 --- Comment #9 from Andy Furniss li...@andyfurniss.entadsl.com --- (In reply to comment #0) bisected to this commit 325422c49449acdd8df1eb2ca8ed81f7696c38cc is the first bad commit commit 325422c49449acdd8df1eb2ca8ed81f7696c38cc Author: Jerome Glisse jgli...@redhat.com Date: Mon Jan 7 17:45:59 2013 -0500 r600g: add async for staging buffer upload v2 v2: Add virtual address to dma src/dst offset for cayman Signed-off-by: Jerome Glisse jgli...@redhat.com :04 04 4ef6e784f3acb7f21da0c5e1923810c78917d16d 55f0ce7d9793ce04d392fc7943059545053a9d79 Msrc Looks correct to me on rv790. I get nothing like the corruption in the screens, for me it's just the band at the bottom of the screen and it's not always there (but seems to be reliable first test after boot from power off). I tested a couple of cycles with mesa reset just before this commit and couldn't see the problem. With mesa on this commit I can see it. Kernel is drm-fixes. -- You are receiving this mail because: You are the assignee for the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 60236] corruption of text and bottom of screen in xonotic menus since 325422c49449acdd8df1eb2ca8ed81f7696c38cc
https://bugs.freedesktop.org/show_bug.cgi?id=60236 --- Comment #10 from Paul Heldens pheld...@ziggo.nl --- Yes for me this effect varies also if I open , say a browser with a complex webpage, and then start xonotic again the text may be garbled the 2nd start its as if video memory or some caches get corrupted -- You are receiving this mail because: You are the assignee for the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v17 4/7] fbmon: add videomode helpers
Hi! On Fri, Feb 01, 2013 at 06:29:50PM +0900, Jingoo Han wrote: On Friday, January 25, 2013 6:02 PM, Steffen Trumtrar wrote + fbmode-sync = 0; + fbmode-vmode = 0; + if (vm-dmt_flags VESA_DMT_HSYNC_HIGH) + fbmode-sync |= FB_SYNC_HOR_HIGH_ACT; + if (vm-dmt_flags VESA_DMT_HSYNC_HIGH) Um, it seems to be a type. 'H'SYNC - 'V'SYNC Thus, it would be changed as below: VESA_DMT_HSYNC_HIGH - VESA_DMT_VSYNC_HIGH Damn. You are right, that is a typo. But I guess some maintainer (Dave) really, really wants to take the series now and this can wait for an -rc. No?! ;-) Thanks, Steffen + fbmode-sync |= FB_SYNC_VERT_HIGH_ACT; + if (vm-data_flags DISPLAY_FLAGS_INTERLACED) + fbmode-vmode |= FB_VMODE_INTERLACED; + if (vm-data_flags DISPLAY_FLAGS_DOUBLESCAN) + fbmode-vmode |= FB_VMODE_DOUBLE; + fbmode-flag = 0; + -- Pengutronix e.K. | | Industrial Linux Solutions | http://www.pengutronix.de/ | Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0| Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917- | ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 43751] [TTM] Out of kernel memory
https://bugzilla.kernel.org/show_bug.cgi?id=43751 --- Comment #9 from cyberbat cyber...@lavabit.com 2013-02-05 20:11:50 --- Created an attachment (id=92571) -- (https://bugzilla.kernel.org/attachment.cgi?id=92571) Config of working linux-3.7.4 Tried a kernel 3.7.4 for some days and it seems to work with config attached. -- Configure bugmail: https://bugzilla.kernel.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are watching the assignee of the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 26891] Radeon KMS fails with inaccessible AtomBIOS on systems with (U)EFI boot
https://bugs.freedesktop.org/show_bug.cgi?id=26891 --- Comment #53 from Benjamin Lee b...@b1c1l1.com --- I can also confirm that Radeon KMS works on my MacBookPro8,2 with kernel version 3.8-rc6 and EFI stub boot. I also needed to add a device section to my xorg.conf. I don't see any video BIOS in /dev/mem so I guess it is loading from ACPI instead. Out of curiosity, I tried to load fglrx and it failed to find a valid VBIOS so fglrx must not have the ACPI loading method. blee@supra ~ $ sudo dd if=/dev/mem of=/dev/stdout bs=65536 skip=12 count=1 2/dev/null | hexdump 000 * 001 [2.589927] [drm] Initialized drm 1.1.0 20060810 [2.589966] [drm] radeon defaulting to kernel modesetting. [2.589969] [drm] radeon kernel modesetting enabled. [2.590189] [drm] initializing kernel modesetting (TURKS 0x1002:0x6741 0x106B :0x00E2). [2.590226] [drm] register mmio base: 0xB080 [2.590229] [drm] register mmio size: 131072 [2.590253] ATOM BIOS: Apple [2.590264] [drm] GPU not posted. posting now... [2.599466] radeon :01:00.0: VRAM: 1024M 0x - 0x3 FFF (1024M used) [2.599472] radeon :01:00.0: GTT: 512M 0x4000 - 0x5FF F [2.604787] [drm] Detected VRAM RAM=1024M, BAR=256M [2.604793] [drm] RAM width 128bits DDR [2.604843] [TTM] Zone kernel: Available graphics memory: 4042710 kiB [2.604846] [TTM] Zone dma32: Available graphics memory: 2097152 kiB [2.604849] [TTM] Initializing pool allocator [2.604858] [TTM] Initializing DMA pool allocator [2.604893] [drm] radeon: 1024M of VRAM memory ready [2.604896] [drm] radeon: 512M of GTT memory ready. [2.604917] [drm] Supports vblank timestamp caching Rev 1 (10.10.2010). [2.604920] [drm] Driver supports precise vblank timestamp query. [2.604982] radeon :01:00.0: irq 45 for MSI/MSI-X [2.604993] radeon :01:00.0: radeon: using MSI. [2.605028] [drm] radeon: irq initialized. [2.605033] [drm] GART: num cpu pages 131072, num gpu pages 131072 [2.605463] [drm] probing gen 2 caps for device 8086:101 = 2/0 [2.605470] [drm] PCIE gen 2 link speeds already enabled [2.605534] [drm] Loading TURKS Microcode -- You are receiving this mail because: You are the assignee for the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm/nouveau: add lockdep annotations
On Mon, Feb 04, 2013 at 10:59:28PM +0100, Maarten Lankhorst wrote:
Op 04-02-13 22:30, Marcin Slusarz schreef:
1) Lockdep thinks all nouveau subdevs belong to the same class and can be
locked in arbitrary order, which is not true (at least in general case).
Tell it to distinguish subdevs by (o)class type.
Apart from this specific case, is there any other reason why we require being
able to nest 2 subdev locks?
I think I tend to prefer Marcin's fix for this actually. The subdev's
are completely separate classes of objects and as interaction between
them increases (PM will be very much like this), we may very well
require holding multiple subdev mutexes at once.
Ben.
Add a NVOBJ_FLAG_CREATE_EXCLUSIVE flag to nouveau_engctx_create and return
-EBUSY if there is any existing object. Problem solved, and lockdep is still
generic.
2) DRM client can be locked under user client lock - tell lockdep to put DRM
client lock in a separate class.
Can you copy paste a typical lockdep splat for this? Also this should be a
separate patch. :-)
Reported-by: Arend van Spriel ar...@broadcom.com
Reported-by: Peter Hurley pe...@hurleysoftware.com
Reported-by: Maarten Lankhorst maarten.lankho...@canonical.com
Reported-by: Daniel J Blueman dan...@quora.org
Signed-off-by: Marcin Slusarz marcin.slus...@gmail.com
Cc: sta...@vger.kernel.org [3.7, but needs s/const ofuncs/ofuncs/ to build]
---
Lightly tested, only on NV4B and NVC1.
---
drivers/gpu/drm/nouveau/core/core/subdev.c | 2 +-
drivers/gpu/drm/nouveau/core/include/core/object.h | 7 +--
drivers/gpu/drm/nouveau/nouveau_drm.c | 3 +++
3 files changed, 9 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/nouveau/core/core/subdev.c
b/drivers/gpu/drm/nouveau/core/core/subdev.c
index f74c30a..48f0637 100644
--- a/drivers/gpu/drm/nouveau/core/core/subdev.c
+++ b/drivers/gpu/drm/nouveau/core/core/subdev.c
@@ -99,7 +99,7 @@ nouveau_subdev_create_(struct nouveau_object *parent,
if (ret)
return ret;
- mutex_init(subdev-mutex);
+ __mutex_init(subdev-mutex, subname, oclass-lock_class_key);
subdev-name = subname;
if (parent) {
diff --git a/drivers/gpu/drm/nouveau/core/include/core/object.h
b/drivers/gpu/drm/nouveau/core/include/core/object.h
index 6a90267..62e68ba 100644
--- a/drivers/gpu/drm/nouveau/core/include/core/object.h
+++ b/drivers/gpu/drm/nouveau/core/include/core/object.h
@@ -50,10 +50,13 @@ int nouveau_object_fini(struct nouveau_object *, bool
suspend);
extern struct nouveau_ofuncs nouveau_object_ofuncs;
+/* Don't allocate dynamically, because lockdep needs lock_class_keys to be
in
+ * .data. */
struct nouveau_oclass {
u32 handle;
- struct nouveau_ofuncs *ofuncs;
- struct nouveau_omthds *omthds;
+ struct nouveau_ofuncs * const ofuncs;
+ struct nouveau_omthds * const omthds;
+ struct lock_class_key lock_class_key;
};
#define nv_oclass(o)nv_object(o)-oclass
diff --git a/drivers/gpu/drm/nouveau/nouveau_drm.c
b/drivers/gpu/drm/nouveau/nouveau_drm.c
index ef1ad21..bc00587 100644
--- a/drivers/gpu/drm/nouveau/nouveau_drm.c
+++ b/drivers/gpu/drm/nouveau/nouveau_drm.c
@@ -245,6 +245,8 @@ static int nouveau_drm_probe(struct pci_dev *pdev,
return 0;
}
+static struct lock_class_key drm_client_lock_class_key;
+
static int
nouveau_drm_load(struct drm_device *dev, unsigned long flags)
{
@@ -256,6 +258,7 @@ nouveau_drm_load(struct drm_device *dev, unsigned long
flags)
ret = nouveau_cli_create(pdev, DRM, sizeof(*drm), (void**)drm);
if (ret)
return ret;
+ lockdep_set_class(drm-client.mutex, drm_client_lock_class_key);
dev-dev_private = drm;
drm-dev = dev;
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: 答复: [PATCH]Siliconmotion initial patch
On Tue, Feb 05, 2013 at 03:51:55PM +0800, Aaron.Chen 陈俊杰 wrote: This is an initial patch for Siliconmotion Graphics chips. It add SM750 chip support with 2d accelerate and hw curser support. It is a complete new driver. So the patch is a little bit big. Is it OK for review? Adding a new fbdev driver while established consensus pretty much boils down to fbdev being a dead subsystem which should only be used for legacy applications and drivers: Not good. You should implement this as a drm modesetting driver, and if required base your 2d acceleration on top of the drm fb helpers. Or just implement a drm/gem driver to expose this. Additionally you should include the appropriate mailing lists, which is linux-fbdev for fbdev drivers. On a very quick read the patch has serious issues: - checkpatch.pl: total: 2 errors, 779 warnings, 7961 lines checked NOTE: whitespace errors detected, you may wish to use scripts/cleanpatch or scripts/cleanfile - Remants of hungarian notation (dunno whether checkpatch checks for those, too much other stuff flying by, but it really stuck out). - Not using the linux i2c layer in the ddk750_hwi2c.c file. - Reimplementing i2c bit-banging code in the ddk750_swi2c.c - Adding a new implementation of a sil 164 dvi driver, we already have at least two in drivers/gpu/drm/i2c/sil164_drv.c and drivers/gpu/drm/i915/dvo_sil164.c. This should be unified and probably use the drm encoder slave framework. At that point I've given up on further review, since there's clearly a lot of work left to do. Please review SubmittingPatches from the kernel documentation carefully. Also cc'ing our dear staging maintainer, he should be able to point you at further useful resources for getting this going. Cheers, Daniel -- Daniel Vetter Software Engineer, Intel Corporation +41 (0) 79 365 57 48 - http://blog.ffwll.ch ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 59332] Problems building 32bit Mesa
https://bugs.freedesktop.org/show_bug.cgi?id=59332 Mike Lothian m...@fireburn.co.uk changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |INVALID --- Comment #11 from Mike Lothian m...@fireburn.co.uk --- Seems I had a rogue /usr/lib32/libstdc++.so causing problems with my 32bit builds Everything is working fine now with LLVM enabled -- You are receiving this mail because: You are the assignee for the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 59332] Problems building 32bit Mesa
https://bugs.freedesktop.org/show_bug.cgi?id=59332 Matt Turner matts...@gmail.com changed: What|Removed |Added Blocks|59304 | -- You are receiving this mail because: You are the assignee for the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm/fb-helper: improve kerneldoc
On Fri, Feb 01, 2013 at 01:21:29PM +0100, Laurent Pinchart wrote: Hi Daniel, Thanks for improving the documentation :-) On Sunday 27 January 2013 18:42:16 Daniel Vetter wrote: Now that the fbdev helper interface for drivers is trimmed down, update the kerneldoc for all the remaining exported functions. I've tried to beat the DocBook a bit by reordering the function references a bit into a more sensible ordering. But that didn't work out at all. Hence just extend the in-code DOC: section a bit. Also remove the LOCKING: sections - especially for the setup functions they're totally bogus. But that's not a documentation problem, but simply an artifact of the current rather hazardous locking around drm init and even more so around fbdev setup ... Please see below for comments (I've reflowed the text to ease review). v2: Some further improvements: - Also add documentation for drm_fb_helper_single_add_all_connectors, Dave Airlie didn't want me to kill this one from the fb helper interface. - Update docs for drm_fb_helper_fill_var/fix - they should be used from the driver's -fb_probe callback to setup the fbdev info structure. - Clarify what the -fb_probe callback should all do - it needs to setup both the fbdev info and allocate the drm framebuffer used as backing storage. - Add basic documentaation for the drm_fb_helper_funcs driver callback vfunc. Signed-off-by: Daniel Vetter daniel.vet...@ffwll.ch moar kerneldoc --- Documentation/DocBook/drm.tmpl |1 + drivers/gpu/drm/drm_fb_helper.c | 146 include/drm/drm_fb_helper.h | 11 +++ 3 files changed, 143 insertions(+), 15 deletions(-) diff --git a/Documentation/DocBook/drm.tmpl b/Documentation/DocBook/drm.tmpl index 6c11d77..14ad829 100644 --- a/Documentation/DocBook/drm.tmpl +++ b/Documentation/DocBook/drm.tmpl @@ -2139,6 +2139,7 @@ void intel_crt_init(struct drm_device *dev) titlefbdev Helper Functions Reference/title !Pdrivers/gpu/drm/drm_fb_helper.c fbdev helpers !Edrivers/gpu/drm/drm_fb_helper.c +!Iinclude/drm/drm_fb_helper.h /sect2 sect2 titleDisplay Port Helper Functions Reference/title diff --git a/drivers/gpu/drm/drm_fb_helper.c b/drivers/gpu/drm/drm_fb_helper.c index 5a92470..a7538cc 100644 --- a/drivers/gpu/drm/drm_fb_helper.c +++ b/drivers/gpu/drm/drm_fb_helper.c @@ -52,9 +52,34 @@ static LIST_HEAD(kernel_fb_helper_list); * mode setting driver. They can be used mostly independantely from the Now that you have removed one of the dependencies on the crtc helpers in your drm/fb-helper: don't disable everything in initial_config patch, are there others ? If not you can s/mostly //. It's getting better, but a few of the driver callbacks used by the fb helper are still in the crtc helper function tables. And there's the fb helper private way to safe/restore gamma tables. But at least semantically there's no dependency any longer after these patches I think. * crtc helper functions used by many drivers to implement the kernel mode * setting interfaces. + * + * Initialization is done as a three-step process with + * drm_fb_helper_init(), drm_fb_helper_single_add_all_connectors() and + * drm_fb_helper_initial_config(). Drivers with fancier requirements than + * the default beheviour can override the second step with their own code. + * Teardown is done with drm_fb_helper_fini(). + * + * At runtime drivers should restore the fbdev console by calling + * drm_fb_helper_restore_fbdev_mode() from their -lastclose callback. They + * can also notify the fb helper code from updates to the output Is it can or must ? If can, in what conditions should they call drm_fb_helper_restore_fbdev_mode() and in what conditions shouldn't they ? I've figured that hpd support is optional, hence no must. I've opted for a should instead. Also added a bit of text to suggest a good place to put this call. + * configuration by calling drm_fb_helper_hotplug_event(). + * + * All other functions exported by the fb helper library can be used to + * implement the fbdev driver interface by the driver. */ -/* simple single crtc case helper function */ +/** + * drm_fb_helper_single_add_all_connectors() - add all connectors to fbdev + *emulation helper + * @fb_helper: fbdev initialized with drm_fb_helper_init + * + * This functions adds all the available connectors for use with the given + * fb_helper. This is a separate step to allow drivers to freely assign or + * connectors to the fbdev, e.g. if some are reserved for special purposes + * not adequate to be used for the fbcon. + * + * Since this is part of the initial setup before the fbdev is published, + * no locking is required. + */ int drm_fb_helper_single_add_all_connectors(struct drm_fb_helper
[PATCH] drm/fb-helper: improve kerneldoc
Now that the fbdev helper interface for drivers is trimmed down,
update the kerneldoc for all the remaining exported functions.
I've tried to beat the DocBook a bit by reordering the function
references a bit into a more sensible ordering. But that didn't work
out at all. Hence just extend the in-code DOC: section a bit.
Also remove the LOCKING: sections - especially for the setup functions
they're totally bogus. But that's not a documentation problem, but
simply an artifact of the current rather hazardous locking around drm
init and even more so around fbdev setup ...
v2: Some further improvements:
- Also add documentation for drm_fb_helper_single_add_all_connectors,
Dave Airlie didn't want me to kill this one from the fb helper
interface.
- Update docs for drm_fb_helper_fill_var/fix - they should be used
from the driver's -fb_probe callback to setup the fbdev info
structure.
- Clarify what the -fb_probe callback should all do - it needs to
setup both the fbdev info and allocate the drm framebuffer used as
backing storage.
- Add basic documentaation for the drm_fb_helper_funcs driver callback
vfunc.
v3: Implement clarifications Lauren Pinchart suggested in his review.
Cc: Laurent Pinchart laurent.pinch...@ideasonboard.com
Signed-off-by: Daniel Vetter daniel.vet...@ffwll.ch
---
Documentation/DocBook/drm.tmpl |1 +
drivers/gpu/drm/drm_fb_helper.c | 148 +++
include/drm/drm_fb_helper.h | 12
3 files changed, 146 insertions(+), 15 deletions(-)
diff --git a/Documentation/DocBook/drm.tmpl b/Documentation/DocBook/drm.tmpl
index 6c11d77..14ad829 100644
--- a/Documentation/DocBook/drm.tmpl
+++ b/Documentation/DocBook/drm.tmpl
@@ -2139,6 +2139,7 @@ void intel_crt_init(struct drm_device *dev)
titlefbdev Helper Functions Reference/title
!Pdrivers/gpu/drm/drm_fb_helper.c fbdev helpers
!Edrivers/gpu/drm/drm_fb_helper.c
+!Iinclude/drm/drm_fb_helper.h
/sect2
sect2
titleDisplay Port Helper Functions Reference/title
diff --git a/drivers/gpu/drm/drm_fb_helper.c b/drivers/gpu/drm/drm_fb_helper.c
index 5a92470..b4cbef3 100644
--- a/drivers/gpu/drm/drm_fb_helper.c
+++ b/drivers/gpu/drm/drm_fb_helper.c
@@ -52,9 +52,36 @@ static LIST_HEAD(kernel_fb_helper_list);
* mode setting driver. They can be used mostly independantely from the crtc
* helper functions used by many drivers to implement the kernel mode setting
* interfaces.
+ *
+ * Initialization is done as a three-step process with drm_fb_helper_init(),
+ * drm_fb_helper_single_add_all_connectors() and
drm_fb_helper_initial_config().
+ * Drivers with fancier requirements than the default beheviour can override
the
+ * second step with their own code. Teardown is done with
drm_fb_helper_fini().
+ *
+ * At runtime drivers should restore the fbdev console by calling
+ * drm_fb_helper_restore_fbdev_mode() from their -lastclose callback. They
+ * should also notify the fb helper code from updates to the output
+ * configuration by calling drm_fb_helper_hotplug_event(). For easier
+ * integration with the output polling code in drm_crtc_helper.c the modeset
+ * code proves a -output_poll_changed callback.
+ *
+ * All other functions exported by the fb helper library can be used to
+ * implement the fbdev driver interface by the driver.
*/
-/* simple single crtc case helper function */
+/**
+ * drm_fb_helper_single_add_all_connectors() - add all connectors to fbdev
+ *emulation helper
+ * @fb_helper: fbdev initialized with drm_fb_helper_init
+ *
+ * This functions adds all the available connectors for use with the given
+ * fb_helper. This is a separate step to allow drivers to freely assign
+ * connectors to the fbdev, e.g. if some are reserved for special purposes or
+ * not adequate to be used for the fbcon.
+ *
+ * Since this is part of the initial setup before the fbdev is published, no
+ * locking is required.
+ */
int drm_fb_helper_single_add_all_connectors(struct drm_fb_helper *fb_helper)
{
struct drm_device *dev = fb_helper-dev;
@@ -163,6 +190,10 @@ static void drm_fb_helper_restore_lut_atomic(struct
drm_crtc *crtc)
crtc-funcs-gamma_set(crtc, r_base, g_base, b_base, 0,
crtc-gamma_size);
}
+/**
+ * drm_fb_helper_debug_enter - implementation for -fb_debug_enter
+ * @info: fbdev registered by the helper
+ */
int drm_fb_helper_debug_enter(struct fb_info *info)
{
struct drm_fb_helper *helper = info-par;
@@ -208,6 +239,10 @@ static struct drm_framebuffer *drm_mode_config_fb(struct
drm_crtc *crtc)
return NULL;
}
+/**
+ * drm_fb_helper_debug_leave - implementation for -fb_debug_leave
+ * @info: fbdev registered by the helper
+ */
int drm_fb_helper_debug_leave(struct fb_info *info)
{
struct drm_fb_helper *helper = info-par;
@@ -243,9 +278,9 @@ EXPORT_SYMBOL(drm_fb_helper_debug_leave);
* drm_fb_helper_restore_fbdev_mode - restore fbdev configuration
* @fb_helper: fbcon
[PATCH v3 0/2] Get the HDMI IP block version from device tree
This set changes the hdmi device tree node to properly represent the version of the IP block. The first patch changes the drm hdmi driver to use the compatible field to determine which registers/functions to call, and removes the unfortunate v1.3/v1.4 naming convention. The second patch updates the arch- specific bits for exynos5. Changes in v3: - Use compatible field in device tree instead of hdmi-version field - Change hdmi driver's naming to use IP version instead of hdmi version Sean Paul (2): drm/exynos: Get HDMI version from device tree ARM: Change exynos5-hdmi references to exynos4-hdmi .../devicetree/bindings/drm/exynos/hdmi.txt|9 +- arch/arm/boot/dts/exynos5250.dtsi |3 +- arch/arm/mach-exynos/clock-exynos5.c |4 +- arch/arm/mach-exynos/mach-exynos5-dt.c |4 +- drivers/gpu/drm/exynos/exynos_hdmi.c | 354 ++-- drivers/gpu/drm/exynos/regs-hdmi.h | 78 +++--- 6 files changed, 229 insertions(+), 223 deletions(-) -- 1.7.7.3 ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v3 2/3] ARM: Change exynos5-hdmi references to exynos4-hdmi
With the change drm/exynos: Get HDMI version from device tree,
exynos5-hdmi is no longer relevant. Update references to exynos4-hdmi
and update the hdmi compatibility string to accurately reflect the hdmi
driver.
Signed-off-by: Sean Paul seanp...@chromium.org
---
arch/arm/boot/dts/exynos5250.dtsi |3 ++-
arch/arm/mach-exynos/clock-exynos5.c |4 ++--
arch/arm/mach-exynos/mach-exynos5-dt.c |4 ++--
3 files changed, 6 insertions(+), 5 deletions(-)
diff --git a/arch/arm/boot/dts/exynos5250.dtsi
b/arch/arm/boot/dts/exynos5250.dtsi
index 3acf594..70464bf 100644
--- a/arch/arm/boot/dts/exynos5250.dtsi
+++ b/arch/arm/boot/dts/exynos5250.dtsi
@@ -573,7 +573,8 @@
};
hdmi {
- compatible = samsung,exynos5-hdmi;
+ compatible = samsung,exynos5250-hdmi,
+samsung,exynos4212-hdmi, samsung,exynos4-hdmi;
reg = 0x1453 0x7;
interrupts = 0 95 0;
};
diff --git a/arch/arm/mach-exynos/clock-exynos5.c
b/arch/arm/mach-exynos/clock-exynos5.c
index e9d7b80..6eae39d 100644
--- a/arch/arm/mach-exynos/clock-exynos5.c
+++ b/arch/arm/mach-exynos/clock-exynos5.c
@@ -686,12 +686,12 @@ static struct clk exynos5_init_clocks_off[] = {
.ctrlbit= (1 0),
}, {
.name = hdmi,
- .devname= exynos5-hdmi,
+ .devname= exynos4-hdmi,
.enable = exynos5_clk_ip_disp1_ctrl,
.ctrlbit= (1 6),
}, {
.name = hdmiphy,
- .devname= exynos5-hdmi,
+ .devname= exynos4-hdmi,
.enable = exynos5_clk_hdmiphy_ctrl,
.ctrlbit= (1 0),
}, {
diff --git a/arch/arm/mach-exynos/mach-exynos5-dt.c
b/arch/arm/mach-exynos/mach-exynos5-dt.c
index e99d3d8..0ccda72 100644
--- a/arch/arm/mach-exynos/mach-exynos5-dt.c
+++ b/arch/arm/mach-exynos/mach-exynos5-dt.c
@@ -97,8 +97,8 @@ static const struct of_dev_auxdata
exynos5250_auxdata_lookup[] __initconst = {
exynos-gsc.2, NULL),
OF_DEV_AUXDATA(samsung,exynos5-gsc, EXYNOS5_PA_GSC3,
exynos-gsc.3, NULL),
- OF_DEV_AUXDATA(samsung,exynos5-hdmi, 0x1453,
- exynos5-hdmi, NULL),
+ OF_DEV_AUXDATA(samsung,exynos4-hdmi, 0x1453,
+ exynos4-hdmi, NULL),
OF_DEV_AUXDATA(samsung,exynos5-mixer, 0x1445,
exynos5-mixer, NULL),
OF_DEV_AUXDATA(samsung,mfc-v6, 0x1100, s5p-mfc-v6, NULL),
--
1.7.7.3
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
