)]}' { "log": [ { "commit": "085ae41f66657a9655ce832b0a61832a06f0e1dc", "tree": "215690b947b14fa18cbb2810db1a4082ad607e7a", "parents": [ "064b53dbcc977dbf2753a67c2b8fc1c061d74f21" ], "author": { "name": "David S. Miller", "email": "davem@davemloft.net", "time": "Mon Aug 08 13:19:08 2005 -0700" }, "committer": { "name": "Greg Kroah-Hartman", "email": "gregkh@suse.de", "time": "Thu Sep 08 14:57:25 2005 -0700" }, "message": "[PATCH] Make sparc64 use setup-res.c\n\nThere were three changes necessary in order to allow\nsparc64 to use setup-res.c:\n\n1) Sparc64 roots the PCI I/O and MEM address space using\n parent resources contained in the PCI controller structure.\n I\u0027m actually surprised no other platforms do this, especially\n ones like Alpha and PPC{,64}. These resources get linked into the\n iomem/ioport tree when PCI controllers are probed.\n\n So the hierarchy looks like this:\n\n iomem --|\n\t PCI controller 1 MEM space --|\n\t\t\t\t device 1\n\t\t\t\t\tdevice 2\n\t\t\t\t\tetc.\n\t PCI controller 2 MEM space --|\n\t\t\t\t ...\n ioport --|\n PCI controller 1 IO space --|\n\t\t\t\t\t...\n PCI controller 2 IO space --|\n\t\t\t\t\t...\n\n You get the idea. The drivers/pci/setup-res.c code allocates\n using plain iomem_space and ioport_space as the root, so that\n wouldn\u0027t work with the above setup.\n\n So I added a pcibios_select_root() that is used to handle this.\n It uses the PCI controller struct\u0027s io_space and mem_space on\n sparc64, and io{port,mem}_resource on every other platform to\n keep current behavior.\n\n2) quirk_io_region() is buggy. It takes in raw BUS view addresses\n and tries to use them as a PCI resource.\n\n pci_claim_resource() expects the resource to be fully formed when\n it gets called. The sparc64 implementation would do the translation\n but that\u0027s absolutely wrong, because if the same resource gets\n released then re-claimed we\u0027ll adjust things twice.\n\n So I fixed up quirk_io_region() to do the proper pcibios_bus_to_resource()\n conversion before passing it on to pci_claim_resource().\n\n3) I was mistakedly __init\u0027ing the function methods the PCI controller\n drivers provide on sparc64 to implement some parts of these\n routines. This was, of course, easy to fix.\n\nSo we end up with the following, and that nasty SPARC64 makefile\nifdef in drivers/pci/Makefile is finally zapped.\n\nSigned-off-by: David S. Miller \u003cdavem@davemloft.net\u003e\nSigned-off-by: Greg Kroah-Hartman \u003cgregkh@suse.de\u003e\n" }, { "commit": "43c34735524d5b1c9b9e5d63b49dd4c1b394bde4", "tree": "a61c11d4075f149be9c0aae6b6c0a935c94571af", "parents": [ "fec59a711eef002d4ef9eb8de09dd0a26986eb77" ], "author": { "name": "Dominik Brodowski", "email": "linux@dominikbrodowski.net", "time": "Thu Aug 04 18:06:21 2005 -0700" }, "committer": { "name": "Linus Torvalds", "email": "torvalds@g5.osdl.org", "time": "Thu Aug 04 21:32:46 2005 -0700" }, "message": "[PATCH] pci and yenta: pcibios_bus_to_resource\n\nIn yenta_socket, we default to using the resource setting of the CardBus\nbridge. However, this is a PCI-bus-centric view of resources and thus needs\nto be converted to generic resources first. Therefore, add a call to\npcibios_bus_to_resource() call in between. This function is a mere wrapper on\nx86 and friends, however on some others it already exists, is added in this\npatch (alpha, arm, ppc, ppc64) or still needs to be provided (parisc -- where\nis its pcibios_resource_to_bus() ?).\n\nSigned-off-by: Dominik Brodowski \u003clinux@dominikbrodowski.net\u003e\nSigned-off-by: Andrew Morton \u003cakpm@osdl.org\u003e\nSigned-off-by: Greg Kroah-Hartman \u003cgregkh@suse.de\u003e\nSigned-off-by: Linus Torvalds \u003ctorvalds@osdl.org\u003e\n" }, { "commit": "5028770a42e7bc4d15791a44c28f0ad539323807", "tree": "74800e35129775413c13ce7caf036ca19e3ce56c", "parents": [ "9f02d6b7b43d46a74dd385f06090104ecd0fb807", "d8683a0cb5d09cb7f19feefa708424a84577e68f" ], "author": { "name": "Len Brown", "email": "len.brown@intel.com", "time": "Tue Jul 12 17:21:56 2005 -0400" }, "committer": { "name": "Len Brown", "email": "len.brown@intel.com", "time": "Tue Jul 12 17:21:56 2005 -0400" }, "message": "[ACPI] merge acpi-2.6.12 branch into latest Linux 2.6.13-rc...\n\nSigned-off-by: Len Brown \u003clen.brown@intel.com\u003e\n" }, { "commit": "c9c3e457de24cca2ca688fa397d93a241f472048", "tree": "570b7a07f9c6f570341481500a2bff21c1328d8d", "parents": [ "acf05f4b7f558051ea0028e8e617144123650272" ], "author": { "name": "David Shaohua Li", "email": "shaohua.li@intel.com", "time": "Fri Apr 01 00:07:31 2005 -0500" }, "committer": { "name": "Len Brown", "email": "len.brown@intel.com", "time": "Tue Jul 12 00:03:30 2005 -0400" }, "message": "[ACPI] PNPACPI vs sound IRQ\n\nhttp://bugme.osdl.org/show_bug.cgi?id\u003d4016\n\nWritten-by: David Shaohua Li \u003cshaohua.li@intel.com\u003e\nAcked-by: Adam Belay \u003cabelay@novell.com\u003e\nSigned-off-by: Len Brown \u003clen.brown@intel.com\u003e\n" }, { "commit": "bb4a61b6eaee01707f24deeefc5d7136f25f75c5", "tree": "8d353d7b04addad950de8ae24eda7cdfe6fbea85", "parents": [ "e24c2d963a604d9eaa560c90371fa387d3eec8f1" ], "author": { "name": "Andrew Morton", "email": "akpm@osdl.org", "time": "Mon Jun 06 23:07:46 2005 -0700" }, "committer": { "name": "Greg Kroah-Hartman", "email": "gregkh@suse.de", "time": "Mon Jun 27 21:52:46 2005 -0700" }, "message": "[PATCH] PCI: fix up errors after dma bursting patch and CONFIG_PCI\u003dn\n\nWith CONFIG_PCI\u003dn:\n\nIn file included from include/linux/pci.h:917,\n from lib/iomap.c:6:\ninclude/asm/pci.h:104: warning: `enum pci_dma_burst_strategy\u0027 declared inside parameter list\ninclude/asm/pci.h:104: warning: its scope is only this definition or declaration, which is probably not what you want.\ninclude/asm/pci.h: In function `pci_dma_burst_advice\u0027:\ninclude/asm/pci.h:106: dereferencing pointer to incomplete type\ninclude/asm/pci.h:106: `PCI_DMA_BURST_INFINITY\u0027 undeclared (first use in this function)\ninclude/asm/pci.h:106: (Each undeclared identifier is reported only once\ninclude/asm/pci.h:106: for each function it appears in.)\nmake[1]: *** [lib/iomap.o] Error 1\n\nSigned-off-by: Andrew Morton \u003cakpm@osdl.org\u003e\nSigned-off-by: Greg Kroah-Hartman \u003cgregkh@suse.de\u003e\n" }, { "commit": "e24c2d963a604d9eaa560c90371fa387d3eec8f1", "tree": "66be193d59dd22fac0b62980769c4f19e045b5a2", "parents": [ "2311b1f2bbd36fa5f366a7448c718b2556e0f02c" ], "author": { "name": "David S. Miller", "email": "davem@davemloft.net", "time": "Thu Jun 02 12:55:50 2005 -0700" }, "committer": { "name": "Greg Kroah-Hartman", "email": "gregkh@suse.de", "time": "Mon Jun 27 21:52:45 2005 -0700" }, "message": "[PATCH] PCI: DMA bursting advice\n\nAfter seeing, at best, \"guesses\" as to the following kind\nof information in several drivers, I decided that we really\nneed a way for platforms to specifically give advice in this\narea for what works best with their PCI controller implementation.\n\nBasically, this new interface gives DMA bursting advice on\nPCI. There are three forms of the advice:\n\n1) Burst as much as possible, it is not necessary to end bursts\n on some particular boundary for best performance.\n\n2) Burst on some byte count multiple. A DMA burst to some multiple of\n number of bytes may be done, but it is important to end the burst\n on an exact multiple for best performance.\n\n The best example of this I am aware of are the PPC64 PCI\n controllers, where if you end a burst mid-cacheline then\n chip has to refetch the data and the IOMMU translations\n which hurts performance a lot.\n\n3) Burst on a single byte count multiple. Bursts shall end\n exactly on the next multiple boundary for best performance.\n\n Sparc64 and Alpha\u0027s PCI controllers operate this way. They\n disconnect any device which tries to burst across a cacheline\n boundary.\n\n Actually, newer sparc64 PCI controllers do not have this behavior.\n That is why the \"pdev\" is passed into the interface, so I can\n add code later to check which PCI controller the system is using\n and give advice accordingly.\n\nSigned-off-by: David S. Miller \u003cdavem@davemloft.net\u003e\nSigned-off-by: Greg Kroah-Hartman \u003cgregkh@suse.de\u003e\n" }, { "commit": "2311b1f2bbd36fa5f366a7448c718b2556e0f02c", "tree": "10e836c5c34893f8098464a5ae15aba351a7bb2a", "parents": [ "a0d399a808916d22c1c222c6b5ca4e8edd6d91a9" ], "author": { "name": "Michael Ellerman", "email": "michael@ellerman.id.au", "time": "Fri May 13 17:44:10 2005 +1000" }, "committer": { "name": "Greg Kroah-Hartman", "email": "gregkh@suse.de", "time": "Mon Jun 27 21:52:45 2005 -0700" }, "message": "[PATCH] PCI: fix-pci-mmap-on-ppc-and-ppc64.patch\n\nThis is an updated version of Ben\u0027s fix-pci-mmap-on-ppc-and-ppc64.patch\nwhich is in 2.6.12-rc4-mm1.\n\nIt fixes the patch to work on PPC iSeries, removes some debug printks\nat Ben\u0027s request, and incorporates your\nfix-pci-mmap-on-ppc-and-ppc64-fix.patch also.\n\nOriginally from Benjamin Herrenschmidt \u003cbenh@kernel.crashing.org\u003e\n\nThis patch was discussed at length on linux-pci and so far, the last\niteration of it didn\u0027t raise any comment. It\u0027s effect is a nop on\narchitecture that don\u0027t define the new pci_resource_to_user() callback\nanyway. It allows architecture like ppc who put weird things inside of\nPCI resource structures to convert to some different value for user\nvisible ones. It also fixes mmap\u0027ing of IO space on those archs.\n\nSigned-off-by: Benjamin Herrenschmidt \u003cbenh@kernel.crashing.org\u003e\nSigned-off-by: Michael Ellerman \u003cmichael@ellerman.id.au\u003e\nSigned-off-by: Andrew Morton \u003cakpm@osdl.org\u003e\nSigned-off-by: Greg Kroah-Hartman \u003cgregkh@suse.de\u003e\n" }, { "commit": "1da177e4c3f41524e886b7f1b8a0c1fc7321cac2", "tree": "0bba044c4ce775e45a88a51686b5d9f90697ea9d", "parents": [], "author": { "name": "Linus Torvalds", "email": "torvalds@ppc970.osdl.org", "time": "Sat Apr 16 15:20:36 2005 -0700" }, "committer": { "name": "Linus Torvalds", "email": "torvalds@ppc970.osdl.org", "time": "Sat Apr 16 15:20:36 2005 -0700" }, "message": "Linux-2.6.12-rc2\n\nInitial git repository build. I\u0027m not bothering with the full history,\neven though we have it. We can create a separate \"historical\" git\narchive of that later if we want to, and in the meantime it\u0027s about\n3.2GB when imported into git - space that would just make the early\ngit days unnecessarily complicated, when we don\u0027t have a lot of good\ninfrastructure for it.\n\nLet it rip!\n" } ] }