wiki/Chat_log/20170116-io-chatlog


1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148

--- Log opened Mon Jan 16 08:59:32 2017
08:59 -!- wsa_ [~wsa@p54B33FFD.dip0.t-ipconnect.de] has joined #periperi-io
08:59 -!- Irssi: #periperi-io: Total of 5 nicks [1 ops, 0 halfops, 0 voices, 4 normal]
08:59 -!- Irssi: Join to #periperi-io was synced in 1 secs
09:00 < wsa_> hey guys!
09:00 <@morimoto> hi
09:00 -!- shimoda [~shimoda@relprex3.renesas.com] has joined #periperi-io
09:00 < neg> horms: I accidently sent my ABC awnsers from my private email address to periperi, I have now resent the anwsers but feel free to delete and not to add my private email to the periperi whitelist :-)
09:00 -!- morimoto [~user@relprex3.renesas.com] has left #periperi-io ["ERC Version 5.3 (IRC client for Emacs)"]
09:00 < neg> wsa_: hi
09:00 < horms> neg: ok, will do
09:01 < neg> horms: thanks
09:01 -!- geertu [~geert@d54C189FD.access.telenet.be] has joined #periperi-io
09:01 < wsa_> that reminds me, simon you can remove the wsa-dev address from periperi as well
09:01 < geertu> Bummer, I was in #peripero-io
09:01 < horms> wsa_: sure
09:01 < wsa_> wsa@the-dreams.de seems to be back at full strength
09:02 < wsa_> geertu: "we are the popular front"
09:02 < wsa_> :D
09:03 -!- Irssi: #periperi-io: Total of 6 nicks [0 ops, 0 halfops, 0 voices, 6 normal]
09:04 < wsa_> ok, let's start
09:04 < wsa_> thanks for all the updates
09:04 < wsa_> despite holidays, there were some things going on :)
09:05 < wsa_> i have a few questions
09:05 < wsa_> first one about USB & IPMMU, I lost track a little of it
09:05 < wsa_> shimoda: does a workaround exist meanwhile?
09:06 < shimoda> wsa_: a workaround exist for some devices
09:07 < wsa_> and the SD workaround is basically the same issue
09:07 < wsa_> IPMMU issue
09:07 < wsa_> ?
09:08 < shimoda> wsa_: no. SDHI's restriction differs with IPMMU restriction...
09:09 < wsa_> OK, then I need to reread about that
09:10 < shimoda> wsa_: OK. But, I forgot that I wrote the SD restriction on periperi ML or not
09:10 < shimoda> so, i will summarize them later
09:10 < neg> is this be related to the IPMMU warnings seen on Gen2 while tuning SD or is it unrelated?
09:11 < wsa_> shimoda: thank you
09:11 < shimoda> neg: i'm not sure, but gen2 SYS-DMAC with IPMMU also has a problem
09:12 < geertu> There's also ipmmu-vmsa e67b0000.mmu: DMA-API: device driver tries to sync DMA memory it has not allocated
09:13 < neg> shimoda: ok thank you, I will read your upcoming summary on periperi and take it from there :-)
09:14 < wsa_> sounds good
09:14 < wsa_> i'm also looking forward to the desc :)
09:15 < wsa_> next question I have is about thermal driver testing
09:15 < wsa_> just so I know how to handle upstreaming
09:16 < wsa_> how likely is it that we can get Renesas testing from Gomi-san like this week or next week?
09:16 < shimoda> geertu: sorry I don't understand this "DMA-API" things
09:17 < geertu> shimoda: It means the ipmmu driver does something on a wrong pointer
09:17 < geertu> which may lead to corruption.
09:18 < wsa_> and would it be OK for Renesas if we upstream the driver without internal testing to get into v4.11 and fix issues (if any) with incremental patches?
09:18 < shimoda> wsa_: about thermel driver, Gomi-san and RVC are checking the v6 patch. and maybe i will get some feedack in this week .
09:18 < wsa_> \\o//
09:18 < wsa_> awesome!
09:19 < wsa_> still, the answer to the above question would be nice to know (to have a "Plan B")
09:21 < horms> wsa_: i would think the answer is yes unless there has been special requests made with regards to thermal from Renesas
09:22 < wsa_> there are no special requests
09:22 < shimoda> geertu: it's interesting. Is this easy to reproduce? 
09:23 < geertu> shimoda: Yes, it happens during ipmmu init. Just enable CONFIG_DMA_API_DEBUG=y
09:23 < wsa_> special is that we can do very limited testing on this one
09:23 < horms> wsa_: then I think you should do whatever is best from an upstream pov
09:24 < geertu> Sorry, during ravb_probe(), but I think it happens during init of the first user
09:24 < horms> wsa_: right, obviously we don't want things catching fire :)
09:24 < shimoda> geertu: thank you. i will try the config later
09:24  * wsa_ sings "relight my fire..."
09:25 < horms> haha: lets not have that be the theme for a patchset
09:25 < wsa_> :)
09:26 < wsa_> ok, so we'll try to get it into 4.11 anyhow, but hope that Gomi-san will be able to test this week
09:26 < wsa_> which would be awesome
09:28 < wsa_> is uli back from the holidays?
09:29 < wsa_> well, he has been on the multimedia meeting
09:29 < wsa_> would like to have had an update for his series -> will ask by mail
09:29 < wsa_> any questions from your side?
09:30 < horms> nothing in particular, other than that he should consider resending any outstanding patches
09:31 < neg> wsa_: you got time to talk about IO task after meeting?
09:32 < wsa_> yup
09:32 < wsa_> it's about emergency shutdown right?
09:33 < neg> yes
09:33 < horms> you probably know, but there is code in the BSP for that
09:33 < wsa_> well, there goes the last chance of really creating fire...
09:34 < neg> horms: I had a quick look at it, but I only found it by luck so thanks for pointing it out :-)
09:35 < horms> neg: any time
09:35 < wsa_> ok, if there are no other questions, let's talk about further hacking thermal/emergency
09:36 < wsa_> people not interested are free to leave, but everyone is welcome to stay, of course :)
09:36 < horms> i had one question, sorry
09:36 < wsa_> sure
09:36 < horms> meeting next month in .be
09:36 < horms> any firm plans?
09:37 < shimoda> about emergency shutdown, this is also handled by Gomi-san and/or related member. so, i can ask him about this
09:37 < wsa_> there will be an io meeting on friday
09:37 < wsa_> when exactly depends on when we have the room
09:37 < wsa_> geertu: ?
09:38 < horms> ok, do we have a location: I only ask so I can arrange some accomodation for myself
09:38 < geertu> horms: Yes, see "Meeting around FOSDEM"
09:39 < geertu> on periperi-ML
09:39 < horms> ok, thanks
09:39 < geertu> wsa_: I don't have hours, it's booked for the full day
09:39 < horms> I see it now
09:39 < neg> shimoda: thanks for telling me Gomi-san is working with emergency shutdown
09:40 < geertu> As I have to get their by train, I think I can be their at 9 or 9h30
09:40 < geertu> Of course you can start earlier ;-)
09:41 < geertu> s/be their/be there/
09:41 < wsa_> i don't think i can make it earlier than 9 as well
09:41 < horms> fwiw, i will likely arrive the day before
09:42 < wsa_> 9-13 first meeting, lunch, 14-18 second meeting ?
09:42 < geertu> Please reply to "Meeting around FOSDEM" to confirm your (un)attendence by Wednesday morning, thanks
09:42 < neg> I think 9:30 is a fine time, I need to navigate the local public transport system which if last year was any indication of my skill will take some time :-)
09:42 < geertu> BTW, Magnus just told me Ito-san may want to join the meetings
09:43 < wsa_> i'll be likely in brussels on thursday as well, but just "likely" yet...
09:43 < geertu> neg: I believe there's a direct subway from your hotel
09:43 < wsa_> neg: ok
09:43 < wsa_> 9:30-13:30 first meeting, lunch, 15-19 second meeting ?
09:44 < geertu> 13:30 may be a bit late for lunch
09:44 < neg> geertu: ahh thanks, will look it up
09:45 < wsa_> 9:30-13:00 first meeting, lunch, 14:30-18 second meeting, then open_end hacking ?
09:45 < geertu> What about 9:30-12:30 (I/O), 13:30-16:30 (Core), 16:30-18:00 (misc)
09:45 < wsa_> also fine
09:46 < wsa_> although, 1:30 for lunch might be more relaxing
09:46 < geertu> Note that we have to think about Dinner, and FOSDEM Beer Event starts at 16:00 :-)
09:47 < wsa_> even if it is lurking in the room for 30 minutes or having a short walk or something
09:48 < wsa_> can't tell that yet, i have not made all FOSDEM appointments
09:49 < wsa_> might be I'm busy on Friday evening meeting some ppl
09:49 < wsa_> hopefully not
09:49 < wsa_> :)
09:50 < wsa_> ok, back to thermal?
09:52 < wsa_> neg: fire away
09:52 < neg> So my question is more or less if you think "Thermal,?,noplan,?,add emergency shutdown support" could be a base or additonal task for me duing Q1 or if you rather see me working on something else. At the moment I have no IO tasks planed for Q1
09:53 < wsa_> i was rather thinking about "Thermal,?,noplan,?,add interrupt support" as your next task :)
09:54 < wsa_> which might be a prerequisite for shutdown anyhow
09:54 < wsa_> haven't checked
09:54 < neg> OK that also sounds like a suitable task for me
09:55 < wsa_> i have some drafts on my hdd somewhere, but it needs to be heavily refactored
09:55 < wsa_> if not redesigned
09:56 < wsa_> but at least we got the bindings in shape already
09:56 < wsa_> so we have freedom to redesign
09:57 < neg> OK that is fine, there is no rush we can hammer it out with email maybe before FOSDEM. My primary cencern where that there where some IO work for me to do :-)
09:57 < wsa_> interrupts were the reason why I went from three DT nodes to one and to introduce the #thermal-sensor-cells to be 1
09:58 < wsa_> you won't be bored with us
09:58 < wsa_> if all fails, there is SDHI ;)
09:59 < wsa_> but i think thermal might be your friend in the next time
10:00 < neg> nice :-) Then maybe you can send me the draft you made and think about if you wish me to do this as part of base or if we should try to get some of the work as an additinal contract and we take it from there?
10:00 < wsa_> exactly
10:01 < neg> thank you
10:03 < wsa_> i think we are done then
10:03 < wsa_> thank you all!
10:03 < wsa_> have a great week
10:03 < neg> I have nothing more, thanks all
10:04 < shimoda> thank you!
10:05 < geertu> thx
10:10 -!- shimoda [~shimoda@relprex3.renesas.com] has quit Quit: WeeChat 0.4.2
--- Log closed Mon Jan 16 10:16:36 2017
/**************************************************************************
 * 
 * Copyright 2006 Tungsten Graphics, Inc., Cedar Park, Texas.
 * All Rights Reserved.
 * 
 * Permission is hereby granted, free of charge, to any person obtaining a
 * copy of this software and associated documentation files (the
 * "Software"), to deal in the Software without restriction, including
 * without limitation the rights to use, copy, modify, merge, publish,
 * distribute, sub license, and/or sell copies of the Software, and to
 * permit persons to whom the Software is furnished to do so, subject to
 * the following conditions:
 * 
 * The above copyright notice and this permission notice (including the
 * next paragraph) shall be included in all copies or substantial portions
 * of the Software.
 * 
 * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS
 * OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF
 * MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND NON-INFRINGEMENT.
 * IN NO EVENT SHALL TUNGSTEN GRAPHICS AND/OR ITS SUPPLIERS BE LIABLE FOR
 * ANY CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN AN ACTION OF CONTRACT,
 * TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN CONNECTION WITH THE
 * SOFTWARE OR THE USE OR OTHER DEALINGS IN THE SOFTWARE.
 * 
 **************************************************************************/

