2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2016-08-17 16:00:34 +08:00
|
|
|
|
2009-08-28 13:00:06 -07:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
2012-02-23 20:18:59 -07:00
|
|
|
|
2012-02-23 14:29:23 -07:00
|
|
|
|
2012-01-21 02:08:27 -08:00
|
|
|
|
|
|
|
|
|
2012-01-21 02:08:26 -08:00
|
|
|
|
|
|
|
|
|
2010-01-22 01:02:21 -08:00
|
|
|
|
|
|
|
|
|
2011-02-14 17:43:20 -08:00
|
|
|
|
2011-07-25 13:08:39 -07:00
|
|
|
|
2010-01-22 01:02:21 -08:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2012-01-21 02:08:30 -08:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2011-02-14 17:43:18 -08:00
|
|
|
|
2011-02-14 17:43:20 -08:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2012-01-21 02:08:27 -08:00
|
|
|
|
2011-02-14 17:43:20 -08:00
|
|
|
|
2011-07-25 13:08:39 -07:00
|
|
|
|
2010-01-22 01:02:21 -08:00
|
|
|
|
2012-01-21 02:08:28 -08:00
|
|
|
|
2010-01-22 01:02:21 -08:00
|
|
|
|
2012-01-21 02:08:27 -08:00
|
|
|
|
2010-01-22 01:02:21 -08:00
|
|
|
|
2014-04-18 20:13:49 -04:00
|
|
|
|
2012-01-21 02:08:18 -08:00
|
|
|
|
2010-01-22 01:02:21 -08:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2011-02-14 17:43:20 -08:00
|
|
|
|
2011-07-25 13:08:39 -07:00
|
|
|
|
2012-01-21 02:08:27 -08:00
|
|
|
|
|
|
|
|
|
2012-01-21 02:08:18 -08:00
|
|
|
|
|
|
|
|
|
2010-01-22 01:02:21 -08:00
|
|
|
|
|
|
|
|
|
2012-01-21 02:08:29 -08:00
|
|
|
|
2012-01-21 02:08:20 -08:00
|
|
|
|
|
|
|
|
|
2012-01-21 02:08:29 -08:00
|
|
|
|
2012-01-21 02:08:20 -08:00
|
|
|
|
2012-01-21 02:08:29 -08:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2012-01-21 02:08:27 -08:00
|
|
|
|
2012-01-21 02:08:20 -08:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2015-03-25 16:23:51 +08:00
|
|
|
|
|
|
|
|
|
2012-01-21 02:08:19 -08:00
|
|
|
|
2012-01-21 02:08:29 -08:00
|
|
|
|
2012-01-21 02:08:19 -08:00
|
|
|
|
2012-01-21 02:08:29 -08:00
|
|
|
|
2016-12-29 11:27:52 -06:00
|
|
|
|
2015-03-25 16:23:51 +08:00
|
|
|
|
2012-01-21 02:08:20 -08:00
|
|
|
|
2012-01-21 02:08:19 -08:00
|
|
|
|
2015-03-25 16:23:51 +08:00
|
|
|
|
2012-01-21 02:08:19 -08:00
|
|
|
|
|
|
|
|
|
2015-03-25 16:23:51 +08:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2012-01-21 02:08:25 -08:00
|
|
|
|
2012-01-21 02:08:27 -08:00
|
|
|
|
2012-01-21 02:08:25 -08:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2012-01-21 02:08:27 -08:00
|
|
|
|
2012-01-21 02:08:25 -08:00
|
|
|
|
2012-01-21 02:08:27 -08:00
|
|
|
|
2012-01-21 02:08:25 -08:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2012-01-21 02:08:27 -08:00
|
|
|
|
|
|
|
|
|
2014-04-18 20:13:50 -04:00
|
|
|
|
2012-01-21 02:08:27 -08:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2012-01-21 02:08:25 -08:00
|
|
|
|
|
|
|
|
|
2012-01-21 02:08:27 -08:00
|
|
|
|
2012-01-21 02:08:25 -08:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2012-01-21 02:08:27 -08:00
|
|
|
|
|
|
|
|
|
2012-01-21 02:08:25 -08:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2010-01-22 01:02:25 -08:00
|
|
|
|
2012-01-21 02:08:27 -08:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
2010-01-22 01:02:25 -08:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
2010-01-22 01:02:25 -08:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
2010-01-22 01:02:25 -08:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
|
|
2010-01-22 01:02:25 -08:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2011-02-14 17:43:19 -08:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2011-02-14 17:43:20 -08:00
|
|
|
|
2011-07-25 13:08:42 -07:00
|
|
|
|
2011-02-14 17:43:20 -08:00
|
|
|
|
2011-07-25 13:08:42 -07:00
|
|
|
|
2011-02-14 17:43:20 -08:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2011-07-25 13:08:42 -07:00
|
|
|
|
2011-02-14 17:43:20 -08:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2012-01-21 02:08:27 -08:00
|
|
|
|
|
|
|
|
|
2011-02-14 17:43:20 -08:00
|
|
|
|
|
|
|
|
|
2012-01-21 02:08:29 -08:00
|
|
|
|
2012-01-21 02:08:27 -08:00
|
|
|
|
2015-03-25 16:23:51 +08:00
|
|
|
|
2011-02-14 17:43:20 -08:00
|
|
|
|
|
|
|
|
|
2012-01-21 02:08:29 -08:00
|
|
|
|
2012-01-21 02:08:27 -08:00
|
|
|
|
|
|
|
|
|
2012-01-21 02:08:29 -08:00
|
|
|
|
2011-02-14 17:43:20 -08:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2012-01-21 02:08:27 -08:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2011-02-14 17:43:20 -08:00
|
|
|
|
2012-01-21 02:08:27 -08:00
|
|
|
|
|
|
|
|
|
2011-02-14 17:43:20 -08:00
|
|
|
|
2012-01-21 02:08:29 -08:00
|
|
|
|
|
|
|
|
|
2015-03-25 16:23:51 +08:00
|
|
|
|
2011-07-25 13:08:39 -07:00
|
|
|
|
2015-03-25 16:23:51 +08:00
|
|
|
|
2011-07-25 13:08:39 -07:00
|
|
|
|
2012-01-21 02:08:29 -08:00
|
|
|
|
2011-02-14 17:43:20 -08:00
|
|
|
|
2011-07-25 13:08:39 -07:00
|
|
|
|
2012-01-21 02:08:29 -08:00
|
|
|
|
2012-01-21 02:08:27 -08:00
|
|
|
|
2012-01-21 02:08:29 -08:00
|
|
|
|
2012-01-21 02:08:27 -08:00
|
|
|
|
2012-01-21 02:08:29 -08:00
|
|
|
|
2012-01-21 02:08:31 -08:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2011-02-14 17:43:20 -08:00
|
|
|
|
|
|
|
|
|
2012-01-21 02:08:29 -08:00
|
|
|
|
|
|
|
|
|
2011-02-14 17:43:20 -08:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2012-06-15 21:15:49 +08:00
|
|
|
|
2011-02-14 17:43:20 -08:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2012-01-21 02:08:27 -08:00
|
|
|
|
|
|
|
|
|
2010-01-22 01:02:25 -08:00
|
|
|
|
|
|
|
|
|
2012-01-21 02:08:27 -08:00
|
|
|
|
2010-01-22 01:02:25 -08:00
|
|
|
|
|
|
|
|
|
2012-01-21 02:08:27 -08:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2013-01-21 13:20:43 -08:00
|
|
|
|
2010-02-28 15:49:39 -08:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2012-01-21 02:08:32 -08:00
|
|
|
|
|
|
|
|
|
2013-11-14 11:28:18 -07:00
|
|
|
|
|
|
|
|
|
2010-02-28 15:49:39 -08:00
|
|
|
|
2011-02-14 17:43:19 -08:00
|
|
|
|
2005-04-28 00:25:50 -07:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2013-07-25 06:31:38 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2012-01-21 02:08:27 -08:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2011-02-14 17:43:20 -08:00
|
|
|
|
2012-01-21 02:08:20 -08:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2012-07-23 22:39:51 +09:00
|
|
|
|
2012-01-21 02:08:20 -08:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2013-07-25 06:31:38 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2012-01-21 02:08:20 -08:00
|
|
|
|
2012-01-21 02:08:27 -08:00
|
|
|
|
|
|
|
|
|
2012-01-21 02:08:29 -08:00
|
|
|
|
2015-03-25 16:23:51 +08:00
|
|
|
|
2013-07-25 06:31:38 -07:00
|
|
|
|
2015-03-25 16:23:51 +08:00
|
|
|
|
2012-01-21 02:08:20 -08:00
|
|
|
|
|
|
|
|
|
2012-01-21 02:08:27 -08:00
|
|
|
|
2012-01-21 02:08:20 -08:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2012-01-21 02:08:27 -08:00
|
|
|
|
|
|
|
|
|
2012-01-21 02:08:30 -08:00
|
|
|
|
2012-01-21 02:08:20 -08:00
|
|
|
|
|
|
|
|
|
2012-01-21 02:08:27 -08:00
|
|
|
|
2012-01-21 02:08:20 -08:00
|
|
|
|
|
|
|
|
|
2015-03-25 16:23:51 +08:00
|
|
|
|
2012-01-21 02:08:27 -08:00
|
|
|
|
|
|
|
|
|
2012-01-21 02:08:20 -08:00
|
|
|
|
2015-03-25 16:23:51 +08:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2015-05-28 22:40:00 -07:00
|
|
|
|
|
|
|
|
|
2015-03-25 16:23:51 +08:00
|
|
|
|
2015-05-28 22:40:00 -07:00
|
|
|
|
2015-03-25 16:23:51 +08:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2015-05-19 14:24:17 +08:00
|
|
|
|
2015-03-25 16:23:51 +08:00
|
|
|
|
|
|
|
|
|
2015-05-19 14:24:17 +08:00
|
|
|
|
|
|
|
|
|
2015-03-25 16:23:51 +08:00
|
|
|
|
2015-12-27 13:21:11 -08:00
|
|
|
|
2015-03-25 16:23:51 +08:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2012-01-21 02:08:20 -08:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2012-01-21 02:08:27 -08:00
|
|
|
|
2012-01-21 02:08:20 -08:00
|
|
|
|
2012-01-21 02:08:27 -08:00
|
|
|
|
|
|
|
|
|
2012-01-21 02:08:30 -08:00
|
|
|
|
|
|
|
|
|
2012-01-21 02:08:20 -08:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2013-07-25 06:31:38 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2012-01-21 02:08:30 -08:00
|
|
|
|
2012-01-21 02:08:20 -08:00
|
|
|
|
2012-01-21 02:08:27 -08:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2012-01-21 02:08:20 -08:00
|
|
|
|
2012-01-21 02:08:29 -08:00
|
|
|
|
|
|
|
|
|
2012-01-21 02:08:20 -08:00
|
|
|
|
2012-01-21 02:08:29 -08:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2012-01-21 02:08:20 -08:00
|
|
|
|
2012-01-21 02:08:30 -08:00
|
|
|
|
2012-01-21 02:08:20 -08:00
|
|
|
|
|
|
|
|
|
2011-02-14 17:43:20 -08:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2011-07-25 13:08:41 -07:00
|
|
|
|
2011-02-14 17:43:20 -08:00
|
|
|
|
2011-07-25 13:08:42 -07:00
|
|
|
|
|
|
|
|
|
2012-01-21 02:08:30 -08:00
|
|
|
|
2011-02-14 17:43:20 -08:00
|
|
|
|
|
|
|
|
|
2010-01-22 01:02:25 -08:00
|
|
|
|
2012-01-21 02:08:27 -08:00
|
|
|
|
|
|
|
|
|
2010-01-22 01:02:25 -08:00
|
|
|
|
2012-01-21 02:08:27 -08:00
|
|
|
|
2010-01-22 01:02:25 -08:00
|
|
|
|
|
|
|
|
|
2012-01-21 02:08:21 -08:00
|
|
|
|
2010-01-22 01:02:25 -08:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2012-01-21 02:08:27 -08:00
|
|
|
|
|
|
|
|
|
2010-01-22 01:02:25 -08:00
|
|
|
|
|
|
|
|
|
2012-01-21 02:08:27 -08:00
|
|
|
|
2010-01-22 01:02:25 -08:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2011-07-25 13:08:42 -07:00
|
|
|
|
2010-01-22 01:02:25 -08:00
|
|
|
|
|
|
|
|
|
2005-09-09 13:03:23 -07:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
|
|
2009-10-27 13:26:47 -06:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
|
|
2012-05-17 18:51:11 -07:00
|
|
|
|
|
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
2009-10-27 13:26:47 -06:00
|
|
|
|
PCI: Convert pcibios_resource_to_bus() to take a pci_bus, not a pci_dev
These interfaces:
pcibios_resource_to_bus(struct pci_dev *dev, *bus_region, *resource)
pcibios_bus_to_resource(struct pci_dev *dev, *resource, *bus_region)
took a pci_dev, but they really depend only on the pci_bus. And we want to
use them in resource allocation paths where we have the bus but not a
device, so this patch converts them to take the pci_bus instead of the
pci_dev:
pcibios_resource_to_bus(struct pci_bus *bus, *bus_region, *resource)
pcibios_bus_to_resource(struct pci_bus *bus, *resource, *bus_region)
In fact, with standard PCI-PCI bridges, they only depend on the host
bridge, because that's the only place address translation occurs, but
we aren't going that far yet.
[bhelgaas: changelog]
Signed-off-by: Yinghai Lu <yinghai@kernel.org>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
2013-12-09 22:54:40 -08:00
|
|
|
|
2009-10-27 13:26:47 -06:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2009-10-27 13:26:47 -06:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2009-10-27 13:26:47 -06:00
|
|
|
|
PCI: Convert pcibios_resource_to_bus() to take a pci_bus, not a pci_dev
These interfaces:
pcibios_resource_to_bus(struct pci_dev *dev, *bus_region, *resource)
pcibios_bus_to_resource(struct pci_dev *dev, *resource, *bus_region)
took a pci_dev, but they really depend only on the pci_bus. And we want to
use them in resource allocation paths where we have the bus but not a
device, so this patch converts them to take the pci_bus instead of the
pci_dev:
pcibios_resource_to_bus(struct pci_bus *bus, *bus_region, *resource)
pcibios_bus_to_resource(struct pci_bus *bus, *resource, *bus_region)
In fact, with standard PCI-PCI bridges, they only depend on the host
bridge, because that's the only place address translation occurs, but
we aren't going that far yet.
[bhelgaas: changelog]
Signed-off-by: Yinghai Lu <yinghai@kernel.org>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
2013-12-09 22:54:40 -08:00
|
|
|
|
2009-10-27 13:26:47 -06:00
|
|
|
|
|
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2009-10-27 13:26:47 -06:00
|
|
|
|
PCI: Convert pcibios_resource_to_bus() to take a pci_bus, not a pci_dev
These interfaces:
pcibios_resource_to_bus(struct pci_dev *dev, *bus_region, *resource)
pcibios_bus_to_resource(struct pci_dev *dev, *resource, *bus_region)
took a pci_dev, but they really depend only on the pci_bus. And we want to
use them in resource allocation paths where we have the bus but not a
device, so this patch converts them to take the pci_bus instead of the
pci_dev:
pcibios_resource_to_bus(struct pci_bus *bus, *bus_region, *resource)
pcibios_bus_to_resource(struct pci_bus *bus, *resource, *bus_region)
In fact, with standard PCI-PCI bridges, they only depend on the host
bridge, because that's the only place address translation occurs, but
we aren't going that far yet.
[bhelgaas: changelog]
Signed-off-by: Yinghai Lu <yinghai@kernel.org>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
2013-12-09 22:54:40 -08:00
|
|
|
|
2009-10-27 13:26:47 -06:00
|
|
|
|
|
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2009-10-27 13:26:47 -06:00
|
|
|
|
PCI: Convert pcibios_resource_to_bus() to take a pci_bus, not a pci_dev
These interfaces:
pcibios_resource_to_bus(struct pci_dev *dev, *bus_region, *resource)
pcibios_bus_to_resource(struct pci_dev *dev, *resource, *bus_region)
took a pci_dev, but they really depend only on the pci_bus. And we want to
use them in resource allocation paths where we have the bus but not a
device, so this patch converts them to take the pci_bus instead of the
pci_dev:
pcibios_resource_to_bus(struct pci_bus *bus, *bus_region, *resource)
pcibios_bus_to_resource(struct pci_bus *bus, *resource, *bus_region)
In fact, with standard PCI-PCI bridges, they only depend on the host
bridge, because that's the only place address translation occurs, but
we aren't going that far yet.
[bhelgaas: changelog]
Signed-off-by: Yinghai Lu <yinghai@kernel.org>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
2013-12-09 22:54:40 -08:00
|
|
|
|
2009-10-27 13:26:47 -06:00
|
|
|
|
|
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2005-09-09 13:03:23 -07:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2015-01-15 10:22:31 -06:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
2009-10-27 13:26:47 -06:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
2012-07-09 13:38:57 -06:00
|
|
|
|
|
|
|
|
|
2013-11-27 17:24:50 -07:00
|
|
|
|
|
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
2012-07-09 13:38:57 -06:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
2015-01-15 10:22:31 -06:00
|
|
|
|
PCI: Convert pcibios_resource_to_bus() to take a pci_bus, not a pci_dev
These interfaces:
pcibios_resource_to_bus(struct pci_dev *dev, *bus_region, *resource)
pcibios_bus_to_resource(struct pci_dev *dev, *resource, *bus_region)
took a pci_dev, but they really depend only on the pci_bus. And we want to
use them in resource allocation paths where we have the bus but not a
device, so this patch converts them to take the pci_bus instead of the
pci_dev:
pcibios_resource_to_bus(struct pci_bus *bus, *bus_region, *resource)
pcibios_bus_to_resource(struct pci_bus *bus, *resource, *bus_region)
In fact, with standard PCI-PCI bridges, they only depend on the host
bridge, because that's the only place address translation occurs, but
we aren't going that far yet.
[bhelgaas: changelog]
Signed-off-by: Yinghai Lu <yinghai@kernel.org>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
2013-12-09 22:54:40 -08:00
|
|
|
|
2009-10-27 13:26:47 -06:00
|
|
|
|
2013-11-27 17:24:50 -07:00
|
|
|
|
2012-07-09 13:38:57 -06:00
|
|
|
|
|
|
|
|
|
2013-11-27 17:24:50 -07:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
|
|
2009-10-27 13:26:47 -06:00
|
|
|
|
2009-12-22 15:02:21 -08:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2013-11-27 17:24:50 -07:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
|
|
2009-12-22 15:02:21 -08:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
2015-01-15 10:22:31 -06:00
|
|
|
|
2009-12-22 15:02:21 -08:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2015-01-15 10:22:31 -06:00
|
|
|
|
PCI: Convert pcibios_resource_to_bus() to take a pci_bus, not a pci_dev
These interfaces:
pcibios_resource_to_bus(struct pci_dev *dev, *bus_region, *resource)
pcibios_bus_to_resource(struct pci_dev *dev, *resource, *bus_region)
took a pci_dev, but they really depend only on the pci_bus. And we want to
use them in resource allocation paths where we have the bus but not a
device, so this patch converts them to take the pci_bus instead of the
pci_dev:
pcibios_resource_to_bus(struct pci_bus *bus, *bus_region, *resource)
pcibios_bus_to_resource(struct pci_bus *bus, *resource, *bus_region)
In fact, with standard PCI-PCI bridges, they only depend on the host
bridge, because that's the only place address translation occurs, but
we aren't going that far yet.
[bhelgaas: changelog]
Signed-off-by: Yinghai Lu <yinghai@kernel.org>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
2013-12-09 22:54:40 -08:00
|
|
|
|
2009-10-27 13:26:47 -06:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
|
|
2009-10-27 13:26:47 -06:00
|
|
|
|
2009-12-22 15:02:21 -08:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2009-12-22 15:02:21 -08:00
|
|
|
|
|
|
|
|
|
2015-01-15 10:22:31 -06:00
|
|
|
|
2009-12-22 15:02:21 -08:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2007-12-10 17:32:15 +11:00
|
|
|
|
2015-01-15 10:22:31 -06:00
|
|
|
|
PCI: Convert pcibios_resource_to_bus() to take a pci_bus, not a pci_dev
These interfaces:
pcibios_resource_to_bus(struct pci_dev *dev, *bus_region, *resource)
pcibios_bus_to_resource(struct pci_dev *dev, *resource, *bus_region)
took a pci_dev, but they really depend only on the pci_bus. And we want to
use them in resource allocation paths where we have the bus but not a
device, so this patch converts them to take the pci_bus instead of the
pci_dev:
pcibios_resource_to_bus(struct pci_bus *bus, *bus_region, *resource)
pcibios_bus_to_resource(struct pci_bus *bus, *resource, *bus_region)
In fact, with standard PCI-PCI bridges, they only depend on the host
bridge, because that's the only place address translation occurs, but
we aren't going that far yet.
[bhelgaas: changelog]
Signed-off-by: Yinghai Lu <yinghai@kernel.org>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
2013-12-09 22:54:40 -08:00
|
|
|
|
2009-10-27 13:26:47 -06:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
|
|
2009-10-27 13:26:47 -06:00
|
|
|
|
2009-04-23 20:48:32 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2009-10-27 13:26:47 -06:00
|
|
|
|
2009-12-22 15:02:21 -08:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2009-11-30 14:51:44 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2009-12-22 15:02:21 -08:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2012-05-17 18:51:11 -07:00
|
|
|
|
|
|
|
|
|
2009-12-22 15:02:21 -08:00
|
|
|
|
|
|
|
|
|
2015-01-15 10:22:31 -06:00
|
|
|
|
2009-12-22 15:02:21 -08:00
|
|
|
|
|
|
|
|
|
2015-01-15 10:22:31 -06:00
|
|
|
|
2009-12-22 15:02:21 -08:00
|
|
|
|
|
|
|
|
|
2015-01-15 10:22:31 -06:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2016-05-20 16:41:25 +10:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2011-09-11 14:08:38 -03:00
|
|
|
|
2009-12-22 15:02:21 -08:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2016-05-20 16:41:25 +10:00
|
|
|
|
2009-12-22 15:02:21 -08:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
PCI: Add pci_claim_bridge_resource() to clip window if necessary
Add pci_claim_bridge_resource() to claim a PCI-PCI bridge window. This is
like regular pci_claim_resource(), except that if we fail to claim the
window, we check to see if we can reduce the size of the window and try
again.
This is for scenarios like this:
pci_bus 0000:00: root bus resource [mem 0xc0000000-0xffffffff]
pci 0000:00:01.0: bridge window [mem 0xbdf00000-0xddefffff 64bit pref]
pci 0000:01:00.0: reg 0x10: [mem 0xc0000000-0xcfffffff pref]
The 00:01.0 window is illegal: it starts before the host bridge window, so
we have to assume the [0xbdf00000-0xbfffffff] region is inaccessible. We
can make it legal by clipping it to [mem 0xc0000000-0xddefffff 64bit pref].
Previously we discarded the 00:01.0 window and tried to reassign that part
of the hierarchy from scratch. That is a problem because Linux doesn't
always assign things optimally. For example, in this case, BIOS put the
01:00.0 device in a prefetchable window below 4GB, but after 5b28541552ef,
Linux puts the prefetchable window above 4GB where the 32-bit 01:00.0
device can't use it.
Clipping the 00:01.0 window is less intrusive than completely reassigning
things and is sufficient to let us use most of the BIOS configuration. Of
course, it's possible that devices below 00:01.0 will no longer fit. If
that's the case, we'll have to reassign things. But that's a separate
problem.
[bhelgaas: changelog, split into separate patch]
Link: https://bugzilla.kernel.org/show_bug.cgi?id=85491
Reported-by: Marek Kordik <kordikmarek@gmail.com>
Fixes: 5b28541552ef ("PCI: Restrict 64-bit prefetchable bridge windows to 64-bit resources")
Signed-off-by: Yinghai Lu <yinghai@kernel.org>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
CC: stable@vger.kernel.org # v3.16+
2015-01-15 16:21:49 -06:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2007-03-26 21:53:30 -08:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
PCI: Prevent bus conflicts while checking for bridge apertures
pci_bridge_check_ranges() determines whether the bridge supports an I/O
aperture and a prefetchable memory aperture.
Previously, if the I/O aperture was unsupported, disabled, or configured at
[io 0x0000-0x0fff], we wrote 0xf0 to PCI_IO_BASE and PCI_IO_LIMIT, which,
if the bridge supports it, enables the I/O aperture at [io 0xf000-0xffff].
The enabled aperture may conflict with other devices in the system.
Similarly, we wrote 0xfff0 to PCI_PREF_MEMORY_BASE and
PCI_PREF_MEMORY_LIMIT, which enables the prefetchable memory aperture at
[mem 0xfff00000-0xffffffff], and that may also conflict with other devices.
All we need to know is whether the base and limit registers are writable,
so we can use values that leave the apertures disabled, e.g., PCI_IO_BASE =
0xf0, PCI_IO_LIMIT = 0xe0, PCI_PREF_MEMORY_BASE = 0xfff0,
PCI_PREF_MEMORY_LIMIT = 0xffe0.
Writing non-zero values to both the base and limit registers means we
detect whether either or both are writable, as we did before.
Reported-by: Jason Gunthorpe <jgunthorpe@obsidianresearch.com>
Based-on-patch-by: Jason Gunthorpe <jgunthorpe@obsidianresearch.com>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
2013-11-27 15:31:07 -07:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
2013-11-14 11:28:18 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
PCI: Prevent bus conflicts while checking for bridge apertures
pci_bridge_check_ranges() determines whether the bridge supports an I/O
aperture and a prefetchable memory aperture.
Previously, if the I/O aperture was unsupported, disabled, or configured at
[io 0x0000-0x0fff], we wrote 0xf0 to PCI_IO_BASE and PCI_IO_LIMIT, which,
if the bridge supports it, enables the I/O aperture at [io 0xf000-0xffff].
The enabled aperture may conflict with other devices in the system.
Similarly, we wrote 0xfff0 to PCI_PREF_MEMORY_BASE and
PCI_PREF_MEMORY_LIMIT, which enables the prefetchable memory aperture at
[mem 0xfff00000-0xffffffff], and that may also conflict with other devices.
All we need to know is whether the base and limit registers are writable,
so we can use values that leave the apertures disabled, e.g., PCI_IO_BASE =
0xf0, PCI_IO_LIMIT = 0xe0, PCI_PREF_MEMORY_BASE = 0xfff0,
PCI_PREF_MEMORY_LIMIT = 0xffe0.
Writing non-zero values to both the base and limit registers means we
detect whether either or both are writable, as we did before.
Reported-by: Jason Gunthorpe <jgunthorpe@obsidianresearch.com>
Based-on-patch-by: Jason Gunthorpe <jgunthorpe@obsidianresearch.com>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
2013-11-27 15:31:07 -07:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
PCI: Prevent bus conflicts while checking for bridge apertures
pci_bridge_check_ranges() determines whether the bridge supports an I/O
aperture and a prefetchable memory aperture.
Previously, if the I/O aperture was unsupported, disabled, or configured at
[io 0x0000-0x0fff], we wrote 0xf0 to PCI_IO_BASE and PCI_IO_LIMIT, which,
if the bridge supports it, enables the I/O aperture at [io 0xf000-0xffff].
The enabled aperture may conflict with other devices in the system.
Similarly, we wrote 0xfff0 to PCI_PREF_MEMORY_BASE and
PCI_PREF_MEMORY_LIMIT, which enables the prefetchable memory aperture at
[mem 0xfff00000-0xffffffff], and that may also conflict with other devices.
All we need to know is whether the base and limit registers are writable,
so we can use values that leave the apertures disabled, e.g., PCI_IO_BASE =
0xf0, PCI_IO_LIMIT = 0xe0, PCI_PREF_MEMORY_BASE = 0xfff0,
PCI_PREF_MEMORY_LIMIT = 0xffe0.
Writing non-zero values to both the base and limit registers means we
detect whether either or both are writable, as we did before.
Reported-by: Jason Gunthorpe <jgunthorpe@obsidianresearch.com>
Based-on-patch-by: Jason Gunthorpe <jgunthorpe@obsidianresearch.com>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
2013-11-27 15:31:07 -07:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
PCI: Prevent bus conflicts while checking for bridge apertures
pci_bridge_check_ranges() determines whether the bridge supports an I/O
aperture and a prefetchable memory aperture.
Previously, if the I/O aperture was unsupported, disabled, or configured at
[io 0x0000-0x0fff], we wrote 0xf0 to PCI_IO_BASE and PCI_IO_LIMIT, which,
if the bridge supports it, enables the I/O aperture at [io 0xf000-0xffff].
The enabled aperture may conflict with other devices in the system.
Similarly, we wrote 0xfff0 to PCI_PREF_MEMORY_BASE and
PCI_PREF_MEMORY_LIMIT, which enables the prefetchable memory aperture at
[mem 0xfff00000-0xffffffff], and that may also conflict with other devices.
All we need to know is whether the base and limit registers are writable,
so we can use values that leave the apertures disabled, e.g., PCI_IO_BASE =
0xf0, PCI_IO_LIMIT = 0xe0, PCI_PREF_MEMORY_BASE = 0xfff0,
PCI_PREF_MEMORY_LIMIT = 0xffe0.
Writing non-zero values to both the base and limit registers means we
detect whether either or both are writable, as we did before.
Reported-by: Jason Gunthorpe <jgunthorpe@obsidianresearch.com>
Based-on-patch-by: Jason Gunthorpe <jgunthorpe@obsidianresearch.com>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
2013-11-27 15:31:07 -07:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2009-04-23 20:48:32 -07:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
2010-01-22 01:02:28 -08:00
|
|
|
|
|
|
|
|
|
2009-04-23 20:48:32 -07:00
|
|
|
|
2010-01-22 01:02:28 -08:00
|
|
|
|
|
|
|
|
|
2009-04-23 20:48:32 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
PCI: Restrict 64-bit prefetchable bridge windows to 64-bit resources
This patch changes the way we handle 64-bit prefetchable bridge windows to
make it more likely that we can assign space to all devices.
Previously we put all prefetchable resources in the prefetchable bridge
window. If any of those resources was 32-bit only, we restricted the
window to be below 4GB.
After this patch, we only put 64-bit prefetchable resources in a 64-bit
prefetchable window. We put all 32-bit prefetchable resources in the
non-prefetchable window, even if there are no 64-bit prefetchable
resources.
With the previous approach, if there was a 32-bit prefetchable resource
behind a bridge, we forced the bridge's prefetchable window below 4GB,
which meant that even if there was plenty of space above 4GB available, we
couldn't use it, and assignment of large 64-bit resources could fail, as
in the bugzilla below.
The new strategy is:
1) If the prefetchable window is 64 bits wide, we put only 64-bit
prefetchable resources in it. Any 32-bit prefetchable resources go in
the non-prefetchable window.
2) If the prefetchable window is 32 bits wide, we put both 32- and 64-bit
prefetchable resources in it.
3) If there is no prefetchable window, all MMIO resources go in the
non-prefetchable window.
This reduces performance for 32-bit prefetchable resources below a bridge
with a 64-bit prefetchable window. We previously assigned prefetchable
space, but now we'll assign non-prefetchable space. This is the case even
if there are no 64-bit prefetchable resources, or if they would all fit
below 4GB. In those cases, the old strategy would work and would have
better performance.
[bhelgaas: write changelog, add bugzilla link, fold in mem64_mask removal]
Link: https://bugzilla.kernel.org/show_bug.cgi?id=74151
Tested-by: Guo Chao <yan@linux.vnet.ibm.com>
Tested-by: Wei Yang <weiyang@linux.vnet.ibm.com>
Signed-off-by: Yinghai Lu <yinghai@kernel.org>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
2014-05-19 17:01:55 -06:00
|
|
|
|
|
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2010-02-23 10:24:31 -07:00
|
|
|
|
2005-06-15 18:59:27 +04:00
|
|
|
|
|
|
|
|
|
2009-10-27 09:39:18 -07:00
|
|
|
|
|
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2011-02-14 17:43:17 -08:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2014-04-18 20:13:49 -04:00
|
|
|
|
2011-02-14 17:43:17 -08:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2014-04-18 20:13:49 -04:00
|
|
|
|
2011-02-14 17:43:17 -08:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2012-09-11 16:59:45 -06:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2011-02-14 17:43:20 -08:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2011-07-25 13:08:42 -07:00
|
|
|
|
2011-02-14 17:43:20 -08:00
|
|
|
|
|
|
|
|
|
2012-07-09 19:55:29 -06:00
|
|
|
|
2011-02-14 17:43:20 -08:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2012-01-21 02:08:27 -08:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
|
|
PCI: Restrict 64-bit prefetchable bridge windows to 64-bit resources
This patch changes the way we handle 64-bit prefetchable bridge windows to
make it more likely that we can assign space to all devices.
Previously we put all prefetchable resources in the prefetchable bridge
window. If any of those resources was 32-bit only, we restricted the
window to be below 4GB.
After this patch, we only put 64-bit prefetchable resources in a 64-bit
prefetchable window. We put all 32-bit prefetchable resources in the
non-prefetchable window, even if there are no 64-bit prefetchable
resources.
With the previous approach, if there was a 32-bit prefetchable resource
behind a bridge, we forced the bridge's prefetchable window below 4GB,
which meant that even if there was plenty of space above 4GB available, we
couldn't use it, and assignment of large 64-bit resources could fail, as
in the bugzilla below.
The new strategy is:
1) If the prefetchable window is 64 bits wide, we put only 64-bit
prefetchable resources in it. Any 32-bit prefetchable resources go in
the non-prefetchable window.
2) If the prefetchable window is 32 bits wide, we put both 32- and 64-bit
prefetchable resources in it.
3) If there is no prefetchable window, all MMIO resources go in the
non-prefetchable window.
This reduces performance for 32-bit prefetchable resources below a bridge
with a 64-bit prefetchable window. We previously assigned prefetchable
space, but now we'll assign non-prefetchable space. This is the case even
if there are no 64-bit prefetchable resources, or if they would all fit
below 4GB. In those cases, the old strategy would work and would have
better performance.
[bhelgaas: write changelog, add bugzilla link, fold in mem64_mask removal]
Link: https://bugzilla.kernel.org/show_bug.cgi?id=74151
Tested-by: Guo Chao <yan@linux.vnet.ibm.com>
Tested-by: Wei Yang <weiyang@linux.vnet.ibm.com>
Signed-off-by: Yinghai Lu <yinghai@kernel.org>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
2014-05-19 17:01:55 -06:00
|
|
|
|
|
|
|
|
|
2013-08-02 17:31:05 +08:00
|
|
|
|
2011-07-25 13:08:38 -07:00
|
|
|
|
2013-08-05 16:15:10 -06:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
|
|
2013-11-14 11:28:18 -07:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
2013-08-05 16:15:10 -06:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2008-10-13 19:24:28 +08:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2011-07-25 13:08:38 -07:00
|
|
|
|
2012-07-09 19:55:29 -06:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2011-07-25 13:08:42 -07:00
|
|
|
|
|
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
|
|
2012-07-09 19:55:29 -06:00
|
|
|
|
2011-02-14 17:43:20 -08:00
|
|
|
|
2012-07-09 19:55:29 -06:00
|
|
|
|
2011-07-25 13:08:38 -07:00
|
|
|
|
|
|
|
|
|
2011-07-25 13:08:42 -07:00
|
|
|
|
2012-01-21 02:08:17 -08:00
|
|
|
|
2012-07-09 19:55:29 -06:00
|
|
|
|
2011-02-14 17:43:20 -08:00
|
|
|
|
2009-11-04 10:32:57 -07:00
|
|
|
|
2014-04-18 20:13:50 -04:00
|
|
|
|
|
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2012-07-09 19:55:29 -06:00
|
|
|
|
|
|
|
|
|
2011-02-14 17:43:20 -08:00
|
|
|
|
PCI: clean up resource alignment management
Done per Linus' request and suggestions. Linus has explained that
better than I'll be able to explain:
On Thu, Mar 27, 2008 at 10:12:10AM -0700, Linus Torvalds wrote:
> Actually, before we go any further, there might be a less intrusive
> alternative: add just a couple of flags to the resource flags field (we
> still have something like 8 unused bits on 32-bit), and use those to
> implement a generic "resource_alignment()" routine.
>
> Two flags would do it:
>
> - IORESOURCE_SIZEALIGN: size indicates alignment (regular PCI device
> resources)
>
> - IORESOURCE_STARTALIGN: start field is alignment (PCI bus resources
> during probing)
>
> and then the case of both flags zero (or both bits set) would actually be
> "invalid", and we would also clear the IORESOURCE_STARTALIGN flag when we
> actually allocate the resource (so that we don't use the "start" field as
> alignment incorrectly when it no longer indicates alignment).
>
> That wouldn't be totally generic, but it would have the nice property of
> automatically at least add sanity checking for that whole "res->start has
> the odd meaning of 'alignment' during probing" and remove the need for a
> new field, and it would allow us to have a generic "resource_alignment()"
> routine that just gets a resource pointer.
Besides, I removed IORESOURCE_BUS_HAS_VGA flag which was unused for ages.
Signed-off-by: Ivan Kokshaysky <ink@jurassic.park.msu.ru>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Gary Hade <garyhade@us.ibm.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2008-03-30 19:50:14 +04:00
|
|
|
|
2012-01-21 02:08:31 -08:00
|
|
|
|
2012-07-09 19:55:29 -06:00
|
|
|
|
|
|
|
|
|
2014-04-18 20:13:50 -04:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2012-01-21 02:08:31 -08:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
|
|
2012-09-11 16:59:46 -06:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2011-02-14 17:43:20 -08:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2013-08-02 17:31:04 +08:00
|
|
|
|
|
|
|
|
|
PCI: Restrict 64-bit prefetchable bridge windows to 64-bit resources
This patch changes the way we handle 64-bit prefetchable bridge windows to
make it more likely that we can assign space to all devices.
Previously we put all prefetchable resources in the prefetchable bridge
window. If any of those resources was 32-bit only, we restricted the
window to be below 4GB.
After this patch, we only put 64-bit prefetchable resources in a 64-bit
prefetchable window. We put all 32-bit prefetchable resources in the
non-prefetchable window, even if there are no 64-bit prefetchable
resources.
With the previous approach, if there was a 32-bit prefetchable resource
behind a bridge, we forced the bridge's prefetchable window below 4GB,
which meant that even if there was plenty of space above 4GB available, we
couldn't use it, and assignment of large 64-bit resources could fail, as
in the bugzilla below.
The new strategy is:
1) If the prefetchable window is 64 bits wide, we put only 64-bit
prefetchable resources in it. Any 32-bit prefetchable resources go in
the non-prefetchable window.
2) If the prefetchable window is 32 bits wide, we put both 32- and 64-bit
prefetchable resources in it.
3) If there is no prefetchable window, all MMIO resources go in the
non-prefetchable window.
This reduces performance for 32-bit prefetchable resources below a bridge
with a 64-bit prefetchable window. We previously assigned prefetchable
space, but now we'll assign non-prefetchable space. This is the case even
if there are no 64-bit prefetchable resources, or if they would all fit
below 4GB. In those cases, the old strategy would work and would have
better performance.
[bhelgaas: write changelog, add bugzilla link, fold in mem64_mask removal]
Link: https://bugzilla.kernel.org/show_bug.cgi?id=74151
Tested-by: Guo Chao <yan@linux.vnet.ibm.com>
Tested-by: Wei Yang <weiyang@linux.vnet.ibm.com>
Signed-off-by: Yinghai Lu <yinghai@kernel.org>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
2014-05-19 17:01:55 -06:00
|
|
|
|
|
|
|
|
|
2011-02-14 17:43:20 -08:00
|
|
|
|
|
|
|
|
|
2011-07-25 13:08:42 -07:00
|
|
|
|
2011-02-14 17:43:20 -08:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2014-05-19 18:28:37 -06:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2011-02-14 17:43:20 -08:00
|
|
|
|
2009-09-09 14:09:24 -07:00
|
|
|
|
PCI: Restrict 64-bit prefetchable bridge windows to 64-bit resources
This patch changes the way we handle 64-bit prefetchable bridge windows to
make it more likely that we can assign space to all devices.
Previously we put all prefetchable resources in the prefetchable bridge
window. If any of those resources was 32-bit only, we restricted the
window to be below 4GB.
After this patch, we only put 64-bit prefetchable resources in a 64-bit
prefetchable window. We put all 32-bit prefetchable resources in the
non-prefetchable window, even if there are no 64-bit prefetchable
resources.
With the previous approach, if there was a 32-bit prefetchable resource
behind a bridge, we forced the bridge's prefetchable window below 4GB,
which meant that even if there was plenty of space above 4GB available, we
couldn't use it, and assignment of large 64-bit resources could fail, as
in the bugzilla below.
The new strategy is:
1) If the prefetchable window is 64 bits wide, we put only 64-bit
prefetchable resources in it. Any 32-bit prefetchable resources go in
the non-prefetchable window.
2) If the prefetchable window is 32 bits wide, we put both 32- and 64-bit
prefetchable resources in it.
3) If there is no prefetchable window, all MMIO resources go in the
non-prefetchable window.
This reduces performance for 32-bit prefetchable resources below a bridge
with a 64-bit prefetchable window. We previously assigned prefetchable
space, but now we'll assign non-prefetchable space. This is the case even
if there are no 64-bit prefetchable resources, or if they would all fit
below 4GB. In those cases, the old strategy would work and would have
better performance.
[bhelgaas: write changelog, add bugzilla link, fold in mem64_mask removal]
Link: https://bugzilla.kernel.org/show_bug.cgi?id=74151
Tested-by: Guo Chao <yan@linux.vnet.ibm.com>
Tested-by: Wei Yang <weiyang@linux.vnet.ibm.com>
Signed-off-by: Yinghai Lu <yinghai@kernel.org>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
2014-05-19 17:01:55 -06:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
|
|
2011-02-14 17:43:20 -08:00
|
|
|
|
2014-07-03 13:46:17 -07:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
PCI: Restrict 64-bit prefetchable bridge windows to 64-bit resources
This patch changes the way we handle 64-bit prefetchable bridge windows to
make it more likely that we can assign space to all devices.
Previously we put all prefetchable resources in the prefetchable bridge
window. If any of those resources was 32-bit only, we restricted the
window to be below 4GB.
After this patch, we only put 64-bit prefetchable resources in a 64-bit
prefetchable window. We put all 32-bit prefetchable resources in the
non-prefetchable window, even if there are no 64-bit prefetchable
resources.
With the previous approach, if there was a 32-bit prefetchable resource
behind a bridge, we forced the bridge's prefetchable window below 4GB,
which meant that even if there was plenty of space above 4GB available, we
couldn't use it, and assignment of large 64-bit resources could fail, as
in the bugzilla below.
The new strategy is:
1) If the prefetchable window is 64 bits wide, we put only 64-bit
prefetchable resources in it. Any 32-bit prefetchable resources go in
the non-prefetchable window.
2) If the prefetchable window is 32 bits wide, we put both 32- and 64-bit
prefetchable resources in it.
3) If there is no prefetchable window, all MMIO resources go in the
non-prefetchable window.
This reduces performance for 32-bit prefetchable resources below a bridge
with a 64-bit prefetchable window. We previously assigned prefetchable
space, but now we'll assign non-prefetchable space. This is the case even
if there are no 64-bit prefetchable resources, or if they would all fit
below 4GB. In those cases, the old strategy would work and would have
better performance.
[bhelgaas: write changelog, add bugzilla link, fold in mem64_mask removal]
Link: https://bugzilla.kernel.org/show_bug.cgi?id=74151
Tested-by: Guo Chao <yan@linux.vnet.ibm.com>
Tested-by: Wei Yang <weiyang@linux.vnet.ibm.com>
Signed-off-by: Yinghai Lu <yinghai@kernel.org>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
2014-05-19 17:01:55 -06:00
|
|
|
|
|
|
|
|
|
2011-07-25 13:08:38 -07:00
|
|
|
|
2015-03-25 16:23:51 +08:00
|
|
|
|
|
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
|
|
2014-05-19 18:28:37 -06:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2009-04-23 20:48:32 -07:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
|
|
2007-12-10 17:32:15 +11:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
2015-10-29 17:35:39 -05:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
2008-10-13 19:24:28 +08:00
|
|
|
|
2011-07-25 13:08:40 -07:00
|
|
|
|
|
|
|
|
|
2011-07-25 13:08:42 -07:00
|
|
|
|
2011-07-25 13:08:40 -07:00
|
|
|
|
2015-03-25 16:23:51 +08:00
|
|
|
|
2011-07-25 13:08:40 -07:00
|
|
|
|
2013-11-14 11:28:18 -07:00
|
|
|
|
2011-07-25 13:08:40 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2014-05-19 14:03:14 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2009-08-28 13:00:06 -07:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
2014-05-19 14:03:14 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2014-04-18 20:13:50 -04:00
|
|
|
|
|
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2017-04-10 19:58:11 +08:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
|
|
2017-04-10 19:58:11 +08:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2011-07-25 13:08:38 -07:00
|
|
|
|
2015-03-25 16:23:51 +08:00
|
|
|
|
2011-07-25 13:08:42 -07:00
|
|
|
|
2015-03-25 16:23:51 +08:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
|
|
2012-09-11 16:59:46 -06:00
|
|
|
|
2012-09-11 16:59:46 -06:00
|
|
|
|
2013-09-06 09:45:58 +08:00
|
|
|
|
2011-04-11 10:53:11 -07:00
|
|
|
|
2015-03-25 16:23:51 +08:00
|
|
|
|
2011-07-25 13:08:38 -07:00
|
|
|
|
|
|
|
|
|
2011-07-25 13:08:42 -07:00
|
|
|
|
2012-01-21 02:08:17 -08:00
|
|
|
|
2015-03-25 16:23:51 +08:00
|
|
|
|
2011-02-14 17:43:20 -08:00
|
|
|
|
2009-11-04 10:32:57 -07:00
|
|
|
|
2014-04-18 20:13:50 -04:00
|
|
|
|
|
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
2014-05-19 18:28:37 -06:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
|
|
2011-02-14 17:43:20 -08:00
|
|
|
|
PCI: Restrict 64-bit prefetchable bridge windows to 64-bit resources
This patch changes the way we handle 64-bit prefetchable bridge windows to
make it more likely that we can assign space to all devices.
Previously we put all prefetchable resources in the prefetchable bridge
window. If any of those resources was 32-bit only, we restricted the
window to be below 4GB.
After this patch, we only put 64-bit prefetchable resources in a 64-bit
prefetchable window. We put all 32-bit prefetchable resources in the
non-prefetchable window, even if there are no 64-bit prefetchable
resources.
With the previous approach, if there was a 32-bit prefetchable resource
behind a bridge, we forced the bridge's prefetchable window below 4GB,
which meant that even if there was plenty of space above 4GB available, we
couldn't use it, and assignment of large 64-bit resources could fail, as
in the bugzilla below.
The new strategy is:
1) If the prefetchable window is 64 bits wide, we put only 64-bit
prefetchable resources in it. Any 32-bit prefetchable resources go in
the non-prefetchable window.
2) If the prefetchable window is 32 bits wide, we put both 32- and 64-bit
prefetchable resources in it.
3) If there is no prefetchable window, all MMIO resources go in the
non-prefetchable window.
This reduces performance for 32-bit prefetchable resources below a bridge
with a 64-bit prefetchable window. We previously assigned prefetchable
space, but now we'll assign non-prefetchable space. This is the case even
if there are no 64-bit prefetchable resources, or if they would all fit
below 4GB. In those cases, the old strategy would work and would have
better performance.
[bhelgaas: write changelog, add bugzilla link, fold in mem64_mask removal]
Link: https://bugzilla.kernel.org/show_bug.cgi?id=74151
Tested-by: Guo Chao <yan@linux.vnet.ibm.com>
Tested-by: Wei Yang <weiyang@linux.vnet.ibm.com>
Signed-off-by: Yinghai Lu <yinghai@kernel.org>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
2014-05-19 17:01:55 -06:00
|
|
|
|
2012-01-21 02:08:31 -08:00
|
|
|
|
2015-03-25 16:23:51 +08:00
|
|
|
|
|
|
|
|
|
2014-04-18 20:13:50 -04:00
|
|
|
|
2015-03-25 16:23:51 +08:00
|
|
|
|
|
|
|
|
|
2012-01-21 02:08:31 -08:00
|
|
|
|
2014-05-19 18:28:37 -06:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
|
|
2011-07-25 13:08:41 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2012-01-21 02:08:27 -08:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2012-02-10 15:33:47 -08:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
|
|
2012-02-10 15:33:48 -08:00
|
|
|
|
|
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2012-02-10 15:33:47 -08:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
2012-02-10 15:33:48 -08:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2012-02-10 15:33:47 -08:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
2012-02-10 15:33:48 -08:00
|
|
|
|
2012-02-10 15:33:46 -08:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2012-02-10 15:33:48 -08:00
|
|
|
|
|
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2012-02-10 15:33:47 -08:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
2012-02-10 15:33:47 -08:00
|
|
|
|
|
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
2011-07-25 13:08:41 -07:00
|
|
|
|
2012-02-10 15:33:48 -08:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2012-02-10 15:33:47 -08:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2012-02-10 15:33:48 -08:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
|
|
2014-04-14 16:11:40 -06:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
|
|
PCI: Restrict 64-bit prefetchable bridge windows to 64-bit resources
This patch changes the way we handle 64-bit prefetchable bridge windows to
make it more likely that we can assign space to all devices.
Previously we put all prefetchable resources in the prefetchable bridge
window. If any of those resources was 32-bit only, we restricted the
window to be below 4GB.
After this patch, we only put 64-bit prefetchable resources in a 64-bit
prefetchable window. We put all 32-bit prefetchable resources in the
non-prefetchable window, even if there are no 64-bit prefetchable
resources.
With the previous approach, if there was a 32-bit prefetchable resource
behind a bridge, we forced the bridge's prefetchable window below 4GB,
which meant that even if there was plenty of space above 4GB available, we
couldn't use it, and assignment of large 64-bit resources could fail, as
in the bugzilla below.
The new strategy is:
1) If the prefetchable window is 64 bits wide, we put only 64-bit
prefetchable resources in it. Any 32-bit prefetchable resources go in
the non-prefetchable window.
2) If the prefetchable window is 32 bits wide, we put both 32- and 64-bit
prefetchable resources in it.
3) If there is no prefetchable window, all MMIO resources go in the
non-prefetchable window.
This reduces performance for 32-bit prefetchable resources below a bridge
with a 64-bit prefetchable window. We previously assigned prefetchable
space, but now we'll assign non-prefetchable space. This is the case even
if there are no 64-bit prefetchable resources, or if they would all fit
below 4GB. In those cases, the old strategy would work and would have
better performance.
[bhelgaas: write changelog, add bugzilla link, fold in mem64_mask removal]
Link: https://bugzilla.kernel.org/show_bug.cgi?id=74151
Tested-by: Guo Chao <yan@linux.vnet.ibm.com>
Tested-by: Wei Yang <weiyang@linux.vnet.ibm.com>
Signed-off-by: Yinghai Lu <yinghai@kernel.org>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
2014-05-19 17:01:55 -06:00
|
|
|
|
2011-02-14 17:43:20 -08:00
|
|
|
|
PCI: Restrict 64-bit prefetchable bridge windows to 64-bit resources
This patch changes the way we handle 64-bit prefetchable bridge windows to
make it more likely that we can assign space to all devices.
Previously we put all prefetchable resources in the prefetchable bridge
window. If any of those resources was 32-bit only, we restricted the
window to be below 4GB.
After this patch, we only put 64-bit prefetchable resources in a 64-bit
prefetchable window. We put all 32-bit prefetchable resources in the
non-prefetchable window, even if there are no 64-bit prefetchable
resources.
With the previous approach, if there was a 32-bit prefetchable resource
behind a bridge, we forced the bridge's prefetchable window below 4GB,
which meant that even if there was plenty of space above 4GB available, we
couldn't use it, and assignment of large 64-bit resources could fail, as
in the bugzilla below.
The new strategy is:
1) If the prefetchable window is 64 bits wide, we put only 64-bit
prefetchable resources in it. Any 32-bit prefetchable resources go in
the non-prefetchable window.
2) If the prefetchable window is 32 bits wide, we put both 32- and 64-bit
prefetchable resources in it.
3) If there is no prefetchable window, all MMIO resources go in the
non-prefetchable window.
This reduces performance for 32-bit prefetchable resources below a bridge
with a 64-bit prefetchable window. We previously assigned prefetchable
space, but now we'll assign non-prefetchable space. This is the case even
if there are no 64-bit prefetchable resources, or if they would all fit
below 4GB. In those cases, the old strategy would work and would have
better performance.
[bhelgaas: write changelog, add bugzilla link, fold in mem64_mask removal]
Link: https://bugzilla.kernel.org/show_bug.cgi?id=74151
Tested-by: Guo Chao <yan@linux.vnet.ibm.com>
Tested-by: Wei Yang <weiyang@linux.vnet.ibm.com>
Signed-off-by: Yinghai Lu <yinghai@kernel.org>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
2014-05-19 17:01:55 -06:00
|
|
|
|
2014-05-19 18:28:37 -06:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2011-07-25 13:08:42 -07:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2011-07-25 13:08:42 -07:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2013-09-06 09:45:56 +08:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2009-09-09 14:09:24 -07:00
|
|
|
|
2011-02-14 17:43:20 -08:00
|
|
|
|
|
|
|
|
|
2009-09-09 14:09:24 -07:00
|
|
|
|
2014-05-19 18:32:18 -06:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
2012-01-21 02:08:24 -08:00
|
|
|
|
|
|
|
|
|
2014-05-19 18:32:18 -06:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
PCI: Restrict 64-bit prefetchable bridge windows to 64-bit resources
This patch changes the way we handle 64-bit prefetchable bridge windows to
make it more likely that we can assign space to all devices.
Previously we put all prefetchable resources in the prefetchable bridge
window. If any of those resources was 32-bit only, we restricted the
window to be below 4GB.
After this patch, we only put 64-bit prefetchable resources in a 64-bit
prefetchable window. We put all 32-bit prefetchable resources in the
non-prefetchable window, even if there are no 64-bit prefetchable
resources.
With the previous approach, if there was a 32-bit prefetchable resource
behind a bridge, we forced the bridge's prefetchable window below 4GB,
which meant that even if there was plenty of space above 4GB available, we
couldn't use it, and assignment of large 64-bit resources could fail, as
in the bugzilla below.
The new strategy is:
1) If the prefetchable window is 64 bits wide, we put only 64-bit
prefetchable resources in it. Any 32-bit prefetchable resources go in
the non-prefetchable window.
2) If the prefetchable window is 32 bits wide, we put both 32- and 64-bit
prefetchable resources in it.
3) If there is no prefetchable window, all MMIO resources go in the
non-prefetchable window.
This reduces performance for 32-bit prefetchable resources below a bridge
with a 64-bit prefetchable window. We previously assigned prefetchable
space, but now we'll assign non-prefetchable space. This is the case even
if there are no 64-bit prefetchable resources, or if they would all fit
below 4GB. In those cases, the old strategy would work and would have
better performance.
[bhelgaas: write changelog, add bugzilla link, fold in mem64_mask removal]
Link: https://bugzilla.kernel.org/show_bug.cgi?id=74151
Tested-by: Guo Chao <yan@linux.vnet.ibm.com>
Tested-by: Wei Yang <weiyang@linux.vnet.ibm.com>
Signed-off-by: Yinghai Lu <yinghai@kernel.org>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
2014-05-19 17:01:55 -06:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
|
|
PCI: Restrict 64-bit prefetchable bridge windows to 64-bit resources
This patch changes the way we handle 64-bit prefetchable bridge windows to
make it more likely that we can assign space to all devices.
Previously we put all prefetchable resources in the prefetchable bridge
window. If any of those resources was 32-bit only, we restricted the
window to be below 4GB.
After this patch, we only put 64-bit prefetchable resources in a 64-bit
prefetchable window. We put all 32-bit prefetchable resources in the
non-prefetchable window, even if there are no 64-bit prefetchable
resources.
With the previous approach, if there was a 32-bit prefetchable resource
behind a bridge, we forced the bridge's prefetchable window below 4GB,
which meant that even if there was plenty of space above 4GB available, we
couldn't use it, and assignment of large 64-bit resources could fail, as
in the bugzilla below.
The new strategy is:
1) If the prefetchable window is 64 bits wide, we put only 64-bit
prefetchable resources in it. Any 32-bit prefetchable resources go in
the non-prefetchable window.
2) If the prefetchable window is 32 bits wide, we put both 32- and 64-bit
prefetchable resources in it.
3) If there is no prefetchable window, all MMIO resources go in the
non-prefetchable window.
This reduces performance for 32-bit prefetchable resources below a bridge
with a 64-bit prefetchable window. We previously assigned prefetchable
space, but now we'll assign non-prefetchable space. This is the case even
if there are no 64-bit prefetchable resources, or if they would all fit
below 4GB. In those cases, the old strategy would work and would have
better performance.
[bhelgaas: write changelog, add bugzilla link, fold in mem64_mask removal]
Link: https://bugzilla.kernel.org/show_bug.cgi?id=74151
Tested-by: Guo Chao <yan@linux.vnet.ibm.com>
Tested-by: Wei Yang <weiyang@linux.vnet.ibm.com>
Signed-off-by: Yinghai Lu <yinghai@kernel.org>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
2014-05-19 17:01:55 -06:00
|
|
|
|
|
|
|
|
|
2014-05-19 18:28:37 -06:00
|
|
|
|
PCI: Restrict 64-bit prefetchable bridge windows to 64-bit resources
This patch changes the way we handle 64-bit prefetchable bridge windows to
make it more likely that we can assign space to all devices.
Previously we put all prefetchable resources in the prefetchable bridge
window. If any of those resources was 32-bit only, we restricted the
window to be below 4GB.
After this patch, we only put 64-bit prefetchable resources in a 64-bit
prefetchable window. We put all 32-bit prefetchable resources in the
non-prefetchable window, even if there are no 64-bit prefetchable
resources.
With the previous approach, if there was a 32-bit prefetchable resource
behind a bridge, we forced the bridge's prefetchable window below 4GB,
which meant that even if there was plenty of space above 4GB available, we
couldn't use it, and assignment of large 64-bit resources could fail, as
in the bugzilla below.
The new strategy is:
1) If the prefetchable window is 64 bits wide, we put only 64-bit
prefetchable resources in it. Any 32-bit prefetchable resources go in
the non-prefetchable window.
2) If the prefetchable window is 32 bits wide, we put both 32- and 64-bit
prefetchable resources in it.
3) If there is no prefetchable window, all MMIO resources go in the
non-prefetchable window.
This reduces performance for 32-bit prefetchable resources below a bridge
with a 64-bit prefetchable window. We previously assigned prefetchable
space, but now we'll assign non-prefetchable space. This is the case even
if there are no 64-bit prefetchable resources, or if they would all fit
below 4GB. In those cases, the old strategy would work and would have
better performance.
[bhelgaas: write changelog, add bugzilla link, fold in mem64_mask removal]
Link: https://bugzilla.kernel.org/show_bug.cgi?id=74151
Tested-by: Guo Chao <yan@linux.vnet.ibm.com>
Tested-by: Wei Yang <weiyang@linux.vnet.ibm.com>
Signed-off-by: Yinghai Lu <yinghai@kernel.org>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
2014-05-19 17:01:55 -06:00
|
|
|
|
2012-01-21 02:08:24 -08:00
|
|
|
|
2014-05-19 18:28:37 -06:00
|
|
|
|
2014-05-19 18:32:18 -06:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2014-05-19 18:28:37 -06:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
PCI: Restrict 64-bit prefetchable bridge windows to 64-bit resources
This patch changes the way we handle 64-bit prefetchable bridge windows to
make it more likely that we can assign space to all devices.
Previously we put all prefetchable resources in the prefetchable bridge
window. If any of those resources was 32-bit only, we restricted the
window to be below 4GB.
After this patch, we only put 64-bit prefetchable resources in a 64-bit
prefetchable window. We put all 32-bit prefetchable resources in the
non-prefetchable window, even if there are no 64-bit prefetchable
resources.
With the previous approach, if there was a 32-bit prefetchable resource
behind a bridge, we forced the bridge's prefetchable window below 4GB,
which meant that even if there was plenty of space above 4GB available, we
couldn't use it, and assignment of large 64-bit resources could fail, as
in the bugzilla below.
The new strategy is:
1) If the prefetchable window is 64 bits wide, we put only 64-bit
prefetchable resources in it. Any 32-bit prefetchable resources go in
the non-prefetchable window.
2) If the prefetchable window is 32 bits wide, we put both 32- and 64-bit
prefetchable resources in it.
3) If there is no prefetchable window, all MMIO resources go in the
non-prefetchable window.
This reduces performance for 32-bit prefetchable resources below a bridge
with a 64-bit prefetchable window. We previously assigned prefetchable
space, but now we'll assign non-prefetchable space. This is the case even
if there are no 64-bit prefetchable resources, or if they would all fit
below 4GB. In those cases, the old strategy would work and would have
better performance.
[bhelgaas: write changelog, add bugzilla link, fold in mem64_mask removal]
Link: https://bugzilla.kernel.org/show_bug.cgi?id=74151
Tested-by: Guo Chao <yan@linux.vnet.ibm.com>
Tested-by: Wei Yang <weiyang@linux.vnet.ibm.com>
Signed-off-by: Yinghai Lu <yinghai@kernel.org>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
2014-05-19 17:01:55 -06:00
|
|
|
|
|
|
|
|
|
2014-05-19 18:32:18 -06:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
PCI: Restrict 64-bit prefetchable bridge windows to 64-bit resources
This patch changes the way we handle 64-bit prefetchable bridge windows to
make it more likely that we can assign space to all devices.
Previously we put all prefetchable resources in the prefetchable bridge
window. If any of those resources was 32-bit only, we restricted the
window to be below 4GB.
After this patch, we only put 64-bit prefetchable resources in a 64-bit
prefetchable window. We put all 32-bit prefetchable resources in the
non-prefetchable window, even if there are no 64-bit prefetchable
resources.
With the previous approach, if there was a 32-bit prefetchable resource
behind a bridge, we forced the bridge's prefetchable window below 4GB,
which meant that even if there was plenty of space above 4GB available, we
couldn't use it, and assignment of large 64-bit resources could fail, as
in the bugzilla below.
The new strategy is:
1) If the prefetchable window is 64 bits wide, we put only 64-bit
prefetchable resources in it. Any 32-bit prefetchable resources go in
the non-prefetchable window.
2) If the prefetchable window is 32 bits wide, we put both 32- and 64-bit
prefetchable resources in it.
3) If there is no prefetchable window, all MMIO resources go in the
non-prefetchable window.
This reduces performance for 32-bit prefetchable resources below a bridge
with a 64-bit prefetchable window. We previously assigned prefetchable
space, but now we'll assign non-prefetchable space. This is the case even
if there are no 64-bit prefetchable resources, or if they would all fit
below 4GB. In those cases, the old strategy would work and would have
better performance.
[bhelgaas: write changelog, add bugzilla link, fold in mem64_mask removal]
Link: https://bugzilla.kernel.org/show_bug.cgi?id=74151
Tested-by: Guo Chao <yan@linux.vnet.ibm.com>
Tested-by: Wei Yang <weiyang@linux.vnet.ibm.com>
Signed-off-by: Yinghai Lu <yinghai@kernel.org>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
2014-05-19 17:01:55 -06:00
|
|
|
|
|
|
|
|
|
2014-05-19 18:28:37 -06:00
|
|
|
|
PCI: Restrict 64-bit prefetchable bridge windows to 64-bit resources
This patch changes the way we handle 64-bit prefetchable bridge windows to
make it more likely that we can assign space to all devices.
Previously we put all prefetchable resources in the prefetchable bridge
window. If any of those resources was 32-bit only, we restricted the
window to be below 4GB.
After this patch, we only put 64-bit prefetchable resources in a 64-bit
prefetchable window. We put all 32-bit prefetchable resources in the
non-prefetchable window, even if there are no 64-bit prefetchable
resources.
With the previous approach, if there was a 32-bit prefetchable resource
behind a bridge, we forced the bridge's prefetchable window below 4GB,
which meant that even if there was plenty of space above 4GB available, we
couldn't use it, and assignment of large 64-bit resources could fail, as
in the bugzilla below.
The new strategy is:
1) If the prefetchable window is 64 bits wide, we put only 64-bit
prefetchable resources in it. Any 32-bit prefetchable resources go in
the non-prefetchable window.
2) If the prefetchable window is 32 bits wide, we put both 32- and 64-bit
prefetchable resources in it.
3) If there is no prefetchable window, all MMIO resources go in the
non-prefetchable window.
This reduces performance for 32-bit prefetchable resources below a bridge
with a 64-bit prefetchable window. We previously assigned prefetchable
space, but now we'll assign non-prefetchable space. This is the case even
if there are no 64-bit prefetchable resources, or if they would all fit
below 4GB. In those cases, the old strategy would work and would have
better performance.
[bhelgaas: write changelog, add bugzilla link, fold in mem64_mask removal]
Link: https://bugzilla.kernel.org/show_bug.cgi?id=74151
Tested-by: Guo Chao <yan@linux.vnet.ibm.com>
Tested-by: Wei Yang <weiyang@linux.vnet.ibm.com>
Signed-off-by: Yinghai Lu <yinghai@kernel.org>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
2014-05-19 17:01:55 -06:00
|
|
|
|
|
|
|
|
|
2014-05-19 18:28:37 -06:00
|
|
|
|
2014-05-19 18:32:18 -06:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
PCI: Restrict 64-bit prefetchable bridge windows to 64-bit resources
This patch changes the way we handle 64-bit prefetchable bridge windows to
make it more likely that we can assign space to all devices.
Previously we put all prefetchable resources in the prefetchable bridge
window. If any of those resources was 32-bit only, we restricted the
window to be below 4GB.
After this patch, we only put 64-bit prefetchable resources in a 64-bit
prefetchable window. We put all 32-bit prefetchable resources in the
non-prefetchable window, even if there are no 64-bit prefetchable
resources.
With the previous approach, if there was a 32-bit prefetchable resource
behind a bridge, we forced the bridge's prefetchable window below 4GB,
which meant that even if there was plenty of space above 4GB available, we
couldn't use it, and assignment of large 64-bit resources could fail, as
in the bugzilla below.
The new strategy is:
1) If the prefetchable window is 64 bits wide, we put only 64-bit
prefetchable resources in it. Any 32-bit prefetchable resources go in
the non-prefetchable window.
2) If the prefetchable window is 32 bits wide, we put both 32- and 64-bit
prefetchable resources in it.
3) If there is no prefetchable window, all MMIO resources go in the
non-prefetchable window.
This reduces performance for 32-bit prefetchable resources below a bridge
with a 64-bit prefetchable window. We previously assigned prefetchable
space, but now we'll assign non-prefetchable space. This is the case even
if there are no 64-bit prefetchable resources, or if they would all fit
below 4GB. In those cases, the old strategy would work and would have
better performance.
[bhelgaas: write changelog, add bugzilla link, fold in mem64_mask removal]
Link: https://bugzilla.kernel.org/show_bug.cgi?id=74151
Tested-by: Guo Chao <yan@linux.vnet.ibm.com>
Tested-by: Wei Yang <weiyang@linux.vnet.ibm.com>
Signed-off-by: Yinghai Lu <yinghai@kernel.org>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
2014-05-19 17:01:55 -06:00
|
|
|
|
2014-05-19 18:32:18 -06:00
|
|
|
|
PCI: Restrict 64-bit prefetchable bridge windows to 64-bit resources
This patch changes the way we handle 64-bit prefetchable bridge windows to
make it more likely that we can assign space to all devices.
Previously we put all prefetchable resources in the prefetchable bridge
window. If any of those resources was 32-bit only, we restricted the
window to be below 4GB.
After this patch, we only put 64-bit prefetchable resources in a 64-bit
prefetchable window. We put all 32-bit prefetchable resources in the
non-prefetchable window, even if there are no 64-bit prefetchable
resources.
With the previous approach, if there was a 32-bit prefetchable resource
behind a bridge, we forced the bridge's prefetchable window below 4GB,
which meant that even if there was plenty of space above 4GB available, we
couldn't use it, and assignment of large 64-bit resources could fail, as
in the bugzilla below.
The new strategy is:
1) If the prefetchable window is 64 bits wide, we put only 64-bit
prefetchable resources in it. Any 32-bit prefetchable resources go in
the non-prefetchable window.
2) If the prefetchable window is 32 bits wide, we put both 32- and 64-bit
prefetchable resources in it.
3) If there is no prefetchable window, all MMIO resources go in the
non-prefetchable window.
This reduces performance for 32-bit prefetchable resources below a bridge
with a 64-bit prefetchable window. We previously assigned prefetchable
space, but now we'll assign non-prefetchable space. This is the case even
if there are no 64-bit prefetchable resources, or if they would all fit
below 4GB. In those cases, the old strategy would work and would have
better performance.
[bhelgaas: write changelog, add bugzilla link, fold in mem64_mask removal]
Link: https://bugzilla.kernel.org/show_bug.cgi?id=74151
Tested-by: Guo Chao <yan@linux.vnet.ibm.com>
Tested-by: Wei Yang <weiyang@linux.vnet.ibm.com>
Signed-off-by: Yinghai Lu <yinghai@kernel.org>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
2014-05-19 17:01:55 -06:00
|
|
|
|
2014-05-19 18:32:18 -06:00
|
|
|
|
PCI: Restrict 64-bit prefetchable bridge windows to 64-bit resources
This patch changes the way we handle 64-bit prefetchable bridge windows to
make it more likely that we can assign space to all devices.
Previously we put all prefetchable resources in the prefetchable bridge
window. If any of those resources was 32-bit only, we restricted the
window to be below 4GB.
After this patch, we only put 64-bit prefetchable resources in a 64-bit
prefetchable window. We put all 32-bit prefetchable resources in the
non-prefetchable window, even if there are no 64-bit prefetchable
resources.
With the previous approach, if there was a 32-bit prefetchable resource
behind a bridge, we forced the bridge's prefetchable window below 4GB,
which meant that even if there was plenty of space above 4GB available, we
couldn't use it, and assignment of large 64-bit resources could fail, as
in the bugzilla below.
The new strategy is:
1) If the prefetchable window is 64 bits wide, we put only 64-bit
prefetchable resources in it. Any 32-bit prefetchable resources go in
the non-prefetchable window.
2) If the prefetchable window is 32 bits wide, we put both 32- and 64-bit
prefetchable resources in it.
3) If there is no prefetchable window, all MMIO resources go in the
non-prefetchable window.
This reduces performance for 32-bit prefetchable resources below a bridge
with a 64-bit prefetchable window. We previously assigned prefetchable
space, but now we'll assign non-prefetchable space. This is the case even
if there are no 64-bit prefetchable resources, or if they would all fit
below 4GB. In those cases, the old strategy would work and would have
better performance.
[bhelgaas: write changelog, add bugzilla link, fold in mem64_mask removal]
Link: https://bugzilla.kernel.org/show_bug.cgi?id=74151
Tested-by: Guo Chao <yan@linux.vnet.ibm.com>
Tested-by: Wei Yang <weiyang@linux.vnet.ibm.com>
Signed-off-by: Yinghai Lu <yinghai@kernel.org>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
2014-05-19 17:01:55 -06:00
|
|
|
|
|
|
|
|
|
2014-05-19 18:32:18 -06:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
PCI: Restrict 64-bit prefetchable bridge windows to 64-bit resources
This patch changes the way we handle 64-bit prefetchable bridge windows to
make it more likely that we can assign space to all devices.
Previously we put all prefetchable resources in the prefetchable bridge
window. If any of those resources was 32-bit only, we restricted the
window to be below 4GB.
After this patch, we only put 64-bit prefetchable resources in a 64-bit
prefetchable window. We put all 32-bit prefetchable resources in the
non-prefetchable window, even if there are no 64-bit prefetchable
resources.
With the previous approach, if there was a 32-bit prefetchable resource
behind a bridge, we forced the bridge's prefetchable window below 4GB,
which meant that even if there was plenty of space above 4GB available, we
couldn't use it, and assignment of large 64-bit resources could fail, as
in the bugzilla below.
The new strategy is:
1) If the prefetchable window is 64 bits wide, we put only 64-bit
prefetchable resources in it. Any 32-bit prefetchable resources go in
the non-prefetchable window.
2) If the prefetchable window is 32 bits wide, we put both 32- and 64-bit
prefetchable resources in it.
3) If there is no prefetchable window, all MMIO resources go in the
non-prefetchable window.
This reduces performance for 32-bit prefetchable resources below a bridge
with a 64-bit prefetchable window. We previously assigned prefetchable
space, but now we'll assign non-prefetchable space. This is the case even
if there are no 64-bit prefetchable resources, or if they would all fit
below 4GB. In those cases, the old strategy would work and would have
better performance.
[bhelgaas: write changelog, add bugzilla link, fold in mem64_mask removal]
Link: https://bugzilla.kernel.org/show_bug.cgi?id=74151
Tested-by: Guo Chao <yan@linux.vnet.ibm.com>
Tested-by: Wei Yang <weiyang@linux.vnet.ibm.com>
Signed-off-by: Yinghai Lu <yinghai@kernel.org>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
2014-05-19 17:01:55 -06:00
|
|
|
|
2012-01-21 02:08:24 -08:00
|
|
|
|
|
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2011-02-14 17:43:20 -08:00
|
|
|
|
2014-04-14 16:11:40 -06:00
|
|
|
|
2011-02-14 17:43:20 -08:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
|
|
2015-10-29 17:35:39 -05:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2014-04-14 16:11:40 -06:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2011-07-25 13:08:42 -07:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
|
|
2015-10-29 17:35:39 -05:00
|
|
|
|
|
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2011-07-25 13:08:42 -07:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2010-01-22 01:02:25 -08:00
|
|
|
|
|
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2014-04-18 20:13:50 -04:00
|
|
|
|
|
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2010-01-22 01:02:21 -08:00
|
|
|
|
2014-04-14 16:11:40 -06:00
|
|
|
|
2010-01-22 01:02:21 -08:00
|
|
|
|
2011-02-14 17:43:20 -08:00
|
|
|
|
2010-01-22 01:02:21 -08:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
|
|
2016-06-08 12:04:47 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2014-04-14 16:11:40 -06:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2010-01-22 01:02:25 -08:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2012-01-21 02:08:21 -08:00
|
|
|
|
|
|
|
|
|
2010-01-22 01:02:25 -08:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2012-01-21 02:08:21 -08:00
|
|
|
|
2010-01-22 01:02:25 -08:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2014-04-18 20:13:50 -04:00
|
|
|
|
|
|
|
|
|
2010-01-22 01:02:25 -08:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2010-01-22 01:02:20 -08:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
PCI: Restrict 64-bit prefetchable bridge windows to 64-bit resources
This patch changes the way we handle 64-bit prefetchable bridge windows to
make it more likely that we can assign space to all devices.
Previously we put all prefetchable resources in the prefetchable bridge
window. If any of those resources was 32-bit only, we restricted the
window to be below 4GB.
After this patch, we only put 64-bit prefetchable resources in a 64-bit
prefetchable window. We put all 32-bit prefetchable resources in the
non-prefetchable window, even if there are no 64-bit prefetchable
resources.
With the previous approach, if there was a 32-bit prefetchable resource
behind a bridge, we forced the bridge's prefetchable window below 4GB,
which meant that even if there was plenty of space above 4GB available, we
couldn't use it, and assignment of large 64-bit resources could fail, as
in the bugzilla below.
The new strategy is:
1) If the prefetchable window is 64 bits wide, we put only 64-bit
prefetchable resources in it. Any 32-bit prefetchable resources go in
the non-prefetchable window.
2) If the prefetchable window is 32 bits wide, we put both 32- and 64-bit
prefetchable resources in it.
3) If there is no prefetchable window, all MMIO resources go in the
non-prefetchable window.
This reduces performance for 32-bit prefetchable resources below a bridge
with a 64-bit prefetchable window. We previously assigned prefetchable
space, but now we'll assign non-prefetchable space. This is the case even
if there are no 64-bit prefetchable resources, or if they would all fit
below 4GB. In those cases, the old strategy would work and would have
better performance.
[bhelgaas: write changelog, add bugzilla link, fold in mem64_mask removal]
Link: https://bugzilla.kernel.org/show_bug.cgi?id=74151
Tested-by: Guo Chao <yan@linux.vnet.ibm.com>
Tested-by: Wei Yang <weiyang@linux.vnet.ibm.com>
Signed-off-by: Yinghai Lu <yinghai@kernel.org>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
2014-05-19 17:01:55 -06:00
|
|
|
|
2010-01-22 01:02:20 -08:00
|
|
|
|
|
|
|
|
|
PCI: Restrict 64-bit prefetchable bridge windows to 64-bit resources
This patch changes the way we handle 64-bit prefetchable bridge windows to
make it more likely that we can assign space to all devices.
Previously we put all prefetchable resources in the prefetchable bridge
window. If any of those resources was 32-bit only, we restricted the
window to be below 4GB.
After this patch, we only put 64-bit prefetchable resources in a 64-bit
prefetchable window. We put all 32-bit prefetchable resources in the
non-prefetchable window, even if there are no 64-bit prefetchable
resources.
With the previous approach, if there was a 32-bit prefetchable resource
behind a bridge, we forced the bridge's prefetchable window below 4GB,
which meant that even if there was plenty of space above 4GB available, we
couldn't use it, and assignment of large 64-bit resources could fail, as
in the bugzilla below.
The new strategy is:
1) If the prefetchable window is 64 bits wide, we put only 64-bit
prefetchable resources in it. Any 32-bit prefetchable resources go in
the non-prefetchable window.
2) If the prefetchable window is 32 bits wide, we put both 32- and 64-bit
prefetchable resources in it.
3) If there is no prefetchable window, all MMIO resources go in the
non-prefetchable window.
This reduces performance for 32-bit prefetchable resources below a bridge
with a 64-bit prefetchable window. We previously assigned prefetchable
space, but now we'll assign non-prefetchable space. This is the case even
if there are no 64-bit prefetchable resources, or if they would all fit
below 4GB. In those cases, the old strategy would work and would have
better performance.
[bhelgaas: write changelog, add bugzilla link, fold in mem64_mask removal]
Link: https://bugzilla.kernel.org/show_bug.cgi?id=74151
Tested-by: Guo Chao <yan@linux.vnet.ibm.com>
Tested-by: Wei Yang <weiyang@linux.vnet.ibm.com>
Signed-off-by: Yinghai Lu <yinghai@kernel.org>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
2014-05-19 17:01:55 -06:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2010-01-22 01:02:20 -08:00
|
|
|
|
PCI: Restrict 64-bit prefetchable bridge windows to 64-bit resources
This patch changes the way we handle 64-bit prefetchable bridge windows to
make it more likely that we can assign space to all devices.
Previously we put all prefetchable resources in the prefetchable bridge
window. If any of those resources was 32-bit only, we restricted the
window to be below 4GB.
After this patch, we only put 64-bit prefetchable resources in a 64-bit
prefetchable window. We put all 32-bit prefetchable resources in the
non-prefetchable window, even if there are no 64-bit prefetchable
resources.
With the previous approach, if there was a 32-bit prefetchable resource
behind a bridge, we forced the bridge's prefetchable window below 4GB,
which meant that even if there was plenty of space above 4GB available, we
couldn't use it, and assignment of large 64-bit resources could fail, as
in the bugzilla below.
The new strategy is:
1) If the prefetchable window is 64 bits wide, we put only 64-bit
prefetchable resources in it. Any 32-bit prefetchable resources go in
the non-prefetchable window.
2) If the prefetchable window is 32 bits wide, we put both 32- and 64-bit
prefetchable resources in it.
3) If there is no prefetchable window, all MMIO resources go in the
non-prefetchable window.
This reduces performance for 32-bit prefetchable resources below a bridge
with a 64-bit prefetchable window. We previously assigned prefetchable
space, but now we'll assign non-prefetchable space. This is the case even
if there are no 64-bit prefetchable resources, or if they would all fit
below 4GB. In those cases, the old strategy would work and would have
better performance.
[bhelgaas: write changelog, add bugzilla link, fold in mem64_mask removal]
Link: https://bugzilla.kernel.org/show_bug.cgi?id=74151
Tested-by: Guo Chao <yan@linux.vnet.ibm.com>
Tested-by: Wei Yang <weiyang@linux.vnet.ibm.com>
Signed-off-by: Yinghai Lu <yinghai@kernel.org>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
2014-05-19 17:01:55 -06:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2010-01-22 01:02:20 -08:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
PCI: Restrict 64-bit prefetchable bridge windows to 64-bit resources
This patch changes the way we handle 64-bit prefetchable bridge windows to
make it more likely that we can assign space to all devices.
Previously we put all prefetchable resources in the prefetchable bridge
window. If any of those resources was 32-bit only, we restricted the
window to be below 4GB.
After this patch, we only put 64-bit prefetchable resources in a 64-bit
prefetchable window. We put all 32-bit prefetchable resources in the
non-prefetchable window, even if there are no 64-bit prefetchable
resources.
With the previous approach, if there was a 32-bit prefetchable resource
behind a bridge, we forced the bridge's prefetchable window below 4GB,
which meant that even if there was plenty of space above 4GB available, we
couldn't use it, and assignment of large 64-bit resources could fail, as
in the bugzilla below.
The new strategy is:
1) If the prefetchable window is 64 bits wide, we put only 64-bit
prefetchable resources in it. Any 32-bit prefetchable resources go in
the non-prefetchable window.
2) If the prefetchable window is 32 bits wide, we put both 32- and 64-bit
prefetchable resources in it.
3) If there is no prefetchable window, all MMIO resources go in the
non-prefetchable window.
This reduces performance for 32-bit prefetchable resources below a bridge
with a 64-bit prefetchable window. We previously assigned prefetchable
space, but now we'll assign non-prefetchable space. This is the case even
if there are no 64-bit prefetchable resources, or if they would all fit
below 4GB. In those cases, the old strategy would work and would have
better performance.
[bhelgaas: write changelog, add bugzilla link, fold in mem64_mask removal]
Link: https://bugzilla.kernel.org/show_bug.cgi?id=74151
Tested-by: Guo Chao <yan@linux.vnet.ibm.com>
Tested-by: Wei Yang <weiyang@linux.vnet.ibm.com>
Signed-off-by: Yinghai Lu <yinghai@kernel.org>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
2014-05-19 17:01:55 -06:00
|
|
|
|
|
|
|
|
|
2010-01-22 01:02:20 -08:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2014-04-14 16:11:40 -06:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2010-01-22 01:02:20 -08:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2008-06-23 20:33:06 +02:00
|
|
|
|
|
|
|
|
|
2010-02-23 10:24:31 -07:00
|
|
|
|
|
|
|
|
|
2009-12-22 15:02:24 -08:00
|
|
|
|
2010-02-23 10:24:31 -07:00
|
|
|
|
2009-12-22 15:02:24 -08:00
|
|
|
|
2014-04-18 20:13:49 -04:00
|
|
|
|
2008-06-23 20:33:06 +02:00
|
|
|
|
2009-10-27 13:26:47 -06:00
|
|
|
|
2014-04-18 20:13:49 -04:00
|
|
|
|
2008-06-23 20:33:06 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2013-07-24 15:37:13 -06:00
|
|
|
|
2011-05-12 17:11:37 -07:00
|
|
|
|
|
|
|
|
|
2013-08-02 17:31:03 +08:00
|
|
|
|
2011-05-12 17:11:37 -07:00
|
|
|
|
2014-04-18 20:13:49 -04:00
|
|
|
|
2011-05-12 17:11:37 -07:00
|
|
|
|
|
|
|
|
|
2013-08-02 17:31:03 +08:00
|
|
|
|
2011-05-12 17:11:37 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2012-02-23 19:23:30 -08:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2013-07-24 15:37:13 -06:00
|
|
|
|
2012-02-23 19:23:30 -08:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2013-07-24 15:37:13 -06:00
|
|
|
|
2012-02-23 19:23:30 -08:00
|
|
|
|
2013-07-22 14:37:15 -07:00
|
|
|
|
2012-02-23 19:23:30 -08:00
|
|
|
|
2011-07-07 11:19:10 -07:00
|
|
|
|
2012-02-23 19:23:32 -08:00
|
|
|
|
2013-07-24 15:37:13 -06:00
|
|
|
|
2013-07-22 14:37:13 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2012-02-23 19:23:32 -08:00
|
|
|
|
2013-07-22 14:37:13 -07:00
|
|
|
|
|
|
|
|
|
2013-07-22 14:37:14 -07:00
|
|
|
|
2012-02-23 19:23:32 -08:00
|
|
|
|
2013-07-22 14:37:13 -07:00
|
|
|
|
2013-07-22 14:37:14 -07:00
|
|
|
|
|
|
|
|
|
2012-02-23 19:23:32 -08:00
|
|
|
|
PCI: Convert pcibios_resource_to_bus() to take a pci_bus, not a pci_dev
These interfaces:
pcibios_resource_to_bus(struct pci_dev *dev, *bus_region, *resource)
pcibios_bus_to_resource(struct pci_dev *dev, *resource, *bus_region)
took a pci_dev, but they really depend only on the pci_bus. And we want to
use them in resource allocation paths where we have the bus but not a
device, so this patch converts them to take the pci_bus instead of the
pci_dev:
pcibios_resource_to_bus(struct pci_bus *bus, *bus_region, *resource)
pcibios_bus_to_resource(struct pci_bus *bus, *resource, *bus_region)
In fact, with standard PCI-PCI bridges, they only depend on the host
bridge, because that's the only place address translation occurs, but
we aren't going that far yet.
[bhelgaas: changelog]
Signed-off-by: Yinghai Lu <yinghai@kernel.org>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
2013-12-09 22:54:40 -08:00
|
|
|
|
2013-07-22 14:37:14 -07:00
|
|
|
|
2013-07-22 14:37:13 -07:00
|
|
|
|
|
|
|
|
|
2012-02-23 19:23:32 -08:00
|
|
|
|
|
|
|
|
|
2013-07-22 14:37:13 -07:00
|
|
|
|
|
|
|
|
|
2012-02-23 19:23:32 -08:00
|
|
|
|
|
|
|
|
|
2013-07-24 15:37:13 -06:00
|
|
|
|
2013-07-22 14:37:15 -07:00
|
|
|
|
2013-07-22 14:37:13 -07:00
|
|
|
|
|
|
|
|
|
2012-02-23 19:23:32 -08:00
|
|
|
|
2013-07-22 14:37:15 -07:00
|
|
|
|
|
|
|
|
|
2012-02-23 19:23:32 -08:00
|
|
|
|
2013-07-22 14:37:15 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2012-02-23 19:23:32 -08:00
|
|
|
|
2013-07-22 14:37:13 -07:00
|
|
|
|
2013-07-24 15:37:13 -06:00
|
|
|
|
2013-07-22 14:37:15 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2013-07-22 14:37:13 -07:00
|
|
|
|
2012-02-23 19:23:32 -08:00
|
|
|
|
2011-05-12 17:11:37 -07:00
|
|
|
|
|
|
|
|
|
2013-11-14 11:28:18 -07:00
|
|
|
|
|
|
|
|
|
2011-05-12 17:11:37 -07:00
|
|
|
|
2013-07-22 14:37:18 -07:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
2012-01-21 02:08:27 -08:00
|
|
|
|
2011-02-14 17:43:20 -08:00
|
|
|
|
2012-01-21 02:08:27 -08:00
|
|
|
|
2011-05-12 17:11:37 -07:00
|
|
|
|
|
|
|
|
|
2012-01-21 02:08:27 -08:00
|
|
|
|
2012-01-21 02:08:29 -08:00
|
|
|
|
2011-05-12 17:11:37 -07:00
|
|
|
|
PCI: Restrict 64-bit prefetchable bridge windows to 64-bit resources
This patch changes the way we handle 64-bit prefetchable bridge windows to
make it more likely that we can assign space to all devices.
Previously we put all prefetchable resources in the prefetchable bridge
window. If any of those resources was 32-bit only, we restricted the
window to be below 4GB.
After this patch, we only put 64-bit prefetchable resources in a 64-bit
prefetchable window. We put all 32-bit prefetchable resources in the
non-prefetchable window, even if there are no 64-bit prefetchable
resources.
With the previous approach, if there was a 32-bit prefetchable resource
behind a bridge, we forced the bridge's prefetchable window below 4GB,
which meant that even if there was plenty of space above 4GB available, we
couldn't use it, and assignment of large 64-bit resources could fail, as
in the bugzilla below.
The new strategy is:
1) If the prefetchable window is 64 bits wide, we put only 64-bit
prefetchable resources in it. Any 32-bit prefetchable resources go in
the non-prefetchable window.
2) If the prefetchable window is 32 bits wide, we put both 32- and 64-bit
prefetchable resources in it.
3) If there is no prefetchable window, all MMIO resources go in the
non-prefetchable window.
This reduces performance for 32-bit prefetchable resources below a bridge
with a 64-bit prefetchable window. We previously assigned prefetchable
space, but now we'll assign non-prefetchable space. This is the case even
if there are no 64-bit prefetchable resources, or if they would all fit
below 4GB. In those cases, the old strategy would work and would have
better performance.
[bhelgaas: write changelog, add bugzilla link, fold in mem64_mask removal]
Link: https://bugzilla.kernel.org/show_bug.cgi?id=74151
Tested-by: Guo Chao <yan@linux.vnet.ibm.com>
Tested-by: Wei Yang <weiyang@linux.vnet.ibm.com>
Signed-off-by: Yinghai Lu <yinghai@kernel.org>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
2014-05-19 17:01:55 -06:00
|
|
|
|
2012-01-21 02:08:24 -08:00
|
|
|
|
2013-07-22 14:37:16 -07:00
|
|
|
|
2011-05-12 17:11:37 -07:00
|
|
|
|
2012-01-21 02:08:24 -08:00
|
|
|
|
2013-07-22 14:37:16 -07:00
|
|
|
|
2013-07-22 14:37:15 -07:00
|
|
|
|
2013-07-22 14:37:16 -07:00
|
|
|
|
2012-01-21 02:08:24 -08:00
|
|
|
|
|
|
|
|
|
2013-07-22 14:37:16 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2012-01-21 02:08:24 -08:00
|
|
|
|
2011-05-12 17:11:37 -07:00
|
|
|
|
|
|
|
|
|
2012-01-21 02:08:24 -08:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2012-01-21 02:08:27 -08:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
|
|
2013-07-22 14:37:16 -07:00
|
|
|
|
2011-02-14 17:43:20 -08:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
2013-07-22 14:37:16 -07:00
|
|
|
|
2012-01-21 02:08:24 -08:00
|
|
|
|
2012-01-21 02:08:27 -08:00
|
|
|
|
2011-05-12 17:11:37 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2012-01-21 02:08:27 -08:00
|
|
|
|
2013-07-22 14:37:17 -07:00
|
|
|
|
2011-07-07 11:19:10 -07:00
|
|
|
|
2012-02-23 19:23:29 -08:00
|
|
|
|
2013-07-22 14:37:15 -07:00
|
|
|
|
2013-07-22 14:37:16 -07:00
|
|
|
|
2013-07-22 14:37:15 -07:00
|
|
|
|
2013-07-22 14:37:16 -07:00
|
|
|
|
2012-02-23 19:23:31 -08:00
|
|
|
|
2012-01-21 02:08:30 -08:00
|
|
|
|
2013-07-22 14:37:17 -07:00
|
|
|
|
2011-05-12 17:11:37 -07:00
|
|
|
|
|
|
|
|
|
2013-07-22 14:37:16 -07:00
|
|
|
|
|
|
|
|
|
2011-05-12 17:11:37 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2013-07-22 14:37:12 -07:00
|
|
|
|
|
|
|
|
|
2012-01-21 02:08:29 -08:00
|
|
|
|
2012-01-21 02:08:27 -08:00
|
|
|
|
2013-07-22 14:37:12 -07:00
|
|
|
|
2011-05-12 17:11:37 -07:00
|
|
|
|
2012-01-21 02:08:29 -08:00
|
|
|
|
|
|
|
|
|
2011-05-12 17:11:37 -07:00
|
|
|
|
2012-01-21 02:08:29 -08:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2011-05-12 17:11:37 -07:00
|
|
|
|
|
|
|
|
|
2012-01-21 02:08:30 -08:00
|
|
|
|
2011-05-12 17:11:37 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2013-07-22 14:37:17 -07:00
|
|
|
|
2008-06-23 20:33:06 +02:00
|
|
|
|
2013-07-22 14:37:16 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2016-08-17 16:00:34 +08:00
|
|
|
|
2013-07-22 14:37:16 -07:00
|
|
|
|
2016-09-10 23:40:45 +08:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2016-08-17 16:00:34 +08:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
2010-01-22 01:02:25 -08:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2012-01-21 02:08:27 -08:00
|
|
|
|
2012-01-21 02:08:21 -08:00
|
|
|
|
2010-01-22 01:02:27 -08:00
|
|
|
|
2012-01-21 02:08:27 -08:00
|
|
|
|
2012-01-21 02:08:29 -08:00
|
|
|
|
2010-01-22 01:02:25 -08:00
|
|
|
|
2010-01-22 01:02:27 -08:00
|
|
|
|
2014-08-22 18:15:07 -07:00
|
|
|
|
2010-01-22 01:02:25 -08:00
|
|
|
|
2010-01-22 01:02:27 -08:00
|
|
|
|
2012-01-21 02:08:21 -08:00
|
|
|
|
2012-01-21 02:08:27 -08:00
|
|
|
|
|
|
|
|
|
2010-01-22 01:02:27 -08:00
|
|
|
|
|
|
|
|
|
2012-01-21 02:08:27 -08:00
|
|
|
|
2010-05-21 14:35:06 -07:00
|
|
|
|
2010-01-22 01:02:27 -08:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2012-01-21 02:08:30 -08:00
|
|
|
|
2010-05-21 14:35:06 -07:00
|
|
|
|
2010-01-22 01:02:27 -08:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2013-07-22 14:37:12 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2010-01-22 01:02:27 -08:00
|
|
|
|
2013-07-22 14:37:12 -07:00
|
|
|
|
2010-01-22 01:02:27 -08:00
|
|
|
|
2012-01-21 02:08:29 -08:00
|
|
|
|
|
|
|
|
|
2010-01-22 01:02:27 -08:00
|
|
|
|
2012-01-21 02:08:29 -08:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2010-01-22 01:02:27 -08:00
|
|
|
|
|
|
|
|
|
2012-01-21 02:08:30 -08:00
|
|
|
|
2010-01-22 01:02:27 -08:00
|
|
|
|
|
|
|
|
|
2010-05-21 14:35:06 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2013-04-12 11:35:40 -06:00
|
|
|
|
|
|
|
|
|
2010-05-21 14:35:06 -07:00
|
|
|
|
2010-01-22 01:02:25 -08:00
|
|
|
|
|
|
|
|
|
2012-01-21 02:08:23 -08:00
|
|
|
|
2012-10-30 14:31:10 -06:00
|
|
|
|
2012-01-21 02:08:23 -08:00
|
|
|
|
|
|
|
|
|
2012-01-21 02:08:27 -08:00
|
|
|
|
2012-01-21 02:08:23 -08:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2014-05-04 12:23:38 +08:00
|
|
|
|
2012-01-21 02:08:23 -08:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2012-01-21 02:08:27 -08:00
|
|
|
|
2012-10-30 14:31:10 -06:00
|
|
|
|
2015-04-08 11:21:33 -07:00
|
|
|
|