/* Originally a fake version of the buffer manager so that we can
 * prototype the changes in a driver fairly quickly, has been fleshed
 * out to a fully functional interim solution.
 *
 * Basically wraps the old style memory management in the new
 * programming interface, but is more expressive and avoids many of
 * the bugs in the old texture manager.
 */

#ifdef HAVE_CONFIG_H
#include "config.h"
#endif

#include <stdlib.h>
#include <string.h>
#include <assert.h>
#include <errno.h>
#include <xf86drm.h>
#include <pthread.h>
#include "intel_bufmgr.h"
#include "intel_bufmgr_priv.h"
#include "drm.h"
#include "i915_drm.h"
#include "mm.h"
#include "libdrm.h"
#include "libdrm_lists.h"

/* Support gcc's __FUNCTION__ for people using other compilers */
#if !defined(__GNUC__) && !defined(__FUNCTION__)
# define __FUNCTION__ __func__ /* C99 */
#endif

#define DBG(...) do {					\
	if (bufmgr_fake->bufmgr.debug)			\
		drmMsg(__VA_ARGS__);			\
} while (0)

/* Internal flags:
 */
#define BM_NO_BACKING_STORE			0x00000001
#define BM_NO_FENCE_SUBDATA			0x00000002
#define BM_PINNED				0x00000004

/* Wrapper around mm.c's mem_block, which understands that you must
 * wait for fences to expire before memory can be freed.  This is
 * specific to our use of memcpy for uploads - an upload that was
 * processed through the command queue wouldn't need to care about
 * fences.
 */
#define MAX_RELOCS 4096

struct fake_buffer_reloc {
	/** Buffer object that the relocation points at. */
	drm_intel_bo *target_buf;
	/** Offset of the relocation entry within reloc_buf. */
	uint32_t offset;
	/**
	 * Cached value of the offset when we last performed this relocation.
	 */
	uint32_t last_target_offset;
	/** Value added to target_buf's offset to get the relocation entry. */
	uint32_t delta;
	/** Cache domains the target buffer is read into. */
	uint32_t read_domains;
	/** Cache domain the target buffer will have dirty cachelines in. */
	uint32_t write_domain;
};

struct block {
	struct block *next, *prev;
	struct mem_block *mem;	/* BM_MEM_AGP */

	/**
	 * Marks that the block is currently in the aperture and has yet to be
	 * fenced.
	 */
	unsigned on_hardware:1;
	/**
	 * Marks that the block is currently fenced (being used by rendering)
	 * and can't be freed until @fence is passed.
	 */
	unsigned fenced:1;

	/** Fence cookie for the block. */
	unsigned fence;		/* Split to read_fence, write_fence */

	drm_intel_bo *bo;
	void *virtual;
};

typedef struct _bufmgr_fake {
	drm_intel_bufmgr bufmgr;

	pthread_mutex_t lock;

	unsigned long low_offset;
	unsigned long size;
	void *virtual;

	struct mem_block *heap;

	unsigned buf_nr;	/* for generating ids */

	/**
	 * List of blocks which are currently in the GART but haven't been
	 * fenced yet.
	 */
	struct block on_hardware;
	/**
	 * List of blocks which are in the GART and have an active fence on
	 * them.
	 */
	struct block fenced;
	/**
	 * List of blocks which have an expired fence and are ready to be
	 * evicted.
	 */
	struct block lru;

	unsigned int last_fence;

	unsigned fail:1;
	unsigned need_fence:1;
	int thrashing;

	/**
	 * Driver callback to emit a fence, returning the cookie.
	 *
	 * This allows the driver to hook in a replacement for the DRM usage in
	 * bufmgr_fake.
	 *
	 * Currently, this also requires that a write flush be emitted before
	 * emitting the fence, but this should change.
	 */
	unsigned int (*fence_emit) (void *private);
	/** Driver callback to wait for a fence cookie to have passed. */
	void (*fence_wait) (unsigned int fence, void *private);
	void *fence_priv;

	/**
	 * Driver callback to execute a buffer.
	 *
	 * This allows the driver to hook in a replacement for the DRM usage in
	 * bufmgr_fake.
	 */
	int (*exec) (drm_intel_bo *bo, unsigned int used, void *priv);
	void *exec_priv;

	/** Driver-supplied argument to driver callbacks */
	void *driver_priv;
	/**
	 * Pointer to kernel-updated sarea data for the last completed user irq
	 */
	volatile int *last_dispatch;

	int fd;

	int debug;

	int performed_rendering;
} drm_intel_bufmgr_fake;

typedef struct _drm_intel_bo_fake {
	drm_intel_bo bo;

	unsigned id;		/* debug only */
	const char *name;

	unsigned dirty:1;
	/**