* ACPI vs DT at runtime @ 2013-11-15 1:44 ` Olof Johansson 0 siblings, 0 replies; 186+ messages in thread From: Olof Johansson @ 2013-11-15 1:44 UTC (permalink / raw) To: devicetree-u79uwXL29TY76Z2rM5mHXA, linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r Cc: Grant Likely, Rob Herring, Arnd Bergmann The more I start to see early UEFI/ACPI code, the more I am certain that we want none of that crap in the kernel. It's making things considerably messier, while we're already very busy trying to convert everything over and enable DT -- we'll be preempting that effort just to add even more boilerplate everywhere and total progress will be hurt. The server guys really want UEFI for their boot protocols, installation managers, etc, etc. That's fine, let them do that, but that doesn't mean we need to bring the same APIs all the way into the kernel. So, I'm strongly urging that whatever the server guys try to do, it will in the end result in the ACPI data being translated into DT equivalents, such that the kernel _only_ needs to handle data via DT. Just like PowerPC scrapes the OpenFirmware client interface to build a flat device tree, we should add a pre-boot stage that scrapes ACPI/UEFI data and constructs an appropriate device-tree. We can still bring over ACPI methods and represent those in the DT, but we should _not_ have two native interfaces. It might be done via having a skeleton/framework DT for the vendor platform that is updated via UEFI/ACPI data, or it might be constructed entirely out of tables coming from firmware. I don't care about the methods for how it is done, but I do feel strongly that we should _not_ introduce a second API for everything. I can't think of a single good reason to do it. [There, commence centithread] -Olof -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org More majordomo info at http://vger.kernel.org/majordomo-info.html ^ permalink raw reply [flat|nested] 186+ messages in thread
* ACPI vs DT at runtime @ 2013-11-15 1:44 ` Olof Johansson 0 siblings, 0 replies; 186+ messages in thread From: Olof Johansson @ 2013-11-15 1:44 UTC (permalink / raw) To: linux-arm-kernel The more I start to see early UEFI/ACPI code, the more I am certain that we want none of that crap in the kernel. It's making things considerably messier, while we're already very busy trying to convert everything over and enable DT -- we'll be preempting that effort just to add even more boilerplate everywhere and total progress will be hurt. The server guys really want UEFI for their boot protocols, installation managers, etc, etc. That's fine, let them do that, but that doesn't mean we need to bring the same APIs all the way into the kernel. So, I'm strongly urging that whatever the server guys try to do, it will in the end result in the ACPI data being translated into DT equivalents, such that the kernel _only_ needs to handle data via DT. Just like PowerPC scrapes the OpenFirmware client interface to build a flat device tree, we should add a pre-boot stage that scrapes ACPI/UEFI data and constructs an appropriate device-tree. We can still bring over ACPI methods and represent those in the DT, but we should _not_ have two native interfaces. It might be done via having a skeleton/framework DT for the vendor platform that is updated via UEFI/ACPI data, or it might be constructed entirely out of tables coming from firmware. I don't care about the methods for how it is done, but I do feel strongly that we should _not_ introduce a second API for everything. I can't think of a single good reason to do it. [There, commence centithread] -Olof ^ permalink raw reply [flat|nested] 186+ messages in thread
* Re: ACPI vs DT at runtime 2013-11-15 1:44 ` Olof Johansson @ 2013-11-15 9:57 ` Mark Rutland -1 siblings, 0 replies; 186+ messages in thread From: Mark Rutland @ 2013-11-15 9:57 UTC (permalink / raw) To: Olof Johansson; +Cc: Grant Likely, devicetree, Arnd Bergmann, linux-arm-kernel On Fri, Nov 15, 2013 at 01:44:10AM +0000, Olof Johansson wrote: > The more I start to see early UEFI/ACPI code, the more I am certain > that we want none of that crap in the kernel. It's making things > considerably messier, while we're already very busy trying to convert > everything over and enable DT -- we'll be preempting that effort just > to add even more boilerplate everywhere and total progress will be > hurt. We are certainly under a lot of pressure with the device tree migration, and I agree that adding another information source is going to be a source of pain. However, I'd argue that we're going to encounter pain regardless of which approach we take. I'm of the opinion that the only way we should support ACPI is as a first-class citizen. We don't need to modify every driver and subsystem to support ACPI, only those necessary to support the minimal set of platforms using ACPI. ACPI is new in the arm space, and we can enforce quality standards on ACPI _now_ above what we're allowing for DT, and avoid future problems. There may even be things which we don't have to deal with at all on ACPI systems as used in servers (e.g. clock management), but perhaps we will if people see value in those elements. > The server guys really want UEFI for their boot protocols, > installation managers, etc, etc. That's fine, let them do that, but > that doesn't mean we need to bring the same APIs all the way into the > kernel. > > So, I'm strongly urging that whatever the server guys try to do, it > will in the end result in the ACPI data being translated into DT > equivalents, such that the kernel _only_ needs to handle data via DT. I'm not sure that translating ACPI tables to dt makes any sense. If AML is used (even sparingly), I do not believe that we can do any sensible conversion to device tree. My understanding is that AML includes functionality for modifying ACPI tables, and I don't see how we can possibly support that without having to add a lot of boilerplate to all the code handling AML to add a device tree backend... > Just like PowerPC scrapes the OpenFirmware client interface to build a > flat device tree, we should add a pre-boot stage that scrapes > ACPI/UEFI data and constructs an appropriate device-tree. We can still > bring over ACPI methods and represent those in the DT, but we should > _not_ have two native interfaces. I'm not sure the two cases are comparable. The format of the FDT was designed to encode the data structure used by OpenFirmware, and thus the two map to each other pretty well. I do not believe that mapping from ACPI tables to an FDT blob is anywhere near as simple, and as I mention above I do not believe that we can just copy over the ACPI methods in isolation. > It might be done via having a skeleton/framework DT for the vendor > platform that is updated via UEFI/ACPI data, or it might be > constructed entirely out of tables coming from firmware. I don't care > about the methods for how it is done, but I do feel strongly that we > should _not_ introduce a second API for everything. I can't think of a > single good reason to do it. Where does this skeleton/framework come from? Within the kernel? That sounds like an arcane board file equivalent, and is counter to the entire reason for using UEFI and ACPI -- having a well-defined (excluding particular driver bindings, and I'm not arguing well-defined means nice) stable standard that allows the kernel to boot on an arbitrary platform without requiring arbitrary platform-specific code everywhere in the boot path. It might not be pretty, and it will certainly require a lot of work, but I'd prefer it at least for a semblance of uniformity. I think that trying to shoe-horn ACPI-derived information into device tree is fundamentally the wrong approach. I don't think it encourages best practices, and I don't think it's beneficial to the long term health of Linux or the ecosystem as a whole. > [There, commence centithread] [centithread commenced] Thanks, Mark. ^ permalink raw reply [flat|nested] 186+ messages in thread
* ACPI vs DT at runtime @ 2013-11-15 9:57 ` Mark Rutland 0 siblings, 0 replies; 186+ messages in thread From: Mark Rutland @ 2013-11-15 9:57 UTC (permalink / raw) To: linux-arm-kernel On Fri, Nov 15, 2013 at 01:44:10AM +0000, Olof Johansson wrote: > The more I start to see early UEFI/ACPI code, the more I am certain > that we want none of that crap in the kernel. It's making things > considerably messier, while we're already very busy trying to convert > everything over and enable DT -- we'll be preempting that effort just > to add even more boilerplate everywhere and total progress will be > hurt. We are certainly under a lot of pressure with the device tree migration, and I agree that adding another information source is going to be a source of pain. However, I'd argue that we're going to encounter pain regardless of which approach we take. I'm of the opinion that the only way we should support ACPI is as a first-class citizen. We don't need to modify every driver and subsystem to support ACPI, only those necessary to support the minimal set of platforms using ACPI. ACPI is new in the arm space, and we can enforce quality standards on ACPI _now_ above what we're allowing for DT, and avoid future problems. There may even be things which we don't have to deal with at all on ACPI systems as used in servers (e.g. clock management), but perhaps we will if people see value in those elements. > The server guys really want UEFI for their boot protocols, > installation managers, etc, etc. That's fine, let them do that, but > that doesn't mean we need to bring the same APIs all the way into the > kernel. > > So, I'm strongly urging that whatever the server guys try to do, it > will in the end result in the ACPI data being translated into DT > equivalents, such that the kernel _only_ needs to handle data via DT. I'm not sure that translating ACPI tables to dt makes any sense. If AML is used (even sparingly), I do not believe that we can do any sensible conversion to device tree. My understanding is that AML includes functionality for modifying ACPI tables, and I don't see how we can possibly support that without having to add a lot of boilerplate to all the code handling AML to add a device tree backend... > Just like PowerPC scrapes the OpenFirmware client interface to build a > flat device tree, we should add a pre-boot stage that scrapes > ACPI/UEFI data and constructs an appropriate device-tree. We can still > bring over ACPI methods and represent those in the DT, but we should > _not_ have two native interfaces. I'm not sure the two cases are comparable. The format of the FDT was designed to encode the data structure used by OpenFirmware, and thus the two map to each other pretty well. I do not believe that mapping from ACPI tables to an FDT blob is anywhere near as simple, and as I mention above I do not believe that we can just copy over the ACPI methods in isolation. > It might be done via having a skeleton/framework DT for the vendor > platform that is updated via UEFI/ACPI data, or it might be > constructed entirely out of tables coming from firmware. I don't care > about the methods for how it is done, but I do feel strongly that we > should _not_ introduce a second API for everything. I can't think of a > single good reason to do it. Where does this skeleton/framework come from? Within the kernel? That sounds like an arcane board file equivalent, and is counter to the entire reason for using UEFI and ACPI -- having a well-defined (excluding particular driver bindings, and I'm not arguing well-defined means nice) stable standard that allows the kernel to boot on an arbitrary platform without requiring arbitrary platform-specific code everywhere in the boot path. It might not be pretty, and it will certainly require a lot of work, but I'd prefer it at least for a semblance of uniformity. I think that trying to shoe-horn ACPI-derived information into device tree is fundamentally the wrong approach. I don't think it encourages best practices, and I don't think it's beneficial to the long term health of Linux or the ecosystem as a whole. > [There, commence centithread] [centithread commenced] Thanks, Mark. ^ permalink raw reply [flat|nested] 186+ messages in thread
[parent not found: <20131115175241. GB27174@quad.lixom.net>]
[parent not found: <20131115095717.GC1709-NuALmloUBlrZROr8t4l/smS4ubULX0JqMm0uRHvK7Nw@public.gmane.org>]
* Re: ACPI vs DT at runtime 2013-11-15 9:57 ` Mark Rutland @ 2013-11-15 17:52 ` Olof Johansson -1 siblings, 0 replies; 186+ messages in thread From: Olof Johansson @ 2013-11-15 17:52 UTC (permalink / raw) To: Mark Rutland Cc: devicetree-u79uwXL29TY76Z2rM5mHXA, linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r, Grant Likely, Rob Herring, Arnd Bergmann On Fri, Nov 15, 2013 at 09:57:17AM +0000, Mark Rutland wrote: > On Fri, Nov 15, 2013 at 01:44:10AM +0000, Olof Johansson wrote: > > The more I start to see early UEFI/ACPI code, the more I am certain > > that we want none of that crap in the kernel. It's making things > > considerably messier, while we're already very busy trying to convert > > everything over and enable DT -- we'll be preempting that effort just > > to add even more boilerplate everywhere and total progress will be > > hurt. > > We are certainly under a lot of pressure with the device tree migration, > and I agree that adding another information source is going to be a > source of pain. However, I'd argue that we're going to encounter pain > regardless of which approach we take. > > I'm of the opinion that the only way we should support ACPI is as a > first-class citizen. We don't need to modify every driver and subsystem > to support ACPI, only those necessary to support the minimal set of > platforms using ACPI. ACPI is new in the arm space, and we can enforce > quality standards on ACPI _now_ above what we're allowing for DT, and > avoid future problems. It's obvious from the very first submission, from a vendor that has worked closely with "the community" (i.e. one enterprise distro at least), that this is completely new territory for _everyone_ involved. There's no way that we can enforce quality standards for ACPI yet -- we don't know what they look like! Nobody knows how to design a good ACPI implementation or binding. Oh wait, there's people who have been doing this for years. Microsoft. They should be the ones driving this and taking the pain for it. Once the platform is enabled for their needs, we'll sort it out at our end. After all, that has worked reasonably well for x86 platforms. If we knew exactly what we wanted, it'd be a different story. _We don't_. We're into year FOUR of the device tree conversion and we're just now reaching a point where we think we know what a good solution looks like. The first two years were easy -- they were the trivial devices we're now talking about on ACPI. After that it got harder. Going through all of that again with ACPI? No. No way. Microsoft gets to do it and while they're busy sorting it out, we'll boot with device tree. Once they're done, we'll figure out how to enable new hardware. Sure, someone needs to keep them sane and participate in the standardization process, but we don't have to drag the whole kernel through it. > There may even be things which we don't have to deal with at all on ACPI > systems as used in servers (e.g. clock management), but perhaps we will > if people see value in those elements. It's not about seeing value, it's about trying to shoehorn an existing implementation into ACPI right now. People don't program with the ACPI mindset since that's not what they're used to. So everybody needs to re-learn everything all over again. The clock issues still have to be dealt with in ACPI _somewhere_, and they likely have to be dealt with by the same software team at the vendors that do Linux kernel work. So by forcing them to figure out how to do it in ACPI, we're distracting from their efforts to support their hardware better in the kernel in the first place. That's not win-win, it's lose-lose. Or rather, it's lose for all of us, and win for Microsoft since they are DoS:ing us. > > The server guys really want UEFI for their boot protocols, > > installation managers, etc, etc. That's fine, let them do that, but > > that doesn't mean we need to bring the same APIs all the way into the > > kernel. > > > > So, I'm strongly urging that whatever the server guys try to do, it > > will in the end result in the ACPI data being translated into DT > > equivalents, such that the kernel _only_ needs to handle data via DT. > > I'm not sure that translating ACPI tables to dt makes any sense. If AML > is used (even sparingly), I do not believe that we can do any sensible > conversion to device tree. My understanding is that AML includes > functionality for modifying ACPI tables, and I don't see how we can > possibly support that without having to add a lot of boilerplate to all > the code handling AML to add a device tree backend... We can definitely modify device tree contents at runtime, it's just that nobody besides the POWER server guys are doing that today. So that's not a strong argument in ACPI's favor. We should fix device-tree where needed instead. Also, we can either have some of our better people sort out the ACPI-to-DT translation and management, and get it done right, or we can rely on all the vendors to get ACPI right in all their drivers. While some of them will, I suspect we'll be more successful driving this from a common place. It also gives us a place to stick all the fixups for broken firmware, since the first generations of ARM servers are bound to have them. And best of all, it allows us to continue focus on device tree and getting that done right, than splitting all efforts into two. We can't affort that right now. > > Just like PowerPC scrapes the OpenFirmware client interface to build a > > flat device tree, we should add a pre-boot stage that scrapes > > ACPI/UEFI data and constructs an appropriate device-tree. We can still > > bring over ACPI methods and represent those in the DT, but we should > > _not_ have two native interfaces. > > I'm not sure the two cases are comparable. The format of the FDT was > designed to encode the data structure used by OpenFirmware, and thus the > two map to each other pretty well. I do not believe that mapping from > ACPI tables to an FDT blob is anywhere near as simple, and as I mention > above I do not believe that we can just copy over the ACPI methods in > isolation. Sorry, I wasn't implying that there's a one-time trivial conversion to be made in the generic case, but it can still be done in a similar manner even though it will be more complex. Nobody is expecting there to be zero work for new drivers with ACPI; after all, the driver itself still has to be written. We're talking differences from board to board and system to system here, which we can definitely handle through a translator as well. And, as you say, if the first platforms are going to be trivial and easy to implement with ACPI, then doing a translation for them will be simple too. Shipping a firmware with ACPI is really no different from shipping a firmware with a flashed device tree. Whatever bugs or strange things the vendor chooses to do in there, we'll have to live with forever. We all know DT considerably better to a point where I would recommend that they flash a DTB in their UEFI firmware instead of go with ACPI. For simple hardware and basic devices we've got most bindings sorted out by now, and we've decided on backwards compatibility from here on out. > > It might be done via having a skeleton/framework DT for the vendor > > platform that is updated via UEFI/ACPI data, or it might be > > constructed entirely out of tables coming from firmware. I don't care > > about the methods for how it is done, but I do feel strongly that we > > should _not_ introduce a second API for everything. I can't think of a > > single good reason to do it. > > Where does this skeleton/framework come from? Within the kernel? Since there might need to be runtime modifications done to the tree based on ACPI events, it seems to make sense to do it in the kernel, so that translation state and such can be kept around for use by the runtime modification parts. Having it extractable out of the kernel tree for testing purposes would be greatly appreciated, so it can be ran through valgrind, add testcases, etc. > That > sounds like an arcane board file equivalent, and is counter to the > entire reason for using UEFI and ACPI -- having a well-defined > (excluding particular driver bindings, and I'm not arguing well-defined > means nice) stable standard that allows the kernel to boot on an > arbitrary platform without requiring arbitrary platform-specific code > everywhere in the boot path. > > It might not be pretty, and it will certainly require a lot of work, but > I'd prefer it at least for a semblance of uniformity. That is a red herring -- that booting standard has _nothing_ to do with ACPI. Once you've got a standard that is well-defined enough like that, you no longer need the runtime portions of ACPI to deal with it. You can just hardcode it. You need a way to probe _which_ type of standard is used, but from there on out you can assume that things are the same way. > I think that trying to shoe-horn ACPI-derived information into device > tree is fundamentally the wrong approach. I don't think it encourages > best practices, and I don't think it's beneficial to the long term > health of Linux or the ecosystem as a whole. There are no known best practices with ACPI. It's a complete fumbling around in the dark right now. We're complaining about reviewer bandwith on DT -- do we have a single reviewer for ACPI on ARM that actually knows what a good solution looks like? I don't think so. So, until there's strong evidence that ACPI is actually going to be a sane solution, in other words, until someone has shipped a system that uses it (with Windows) and does it successfully without being a hot mess, we shouldn't litter the kernel with it. Vendors can standardise of UEFI if they want, but I would much rather see them bundle DTB images with their firmware today, than rely on early buggy and still-early-on-the-learning-curve ACPI bindings that we then have to live with forever. -Olof -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org More majordomo info at http://vger.kernel.org/majordomo-info.html ^ permalink raw reply [flat|nested] 186+ messages in thread
* ACPI vs DT at runtime @ 2013-11-15 17:52 ` Olof Johansson 0 siblings, 0 replies; 186+ messages in thread From: Olof Johansson @ 2013-11-15 17:52 UTC (permalink / raw) To: linux-arm-kernel On Fri, Nov 15, 2013 at 09:57:17AM +0000, Mark Rutland wrote: > On Fri, Nov 15, 2013 at 01:44:10AM +0000, Olof Johansson wrote: > > The more I start to see early UEFI/ACPI code, the more I am certain > > that we want none of that crap in the kernel. It's making things > > considerably messier, while we're already very busy trying to convert > > everything over and enable DT -- we'll be preempting that effort just > > to add even more boilerplate everywhere and total progress will be > > hurt. > > We are certainly under a lot of pressure with the device tree migration, > and I agree that adding another information source is going to be a > source of pain. However, I'd argue that we're going to encounter pain > regardless of which approach we take. > > I'm of the opinion that the only way we should support ACPI is as a > first-class citizen. We don't need to modify every driver and subsystem > to support ACPI, only those necessary to support the minimal set of > platforms using ACPI. ACPI is new in the arm space, and we can enforce > quality standards on ACPI _now_ above what we're allowing for DT, and > avoid future problems. It's obvious from the very first submission, from a vendor that has worked closely with "the community" (i.e. one enterprise distro at least), that this is completely new territory for _everyone_ involved. There's no way that we can enforce quality standards for ACPI yet -- we don't know what they look like! Nobody knows how to design a good ACPI implementation or binding. Oh wait, there's people who have been doing this for years. Microsoft. They should be the ones driving this and taking the pain for it. Once the platform is enabled for their needs, we'll sort it out at our end. After all, that has worked reasonably well for x86 platforms. If we knew exactly what we wanted, it'd be a different story. _We don't_. We're into year FOUR of the device tree conversion and we're just now reaching a point where we think we know what a good solution looks like. The first two years were easy -- they were the trivial devices we're now talking about on ACPI. After that it got harder. Going through all of that again with ACPI? No. No way. Microsoft gets to do it and while they're busy sorting it out, we'll boot with device tree. Once they're done, we'll figure out how to enable new hardware. Sure, someone needs to keep them sane and participate in the standardization process, but we don't have to drag the whole kernel through it. > There may even be things which we don't have to deal with at all on ACPI > systems as used in servers (e.g. clock management), but perhaps we will > if people see value in those elements. It's not about seeing value, it's about trying to shoehorn an existing implementation into ACPI right now. People don't program with the ACPI mindset since that's not what they're used to. So everybody needs to re-learn everything all over again. The clock issues still have to be dealt with in ACPI _somewhere_, and they likely have to be dealt with by the same software team at the vendors that do Linux kernel work. So by forcing them to figure out how to do it in ACPI, we're distracting from their efforts to support their hardware better in the kernel in the first place. That's not win-win, it's lose-lose. Or rather, it's lose for all of us, and win for Microsoft since they are DoS:ing us. > > The server guys really want UEFI for their boot protocols, > > installation managers, etc, etc. That's fine, let them do that, but > > that doesn't mean we need to bring the same APIs all the way into the > > kernel. > > > > So, I'm strongly urging that whatever the server guys try to do, it > > will in the end result in the ACPI data being translated into DT > > equivalents, such that the kernel _only_ needs to handle data via DT. > > I'm not sure that translating ACPI tables to dt makes any sense. If AML > is used (even sparingly), I do not believe that we can do any sensible > conversion to device tree. My understanding is that AML includes > functionality for modifying ACPI tables, and I don't see how we can > possibly support that without having to add a lot of boilerplate to all > the code handling AML to add a device tree backend... We can definitely modify device tree contents at runtime, it's just that nobody besides the POWER server guys are doing that today. So that's not a strong argument in ACPI's favor. We should fix device-tree where needed instead. Also, we can either have some of our better people sort out the ACPI-to-DT translation and management, and get it done right, or we can rely on all the vendors to get ACPI right in all their drivers. While some of them will, I suspect we'll be more successful driving this from a common place. It also gives us a place to stick all the fixups for broken firmware, since the first generations of ARM servers are bound to have them. And best of all, it allows us to continue focus on device tree and getting that done right, than splitting all efforts into two. We can't affort that right now. > > Just like PowerPC scrapes the OpenFirmware client interface to build a > > flat device tree, we should add a pre-boot stage that scrapes > > ACPI/UEFI data and constructs an appropriate device-tree. We can still > > bring over ACPI methods and represent those in the DT, but we should > > _not_ have two native interfaces. > > I'm not sure the two cases are comparable. The format of the FDT was > designed to encode the data structure used by OpenFirmware, and thus the > two map to each other pretty well. I do not believe that mapping from > ACPI tables to an FDT blob is anywhere near as simple, and as I mention > above I do not believe that we can just copy over the ACPI methods in > isolation. Sorry, I wasn't implying that there's a one-time trivial conversion to be made in the generic case, but it can still be done in a similar manner even though it will be more complex. Nobody is expecting there to be zero work for new drivers with ACPI; after all, the driver itself still has to be written. We're talking differences from board to board and system to system here, which we can definitely handle through a translator as well. And, as you say, if the first platforms are going to be trivial and easy to implement with ACPI, then doing a translation for them will be simple too. Shipping a firmware with ACPI is really no different from shipping a firmware with a flashed device tree. Whatever bugs or strange things the vendor chooses to do in there, we'll have to live with forever. We all know DT considerably better to a point where I would recommend that they flash a DTB in their UEFI firmware instead of go with ACPI. For simple hardware and basic devices we've got most bindings sorted out by now, and we've decided on backwards compatibility from here on out. > > It might be done via having a skeleton/framework DT for the vendor > > platform that is updated via UEFI/ACPI data, or it might be > > constructed entirely out of tables coming from firmware. I don't care > > about the methods for how it is done, but I do feel strongly that we > > should _not_ introduce a second API for everything. I can't think of a > > single good reason to do it. > > Where does this skeleton/framework come from? Within the kernel? Since there might need to be runtime modifications done to the tree based on ACPI events, it seems to make sense to do it in the kernel, so that translation state and such can be kept around for use by the runtime modification parts. Having it extractable out of the kernel tree for testing purposes would be greatly appreciated, so it can be ran through valgrind, add testcases, etc. > That > sounds like an arcane board file equivalent, and is counter to the > entire reason for using UEFI and ACPI -- having a well-defined > (excluding particular driver bindings, and I'm not arguing well-defined > means nice) stable standard that allows the kernel to boot on an > arbitrary platform without requiring arbitrary platform-specific code > everywhere in the boot path. > > It might not be pretty, and it will certainly require a lot of work, but > I'd prefer it at least for a semblance of uniformity. That is a red herring -- that booting standard has _nothing_ to do with ACPI. Once you've got a standard that is well-defined enough like that, you no longer need the runtime portions of ACPI to deal with it. You can just hardcode it. You need a way to probe _which_ type of standard is used, but from there on out you can assume that things are the same way. > I think that trying to shoe-horn ACPI-derived information into device > tree is fundamentally the wrong approach. I don't think it encourages > best practices, and I don't think it's beneficial to the long term > health of Linux or the ecosystem as a whole. There are no known best practices with ACPI. It's a complete fumbling around in the dark right now. We're complaining about reviewer bandwith on DT -- do we have a single reviewer for ACPI on ARM that actually knows what a good solution looks like? I don't think so. So, until there's strong evidence that ACPI is actually going to be a sane solution, in other words, until someone has shipped a system that uses it (with Windows) and does it successfully without being a hot mess, we shouldn't litter the kernel with it. Vendors can standardise of UEFI if they want, but I would much rather see them bundle DTB images with their firmware today, than rely on early buggy and still-early-on-the-learning-curve ACPI bindings that we then have to live with forever. -Olof ^ permalink raw reply [flat|nested] 186+ messages in thread
* ACPI vs DT at runtime 2013-11-15 17:52 ` Olof Johansson (?) @ 2013-11-15 18:13 ` David Goodenough 2013-11-21 16:15 ` Grant Likely -1 siblings, 1 reply; 186+ messages in thread From: David Goodenough @ 2013-11-15 18:13 UTC (permalink / raw) To: linux-arm-kernel On Friday 15 Nov 2013, Olof Johansson wrote: > On Fri, Nov 15, 2013 at 09:57:17AM +0000, Mark Rutland wrote: > > On Fri, Nov 15, 2013 at 01:44:10AM +0000, Olof Johansson wrote: > > > The more I start to see early UEFI/ACPI code, the more I am certain > > > that we want none of that crap in the kernel. It's making things > > > considerably messier, while we're already very busy trying to convert > > > everything over and enable DT -- we'll be preempting that effort just > > > to add even more boilerplate everywhere and total progress will be > > > hurt. > > > > We are certainly under a lot of pressure with the device tree migration, > > and I agree that adding another information source is going to be a > > source of pain. However, I'd argue that we're going to encounter pain > > regardless of which approach we take. > > > > I'm of the opinion that the only way we should support ACPI is as a > > first-class citizen. We don't need to modify every driver and subsystem > > to support ACPI, only those necessary to support the minimal set of > > platforms using ACPI. ACPI is new in the arm space, and we can enforce > > quality standards on ACPI _now_ above what we're allowing for DT, and > > avoid future problems. > > It's obvious from the very first submission, from a vendor that has worked > closely with "the community" (i.e. one enterprise distro at least), that > this is completely new territory for _everyone_ involved. There's no way > that we can enforce quality standards for ACPI yet -- we don't know what > they look like! Nobody knows how to design a good ACPI implementation or > binding. > > Oh wait, there's people who have been doing this for years. Microsoft. They > should be the ones driving this and taking the pain for it. Once the > platform is enabled for their needs, we'll sort it out at our end. After > all, that has worked reasonably well for x86 platforms. > > If we knew exactly what we wanted, it'd be a different story. _We > don't_. We're into year FOUR of the device tree conversion and we're just > now reaching a point where we think we know what a good solution looks > like. The first two years were easy -- they were the trivial devices we're > now talking about on ACPI. After that it got harder. Going through all > of that again with ACPI? No. No way. Microsoft gets to do it and while > they're busy sorting it out, we'll boot with device tree. > > Once they're done, we'll figure out how to enable new hardware. Sure, > someone needs to keep them sane and participate in the standardization > process, but we don't have to drag the whole kernel through it. > > > There may even be things which we don't have to deal with at all on ACPI > > systems as used in servers (e.g. clock management), but perhaps we will > > if people see value in those elements. > > It's not about seeing value, it's about trying to shoehorn an existing > implementation into ACPI right now. People don't program with the ACPI > mindset since that's not what they're used to. So everybody needs to > re-learn everything all over again. > > The clock issues still have to be dealt with in ACPI _somewhere_, > and they likely have to be dealt with by the same software team at the > vendors that do Linux kernel work. So by forcing them to figure out how > to do it in ACPI, we're distracting from their efforts to support their > hardware better in the kernel in the first place. That's not win-win, > it's lose-lose. Or rather, it's lose for all of us, and win for Microsoft > since they are DoS:ing us. > > > > The server guys really want UEFI for their boot protocols, > > > installation managers, etc, etc. That's fine, let them do that, but > > > that doesn't mean we need to bring the same APIs all the way into the > > > kernel. > > > > > > So, I'm strongly urging that whatever the server guys try to do, it > > > will in the end result in the ACPI data being translated into DT > > > equivalents, such that the kernel _only_ needs to handle data via DT. > > > > I'm not sure that translating ACPI tables to dt makes any sense. If AML > > is used (even sparingly), I do not believe that we can do any sensible > > conversion to device tree. My understanding is that AML includes > > functionality for modifying ACPI tables, and I don't see how we can > > possibly support that without having to add a lot of boilerplate to all > > the code handling AML to add a device tree backend... > > We can definitely modify device tree contents at runtime, it's just that > nobody besides the POWER server guys are doing that today. So that's > not a strong argument in ACPI's favor. We should fix device-tree where > needed instead. Is this true. On the Beagle Board/Bone there is extensive use of Device Tree Overlays, which feels like run time modification to me. It gets used to enable multiplexed pins to a particular configuration. David > > Also, we can either have some of our better people sort out the ACPI-to-DT > translation and management, and get it done right, or we can rely on all > the vendors to get ACPI right in all their drivers. While some of them > will, I suspect we'll be more successful driving this from a common place. > It also gives us a place to stick all the fixups for broken firmware, > since the first generations of ARM servers are bound to have them. > > And best of all, it allows us to continue focus on device tree and > getting that done right, than splitting all efforts into two. We can't > affort that right now. > > > > Just like PowerPC scrapes the OpenFirmware client interface to build a > > > flat device tree, we should add a pre-boot stage that scrapes > > > ACPI/UEFI data and constructs an appropriate device-tree. We can still > > > bring over ACPI methods and represent those in the DT, but we should > > > _not_ have two native interfaces. > > > > I'm not sure the two cases are comparable. The format of the FDT was > > designed to encode the data structure used by OpenFirmware, and thus the > > two map to each other pretty well. I do not believe that mapping from > > ACPI tables to an FDT blob is anywhere near as simple, and as I mention > > above I do not believe that we can just copy over the ACPI methods in > > isolation. > > Sorry, I wasn't implying that there's a one-time trivial conversion > to be made in the generic case, but it can still be done in a similar > manner even though it will be more complex. > > Nobody is expecting there to be zero work for new drivers with ACPI; > after all, the driver itself still has to be written. We're talking > differences from board to board and system to system here, which we can > definitely handle through a translator as well. > > And, as you say, if the first platforms are going to be trivial and easy to > implement with ACPI, then doing a translation for them will be simple too. > > Shipping a firmware with ACPI is really no different from shipping a > firmware with a flashed device tree. Whatever bugs or strange things the > vendor chooses to do in there, we'll have to live with forever. > > We all know DT considerably better to a point where I would recommend > that they flash a DTB in their UEFI firmware instead of go with ACPI. For > simple hardware and basic devices we've got most bindings sorted out by > now, and we've decided on backwards compatibility from here on out. > > > > It might be done via having a skeleton/framework DT for the vendor > > > platform that is updated via UEFI/ACPI data, or it might be > > > constructed entirely out of tables coming from firmware. I don't care > > > about the methods for how it is done, but I do feel strongly that we > > > should _not_ introduce a second API for everything. I can't think of a > > > single good reason to do it. > > > > Where does this skeleton/framework come from? Within the kernel? > > Since there might need to be runtime modifications done to the tree based > on ACPI events, it seems to make sense to do it in the kernel, so that > translation state and such can be kept around for use by the runtime > modification parts. > > Having it extractable out of the kernel tree for testing purposes would be > greatly appreciated, so it can be ran through valgrind, add testcases, etc. > > > That > > sounds like an arcane board file equivalent, and is counter to the > > entire reason for using UEFI and ACPI -- having a well-defined > > (excluding particular driver bindings, and I'm not arguing well-defined > > means nice) stable standard that allows the kernel to boot on an > > arbitrary platform without requiring arbitrary platform-specific code > > everywhere in the boot path. > > > > It might not be pretty, and it will certainly require a lot of work, but > > I'd prefer it at least for a semblance of uniformity. > > That is a red herring -- that booting standard has _nothing_ to do with > ACPI. Once you've got a standard that is well-defined enough like that, > you no longer need the runtime portions of ACPI to deal with it. You > can just hardcode it. You need a way to probe _which_ type of standard > is used, but from there on out you can assume that things are the same > way. > > > I think that trying to shoe-horn ACPI-derived information into device > > tree is fundamentally the wrong approach. I don't think it encourages > > best practices, and I don't think it's beneficial to the long term > > health of Linux or the ecosystem as a whole. > > There are no known best practices with ACPI. It's a complete fumbling > around in the dark right now. We're complaining about reviewer bandwith > on DT -- do we have a single reviewer for ACPI on ARM that actually > knows what a good solution looks like? I don't think so. > > So, until there's strong evidence that ACPI is actually going to be > a sane solution, in other words, until someone has shipped a system > that uses it (with Windows) and does it successfully without being > a hot mess, we shouldn't litter the kernel with it. > > Vendors can standardise of UEFI if they want, but I would much rather > see them bundle DTB images with their firmware today, than rely on early > buggy and still-early-on-the-learning-curve ACPI bindings that we then > have to live with forever. > > > -Olof > > _______________________________________________ > linux-arm-kernel mailing list > linux-arm-kernel at lists.infradead.org > http://lists.infradead.org/mailman/listinfo/linux-arm-kernel ^ permalink raw reply [flat|nested] 186+ messages in thread
* ACPI vs DT at runtime 2013-11-15 18:13 ` David Goodenough @ 2013-11-21 16:15 ` Grant Likely 0 siblings, 0 replies; 186+ messages in thread From: Grant Likely @ 2013-11-21 16:15 UTC (permalink / raw) To: linux-arm-kernel On Fri, 15 Nov 2013 18:13:47 +0000, David Goodenough <david.goodenough@btconnect.com> wrote: > On Friday 15 Nov 2013, Olof Johansson wrote: > > > I'm not sure that translating ACPI tables to dt makes any sense. If AML > > > is used (even sparingly), I do not believe that we can do any sensible > > > conversion to device tree. My understanding is that AML includes > > > functionality for modifying ACPI tables, and I don't see how we can > > > possibly support that without having to add a lot of boilerplate to all > > > the code handling AML to add a device tree backend... > > > > We can definitely modify device tree contents at runtime, it's just that > > nobody besides the POWER server guys are doing that today. So that's > > not a strong argument in ACPI's favor. We should fix device-tree where > > needed instead. > Is this true. On the Beagle Board/Bone there is extensive use of Device > Tree Overlays, which feels like run time modification to me. It gets > used to enable multiplexed pins to a particular configuration. ACPI can load/unload an arbitrary number of SSDTs into the ACPI namespace. They pretty much act in the same way as DT overlays. The hard part is that the loading of an SSDT can be embedded into an AML method so that it can be triggered by an event. I'm told that it is used for things like hotplugging CPUs. This is what I meant in my earlier comment that ACPI is oriented towards handling the difficult bits in the platform. On a DT system we would describe the possible hotplugged CPUs and expect a device driver to be present that knows when to perform those operations. g. ^ permalink raw reply [flat|nested] 186+ messages in thread
* Re: ACPI vs DT at runtime 2013-11-15 17:52 ` Olof Johansson @ 2013-11-18 17:47 ` Jon Masters -1 siblings, 0 replies; 186+ messages in thread From: Jon Masters @ 2013-11-18 17:47 UTC (permalink / raw) To: Olof Johansson Cc: Mark Rutland, Grant Likely, linux-arm-kernel, Arnd Bergmann, devicetree On Nov 15, 2013, at 12:52 PM, Olof Johansson <olof@lixom.net> wrote: > On Fri, Nov 15, 2013 at 09:57:17AM +0000, Mark Rutland wrote: >> On Fri, Nov 15, 2013 at 01:44:10AM +0000, Olof Johansson wrote: >>> The more I start to see early UEFI/ACPI code, the more I am certain >>> that we want none of that crap in the kernel. It's making things >>> considerably messier, while we're already very busy trying to convert >>> everything over and enable DT -- we'll be preempting that effort just >>> to add even more boilerplate everywhere and total progress will be >>> hurt. >> >> We are certainly under a lot of pressure with the device tree migration, >> and I agree that adding another information source is going to be a >> source of pain. However, I'd argue that we're going to encounter pain >> regardless of which approach we take. >> >> I'm of the opinion that the only way we should support ACPI is as a >> first-class citizen. We don't need to modify every driver and subsystem >> to support ACPI, only those necessary to support the minimal set of >> platforms using ACPI. ACPI is new in the arm space, and we can enforce >> quality standards on ACPI _now_ above what we're allowing for DT, and >> avoid future problems. > > It's obvious from the very first submission, from a vendor that has worked > closely with "the community" (i.e. one enterprise distro at least), that this > is completely new territory for _everyone_ involved. There's no way that we can > enforce quality standards for ACPI yet -- we don't know what they look like! > Nobody knows how to design a good ACPI implementation or binding. > > Oh wait, there's people who have been doing this for years. Microsoft. They > should be the ones driving this and taking the pain for it. Once the platform > is enabled for their needs, we'll sort it out at our end. After all, that has > worked reasonably well for x86 platforms. For the record, Red Hat's position is to fully back ACPI on ARMv8. This is not to say that you ever will see a commercial product from Red Hat (I have nothing to say there of any kind), but in saying the above you do attempt to preclude the possibility that someone might want to ship a real Enterprise grade OS for the next few years (no offense to others who are shipping today). I would suggest a more pragmatic solution is to leverage the opportunity to be involved in the steering of ACPI on ARMv8 from the ground up, rather than just waiting for others to do it as has happened in the past (isn't that a sad reality? waiting for Microsoft to do the lifting?). It's going to happen either way. Too many silicon companies have billions on the line, and most of them are already on the ACPI train at this point - along with the major OEMs. Now if people said "sure, we'd love to join UEFI Forum but we can't afford it" or something tangible I could take back to others to secure funds or support for such involvement to proceed, then we'd be usefully advancing this :) Jon. ^ permalink raw reply [flat|nested] 186+ messages in thread
* ACPI vs DT at runtime @ 2013-11-18 17:47 ` Jon Masters 0 siblings, 0 replies; 186+ messages in thread From: Jon Masters @ 2013-11-18 17:47 UTC (permalink / raw) To: linux-arm-kernel On Nov 15, 2013, at 12:52 PM, Olof Johansson <olof@lixom.net> wrote: > On Fri, Nov 15, 2013 at 09:57:17AM +0000, Mark Rutland wrote: >> On Fri, Nov 15, 2013 at 01:44:10AM +0000, Olof Johansson wrote: >>> The more I start to see early UEFI/ACPI code, the more I am certain >>> that we want none of that crap in the kernel. It's making things >>> considerably messier, while we're already very busy trying to convert >>> everything over and enable DT -- we'll be preempting that effort just >>> to add even more boilerplate everywhere and total progress will be >>> hurt. >> >> We are certainly under a lot of pressure with the device tree migration, >> and I agree that adding another information source is going to be a >> source of pain. However, I'd argue that we're going to encounter pain >> regardless of which approach we take. >> >> I'm of the opinion that the only way we should support ACPI is as a >> first-class citizen. We don't need to modify every driver and subsystem >> to support ACPI, only those necessary to support the minimal set of >> platforms using ACPI. ACPI is new in the arm space, and we can enforce >> quality standards on ACPI _now_ above what we're allowing for DT, and >> avoid future problems. > > It's obvious from the very first submission, from a vendor that has worked > closely with "the community" (i.e. one enterprise distro at least), that this > is completely new territory for _everyone_ involved. There's no way that we can > enforce quality standards for ACPI yet -- we don't know what they look like! > Nobody knows how to design a good ACPI implementation or binding. > > Oh wait, there's people who have been doing this for years. Microsoft. They > should be the ones driving this and taking the pain for it. Once the platform > is enabled for their needs, we'll sort it out at our end. After all, that has > worked reasonably well for x86 platforms. For the record, Red Hat's position is to fully back ACPI on ARMv8. This is not to say that you ever will see a commercial product from Red Hat (I have nothing to say there of any kind), but in saying the above you do attempt to preclude the possibility that someone might want to ship a real Enterprise grade OS for the next few years (no offense to others who are shipping today). I would suggest a more pragmatic solution is to leverage the opportunity to be involved in the steering of ACPI on ARMv8 from the ground up, rather than just waiting for others to do it as has happened in the past (isn't that a sad reality? waiting for Microsoft to do the lifting?). It's going to happen either way. Too many silicon companies have billions on the line, and most of them are already on the ACPI train at this point - along with the major OEMs. Now if people said "sure, we'd love to join UEFI Forum but we can't afford it" or something tangible I could take back to others to secure funds or support for such involvement to proceed, then we'd be usefully advancing this :) Jon. ^ permalink raw reply [flat|nested] 186+ messages in thread
[parent not found: <20131115175241.GB27174-O5ziIzlqnXUVNXGz7ipsyg@public.gmane.org>]
* Re: ACPI vs DT at runtime 2013-11-15 17:52 ` Olof Johansson @ 2013-11-15 18:08 ` Russell King - ARM Linux -1 siblings, 0 replies; 186+ messages in thread From: Russell King - ARM Linux @ 2013-11-15 18:08 UTC (permalink / raw) To: Olof Johansson Cc: Mark Rutland, Grant Likely, devicetree-u79uwXL29TY76Z2rM5mHXA, Arnd Bergmann, linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r On Fri, Nov 15, 2013 at 09:52:41AM -0800, Olof Johansson wrote: > If we knew exactly what we wanted, it'd be a different story. _We > don't_. We're into year FOUR of the device tree conversion and we're just > now reaching a point where we think we know what a good solution looks > like. The first two years were easy -- they were the trivial devices we're > now talking about on ACPI. After that it got harder. Going through all > of that again with ACPI? No. No way. Microsoft gets to do it and while > they're busy sorting it out, we'll boot with device tree. However, there's a very big danger here. I disagree with the stance you're taking. It seems that under ACPI and DT, we refer to properties by string names. That's good, but do we really want to have different string names for the same property. Or worse still, the same hardware property described in two completely different ways between ACPI and DT? If you think Microsoft will come along, look at what we've done for DT, and implement something in ACPI which is somehow compatible with that, I'd have to ask where you've been for the last 30 years. That's not how Microsoft operates. Microsoft will instead design something different (whether it's intentionally different or not depends on your point of view) but it will be designed how they want and not how we'd like it to be. From their point of view, if it's completely different and very difficult to convert to device tree, that's a win for them because it means they're pushing back on Linux being used in markets they wish to be successful. We have a possibility here to define how we'd like ACPI to look: we have the chance to have ACPI properties using the same naming that we already have for DT. What this means is that _if_ we wanted one day to have first class support for ACPI (which we may wish to for the AML) then we wouldn't have to rewrite all the drivers we've already converted. Yes, we'd have a some churn, but most of that would be along the lines of converting the of_* calls to being firmware_* calls, taking a generic firmware handle. Who knows, we may decide in the future that we want to move everything over to ACPI rather than using DT, and having things as I mention above would make it much easier to convert from DT to ACPI. I believe that we're only going to regret shutting the door on this in the future. It's not like the kernel doesn't already have native support for ACPI. -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org More majordomo info at http://vger.kernel.org/majordomo-info.html ^ permalink raw reply [flat|nested] 186+ messages in thread
* ACPI vs DT at runtime @ 2013-11-15 18:08 ` Russell King - ARM Linux 0 siblings, 0 replies; 186+ messages in thread From: Russell King - ARM Linux @ 2013-11-15 18:08 UTC (permalink / raw) To: linux-arm-kernel On Fri, Nov 15, 2013 at 09:52:41AM -0800, Olof Johansson wrote: > If we knew exactly what we wanted, it'd be a different story. _We > don't_. We're into year FOUR of the device tree conversion and we're just > now reaching a point where we think we know what a good solution looks > like. The first two years were easy -- they were the trivial devices we're > now talking about on ACPI. After that it got harder. Going through all > of that again with ACPI? No. No way. Microsoft gets to do it and while > they're busy sorting it out, we'll boot with device tree. However, there's a very big danger here. I disagree with the stance you're taking. It seems that under ACPI and DT, we refer to properties by string names. That's good, but do we really want to have different string names for the same property. Or worse still, the same hardware property described in two completely different ways between ACPI and DT? If you think Microsoft will come along, look at what we've done for DT, and implement something in ACPI which is somehow compatible with that, I'd have to ask where you've been for the last 30 years. That's not how Microsoft operates. Microsoft will instead design something different (whether it's intentionally different or not depends on your point of view) but it will be designed how they want and not how we'd like it to be. From their point of view, if it's completely different and very difficult to convert to device tree, that's a win for them because it means they're pushing back on Linux being used in markets they wish to be successful. We have a possibility here to define how we'd like ACPI to look: we have the chance to have ACPI properties using the same naming that we already have for DT. What this means is that _if_ we wanted one day to have first class support for ACPI (which we may wish to for the AML) then we wouldn't have to rewrite all the drivers we've already converted. Yes, we'd have a some churn, but most of that would be along the lines of converting the of_* calls to being firmware_* calls, taking a generic firmware handle. Who knows, we may decide in the future that we want to move everything over to ACPI rather than using DT, and having things as I mention above would make it much easier to convert from DT to ACPI. I believe that we're only going to regret shutting the door on this in the future. It's not like the kernel doesn't already have native support for ACPI. ^ permalink raw reply [flat|nested] 186+ messages in thread
[parent not found: <20131115180832.GR16735-l+eeeJia6m9vn6HldHNs0ANdhmdF6hFW@public.gmane.org>]
* Re: ACPI vs DT at runtime 2013-11-15 18:08 ` Russell King - ARM Linux @ 2013-11-15 18:42 ` Olof Johansson -1 siblings, 0 replies; 186+ messages in thread From: Olof Johansson @ 2013-11-15 18:42 UTC (permalink / raw) To: Russell King - ARM Linux Cc: Mark Rutland, Grant Likely, devicetree-u79uwXL29TY76Z2rM5mHXA, Arnd Bergmann, linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r On Fri, Nov 15, 2013 at 10:08 AM, Russell King - ARM Linux <linux-lFZ/pmaqli7XmaaqVzeoHQ@public.gmane.org> wrote: > On Fri, Nov 15, 2013 at 09:52:41AM -0800, Olof Johansson wrote: >> If we knew exactly what we wanted, it'd be a different story. _We >> don't_. We're into year FOUR of the device tree conversion and we're just >> now reaching a point where we think we know what a good solution looks >> like. The first two years were easy -- they were the trivial devices we're >> now talking about on ACPI. After that it got harder. Going through all >> of that again with ACPI? No. No way. Microsoft gets to do it and while >> they're busy sorting it out, we'll boot with device tree. > > However, there's a very big danger here. I disagree with the stance > you're taking. > > It seems that under ACPI and DT, we refer to properties by string names. > That's good, but do we really want to have different string names for the > same property. > > Or worse still, the same hardware property described in two completely > different ways between ACPI and DT? > > If you think Microsoft will come along, look at what we've done for DT, > and implement something in ACPI which is somehow compatible with that, > I'd have to ask where you've been for the last 30 years. That's not > how Microsoft operates. > > Microsoft will instead design something different (whether it's > intentionally different or not depends on your point of view) but it > will be designed how they want and not how we'd like it to be. From > their point of view, if it's completely different and very difficult > to convert to device tree, that's a win for them because it means > they're pushing back on Linux being used in markets they wish to be > successful. Main reply at the bottom but on this: I don't know if this is already happening. Given that APM is asking us how to do clock bindings, I'm guessing they're not working with Microsoft on ACPI yet. So I have no idea if there's a complete impedance mismatch between what we're tying to do, and what they will later require, or not. They might chose to discard any ACPI implementation that's been written just to Linux, and have their own set of criteria. We just don't know at this time since I get the impression we're working on our own right now. > We have a possibility here to define how we'd like ACPI to look: we > have the chance to have ACPI properties using the same naming that we > already have for DT. What this means is that _if_ we wanted one day > to have first class support for ACPI (which we may wish to for the > AML) then we wouldn't have to rewrite all the drivers we've already > converted. Yes, we'd have a some churn, but most of that would be > along the lines of converting the of_* calls to being firmware_* > calls, taking a generic firmware handle. > > Who knows, we may decide in the future that we want to move everything > over to ACPI rather than using DT, and having things as I mention above > would make it much easier to convert from DT to ACPI. > > I believe that we're only going to regret shutting the door on this > in the future. It's not like the kernel doesn't already have native > support for ACPI. Yeah, I should have been clearer on that: It still makes much sense to make sure that we have Linux representation in the UEFI/ACPI standards committees, and it's my impression that Linaro is providing that -- that's a good initiative and should continue. It is particularly true once we move off the path of the simple initial stuff and start to enter corner cases of where things don't fit the standard model (like we're at with DT now), since we'd need to come up with common solutions. -Olof -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org More majordomo info at http://vger.kernel.org/majordomo-info.html ^ permalink raw reply [flat|nested] 186+ messages in thread
* ACPI vs DT at runtime @ 2013-11-15 18:42 ` Olof Johansson 0 siblings, 0 replies; 186+ messages in thread From: Olof Johansson @ 2013-11-15 18:42 UTC (permalink / raw) To: linux-arm-kernel On Fri, Nov 15, 2013 at 10:08 AM, Russell King - ARM Linux <linux@arm.linux.org.uk> wrote: > On Fri, Nov 15, 2013 at 09:52:41AM -0800, Olof Johansson wrote: >> If we knew exactly what we wanted, it'd be a different story. _We >> don't_. We're into year FOUR of the device tree conversion and we're just >> now reaching a point where we think we know what a good solution looks >> like. The first two years were easy -- they were the trivial devices we're >> now talking about on ACPI. After that it got harder. Going through all >> of that again with ACPI? No. No way. Microsoft gets to do it and while >> they're busy sorting it out, we'll boot with device tree. > > However, there's a very big danger here. I disagree with the stance > you're taking. > > It seems that under ACPI and DT, we refer to properties by string names. > That's good, but do we really want to have different string names for the > same property. > > Or worse still, the same hardware property described in two completely > different ways between ACPI and DT? > > If you think Microsoft will come along, look at what we've done for DT, > and implement something in ACPI which is somehow compatible with that, > I'd have to ask where you've been for the last 30 years. That's not > how Microsoft operates. > > Microsoft will instead design something different (whether it's > intentionally different or not depends on your point of view) but it > will be designed how they want and not how we'd like it to be. From > their point of view, if it's completely different and very difficult > to convert to device tree, that's a win for them because it means > they're pushing back on Linux being used in markets they wish to be > successful. Main reply at the bottom but on this: I don't know if this is already happening. Given that APM is asking us how to do clock bindings, I'm guessing they're not working with Microsoft on ACPI yet. So I have no idea if there's a complete impedance mismatch between what we're tying to do, and what they will later require, or not. They might chose to discard any ACPI implementation that's been written just to Linux, and have their own set of criteria. We just don't know at this time since I get the impression we're working on our own right now. > We have a possibility here to define how we'd like ACPI to look: we > have the chance to have ACPI properties using the same naming that we > already have for DT. What this means is that _if_ we wanted one day > to have first class support for ACPI (which we may wish to for the > AML) then we wouldn't have to rewrite all the drivers we've already > converted. Yes, we'd have a some churn, but most of that would be > along the lines of converting the of_* calls to being firmware_* > calls, taking a generic firmware handle. > > Who knows, we may decide in the future that we want to move everything > over to ACPI rather than using DT, and having things as I mention above > would make it much easier to convert from DT to ACPI. > > I believe that we're only going to regret shutting the door on this > in the future. It's not like the kernel doesn't already have native > support for ACPI. Yeah, I should have been clearer on that: It still makes much sense to make sure that we have Linux representation in the UEFI/ACPI standards committees, and it's my impression that Linaro is providing that -- that's a good initiative and should continue. It is particularly true once we move off the path of the simple initial stuff and start to enter corner cases of where things don't fit the standard model (like we're at with DT now), since we'd need to come up with common solutions. -Olof ^ permalink raw reply [flat|nested] 186+ messages in thread
* Re: ACPI vs DT at runtime 2013-11-15 18:08 ` Russell King - ARM Linux @ 2013-11-15 19:56 ` Arnd Bergmann -1 siblings, 0 replies; 186+ messages in thread From: Arnd Bergmann @ 2013-11-15 19:56 UTC (permalink / raw) To: Russell King - ARM Linux Cc: Olof Johansson, Mark Rutland, Grant Likely, devicetree-u79uwXL29TY76Z2rM5mHXA, linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r On Friday 15 November 2013, Russell King - ARM Linux wrote: > On Fri, Nov 15, 2013 at 09:52:41AM -0800, Olof Johansson wrote: > > If we knew exactly what we wanted, it'd be a different story. _We > > don't_. We're into year FOUR of the device tree conversion and we're just > > now reaching a point where we think we know what a good solution looks > > like. The first two years were easy -- they were the trivial devices we're > > now talking about on ACPI. After that it got harder. Going through all > > of that again with ACPI? No. No way. Microsoft gets to do it and while > > they're busy sorting it out, we'll boot with device tree. > > However, there's a very big danger here. I disagree with the stance > you're taking. > > It seems that under ACPI and DT, we refer to properties by string names. > That's good, but do we really want to have different string names for the > same property. For all I know, doing this in ACPI is something that is only now being discussed as Intel wants to be able to reuse the existing features from DT enabled drivers in the kernel and share the implementation between embedded x86 SoCs and embedded ARM/PowerPC/MIPS/... SoCs. That part actually isn't as crazy. The existing ACPI usage however is basically all binary and cannot be shared with DT, in particular it won't help for the orthogonal problem of using ACPI to get "enterprise server" features on ARM64. > Or worse still, the same hardware property described in two completely > different ways between ACPI and DT? I think we should definitely try to have the same peripherals on ACPI and DT use the same bindings for device-specific properties (once we have a agreed on how those are done in ACPI), but I think that's the easier part of the problem. For anything that defines a connection between two a consumer and a producer (IRQ, DMA, pinmux, GPIO, regulator, ...), we need subsystem specific code for each firmware interface, simply because the way to refer to another node is so wildly different. Arnd -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org More majordomo info at http://vger.kernel.org/majordomo-info.html ^ permalink raw reply [flat|nested] 186+ messages in thread
* ACPI vs DT at runtime @ 2013-11-15 19:56 ` Arnd Bergmann 0 siblings, 0 replies; 186+ messages in thread From: Arnd Bergmann @ 2013-11-15 19:56 UTC (permalink / raw) To: linux-arm-kernel On Friday 15 November 2013, Russell King - ARM Linux wrote: > On Fri, Nov 15, 2013 at 09:52:41AM -0800, Olof Johansson wrote: > > If we knew exactly what we wanted, it'd be a different story. _We > > don't_. We're into year FOUR of the device tree conversion and we're just > > now reaching a point where we think we know what a good solution looks > > like. The first two years were easy -- they were the trivial devices we're > > now talking about on ACPI. After that it got harder. Going through all > > of that again with ACPI? No. No way. Microsoft gets to do it and while > > they're busy sorting it out, we'll boot with device tree. > > However, there's a very big danger here. I disagree with the stance > you're taking. > > It seems that under ACPI and DT, we refer to properties by string names. > That's good, but do we really want to have different string names for the > same property. For all I know, doing this in ACPI is something that is only now being discussed as Intel wants to be able to reuse the existing features from DT enabled drivers in the kernel and share the implementation between embedded x86 SoCs and embedded ARM/PowerPC/MIPS/... SoCs. That part actually isn't as crazy. The existing ACPI usage however is basically all binary and cannot be shared with DT, in particular it won't help for the orthogonal problem of using ACPI to get "enterprise server" features on ARM64. > Or worse still, the same hardware property described in two completely > different ways between ACPI and DT? I think we should definitely try to have the same peripherals on ACPI and DT use the same bindings for device-specific properties (once we have a agreed on how those are done in ACPI), but I think that's the easier part of the problem. For anything that defines a connection between two a consumer and a producer (IRQ, DMA, pinmux, GPIO, regulator, ...), we need subsystem specific code for each firmware interface, simply because the way to refer to another node is so wildly different. Arnd ^ permalink raw reply [flat|nested] 186+ messages in thread
[parent not found: <201311152056.47846.arnd-r2nGTMty4D4@public.gmane.org>]
* Re: ACPI vs DT at runtime 2013-11-15 19:56 ` Arnd Bergmann @ 2013-11-15 23:21 ` Russell King - ARM Linux -1 siblings, 0 replies; 186+ messages in thread From: Russell King - ARM Linux @ 2013-11-15 23:21 UTC (permalink / raw) To: Arnd Bergmann Cc: Olof Johansson, Mark Rutland, Grant Likely, devicetree-u79uwXL29TY76Z2rM5mHXA, linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r On Fri, Nov 15, 2013 at 08:56:47PM +0100, Arnd Bergmann wrote: > On Friday 15 November 2013, Russell King - ARM Linux wrote: > > On Fri, Nov 15, 2013 at 09:52:41AM -0800, Olof Johansson wrote: > > > If we knew exactly what we wanted, it'd be a different story. _We > > > don't_. We're into year FOUR of the device tree conversion and we're just > > > now reaching a point where we think we know what a good solution looks > > > like. The first two years were easy -- they were the trivial devices we're > > > now talking about on ACPI. After that it got harder. Going through all > > > of that again with ACPI? No. No way. Microsoft gets to do it and while > > > they're busy sorting it out, we'll boot with device tree. > > > > However, there's a very big danger here. I disagree with the stance > > you're taking. > > > > It seems that under ACPI and DT, we refer to properties by string names. > > That's good, but do we really want to have different string names for the > > same property. > > For all I know, doing this in ACPI is something that is only now being > discussed as Intel wants to be able to reuse the existing features from > DT enabled drivers in the kernel and share the implementation between > embedded x86 SoCs and embedded ARM/PowerPC/MIPS/... SoCs. That part actually > isn't as crazy. > > The existing ACPI usage however is basically all binary and cannot be > shared with DT, in particular it won't help for the orthogonal problem of > using ACPI to get "enterprise server" features on ARM64. That's strange, because the patches I've seen from people who want to add ACPI support to AMBA are all based around very similar strings to those in DT to lookup the same data in ACPI. What's been done there is the function which reads from DT has been duplicated, and instead of reading the information from DT, it reads it from ACPI instead using string names without the vendor prefix. That tells me that what I've stated in my previous email to which you replied is _definitely_ possible to do. That means it's certainly possible to do this without reinventing the wheel, and without having to rewrite lots of parsing code, precisely along the lines I set out in my original email. -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org More majordomo info at http://vger.kernel.org/majordomo-info.html ^ permalink raw reply [flat|nested] 186+ messages in thread
* ACPI vs DT at runtime @ 2013-11-15 23:21 ` Russell King - ARM Linux 0 siblings, 0 replies; 186+ messages in thread From: Russell King - ARM Linux @ 2013-11-15 23:21 UTC (permalink / raw) To: linux-arm-kernel On Fri, Nov 15, 2013 at 08:56:47PM +0100, Arnd Bergmann wrote: > On Friday 15 November 2013, Russell King - ARM Linux wrote: > > On Fri, Nov 15, 2013 at 09:52:41AM -0800, Olof Johansson wrote: > > > If we knew exactly what we wanted, it'd be a different story. _We > > > don't_. We're into year FOUR of the device tree conversion and we're just > > > now reaching a point where we think we know what a good solution looks > > > like. The first two years were easy -- they were the trivial devices we're > > > now talking about on ACPI. After that it got harder. Going through all > > > of that again with ACPI? No. No way. Microsoft gets to do it and while > > > they're busy sorting it out, we'll boot with device tree. > > > > However, there's a very big danger here. I disagree with the stance > > you're taking. > > > > It seems that under ACPI and DT, we refer to properties by string names. > > That's good, but do we really want to have different string names for the > > same property. > > For all I know, doing this in ACPI is something that is only now being > discussed as Intel wants to be able to reuse the existing features from > DT enabled drivers in the kernel and share the implementation between > embedded x86 SoCs and embedded ARM/PowerPC/MIPS/... SoCs. That part actually > isn't as crazy. > > The existing ACPI usage however is basically all binary and cannot be > shared with DT, in particular it won't help for the orthogonal problem of > using ACPI to get "enterprise server" features on ARM64. That's strange, because the patches I've seen from people who want to add ACPI support to AMBA are all based around very similar strings to those in DT to lookup the same data in ACPI. What's been done there is the function which reads from DT has been duplicated, and instead of reading the information from DT, it reads it from ACPI instead using string names without the vendor prefix. That tells me that what I've stated in my previous email to which you replied is _definitely_ possible to do. That means it's certainly possible to do this without reinventing the wheel, and without having to rewrite lots of parsing code, precisely along the lines I set out in my original email. ^ permalink raw reply [flat|nested] 186+ messages in thread
[parent not found: <20131115232109.GT16735-l+eeeJia6m9vn6HldHNs0ANdhmdF6hFW@public.gmane.org>]
* Re: ACPI vs DT at runtime 2013-11-15 23:21 ` Russell King - ARM Linux @ 2013-11-18 15:05 ` Arnd Bergmann -1 siblings, 0 replies; 186+ messages in thread From: Arnd Bergmann @ 2013-11-18 15:05 UTC (permalink / raw) To: Russell King - ARM Linux Cc: Olof Johansson, Mark Rutland, Grant Likely, devicetree-u79uwXL29TY76Z2rM5mHXA, linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r On Saturday 16 November 2013, Russell King - ARM Linux wrote: > On Fri, Nov 15, 2013 at 08:56:47PM +0100, Arnd Bergmann wrote: > > > > For all I know, doing this in ACPI is something that is only now being > > discussed as Intel wants to be able to reuse the existing features from > > DT enabled drivers in the kernel and share the implementation between > > embedded x86 SoCs and embedded ARM/PowerPC/MIPS/... SoCs. That part actually > > isn't as crazy. > > > > The existing ACPI usage however is basically all binary and cannot be > > shared with DT, in particular it won't help for the orthogonal problem of > > using ACPI to get "enterprise server" features on ARM64. > > That's strange, because the patches I've seen from people who want to > add ACPI support to AMBA are all based around very similar strings to > those in DT to lookup the same data in ACPI. Can you point to specific patches? I can't say I'm an expert on this, but everything I've seen with ACPI is tables of binary data with four-letter identifiers that are defined by the ACPI group, but not using strings in a similar manner to DT. Apple has an extension to do DT-style properties in their phones, and we had a discussion at the kernel summit to do a more generic variation of the same idea that Darren Hart presented, but that is still in prototype stage. > What's been done there is the function which reads from DT has been > duplicated, and instead of reading the information from DT, it reads it > from ACPI instead using string names without the vendor prefix. The recently posted x-gene ahci driver does this, but from what I can tell, the implementation is inappropriate on both DT (because of the use of unreadable four-character upper-case identifiers) and on ACPI (because of the use of non-standard identifiers). > That tells me that what I've stated in my previous email to which you > replied is _definitely_ possible to do. That means it's certainly > possible to do this without reinventing the wheel, and without having > to rewrite lots of parsing code, precisely along the lines I set out > in my original email. To clarify my complaint: while we can do simple (boolean, integer, text, or arrays of those three) properties with Darren's approach as long as they are private to one device, that won't suffice for anything that requires links between devices. We have phandles on DT that can be freely mixed with integers for things like GPIO or clock references. ACPI has similar references, but uses a different syntax for doing the same things, and these have to be standardized per subsystem (i.e. per type of connection) to make sense. As a result, every subsystem that has a producer-consumer type connection requires different code for DT and for ACPI. If the subsystem-to-driver interface is done well, we can have a common device driver, but in a lot of cases there will be a leaky abstraction. As Olof pointed out, even migrating from a DT-only interface to a generic interface would require changing each driver, even if the result is no more ugly than the current state. Arnd -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org More majordomo info at http://vger.kernel.org/majordomo-info.html ^ permalink raw reply [flat|nested] 186+ messages in thread
* ACPI vs DT at runtime @ 2013-11-18 15:05 ` Arnd Bergmann 0 siblings, 0 replies; 186+ messages in thread From: Arnd Bergmann @ 2013-11-18 15:05 UTC (permalink / raw) To: linux-arm-kernel On Saturday 16 November 2013, Russell King - ARM Linux wrote: > On Fri, Nov 15, 2013 at 08:56:47PM +0100, Arnd Bergmann wrote: > > > > For all I know, doing this in ACPI is something that is only now being > > discussed as Intel wants to be able to reuse the existing features from > > DT enabled drivers in the kernel and share the implementation between > > embedded x86 SoCs and embedded ARM/PowerPC/MIPS/... SoCs. That part actually > > isn't as crazy. > > > > The existing ACPI usage however is basically all binary and cannot be > > shared with DT, in particular it won't help for the orthogonal problem of > > using ACPI to get "enterprise server" features on ARM64. > > That's strange, because the patches I've seen from people who want to > add ACPI support to AMBA are all based around very similar strings to > those in DT to lookup the same data in ACPI. Can you point to specific patches? I can't say I'm an expert on this, but everything I've seen with ACPI is tables of binary data with four-letter identifiers that are defined by the ACPI group, but not using strings in a similar manner to DT. Apple has an extension to do DT-style properties in their phones, and we had a discussion at the kernel summit to do a more generic variation of the same idea that Darren Hart presented, but that is still in prototype stage. > What's been done there is the function which reads from DT has been > duplicated, and instead of reading the information from DT, it reads it > from ACPI instead using string names without the vendor prefix. The recently posted x-gene ahci driver does this, but from what I can tell, the implementation is inappropriate on both DT (because of the use of unreadable four-character upper-case identifiers) and on ACPI (because of the use of non-standard identifiers). > That tells me that what I've stated in my previous email to which you > replied is _definitely_ possible to do. That means it's certainly > possible to do this without reinventing the wheel, and without having > to rewrite lots of parsing code, precisely along the lines I set out > in my original email. To clarify my complaint: while we can do simple (boolean, integer, text, or arrays of those three) properties with Darren's approach as long as they are private to one device, that won't suffice for anything that requires links between devices. We have phandles on DT that can be freely mixed with integers for things like GPIO or clock references. ACPI has similar references, but uses a different syntax for doing the same things, and these have to be standardized per subsystem (i.e. per type of connection) to make sense. As a result, every subsystem that has a producer-consumer type connection requires different code for DT and for ACPI. If the subsystem-to-driver interface is done well, we can have a common device driver, but in a lot of cases there will be a leaky abstraction. As Olof pointed out, even migrating from a DT-only interface to a generic interface would require changing each driver, even if the result is no more ugly than the current state. Arnd ^ permalink raw reply [flat|nested] 186+ messages in thread
[parent not found: <201311181605.37300.arnd-r2nGTMty4D4@public.gmane.org>]
* Re: ACPI vs DT at runtime 2013-11-18 15:05 ` Arnd Bergmann @ 2013-11-18 15:19 ` Russell King - ARM Linux -1 siblings, 0 replies; 186+ messages in thread From: Russell King - ARM Linux @ 2013-11-18 15:19 UTC (permalink / raw) To: Arnd Bergmann Cc: Olof Johansson, Mark Rutland, Grant Likely, devicetree-u79uwXL29TY76Z2rM5mHXA, linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r On Mon, Nov 18, 2013 at 04:05:37PM +0100, Arnd Bergmann wrote: > On Saturday 16 November 2013, Russell King - ARM Linux wrote: > > On Fri, Nov 15, 2013 at 08:56:47PM +0100, Arnd Bergmann wrote: > > > > > > For all I know, doing this in ACPI is something that is only now being > > > discussed as Intel wants to be able to reuse the existing features from > > > DT enabled drivers in the kernel and share the implementation between > > > embedded x86 SoCs and embedded ARM/PowerPC/MIPS/... SoCs. That part actually > > > isn't as crazy. > > > > > > The existing ACPI usage however is basically all binary and cannot be > > > shared with DT, in particular it won't help for the orthogonal problem of > > > using ACPI to get "enterprise server" features on ARM64. > > > > That's strange, because the patches I've seen from people who want to > > add ACPI support to AMBA are all based around very similar strings to > > those in DT to lookup the same data in ACPI. > > Can you point to specific patches? No, because they weren't publically posted, so I don't feel that I can say all that much; they were from quite a large company though. > I can't say I'm an expert on this, but everything I've seen with ACPI > is tables of binary data with four-letter identifiers that are defined > by the ACPI group, but not using strings in a similar manner to DT. They are using strings which are the same as the DT properties, but without the vendor prefix - but yes, to only retrieve things like booleans, u32s and such like. They also have support for fixed-rate clocks via the clk API too... I'd like them to post the patches publically so a more open discussion could occur. -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org More majordomo info at http://vger.kernel.org/majordomo-info.html ^ permalink raw reply [flat|nested] 186+ messages in thread
* ACPI vs DT at runtime @ 2013-11-18 15:19 ` Russell King - ARM Linux 0 siblings, 0 replies; 186+ messages in thread From: Russell King - ARM Linux @ 2013-11-18 15:19 UTC (permalink / raw) To: linux-arm-kernel On Mon, Nov 18, 2013 at 04:05:37PM +0100, Arnd Bergmann wrote: > On Saturday 16 November 2013, Russell King - ARM Linux wrote: > > On Fri, Nov 15, 2013 at 08:56:47PM +0100, Arnd Bergmann wrote: > > > > > > For all I know, doing this in ACPI is something that is only now being > > > discussed as Intel wants to be able to reuse the existing features from > > > DT enabled drivers in the kernel and share the implementation between > > > embedded x86 SoCs and embedded ARM/PowerPC/MIPS/... SoCs. That part actually > > > isn't as crazy. > > > > > > The existing ACPI usage however is basically all binary and cannot be > > > shared with DT, in particular it won't help for the orthogonal problem of > > > using ACPI to get "enterprise server" features on ARM64. > > > > That's strange, because the patches I've seen from people who want to > > add ACPI support to AMBA are all based around very similar strings to > > those in DT to lookup the same data in ACPI. > > Can you point to specific patches? No, because they weren't publically posted, so I don't feel that I can say all that much; they were from quite a large company though. > I can't say I'm an expert on this, but everything I've seen with ACPI > is tables of binary data with four-letter identifiers that are defined > by the ACPI group, but not using strings in a similar manner to DT. They are using strings which are the same as the DT properties, but without the vendor prefix - but yes, to only retrieve things like booleans, u32s and such like. They also have support for fixed-rate clocks via the clk API too... I'd like them to post the patches publically so a more open discussion could occur. ^ permalink raw reply [flat|nested] 186+ messages in thread
* Re: ACPI vs DT at runtime 2013-11-18 15:19 ` Russell King - ARM Linux @ 2013-11-18 15:46 ` Arnd Bergmann -1 siblings, 0 replies; 186+ messages in thread From: Arnd Bergmann @ 2013-11-18 15:46 UTC (permalink / raw) To: Russell King - ARM Linux Cc: Olof Johansson, Mark Rutland, linux-arm-kernel, Grant Likely, devicetree On Monday 18 November 2013, Russell King - ARM Linux wrote: > > Can you point to specific patches? > > No, because they weren't publically posted, so I don't feel that I can > say all that much; they were from quite a large company though. I see. > > I can't say I'm an expert on this, but everything I've seen with ACPI > > is tables of binary data with four-letter identifiers that are defined > > by the ACPI group, but not using strings in a similar manner to DT. > > They are using strings which are the same as the DT properties, but > without the vendor prefix - but yes, to only retrieve things like > booleans, u32s and such like. They also have support for fixed-rate > clocks via the clk API too... > > I'd like them to post the patches publically so a more open discussion > could occur. I'd definitely like that too, especially since managing clocks etc. is (as multiple people have pointed out in this thread) a very un-ACPI-like thing to do and it would be important for them to have the debate whether that has a chance of getting accepted in the kernel (or the ACPI spec, for that matter) or not. Arnd ^ permalink raw reply [flat|nested] 186+ messages in thread
* ACPI vs DT at runtime @ 2013-11-18 15:46 ` Arnd Bergmann 0 siblings, 0 replies; 186+ messages in thread From: Arnd Bergmann @ 2013-11-18 15:46 UTC (permalink / raw) To: linux-arm-kernel On Monday 18 November 2013, Russell King - ARM Linux wrote: > > Can you point to specific patches? > > No, because they weren't publically posted, so I don't feel that I can > say all that much; they were from quite a large company though. I see. > > I can't say I'm an expert on this, but everything I've seen with ACPI > > is tables of binary data with four-letter identifiers that are defined > > by the ACPI group, but not using strings in a similar manner to DT. > > They are using strings which are the same as the DT properties, but > without the vendor prefix - but yes, to only retrieve things like > booleans, u32s and such like. They also have support for fixed-rate > clocks via the clk API too... > > I'd like them to post the patches publically so a more open discussion > could occur. I'd definitely like that too, especially since managing clocks etc. is (as multiple people have pointed out in this thread) a very un-ACPI-like thing to do and it would be important for them to have the debate whether that has a chance of getting accepted in the kernel (or the ACPI spec, for that matter) or not. Arnd ^ permalink raw reply [flat|nested] 186+ messages in thread
* Re: ACPI vs DT at runtime 2013-11-18 15:05 ` Arnd Bergmann @ 2013-11-21 16:10 ` Grant Likely -1 siblings, 0 replies; 186+ messages in thread From: Grant Likely @ 2013-11-21 16:10 UTC (permalink / raw) To: Arnd Bergmann, Russell King - ARM Linux Cc: Olof Johansson, Mark Rutland, devicetree-u79uwXL29TY76Z2rM5mHXA, linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r On Mon, 18 Nov 2013 16:05:37 +0100, Arnd Bergmann <arnd-r2nGTMty4D4@public.gmane.org> wrote: > On Saturday 16 November 2013, Russell King - ARM Linux wrote: > > On Fri, Nov 15, 2013 at 08:56:47PM +0100, Arnd Bergmann wrote: > > > > > > For all I know, doing this in ACPI is something that is only now being > > > discussed as Intel wants to be able to reuse the existing features from > > > DT enabled drivers in the kernel and share the implementation between > > > embedded x86 SoCs and embedded ARM/PowerPC/MIPS/... SoCs. That part actually > > > isn't as crazy. > > > > > > The existing ACPI usage however is basically all binary and cannot be > > > shared with DT, in particular it won't help for the orthogonal problem of > > > using ACPI to get "enterprise server" features on ARM64. > > > > That's strange, because the patches I've seen from people who want to > > add ACPI support to AMBA are all based around very similar strings to > > those in DT to lookup the same data in ACPI. > > Can you point to specific patches? I can't say I'm an expert on this, but > everything I've seen with ACPI is tables of binary data with four-letter > identifiers that are defined by the ACPI group, but not using strings > in a similar manner to DT. Apple has an extension to do DT-style properties > in their phones, and we had a discussion at the kernel summit to do > a more generic variation of the same idea that Darren Hart presented, > but that is still in prototype stage. ACPI is a mix of binary tables (can be dereferenced directly as C structs) and the "ACPI Namespace" which looks remarkably like a device tree, except the nodes contains bytecode methods instead of static properties. Many of the methods are defined by the ACPI standard to be called for various events; like initialization and power management activities. A lot of core devices on the platform are described both in the static tables and the ACPI namespace. (The ACPI namepaces is the structure decoded by interpreting the bytecode in the DSDT and SSDT tables.) As I see it, ACPI prefers to defer the difficult bits to the platform by using a bytecode to perform arbitrary operations. DT on the other hand defers to the kernel. > > What's been done there is the function which reads from DT has been > > duplicated, and instead of reading the information from DT, it reads it > > from ACPI instead using string names without the vendor prefix. > > The recently posted x-gene ahci driver does this, but from what I can > tell, the implementation is inappropriate on both DT (because of the > use of unreadable four-character upper-case identifiers) and on ACPI > (because of the use of non-standard identifiers). > > > That tells me that what I've stated in my previous email to which you > > replied is _definitely_ possible to do. That means it's certainly > > possible to do this without reinventing the wheel, and without having > > to rewrite lots of parsing code, precisely along the lines I set out > > in my original email. > > To clarify my complaint: while we can do simple (boolean, integer, text, > or arrays of those three) properties with Darren's approach as long as they > are private to one device, that won't suffice for anything that requires > links between devices. We have phandles on DT that can be freely mixed with > integers for things like GPIO or clock references. ACPI has similar > references, but uses a different syntax for doing the same things, and these > have to be standardized per subsystem (i.e. per type of connection) to make > sense. > As a result, every subsystem that has a producer-consumer type connection > requires different code for DT and for ACPI. If the subsystem-to-driver > interface is done well, we can have a common device driver, but in a > lot of cases there will be a leaky abstraction. As Olof pointed out, > even migrating from a DT-only interface to a generic interface would > require changing each driver, even if the result is no more ugly than > the current state. This too should look transparent to device drivers. DT and ACPI have different mechanism for doing cross tree references, but the concept is the same. A driver calling something like "platform_get_my_gpio_resource()" should do the right thing with either an ACPI or DT backend. None of that should appear as custom device driver or architecture code. It should be generic code supporting the driver core. Regardless of the ACPI on ARM question, we need to do this anyway. There are Intel platforms that need it. g. -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org More majordomo info at http://vger.kernel.org/majordomo-info.html ^ permalink raw reply [flat|nested] 186+ messages in thread
* ACPI vs DT at runtime @ 2013-11-21 16:10 ` Grant Likely 0 siblings, 0 replies; 186+ messages in thread From: Grant Likely @ 2013-11-21 16:10 UTC (permalink / raw) To: linux-arm-kernel On Mon, 18 Nov 2013 16:05:37 +0100, Arnd Bergmann <arnd@arndb.de> wrote: > On Saturday 16 November 2013, Russell King - ARM Linux wrote: > > On Fri, Nov 15, 2013 at 08:56:47PM +0100, Arnd Bergmann wrote: > > > > > > For all I know, doing this in ACPI is something that is only now being > > > discussed as Intel wants to be able to reuse the existing features from > > > DT enabled drivers in the kernel and share the implementation between > > > embedded x86 SoCs and embedded ARM/PowerPC/MIPS/... SoCs. That part actually > > > isn't as crazy. > > > > > > The existing ACPI usage however is basically all binary and cannot be > > > shared with DT, in particular it won't help for the orthogonal problem of > > > using ACPI to get "enterprise server" features on ARM64. > > > > That's strange, because the patches I've seen from people who want to > > add ACPI support to AMBA are all based around very similar strings to > > those in DT to lookup the same data in ACPI. > > Can you point to specific patches? I can't say I'm an expert on this, but > everything I've seen with ACPI is tables of binary data with four-letter > identifiers that are defined by the ACPI group, but not using strings > in a similar manner to DT. Apple has an extension to do DT-style properties > in their phones, and we had a discussion at the kernel summit to do > a more generic variation of the same idea that Darren Hart presented, > but that is still in prototype stage. ACPI is a mix of binary tables (can be dereferenced directly as C structs) and the "ACPI Namespace" which looks remarkably like a device tree, except the nodes contains bytecode methods instead of static properties. Many of the methods are defined by the ACPI standard to be called for various events; like initialization and power management activities. A lot of core devices on the platform are described both in the static tables and the ACPI namespace. (The ACPI namepaces is the structure decoded by interpreting the bytecode in the DSDT and SSDT tables.) As I see it, ACPI prefers to defer the difficult bits to the platform by using a bytecode to perform arbitrary operations. DT on the other hand defers to the kernel. > > What's been done there is the function which reads from DT has been > > duplicated, and instead of reading the information from DT, it reads it > > from ACPI instead using string names without the vendor prefix. > > The recently posted x-gene ahci driver does this, but from what I can > tell, the implementation is inappropriate on both DT (because of the > use of unreadable four-character upper-case identifiers) and on ACPI > (because of the use of non-standard identifiers). > > > That tells me that what I've stated in my previous email to which you > > replied is _definitely_ possible to do. That means it's certainly > > possible to do this without reinventing the wheel, and without having > > to rewrite lots of parsing code, precisely along the lines I set out > > in my original email. > > To clarify my complaint: while we can do simple (boolean, integer, text, > or arrays of those three) properties with Darren's approach as long as they > are private to one device, that won't suffice for anything that requires > links between devices. We have phandles on DT that can be freely mixed with > integers for things like GPIO or clock references. ACPI has similar > references, but uses a different syntax for doing the same things, and these > have to be standardized per subsystem (i.e. per type of connection) to make > sense. > As a result, every subsystem that has a producer-consumer type connection > requires different code for DT and for ACPI. If the subsystem-to-driver > interface is done well, we can have a common device driver, but in a > lot of cases there will be a leaky abstraction. As Olof pointed out, > even migrating from a DT-only interface to a generic interface would > require changing each driver, even if the result is no more ugly than > the current state. This too should look transparent to device drivers. DT and ACPI have different mechanism for doing cross tree references, but the concept is the same. A driver calling something like "platform_get_my_gpio_resource()" should do the right thing with either an ACPI or DT backend. None of that should appear as custom device driver or architecture code. It should be generic code supporting the driver core. Regardless of the ACPI on ARM question, we need to do this anyway. There are Intel platforms that need it. g. ^ permalink raw reply [flat|nested] 186+ messages in thread
[parent not found: <20131121161037.C528CC406A3-WNowdnHR2B42iJbIjFUEsiwD8/FfD2ys@public.gmane.org>]
* Re: ACPI vs DT at runtime 2013-11-21 16:10 ` Grant Likely @ 2013-11-21 18:26 ` Arnd Bergmann -1 siblings, 0 replies; 186+ messages in thread From: Arnd Bergmann @ 2013-11-21 18:26 UTC (permalink / raw) To: Grant Likely Cc: Russell King - ARM Linux, Olof Johansson, Mark Rutland, devicetree-u79uwXL29TY76Z2rM5mHXA, linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r On Thursday 21 November 2013, Grant Likely wrote: > This too should look transparent to device drivers. DT and ACPI have > different mechanism for doing cross tree references, but the concept is > the same. A driver calling something like "platform_get_my_gpio_resource()" > should do the right thing with either an ACPI or DT backend. None of > that should appear as custom device driver or architecture code. It > should be generic code supporting the driver core. I definitely agree with the approach, and I've already made some suggestions for how to implement parts of this. The problem is that this will touch dozens of subsystems and hundreds of device drivers. We have the experience of having done it all before when introducing the DT interfaces and some of the new subsystems, which is a big advantage for doing it again, but on the other hand there are now more drivers than we had before, and we have to be more careful so we don't break the existing code base. > Regardless of the ACPI on ARM question, we need to do this anyway. There > are Intel platforms that need it. There is certainly some overhead, but my guess is that it's actually less than half of the total work because they are trying to do something completely different: - Intel are doing this only for embedded systems, so they don't have to worry about subsystems that are only relevant to servers (e.g. fault isolation) - Significant parts of the x86 architecture are completely standardized and don't need to be described in a complex matter (e.g. IOMMU) + A number of subsystems that Intel needs to handle on embedded systems should really not be described in detail on servers on any architecture but instead be handled in AML or SMBIOS (e.g. pinctrl or phy). + Some subsystems won't even be used on servers and don't need to be handled at all but are very relevant to embedded systems (e.g. v4l or dmaengine) For the parts that do overlap (e.g. irqdomain or reset), we should certainly work together across architectures. Arnd -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org More majordomo info at http://vger.kernel.org/majordomo-info.html ^ permalink raw reply [flat|nested] 186+ messages in thread
* ACPI vs DT at runtime @ 2013-11-21 18:26 ` Arnd Bergmann 0 siblings, 0 replies; 186+ messages in thread From: Arnd Bergmann @ 2013-11-21 18:26 UTC (permalink / raw) To: linux-arm-kernel On Thursday 21 November 2013, Grant Likely wrote: > This too should look transparent to device drivers. DT and ACPI have > different mechanism for doing cross tree references, but the concept is > the same. A driver calling something like "platform_get_my_gpio_resource()" > should do the right thing with either an ACPI or DT backend. None of > that should appear as custom device driver or architecture code. It > should be generic code supporting the driver core. I definitely agree with the approach, and I've already made some suggestions for how to implement parts of this. The problem is that this will touch dozens of subsystems and hundreds of device drivers. We have the experience of having done it all before when introducing the DT interfaces and some of the new subsystems, which is a big advantage for doing it again, but on the other hand there are now more drivers than we had before, and we have to be more careful so we don't break the existing code base. > Regardless of the ACPI on ARM question, we need to do this anyway. There > are Intel platforms that need it. There is certainly some overhead, but my guess is that it's actually less than half of the total work because they are trying to do something completely different: - Intel are doing this only for embedded systems, so they don't have to worry about subsystems that are only relevant to servers (e.g. fault isolation) - Significant parts of the x86 architecture are completely standardized and don't need to be described in a complex matter (e.g. IOMMU) + A number of subsystems that Intel needs to handle on embedded systems should really not be described in detail on servers on any architecture but instead be handled in AML or SMBIOS (e.g. pinctrl or phy). + Some subsystems won't even be used on servers and don't need to be handled at all but are very relevant to embedded systems (e.g. v4l or dmaengine) For the parts that do overlap (e.g. irqdomain or reset), we should certainly work together across architectures. Arnd ^ permalink raw reply [flat|nested] 186+ messages in thread
* Re: ACPI vs DT at runtime 2013-11-21 18:26 ` Arnd Bergmann @ 2013-11-21 19:40 ` Mark Brown -1 siblings, 0 replies; 186+ messages in thread From: Mark Brown @ 2013-11-21 19:40 UTC (permalink / raw) To: Arnd Bergmann Cc: Mark Rutland, devicetree, Russell King - ARM Linux, Grant Likely, Olof Johansson, linux-arm-kernel [-- Attachment #1.1: Type: text/plain, Size: 556 bytes --] On Thu, Nov 21, 2013 at 07:26:02PM +0100, Arnd Bergmann wrote: > + A number of subsystems that Intel needs to handle on embedded systems > should really not be described in detail on servers on any architecture > but instead be handled in AML or SMBIOS (e.g. pinctrl or phy). Are we 100% sure about this assumption? We're saying "server" here but how much of that is really "distro" - if it is distro then you start to get things like laptops coming into play which do have a lot more of the fun stuff that we see on embedded devices in active use. [-- Attachment #1.2: Digital signature --] [-- Type: application/pgp-signature, Size: 836 bytes --] [-- Attachment #2: Type: text/plain, Size: 176 bytes --] _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel ^ permalink raw reply [flat|nested] 186+ messages in thread
* ACPI vs DT at runtime @ 2013-11-21 19:40 ` Mark Brown 0 siblings, 0 replies; 186+ messages in thread From: Mark Brown @ 2013-11-21 19:40 UTC (permalink / raw) To: linux-arm-kernel On Thu, Nov 21, 2013 at 07:26:02PM +0100, Arnd Bergmann wrote: > + A number of subsystems that Intel needs to handle on embedded systems > should really not be described in detail on servers on any architecture > but instead be handled in AML or SMBIOS (e.g. pinctrl or phy). Are we 100% sure about this assumption? We're saying "server" here but how much of that is really "distro" - if it is distro then you start to get things like laptops coming into play which do have a lot more of the fun stuff that we see on embedded devices in active use. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 836 bytes Desc: Digital signature URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20131121/2b2de12c/attachment.sig> ^ permalink raw reply [flat|nested] 186+ messages in thread
[parent not found: <20131118151900.GF16735@ n2100.arm.linux.org.uk>]
[parent not found: <20131118151900.GF16735-l+eeeJia6m9vn6HldHNs0ANdhmdF6hFW@public.gmane.org>]
* Re: ACPI vs DT at runtime 2013-11-18 15:19 ` Russell King - ARM Linux @ 2013-11-21 16:11 ` Grant Likely -1 siblings, 0 replies; 186+ messages in thread From: Grant Likely @ 2013-11-21 16:11 UTC (permalink / raw) To: Russell King - ARM Linux, Arnd Bergmann Cc: Olof Johansson, Mark Rutland, devicetree-u79uwXL29TY76Z2rM5mHXA, linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r On Mon, 18 Nov 2013 15:19:01 +0000, Russell King - ARM Linux <linux-lFZ/pmaqli7XmaaqVzeoHQ@public.gmane.org> wrote: > They are using strings which are the same as the DT properties, but > without the vendor prefix - but yes, to only retrieve things like > booleans, u32s and such like. They also have support for fixed-rate > clocks via the clk API too... > > I'd like them to post the patches publically so a more open discussion > could occur. Indeed. g. -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org More majordomo info at http://vger.kernel.org/majordomo-info.html ^ permalink raw reply [flat|nested] 186+ messages in thread
* ACPI vs DT at runtime @ 2013-11-21 16:11 ` Grant Likely 0 siblings, 0 replies; 186+ messages in thread From: Grant Likely @ 2013-11-21 16:11 UTC (permalink / raw) To: linux-arm-kernel On Mon, 18 Nov 2013 15:19:01 +0000, Russell King - ARM Linux <linux@arm.linux.org.uk> wrote: > They are using strings which are the same as the DT properties, but > without the vendor prefix - but yes, to only retrieve things like > booleans, u32s and such like. They also have support for fixed-rate > clocks via the clk API too... > > I'd like them to post the patches publically so a more open discussion > could occur. Indeed. g. ^ permalink raw reply [flat|nested] 186+ messages in thread
* Re: ACPI vs DT at runtime 2013-11-15 23:21 ` Russell King - ARM Linux @ 2013-11-21 16:00 ` Grant Likely -1 siblings, 0 replies; 186+ messages in thread From: Grant Likely @ 2013-11-21 16:00 UTC (permalink / raw) To: Russell King - ARM Linux, Arnd Bergmann Cc: Olof Johansson, Mark Rutland, devicetree-u79uwXL29TY76Z2rM5mHXA, linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r On Fri, 15 Nov 2013 23:21:09 +0000, Russell King - ARM Linux <linux-lFZ/pmaqli7XmaaqVzeoHQ@public.gmane.org> wrote: > On Fri, Nov 15, 2013 at 08:56:47PM +0100, Arnd Bergmann wrote: > > On Friday 15 November 2013, Russell King - ARM Linux wrote: > > > On Fri, Nov 15, 2013 at 09:52:41AM -0800, Olof Johansson wrote: > > > > If we knew exactly what we wanted, it'd be a different story. _We > > > > don't_. We're into year FOUR of the device tree conversion and we're just > > > > now reaching a point where we think we know what a good solution looks > > > > like. The first two years were easy -- they were the trivial devices we're > > > > now talking about on ACPI. After that it got harder. Going through all > > > > of that again with ACPI? No. No way. Microsoft gets to do it and while > > > > they're busy sorting it out, we'll boot with device tree. > > > > > > However, there's a very big danger here. I disagree with the stance > > > you're taking. > > > > > > It seems that under ACPI and DT, we refer to properties by string names. > > > That's good, but do we really want to have different string names for the > > > same property. > > > > For all I know, doing this in ACPI is something that is only now being > > discussed as Intel wants to be able to reuse the existing features from > > DT enabled drivers in the kernel and share the implementation between > > embedded x86 SoCs and embedded ARM/PowerPC/MIPS/... SoCs. That part actually > > isn't as crazy. > > > > The existing ACPI usage however is basically all binary and cannot be > > shared with DT, in particular it won't help for the orthogonal problem of > > using ACPI to get "enterprise server" features on ARM64. > > That's strange, because the patches I've seen from people who want to > add ACPI support to AMBA are all based around very similar strings to > those in DT to lookup the same data in ACPI. > > What's been done there is the function which reads from DT has been > duplicated, and instead of reading the information from DT, it reads it > from ACPI instead using string names without the vendor prefix. The fact that they are using different strings is a problem though. Push back on that. As much as possible the property formats between DT and ACPI should be identical. This is entirely new territory for ACPI and we have significant influence over it. g. -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org More majordomo info at http://vger.kernel.org/majordomo-info.html ^ permalink raw reply [flat|nested] 186+ messages in thread
* ACPI vs DT at runtime @ 2013-11-21 16:00 ` Grant Likely 0 siblings, 0 replies; 186+ messages in thread From: Grant Likely @ 2013-11-21 16:00 UTC (permalink / raw) To: linux-arm-kernel On Fri, 15 Nov 2013 23:21:09 +0000, Russell King - ARM Linux <linux@arm.linux.org.uk> wrote: > On Fri, Nov 15, 2013 at 08:56:47PM +0100, Arnd Bergmann wrote: > > On Friday 15 November 2013, Russell King - ARM Linux wrote: > > > On Fri, Nov 15, 2013 at 09:52:41AM -0800, Olof Johansson wrote: > > > > If we knew exactly what we wanted, it'd be a different story. _We > > > > don't_. We're into year FOUR of the device tree conversion and we're just > > > > now reaching a point where we think we know what a good solution looks > > > > like. The first two years were easy -- they were the trivial devices we're > > > > now talking about on ACPI. After that it got harder. Going through all > > > > of that again with ACPI? No. No way. Microsoft gets to do it and while > > > > they're busy sorting it out, we'll boot with device tree. > > > > > > However, there's a very big danger here. I disagree with the stance > > > you're taking. > > > > > > It seems that under ACPI and DT, we refer to properties by string names. > > > That's good, but do we really want to have different string names for the > > > same property. > > > > For all I know, doing this in ACPI is something that is only now being > > discussed as Intel wants to be able to reuse the existing features from > > DT enabled drivers in the kernel and share the implementation between > > embedded x86 SoCs and embedded ARM/PowerPC/MIPS/... SoCs. That part actually > > isn't as crazy. > > > > The existing ACPI usage however is basically all binary and cannot be > > shared with DT, in particular it won't help for the orthogonal problem of > > using ACPI to get "enterprise server" features on ARM64. > > That's strange, because the patches I've seen from people who want to > add ACPI support to AMBA are all based around very similar strings to > those in DT to lookup the same data in ACPI. > > What's been done there is the function which reads from DT has been > duplicated, and instead of reading the information from DT, it reads it > from ACPI instead using string names without the vendor prefix. The fact that they are using different strings is a problem though. Push back on that. As much as possible the property formats between DT and ACPI should be identical. This is entirely new territory for ACPI and we have significant influence over it. g. ^ permalink raw reply [flat|nested] 186+ messages in thread
* Re: ACPI vs DT at runtime 2013-11-15 17:52 ` Olof Johansson @ 2013-11-19 11:30 ` Mark Rutland -1 siblings, 0 replies; 186+ messages in thread From: Mark Rutland @ 2013-11-19 11:30 UTC (permalink / raw) To: Olof Johansson Cc: devicetree-u79uwXL29TY76Z2rM5mHXA, linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r, Grant Likely, Rob Herring, Arnd Bergmann On Fri, Nov 15, 2013 at 05:52:41PM +0000, Olof Johansson wrote: > On Fri, Nov 15, 2013 at 09:57:17AM +0000, Mark Rutland wrote: > > On Fri, Nov 15, 2013 at 01:44:10AM +0000, Olof Johansson wrote: > > > The more I start to see early UEFI/ACPI code, the more I am certain > > > that we want none of that crap in the kernel. It's making things > > > considerably messier, while we're already very busy trying to convert > > > everything over and enable DT -- we'll be preempting that effort just > > > to add even more boilerplate everywhere and total progress will be > > > hurt. > > > > We are certainly under a lot of pressure with the device tree migration, > > and I agree that adding another information source is going to be a > > source of pain. However, I'd argue that we're going to encounter pain > > regardless of which approach we take. > > > > I'm of the opinion that the only way we should support ACPI is as a > > first-class citizen. We don't need to modify every driver and subsystem > > to support ACPI, only those necessary to support the minimal set of > > platforms using ACPI. ACPI is new in the arm space, and we can enforce > > quality standards on ACPI _now_ above what we're allowing for DT, and > > avoid future problems. > > It's obvious from the very first submission, from a vendor that has worked > closely with "the community" (i.e. one enterprise distro at least), that this > is completely new territory for _everyone_ involved. There's no way that we can > enforce quality standards for ACPI yet -- we don't know what they look like! > Nobody knows how to design a good ACPI implementation or binding. If we don't know what quality standards we require for ACPI, then I would rather see ACPI delayed until we are more comfortable with it than to enforce an arbitrary set of rules required to enable mapping it to device tree. > Oh wait, there's people who have been doing this for years. Microsoft. They > should be the ones driving this and taking the pain for it. Once the platform > is enabled for their needs, we'll sort it out at our end. After all, that has > worked reasonably well for x86 platforms. I'm not sure it's entirely reasonable to assume that Microsoft will swoop in and develop standards that are useful to us or even applicable to the vast majority of the systems that are likely to exist. If they do, then we will (by the expectation that Linux should be able to run wherever another OS can) have to support whatever standards they may create. Regardless of whether we place support for it into Linux, we should certainly be spending time now attempting to understand ACPI, what it does and does not provide, and how it can be moved towards something that fulfils our needs and we can support long-term. We should certainly not be taking a back seat approach. Outside of the ARM Linux community there is work ongoing to change ACPI to better suit the level of variation we seem in the ARM space (see Darren Hart's presentation from ELCE [1]). We need to be involved now in order to make sure that this is actually generally applicable. > If we knew exactly what we wanted, it'd be a different story. _We > don't_. We're into year FOUR of the device tree conversion and we're just > now reaching a point where we think we know what a good solution looks > like. The first two years were easy -- they were the trivial devices we're > now talking about on ACPI. After that it got harder. Going through all > of that again with ACPI? No. No way. Microsoft gets to do it and while > they're busy sorting it out, we'll boot with device tree. Until ACPI is able to provide all the necessary information, and has suitable standard mechanisms for describing the horrible portions we are only just figuring out how to describe in DT, then ACPI is eitehr no better or worse than DT, and should not be used. However, we should be looking into it so that when portions of it eventually appear we have enough of an understanding to cull the obviously broken parts. I would also expect that _any_ ACPI support we would accept would not rely on any board-specific support code whatsoever -- either everything comes from ACPI or the platform doesn't boot. If we allow board files for a transitionary period to ACPI we'd be making the same mistake we did with DT. > Once they're done, we'll figure out how to enable new hardware. Sure, someone > needs to keep them sane and participate in the standardization process, but we > don't have to drag the whole kernel through it. To me, reworking the AML code and drivers to support AML + DT feels like dragging the whole kernel through it. I would rather see ACPI in full or no ACPI than a gigantic ARM-specific set of changes to general infrastructure that we'd expect to deprecate in future once we understand (the future state of) ACPI. > > There may even be things which we don't have to deal with at all on ACPI > > systems as used in servers (e.g. clock management), but perhaps we will > > if people see value in those elements. > > It's not about seeing value, it's about trying to shoehorn an existing > implementation into ACPI right now. People don't program with the ACPI > mindset since that's not what they're used to. So everybody needs to > re-learn everything all over again. > > The clock issues still have to be dealt with in ACPI _somewhere_, > and they likely have to be dealt with by the same software team at the > vendors that do Linux kernel work. So by forcing them to figure out how > to do it in ACPI, we're distracting from their efforts to support their > hardware better in the kernel in the first place. That's not win-win, > it's lose-lose. Or rather, it's lose for all of us, and win for Microsoft > since they are DoS:ing us. > > > > The server guys really want UEFI for their boot protocols, > > > installation managers, etc, etc. That's fine, let them do that, but > > > that doesn't mean we need to bring the same APIs all the way into the > > > kernel. > > > > > > So, I'm strongly urging that whatever the server guys try to do, it > > > will in the end result in the ACPI data being translated into DT > > > equivalents, such that the kernel _only_ needs to handle data via DT. > > > > I'm not sure that translating ACPI tables to dt makes any sense. If AML > > is used (even sparingly), I do not believe that we can do any sensible > > conversion to device tree. My understanding is that AML includes > > functionality for modifying ACPI tables, and I don't see how we can > > possibly support that without having to add a lot of boilerplate to all > > the code handling AML to add a device tree backend... > > We can definitely modify device tree contents at runtime, it's just that > nobody besides the POWER server guys are doing that today. So that's > not a strong argument in ACPI's favor. We should fix device-tree where > needed instead. As mentioned above, I think that the work to do this is going to end up as a weird ARM-specific legacy feature. We will get something wrong here in a way that we have to support long-term. I would rather support solely DT or solely ACPI at runtime (with a kernel supporting both), rather than a mixture of both forever due to an artifact of the development process. > Also, we can either have some of our better people sort out the ACPI-to-DT > translation and management, and get it done right, or we can rely on all the > vendors to get ACPI right in all their drivers. While some of them will, > I suspect we'll be more successful driving this from a common place. It > also gives us a place to stick all the fixups for broken firmware, > since the first generations of ARM servers are bound to have them. This common place is going to end up handling arbitrarily different idioms in each format (e.g. how GPIOs are represented), and is almost certainly going to become a sprawling mess. Also having "all the fixups" in there makes this sound like an every-single-board file, which is something I think everyone would like to avoid. > And best of all, it allows us to continue focus on device tree and > getting that done right, than splitting all efforts into two. We can't > affort that right now. > > > > Just like PowerPC scrapes the OpenFirmware client interface to build a > > > flat device tree, we should add a pre-boot stage that scrapes > > > ACPI/UEFI data and constructs an appropriate device-tree. We can still > > > bring over ACPI methods and represent those in the DT, but we should > > > _not_ have two native interfaces. > > > > I'm not sure the two cases are comparable. The format of the FDT was > > designed to encode the data structure used by OpenFirmware, and thus the > > two map to each other pretty well. I do not believe that mapping from > > ACPI tables to an FDT blob is anywhere near as simple, and as I mention > > above I do not believe that we can just copy over the ACPI methods in > > isolation. > > Sorry, I wasn't implying that there's a one-time trivial conversion > to be made in the generic case, but it can still be done in a similar > manner even though it will be more complex. Until I see code, I'm going to remain of the opinion that this is unworkable without embedding knowledge of every separate subsystem (GPIO, IRQ, etc) into a single place. That seems worse to me than teaching those subsystems to deal with the different information sources. > Nobody is expecting there to be zero work for new drivers with ACPI; > after all, the driver itself still has to be written. We're talking differences > from board to board and system to system here, which we can definitely handle > through a translator as well. > > And, as you say, if the first platforms are going to be trivial and easy to > implement with ACPI, then doing a translation for them will be simple too. This may be true. I worry that by working on this assumption we will lead people to do the wrong thing by focusing on short-term gain (i.e. placing board-specific hacks all other drivers and not handling the general case), rather than getting a long term solution together. > Shipping a firmware with ACPI is really no different from shipping a firmware > with a flashed device tree. Whatever bugs or strange things the vendor chooses > to do in there, we'll have to live with forever. > > We all know DT considerably better to a point where I would recommend > that they flash a DTB in their UEFI firmware instead of go with ACPI. For > simple hardware and basic devices we've got most bindings sorted out by > now, and we've decided on backwards compatibility from here on out. If a vendor does this, with a DTB that correctly describes their hardware then I am not against it (and would prefer this case to mapping from ACPI to DT). For that case we will also require a nailed-down boot protocol that allows for either DTB or ACPI (only one at a time). > > > It might be done via having a skeleton/framework DT for the vendor > > > platform that is updated via UEFI/ACPI data, or it might be > > > constructed entirely out of tables coming from firmware. I don't care > > > about the methods for how it is done, but I do feel strongly that we > > > should _not_ introduce a second API for everything. I can't think of a > > > single good reason to do it. > > > > Where does this skeleton/framework come from? Within the kernel? > > Since there might need to be runtime modifications done to the tree based on > ACPI events, it seems to make sense to do it in the kernel, so that translation > state and such can be kept around for use by the runtime modification parts. > > Having it extractable out of the kernel tree for testing purposes would be > greatly appreciated, so it can be ran through valgrind, add testcases, etc. This is still sounding awfully complicated. > > That > > sounds like an arcane board file equivalent, and is counter to the > > entire reason for using UEFI and ACPI -- having a well-defined > > (excluding particular driver bindings, and I'm not arguing well-defined > > means nice) stable standard that allows the kernel to boot on an > > arbitrary platform without requiring arbitrary platform-specific code > > everywhere in the boot path. > > > > It might not be pretty, and it will certainly require a lot of work, but > > I'd prefer it at least for a semblance of uniformity. > > That is a red herring -- that booting standard has _nothing_ to do with > ACPI. Once you've got a standard that is well-defined enough like that, > you no longer need the runtime portions of ACPI to deal with it. You > can just hardcode it. You need a way to probe _which_ type of standard > is used, but from there on out you can assume that things are the same > way. The UEFI spec pulls in portions of ACPI. I do not know the full extent of the interaction between the two, but I know that they are not completely decoupled. As you have pointed out we are not experienced with ACPI or UEFI, so I don't think we can make statements that one is perfectly fine without the other. > > I think that trying to shoe-horn ACPI-derived information into device > > tree is fundamentally the wrong approach. I don't think it encourages > > best practices, and I don't think it's beneficial to the long term > > health of Linux or the ecosystem as a whole. > > There are no known best practices with ACPI. It's a complete fumbling > around in the dark right now. We're complaining about reviewer bandwith > on DT -- do we have a single reviewer for ACPI on ARM that actually > knows what a good solution looks like? I don't think so. There are many people in the Linux community who have ACPI experience. They may not be active on the ARM side, but it's not fair to say there are no known best practices. I will agree that for the level of variation we're likely to expect we are pushing the boundaries. > So, until there's strong evidence that ACPI is actually going to be > a sane solution, in other words, until someone has shipped a system > that uses it (with Windows) and does it successfully without being > a hot mess, we shouldn't litter the kernel with it. Again, I'm not sure that we should rely on Windows as our saviour from insanity. A lot of the issues we are going to encounter are going to be in vendor-specific code (i.e. drivers), and I do not believe that is solved by having a single entity in charge of the general frameworks those are built upon. > Vendors can standardise of UEFI if they want, but I would much rather > see them bundle DTB images with their firmware today, than rely on early > buggy and still-early-on-the-learning-curve ACPI bindings that we then > have to live with forever. I agree that today a DTB is preferable to an ACPI implementation. I think that mapping from ACPI => DT is less sane than building support for ACPI, and is not going to help us in the long term. I think that we need to be involved in ACPI from today if we have any hope of having something sane in future. Thanks, Mark. [1] http://events.linuxfoundation.org/sites/events/files/slides/x86-platform.pdf -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org More majordomo info at http://vger.kernel.org/majordomo-info.html ^ permalink raw reply [flat|nested] 186+ messages in thread
* ACPI vs DT at runtime @ 2013-11-19 11:30 ` Mark Rutland 0 siblings, 0 replies; 186+ messages in thread From: Mark Rutland @ 2013-11-19 11:30 UTC (permalink / raw) To: linux-arm-kernel On Fri, Nov 15, 2013 at 05:52:41PM +0000, Olof Johansson wrote: > On Fri, Nov 15, 2013 at 09:57:17AM +0000, Mark Rutland wrote: > > On Fri, Nov 15, 2013 at 01:44:10AM +0000, Olof Johansson wrote: > > > The more I start to see early UEFI/ACPI code, the more I am certain > > > that we want none of that crap in the kernel. It's making things > > > considerably messier, while we're already very busy trying to convert > > > everything over and enable DT -- we'll be preempting that effort just > > > to add even more boilerplate everywhere and total progress will be > > > hurt. > > > > We are certainly under a lot of pressure with the device tree migration, > > and I agree that adding another information source is going to be a > > source of pain. However, I'd argue that we're going to encounter pain > > regardless of which approach we take. > > > > I'm of the opinion that the only way we should support ACPI is as a > > first-class citizen. We don't need to modify every driver and subsystem > > to support ACPI, only those necessary to support the minimal set of > > platforms using ACPI. ACPI is new in the arm space, and we can enforce > > quality standards on ACPI _now_ above what we're allowing for DT, and > > avoid future problems. > > It's obvious from the very first submission, from a vendor that has worked > closely with "the community" (i.e. one enterprise distro at least), that this > is completely new territory for _everyone_ involved. There's no way that we can > enforce quality standards for ACPI yet -- we don't know what they look like! > Nobody knows how to design a good ACPI implementation or binding. If we don't know what quality standards we require for ACPI, then I would rather see ACPI delayed until we are more comfortable with it than to enforce an arbitrary set of rules required to enable mapping it to device tree. > Oh wait, there's people who have been doing this for years. Microsoft. They > should be the ones driving this and taking the pain for it. Once the platform > is enabled for their needs, we'll sort it out at our end. After all, that has > worked reasonably well for x86 platforms. I'm not sure it's entirely reasonable to assume that Microsoft will swoop in and develop standards that are useful to us or even applicable to the vast majority of the systems that are likely to exist. If they do, then we will (by the expectation that Linux should be able to run wherever another OS can) have to support whatever standards they may create. Regardless of whether we place support for it into Linux, we should certainly be spending time now attempting to understand ACPI, what it does and does not provide, and how it can be moved towards something that fulfils our needs and we can support long-term. We should certainly not be taking a back seat approach. Outside of the ARM Linux community there is work ongoing to change ACPI to better suit the level of variation we seem in the ARM space (see Darren Hart's presentation from ELCE [1]). We need to be involved now in order to make sure that this is actually generally applicable. > If we knew exactly what we wanted, it'd be a different story. _We > don't_. We're into year FOUR of the device tree conversion and we're just > now reaching a point where we think we know what a good solution looks > like. The first two years were easy -- they were the trivial devices we're > now talking about on ACPI. After that it got harder. Going through all > of that again with ACPI? No. No way. Microsoft gets to do it and while > they're busy sorting it out, we'll boot with device tree. Until ACPI is able to provide all the necessary information, and has suitable standard mechanisms for describing the horrible portions we are only just figuring out how to describe in DT, then ACPI is eitehr no better or worse than DT, and should not be used. However, we should be looking into it so that when portions of it eventually appear we have enough of an understanding to cull the obviously broken parts. I would also expect that _any_ ACPI support we would accept would not rely on any board-specific support code whatsoever -- either everything comes from ACPI or the platform doesn't boot. If we allow board files for a transitionary period to ACPI we'd be making the same mistake we did with DT. > Once they're done, we'll figure out how to enable new hardware. Sure, someone > needs to keep them sane and participate in the standardization process, but we > don't have to drag the whole kernel through it. To me, reworking the AML code and drivers to support AML + DT feels like dragging the whole kernel through it. I would rather see ACPI in full or no ACPI than a gigantic ARM-specific set of changes to general infrastructure that we'd expect to deprecate in future once we understand (the future state of) ACPI. > > There may even be things which we don't have to deal with at all on ACPI > > systems as used in servers (e.g. clock management), but perhaps we will > > if people see value in those elements. > > It's not about seeing value, it's about trying to shoehorn an existing > implementation into ACPI right now. People don't program with the ACPI > mindset since that's not what they're used to. So everybody needs to > re-learn everything all over again. > > The clock issues still have to be dealt with in ACPI _somewhere_, > and they likely have to be dealt with by the same software team at the > vendors that do Linux kernel work. So by forcing them to figure out how > to do it in ACPI, we're distracting from their efforts to support their > hardware better in the kernel in the first place. That's not win-win, > it's lose-lose. Or rather, it's lose for all of us, and win for Microsoft > since they are DoS:ing us. > > > > The server guys really want UEFI for their boot protocols, > > > installation managers, etc, etc. That's fine, let them do that, but > > > that doesn't mean we need to bring the same APIs all the way into the > > > kernel. > > > > > > So, I'm strongly urging that whatever the server guys try to do, it > > > will in the end result in the ACPI data being translated into DT > > > equivalents, such that the kernel _only_ needs to handle data via DT. > > > > I'm not sure that translating ACPI tables to dt makes any sense. If AML > > is used (even sparingly), I do not believe that we can do any sensible > > conversion to device tree. My understanding is that AML includes > > functionality for modifying ACPI tables, and I don't see how we can > > possibly support that without having to add a lot of boilerplate to all > > the code handling AML to add a device tree backend... > > We can definitely modify device tree contents at runtime, it's just that > nobody besides the POWER server guys are doing that today. So that's > not a strong argument in ACPI's favor. We should fix device-tree where > needed instead. As mentioned above, I think that the work to do this is going to end up as a weird ARM-specific legacy feature. We will get something wrong here in a way that we have to support long-term. I would rather support solely DT or solely ACPI at runtime (with a kernel supporting both), rather than a mixture of both forever due to an artifact of the development process. > Also, we can either have some of our better people sort out the ACPI-to-DT > translation and management, and get it done right, or we can rely on all the > vendors to get ACPI right in all their drivers. While some of them will, > I suspect we'll be more successful driving this from a common place. It > also gives us a place to stick all the fixups for broken firmware, > since the first generations of ARM servers are bound to have them. This common place is going to end up handling arbitrarily different idioms in each format (e.g. how GPIOs are represented), and is almost certainly going to become a sprawling mess. Also having "all the fixups" in there makes this sound like an every-single-board file, which is something I think everyone would like to avoid. > And best of all, it allows us to continue focus on device tree and > getting that done right, than splitting all efforts into two. We can't > affort that right now. > > > > Just like PowerPC scrapes the OpenFirmware client interface to build a > > > flat device tree, we should add a pre-boot stage that scrapes > > > ACPI/UEFI data and constructs an appropriate device-tree. We can still > > > bring over ACPI methods and represent those in the DT, but we should > > > _not_ have two native interfaces. > > > > I'm not sure the two cases are comparable. The format of the FDT was > > designed to encode the data structure used by OpenFirmware, and thus the > > two map to each other pretty well. I do not believe that mapping from > > ACPI tables to an FDT blob is anywhere near as simple, and as I mention > > above I do not believe that we can just copy over the ACPI methods in > > isolation. > > Sorry, I wasn't implying that there's a one-time trivial conversion > to be made in the generic case, but it can still be done in a similar > manner even though it will be more complex. Until I see code, I'm going to remain of the opinion that this is unworkable without embedding knowledge of every separate subsystem (GPIO, IRQ, etc) into a single place. That seems worse to me than teaching those subsystems to deal with the different information sources. > Nobody is expecting there to be zero work for new drivers with ACPI; > after all, the driver itself still has to be written. We're talking differences > from board to board and system to system here, which we can definitely handle > through a translator as well. > > And, as you say, if the first platforms are going to be trivial and easy to > implement with ACPI, then doing a translation for them will be simple too. This may be true. I worry that by working on this assumption we will lead people to do the wrong thing by focusing on short-term gain (i.e. placing board-specific hacks all other drivers and not handling the general case), rather than getting a long term solution together. > Shipping a firmware with ACPI is really no different from shipping a firmware > with a flashed device tree. Whatever bugs or strange things the vendor chooses > to do in there, we'll have to live with forever. > > We all know DT considerably better to a point where I would recommend > that they flash a DTB in their UEFI firmware instead of go with ACPI. For > simple hardware and basic devices we've got most bindings sorted out by > now, and we've decided on backwards compatibility from here on out. If a vendor does this, with a DTB that correctly describes their hardware then I am not against it (and would prefer this case to mapping from ACPI to DT). For that case we will also require a nailed-down boot protocol that allows for either DTB or ACPI (only one at a time). > > > It might be done via having a skeleton/framework DT for the vendor > > > platform that is updated via UEFI/ACPI data, or it might be > > > constructed entirely out of tables coming from firmware. I don't care > > > about the methods for how it is done, but I do feel strongly that we > > > should _not_ introduce a second API for everything. I can't think of a > > > single good reason to do it. > > > > Where does this skeleton/framework come from? Within the kernel? > > Since there might need to be runtime modifications done to the tree based on > ACPI events, it seems to make sense to do it in the kernel, so that translation > state and such can be kept around for use by the runtime modification parts. > > Having it extractable out of the kernel tree for testing purposes would be > greatly appreciated, so it can be ran through valgrind, add testcases, etc. This is still sounding awfully complicated. > > That > > sounds like an arcane board file equivalent, and is counter to the > > entire reason for using UEFI and ACPI -- having a well-defined > > (excluding particular driver bindings, and I'm not arguing well-defined > > means nice) stable standard that allows the kernel to boot on an > > arbitrary platform without requiring arbitrary platform-specific code > > everywhere in the boot path. > > > > It might not be pretty, and it will certainly require a lot of work, but > > I'd prefer it at least for a semblance of uniformity. > > That is a red herring -- that booting standard has _nothing_ to do with > ACPI. Once you've got a standard that is well-defined enough like that, > you no longer need the runtime portions of ACPI to deal with it. You > can just hardcode it. You need a way to probe _which_ type of standard > is used, but from there on out you can assume that things are the same > way. The UEFI spec pulls in portions of ACPI. I do not know the full extent of the interaction between the two, but I know that they are not completely decoupled. As you have pointed out we are not experienced with ACPI or UEFI, so I don't think we can make statements that one is perfectly fine without the other. > > I think that trying to shoe-horn ACPI-derived information into device > > tree is fundamentally the wrong approach. I don't think it encourages > > best practices, and I don't think it's beneficial to the long term > > health of Linux or the ecosystem as a whole. > > There are no known best practices with ACPI. It's a complete fumbling > around in the dark right now. We're complaining about reviewer bandwith > on DT -- do we have a single reviewer for ACPI on ARM that actually > knows what a good solution looks like? I don't think so. There are many people in the Linux community who have ACPI experience. They may not be active on the ARM side, but it's not fair to say there are no known best practices. I will agree that for the level of variation we're likely to expect we are pushing the boundaries. > So, until there's strong evidence that ACPI is actually going to be > a sane solution, in other words, until someone has shipped a system > that uses it (with Windows) and does it successfully without being > a hot mess, we shouldn't litter the kernel with it. Again, I'm not sure that we should rely on Windows as our saviour from insanity. A lot of the issues we are going to encounter are going to be in vendor-specific code (i.e. drivers), and I do not believe that is solved by having a single entity in charge of the general frameworks those are built upon. > Vendors can standardise of UEFI if they want, but I would much rather > see them bundle DTB images with their firmware today, than rely on early > buggy and still-early-on-the-learning-curve ACPI bindings that we then > have to live with forever. I agree that today a DTB is preferable to an ACPI implementation. I think that mapping from ACPI => DT is less sane than building support for ACPI, and is not going to help us in the long term. I think that we need to be involved in ACPI from today if we have any hope of having something sane in future. Thanks, Mark. [1] http://events.linuxfoundation.org/sites/events/files/slides/x86-platform.pdf ^ permalink raw reply [flat|nested] 186+ messages in thread
* Re: ACPI vs DT at runtime 2013-11-19 11:30 ` Mark Rutland @ 2013-11-19 11:35 ` Mark Rutland -1 siblings, 0 replies; 186+ messages in thread From: Mark Rutland @ 2013-11-19 11:35 UTC (permalink / raw) To: Olof Johansson; +Cc: Grant Likely, devicetree, Arnd Bergmann, linux-arm-kernel Hi, > > > That > > > sounds like an arcane board file equivalent, and is counter to the > > > entire reason for using UEFI and ACPI -- having a well-defined > > > (excluding particular driver bindings, and I'm not arguing well-defined > > > means nice) stable standard that allows the kernel to boot on an > > > arbitrary platform without requiring arbitrary platform-specific code > > > everywhere in the boot path. > > > > > > It might not be pretty, and it will certainly require a lot of work, but > > > I'd prefer it at least for a semblance of uniformity. > > > > That is a red herring -- that booting standard has _nothing_ to do with > > ACPI. Once you've got a standard that is well-defined enough like that, > > you no longer need the runtime portions of ACPI to deal with it. You > > can just hardcode it. You need a way to probe _which_ type of standard > > is used, but from there on out you can assume that things are the same > > way. > > The UEFI spec pulls in portions of ACPI. I do not know the full extent > of the interaction between the two, but I know that they are not > completely decoupled. As you have pointed out we are not experienced > with ACPI or UEFI, so I don't think we can make statements that one is > perfectly fine without the other. Given Leif's comments it seems that they are decoupled sufficiently to be considered separately. Apologies for adding to the confusion here. Mark. ^ permalink raw reply [flat|nested] 186+ messages in thread
* ACPI vs DT at runtime @ 2013-11-19 11:35 ` Mark Rutland 0 siblings, 0 replies; 186+ messages in thread From: Mark Rutland @ 2013-11-19 11:35 UTC (permalink / raw) To: linux-arm-kernel Hi, > > > That > > > sounds like an arcane board file equivalent, and is counter to the > > > entire reason for using UEFI and ACPI -- having a well-defined > > > (excluding particular driver bindings, and I'm not arguing well-defined > > > means nice) stable standard that allows the kernel to boot on an > > > arbitrary platform without requiring arbitrary platform-specific code > > > everywhere in the boot path. > > > > > > It might not be pretty, and it will certainly require a lot of work, but > > > I'd prefer it at least for a semblance of uniformity. > > > > That is a red herring -- that booting standard has _nothing_ to do with > > ACPI. Once you've got a standard that is well-defined enough like that, > > you no longer need the runtime portions of ACPI to deal with it. You > > can just hardcode it. You need a way to probe _which_ type of standard > > is used, but from there on out you can assume that things are the same > > way. > > The UEFI spec pulls in portions of ACPI. I do not know the full extent > of the interaction between the two, but I know that they are not > completely decoupled. As you have pointed out we are not experienced > with ACPI or UEFI, so I don't think we can make statements that one is > perfectly fine without the other. Given Leif's comments it seems that they are decoupled sufficiently to be considered separately. Apologies for adding to the confusion here. Mark. ^ permalink raw reply [flat|nested] 186+ messages in thread
[parent not found: <20131119113557.GI5914-NuALmloUBlrZROr8t4l/smS4ubULX0JqMm0uRHvK7Nw@public.gmane.org>]
* Re: ACPI vs DT at runtime 2013-11-19 11:35 ` Mark Rutland @ 2013-11-19 11:51 ` Leif Lindholm -1 siblings, 0 replies; 186+ messages in thread From: Leif Lindholm @ 2013-11-19 11:51 UTC (permalink / raw) To: Mark Rutland Cc: Olof Johansson, Grant Likely, devicetree-u79uwXL29TY76Z2rM5mHXA, Arnd Bergmann, linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r On Tue, Nov 19, 2013 at 11:35:57AM +0000, Mark Rutland wrote: > > The UEFI spec pulls in portions of ACPI. I do not know the full extent > > of the interaction between the two, but I know that they are not > > completely decoupled. As you have pointed out we are not experienced > > with ACPI or UEFI, so I don't think we can make statements that one is > > perfectly fine without the other. > > Given Leif's comments it seems that they are decoupled sufficiently to > be considered separately. Well, UEFI should be considered separately from ACPI. I am not convinced it makes sense to consider ACPI for any case that does not also include UEFI. / Leif -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org More majordomo info at http://vger.kernel.org/majordomo-info.html ^ permalink raw reply [flat|nested] 186+ messages in thread
* ACPI vs DT at runtime @ 2013-11-19 11:51 ` Leif Lindholm 0 siblings, 0 replies; 186+ messages in thread From: Leif Lindholm @ 2013-11-19 11:51 UTC (permalink / raw) To: linux-arm-kernel On Tue, Nov 19, 2013 at 11:35:57AM +0000, Mark Rutland wrote: > > The UEFI spec pulls in portions of ACPI. I do not know the full extent > > of the interaction between the two, but I know that they are not > > completely decoupled. As you have pointed out we are not experienced > > with ACPI or UEFI, so I don't think we can make statements that one is > > perfectly fine without the other. > > Given Leif's comments it seems that they are decoupled sufficiently to > be considered separately. Well, UEFI should be considered separately from ACPI. I am not convinced it makes sense to consider ACPI for any case that does not also include UEFI. / Leif ^ permalink raw reply [flat|nested] 186+ messages in thread
[parent not found: <20131119113015.GH5914-NuALmloUBlrZROr8t4l/smS4ubULX0JqMm0uRHvK7Nw@public.gmane.org>]
* Re: ACPI vs DT at runtime 2013-11-19 11:30 ` Mark Rutland @ 2013-11-19 11:57 ` Russell King - ARM Linux -1 siblings, 0 replies; 186+ messages in thread From: Russell King - ARM Linux @ 2013-11-19 11:57 UTC (permalink / raw) To: Mark Rutland Cc: Olof Johansson, Grant Likely, devicetree-u79uwXL29TY76Z2rM5mHXA, Arnd Bergmann, linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r On Tue, Nov 19, 2013 at 11:30:15AM +0000, Mark Rutland wrote: > I'm not sure it's entirely reasonable to assume that Microsoft will > swoop in and develop standards that are useful to us or even applicable > to the vast majority of the systems that are likely to exist. It's not in their interest to do this, so it won't happen. > Outside of the ARM Linux community there is work ongoing to change ACPI > to better suit the level of variation we seem in the ARM space (see > Darren Hart's presentation from ELCE [1]). We need to be involved now in > order to make sure that this is actually generally applicable. It may have been interesting to have attended some of these talks, but because the LF botched up and never told the KSummit invitees that they had free access to ELCE until after ELCE had finished... > I think that we need to be involved in ACPI from today if we have any > hope of having something sane in future. I fully agree with that. If we're not involved now, we're going to end up with something that's already designed and implemented on systems which we'll then _have_ no option but to accept or just not be able to run mainline kernels on such systems. To ignore ACPI now would be extremely näieve. -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org More majordomo info at http://vger.kernel.org/majordomo-info.html ^ permalink raw reply [flat|nested] 186+ messages in thread
* ACPI vs DT at runtime @ 2013-11-19 11:57 ` Russell King - ARM Linux 0 siblings, 0 replies; 186+ messages in thread From: Russell King - ARM Linux @ 2013-11-19 11:57 UTC (permalink / raw) To: linux-arm-kernel On Tue, Nov 19, 2013 at 11:30:15AM +0000, Mark Rutland wrote: > I'm not sure it's entirely reasonable to assume that Microsoft will > swoop in and develop standards that are useful to us or even applicable > to the vast majority of the systems that are likely to exist. It's not in their interest to do this, so it won't happen. > Outside of the ARM Linux community there is work ongoing to change ACPI > to better suit the level of variation we seem in the ARM space (see > Darren Hart's presentation from ELCE [1]). We need to be involved now in > order to make sure that this is actually generally applicable. It may have been interesting to have attended some of these talks, but because the LF botched up and never told the KSummit invitees that they had free access to ELCE until after ELCE had finished... > I think that we need to be involved in ACPI from today if we have any > hope of having something sane in future. I fully agree with that. If we're not involved now, we're going to end up with something that's already designed and implemented on systems which we'll then _have_ no option but to accept or just not be able to run mainline kernels on such systems. To ignore ACPI now would be extremely n?ieve. ^ permalink raw reply [flat|nested] 186+ messages in thread
* Re: ACPI vs DT at runtime 2013-11-19 11:30 ` Mark Rutland @ 2013-11-19 13:56 ` Stefano Stabellini -1 siblings, 0 replies; 186+ messages in thread From: Stefano Stabellini @ 2013-11-19 13:56 UTC (permalink / raw) To: Mark Rutland Cc: Olof Johansson, Grant Likely, devicetree-u79uwXL29TY76Z2rM5mHXA, Arnd Bergmann, linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r On Tue, 19 Nov 2013, Mark Rutland wrote: > > We all know DT considerably better to a point where I would recommend > > that they flash a DTB in their UEFI firmware instead of go with ACPI. For > > simple hardware and basic devices we've got most bindings sorted out by > > now, and we've decided on backwards compatibility from here on out. > > If a vendor does this, with a DTB that correctly describes their > hardware then I am not against it (and would prefer this case to mapping > from ACPI to DT). I think that the firmware passing a DTB to the bootloader/kernel is the best option we have. > For that case we will also require a nailed-down boot > protocol that allows for either DTB or ACPI. The latest documentation patch for the "arm/arm64 UEFI boot protocol" implies that UEFI on ARM is already capable of passing a DTB to the kernel: "The implementation depends on receiving information about the UEFI environment in a Flattened Device Tree (FDT) - so is only available with CONFIG_OF." Maybe we just need to better document it? > (only one at a time) I would not go as far as requiring that only one is available. Certainly I would mandate that either of them are independently complete and sufficient to describe the platform. -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org More majordomo info at http://vger.kernel.org/majordomo-info.html ^ permalink raw reply [flat|nested] 186+ messages in thread
* ACPI vs DT at runtime @ 2013-11-19 13:56 ` Stefano Stabellini 0 siblings, 0 replies; 186+ messages in thread From: Stefano Stabellini @ 2013-11-19 13:56 UTC (permalink / raw) To: linux-arm-kernel On Tue, 19 Nov 2013, Mark Rutland wrote: > > We all know DT considerably better to a point where I would recommend > > that they flash a DTB in their UEFI firmware instead of go with ACPI. For > > simple hardware and basic devices we've got most bindings sorted out by > > now, and we've decided on backwards compatibility from here on out. > > If a vendor does this, with a DTB that correctly describes their > hardware then I am not against it (and would prefer this case to mapping > from ACPI to DT). I think that the firmware passing a DTB to the bootloader/kernel is the best option we have. > For that case we will also require a nailed-down boot > protocol that allows for either DTB or ACPI. The latest documentation patch for the "arm/arm64 UEFI boot protocol" implies that UEFI on ARM is already capable of passing a DTB to the kernel: "The implementation depends on receiving information about the UEFI environment in a Flattened Device Tree (FDT) - so is only available with CONFIG_OF." Maybe we just need to better document it? > (only one at a time) I would not go as far as requiring that only one is available. Certainly I would mandate that either of them are independently complete and sufficient to describe the platform. ^ permalink raw reply [flat|nested] 186+ messages in thread
* Re: ACPI vs DT at runtime 2013-11-19 13:56 ` Stefano Stabellini @ 2013-11-19 14:38 ` Mark Rutland -1 siblings, 0 replies; 186+ messages in thread From: Mark Rutland @ 2013-11-19 14:38 UTC (permalink / raw) To: Stefano Stabellini Cc: Olof Johansson, Grant Likely, linux-arm-kernel, Arnd Bergmann, devicetree On Tue, Nov 19, 2013 at 01:56:26PM +0000, Stefano Stabellini wrote: > On Tue, 19 Nov 2013, Mark Rutland wrote: > > > We all know DT considerably better to a point where I would recommend > > > that they flash a DTB in their UEFI firmware instead of go with ACPI. For > > > simple hardware and basic devices we've got most bindings sorted out by > > > now, and we've decided on backwards compatibility from here on out. > > > > If a vendor does this, with a DTB that correctly describes their > > hardware then I am not against it (and would prefer this case to mapping > > from ACPI to DT). > > I think that the firmware passing a DTB to the bootloader/kernel is the > best option we have. > > > > For that case we will also require a nailed-down boot > > protocol that allows for either DTB or ACPI. > > The latest documentation patch for the "arm/arm64 UEFI boot protocol" > implies that UEFI on ARM is already capable of passing a DTB to the > kernel: > > "The implementation depends on receiving information about the UEFI > environment in a Flattened Device Tree (FDT) - so is only available with > CONFIG_OF." > > Maybe we just need to better document it? Yes, we just need to document it. As far as I'm aware, there are two ways we might boot the kernel: 1) Via the current boot protocol, passing a DTB in a particular register. 2) As an EFI application. As I understand it in this case the DTB will be saved in a system table (I may have got the terminology wrong here), and the EFI stub will need to look it up to pass it to the kernel. As long as that's well defined and does not preclude ACPI, then I am happy. > > > > (only one at a time) > > I would not go as far as requiring that only one is available. > Certainly I would mandate that either of them are independently complete > and sufficient to describe the platform. At that point we need to choose one to prefer. This will be a completely arbitrary choice, but as in the EFI case we would expect a DTB stub (for passing some options in /chosen), preferring the DT if it's more than a stub would make sense to me. The key point is that the kernel will rely solely on one of them to provide hardware description. Thanks, Mark. ^ permalink raw reply [flat|nested] 186+ messages in thread
* ACPI vs DT at runtime @ 2013-11-19 14:38 ` Mark Rutland 0 siblings, 0 replies; 186+ messages in thread From: Mark Rutland @ 2013-11-19 14:38 UTC (permalink / raw) To: linux-arm-kernel On Tue, Nov 19, 2013 at 01:56:26PM +0000, Stefano Stabellini wrote: > On Tue, 19 Nov 2013, Mark Rutland wrote: > > > We all know DT considerably better to a point where I would recommend > > > that they flash a DTB in their UEFI firmware instead of go with ACPI. For > > > simple hardware and basic devices we've got most bindings sorted out by > > > now, and we've decided on backwards compatibility from here on out. > > > > If a vendor does this, with a DTB that correctly describes their > > hardware then I am not against it (and would prefer this case to mapping > > from ACPI to DT). > > I think that the firmware passing a DTB to the bootloader/kernel is the > best option we have. > > > > For that case we will also require a nailed-down boot > > protocol that allows for either DTB or ACPI. > > The latest documentation patch for the "arm/arm64 UEFI boot protocol" > implies that UEFI on ARM is already capable of passing a DTB to the > kernel: > > "The implementation depends on receiving information about the UEFI > environment in a Flattened Device Tree (FDT) - so is only available with > CONFIG_OF." > > Maybe we just need to better document it? Yes, we just need to document it. As far as I'm aware, there are two ways we might boot the kernel: 1) Via the current boot protocol, passing a DTB in a particular register. 2) As an EFI application. As I understand it in this case the DTB will be saved in a system table (I may have got the terminology wrong here), and the EFI stub will need to look it up to pass it to the kernel. As long as that's well defined and does not preclude ACPI, then I am happy. > > > > (only one at a time) > > I would not go as far as requiring that only one is available. > Certainly I would mandate that either of them are independently complete > and sufficient to describe the platform. At that point we need to choose one to prefer. This will be a completely arbitrary choice, but as in the EFI case we would expect a DTB stub (for passing some options in /chosen), preferring the DT if it's more than a stub would make sense to me. The key point is that the kernel will rely solely on one of them to provide hardware description. Thanks, Mark. ^ permalink raw reply [flat|nested] 186+ messages in thread
[parent not found: <20131119143840.GN5914-NuALmloUBlrZROr8t4l/smS4ubULX0JqMm0uRHvK7Nw@public.gmane.org>]
* Re: ACPI vs DT at runtime 2013-11-19 14:38 ` Mark Rutland @ 2013-11-19 14:59 ` Leif Lindholm -1 siblings, 0 replies; 186+ messages in thread From: Leif Lindholm @ 2013-11-19 14:59 UTC (permalink / raw) To: Mark Rutland Cc: Stefano Stabellini, Olof Johansson, Grant Likely, linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r, Arnd Bergmann, devicetree-u79uwXL29TY76Z2rM5mHXA On Tue, Nov 19, 2013 at 02:38:40PM +0000, Mark Rutland wrote: > > > For that case we will also require a nailed-down boot > > > protocol that allows for either DTB or ACPI. > > > > The latest documentation patch for the "arm/arm64 UEFI boot protocol" > > implies that UEFI on ARM is already capable of passing a DTB to the > > kernel: > > > > "The implementation depends on receiving information about the UEFI > > environment in a Flattened Device Tree (FDT) - so is only available with > > CONFIG_OF." > > > > Maybe we just need to better document it? > > Yes, we just need to document it. Better document it than what is currently in Booting? > As far as I'm aware, there are two ways we might boot the kernel: Nope, just one. > 1) Via the current boot protocol, passing a DTB in a particular > register. This is the only bit relevant to the kernel proper. It does not change with UEFI/ACPI. > 2) As an EFI application. As I understand it in this case the DTB will > be saved in a system table (I may have got the terminology wrong here), > and the EFI stub will need to look it up to pass it to the kernel. This applies only to the stub itself, and relates to dealing with a firmware that provides a preloaded tree. As well as an obscurity relating to _stub_ command line passing. It has also not been included in the patch sets sent out so far. > As long as that's well defined and does not preclude ACPI, then I am > happy. This is already well defined. I'll agree it may not be explicit enough. If we do need any documentation changes, I feel they belong in Booting, to explain that a minimal DT will be used even with ACPI in order _not_ to break the existing boot protocol. / Leif -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org More majordomo info at http://vger.kernel.org/majordomo-info.html ^ permalink raw reply [flat|nested] 186+ messages in thread
* ACPI vs DT at runtime @ 2013-11-19 14:59 ` Leif Lindholm 0 siblings, 0 replies; 186+ messages in thread From: Leif Lindholm @ 2013-11-19 14:59 UTC (permalink / raw) To: linux-arm-kernel On Tue, Nov 19, 2013 at 02:38:40PM +0000, Mark Rutland wrote: > > > For that case we will also require a nailed-down boot > > > protocol that allows for either DTB or ACPI. > > > > The latest documentation patch for the "arm/arm64 UEFI boot protocol" > > implies that UEFI on ARM is already capable of passing a DTB to the > > kernel: > > > > "The implementation depends on receiving information about the UEFI > > environment in a Flattened Device Tree (FDT) - so is only available with > > CONFIG_OF." > > > > Maybe we just need to better document it? > > Yes, we just need to document it. Better document it than what is currently in Booting? > As far as I'm aware, there are two ways we might boot the kernel: Nope, just one. > 1) Via the current boot protocol, passing a DTB in a particular > register. This is the only bit relevant to the kernel proper. It does not change with UEFI/ACPI. > 2) As an EFI application. As I understand it in this case the DTB will > be saved in a system table (I may have got the terminology wrong here), > and the EFI stub will need to look it up to pass it to the kernel. This applies only to the stub itself, and relates to dealing with a firmware that provides a preloaded tree. As well as an obscurity relating to _stub_ command line passing. It has also not been included in the patch sets sent out so far. > As long as that's well defined and does not preclude ACPI, then I am > happy. This is already well defined. I'll agree it may not be explicit enough. If we do need any documentation changes, I feel they belong in Booting, to explain that a minimal DT will be used even with ACPI in order _not_ to break the existing boot protocol. / Leif ^ permalink raw reply [flat|nested] 186+ messages in thread
* Re: ACPI vs DT at runtime 2013-11-19 14:38 ` Mark Rutland @ 2013-11-19 18:23 ` Olof Johansson -1 siblings, 0 replies; 186+ messages in thread From: Olof Johansson @ 2013-11-19 18:23 UTC (permalink / raw) To: Mark Rutland Cc: Stefano Stabellini, Grant Likely, devicetree-u79uwXL29TY76Z2rM5mHXA, Arnd Bergmann, linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r On Tue, Nov 19, 2013 at 02:38:40PM +0000, Mark Rutland wrote: > On Tue, Nov 19, 2013 at 01:56:26PM +0000, Stefano Stabellini wrote: > > I would not go as far as requiring that only one is available. > > Certainly I would mandate that either of them are independently complete > > and sufficient to describe the platform. > > At that point we need to choose one to prefer. This will be a completely > arbitrary choice, but as in the EFI case we would expect a DTB stub (for > passing some options in /chosen), preferring the DT if it's more than a > stub would make sense to me. > > The key point is that the kernel will rely solely on one of them to > provide hardware description. Given that the likley path is to have a static DT override a broken ACPI table on a system, giving preference to DT seems like the logical choice at this time. There's also presendence from x86 to allow bootargs such as "noacpi" to disable one or the other, but hopefully we can avoid that as long as possible. -Olof -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org More majordomo info at http://vger.kernel.org/majordomo-info.html ^ permalink raw reply [flat|nested] 186+ messages in thread
* ACPI vs DT at runtime @ 2013-11-19 18:23 ` Olof Johansson 0 siblings, 0 replies; 186+ messages in thread From: Olof Johansson @ 2013-11-19 18:23 UTC (permalink / raw) To: linux-arm-kernel On Tue, Nov 19, 2013 at 02:38:40PM +0000, Mark Rutland wrote: > On Tue, Nov 19, 2013 at 01:56:26PM +0000, Stefano Stabellini wrote: > > I would not go as far as requiring that only one is available. > > Certainly I would mandate that either of them are independently complete > > and sufficient to describe the platform. > > At that point we need to choose one to prefer. This will be a completely > arbitrary choice, but as in the EFI case we would expect a DTB stub (for > passing some options in /chosen), preferring the DT if it's more than a > stub would make sense to me. > > The key point is that the kernel will rely solely on one of them to > provide hardware description. Given that the likley path is to have a static DT override a broken ACPI table on a system, giving preference to DT seems like the logical choice at this time. There's also presendence from x86 to allow bootargs such as "noacpi" to disable one or the other, but hopefully we can avoid that as long as possible. -Olof ^ permalink raw reply [flat|nested] 186+ messages in thread
* Re: ACPI vs DT at runtime 2013-11-19 11:30 ` Mark Rutland @ 2013-11-19 14:05 ` Arnd Bergmann -1 siblings, 0 replies; 186+ messages in thread From: Arnd Bergmann @ 2013-11-19 14:05 UTC (permalink / raw) To: Mark Rutland Cc: Olof Johansson, devicetree-u79uwXL29TY76Z2rM5mHXA, linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r, Grant Likely, Rob Herring On Tuesday 19 November 2013, Mark Rutland wrote: > On Fri, Nov 15, 2013 at 05:52:41PM +0000, Olof Johansson wrote: > > On Fri, Nov 15, 2013 at 09:57:17AM +0000, Mark Rutland wrote: > > Oh wait, there's people who have been doing this for years. Microsoft. They > > should be the ones driving this and taking the pain for it. Once the platform > > is enabled for their needs, we'll sort it out at our end. After all, that has > > worked reasonably well for x86 platforms. > > I'm not sure it's entirely reasonable to assume that Microsoft will > swoop in and develop standards that are useful to us or even applicable > to the vast majority of the systems that are likely to exist. If they > do, then we will (by the expectation that Linux should be able to run > wherever another OS can) have to support whatever standards they may > create. That company is undergoing a lot of change now, I think anything is possible: They might decide that ARM is a really bad idea (after the Windows-RT fiasco), they could start working together with us on these problems, or they could do everything in their hands to make our lives as hard as they can (as before, see http://www.groklaw.net/articlebasic.php?story=2010011422570951). > Regardless of whether we place support for it into Linux, we should > certainly be spending time now attempting to understand ACPI, what it > does and does not provide, and how it can be moved towards something > that fulfils our needs and we can support long-term. We should certainly > not be taking a back seat approach. > > Outside of the ARM Linux community there is work ongoing to change ACPI > to better suit the level of variation we seem in the ARM space (see > Darren Hart's presentation from ELCE [1]). We need to be involved now in > order to make sure that this is actually generally applicable. Agreed. I'm not sure who "we" is in this, but I assume you mean the wider ARM Linux developer community. Linaro already has full-time developers working on this, with ties into the UEFI and ACPI standard bodies, and that is good. Still it does not mean we should prematurely merge any of the code coming out of it, until there are products out there with ACPI firmware that is not completely messed up and that is worth supporting in mainline, considering the maintainance effort. > I would also expect that _any_ ACPI support we would accept would not > rely on any board-specific support code whatsoever -- either everything > comes from ACPI or the platform doesn't boot. If we allow board files > for a transitionary period to ACPI we'd be making the same mistake we > did with DT. I would go further and reject any code that adds an SoC or BIOS vendor specific glue layer. The bar we have set with the current ARM64 code and for new ARM32 is that everything is in device drivers of some sort. I would hate to reintroduce platform directories just because every company has a different understanding of how to describe the same things in ACPI, or because ACPI-5.0 is insufficient to describe the SoC and go back to static platform devices. > > Once they're done, we'll figure out how to enable new hardware. Sure, someone > > needs to keep them sane and participate in the standardization process, but we > > don't have to drag the whole kernel through it. > > To me, reworking the AML code and drivers to support AML + DT feels like > dragging the whole kernel through it. I would rather see ACPI in full or > no ACPI than a gigantic ARM-specific set of changes to general > infrastructure that we'd expect to deprecate in future once we > understand (the future state of) ACPI. I'm skeptical about getting AML working on DT nodes, just as I doubt that AML is sufficient to do what people want when faced with a complex SoC. Also, if AML ends up being mainly used as a trampoline to get into EL2/EL3 firmware, I'd much rather standardize the actual firmware interfaces underneath. > As mentioned above, I think that the work to do this is going to end up > as a weird ARM-specific legacy feature. We will get something wrong here > in a way that we have to support long-term. I would rather support > solely DT or solely ACPI at runtime (with a kernel supporting both), > rather than a mixture of both forever due to an artifact of the > development process. I think that depends on how whether you expect ACPI to succeed in the market or not. If it ends up being a historic sidenote, that's what the code should be. A precedent for this would be mach-shark, which we just removed. It was one of the original StrongARM machines and actually came with Open Firmware and a DT that was (rightfully so) converted to ATAGS format on boot. > > Also, we can either have some of our better people sort out the ACPI-to-DT > > translation and management, and get it done right, or we can rely on all the > > vendors to get ACPI right in all their drivers. While some of them will, > > I suspect we'll be more successful driving this from a common place. It > > also gives us a place to stick all the fixups for broken firmware, > > since the first generations of ARM servers are bound to have them. > > This common place is going to end up handling arbitrarily different > idioms in each format (e.g. how GPIOs are represented), and is almost > certainly going to become a sprawling mess. Also having "all the fixups" > in there makes this sound like an every-single-board file, which is > something I think everyone would like to avoid. I guess if it grows too big, it could be moved into a separate boot loader project and out of the kernel, as we do for the ATAGS-to-DT conversion with the impedence-matcher. > > > I'm not sure the two cases are comparable. The format of the FDT was > > > designed to encode the data structure used by OpenFirmware, and thus the > > > two map to each other pretty well. I do not believe that mapping from > > > ACPI tables to an FDT blob is anywhere near as simple, and as I mention > > > above I do not believe that we can just copy over the ACPI methods in > > > isolation. > > > > Sorry, I wasn't implying that there's a one-time trivial conversion > > to be made in the generic case, but it can still be done in a similar > > manner even though it will be more complex. > > Until I see code, I'm going to remain of the opinion that this is > unworkable without embedding knowledge of every separate subsystem > (GPIO, IRQ, etc) into a single place. That seems worse to me than > teaching those subsystems to deal with the different information > sources. Agreed. > > Vendors can standardise of UEFI if they want, but I would much rather > > see them bundle DTB images with their firmware today, than rely on early > > buggy and still-early-on-the-learning-curve ACPI bindings that we then > > have to live with forever. > > I agree that today a DTB is preferable to an ACPI implementation. > > I think that mapping from ACPI => DT is less sane than building support > for ACPI, and is not going to help us in the long term. > > I think that we need to be involved in ACPI from today if we have any > hope of having something sane in future. I mostly agree, but I think that the decision whether to ignore, translate or implement support for ACPI BIOS implementations depends a lot on what kinds of systems we are going to see and the level of sophistication they put into their firmware. If we are basically talking about PCs with their x86 CPU removed and an ARM chip put in there, I think an ACPI implementation would be harmless enough. However if we are talking about complex SoCs that just have the same information in ACPI that we have in DT in a different format, we really need to tell the responsible developers that ACPI support for these just won't get merged. Arnd -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org More majordomo info at http://vger.kernel.org/majordomo-info.html ^ permalink raw reply [flat|nested] 186+ messages in thread
* ACPI vs DT at runtime @ 2013-11-19 14:05 ` Arnd Bergmann 0 siblings, 0 replies; 186+ messages in thread From: Arnd Bergmann @ 2013-11-19 14:05 UTC (permalink / raw) To: linux-arm-kernel On Tuesday 19 November 2013, Mark Rutland wrote: > On Fri, Nov 15, 2013 at 05:52:41PM +0000, Olof Johansson wrote: > > On Fri, Nov 15, 2013 at 09:57:17AM +0000, Mark Rutland wrote: > > Oh wait, there's people who have been doing this for years. Microsoft. They > > should be the ones driving this and taking the pain for it. Once the platform > > is enabled for their needs, we'll sort it out at our end. After all, that has > > worked reasonably well for x86 platforms. > > I'm not sure it's entirely reasonable to assume that Microsoft will > swoop in and develop standards that are useful to us or even applicable > to the vast majority of the systems that are likely to exist. If they > do, then we will (by the expectation that Linux should be able to run > wherever another OS can) have to support whatever standards they may > create. That company is undergoing a lot of change now, I think anything is possible: They might decide that ARM is a really bad idea (after the Windows-RT fiasco), they could start working together with us on these problems, or they could do everything in their hands to make our lives as hard as they can (as before, see http://www.groklaw.net/articlebasic.php?story=2010011422570951). > Regardless of whether we place support for it into Linux, we should > certainly be spending time now attempting to understand ACPI, what it > does and does not provide, and how it can be moved towards something > that fulfils our needs and we can support long-term. We should certainly > not be taking a back seat approach. > > Outside of the ARM Linux community there is work ongoing to change ACPI > to better suit the level of variation we seem in the ARM space (see > Darren Hart's presentation from ELCE [1]). We need to be involved now in > order to make sure that this is actually generally applicable. Agreed. I'm not sure who "we" is in this, but I assume you mean the wider ARM Linux developer community. Linaro already has full-time developers working on this, with ties into the UEFI and ACPI standard bodies, and that is good. Still it does not mean we should prematurely merge any of the code coming out of it, until there are products out there with ACPI firmware that is not completely messed up and that is worth supporting in mainline, considering the maintainance effort. > I would also expect that _any_ ACPI support we would accept would not > rely on any board-specific support code whatsoever -- either everything > comes from ACPI or the platform doesn't boot. If we allow board files > for a transitionary period to ACPI we'd be making the same mistake we > did with DT. I would go further and reject any code that adds an SoC or BIOS vendor specific glue layer. The bar we have set with the current ARM64 code and for new ARM32 is that everything is in device drivers of some sort. I would hate to reintroduce platform directories just because every company has a different understanding of how to describe the same things in ACPI, or because ACPI-5.0 is insufficient to describe the SoC and go back to static platform devices. > > Once they're done, we'll figure out how to enable new hardware. Sure, someone > > needs to keep them sane and participate in the standardization process, but we > > don't have to drag the whole kernel through it. > > To me, reworking the AML code and drivers to support AML + DT feels like > dragging the whole kernel through it. I would rather see ACPI in full or > no ACPI than a gigantic ARM-specific set of changes to general > infrastructure that we'd expect to deprecate in future once we > understand (the future state of) ACPI. I'm skeptical about getting AML working on DT nodes, just as I doubt that AML is sufficient to do what people want when faced with a complex SoC. Also, if AML ends up being mainly used as a trampoline to get into EL2/EL3 firmware, I'd much rather standardize the actual firmware interfaces underneath. > As mentioned above, I think that the work to do this is going to end up > as a weird ARM-specific legacy feature. We will get something wrong here > in a way that we have to support long-term. I would rather support > solely DT or solely ACPI at runtime (with a kernel supporting both), > rather than a mixture of both forever due to an artifact of the > development process. I think that depends on how whether you expect ACPI to succeed in the market or not. If it ends up being a historic sidenote, that's what the code should be. A precedent for this would be mach-shark, which we just removed. It was one of the original StrongARM machines and actually came with Open Firmware and a DT that was (rightfully so) converted to ATAGS format on boot. > > Also, we can either have some of our better people sort out the ACPI-to-DT > > translation and management, and get it done right, or we can rely on all the > > vendors to get ACPI right in all their drivers. While some of them will, > > I suspect we'll be more successful driving this from a common place. It > > also gives us a place to stick all the fixups for broken firmware, > > since the first generations of ARM servers are bound to have them. > > This common place is going to end up handling arbitrarily different > idioms in each format (e.g. how GPIOs are represented), and is almost > certainly going to become a sprawling mess. Also having "all the fixups" > in there makes this sound like an every-single-board file, which is > something I think everyone would like to avoid. I guess if it grows too big, it could be moved into a separate boot loader project and out of the kernel, as we do for the ATAGS-to-DT conversion with the impedence-matcher. > > > I'm not sure the two cases are comparable. The format of the FDT was > > > designed to encode the data structure used by OpenFirmware, and thus the > > > two map to each other pretty well. I do not believe that mapping from > > > ACPI tables to an FDT blob is anywhere near as simple, and as I mention > > > above I do not believe that we can just copy over the ACPI methods in > > > isolation. > > > > Sorry, I wasn't implying that there's a one-time trivial conversion > > to be made in the generic case, but it can still be done in a similar > > manner even though it will be more complex. > > Until I see code, I'm going to remain of the opinion that this is > unworkable without embedding knowledge of every separate subsystem > (GPIO, IRQ, etc) into a single place. That seems worse to me than > teaching those subsystems to deal with the different information > sources. Agreed. > > Vendors can standardise of UEFI if they want, but I would much rather > > see them bundle DTB images with their firmware today, than rely on early > > buggy and still-early-on-the-learning-curve ACPI bindings that we then > > have to live with forever. > > I agree that today a DTB is preferable to an ACPI implementation. > > I think that mapping from ACPI => DT is less sane than building support > for ACPI, and is not going to help us in the long term. > > I think that we need to be involved in ACPI from today if we have any > hope of having something sane in future. I mostly agree, but I think that the decision whether to ignore, translate or implement support for ACPI BIOS implementations depends a lot on what kinds of systems we are going to see and the level of sophistication they put into their firmware. If we are basically talking about PCs with their x86 CPU removed and an ARM chip put in there, I think an ACPI implementation would be harmless enough. However if we are talking about complex SoCs that just have the same information in ACPI that we have in DT in a different format, we really need to tell the responsible developers that ACPI support for these just won't get merged. Arnd ^ permalink raw reply [flat|nested] 186+ messages in thread
* Re: ACPI vs DT at runtime 2013-11-19 14:05 ` Arnd Bergmann @ 2013-11-19 15:21 ` Mark Rutland -1 siblings, 0 replies; 186+ messages in thread From: Mark Rutland @ 2013-11-19 15:21 UTC (permalink / raw) To: Arnd Bergmann; +Cc: Olof Johansson, devicetree, Grant Likely, linux-arm-kernel On Tue, Nov 19, 2013 at 02:05:33PM +0000, Arnd Bergmann wrote: > On Tuesday 19 November 2013, Mark Rutland wrote: > > On Fri, Nov 15, 2013 at 05:52:41PM +0000, Olof Johansson wrote: > > > On Fri, Nov 15, 2013 at 09:57:17AM +0000, Mark Rutland wrote: > > > > Oh wait, there's people who have been doing this for years. Microsoft. They > > > should be the ones driving this and taking the pain for it. Once the platform > > > is enabled for their needs, we'll sort it out at our end. After all, that has > > > worked reasonably well for x86 platforms. > > > > I'm not sure it's entirely reasonable to assume that Microsoft will > > swoop in and develop standards that are useful to us or even applicable > > to the vast majority of the systems that are likely to exist. If they > > do, then we will (by the expectation that Linux should be able to run > > wherever another OS can) have to support whatever standards they may > > create. > > That company is undergoing a lot of change now, I think anything is > possible: They might decide that ARM is a really bad idea (after > the Windows-RT fiasco), they could start working together with us > on these problems, or they could do everything in their hands to > make our lives as hard as they can (as before, see > http://www.groklaw.net/articlebasic.php?story=2010011422570951). > > > Regardless of whether we place support for it into Linux, we should > > certainly be spending time now attempting to understand ACPI, what it > > does and does not provide, and how it can be moved towards something > > that fulfils our needs and we can support long-term. We should certainly > > not be taking a back seat approach. > > > > Outside of the ARM Linux community there is work ongoing to change ACPI > > to better suit the level of variation we seem in the ARM space (see > > Darren Hart's presentation from ELCE [1]). We need to be involved now in > > order to make sure that this is actually generally applicable. > > Agreed. I'm not sure who "we" is in this, but I assume you mean the wider > ARM Linux developer community. Linaro already has full-time developers > working on this, with ties into the UEFI and ACPI standard bodies, and that > is good. Still it does not mean we should prematurely merge any of the > code coming out of it, until there are products out there with ACPI firmware > that is not completely messed up and that is worth supporting in mainline, > considering the maintainance effort. Yes, I meant the greater ARM Linux community. I'm aware that Linaro have people working full-time on this, but we still need members of the greater community to become familiar with ACPI and have an input on it before the greater community can realistically expect to support it. > > > I would also expect that _any_ ACPI support we would accept would not > > rely on any board-specific support code whatsoever -- either everything > > comes from ACPI or the platform doesn't boot. If we allow board files > > for a transitionary period to ACPI we'd be making the same mistake we > > did with DT. > > I would go further and reject any code that adds an SoC or BIOS vendor > specific glue layer. The bar we have set with the current ARM64 code > and for new ARM32 is that everything is in device drivers of some sort. > I would hate to reintroduce platform directories just because every > company has a different understanding of how to describe the same things > in ACPI, or because ACPI-5.0 is insufficient to describe the SoC and > go back to static platform devices. Agreed. > > > Once they're done, we'll figure out how to enable new hardware. Sure, someone > > > needs to keep them sane and participate in the standardization process, but we > > > don't have to drag the whole kernel through it. > > > > To me, reworking the AML code and drivers to support AML + DT feels like > > dragging the whole kernel through it. I would rather see ACPI in full or > > no ACPI than a gigantic ARM-specific set of changes to general > > infrastructure that we'd expect to deprecate in future once we > > understand (the future state of) ACPI. > > I'm skeptical about getting AML working on DT nodes, just as I doubt that > AML is sufficient to do what people want when faced with a complex SoC. > > Also, if AML ends up being mainly used as a trampoline to get into EL2/EL3 > firmware, I'd much rather standardize the actual firmware interfaces > underneath. Agreed. I currently hope that any firmware interfaces for (CPU) power management will be PSCI compatible. > > > As mentioned above, I think that the work to do this is going to end up > > as a weird ARM-specific legacy feature. We will get something wrong here > > in a way that we have to support long-term. I would rather support > > solely DT or solely ACPI at runtime (with a kernel supporting both), > > rather than a mixture of both forever due to an artifact of the > > development process. > > I think that depends on how whether you expect ACPI to succeed in the market > or not. If it ends up being a historic sidenote, that's what the code > should be. > A precedent for this would be mach-shark, which we just removed. It > was one of the original StrongARM machines and actually came with Open > Firmware and a DT that was (rightfully so) converted to ATAGS format > on boot. >From the looks of the removed arch/arm/boot/compressed/ofw-shark.c, the converter only converted /memory, /chosen/bootargs, and /banner-name. That's far less complex than converting an arbitrary ACPI table, and far less likely to hold subtle quirks that vendors will begin relying on in their firmware. It also looks like it could have been factored out were there more OpenFirmware systems. I think that with ACPI systems the data we would have to convert is going to be larger and more varied than that. Given we already have code in the kernel for handling ACPI, I believe it would be more valuable to leverage that and support ACPI directly in those places which require it > > > > Also, we can either have some of our better people sort out the ACPI-to-DT > > > translation and management, and get it done right, or we can rely on all the > > > vendors to get ACPI right in all their drivers. While some of them will, > > > I suspect we'll be more successful driving this from a common place. It > > > also gives us a place to stick all the fixups for broken firmware, > > > since the first generations of ARM servers are bound to have them. > > > > This common place is going to end up handling arbitrarily different > > idioms in each format (e.g. how GPIOs are represented), and is almost > > certainly going to become a sprawling mess. Also having "all the fixups" > > in there makes this sound like an every-single-board file, which is > > something I think everyone would like to avoid. > > I guess if it grows too big, it could be moved into a separate boot loader > project and out of the kernel, as we do for the ATAGS-to-DT conversion > with the impedence-matcher. I think there's a big difference between the impedence matcher and the proposed ACPI => DT converter. The impedence matcher maps a well-defined unique ID to a binary blob it knows nothing about. The proposed ACPI => DT converter necessarily needs to map differing idioms used to represent classes of device, and thus picks up all the domain-specific knowledge that would otherwise be part of a particular subsystem (e.g. GPIO), or even drivers depending on the granularity of conversion. To me it seems that placing this in an external blob is fundamentally the wrong way to go. It must necessarily lump together various unconnected concerns, and will end up mirroring the structure of Linux subsystems and drivers. I think by the time it "grows too big", we've already lost, having wasted our time putting something together that should have been handled in Linux from the start. > > > > > I'm not sure the two cases are comparable. The format of the FDT was > > > > designed to encode the data structure used by OpenFirmware, and thus the > > > > two map to each other pretty well. I do not believe that mapping from > > > > ACPI tables to an FDT blob is anywhere near as simple, and as I mention > > > > above I do not believe that we can just copy over the ACPI methods in > > > > isolation. > > > > > > Sorry, I wasn't implying that there's a one-time trivial conversion > > > to be made in the generic case, but it can still be done in a similar > > > manner even though it will be more complex. > > > > Until I see code, I'm going to remain of the opinion that this is > > unworkable without embedding knowledge of every separate subsystem > > (GPIO, IRQ, etc) into a single place. That seems worse to me than > > teaching those subsystems to deal with the different information > > sources. > > Agreed. > > > > Vendors can standardise of UEFI if they want, but I would much rather > > > see them bundle DTB images with their firmware today, than rely on early > > > buggy and still-early-on-the-learning-curve ACPI bindings that we then > > > have to live with forever. > > > > I agree that today a DTB is preferable to an ACPI implementation. > > > > I think that mapping from ACPI => DT is less sane than building support > > for ACPI, and is not going to help us in the long term. > > > > I think that we need to be involved in ACPI from today if we have any > > hope of having something sane in future. > > I mostly agree, but I think that the decision whether to ignore, translate > or implement support for ACPI BIOS implementations depends a lot on > what kinds of systems we are going to see and the level of sophistication > they put into their firmware. > > If we are basically talking about PCs with their x86 CPU removed and > an ARM chip put in there, I think an ACPI implementation would be > harmless enough. However if we are talking about complex SoCs that just > have the same information in ACPI that we have in DT in a different > format, we really need to tell the responsible developers that ACPI > support for these just won't get merged. I mostly agree. However, I'm not so sure on the latter case. If ACPI matures support for richer description (as some x86 people are pushing for) and it's used in a sane manner, then I don't think we should prevent that, especially if the maintenance burden is shared by the larger Linux community. Thanks, Mark. ^ permalink raw reply [flat|nested] 186+ messages in thread
* ACPI vs DT at runtime @ 2013-11-19 15:21 ` Mark Rutland 0 siblings, 0 replies; 186+ messages in thread From: Mark Rutland @ 2013-11-19 15:21 UTC (permalink / raw) To: linux-arm-kernel On Tue, Nov 19, 2013 at 02:05:33PM +0000, Arnd Bergmann wrote: > On Tuesday 19 November 2013, Mark Rutland wrote: > > On Fri, Nov 15, 2013 at 05:52:41PM +0000, Olof Johansson wrote: > > > On Fri, Nov 15, 2013 at 09:57:17AM +0000, Mark Rutland wrote: > > > > Oh wait, there's people who have been doing this for years. Microsoft. They > > > should be the ones driving this and taking the pain for it. Once the platform > > > is enabled for their needs, we'll sort it out at our end. After all, that has > > > worked reasonably well for x86 platforms. > > > > I'm not sure it's entirely reasonable to assume that Microsoft will > > swoop in and develop standards that are useful to us or even applicable > > to the vast majority of the systems that are likely to exist. If they > > do, then we will (by the expectation that Linux should be able to run > > wherever another OS can) have to support whatever standards they may > > create. > > That company is undergoing a lot of change now, I think anything is > possible: They might decide that ARM is a really bad idea (after > the Windows-RT fiasco), they could start working together with us > on these problems, or they could do everything in their hands to > make our lives as hard as they can (as before, see > http://www.groklaw.net/articlebasic.php?story=2010011422570951). > > > Regardless of whether we place support for it into Linux, we should > > certainly be spending time now attempting to understand ACPI, what it > > does and does not provide, and how it can be moved towards something > > that fulfils our needs and we can support long-term. We should certainly > > not be taking a back seat approach. > > > > Outside of the ARM Linux community there is work ongoing to change ACPI > > to better suit the level of variation we seem in the ARM space (see > > Darren Hart's presentation from ELCE [1]). We need to be involved now in > > order to make sure that this is actually generally applicable. > > Agreed. I'm not sure who "we" is in this, but I assume you mean the wider > ARM Linux developer community. Linaro already has full-time developers > working on this, with ties into the UEFI and ACPI standard bodies, and that > is good. Still it does not mean we should prematurely merge any of the > code coming out of it, until there are products out there with ACPI firmware > that is not completely messed up and that is worth supporting in mainline, > considering the maintainance effort. Yes, I meant the greater ARM Linux community. I'm aware that Linaro have people working full-time on this, but we still need members of the greater community to become familiar with ACPI and have an input on it before the greater community can realistically expect to support it. > > > I would also expect that _any_ ACPI support we would accept would not > > rely on any board-specific support code whatsoever -- either everything > > comes from ACPI or the platform doesn't boot. If we allow board files > > for a transitionary period to ACPI we'd be making the same mistake we > > did with DT. > > I would go further and reject any code that adds an SoC or BIOS vendor > specific glue layer. The bar we have set with the current ARM64 code > and for new ARM32 is that everything is in device drivers of some sort. > I would hate to reintroduce platform directories just because every > company has a different understanding of how to describe the same things > in ACPI, or because ACPI-5.0 is insufficient to describe the SoC and > go back to static platform devices. Agreed. > > > Once they're done, we'll figure out how to enable new hardware. Sure, someone > > > needs to keep them sane and participate in the standardization process, but we > > > don't have to drag the whole kernel through it. > > > > To me, reworking the AML code and drivers to support AML + DT feels like > > dragging the whole kernel through it. I would rather see ACPI in full or > > no ACPI than a gigantic ARM-specific set of changes to general > > infrastructure that we'd expect to deprecate in future once we > > understand (the future state of) ACPI. > > I'm skeptical about getting AML working on DT nodes, just as I doubt that > AML is sufficient to do what people want when faced with a complex SoC. > > Also, if AML ends up being mainly used as a trampoline to get into EL2/EL3 > firmware, I'd much rather standardize the actual firmware interfaces > underneath. Agreed. I currently hope that any firmware interfaces for (CPU) power management will be PSCI compatible. > > > As mentioned above, I think that the work to do this is going to end up > > as a weird ARM-specific legacy feature. We will get something wrong here > > in a way that we have to support long-term. I would rather support > > solely DT or solely ACPI at runtime (with a kernel supporting both), > > rather than a mixture of both forever due to an artifact of the > > development process. > > I think that depends on how whether you expect ACPI to succeed in the market > or not. If it ends up being a historic sidenote, that's what the code > should be. > A precedent for this would be mach-shark, which we just removed. It > was one of the original StrongARM machines and actually came with Open > Firmware and a DT that was (rightfully so) converted to ATAGS format > on boot. >From the looks of the removed arch/arm/boot/compressed/ofw-shark.c, the converter only converted /memory, /chosen/bootargs, and /banner-name. That's far less complex than converting an arbitrary ACPI table, and far less likely to hold subtle quirks that vendors will begin relying on in their firmware. It also looks like it could have been factored out were there more OpenFirmware systems. I think that with ACPI systems the data we would have to convert is going to be larger and more varied than that. Given we already have code in the kernel for handling ACPI, I believe it would be more valuable to leverage that and support ACPI directly in those places which require it > > > > Also, we can either have some of our better people sort out the ACPI-to-DT > > > translation and management, and get it done right, or we can rely on all the > > > vendors to get ACPI right in all their drivers. While some of them will, > > > I suspect we'll be more successful driving this from a common place. It > > > also gives us a place to stick all the fixups for broken firmware, > > > since the first generations of ARM servers are bound to have them. > > > > This common place is going to end up handling arbitrarily different > > idioms in each format (e.g. how GPIOs are represented), and is almost > > certainly going to become a sprawling mess. Also having "all the fixups" > > in there makes this sound like an every-single-board file, which is > > something I think everyone would like to avoid. > > I guess if it grows too big, it could be moved into a separate boot loader > project and out of the kernel, as we do for the ATAGS-to-DT conversion > with the impedence-matcher. I think there's a big difference between the impedence matcher and the proposed ACPI => DT converter. The impedence matcher maps a well-defined unique ID to a binary blob it knows nothing about. The proposed ACPI => DT converter necessarily needs to map differing idioms used to represent classes of device, and thus picks up all the domain-specific knowledge that would otherwise be part of a particular subsystem (e.g. GPIO), or even drivers depending on the granularity of conversion. To me it seems that placing this in an external blob is fundamentally the wrong way to go. It must necessarily lump together various unconnected concerns, and will end up mirroring the structure of Linux subsystems and drivers. I think by the time it "grows too big", we've already lost, having wasted our time putting something together that should have been handled in Linux from the start. > > > > > I'm not sure the two cases are comparable. The format of the FDT was > > > > designed to encode the data structure used by OpenFirmware, and thus the > > > > two map to each other pretty well. I do not believe that mapping from > > > > ACPI tables to an FDT blob is anywhere near as simple, and as I mention > > > > above I do not believe that we can just copy over the ACPI methods in > > > > isolation. > > > > > > Sorry, I wasn't implying that there's a one-time trivial conversion > > > to be made in the generic case, but it can still be done in a similar > > > manner even though it will be more complex. > > > > Until I see code, I'm going to remain of the opinion that this is > > unworkable without embedding knowledge of every separate subsystem > > (GPIO, IRQ, etc) into a single place. That seems worse to me than > > teaching those subsystems to deal with the different information > > sources. > > Agreed. > > > > Vendors can standardise of UEFI if they want, but I would much rather > > > see them bundle DTB images with their firmware today, than rely on early > > > buggy and still-early-on-the-learning-curve ACPI bindings that we then > > > have to live with forever. > > > > I agree that today a DTB is preferable to an ACPI implementation. > > > > I think that mapping from ACPI => DT is less sane than building support > > for ACPI, and is not going to help us in the long term. > > > > I think that we need to be involved in ACPI from today if we have any > > hope of having something sane in future. > > I mostly agree, but I think that the decision whether to ignore, translate > or implement support for ACPI BIOS implementations depends a lot on > what kinds of systems we are going to see and the level of sophistication > they put into their firmware. > > If we are basically talking about PCs with their x86 CPU removed and > an ARM chip put in there, I think an ACPI implementation would be > harmless enough. However if we are talking about complex SoCs that just > have the same information in ACPI that we have in DT in a different > format, we really need to tell the responsible developers that ACPI > support for these just won't get merged. I mostly agree. However, I'm not so sure on the latter case. If ACPI matures support for richer description (as some x86 people are pushing for) and it's used in a sane manner, then I don't think we should prevent that, especially if the maintenance burden is shared by the larger Linux community. Thanks, Mark. ^ permalink raw reply [flat|nested] 186+ messages in thread
[parent not found: <20131119152157.GO5914-NuALmloUBlrZROr8t4l/smS4ubULX0JqMm0uRHvK7Nw@public.gmane.org>]
* Re: ACPI vs DT at runtime 2013-11-19 15:21 ` Mark Rutland @ 2013-11-19 16:19 ` Arnd Bergmann -1 siblings, 0 replies; 186+ messages in thread From: Arnd Bergmann @ 2013-11-19 16:19 UTC (permalink / raw) To: Mark Rutland Cc: Olof Johansson, devicetree-u79uwXL29TY76Z2rM5mHXA, linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r, Grant Likely, Rob Herring On Tuesday 19 November 2013, Mark Rutland wrote: > On Tue, Nov 19, 2013 at 02:05:33PM +0000, Arnd Bergmann wrote: > > > As mentioned above, I think that the work to do this is going to end up > > > as a weird ARM-specific legacy feature. We will get something wrong here > > > in a way that we have to support long-term. I would rather support > > > solely DT or solely ACPI at runtime (with a kernel supporting both), > > > rather than a mixture of both forever due to an artifact of the > > > development process. > > > > I think that depends on how whether you expect ACPI to succeed in the market > > or not. If it ends up being a historic sidenote, that's what the code > > should be. > > A precedent for this would be mach-shark, which we just removed. It > > was one of the original StrongARM machines and actually came with Open > > Firmware and a DT that was (rightfully so) converted to ATAGS format > > on boot. > > From the looks of the removed arch/arm/boot/compressed/ofw-shark.c, the > converter only converted /memory, /chosen/bootargs, and /banner-name. > That's far less complex than converting an arbitrary ACPI table, and far > less likely to hold subtle quirks that vendors will begin relying on in > their firmware. It also looks like it could have been factored out were > there more OpenFirmware systems. Right. Of course at the time, things were much simpler in general. > I think that with ACPI systems the data we would have to convert is > going to be larger and more varied than that. Given we already have code > in the kernel for handling ACPI, I believe it would be more valuable to > leverage that and support ACPI directly in those places which require it We have code in the kernel to handle power management and a couple of very specific platform devices on ACPI based x86 and Itanium PCs. We would use very little of that on ARM, and it doesn't do much of what we need at the moment. We definitely shouldn't add all that infrastructure to make it work on ARM just because someone accidentally put four letters into a requirements document and didn't understand the consequences... > > > > Also, we can either have some of our better people sort out the ACPI-to-DT > > > > translation and management, and get it done right, or we can rely on all the > > > > vendors to get ACPI right in all their drivers. While some of them will, > > > > I suspect we'll be more successful driving this from a common place. It > > > > also gives us a place to stick all the fixups for broken firmware, > > > > since the first generations of ARM servers are bound to have them. > > > > > > This common place is going to end up handling arbitrarily different > > > idioms in each format (e.g. how GPIOs are represented), and is almost > > > certainly going to become a sprawling mess. Also having "all the fixups" > > > in there makes this sound like an every-single-board file, which is > > > something I think everyone would like to avoid. > > > > I guess if it grows too big, it could be moved into a separate boot loader > > project and out of the kernel, as we do for the ATAGS-to-DT conversion > > with the impedence-matcher. > > I think there's a big difference between the impedence matcher and the > proposed ACPI => DT converter. The impedence matcher maps a well-defined > unique ID to a binary blob it knows nothing about. The proposed ACPI => > DT converter necessarily needs to map differing idioms used to represent > classes of device, and thus picks up all the domain-specific knowledge > that would otherwise be part of a particular subsystem (e.g. GPIO), or > even drivers depending on the granularity of conversion. > > To me it seems that placing this in an external blob is fundamentally > the wrong way to go. It must necessarily lump together various > unconnected concerns, and will end up mirroring the structure of Linux > subsystems and drivers. I think by the time it "grows too big", we've > already lost, having wasted our time putting something together that > should have been handled in Linux from the start. As I said, it really depends on what people actually want to do with ACPI, and why they want it. I can see some scenarios in which it would be fairly easy to do the conversion, such as when all the devices are fixed in the SoC and you just need to map a couple of GPIO lines or I2C devices. Doing the full conversion of an SoC structure otoh would be pretty crazy. > > > > Vendors can standardise of UEFI if they want, but I would much rather > > > > see them bundle DTB images with their firmware today, than rely on early > > > > buggy and still-early-on-the-learning-curve ACPI bindings that we then > > > > have to live with forever. > > > > > > I agree that today a DTB is preferable to an ACPI implementation. > > > > > > I think that mapping from ACPI => DT is less sane than building support > > > for ACPI, and is not going to help us in the long term. > > > > > > I think that we need to be involved in ACPI from today if we have any > > > hope of having something sane in future. > > > > I mostly agree, but I think that the decision whether to ignore, translate > > or implement support for ACPI BIOS implementations depends a lot on > > what kinds of systems we are going to see and the level of sophistication > > they put into their firmware. > > > > If we are basically talking about PCs with their x86 CPU removed and > > an ARM chip put in there, I think an ACPI implementation would be > > harmless enough. However if we are talking about complex SoCs that just > > have the same information in ACPI that we have in DT in a different > > format, we really need to tell the responsible developers that ACPI > > support for these just won't get merged. > > I mostly agree. However, I'm not so sure on the latter case. If ACPI > matures support for richer description (as some x86 people are pushing > for) and it's used in a sane manner, then I don't think we should > prevent that, especially if the maintenance burden is shared by the > larger Linux community. True, I just think that's too many "if"s to build a product roadmap on. It can turn into that in a couple of years, but anyone building a complex SoC today is better off assuming it won't come to that IMHO. Arnd -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org More majordomo info at http://vger.kernel.org/majordomo-info.html ^ permalink raw reply [flat|nested] 186+ messages in thread
* ACPI vs DT at runtime @ 2013-11-19 16:19 ` Arnd Bergmann 0 siblings, 0 replies; 186+ messages in thread From: Arnd Bergmann @ 2013-11-19 16:19 UTC (permalink / raw) To: linux-arm-kernel On Tuesday 19 November 2013, Mark Rutland wrote: > On Tue, Nov 19, 2013 at 02:05:33PM +0000, Arnd Bergmann wrote: > > > As mentioned above, I think that the work to do this is going to end up > > > as a weird ARM-specific legacy feature. We will get something wrong here > > > in a way that we have to support long-term. I would rather support > > > solely DT or solely ACPI at runtime (with a kernel supporting both), > > > rather than a mixture of both forever due to an artifact of the > > > development process. > > > > I think that depends on how whether you expect ACPI to succeed in the market > > or not. If it ends up being a historic sidenote, that's what the code > > should be. > > A precedent for this would be mach-shark, which we just removed. It > > was one of the original StrongARM machines and actually came with Open > > Firmware and a DT that was (rightfully so) converted to ATAGS format > > on boot. > > From the looks of the removed arch/arm/boot/compressed/ofw-shark.c, the > converter only converted /memory, /chosen/bootargs, and /banner-name. > That's far less complex than converting an arbitrary ACPI table, and far > less likely to hold subtle quirks that vendors will begin relying on in > their firmware. It also looks like it could have been factored out were > there more OpenFirmware systems. Right. Of course at the time, things were much simpler in general. > I think that with ACPI systems the data we would have to convert is > going to be larger and more varied than that. Given we already have code > in the kernel for handling ACPI, I believe it would be more valuable to > leverage that and support ACPI directly in those places which require it We have code in the kernel to handle power management and a couple of very specific platform devices on ACPI based x86 and Itanium PCs. We would use very little of that on ARM, and it doesn't do much of what we need at the moment. We definitely shouldn't add all that infrastructure to make it work on ARM just because someone accidentally put four letters into a requirements document and didn't understand the consequences... > > > > Also, we can either have some of our better people sort out the ACPI-to-DT > > > > translation and management, and get it done right, or we can rely on all the > > > > vendors to get ACPI right in all their drivers. While some of them will, > > > > I suspect we'll be more successful driving this from a common place. It > > > > also gives us a place to stick all the fixups for broken firmware, > > > > since the first generations of ARM servers are bound to have them. > > > > > > This common place is going to end up handling arbitrarily different > > > idioms in each format (e.g. how GPIOs are represented), and is almost > > > certainly going to become a sprawling mess. Also having "all the fixups" > > > in there makes this sound like an every-single-board file, which is > > > something I think everyone would like to avoid. > > > > I guess if it grows too big, it could be moved into a separate boot loader > > project and out of the kernel, as we do for the ATAGS-to-DT conversion > > with the impedence-matcher. > > I think there's a big difference between the impedence matcher and the > proposed ACPI => DT converter. The impedence matcher maps a well-defined > unique ID to a binary blob it knows nothing about. The proposed ACPI => > DT converter necessarily needs to map differing idioms used to represent > classes of device, and thus picks up all the domain-specific knowledge > that would otherwise be part of a particular subsystem (e.g. GPIO), or > even drivers depending on the granularity of conversion. > > To me it seems that placing this in an external blob is fundamentally > the wrong way to go. It must necessarily lump together various > unconnected concerns, and will end up mirroring the structure of Linux > subsystems and drivers. I think by the time it "grows too big", we've > already lost, having wasted our time putting something together that > should have been handled in Linux from the start. As I said, it really depends on what people actually want to do with ACPI, and why they want it. I can see some scenarios in which it would be fairly easy to do the conversion, such as when all the devices are fixed in the SoC and you just need to map a couple of GPIO lines or I2C devices. Doing the full conversion of an SoC structure otoh would be pretty crazy. > > > > Vendors can standardise of UEFI if they want, but I would much rather > > > > see them bundle DTB images with their firmware today, than rely on early > > > > buggy and still-early-on-the-learning-curve ACPI bindings that we then > > > > have to live with forever. > > > > > > I agree that today a DTB is preferable to an ACPI implementation. > > > > > > I think that mapping from ACPI => DT is less sane than building support > > > for ACPI, and is not going to help us in the long term. > > > > > > I think that we need to be involved in ACPI from today if we have any > > > hope of having something sane in future. > > > > I mostly agree, but I think that the decision whether to ignore, translate > > or implement support for ACPI BIOS implementations depends a lot on > > what kinds of systems we are going to see and the level of sophistication > > they put into their firmware. > > > > If we are basically talking about PCs with their x86 CPU removed and > > an ARM chip put in there, I think an ACPI implementation would be > > harmless enough. However if we are talking about complex SoCs that just > > have the same information in ACPI that we have in DT in a different > > format, we really need to tell the responsible developers that ACPI > > support for these just won't get merged. > > I mostly agree. However, I'm not so sure on the latter case. If ACPI > matures support for richer description (as some x86 people are pushing > for) and it's used in a sane manner, then I don't think we should > prevent that, especially if the maintenance burden is shared by the > larger Linux community. True, I just think that's too many "if"s to build a product roadmap on. It can turn into that in a couple of years, but anyone building a complex SoC today is better off assuming it won't come to that IMHO. Arnd ^ permalink raw reply [flat|nested] 186+ messages in thread
* Re: ACPI vs DT at runtime 2013-11-19 15:21 ` Mark Rutland @ 2013-11-19 18:34 ` Olof Johansson -1 siblings, 0 replies; 186+ messages in thread From: Olof Johansson @ 2013-11-19 18:34 UTC (permalink / raw) To: Mark Rutland Cc: Arnd Bergmann, devicetree-u79uwXL29TY76Z2rM5mHXA, linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r, Grant Likely, Rob Herring On Tue, Nov 19, 2013 at 03:21:57PM +0000, Mark Rutland wrote: > On Tue, Nov 19, 2013 at 02:05:33PM +0000, Arnd Bergmann wrote: > > On Tuesday 19 November 2013, Mark Rutland wrote: > > > On Fri, Nov 15, 2013 at 05:52:41PM +0000, Olof Johansson wrote: > > > > On Fri, Nov 15, 2013 at 09:57:17AM +0000, Mark Rutland wrote: > > > > > > Oh wait, there's people who have been doing this for years. Microsoft. They > > > > should be the ones driving this and taking the pain for it. Once the platform > > > > is enabled for their needs, we'll sort it out at our end. After all, that has > > > > worked reasonably well for x86 platforms. > > > > > > I'm not sure it's entirely reasonable to assume that Microsoft will > > > swoop in and develop standards that are useful to us or even applicable > > > to the vast majority of the systems that are likely to exist. If they > > > do, then we will (by the expectation that Linux should be able to run > > > wherever another OS can) have to support whatever standards they may > > > create. > > > > That company is undergoing a lot of change now, I think anything is > > possible: They might decide that ARM is a really bad idea (after > > the Windows-RT fiasco), they could start working together with us > > on these problems, or they could do everything in their hands to > > make our lives as hard as they can (as before, see > > http://www.groklaw.net/articlebasic.php?story=2010011422570951). > > > > > Regardless of whether we place support for it into Linux, we should > > > certainly be spending time now attempting to understand ACPI, what it > > > does and does not provide, and how it can be moved towards something > > > that fulfils our needs and we can support long-term. We should certainly > > > not be taking a back seat approach. > > > > > > Outside of the ARM Linux community there is work ongoing to change ACPI > > > to better suit the level of variation we seem in the ARM space (see > > > Darren Hart's presentation from ELCE [1]). We need to be involved now in > > > order to make sure that this is actually generally applicable. > > > > Agreed. I'm not sure who "we" is in this, but I assume you mean the wider > > ARM Linux developer community. Linaro already has full-time developers > > working on this, with ties into the UEFI and ACPI standard bodies, and that > > is good. Still it does not mean we should prematurely merge any of the > > code coming out of it, until there are products out there with ACPI firmware > > that is not completely messed up and that is worth supporting in mainline, > > considering the maintainance effort. > > Yes, I meant the greater ARM Linux community. I'm aware that Linaro have > people working full-time on this, but we still need members of the > greater community to become familiar with ACPI and have an input on it > before the greater community can realistically expect to support it. Getting people to join straight from "the community" isn't likely. Or if people join, it might not be the people you actually need. It's more likely that people involved both with upstream and other things at various vendors will join and try to keep things sane. However, given that UEFI/ACPI is a standards body, the number of actual software engineers interested in participating in such activity might be small. > > I mostly agree, but I think that the decision whether to ignore, translate > > or implement support for ACPI BIOS implementations depends a lot on > > what kinds of systems we are going to see and the level of sophistication > > they put into their firmware. > > > > If we are basically talking about PCs with their x86 CPU removed and > > an ARM chip put in there, I think an ACPI implementation would be > > harmless enough. However if we are talking about complex SoCs that just > > have the same information in ACPI that we have in DT in a different > > format, we really need to tell the responsible developers that ACPI > > support for these just won't get merged. > > I mostly agree. However, I'm not so sure on the latter case. If ACPI > matures support for richer description (as some x86 people are pushing > for) and it's used in a sane manner, then I don't think we should > prevent that, especially if the maintenance burden is shared by the > larger Linux community. Imposing a maintenance burden on a larger set of users is the completely wrong way to do this. I'm hoping what you're meaning to say is that we can share infrastructure and solutions between the various architectures, which is a completely different thing than imposing our maintenance on them. :) Still, I'm with Arnd here: It's not a given at this time that we'll ever enable ACPI across the board. For the short-to-medium term it certainly seems like a bad idea to bring in much code for it, and for the longer term we don't know yet. For a vendor, it's safer to plan for both -- and if you don't care about RT compatibility focus on DT today (but keep an eye on ACPI developments). -Olof -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org More majordomo info at http://vger.kernel.org/majordomo-info.html ^ permalink raw reply [flat|nested] 186+ messages in thread
* ACPI vs DT at runtime @ 2013-11-19 18:34 ` Olof Johansson 0 siblings, 0 replies; 186+ messages in thread From: Olof Johansson @ 2013-11-19 18:34 UTC (permalink / raw) To: linux-arm-kernel On Tue, Nov 19, 2013 at 03:21:57PM +0000, Mark Rutland wrote: > On Tue, Nov 19, 2013 at 02:05:33PM +0000, Arnd Bergmann wrote: > > On Tuesday 19 November 2013, Mark Rutland wrote: > > > On Fri, Nov 15, 2013 at 05:52:41PM +0000, Olof Johansson wrote: > > > > On Fri, Nov 15, 2013 at 09:57:17AM +0000, Mark Rutland wrote: > > > > > > Oh wait, there's people who have been doing this for years. Microsoft. They > > > > should be the ones driving this and taking the pain for it. Once the platform > > > > is enabled for their needs, we'll sort it out at our end. After all, that has > > > > worked reasonably well for x86 platforms. > > > > > > I'm not sure it's entirely reasonable to assume that Microsoft will > > > swoop in and develop standards that are useful to us or even applicable > > > to the vast majority of the systems that are likely to exist. If they > > > do, then we will (by the expectation that Linux should be able to run > > > wherever another OS can) have to support whatever standards they may > > > create. > > > > That company is undergoing a lot of change now, I think anything is > > possible: They might decide that ARM is a really bad idea (after > > the Windows-RT fiasco), they could start working together with us > > on these problems, or they could do everything in their hands to > > make our lives as hard as they can (as before, see > > http://www.groklaw.net/articlebasic.php?story=2010011422570951). > > > > > Regardless of whether we place support for it into Linux, we should > > > certainly be spending time now attempting to understand ACPI, what it > > > does and does not provide, and how it can be moved towards something > > > that fulfils our needs and we can support long-term. We should certainly > > > not be taking a back seat approach. > > > > > > Outside of the ARM Linux community there is work ongoing to change ACPI > > > to better suit the level of variation we seem in the ARM space (see > > > Darren Hart's presentation from ELCE [1]). We need to be involved now in > > > order to make sure that this is actually generally applicable. > > > > Agreed. I'm not sure who "we" is in this, but I assume you mean the wider > > ARM Linux developer community. Linaro already has full-time developers > > working on this, with ties into the UEFI and ACPI standard bodies, and that > > is good. Still it does not mean we should prematurely merge any of the > > code coming out of it, until there are products out there with ACPI firmware > > that is not completely messed up and that is worth supporting in mainline, > > considering the maintainance effort. > > Yes, I meant the greater ARM Linux community. I'm aware that Linaro have > people working full-time on this, but we still need members of the > greater community to become familiar with ACPI and have an input on it > before the greater community can realistically expect to support it. Getting people to join straight from "the community" isn't likely. Or if people join, it might not be the people you actually need. It's more likely that people involved both with upstream and other things at various vendors will join and try to keep things sane. However, given that UEFI/ACPI is a standards body, the number of actual software engineers interested in participating in such activity might be small. > > I mostly agree, but I think that the decision whether to ignore, translate > > or implement support for ACPI BIOS implementations depends a lot on > > what kinds of systems we are going to see and the level of sophistication > > they put into their firmware. > > > > If we are basically talking about PCs with their x86 CPU removed and > > an ARM chip put in there, I think an ACPI implementation would be > > harmless enough. However if we are talking about complex SoCs that just > > have the same information in ACPI that we have in DT in a different > > format, we really need to tell the responsible developers that ACPI > > support for these just won't get merged. > > I mostly agree. However, I'm not so sure on the latter case. If ACPI > matures support for richer description (as some x86 people are pushing > for) and it's used in a sane manner, then I don't think we should > prevent that, especially if the maintenance burden is shared by the > larger Linux community. Imposing a maintenance burden on a larger set of users is the completely wrong way to do this. I'm hoping what you're meaning to say is that we can share infrastructure and solutions between the various architectures, which is a completely different thing than imposing our maintenance on them. :) Still, I'm with Arnd here: It's not a given at this time that we'll ever enable ACPI across the board. For the short-to-medium term it certainly seems like a bad idea to bring in much code for it, and for the longer term we don't know yet. For a vendor, it's safer to plan for both -- and if you don't care about RT compatibility focus on DT today (but keep an eye on ACPI developments). -Olof ^ permalink raw reply [flat|nested] 186+ messages in thread
* Re: ACPI vs DT at runtime 2013-11-19 15:21 ` Mark Rutland @ 2013-11-19 19:06 ` Tom Rini -1 siblings, 0 replies; 186+ messages in thread From: Tom Rini @ 2013-11-19 19:06 UTC (permalink / raw) To: Mark Rutland Cc: Arnd Bergmann, Olof Johansson, devicetree-u79uwXL29TY76Z2rM5mHXA, linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r, Grant Likely, Rob Herring On Tue, Nov 19, 2013 at 03:21:57PM +0000, Mark Rutland wrote: [snip] > I think that with ACPI systems the data we would have to convert is > going to be larger and more varied than that. Given we already have code > in the kernel for handling ACPI, I believe it would be more valuable to > leverage that and support ACPI directly in those places which require it I'll bite. How realistic a proprosition is that? When I've talked with a few folks here and there they say, roughly, that "the ARM bit" being set means it's a whole new ball game, and no, they don't expect to be able to re-use a lot of the existing code. -- Tom -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org More majordomo info at http://vger.kernel.org/majordomo-info.html ^ permalink raw reply [flat|nested] 186+ messages in thread
* ACPI vs DT at runtime @ 2013-11-19 19:06 ` Tom Rini 0 siblings, 0 replies; 186+ messages in thread From: Tom Rini @ 2013-11-19 19:06 UTC (permalink / raw) To: linux-arm-kernel On Tue, Nov 19, 2013 at 03:21:57PM +0000, Mark Rutland wrote: [snip] > I think that with ACPI systems the data we would have to convert is > going to be larger and more varied than that. Given we already have code > in the kernel for handling ACPI, I believe it would be more valuable to > leverage that and support ACPI directly in those places which require it I'll bite. How realistic a proprosition is that? When I've talked with a few folks here and there they say, roughly, that "the ARM bit" being set means it's a whole new ball game, and no, they don't expect to be able to re-use a lot of the existing code. -- Tom ^ permalink raw reply [flat|nested] 186+ messages in thread
* Re: ACPI vs DT at runtime 2013-11-19 11:30 ` Mark Rutland @ 2013-11-19 18:19 ` Olof Johansson -1 siblings, 0 replies; 186+ messages in thread From: Olof Johansson @ 2013-11-19 18:19 UTC (permalink / raw) To: Mark Rutland Cc: devicetree-u79uwXL29TY76Z2rM5mHXA, linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r, Grant Likely, Rob Herring, Arnd Bergmann On Tue, Nov 19, 2013 at 11:30:15AM +0000, Mark Rutland wrote: > On Fri, Nov 15, 2013 at 05:52:41PM +0000, Olof Johansson wrote: > > On Fri, Nov 15, 2013 at 09:57:17AM +0000, Mark Rutland wrote: > > > On Fri, Nov 15, 2013 at 01:44:10AM +0000, Olof Johansson wrote: > > > > The more I start to see early UEFI/ACPI code, the more I am certain > > > > that we want none of that crap in the kernel. It's making things > > > > considerably messier, while we're already very busy trying to convert > > > > everything over and enable DT -- we'll be preempting that effort just > > > > to add even more boilerplate everywhere and total progress will be > > > > hurt. > > > > > > We are certainly under a lot of pressure with the device tree migration, > > > and I agree that adding another information source is going to be a > > > source of pain. However, I'd argue that we're going to encounter pain > > > regardless of which approach we take. > > > > > > I'm of the opinion that the only way we should support ACPI is as a > > > first-class citizen. We don't need to modify every driver and subsystem > > > to support ACPI, only those necessary to support the minimal set of > > > platforms using ACPI. ACPI is new in the arm space, and we can enforce > > > quality standards on ACPI _now_ above what we're allowing for DT, and > > > avoid future problems. > > > > It's obvious from the very first submission, from a vendor that has worked > > closely with "the community" (i.e. one enterprise distro at least), that this > > is completely new territory for _everyone_ involved. There's no way that we can > > enforce quality standards for ACPI yet -- we don't know what they look like! > > Nobody knows how to design a good ACPI implementation or binding. > > If we don't know what quality standards we require for ACPI, then I > would rather see ACPI delayed until we are more comfortable with it than > to enforce an arbitrary set of rules required to enable mapping it to > device tree. That's essentially what we're saying here: ACPI isn't ready, let's use DT while it's sorted out and if someone wants to try to require ACPI at some level today, they should figure out how to translate it into DT. In reality, it might be easiest to ship a static DT file while ACPI is being developed and sorted out. I think we're getting bogged down by the hypothetical AML-in-DT case. We won't know if we want/need it until we see what kind of stuff vendors think they will need to do in AML. On x86 it's mostly used to abstract out per-board differences, not whole SoC behavior. It also depends on how much of their hardware differences the silicon vendors decide to punt to software to manage -- that's going to work a lot less well in this type of environment than it does on 32-bit today. > > Oh wait, there's people who have been doing this for years. Microsoft. They > > should be the ones driving this and taking the pain for it. Once the platform > > is enabled for their needs, we'll sort it out at our end. After all, that has > > worked reasonably well for x86 platforms. > > I'm not sure it's entirely reasonable to assume that Microsoft will > swoop in and develop standards that are useful to us or even applicable > to the vast majority of the systems that are likely to exist. If they > do, then we will (by the expectation that Linux should be able to run > wherever another OS can) have to support whatever standards they may > create. > > Regardless of whether we place support for it into Linux, we should > certainly be spending time now attempting to understand ACPI, what it > does and does not provide, and how it can be moved towards something > that fulfils our needs and we can support long-term. We should certainly > not be taking a back seat approach. > > Outside of the ARM Linux community there is work ongoing to change ACPI > to better suit the level of variation we seem in the ARM space (see > Darren Hart's presentation from ELCE [1]). We need to be involved now in > order to make sure that this is actually generally applicable. I agree that there should be engagement, but not at the expense of forward progress using the technologies we're finally sorting out how to use successfully. In other words, we should continue enabling DT on these platforms while ACPI happens in the background for now. People who will longer-term depend on ACPI should of course get engaged in that, but things aren't going to work well if they abandon working on the short-to-medium term solutions of continued DT usage. > > If we knew exactly what we wanted, it'd be a different story. _We > > don't_. We're into year FOUR of the device tree conversion and we're just > > now reaching a point where we think we know what a good solution looks > > like. The first two years were easy -- they were the trivial devices we're > > now talking about on ACPI. After that it got harder. Going through all > > of that again with ACPI? No. No way. Microsoft gets to do it and while > > they're busy sorting it out, we'll boot with device tree. > > Until ACPI is able to provide all the necessary information, and has > suitable standard mechanisms for describing the horrible portions we are > only just figuring out how to describe in DT, then ACPI is eitehr no > better or worse than DT, and should not be used. > > However, we should be looking into it so that when portions of it > eventually appear we have enough of an understanding to cull the > obviously broken parts. I think we're in full agreement on this. > I would also expect that _any_ ACPI support we would accept would not > rely on any board-specific support code whatsoever -- either everything > comes from ACPI or the platform doesn't boot. If we allow board files > for a transitionary period to ACPI we'd be making the same mistake we > did with DT. I don't think anyone is arguing for board files here, that's a dead end. :-) There might however be quirks needed for drivers here and there, at least for new platforms (chipsets), errata workarounds, etc. That's expected, and it's something that they need on x86 today as well. > > Once they're done, we'll figure out how to enable new hardware. Sure, someone > > needs to keep them sane and participate in the standardization process, but we > > don't have to drag the whole kernel through it. > > To me, reworking the AML code and drivers to support AML + DT feels like > dragging the whole kernel through it. I would rather see ACPI in full or > no ACPI than a gigantic ARM-specific set of changes to general > infrastructure that we'd expect to deprecate in future once we > understand (the future state of) ACPI. I think we're getting bogged down in details here, unfortunately. Let's see what people have in mind to implement in AML before we go too far down this path. In theory it could be a nightmare to deal with it given the feature set and complexity of AML, but in reality chances are we can do quite well with just device-tree (as Arnd and others have been arguing as well). So I think we can postpone much of this debate until we actually have examples of what people will use in the real world. [pruning out some double quotes and more AML-related arguments here] > > Also, we can either have some of our better people sort out the ACPI-to-DT > > translation and management, and get it done right, or we can rely on all the > > vendors to get ACPI right in all their drivers. While some of them will, > > I suspect we'll be more successful driving this from a common place. It > > also gives us a place to stick all the fixups for broken firmware, > > since the first generations of ARM servers are bound to have them. > > This common place is going to end up handling arbitrarily different > idioms in each format (e.g. how GPIOs are represented), and is almost > certainly going to become a sprawling mess. Also having "all the fixups" > in there makes this sound like an every-single-board file, which is > something I think everyone would like to avoid. Yeah, it would need to be generic enough to not require per-board changes. Again, let's see how things turn out in reality before we go too far down that path, doing it on theoretical needs is going to overly complicate things. [...] > > Nobody is expecting there to be zero work for new drivers with ACPI; > > after all, the driver itself still has to be written. We're talking differences > > from board to board and system to system here, which we can definitely handle > > through a translator as well. > > > > And, as you say, if the first platforms are going to be trivial and easy to > > implement with ACPI, then doing a translation for them will be simple too. > > This may be true. I worry that by working on this assumption we will > lead people to do the wrong thing by focusing on short-term gain (i.e. > placing board-specific hacks all other drivers and not handling the > general case), rather than getting a long term solution together. There's going to be need for both, and we can't sacrifice work on the short-to-medium term solution because I really don't want things to stumble right away. As Jon is saying, lots of companies are spending significant resources on this, and we need to make sure things are as successful as possible right out the door. That means not restricting short-term solutions with promises/wishes/hopes that things will magically get sorted out by themselves down the road. Given the initial output from the ACPI side of things, that's way too scary a bet to make. > > Shipping a firmware with ACPI is really no different from shipping a firmware > > with a flashed device tree. Whatever bugs or strange things the vendor chooses > > to do in there, we'll have to live with forever. > > > > We all know DT considerably better to a point where I would recommend > > that they flash a DTB in their UEFI firmware instead of go with ACPI. For > > simple hardware and basic devices we've got most bindings sorted out by > > now, and we've decided on backwards compatibility from here on out. > > If a vendor does this, with a DTB that correctly describes their > hardware then I am not against it (and would prefer this case to mapping > from ACPI to DT). For that case we will also require a nailed-down boot > protocol that allows for either DTB or ACPI (only one at a time). UEFI already allows this, as far as I know? Even if both are passed, we can easily make DT take precedence over ACPI, just like DT overrides ATAGs today. > > > > It might be done via having a skeleton/framework DT for the vendor > > > > platform that is updated via UEFI/ACPI data, or it might be > > > > constructed entirely out of tables coming from firmware. I don't care > > > > about the methods for how it is done, but I do feel strongly that we > > > > should _not_ introduce a second API for everything. I can't think of a > > > > single good reason to do it. > > > > > > Where does this skeleton/framework come from? Within the kernel? > > > > Since there might need to be runtime modifications done to the tree based on > > ACPI events, it seems to make sense to do it in the kernel, so that translation > > state and such can be kept around for use by the runtime modification parts. > > > > Having it extractable out of the kernel tree for testing purposes would be > > greatly appreciated, so it can be ran through valgrind, add testcases, etc. > > This is still sounding awfully complicated. Yes, but so is doing a native ACPI implementation. Anyway, let's hold off until we know what we're actually going to need. > > There are no known best practices with ACPI. It's a complete fumbling > > around in the dark right now. We're complaining about reviewer bandwith > > on DT -- do we have a single reviewer for ACPI on ARM that actually > > knows what a good solution looks like? I don't think so. > > There are many people in the Linux community who have ACPI experience. > They may not be active on the ARM side, but it's not fair to say there > are no known best practices. I will agree that for the level of > variation we're likely to expect we are pushing the boundaries. Right -- as we've seen with DT where it was easy-peasy on PowerPC since there were only 2-4 real vendors involved, things get substantially more complicated when you increase that by an order of magnitude. In this case, we'd be increasing it with an order of magnitude _and_ bring in their firmware engineers to be involved too (since we would no longer have control over what gets put into the tables). While there are people who have a lot of ACPI experience today, the environment around it (community/participants and technical diversity) _and_ the new need for more complex things is new to everybody. As we've seen with DT, we can't always rely on the existing people to have capacity for the onslaught of activity that will come down the pipe. > > So, until there's strong evidence that ACPI is actually going to be > > a sane solution, in other words, until someone has shipped a system > > that uses it (with Windows) and does it successfully without being > > a hot mess, we shouldn't litter the kernel with it. > > Again, I'm not sure that we should rely on Windows as our saviour from > insanity. A lot of the issues we are going to encounter are going to be > in vendor-specific code (i.e. drivers), and I do not believe that is > solved by having a single entity in charge of the general frameworks > those are built upon. As mentioned in other replies in the thread, I was a bit careless in how I phrased this. We can't just wait until they're done, but we also shouldn't do it all ourselves. And we definitely shouldn't bet our house on it resulting in a useable solution at this point. > > Vendors can standardise of UEFI if they want, but I would much rather > > see them bundle DTB images with their firmware today, than rely on early > > buggy and still-early-on-the-learning-curve ACPI bindings that we then > > have to live with forever. > > I agree that today a DTB is preferable to an ACPI implementation. > > I think that mapping from ACPI => DT is less sane than building support > for ACPI, and is not going to help us in the long term. I think it'll depend on what will actually be needed on real systems. And I'm not making many assumptions on long term here -- we can't let that distract us from getting the first few years sorted out first. > I think that we need to be involved in ACPI from today if we have any > hope of having something sane in future. We agree more than we disagree on this whole discussion, I believe. -Olof -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org More majordomo info at http://vger.kernel.org/majordomo-info.html ^ permalink raw reply [flat|nested] 186+ messages in thread
* ACPI vs DT at runtime @ 2013-11-19 18:19 ` Olof Johansson 0 siblings, 0 replies; 186+ messages in thread From: Olof Johansson @ 2013-11-19 18:19 UTC (permalink / raw) To: linux-arm-kernel On Tue, Nov 19, 2013 at 11:30:15AM +0000, Mark Rutland wrote: > On Fri, Nov 15, 2013 at 05:52:41PM +0000, Olof Johansson wrote: > > On Fri, Nov 15, 2013 at 09:57:17AM +0000, Mark Rutland wrote: > > > On Fri, Nov 15, 2013 at 01:44:10AM +0000, Olof Johansson wrote: > > > > The more I start to see early UEFI/ACPI code, the more I am certain > > > > that we want none of that crap in the kernel. It's making things > > > > considerably messier, while we're already very busy trying to convert > > > > everything over and enable DT -- we'll be preempting that effort just > > > > to add even more boilerplate everywhere and total progress will be > > > > hurt. > > > > > > We are certainly under a lot of pressure with the device tree migration, > > > and I agree that adding another information source is going to be a > > > source of pain. However, I'd argue that we're going to encounter pain > > > regardless of which approach we take. > > > > > > I'm of the opinion that the only way we should support ACPI is as a > > > first-class citizen. We don't need to modify every driver and subsystem > > > to support ACPI, only those necessary to support the minimal set of > > > platforms using ACPI. ACPI is new in the arm space, and we can enforce > > > quality standards on ACPI _now_ above what we're allowing for DT, and > > > avoid future problems. > > > > It's obvious from the very first submission, from a vendor that has worked > > closely with "the community" (i.e. one enterprise distro at least), that this > > is completely new territory for _everyone_ involved. There's no way that we can > > enforce quality standards for ACPI yet -- we don't know what they look like! > > Nobody knows how to design a good ACPI implementation or binding. > > If we don't know what quality standards we require for ACPI, then I > would rather see ACPI delayed until we are more comfortable with it than > to enforce an arbitrary set of rules required to enable mapping it to > device tree. That's essentially what we're saying here: ACPI isn't ready, let's use DT while it's sorted out and if someone wants to try to require ACPI at some level today, they should figure out how to translate it into DT. In reality, it might be easiest to ship a static DT file while ACPI is being developed and sorted out. I think we're getting bogged down by the hypothetical AML-in-DT case. We won't know if we want/need it until we see what kind of stuff vendors think they will need to do in AML. On x86 it's mostly used to abstract out per-board differences, not whole SoC behavior. It also depends on how much of their hardware differences the silicon vendors decide to punt to software to manage -- that's going to work a lot less well in this type of environment than it does on 32-bit today. > > Oh wait, there's people who have been doing this for years. Microsoft. They > > should be the ones driving this and taking the pain for it. Once the platform > > is enabled for their needs, we'll sort it out at our end. After all, that has > > worked reasonably well for x86 platforms. > > I'm not sure it's entirely reasonable to assume that Microsoft will > swoop in and develop standards that are useful to us or even applicable > to the vast majority of the systems that are likely to exist. If they > do, then we will (by the expectation that Linux should be able to run > wherever another OS can) have to support whatever standards they may > create. > > Regardless of whether we place support for it into Linux, we should > certainly be spending time now attempting to understand ACPI, what it > does and does not provide, and how it can be moved towards something > that fulfils our needs and we can support long-term. We should certainly > not be taking a back seat approach. > > Outside of the ARM Linux community there is work ongoing to change ACPI > to better suit the level of variation we seem in the ARM space (see > Darren Hart's presentation from ELCE [1]). We need to be involved now in > order to make sure that this is actually generally applicable. I agree that there should be engagement, but not at the expense of forward progress using the technologies we're finally sorting out how to use successfully. In other words, we should continue enabling DT on these platforms while ACPI happens in the background for now. People who will longer-term depend on ACPI should of course get engaged in that, but things aren't going to work well if they?abandon working on the short-to-medium term solutions of continued DT usage. > > If we knew exactly what we wanted, it'd be a different story. _We > > don't_. We're into year FOUR of the device tree conversion and we're just > > now reaching a point where we think we know what a good solution looks > > like. The first two years were easy -- they were the trivial devices we're > > now talking about on ACPI. After that it got harder. Going through all > > of that again with ACPI? No. No way. Microsoft gets to do it and while > > they're busy sorting it out, we'll boot with device tree. > > Until ACPI is able to provide all the necessary information, and has > suitable standard mechanisms for describing the horrible portions we are > only just figuring out how to describe in DT, then ACPI is eitehr no > better or worse than DT, and should not be used. > > However, we should be looking into it so that when portions of it > eventually appear we have enough of an understanding to cull the > obviously broken parts. I think we're in full agreement on this. > I would also expect that _any_ ACPI support we would accept would not > rely on any board-specific support code whatsoever -- either everything > comes from ACPI or the platform doesn't boot. If we allow board files > for a transitionary period to ACPI we'd be making the same mistake we > did with DT. I don't think anyone is arguing for board files here, that's a dead end. :-) There might however be quirks needed for drivers here and there, at least for new platforms (chipsets), errata workarounds, etc. That's expected, and it's something that they need on x86 today as well. > > Once they're done, we'll figure out how to enable new hardware. Sure, someone > > needs to keep them sane and participate in the standardization process, but we > > don't have to drag the whole kernel through it. > > To me, reworking the AML code and drivers to support AML + DT feels like > dragging the whole kernel through it. I would rather see ACPI in full or > no ACPI than a gigantic ARM-specific set of changes to general > infrastructure that we'd expect to deprecate in future once we > understand (the future state of) ACPI. I think we're getting bogged down in details here, unfortunately. Let's see what people have in mind to implement in AML before we go too far down this path. In theory it could be a nightmare to deal with it given the feature set and complexity of AML, but in reality chances are we can do quite well with just device-tree (as Arnd and others have been arguing as well). So I think we can postpone much of this debate until we actually have examples of what people will use in the real world. [pruning out some double quotes and more AML-related arguments here] > > Also, we can either have some of our better people sort out the ACPI-to-DT > > translation and management, and get it done right, or we can rely on all the > > vendors to get ACPI right in all their drivers. While some of them will, > > I suspect we'll be more successful driving this from a common place. It > > also gives us a place to stick all the fixups for broken firmware, > > since the first generations of ARM servers are bound to have them. > > This common place is going to end up handling arbitrarily different > idioms in each format (e.g. how GPIOs are represented), and is almost > certainly going to become a sprawling mess. Also having "all the fixups" > in there makes this sound like an every-single-board file, which is > something I think everyone would like to avoid. Yeah, it would need to be generic enough to not require per-board changes. Again, let's see how things turn out in reality before we go too far down that path, doing it on theoretical needs is going to overly complicate things. [...] > > Nobody is expecting there to be zero work for new drivers with ACPI; > > after all, the driver itself still has to be written. We're talking differences > > from board to board and system to system here, which we can definitely handle > > through a translator as well. > > > > And, as you say, if the first platforms are going to be trivial and easy to > > implement with ACPI, then doing a translation for them will be simple too. > > This may be true. I worry that by working on this assumption we will > lead people to do the wrong thing by focusing on short-term gain (i.e. > placing board-specific hacks all other drivers and not handling the > general case), rather than getting a long term solution together. There's going to be need for both, and we can't sacrifice work on the short-to-medium term solution because I really don't want things to stumble right away. As Jon is saying, lots of companies are spending significant resources on this, and we need to make sure things are as successful as possible right out the door. That means not restricting short-term solutions with promises/wishes/hopes that things will magically get sorted out by themselves down the road. Given the initial output from the ACPI side of things, that's way too scary a bet to make. > > Shipping a firmware with ACPI is really no different from shipping a firmware > > with a flashed device tree. Whatever bugs or strange things the vendor chooses > > to do in there, we'll have to live with forever. > > > > We all know DT considerably better to a point where I would recommend > > that they flash a DTB in their UEFI firmware instead of go with ACPI. For > > simple hardware and basic devices we've got most bindings sorted out by > > now, and we've decided on backwards compatibility from here on out. > > If a vendor does this, with a DTB that correctly describes their > hardware then I am not against it (and would prefer this case to mapping > from ACPI to DT). For that case we will also require a nailed-down boot > protocol that allows for either DTB or ACPI (only one at a time). UEFI already allows this, as far as I know? Even if both are passed, we can easily make DT take precedence over ACPI, just like DT overrides ATAGs today. > > > > It might be done via having a skeleton/framework DT for the vendor > > > > platform that is updated via UEFI/ACPI data, or it might be > > > > constructed entirely out of tables coming from firmware. I don't care > > > > about the methods for how it is done, but I do feel strongly that we > > > > should _not_ introduce a second API for everything. I can't think of a > > > > single good reason to do it. > > > > > > Where does this skeleton/framework come from? Within the kernel? > > > > Since there might need to be runtime modifications done to the tree based on > > ACPI events, it seems to make sense to do it in the kernel, so that translation > > state and such can be kept around for use by the runtime modification parts. > > > > Having it extractable out of the kernel tree for testing purposes would be > > greatly appreciated, so it can be ran through valgrind, add testcases, etc. > > This is still sounding awfully complicated. Yes, but so is doing a native ACPI implementation. Anyway, let's hold off until we know what we're actually going to need. > > There are no known best practices with ACPI. It's a complete fumbling > > around in the dark right now. We're complaining about reviewer bandwith > > on DT -- do we have a single reviewer for ACPI on ARM that actually > > knows what a good solution looks like? I don't think so. > > There are many people in the Linux community who have ACPI experience. > They may not be active on the ARM side, but it's not fair to say there > are no known best practices. I will agree that for the level of > variation we're likely to expect we are pushing the boundaries. Right -- as we've seen with DT where it was easy-peasy on PowerPC since there were only 2-4 real vendors involved, things get substantially more complicated when you increase that by an order of magnitude. In this case, we'd be increasing it with an order of magnitude _and_ bring in their firmware engineers to be involved too (since we would no longer have control over what gets put into the tables). While there are people who have a lot of ACPI experience today, the environment around it (community/participants and technical diversity) _and_ the new need for more complex things is new to everybody. As we've seen with DT, we can't always rely on the existing people to have capacity for the onslaught of activity that will come down the pipe. > > So, until there's strong evidence that ACPI is actually going to be > > a sane solution, in other words, until someone has shipped a system > > that uses it (with Windows) and does it successfully without being > > a hot mess, we shouldn't litter the kernel with it. > > Again, I'm not sure that we should rely on Windows as our saviour from > insanity. A lot of the issues we are going to encounter are going to be > in vendor-specific code (i.e. drivers), and I do not believe that is > solved by having a single entity in charge of the general frameworks > those are built upon. As mentioned in other replies in the thread, I was a bit careless in how I phrased this. We can't just wait until they're done, but we also shouldn't do it all ourselves. And we definitely shouldn't bet our house on it resulting in a useable solution at this point. > > Vendors can standardise of UEFI if they want, but I would much rather > > see them bundle DTB images with their firmware today, than rely on early > > buggy and still-early-on-the-learning-curve ACPI bindings that we then > > have to live with forever. > > I agree that today a DTB is preferable to an ACPI implementation. > > I think that mapping from ACPI => DT is less sane than building support > for ACPI, and is not going to help us in the long term. I think it'll depend on what will actually be needed on real systems. And I'm not making many assumptions on long term here -- we can't let that distract us from getting the first few years sorted out first. > I think that we need to be involved in ACPI from today if we have any > hope of having something sane in future. We agree more than we disagree on this whole discussion, I believe. -Olof ^ permalink raw reply [flat|nested] 186+ messages in thread
[parent not found: <20131119181959.GA20967-O5ziIzlqnXUVNXGz7ipsyg@public.gmane.org>]
* Re: ACPI vs DT at runtime 2013-11-19 18:19 ` Olof Johansson @ 2013-11-21 16:37 ` Grant Likely -1 siblings, 0 replies; 186+ messages in thread From: Grant Likely @ 2013-11-21 16:37 UTC (permalink / raw) To: Olof Johansson, Mark Rutland Cc: devicetree-u79uwXL29TY76Z2rM5mHXA, linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r, Rob Herring, Arnd Bergmann On Tue, 19 Nov 2013 10:19:59 -0800, Olof Johansson <olof-nZhT3qVonbNeoWH0uzbU5w@public.gmane.org> wrote: > I think we're getting bogged down by the hypothetical AML-in-DT case. We won't > know if we want/need it until we see what kind of stuff vendors think they will > need to do in AML. On x86 it's mostly used to abstract out per-board > differences, not whole SoC behavior. It also depends on how much of their > hardware differences the silicon vendors decide to punt to software to manage > -- that's going to work a lot less well in this type of environment than it > does on 32-bit today. I'm going to go out on a limb here and say flat out "no" to AML in DT. AML in DT makes no sense to me. I've resisted any attempts to add a bytecode to FDT. The whole model we've been working on with DT is describe the hardware as competently as possible and expect device drivers to bind on the platform to handle the fiddly bits. ACPI takes the opposite approach and I don't want to go down the path of pushing functionality out to the platform when using the DT infrastructure. ... That said, I'm not opposed to the ACPI and DT subsystems making use of shared infrastructure wherever possible. > > If a vendor does this, with a DTB that correctly describes their > > hardware then I am not against it (and would prefer this case to mapping > > from ACPI to DT). For that case we will also require a nailed-down boot > > protocol that allows for either DTB or ACPI (only one at a time). > > UEFI already allows this, as far as I know? Even if both are passed, we can > easily make DT take precedence over ACPI, just like DT overrides ATAGs today. Yes, there is no problem with a platform passing both DT and ACPI. g. -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org More majordomo info at http://vger.kernel.org/majordomo-info.html ^ permalink raw reply [flat|nested] 186+ messages in thread
* ACPI vs DT at runtime @ 2013-11-21 16:37 ` Grant Likely 0 siblings, 0 replies; 186+ messages in thread From: Grant Likely @ 2013-11-21 16:37 UTC (permalink / raw) To: linux-arm-kernel On Tue, 19 Nov 2013 10:19:59 -0800, Olof Johansson <olof@lixom.net> wrote: > I think we're getting bogged down by the hypothetical AML-in-DT case. We won't > know if we want/need it until we see what kind of stuff vendors think they will > need to do in AML. On x86 it's mostly used to abstract out per-board > differences, not whole SoC behavior. It also depends on how much of their > hardware differences the silicon vendors decide to punt to software to manage > -- that's going to work a lot less well in this type of environment than it > does on 32-bit today. I'm going to go out on a limb here and say flat out "no" to AML in DT. AML in DT makes no sense to me. I've resisted any attempts to add a bytecode to FDT. The whole model we've been working on with DT is describe the hardware as competently as possible and expect device drivers to bind on the platform to handle the fiddly bits. ACPI takes the opposite approach and I don't want to go down the path of pushing functionality out to the platform when using the DT infrastructure. ... That said, I'm not opposed to the ACPI and DT subsystems making use of shared infrastructure wherever possible. > > If a vendor does this, with a DTB that correctly describes their > > hardware then I am not against it (and would prefer this case to mapping > > from ACPI to DT). For that case we will also require a nailed-down boot > > protocol that allows for either DTB or ACPI (only one at a time). > > UEFI already allows this, as far as I know? Even if both are passed, we can > easily make DT take precedence over ACPI, just like DT overrides ATAGs today. Yes, there is no problem with a platform passing both DT and ACPI. g. ^ permalink raw reply [flat|nested] 186+ messages in thread
* Re: ACPI vs DT at runtime 2013-11-19 11:30 ` Mark Rutland @ 2013-11-21 16:29 ` Grant Likely -1 siblings, 0 replies; 186+ messages in thread From: Grant Likely @ 2013-11-21 16:29 UTC (permalink / raw) To: Mark Rutland, Olof Johansson Cc: devicetree-u79uwXL29TY76Z2rM5mHXA, linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r, Rob Herring, Arnd Bergmann On Tue, 19 Nov 2013 11:30:15 +0000, Mark Rutland <mark.rutland-5wv7dgnIgG8@public.gmane.org> wrote: > On Fri, Nov 15, 2013 at 05:52:41PM +0000, Olof Johansson wrote: > > On Fri, Nov 15, 2013 at 09:57:17AM +0000, Mark Rutland wrote: > > > On Fri, Nov 15, 2013 at 01:44:10AM +0000, Olof Johansson wrote: > The UEFI spec pulls in portions of ACPI. I do not know the full extent > of the interaction between the two, but I know that they are not > completely decoupled. As you have pointed out we are not experienced > with ACPI or UEFI, so I don't think we can make statements that one is > perfectly fine without the other. Not actually. The UEFI spec does define how to pass ACPI, but it can boot the system without any ACPI at all. Merging UEFI support should pretty much be a non-issue. > > > I think that trying to shoe-horn ACPI-derived information into device > > > tree is fundamentally the wrong approach. I don't think it encourages > > > best practices, and I don't think it's beneficial to the long term > > > health of Linux or the ecosystem as a whole. > > > > There are no known best practices with ACPI. It's a complete fumbling > > around in the dark right now. We're complaining about reviewer bandwith > > on DT -- do we have a single reviewer for ACPI on ARM that actually > > knows what a good solution looks like? I don't think so. > > There are many people in the Linux community who have ACPI experience. > They may not be active on the ARM side, but it's not fair to say there > are no known best practices. I will agree that for the level of > variation we're likely to expect we are pushing the boundaries. We are pushing a lot of boundaries and doing things on ACPI that have never been done before. SPI, GPIOs, Clocks, Regulators, composite devices, key-value properties. All brand new territory, and the Linux world is driving a lot of it. > > So, until there's strong evidence that ACPI is actually going to be > > a sane solution, in other words, until someone has shipped a system > > that uses it (with Windows) and does it successfully without being > > a hot mess, we shouldn't litter the kernel with it. > > Again, I'm not sure that we should rely on Windows as our saviour from > insanity. A lot of the issues we are going to encounter are going to be > in vendor-specific code (i.e. drivers), and I do not believe that is > solved by having a single entity in charge of the general frameworks > those are built upon. Personally, I think the issue of ACPI support should be taken on a patch-by-patch basis. A lot of the things that need to be done are quite discrete and fairly well contained. If the patches don't look that way then push back on them. For the parts that look ready, go ahead and merge it. Push back on the ones that don't. > > Vendors can standardise of UEFI if they want, but I would much rather > > see them bundle DTB images with their firmware today, than rely on early > > buggy and still-early-on-the-learning-curve ACPI bindings that we then > > have to live with forever. > > I agree that today a DTB is preferable to an ACPI implementation. > > I think that mapping from ACPI => DT is less sane than building support > for ACPI, and is not going to help us in the long term. > > I think that we need to be involved in ACPI from today if we have any > hope of having something sane in future. +1 g. -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org More majordomo info at http://vger.kernel.org/majordomo-info.html ^ permalink raw reply [flat|nested] 186+ messages in thread
* ACPI vs DT at runtime @ 2013-11-21 16:29 ` Grant Likely 0 siblings, 0 replies; 186+ messages in thread From: Grant Likely @ 2013-11-21 16:29 UTC (permalink / raw) To: linux-arm-kernel On Tue, 19 Nov 2013 11:30:15 +0000, Mark Rutland <mark.rutland@arm.com> wrote: > On Fri, Nov 15, 2013 at 05:52:41PM +0000, Olof Johansson wrote: > > On Fri, Nov 15, 2013 at 09:57:17AM +0000, Mark Rutland wrote: > > > On Fri, Nov 15, 2013 at 01:44:10AM +0000, Olof Johansson wrote: > The UEFI spec pulls in portions of ACPI. I do not know the full extent > of the interaction between the two, but I know that they are not > completely decoupled. As you have pointed out we are not experienced > with ACPI or UEFI, so I don't think we can make statements that one is > perfectly fine without the other. Not actually. The UEFI spec does define how to pass ACPI, but it can boot the system without any ACPI at all. Merging UEFI support should pretty much be a non-issue. > > > I think that trying to shoe-horn ACPI-derived information into device > > > tree is fundamentally the wrong approach. I don't think it encourages > > > best practices, and I don't think it's beneficial to the long term > > > health of Linux or the ecosystem as a whole. > > > > There are no known best practices with ACPI. It's a complete fumbling > > around in the dark right now. We're complaining about reviewer bandwith > > on DT -- do we have a single reviewer for ACPI on ARM that actually > > knows what a good solution looks like? I don't think so. > > There are many people in the Linux community who have ACPI experience. > They may not be active on the ARM side, but it's not fair to say there > are no known best practices. I will agree that for the level of > variation we're likely to expect we are pushing the boundaries. We are pushing a lot of boundaries and doing things on ACPI that have never been done before. SPI, GPIOs, Clocks, Regulators, composite devices, key-value properties. All brand new territory, and the Linux world is driving a lot of it. > > So, until there's strong evidence that ACPI is actually going to be > > a sane solution, in other words, until someone has shipped a system > > that uses it (with Windows) and does it successfully without being > > a hot mess, we shouldn't litter the kernel with it. > > Again, I'm not sure that we should rely on Windows as our saviour from > insanity. A lot of the issues we are going to encounter are going to be > in vendor-specific code (i.e. drivers), and I do not believe that is > solved by having a single entity in charge of the general frameworks > those are built upon. Personally, I think the issue of ACPI support should be taken on a patch-by-patch basis. A lot of the things that need to be done are quite discrete and fairly well contained. If the patches don't look that way then push back on them. For the parts that look ready, go ahead and merge it. Push back on the ones that don't. > > Vendors can standardise of UEFI if they want, but I would much rather > > see them bundle DTB images with their firmware today, than rely on early > > buggy and still-early-on-the-learning-curve ACPI bindings that we then > > have to live with forever. > > I agree that today a DTB is preferable to an ACPI implementation. > > I think that mapping from ACPI => DT is less sane than building support > for ACPI, and is not going to help us in the long term. > > I think that we need to be involved in ACPI from today if we have any > hope of having something sane in future. +1 g. ^ permalink raw reply [flat|nested] 186+ messages in thread
[parent not found: <20131121170122. GB22960@srcf.ucam.org>]
[parent not found: <20131121170122.GB22960-1xO5oi07KQx4cg9Nei1l7Q@public.gmane.org>]
* Re: ACPI vs DT at runtime 2013-11-21 17:01 ` Matthew Garrett @ 2013-11-21 18:38 ` Grant Likely -1 siblings, 0 replies; 186+ messages in thread From: Grant Likely @ 2013-11-21 18:38 UTC (permalink / raw) To: Matthew Garrett Cc: Mark Rutland, Olof Johansson, devicetree-u79uwXL29TY76Z2rM5mHXA, Arnd Bergmann, linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r On Thu, 21 Nov 2013 17:01:22 +0000, Matthew Garrett <mjg59-1xO5oi07KQx4cg9Nei1l7Q@public.gmane.org> wrote: > On Thu, Nov 21, 2013 at 04:29:44PM +0000, Grant Likely wrote: > > > Personally, I think the issue of ACPI support should be taken on a > > patch-by-patch basis. A lot of the things that need to be done are quite > > discrete and fairly well contained. If the patches don't look that way > > then push back on them. For the parts that look ready, go ahead and > > merge it. Push back on the ones that don't. > > I think the most valuable thing in ACPI is the static data tables. > Things like BERT, EINJ, HEST, MPST and the various other bits of RAS > functionality have value in the ARM world, and being able to share the > implementation is a benefit. But that can be implemented without > worrying about using ACPI for device discovery or interfacing. /complete digression.../ As far as static tables are concerned, it would be trivial to pull those into a DT system. g. -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org More majordomo info at http://vger.kernel.org/majordomo-info.html ^ permalink raw reply [flat|nested] 186+ messages in thread
* ACPI vs DT at runtime @ 2013-11-21 18:38 ` Grant Likely 0 siblings, 0 replies; 186+ messages in thread From: Grant Likely @ 2013-11-21 18:38 UTC (permalink / raw) To: linux-arm-kernel On Thu, 21 Nov 2013 17:01:22 +0000, Matthew Garrett <mjg59@srcf.ucam.org> wrote: > On Thu, Nov 21, 2013 at 04:29:44PM +0000, Grant Likely wrote: > > > Personally, I think the issue of ACPI support should be taken on a > > patch-by-patch basis. A lot of the things that need to be done are quite > > discrete and fairly well contained. If the patches don't look that way > > then push back on them. For the parts that look ready, go ahead and > > merge it. Push back on the ones that don't. > > I think the most valuable thing in ACPI is the static data tables. > Things like BERT, EINJ, HEST, MPST and the various other bits of RAS > functionality have value in the ARM world, and being able to share the > implementation is a benefit. But that can be implemented without > worrying about using ACPI for device discovery or interfacing. /complete digression.../ As far as static tables are concerned, it would be trivial to pull those into a DT system. g. ^ permalink raw reply [flat|nested] 186+ messages in thread
[parent not found: <20131121162944.F087FC406A3-WNowdnHR2B42iJbIjFUEsiwD8/FfD2ys@public.gmane.org>]
* Re: ACPI vs DT at runtime 2013-11-21 16:29 ` Grant Likely @ 2013-11-21 17:01 ` Matthew Garrett -1 siblings, 0 replies; 186+ messages in thread From: Matthew Garrett @ 2013-11-21 17:01 UTC (permalink / raw) To: Grant Likely Cc: Mark Rutland, Olof Johansson, devicetree-u79uwXL29TY76Z2rM5mHXA, Arnd Bergmann, linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r On Thu, Nov 21, 2013 at 04:29:44PM +0000, Grant Likely wrote: > Personally, I think the issue of ACPI support should be taken on a > patch-by-patch basis. A lot of the things that need to be done are quite > discrete and fairly well contained. If the patches don't look that way > then push back on them. For the parts that look ready, go ahead and > merge it. Push back on the ones that don't. I think the most valuable thing in ACPI is the static data tables. Things like BERT, EINJ, HEST, MPST and the various other bits of RAS functionality have value in the ARM world, and being able to share the implementation is a benefit. But that can be implemented without worrying about using ACPI for device discovery or interfacing. -- Matthew Garrett | mjg59-1xO5oi07KQx4cg9Nei1l7Q@public.gmane.org -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org More majordomo info at http://vger.kernel.org/majordomo-info.html ^ permalink raw reply [flat|nested] 186+ messages in thread
* ACPI vs DT at runtime @ 2013-11-21 17:01 ` Matthew Garrett 0 siblings, 0 replies; 186+ messages in thread From: Matthew Garrett @ 2013-11-21 17:01 UTC (permalink / raw) To: linux-arm-kernel On Thu, Nov 21, 2013 at 04:29:44PM +0000, Grant Likely wrote: > Personally, I think the issue of ACPI support should be taken on a > patch-by-patch basis. A lot of the things that need to be done are quite > discrete and fairly well contained. If the patches don't look that way > then push back on them. For the parts that look ready, go ahead and > merge it. Push back on the ones that don't. I think the most valuable thing in ACPI is the static data tables. Things like BERT, EINJ, HEST, MPST and the various other bits of RAS functionality have value in the ARM world, and being able to share the implementation is a benefit. But that can be implemented without worrying about using ACPI for device discovery or interfacing. -- Matthew Garrett | mjg59 at srcf.ucam.org ^ permalink raw reply [flat|nested] 186+ messages in thread
* Re: ACPI vs DT at runtime 2013-11-21 16:29 ` Grant Likely @ 2013-11-21 17:58 ` Olof Johansson -1 siblings, 0 replies; 186+ messages in thread From: Olof Johansson @ 2013-11-21 17:58 UTC (permalink / raw) To: Grant Likely Cc: Mark Rutland, devicetree-u79uwXL29TY76Z2rM5mHXA, linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r, Rob Herring, Arnd Bergmann On Thu, Nov 21, 2013 at 04:29:44PM +0000, Grant Likely wrote: > On Tue, 19 Nov 2013 11:30:15 +0000, Mark Rutland <mark.rutland-5wv7dgnIgG8@public.gmane.org> wrote: > > On Fri, Nov 15, 2013 at 05:52:41PM +0000, Olof Johansson wrote: > > On Fri, Nov 15, 2013 at 09:57:17AM +0000, Mark Rutland wrote: > > > > On Fri, Nov 15, 2013 at 01:44:10AM +0000, Olof Johansson wrote: > > The UEFI spec pulls in portions of ACPI. I do not know the full extent > > of the interaction between the two, but I know that they are not > > completely decoupled. As you have pointed out we are not experienced > > with ACPI or UEFI, so I don't think we can make statements that one is > > perfectly fine without the other. > > Not actually. The UEFI spec does define how to pass ACPI, but it can > boot the system without any ACPI at all. Merging UEFI support should > pretty much be a non-issue. > > > > > I think that trying to shoe-horn ACPI-derived information into device > > > > tree is fundamentally the wrong approach. I don't think it encourages > > > > best practices, and I don't think it's beneficial to the long term > > > > health of Linux or the ecosystem as a whole. > > > > > > There are no known best practices with ACPI. It's a complete fumbling > > > around in the dark right now. We're complaining about reviewer bandwith > > > on DT -- do we have a single reviewer for ACPI on ARM that actually > > > knows what a good solution looks like? I don't think so. > > > > There are many people in the Linux community who have ACPI experience. > > They may not be active on the ARM side, but it's not fair to say there > > are no known best practices. I will agree that for the level of > > variation we're likely to expect we are pushing the boundaries. > > We are pushing a lot of boundaries and doing things on ACPI that have > never been done before. SPI, GPIOs, Clocks, Regulators, composite > devices, key-value properties. All brand new territory, and the Linux > world is driving a lot of it. This is a bit of a surprise and a significant concern. The whole point behind ACPI is that it's supposed to abstract away nearly all of that, and _not_ expose clocks, regulators and other things to the kernel. If we're going to expose it, then we might as well go all the way and do it with DT. Exposing all the low-level details of the platform is very much an embedded mindset today. Servers don't do it with DT, nor with ACPI today. So if you're going to build a platform for servers that is modelled after what's done successfully so far, then sticking to that basic concept seems like an appropriate thing to do. > > > So, until there's strong evidence that ACPI is actually going to be > > > a sane solution, in other words, until someone has shipped a system > > > that uses it (with Windows) and does it successfully without being > > > a hot mess, we shouldn't litter the kernel with it. > > > > Again, I'm not sure that we should rely on Windows as our saviour from > > insanity. A lot of the issues we are going to encounter are going to be > > in vendor-specific code (i.e. drivers), and I do not believe that is > > solved by having a single entity in charge of the general frameworks > > those are built upon. > > Personally, I think the issue of ACPI support should be taken on a > patch-by-patch basis. A lot of the things that need to be done are quite > discrete and fairly well contained. If the patches don't look that way > then push back on them. For the parts that look ready, go ahead and > merge it. Push back on the ones that don't. The additional abstractions that are now pushed onto us has impact for everybody, and will cause churn on a lot of drivers. Things such as moving to named resources, etc. While it's easy to say "let's take the patches one by one", that also means nobody keeps an eye on the bigger picture and whether the whole thing makes sense or not. So, I think we need both. Of course we're going to review patches as they're posted (the alternative doesn't make sense). But we also need to know what the end goal is. Nobody is presenting that today, and until we know how steep the slippery slope will get (based on what we can see so far), we shouldn't start down it. -Olof -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org More majordomo info at http://vger.kernel.org/majordomo-info.html ^ permalink raw reply [flat|nested] 186+ messages in thread
* ACPI vs DT at runtime @ 2013-11-21 17:58 ` Olof Johansson 0 siblings, 0 replies; 186+ messages in thread From: Olof Johansson @ 2013-11-21 17:58 UTC (permalink / raw) To: linux-arm-kernel On Thu, Nov 21, 2013 at 04:29:44PM +0000, Grant Likely wrote: > On Tue, 19 Nov 2013 11:30:15 +0000, Mark Rutland <mark.rutland@arm.com> wrote: > > On Fri, Nov 15, 2013 at 05:52:41PM +0000, Olof Johansson wrote: > > On Fri, Nov 15, 2013 at 09:57:17AM +0000, Mark Rutland wrote: > > > > On Fri, Nov 15, 2013 at 01:44:10AM +0000, Olof Johansson wrote: > > The UEFI spec pulls in portions of ACPI. I do not know the full extent > > of the interaction between the two, but I know that they are not > > completely decoupled. As you have pointed out we are not experienced > > with ACPI or UEFI, so I don't think we can make statements that one is > > perfectly fine without the other. > > Not actually. The UEFI spec does define how to pass ACPI, but it can > boot the system without any ACPI at all. Merging UEFI support should > pretty much be a non-issue. > > > > > I think that trying to shoe-horn ACPI-derived information into device > > > > tree is fundamentally the wrong approach. I don't think it encourages > > > > best practices, and I don't think it's beneficial to the long term > > > > health of Linux or the ecosystem as a whole. > > > > > > There are no known best practices with ACPI. It's a complete fumbling > > > around in the dark right now. We're complaining about reviewer bandwith > > > on DT -- do we have a single reviewer for ACPI on ARM that actually > > > knows what a good solution looks like? I don't think so. > > > > There are many people in the Linux community who have ACPI experience. > > They may not be active on the ARM side, but it's not fair to say there > > are no known best practices. I will agree that for the level of > > variation we're likely to expect we are pushing the boundaries. > > We are pushing a lot of boundaries and doing things on ACPI that have > never been done before. SPI, GPIOs, Clocks, Regulators, composite > devices, key-value properties. All brand new territory, and the Linux > world is driving a lot of it. This is a bit of a surprise and a significant concern. The whole point behind ACPI is that it's supposed to abstract away nearly all of that, and _not_ expose clocks, regulators and other things to the kernel. If we're going to expose it, then we might as well go all the way and do it with DT. Exposing all the low-level details of the platform is very much an embedded mindset today. Servers don't do it with DT, nor with ACPI today. So if you're going to build a platform for servers that is modelled after what's done successfully so far, then sticking to that basic concept seems like an appropriate thing to do. > > > So, until there's strong evidence that ACPI is actually going to be > > > a sane solution, in other words, until someone has shipped a system > > > that uses it (with Windows) and does it successfully without being > > > a hot mess, we shouldn't litter the kernel with it. > > > > Again, I'm not sure that we should rely on Windows as our saviour from > > insanity. A lot of the issues we are going to encounter are going to be > > in vendor-specific code (i.e. drivers), and I do not believe that is > > solved by having a single entity in charge of the general frameworks > > those are built upon. > > Personally, I think the issue of ACPI support should be taken on a > patch-by-patch basis. A lot of the things that need to be done are quite > discrete and fairly well contained. If the patches don't look that way > then push back on them. For the parts that look ready, go ahead and > merge it. Push back on the ones that don't. The additional abstractions that are now pushed onto us has impact for everybody, and will cause churn on a lot of drivers. Things such as moving to named resources, etc. While it's easy to say "let's take the patches one by one", that also means nobody keeps an eye on the bigger picture and whether the whole thing makes sense or not. So, I think we need both. Of course we're going to review patches as they're posted (the alternative doesn't make sense). But we also need to know what the end goal is. Nobody is presenting that today, and until we know how steep the slippery slope will get (based on what we can see so far), we shouldn't start down it. -Olof ^ permalink raw reply [flat|nested] 186+ messages in thread
[parent not found: <20131121175822.GA9590-O5ziIzlqnXUVNXGz7ipsyg@public.gmane.org>]
* Re: ACPI vs DT at runtime 2013-11-21 17:58 ` Olof Johansson @ 2013-11-21 18:19 ` Matthew Garrett -1 siblings, 0 replies; 186+ messages in thread From: Matthew Garrett @ 2013-11-21 18:19 UTC (permalink / raw) To: Olof Johansson Cc: Grant Likely, Mark Rutland, devicetree-u79uwXL29TY76Z2rM5mHXA, Arnd Bergmann, linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r On Thu, Nov 21, 2013 at 09:58:22AM -0800, Olof Johansson wrote: > On Thu, Nov 21, 2013 at 04:29:44PM +0000, Grant Likely wrote: > > We are pushing a lot of boundaries and doing things on ACPI that have > > never been done before. SPI, GPIOs, Clocks, Regulators, composite > > devices, key-value properties. All brand new territory, and the Linux > > world is driving a lot of it. > > This is a bit of a surprise and a significant concern. > > The whole point behind ACPI is that it's supposed to abstract away nearly > all of that, and _not_ expose clocks, regulators and other things to > the kernel. If we're going to expose it, then we might as well go all > the way and do it with DT. ACPI is able to ignore most of this because ACPI has (traditionally) been aimed at well-defined platforms. ACPI 5 adds some amount of support for GPIOs, but beyond that there's nothing in the spec that lets you expose this data. This is, obviously, a problem. The current solution is to add DT values to ACPI, allowing us to continue using ACPI for device discovery and allowing vendors to provide platform-specific ACPI methods. There's an argument that in that case you might as well just use DT for device discovery as well and skip ACPI entirely. I'm having trouble coming up with strong counterarguments. -- Matthew Garrett | mjg59-1xO5oi07KQx4cg9Nei1l7Q@public.gmane.org -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org More majordomo info at http://vger.kernel.org/majordomo-info.html ^ permalink raw reply [flat|nested] 186+ messages in thread
* ACPI vs DT at runtime @ 2013-11-21 18:19 ` Matthew Garrett 0 siblings, 0 replies; 186+ messages in thread From: Matthew Garrett @ 2013-11-21 18:19 UTC (permalink / raw) To: linux-arm-kernel On Thu, Nov 21, 2013 at 09:58:22AM -0800, Olof Johansson wrote: > On Thu, Nov 21, 2013 at 04:29:44PM +0000, Grant Likely wrote: > > We are pushing a lot of boundaries and doing things on ACPI that have > > never been done before. SPI, GPIOs, Clocks, Regulators, composite > > devices, key-value properties. All brand new territory, and the Linux > > world is driving a lot of it. > > This is a bit of a surprise and a significant concern. > > The whole point behind ACPI is that it's supposed to abstract away nearly > all of that, and _not_ expose clocks, regulators and other things to > the kernel. If we're going to expose it, then we might as well go all > the way and do it with DT. ACPI is able to ignore most of this because ACPI has (traditionally) been aimed at well-defined platforms. ACPI 5 adds some amount of support for GPIOs, but beyond that there's nothing in the spec that lets you expose this data. This is, obviously, a problem. The current solution is to add DT values to ACPI, allowing us to continue using ACPI for device discovery and allowing vendors to provide platform-specific ACPI methods. There's an argument that in that case you might as well just use DT for device discovery as well and skip ACPI entirely. I'm having trouble coming up with strong counterarguments. -- Matthew Garrett | mjg59 at srcf.ucam.org ^ permalink raw reply [flat|nested] 186+ messages in thread
* Re: ACPI vs DT at runtime 2013-11-21 17:58 ` Olof Johansson @ 2013-11-21 18:33 ` Arnd Bergmann -1 siblings, 0 replies; 186+ messages in thread From: Arnd Bergmann @ 2013-11-21 18:33 UTC (permalink / raw) To: Olof Johansson Cc: Grant Likely, Mark Rutland, devicetree-u79uwXL29TY76Z2rM5mHXA, linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r, Rob Herring On Thursday 21 November 2013, Olof Johansson wrote: > On Thu, Nov 21, 2013 at 04:29:44PM +0000, Grant Likely wrote: > > > We are pushing a lot of boundaries and doing things on ACPI that have > > never been done before. SPI, GPIOs, Clocks, Regulators, composite > > devices, key-value properties. All brand new territory, and the Linux > > world is driving a lot of it. > > This is a bit of a surprise and a significant concern. > > The whole point behind ACPI is that it's supposed to abstract away nearly > all of that, and not expose clocks, regulators and other things to > the kernel. If we're going to expose it, then we might as well go all > the way and do it with DT. I think you are talking about different things here: Grant's example was about embedded x86 adding these so they can reuse the kernel infrastructure we already have without changing their entire firmware, which I think is fine, but he also said in the past that we wouldn't have that on PC-style ARM servers. Other people are pushing for that though (for SoC-style ARM servers I suppose), as Russell mentioned earlier. Arnd -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org More majordomo info at http://vger.kernel.org/majordomo-info.html ^ permalink raw reply [flat|nested] 186+ messages in thread
* ACPI vs DT at runtime @ 2013-11-21 18:33 ` Arnd Bergmann 0 siblings, 0 replies; 186+ messages in thread From: Arnd Bergmann @ 2013-11-21 18:33 UTC (permalink / raw) To: linux-arm-kernel On Thursday 21 November 2013, Olof Johansson wrote: > On Thu, Nov 21, 2013 at 04:29:44PM +0000, Grant Likely wrote: > > > We are pushing a lot of boundaries and doing things on ACPI that have > > never been done before. SPI, GPIOs, Clocks, Regulators, composite > > devices, key-value properties. All brand new territory, and the Linux > > world is driving a lot of it. > > This is a bit of a surprise and a significant concern. > > The whole point behind ACPI is that it's supposed to abstract away nearly > all of that, and not expose clocks, regulators and other things to > the kernel. If we're going to expose it, then we might as well go all > the way and do it with DT. I think you are talking about different things here: Grant's example was about embedded x86 adding these so they can reuse the kernel infrastructure we already have without changing their entire firmware, which I think is fine, but he also said in the past that we wouldn't have that on PC-style ARM servers. Other people are pushing for that though (for SoC-style ARM servers I suppose), as Russell mentioned earlier. Arnd ^ permalink raw reply [flat|nested] 186+ messages in thread
* Re: ACPI vs DT at runtime 2013-11-21 17:58 ` Olof Johansson @ 2013-11-21 18:54 ` Russell King - ARM Linux -1 siblings, 0 replies; 186+ messages in thread From: Russell King - ARM Linux @ 2013-11-21 18:54 UTC (permalink / raw) To: Olof Johansson Cc: Grant Likely, Mark Rutland, devicetree-u79uwXL29TY76Z2rM5mHXA, Arnd Bergmann, linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r On Thu, Nov 21, 2013 at 09:58:22AM -0800, Olof Johansson wrote: > On Thu, Nov 21, 2013 at 04:29:44PM +0000, Grant Likely wrote: > > We are pushing a lot of boundaries and doing things on ACPI that have > > never been done before. SPI, GPIOs, Clocks, Regulators, composite > > devices, key-value properties. All brand new territory, and the Linux > > world is driving a lot of it. > > This is a bit of a surprise and a significant concern. > > The whole point behind ACPI is that it's supposed to abstract away nearly > all of that, and _not_ expose clocks, regulators and other things to > the kernel. If we're going to expose it, then we might as well go all > the way and do it with DT. This depends what you want from ACPI, and what market ACPI is being targetted at. If ACPI is targetted at the embedded end, then having that information is fundamental to good power management (think about it - if you're doing hard power management where you need to turn on a clock from IRQ context, can you do that by running some AML code from that context?) If ACPI is targetted at just the server end, then at the moment it's probably not something that's required, because fine-grained power management isn't found on such platforms. However, that could very well change - we are in a world where we've had the golden years of cheap energy, and energy costs are going to go one way and one way only - so for the server market, power management to the same extent that we see in the embedded world will eventually transition over into that market too. At that point, the OS is probably going to have to know these kinds of details so it can do fine grained power management from tricky contexts... or we'll be running native code fragments provided by the vendor to do that... -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org More majordomo info at http://vger.kernel.org/majordomo-info.html ^ permalink raw reply [flat|nested] 186+ messages in thread
* ACPI vs DT at runtime @ 2013-11-21 18:54 ` Russell King - ARM Linux 0 siblings, 0 replies; 186+ messages in thread From: Russell King - ARM Linux @ 2013-11-21 18:54 UTC (permalink / raw) To: linux-arm-kernel On Thu, Nov 21, 2013 at 09:58:22AM -0800, Olof Johansson wrote: > On Thu, Nov 21, 2013 at 04:29:44PM +0000, Grant Likely wrote: > > We are pushing a lot of boundaries and doing things on ACPI that have > > never been done before. SPI, GPIOs, Clocks, Regulators, composite > > devices, key-value properties. All brand new territory, and the Linux > > world is driving a lot of it. > > This is a bit of a surprise and a significant concern. > > The whole point behind ACPI is that it's supposed to abstract away nearly > all of that, and _not_ expose clocks, regulators and other things to > the kernel. If we're going to expose it, then we might as well go all > the way and do it with DT. This depends what you want from ACPI, and what market ACPI is being targetted at. If ACPI is targetted at the embedded end, then having that information is fundamental to good power management (think about it - if you're doing hard power management where you need to turn on a clock from IRQ context, can you do that by running some AML code from that context?) If ACPI is targetted at just the server end, then at the moment it's probably not something that's required, because fine-grained power management isn't found on such platforms. However, that could very well change - we are in a world where we've had the golden years of cheap energy, and energy costs are going to go one way and one way only - so for the server market, power management to the same extent that we see in the embedded world will eventually transition over into that market too. At that point, the OS is probably going to have to know these kinds of details so it can do fine grained power management from tricky contexts... or we'll be running native code fragments provided by the vendor to do that... ^ permalink raw reply [flat|nested] 186+ messages in thread
[parent not found: <20131121185408.GX16735-l+eeeJia6m9vn6HldHNs0ANdhmdF6hFW@public.gmane.org>]
* Re: ACPI vs DT at runtime 2013-11-21 18:54 ` Russell King - ARM Linux @ 2013-11-21 18:59 ` Olof Johansson -1 siblings, 0 replies; 186+ messages in thread From: Olof Johansson @ 2013-11-21 18:59 UTC (permalink / raw) To: Russell King - ARM Linux Cc: Grant Likely, Mark Rutland, devicetree-u79uwXL29TY76Z2rM5mHXA, Arnd Bergmann, linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r On Thu, Nov 21, 2013 at 10:54 AM, Russell King - ARM Linux <linux-lFZ/pmaqli7XmaaqVzeoHQ@public.gmane.org> wrote: > On Thu, Nov 21, 2013 at 09:58:22AM -0800, Olof Johansson wrote: >> On Thu, Nov 21, 2013 at 04:29:44PM +0000, Grant Likely wrote: >> > We are pushing a lot of boundaries and doing things on ACPI that have >> > never been done before. SPI, GPIOs, Clocks, Regulators, composite >> > devices, key-value properties. All brand new territory, and the Linux >> > world is driving a lot of it. >> >> This is a bit of a surprise and a significant concern. >> >> The whole point behind ACPI is that it's supposed to abstract away nearly >> all of that, and _not_ expose clocks, regulators and other things to >> the kernel. If we're going to expose it, then we might as well go all >> the way and do it with DT. > > This depends what you want from ACPI, and what market ACPI is being > targetted at. We're talking ACPI on servers here. -Olof -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org More majordomo info at http://vger.kernel.org/majordomo-info.html ^ permalink raw reply [flat|nested] 186+ messages in thread
* ACPI vs DT at runtime @ 2013-11-21 18:59 ` Olof Johansson 0 siblings, 0 replies; 186+ messages in thread From: Olof Johansson @ 2013-11-21 18:59 UTC (permalink / raw) To: linux-arm-kernel On Thu, Nov 21, 2013 at 10:54 AM, Russell King - ARM Linux <linux@arm.linux.org.uk> wrote: > On Thu, Nov 21, 2013 at 09:58:22AM -0800, Olof Johansson wrote: >> On Thu, Nov 21, 2013 at 04:29:44PM +0000, Grant Likely wrote: >> > We are pushing a lot of boundaries and doing things on ACPI that have >> > never been done before. SPI, GPIOs, Clocks, Regulators, composite >> > devices, key-value properties. All brand new territory, and the Linux >> > world is driving a lot of it. >> >> This is a bit of a surprise and a significant concern. >> >> The whole point behind ACPI is that it's supposed to abstract away nearly >> all of that, and _not_ expose clocks, regulators and other things to >> the kernel. If we're going to expose it, then we might as well go all >> the way and do it with DT. > > This depends what you want from ACPI, and what market ACPI is being > targetted at. We're talking ACPI on servers here. -Olof ^ permalink raw reply [flat|nested] 186+ messages in thread
[parent not found: <CAOesGMgzUSMDy99XojipfRd5OM88UhfbCYO0aoc5m-Q8Fwnddg-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>]
* Re: ACPI vs DT at runtime 2013-11-21 18:59 ` Olof Johansson @ 2013-11-21 19:01 ` Russell King - ARM Linux -1 siblings, 0 replies; 186+ messages in thread From: Russell King - ARM Linux @ 2013-11-21 19:01 UTC (permalink / raw) To: Olof Johansson Cc: Grant Likely, Mark Rutland, devicetree-u79uwXL29TY76Z2rM5mHXA, Arnd Bergmann, linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r On Thu, Nov 21, 2013 at 10:59:41AM -0800, Olof Johansson wrote: > On Thu, Nov 21, 2013 at 10:54 AM, Russell King - ARM Linux > <linux-lFZ/pmaqli7XmaaqVzeoHQ@public.gmane.org> wrote: > > This depends what you want from ACPI, and what market ACPI is being > > targetted at. > > We're talking ACPI on servers here. Now read the rest of my email, thanks. -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org More majordomo info at http://vger.kernel.org/majordomo-info.html ^ permalink raw reply [flat|nested] 186+ messages in thread
* ACPI vs DT at runtime @ 2013-11-21 19:01 ` Russell King - ARM Linux 0 siblings, 0 replies; 186+ messages in thread From: Russell King - ARM Linux @ 2013-11-21 19:01 UTC (permalink / raw) To: linux-arm-kernel On Thu, Nov 21, 2013 at 10:59:41AM -0800, Olof Johansson wrote: > On Thu, Nov 21, 2013 at 10:54 AM, Russell King - ARM Linux > <linux@arm.linux.org.uk> wrote: > > This depends what you want from ACPI, and what market ACPI is being > > targetted at. > > We're talking ACPI on servers here. Now read the rest of my email, thanks. ^ permalink raw reply [flat|nested] 186+ messages in thread
[parent not found: <20131121190126.GZ16735-l+eeeJia6m9vn6HldHNs0ANdhmdF6hFW@public.gmane.org>]
* Re: ACPI vs DT at runtime 2013-11-21 19:01 ` Russell King - ARM Linux @ 2013-11-21 19:31 ` Olof Johansson -1 siblings, 0 replies; 186+ messages in thread From: Olof Johansson @ 2013-11-21 19:31 UTC (permalink / raw) To: Russell King - ARM Linux Cc: Grant Likely, Mark Rutland, devicetree-u79uwXL29TY76Z2rM5mHXA, Arnd Bergmann, linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r On Thu, Nov 21, 2013 at 11:01 AM, Russell King - ARM Linux <linux-lFZ/pmaqli7XmaaqVzeoHQ@public.gmane.org> wrote: > On Thu, Nov 21, 2013 at 10:59:41AM -0800, Olof Johansson wrote: >> On Thu, Nov 21, 2013 at 10:54 AM, Russell King - ARM Linux >> <linux-lFZ/pmaqli7XmaaqVzeoHQ@public.gmane.org> wrote: >> > This depends what you want from ACPI, and what market ACPI is being >> > targetted at. >> >> We're talking ACPI on servers here. > > Now read the rest of my email, thanks. Yes, there are use cases for ACPI on embedded, which is what Intel is getting into and the standard is changing accordingly. On embedded ARM we're quite comfortable with DT for now, so it doesn't make sense to consider ACPI there just for the sake of it, as far as I am concerned. And, on servers, using the embedded-targeted bindings that expose all hardware details (and leaving implementation to the kernel) seems counter to the main target of forwards- and backwards compatibility. That can only really be achieved by getting rid of hardware diversity and reaching standardized hardware platforms with discoverable devices. Keeping the complex parts of power management out of the kernel on those platforms is going to be important too. -Olof -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org More majordomo info at http://vger.kernel.org/majordomo-info.html ^ permalink raw reply [flat|nested] 186+ messages in thread
* ACPI vs DT at runtime @ 2013-11-21 19:31 ` Olof Johansson 0 siblings, 0 replies; 186+ messages in thread From: Olof Johansson @ 2013-11-21 19:31 UTC (permalink / raw) To: linux-arm-kernel On Thu, Nov 21, 2013 at 11:01 AM, Russell King - ARM Linux <linux@arm.linux.org.uk> wrote: > On Thu, Nov 21, 2013 at 10:59:41AM -0800, Olof Johansson wrote: >> On Thu, Nov 21, 2013 at 10:54 AM, Russell King - ARM Linux >> <linux@arm.linux.org.uk> wrote: >> > This depends what you want from ACPI, and what market ACPI is being >> > targetted at. >> >> We're talking ACPI on servers here. > > Now read the rest of my email, thanks. Yes, there are use cases for ACPI on embedded, which is what Intel is getting into and the standard is changing accordingly. On embedded ARM we're quite comfortable with DT for now, so it doesn't make sense to consider ACPI there just for the sake of it, as far as I am concerned. And, on servers, using the embedded-targeted bindings that expose all hardware details (and leaving implementation to the kernel) seems counter to the main target of forwards- and backwards compatibility. That can only really be achieved by getting rid of hardware diversity and reaching standardized hardware platforms with discoverable devices. Keeping the complex parts of power management out of the kernel on those platforms is going to be important too. -Olof ^ permalink raw reply [flat|nested] 186+ messages in thread
[parent not found: < CAOesGMgzUSMDy99XojipfRd5OM88UhfbCYO0aoc5m-Q8Fwnddg@mail.gmail.com>]
[parent not found: < 20131121190126.GZ16735@n2100.arm.linux.org.uk>]
[parent not found: < CAOesGMgxGq1Zmo+Dq-Rmy2F02-=12yUzB0AKn35yK2j3CacNRQ@mail.gmail.com>]
[parent not found: <CAOesGMgxGq1Zmo+Dq-Rmy2F02-=12yUzB0AKn35yK2j3CacNRQ-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>]
* Re: ACPI vs DT at runtime 2013-11-21 19:31 ` Olof Johansson @ 2013-11-21 20:44 ` Grant Likely -1 siblings, 0 replies; 186+ messages in thread From: Grant Likely @ 2013-11-21 20:44 UTC (permalink / raw) To: Olof Johansson, Russell King - ARM Linux Cc: Mark Rutland, devicetree-u79uwXL29TY76Z2rM5mHXA, Arnd Bergmann, linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r On Thu, 21 Nov 2013 11:31:10 -0800, Olof Johansson <olof-nZhT3qVonbNeoWH0uzbU5w@public.gmane.org> wrote: > On Thu, Nov 21, 2013 at 11:01 AM, Russell King - ARM Linux > <linux-lFZ/pmaqli7XmaaqVzeoHQ@public.gmane.org> wrote: > > On Thu, Nov 21, 2013 at 10:59:41AM -0800, Olof Johansson wrote: > >> On Thu, Nov 21, 2013 at 10:54 AM, Russell King - ARM Linux > >> <linux-lFZ/pmaqli7XmaaqVzeoHQ@public.gmane.org> wrote: > >> > This depends what you want from ACPI, and what market ACPI is being > >> > targetted at. > >> > >> We're talking ACPI on servers here. > > > > Now read the rest of my email, thanks. > > Yes, there are use cases for ACPI on embedded, which is what Intel is > getting into and the standard is changing accordingly. On embedded ARM > we're quite comfortable with DT for now, so it doesn't make sense to > consider ACPI there just for the sake of it, as far as I am concerned. > > And, on servers, using the embedded-targeted bindings that expose all > hardware details (and leaving implementation to the kernel) seems > counter to the main target of forwards- and backwards compatibility. > That can only really be achieved by getting rid of hardware diversity > and reaching standardized hardware platforms with discoverable > devices. Keeping the complex parts of power management out of the > kernel on those platforms is going to be important too. That is something that can definitely push back on. We've got the collision of what have we been required to do for embedded SoCs with technology designed for systems that aren't quite as much "fun". The ACPI team has been investigating what is needed to port existing device drivers to use ACPI bindings, but it is resonable to say that clocks and regulators (for example) have no business being described in the ACPI tree. g. -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org More majordomo info at http://vger.kernel.org/majordomo-info.html ^ permalink raw reply [flat|nested] 186+ messages in thread
* ACPI vs DT at runtime @ 2013-11-21 20:44 ` Grant Likely 0 siblings, 0 replies; 186+ messages in thread From: Grant Likely @ 2013-11-21 20:44 UTC (permalink / raw) To: linux-arm-kernel On Thu, 21 Nov 2013 11:31:10 -0800, Olof Johansson <olof@lixom.net> wrote: > On Thu, Nov 21, 2013 at 11:01 AM, Russell King - ARM Linux > <linux@arm.linux.org.uk> wrote: > > On Thu, Nov 21, 2013 at 10:59:41AM -0800, Olof Johansson wrote: > >> On Thu, Nov 21, 2013 at 10:54 AM, Russell King - ARM Linux > >> <linux@arm.linux.org.uk> wrote: > >> > This depends what you want from ACPI, and what market ACPI is being > >> > targetted at. > >> > >> We're talking ACPI on servers here. > > > > Now read the rest of my email, thanks. > > Yes, there are use cases for ACPI on embedded, which is what Intel is > getting into and the standard is changing accordingly. On embedded ARM > we're quite comfortable with DT for now, so it doesn't make sense to > consider ACPI there just for the sake of it, as far as I am concerned. > > And, on servers, using the embedded-targeted bindings that expose all > hardware details (and leaving implementation to the kernel) seems > counter to the main target of forwards- and backwards compatibility. > That can only really be achieved by getting rid of hardware diversity > and reaching standardized hardware platforms with discoverable > devices. Keeping the complex parts of power management out of the > kernel on those platforms is going to be important too. That is something that can definitely push back on. We've got the collision of what have we been required to do for embedded SoCs with technology designed for systems that aren't quite as much "fun". The ACPI team has been investigating what is needed to port existing device drivers to use ACPI bindings, but it is resonable to say that clocks and regulators (for example) have no business being described in the ACPI tree. g. ^ permalink raw reply [flat|nested] 186+ messages in thread
* Re: ACPI vs DT at runtime 2013-11-21 16:29 ` Grant Likely @ 2013-11-21 18:53 ` Mark Brown -1 siblings, 0 replies; 186+ messages in thread From: Mark Brown @ 2013-11-21 18:53 UTC (permalink / raw) To: Grant Likely Cc: Mark Rutland, Olof Johansson, devicetree-u79uwXL29TY76Z2rM5mHXA, Arnd Bergmann, linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r [-- Attachment #1: Type: text/plain, Size: 954 bytes --] On Thu, Nov 21, 2013 at 04:29:44PM +0000, Grant Likely wrote: > We are pushing a lot of boundaries and doing things on ACPI that have > never been done before. SPI, GPIOs, Clocks, Regulators, composite > devices, key-value properties. All brand new territory, and the Linux > world is driving a lot of it. Indeed, and at a subsystem and platform independent driver level we do have the x86 embedded platforms working with ACPI right now so Linux is going to need to cope with some of this regardless of what people end up doing for ARM servers - Intel are sending me patches for ACPI support in ASoC for example. > Personally, I think the issue of ACPI support should be taken on a > patch-by-patch basis. A lot of the things that need to be done are quite > discrete and fairly well contained. If the patches don't look that way > then push back on them. For the parts that look ready, go ahead and > merge it. Push back on the ones that don't. +1. [-- Attachment #2: Digital signature --] [-- Type: application/pgp-signature, Size: 836 bytes --] ^ permalink raw reply [flat|nested] 186+ messages in thread
* ACPI vs DT at runtime @ 2013-11-21 18:53 ` Mark Brown 0 siblings, 0 replies; 186+ messages in thread From: Mark Brown @ 2013-11-21 18:53 UTC (permalink / raw) To: linux-arm-kernel On Thu, Nov 21, 2013 at 04:29:44PM +0000, Grant Likely wrote: > We are pushing a lot of boundaries and doing things on ACPI that have > never been done before. SPI, GPIOs, Clocks, Regulators, composite > devices, key-value properties. All brand new territory, and the Linux > world is driving a lot of it. Indeed, and at a subsystem and platform independent driver level we do have the x86 embedded platforms working with ACPI right now so Linux is going to need to cope with some of this regardless of what people end up doing for ARM servers - Intel are sending me patches for ACPI support in ASoC for example. > Personally, I think the issue of ACPI support should be taken on a > patch-by-patch basis. A lot of the things that need to be done are quite > discrete and fairly well contained. If the patches don't look that way > then push back on them. For the parts that look ready, go ahead and > merge it. Push back on the ones that don't. +1. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 836 bytes Desc: Digital signature URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20131121/1285621f/attachment.sig> ^ permalink raw reply [flat|nested] 186+ messages in thread
* Re: ACPI vs DT at runtime 2013-11-15 9:57 ` Mark Rutland @ 2013-11-15 18:28 ` Jason Gunthorpe -1 siblings, 0 replies; 186+ messages in thread From: Jason Gunthorpe @ 2013-11-15 18:28 UTC (permalink / raw) To: Mark Rutland Cc: Olof Johansson, Grant Likely, devicetree-u79uwXL29TY76Z2rM5mHXA, Arnd Bergmann, linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r On Fri, Nov 15, 2013 at 09:57:17AM +0000, Mark Rutland wrote: > first-class citizen. We don't need to modify every driver and subsystem > to support ACPI, only those necessary to support the minimal set of > platforms using ACPI. ACPI is new in the arm space, and we can enforce > quality standards on ACPI _now_ above what we're allowing for DT, and > avoid future problems. I think to replicate the kind of 'success' ACPI sees in x86-land you really need to push back on the HW folks and limit what drivers will be supported on ACPI systems. ACPI should be coupled with a standard basic HW environment - analogous to the stable APIC, PCI and HPET standards we have in x86. (ARMv8 only?) Other essential devices (ethernet, graphics, etc) should fit within the PCI framework. Again, mostly like x86. If you don't fit in that model then use DT. If you need the kernel to control clk, pinctrl, regulator, etc then you should be using DT. If you need a special one-off HW driver to boot to a console then you should be using DT ;) DT is here, it is working, it seems viable to set a strong goal for ACPI and shift everything else to DT: ACPI systems should have the broad compatability we see in x86. New hardware bought today should still boot a 3 year old OS. Jason -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org More majordomo info at http://vger.kernel.org/majordomo-info.html ^ permalink raw reply [flat|nested] 186+ messages in thread
* ACPI vs DT at runtime @ 2013-11-15 18:28 ` Jason Gunthorpe 0 siblings, 0 replies; 186+ messages in thread From: Jason Gunthorpe @ 2013-11-15 18:28 UTC (permalink / raw) To: linux-arm-kernel On Fri, Nov 15, 2013 at 09:57:17AM +0000, Mark Rutland wrote: > first-class citizen. We don't need to modify every driver and subsystem > to support ACPI, only those necessary to support the minimal set of > platforms using ACPI. ACPI is new in the arm space, and we can enforce > quality standards on ACPI _now_ above what we're allowing for DT, and > avoid future problems. I think to replicate the kind of 'success' ACPI sees in x86-land you really need to push back on the HW folks and limit what drivers will be supported on ACPI systems. ACPI should be coupled with a standard basic HW environment - analogous to the stable APIC, PCI and HPET standards we have in x86. (ARMv8 only?) Other essential devices (ethernet, graphics, etc) should fit within the PCI framework. Again, mostly like x86. If you don't fit in that model then use DT. If you need the kernel to control clk, pinctrl, regulator, etc then you should be using DT. If you need a special one-off HW driver to boot to a console then you should be using DT ;) DT is here, it is working, it seems viable to set a strong goal for ACPI and shift everything else to DT: ACPI systems should have the broad compatability we see in x86. New hardware bought today should still boot a 3 year old OS. Jason ^ permalink raw reply [flat|nested] 186+ messages in thread
[parent not found: <20131115182826.GB14920-ePGOBjL8dl3ta4EC/59zMFaTQe2KTcn/@public.gmane.org>]
* Re: ACPI vs DT at runtime 2013-11-15 18:28 ` Jason Gunthorpe @ 2013-11-15 18:57 ` Arnd Bergmann -1 siblings, 0 replies; 186+ messages in thread From: Arnd Bergmann @ 2013-11-15 18:57 UTC (permalink / raw) To: Jason Gunthorpe Cc: Mark Rutland, Olof Johansson, Grant Likely, devicetree-u79uwXL29TY76Z2rM5mHXA, linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r On Friday 15 November 2013, Jason Gunthorpe wrote: > > On Fri, Nov 15, 2013 at 09:57:17AM +0000, Mark Rutland wrote: > > > first-class citizen. We don't need to modify every driver and subsystem > > to support ACPI, only those necessary to support the minimal set of > > platforms using ACPI. ACPI is new in the arm space, and we can enforce > > quality standards on ACPI now above what we're allowing for DT, and > > avoid future problems. > > I think to replicate the kind of 'success' ACPI sees in x86-land you > really need to push back on the HW folks and limit what drivers will > be supported on ACPI systems. > > ACPI should be coupled with a standard basic HW environment - > analogous to the stable APIC, PCI and HPET standards we have in > x86. (ARMv8 only?) timers and interrupts are pretty much standardized in ARMv8 and in SMP-capable ARMv7 systems now, it's really the PCI argument that matters here. Even on Intel's embedded SoCs, the integrated peripherals tend to be shown to software as standalone PCI devices that don't need to talk to another internal device to set up DMA, clocks, pinmux etc. > Other essential devices (ethernet, graphics, etc) should fit within > the PCI framework. Again, mostly like x86. > > If you don't fit in that model then use DT. > > If you need the kernel to control clk, pinctrl, regulator, etc then > you should be using DT. Exactly. Arnd -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org More majordomo info at http://vger.kernel.org/majordomo-info.html ^ permalink raw reply [flat|nested] 186+ messages in thread
* ACPI vs DT at runtime @ 2013-11-15 18:57 ` Arnd Bergmann 0 siblings, 0 replies; 186+ messages in thread From: Arnd Bergmann @ 2013-11-15 18:57 UTC (permalink / raw) To: linux-arm-kernel On Friday 15 November 2013, Jason Gunthorpe wrote: > > On Fri, Nov 15, 2013 at 09:57:17AM +0000, Mark Rutland wrote: > > > first-class citizen. We don't need to modify every driver and subsystem > > to support ACPI, only those necessary to support the minimal set of > > platforms using ACPI. ACPI is new in the arm space, and we can enforce > > quality standards on ACPI now above what we're allowing for DT, and > > avoid future problems. > > I think to replicate the kind of 'success' ACPI sees in x86-land you > really need to push back on the HW folks and limit what drivers will > be supported on ACPI systems. > > ACPI should be coupled with a standard basic HW environment - > analogous to the stable APIC, PCI and HPET standards we have in > x86. (ARMv8 only?) timers and interrupts are pretty much standardized in ARMv8 and in SMP-capable ARMv7 systems now, it's really the PCI argument that matters here. Even on Intel's embedded SoCs, the integrated peripherals tend to be shown to software as standalone PCI devices that don't need to talk to another internal device to set up DMA, clocks, pinmux etc. > Other essential devices (ethernet, graphics, etc) should fit within > the PCI framework. Again, mostly like x86. > > If you don't fit in that model then use DT. > > If you need the kernel to control clk, pinctrl, regulator, etc then > you should be using DT. Exactly. Arnd ^ permalink raw reply [flat|nested] 186+ messages in thread
* Re: ACPI vs DT at runtime 2013-11-15 9:57 ` Mark Rutland @ 2013-11-20 13:49 ` Grant Likely -1 siblings, 0 replies; 186+ messages in thread From: Grant Likely @ 2013-11-20 13:49 UTC (permalink / raw) To: Mark Rutland, Olof Johansson Cc: devicetree-u79uwXL29TY76Z2rM5mHXA, linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r, Rob Herring, Arnd Bergmann On Fri, 15 Nov 2013 09:57:17 +0000, Mark Rutland <mark.rutland-5wv7dgnIgG8@public.gmane.org> wrote: > On Fri, Nov 15, 2013 at 01:44:10AM +0000, Olof Johansson wrote: > > The more I start to see early UEFI/ACPI code, the more I am certain > > that we want none of that crap in the kernel. It's making things > > considerably messier, while we're already very busy trying to convert > > everything over and enable DT -- we'll be preempting that effort just > > to add even more boilerplate everywhere and total progress will be > > hurt. > > We are certainly under a lot of pressure with the device tree migration, > and I agree that adding another information source is going to be a > source of pain. However, I'd argue that we're going to encounter pain > regardless of which approach we take. > > I'm of the opinion that the only way we should support ACPI is as a > first-class citizen. We don't need to modify every driver and subsystem > to support ACPI, only those necessary to support the minimal set of > platforms using ACPI. ACPI is new in the arm space, and we can enforce > quality standards on ACPI _now_ above what we're allowing for DT, and > avoid future problems. Translated ACPI tables really don't make any sense at all. While the models are similar in some regards, they are very different in others and any translator (I suspect) would become very complicated to deal with all the edge cases. > I'm not sure that translating ACPI tables to dt makes any sense. If AML > is used (even sparingly), I do not believe that we can do any sensible > conversion to device tree. My understanding is that AML includes > functionality for modifying ACPI tables, and I don't see how we can > possibly support that without having to add a lot of boilerplate to all > the code handling AML to add a device tree backend... The dynamic features of AML would be a no-go. Basically, an AML method can cause SSDT blocks to be loaded/unloaded at runtime. It doesn't edit the tree provided at runtime, but it does augment it. g. -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org More majordomo info at http://vger.kernel.org/majordomo-info.html ^ permalink raw reply [flat|nested] 186+ messages in thread
* ACPI vs DT at runtime @ 2013-11-20 13:49 ` Grant Likely 0 siblings, 0 replies; 186+ messages in thread From: Grant Likely @ 2013-11-20 13:49 UTC (permalink / raw) To: linux-arm-kernel On Fri, 15 Nov 2013 09:57:17 +0000, Mark Rutland <mark.rutland@arm.com> wrote: > On Fri, Nov 15, 2013 at 01:44:10AM +0000, Olof Johansson wrote: > > The more I start to see early UEFI/ACPI code, the more I am certain > > that we want none of that crap in the kernel. It's making things > > considerably messier, while we're already very busy trying to convert > > everything over and enable DT -- we'll be preempting that effort just > > to add even more boilerplate everywhere and total progress will be > > hurt. > > We are certainly under a lot of pressure with the device tree migration, > and I agree that adding another information source is going to be a > source of pain. However, I'd argue that we're going to encounter pain > regardless of which approach we take. > > I'm of the opinion that the only way we should support ACPI is as a > first-class citizen. We don't need to modify every driver and subsystem > to support ACPI, only those necessary to support the minimal set of > platforms using ACPI. ACPI is new in the arm space, and we can enforce > quality standards on ACPI _now_ above what we're allowing for DT, and > avoid future problems. Translated ACPI tables really don't make any sense at all. While the models are similar in some regards, they are very different in others and any translator (I suspect) would become very complicated to deal with all the edge cases. > I'm not sure that translating ACPI tables to dt makes any sense. If AML > is used (even sparingly), I do not believe that we can do any sensible > conversion to device tree. My understanding is that AML includes > functionality for modifying ACPI tables, and I don't see how we can > possibly support that without having to add a lot of boilerplate to all > the code handling AML to add a device tree backend... The dynamic features of AML would be a no-go. Basically, an AML method can cause SSDT blocks to be loaded/unloaded at runtime. It doesn't edit the tree provided at runtime, but it does augment it. g. ^ permalink raw reply [flat|nested] 186+ messages in thread
[parent not found: <20131120134942.95DBFC4079D-WNowdnHR2B42iJbIjFUEsiwD8/FfD2ys@public.gmane.org>]
* Re: ACPI vs DT at runtime 2013-11-20 13:49 ` Grant Likely @ 2013-11-20 17:43 ` Stefano Stabellini -1 siblings, 0 replies; 186+ messages in thread From: Stefano Stabellini @ 2013-11-20 17:43 UTC (permalink / raw) To: Grant Likely Cc: Mark Rutland, Olof Johansson, devicetree-u79uwXL29TY76Z2rM5mHXA, Arnd Bergmann, linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r On Wed, 20 Nov 2013, Grant Likely wrote: > On Fri, 15 Nov 2013 09:57:17 +0000, Mark Rutland <mark.rutland-5wv7dgnIgG8@public.gmane.org> wrote: > > On Fri, Nov 15, 2013 at 01:44:10AM +0000, Olof Johansson wrote: > > > The more I start to see early UEFI/ACPI code, the more I am certain > > > that we want none of that crap in the kernel. It's making things > > > considerably messier, while we're already very busy trying to convert > > > everything over and enable DT -- we'll be preempting that effort just > > > to add even more boilerplate everywhere and total progress will be > > > hurt. > > > > We are certainly under a lot of pressure with the device tree migration, > > and I agree that adding another information source is going to be a > > source of pain. However, I'd argue that we're going to encounter pain > > regardless of which approach we take. > > > > I'm of the opinion that the only way we should support ACPI is as a > > first-class citizen. We don't need to modify every driver and subsystem > > to support ACPI, only those necessary to support the minimal set of > > platforms using ACPI. ACPI is new in the arm space, and we can enforce > > quality standards on ACPI _now_ above what we're allowing for DT, and > > avoid future problems. > > Translated ACPI tables really don't make any sense at all. While the > models are similar in some regards, they are very different in others > and any translator (I suspect) would become very complicated to deal > with all the edge cases. If it turns out that we can't translate the ACPI tables dynamically, we could maintain a repository of "manually" translated DTSes for all the systems that do not ship with device tree. Given that DTBs are fairly small, we could stick them all in an initrd or another binary loaded by the bootloader so that Linux and/or Xen can select the right one at boot time. -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org More majordomo info at http://vger.kernel.org/majordomo-info.html ^ permalink raw reply [flat|nested] 186+ messages in thread
* ACPI vs DT at runtime @ 2013-11-20 17:43 ` Stefano Stabellini 0 siblings, 0 replies; 186+ messages in thread From: Stefano Stabellini @ 2013-11-20 17:43 UTC (permalink / raw) To: linux-arm-kernel On Wed, 20 Nov 2013, Grant Likely wrote: > On Fri, 15 Nov 2013 09:57:17 +0000, Mark Rutland <mark.rutland@arm.com> wrote: > > On Fri, Nov 15, 2013 at 01:44:10AM +0000, Olof Johansson wrote: > > > The more I start to see early UEFI/ACPI code, the more I am certain > > > that we want none of that crap in the kernel. It's making things > > > considerably messier, while we're already very busy trying to convert > > > everything over and enable DT -- we'll be preempting that effort just > > > to add even more boilerplate everywhere and total progress will be > > > hurt. > > > > We are certainly under a lot of pressure with the device tree migration, > > and I agree that adding another information source is going to be a > > source of pain. However, I'd argue that we're going to encounter pain > > regardless of which approach we take. > > > > I'm of the opinion that the only way we should support ACPI is as a > > first-class citizen. We don't need to modify every driver and subsystem > > to support ACPI, only those necessary to support the minimal set of > > platforms using ACPI. ACPI is new in the arm space, and we can enforce > > quality standards on ACPI _now_ above what we're allowing for DT, and > > avoid future problems. > > Translated ACPI tables really don't make any sense at all. While the > models are similar in some regards, they are very different in others > and any translator (I suspect) would become very complicated to deal > with all the edge cases. If it turns out that we can't translate the ACPI tables dynamically, we could maintain a repository of "manually" translated DTSes for all the systems that do not ship with device tree. Given that DTBs are fairly small, we could stick them all in an initrd or another binary loaded by the bootloader so that Linux and/or Xen can select the right one at boot time. ^ permalink raw reply [flat|nested] 186+ messages in thread
[parent not found: <alpine.DEB.2.02.1311201737410.3198-7Z66fg9igcxYtxbxJUhB2Dgeux46jI+i@public.gmane.org>]
* Re: ACPI vs DT at runtime 2013-11-20 17:43 ` Stefano Stabellini @ 2013-11-20 17:47 ` Olof Johansson -1 siblings, 0 replies; 186+ messages in thread From: Olof Johansson @ 2013-11-20 17:47 UTC (permalink / raw) To: Stefano Stabellini Cc: Grant Likely, Mark Rutland, devicetree-u79uwXL29TY76Z2rM5mHXA, Arnd Bergmann, linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r On Wed, Nov 20, 2013 at 9:43 AM, Stefano Stabellini <stefano.stabellini-mvvWK6WmYclDPfheJLI6IQ@public.gmane.org> wrote: > On Wed, 20 Nov 2013, Grant Likely wrote: >> On Fri, 15 Nov 2013 09:57:17 +0000, Mark Rutland <mark.rutland-5wv7dgnIgG8@public.gmane.org> wrote: >> > On Fri, Nov 15, 2013 at 01:44:10AM +0000, Olof Johansson wrote: >> > > The more I start to see early UEFI/ACPI code, the more I am certain >> > > that we want none of that crap in the kernel. It's making things >> > > considerably messier, while we're already very busy trying to convert >> > > everything over and enable DT -- we'll be preempting that effort just >> > > to add even more boilerplate everywhere and total progress will be >> > > hurt. >> > >> > We are certainly under a lot of pressure with the device tree migration, >> > and I agree that adding another information source is going to be a >> > source of pain. However, I'd argue that we're going to encounter pain >> > regardless of which approach we take. >> > >> > I'm of the opinion that the only way we should support ACPI is as a >> > first-class citizen. We don't need to modify every driver and subsystem >> > to support ACPI, only those necessary to support the minimal set of >> > platforms using ACPI. ACPI is new in the arm space, and we can enforce >> > quality standards on ACPI _now_ above what we're allowing for DT, and >> > avoid future problems. >> >> Translated ACPI tables really don't make any sense at all. While the >> models are similar in some regards, they are very different in others >> and any translator (I suspect) would become very complicated to deal >> with all the edge cases. > > If it turns out that we can't translate the ACPI tables dynamically, we > could maintain a repository of "manually" translated DTSes for all the > systems that do not ship with device tree. Given that DTBs are fairly > small, we could stick them all in an initrd or another binary loaded by > the bootloader so that Linux and/or Xen can select the right one at boot > time. There are many possible ways to solve this, and I think we'll have to wait and see how it ends up being used before we decide what to do. Again, it's better to let things settle out for a few generations instead of trying to support everything from the very beginning, given that we're expecting turmoil in this area. -Olof -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org More majordomo info at http://vger.kernel.org/majordomo-info.html ^ permalink raw reply [flat|nested] 186+ messages in thread
* ACPI vs DT at runtime @ 2013-11-20 17:47 ` Olof Johansson 0 siblings, 0 replies; 186+ messages in thread From: Olof Johansson @ 2013-11-20 17:47 UTC (permalink / raw) To: linux-arm-kernel On Wed, Nov 20, 2013 at 9:43 AM, Stefano Stabellini <stefano.stabellini@eu.citrix.com> wrote: > On Wed, 20 Nov 2013, Grant Likely wrote: >> On Fri, 15 Nov 2013 09:57:17 +0000, Mark Rutland <mark.rutland@arm.com> wrote: >> > On Fri, Nov 15, 2013 at 01:44:10AM +0000, Olof Johansson wrote: >> > > The more I start to see early UEFI/ACPI code, the more I am certain >> > > that we want none of that crap in the kernel. It's making things >> > > considerably messier, while we're already very busy trying to convert >> > > everything over and enable DT -- we'll be preempting that effort just >> > > to add even more boilerplate everywhere and total progress will be >> > > hurt. >> > >> > We are certainly under a lot of pressure with the device tree migration, >> > and I agree that adding another information source is going to be a >> > source of pain. However, I'd argue that we're going to encounter pain >> > regardless of which approach we take. >> > >> > I'm of the opinion that the only way we should support ACPI is as a >> > first-class citizen. We don't need to modify every driver and subsystem >> > to support ACPI, only those necessary to support the minimal set of >> > platforms using ACPI. ACPI is new in the arm space, and we can enforce >> > quality standards on ACPI _now_ above what we're allowing for DT, and >> > avoid future problems. >> >> Translated ACPI tables really don't make any sense at all. While the >> models are similar in some regards, they are very different in others >> and any translator (I suspect) would become very complicated to deal >> with all the edge cases. > > If it turns out that we can't translate the ACPI tables dynamically, we > could maintain a repository of "manually" translated DTSes for all the > systems that do not ship with device tree. Given that DTBs are fairly > small, we could stick them all in an initrd or another binary loaded by > the bootloader so that Linux and/or Xen can select the right one at boot > time. There are many possible ways to solve this, and I think we'll have to wait and see how it ends up being used before we decide what to do. Again, it's better to let things settle out for a few generations instead of trying to support everything from the very beginning, given that we're expecting turmoil in this area. -Olof ^ permalink raw reply [flat|nested] 186+ messages in thread
* ACPI vs DT at runtime 2013-11-15 9:57 ` Mark Rutland ` (2 preceding siblings ...) (?) @ 2013-11-18 5:19 ` Jon Masters 2013-11-18 5:26 ` Jon Masters ` (6 more replies) -1 siblings, 7 replies; 186+ messages in thread From: Jon Masters @ 2013-11-18 5:19 UTC (permalink / raw) To: linux-arm-kernel Olof, thanks for starting this thread. Mark, thanks for the followup. Comments on both inline, below. But before I reply to the specific points, let me add that this is clearly an emotional topic for many. There are a great many companies involved in ARMv8 on servers, and a great many have yet to say anything in public. I am trying to strike a balance constantly by being fair to those who have announced and those who have yet to do so. But regardless, we have one chance here to make a good server platform that can challenge the incumbent architectures. If I weren't utterly convinced of that, and of the need for such standards as UEFI and ACPI, then I wouldn't be so vocal about it. Given who is involved in this space, regardless of a decision to adopt ACPI now or later, it is coming. It can be done right now, or not. I (and others) pushed 3 years ago for the adoption of ACPI. Dong, and others instigated the legal processes that resulted in the movement of ACPI under UEFI Forum recently, to become a fully open standard that can be shaped - both by the Linux community, and by others. ACPI.next will benefit from the same development process that has shaped UEFI standards over the past few years, and most people here can easily get involved in shaping that standard - as they can on x86 as well now. I am pushing for a few other things to become public that will help to explain why ACPI is being adopted and provide a standardized description of the ways in which it will be used/consumed. On 11/15/2013 04:57 AM, Mark Rutland wrote: > On Fri, Nov 15, 2013 at 01:44:10AM +0000, Olof Johansson wrote: >> The more I start to see early UEFI/ACPI code, the more I am certain >> that we want none of that crap in the kernel. It's making things >> considerably messier, while we're already very busy trying to convert >> everything over and enable DT -- we'll be preempting that effort just >> to add even more boilerplate everywhere and total progress will be >> hurt. Firstly, I would note that I don't expect DeviceTree to go away. Only on server class systems. I expect all server class ARMv8 systems in the Enterprise/Cloud environment to boot using UEFI and ACPI. This is certainly the case of most future design starts already underway. These can either be supported properly, or not, but ignoring the impending ACPI systems isn't practical. Translation won't work reliably either. For the record, I did suggest to Applied that the first posting of that SATA driver not have the ACPI bits in (since we know it needs cleaning up to use the key/value approaches already discussed, and so on), but after chatting with Loc about it, it seemed reasonable to use the opportunity to start a discussion - which seems to be on cue here. <snip> > I'm of the opinion that the only way we should support ACPI is as a > first-class citizen. There really isn't another way to do it in my opinion. > We don't need to modify every driver and subsystem > to support ACPI, only those necessary to support the minimal set of > platforms using ACPI. ACPI is new in the arm space, and we can enforce > quality standards on ACPI _now_ above what we're allowing for DT, and > avoid future problems. This is key. It's not going to be ACPI everywhere. It's going to be ACPI on server class systems. And later, maybe some client systems. But the big push is from the server crowd. We need to build systems that in 5-10 years time can still boot an older kernel. This can't be done without a standardized/versioned enumeration/discovery mechanism like ACPI that has an API enshrined in stone as far as compatibility. Device Tree is wonderful, anyone can make a binding and use it. Or change the binding in the next kernel release. Or...this doesn't work in the server space. Server platforms aren't vertically welded shut like in the embedded space, where DeviceTree has brought all kinds of benefits for those building with a single kernel for many different targets, but has also seen a huge amount of churn from one kernel to the next. If I counted the number of times I've been told "just update your dtb"...then I would be shivering in the corner a sadden wreck. You can't "just update your dtb" on a server class system. You shouldn't. But anyway, emotional plea aside, a very large number of ACPI systems are coming. Yes, I've been pushing to get existing players to switch, but that's because I know what is coming. And if you want certain other players to appear in this space, you'll need to have ACPI for them, too. > There may even be things which we don't have to deal with at all on ACPI > systems as used in servers (e.g. clock management), but perhaps we will > if people see value in those elements. > >> The server guys really want UEFI for their boot protocols, >> installation managers, etc, etc. That's fine, let them do that, but >> that doesn't mean we need to bring the same APIs all the way into the >> kernel. >> >> So, I'm strongly urging that whatever the server guys try to do, it >> will in the end result in the ACPI data being translated into DT >> equivalents, such that the kernel _only_ needs to handle data via DT. > > I'm not sure that translating ACPI tables to dt makes any sense. If AML > is used (even sparingly), I do not believe that we can do any sensible > conversion to device tree. My understanding is that AML includes > functionality for modifying ACPI tables, and I don't see how we can > possibly support that without having to add a lot of boilerplate to all > the code handling AML to add a device tree backend... AML includes code that is runtime interpreted, for things like power button emulation and the like. You can't just translate this. This comes up every few years - it's impractical. You'll end up having to ship both DTB and ACPI tables for a system. Which means two tables for a platform vendor to get right. You know what will happen - only one table with be correct. Perhaps it seems that it will be the DTB that is more correct, and this might be true this week, but by 2016 I *guarantee* you that the ACPI table will be the one winning. >> Just like PowerPC scrapes the OpenFirmware client interface to build a >> flat device tree, we should add a pre-boot stage that scrapes >> ACPI/UEFI data and constructs an appropriate device-tree. We can still >> bring over ACPI methods and represent those in the DT, but we should >> _not_ have two native interfaces. > > I'm not sure the two cases are comparable. The format of the FDT was > designed to encode the data structure used by OpenFirmware, and thus the > two map to each other pretty well. I do not believe that mapping from > ACPI tables to an FDT blob is anywhere near as simple, and as I mention > above I do not believe that we can just copy over the ACPI methods in > isolation. Indeed. OpenFirmware and DeviceTree share an ancestry. I was pushing to create DeviceTree back in '04 or '05 when I was working on a ppc4xx Xilinx port and I thought there was a better way than their HAL, then noticed that ppc64's boot protocol always created a blob and kexec'd (for same code path regardless) itself during boot. True. So I love the concept of DeviceTree on embedded platforms without real firmware. But it smells a lot like OpenFirmware's tables for *very good reason*. ACPI's DSDT is the equivalent in terms of description data, but ACPI goes way, way beyond the level of just describing platform hardware. <snip> > I think that trying to shoe-horn ACPI-derived information into device > tree is fundamentally the wrong approach. I don't think it encourages > best practices, and I don't think it's beneficial to the long term > health of Linux or the ecosystem as a whole. It's going to be a messy thing to even attempt. Look, I wish we had a time machine and could have done this whole thing years ago, but I'm not sure it would have gone differently. ACPI is something a lot of people emotionally hate. In the Enterprise space myself and others *need* it (along with UEFI) to have a scalable solution that doesn't result in an onslaught of customer support calls, which a non-standards body backed moving target of DTB will do. And besides all of the big boys are going to be using ACPI whether it's liked much or not. Jon. ^ permalink raw reply [flat|nested] 186+ messages in thread
* ACPI vs DT at runtime 2013-11-18 5:19 ` Jon Masters @ 2013-11-18 5:26 ` Jon Masters [not found] ` <5289A4F3.5040203-Zp4isUonpHBD60Wz+7aTrA@public.gmane.org> 2013-11-18 7:22 ` Richard Cochran ` (5 subsequent siblings) 6 siblings, 1 reply; 186+ messages in thread From: Jon Masters @ 2013-11-18 5:26 UTC (permalink / raw) To: linux-arm-kernel On 11/18/2013 12:19 AM, Jon Masters wrote: > It's going to be a messy thing to even attempt. Look, I wish we had a > time machine and could have done this whole thing years ago, but I'm not > sure it would have gone differently. ACPI is something a lot of people > emotionally hate. In the Enterprise space myself and others *need* it > (along with UEFI) to have a scalable solution that doesn't result in an > onslaught of customer support calls, which a non-standards body backed > moving target of DTB will do. And besides all of the big boys are going > to be using ACPI whether it's liked much or not. A while ago I mentioned producing a series of requirements that articulates what Red Hat thinks an ARMv8 server looks like. Suffice it to say that such requirements do in fact exist, and will be made available in the not too distant future as part of another doc. Jon. ^ permalink raw reply [flat|nested] 186+ messages in thread
[parent not found: <5289A4F3.5040203-Zp4isUonpHBD60Wz+7aTrA@public.gmane.org>]
* Re: ACPI vs DT at runtime 2013-11-18 5:26 ` Jon Masters @ 2013-11-18 19:25 ` Olof Johansson 0 siblings, 0 replies; 186+ messages in thread From: Olof Johansson @ 2013-11-18 19:25 UTC (permalink / raw) To: Jon Masters Cc: linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r, devicetree-u79uwXL29TY76Z2rM5mHXA On Mon, Nov 18, 2013 at 12:26:11AM -0500, Jon Masters wrote: > On 11/18/2013 12:19 AM, Jon Masters wrote: > > > It's going to be a messy thing to even attempt. Look, I wish we had a > > time machine and could have done this whole thing years ago, but I'm not > > sure it would have gone differently. ACPI is something a lot of people > > emotionally hate. In the Enterprise space myself and others *need* it > > (along with UEFI) to have a scalable solution that doesn't result in an > > onslaught of customer support calls, which a non-standards body backed > > moving target of DTB will do. And besides all of the big boys are going > > to be using ACPI whether it's liked much or not. > > A while ago I mentioned producing a series of requirements that > articulates what Red Hat thinks an ARMv8 server looks like. Suffice it > to say that such requirements do in fact exist, and will be made > available in the not too distant future as part of another doc. It's nice that there's an unpublished document with a RedHat logo on it somewhere that mandates what we, the kernel project, is going to do. I thought both RedHat and you personally knew that we don't do things that way in the kernel, Jon. Published or not. -Olof -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org More majordomo info at http://vger.kernel.org/majordomo-info.html ^ permalink raw reply [flat|nested] 186+ messages in thread
* ACPI vs DT at runtime @ 2013-11-18 19:25 ` Olof Johansson 0 siblings, 0 replies; 186+ messages in thread From: Olof Johansson @ 2013-11-18 19:25 UTC (permalink / raw) To: linux-arm-kernel On Mon, Nov 18, 2013 at 12:26:11AM -0500, Jon Masters wrote: > On 11/18/2013 12:19 AM, Jon Masters wrote: > > > It's going to be a messy thing to even attempt. Look, I wish we had a > > time machine and could have done this whole thing years ago, but I'm not > > sure it would have gone differently. ACPI is something a lot of people > > emotionally hate. In the Enterprise space myself and others *need* it > > (along with UEFI) to have a scalable solution that doesn't result in an > > onslaught of customer support calls, which a non-standards body backed > > moving target of DTB will do. And besides all of the big boys are going > > to be using ACPI whether it's liked much or not. > > A while ago I mentioned producing a series of requirements that > articulates what Red Hat thinks an ARMv8 server looks like. Suffice it > to say that such requirements do in fact exist, and will be made > available in the not too distant future as part of another doc. It's nice that there's an unpublished document with a RedHat logo on it somewhere that mandates what we, the kernel project, is going to do. I thought both RedHat and you personally knew that we don't do things that way in the kernel, Jon. Published or not. -Olof ^ permalink raw reply [flat|nested] 186+ messages in thread
[parent not found: <20131118192552.GD5886-O5ziIzlqnXUVNXGz7ipsyg@public.gmane.org>]
* Re: ACPI vs DT at runtime 2013-11-18 19:25 ` Olof Johansson @ 2013-11-18 20:43 ` Jon Masters -1 siblings, 0 replies; 186+ messages in thread From: Jon Masters @ 2013-11-18 20:43 UTC (permalink / raw) To: Olof Johansson Cc: linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r, devicetree-u79uwXL29TY76Z2rM5mHXA On 11/18/2013 02:25 PM, Olof Johansson wrote: > On Mon, Nov 18, 2013 at 12:26:11AM -0500, Jon Masters wrote: >> On 11/18/2013 12:19 AM, Jon Masters wrote: >> >>> It's going to be a messy thing to even attempt. Look, I wish we had a >>> time machine and could have done this whole thing years ago, but I'm not >>> sure it would have gone differently. ACPI is something a lot of people >>> emotionally hate. In the Enterprise space myself and others *need* it >>> (along with UEFI) to have a scalable solution that doesn't result in an >>> onslaught of customer support calls, which a non-standards body backed >>> moving target of DTB will do. And besides all of the big boys are going >>> to be using ACPI whether it's liked much or not. >> >> A while ago I mentioned producing a series of requirements that >> articulates what Red Hat thinks an ARMv8 server looks like. Suffice it >> to say that such requirements do in fact exist, and will be made >> available in the not too distant future as part of another doc. > > It's nice that there's an unpublished document with a RedHat logo on it > somewhere that mandates what we, the kernel project, is going to do. > > I thought both RedHat and you personally knew that we don't do things > that way in the kernel, Jon. Published or not. Olof, I understand completely. My hands are unfortunately tied and it's not of my making (or my employer) on this front. In the ARM space, there are a lot of entities involved when it comes to anything at all, and you know what the NDA situation is like. I am pushing to get a few things out there for broader consumption. Jon. -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org More majordomo info at http://vger.kernel.org/majordomo-info.html ^ permalink raw reply [flat|nested] 186+ messages in thread
* ACPI vs DT at runtime @ 2013-11-18 20:43 ` Jon Masters 0 siblings, 0 replies; 186+ messages in thread From: Jon Masters @ 2013-11-18 20:43 UTC (permalink / raw) To: linux-arm-kernel On 11/18/2013 02:25 PM, Olof Johansson wrote: > On Mon, Nov 18, 2013 at 12:26:11AM -0500, Jon Masters wrote: >> On 11/18/2013 12:19 AM, Jon Masters wrote: >> >>> It's going to be a messy thing to even attempt. Look, I wish we had a >>> time machine and could have done this whole thing years ago, but I'm not >>> sure it would have gone differently. ACPI is something a lot of people >>> emotionally hate. In the Enterprise space myself and others *need* it >>> (along with UEFI) to have a scalable solution that doesn't result in an >>> onslaught of customer support calls, which a non-standards body backed >>> moving target of DTB will do. And besides all of the big boys are going >>> to be using ACPI whether it's liked much or not. >> >> A while ago I mentioned producing a series of requirements that >> articulates what Red Hat thinks an ARMv8 server looks like. Suffice it >> to say that such requirements do in fact exist, and will be made >> available in the not too distant future as part of another doc. > > It's nice that there's an unpublished document with a RedHat logo on it > somewhere that mandates what we, the kernel project, is going to do. > > I thought both RedHat and you personally knew that we don't do things > that way in the kernel, Jon. Published or not. Olof, I understand completely. My hands are unfortunately tied and it's not of my making (or my employer) on this front. In the ARM space, there are a lot of entities involved when it comes to anything at all, and you know what the NDA situation is like. I am pushing to get a few things out there for broader consumption. Jon. ^ permalink raw reply [flat|nested] 186+ messages in thread
[parent not found: <528A7BFD.4020303-Zp4isUonpHBD60Wz+7aTrA@public.gmane.org>]
* Re: ACPI vs DT at runtime 2013-11-18 20:43 ` Jon Masters @ 2013-11-18 21:25 ` Olof Johansson -1 siblings, 0 replies; 186+ messages in thread From: Olof Johansson @ 2013-11-18 21:25 UTC (permalink / raw) To: Jon Masters Cc: linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r, devicetree-u79uwXL29TY76Z2rM5mHXA On Mon, Nov 18, 2013 at 12:43 PM, Jon Masters <jonathan-Zp4isUonpHBD60Wz+7aTrA@public.gmane.org> wrote: > On 11/18/2013 02:25 PM, Olof Johansson wrote: >> On Mon, Nov 18, 2013 at 12:26:11AM -0500, Jon Masters wrote: >>> On 11/18/2013 12:19 AM, Jon Masters wrote: >>> >>>> It's going to be a messy thing to even attempt. Look, I wish we had a >>>> time machine and could have done this whole thing years ago, but I'm not >>>> sure it would have gone differently. ACPI is something a lot of people >>>> emotionally hate. In the Enterprise space myself and others *need* it >>>> (along with UEFI) to have a scalable solution that doesn't result in an >>>> onslaught of customer support calls, which a non-standards body backed >>>> moving target of DTB will do. And besides all of the big boys are going >>>> to be using ACPI whether it's liked much or not. >>> >>> A while ago I mentioned producing a series of requirements that >>> articulates what Red Hat thinks an ARMv8 server looks like. Suffice it >>> to say that such requirements do in fact exist, and will be made >>> available in the not too distant future as part of another doc. >> >> It's nice that there's an unpublished document with a RedHat logo on it >> somewhere that mandates what we, the kernel project, is going to do. >> >> I thought both RedHat and you personally knew that we don't do things >> that way in the kernel, Jon. Published or not. > > Olof, I understand completely. My hands are unfortunately tied and it's > not of my making (or my employer) on this front. In the ARM space, there > are a lot of entities involved when it comes to anything at all, and you > know what the NDA situation is like. I am pushing to get a few things > out there for broader consumption. No, I don't think you understand. Or at least, your email is not reflecting it. It's not whether the document is public or not that is the real problem. The real problem is the claim that you have a platforms requirements document that is built upon unmerged features in the upstream kernel. Unless RedHat is willing to carry that functionality in their own kernel instead -- if so, RedHat is of course free to mandate whatever they want to. -Olof -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org More majordomo info at http://vger.kernel.org/majordomo-info.html ^ permalink raw reply [flat|nested] 186+ messages in thread
* ACPI vs DT at runtime @ 2013-11-18 21:25 ` Olof Johansson 0 siblings, 0 replies; 186+ messages in thread From: Olof Johansson @ 2013-11-18 21:25 UTC (permalink / raw) To: linux-arm-kernel On Mon, Nov 18, 2013 at 12:43 PM, Jon Masters <jonathan@jonmasters.org> wrote: > On 11/18/2013 02:25 PM, Olof Johansson wrote: >> On Mon, Nov 18, 2013 at 12:26:11AM -0500, Jon Masters wrote: >>> On 11/18/2013 12:19 AM, Jon Masters wrote: >>> >>>> It's going to be a messy thing to even attempt. Look, I wish we had a >>>> time machine and could have done this whole thing years ago, but I'm not >>>> sure it would have gone differently. ACPI is something a lot of people >>>> emotionally hate. In the Enterprise space myself and others *need* it >>>> (along with UEFI) to have a scalable solution that doesn't result in an >>>> onslaught of customer support calls, which a non-standards body backed >>>> moving target of DTB will do. And besides all of the big boys are going >>>> to be using ACPI whether it's liked much or not. >>> >>> A while ago I mentioned producing a series of requirements that >>> articulates what Red Hat thinks an ARMv8 server looks like. Suffice it >>> to say that such requirements do in fact exist, and will be made >>> available in the not too distant future as part of another doc. >> >> It's nice that there's an unpublished document with a RedHat logo on it >> somewhere that mandates what we, the kernel project, is going to do. >> >> I thought both RedHat and you personally knew that we don't do things >> that way in the kernel, Jon. Published or not. > > Olof, I understand completely. My hands are unfortunately tied and it's > not of my making (or my employer) on this front. In the ARM space, there > are a lot of entities involved when it comes to anything at all, and you > know what the NDA situation is like. I am pushing to get a few things > out there for broader consumption. No, I don't think you understand. Or at least, your email is not reflecting it. It's not whether the document is public or not that is the real problem. The real problem is the claim that you have a platforms requirements document that is built upon unmerged features in the upstream kernel. Unless RedHat is willing to carry that functionality in their own kernel instead -- if so, RedHat is of course free to mandate whatever they want to. -Olof ^ permalink raw reply [flat|nested] 186+ messages in thread
* ACPI vs DT at runtime 2013-11-18 5:19 ` Jon Masters 2013-11-18 5:26 ` Jon Masters @ 2013-11-18 7:22 ` Richard Cochran 2013-11-18 13:55 ` Stefano Stabellini ` (4 subsequent siblings) 6 siblings, 0 replies; 186+ messages in thread From: Richard Cochran @ 2013-11-18 7:22 UTC (permalink / raw) To: linux-arm-kernel On Mon, Nov 18, 2013 at 12:19:18AM -0500, Jon Masters wrote: > If I counted > the number of times I've been told "just update your dtb"...then I would > be shivering in the corner a sadden wreck. You can't "just update your > dtb" on a server class system. You shouldn't. Ditto for embedded, really. Thanks, Richard ^ permalink raw reply [flat|nested] 186+ messages in thread
* ACPI vs DT at runtime 2013-11-18 5:19 ` Jon Masters 2013-11-18 5:26 ` Jon Masters 2013-11-18 7:22 ` Richard Cochran @ 2013-11-18 13:55 ` Stefano Stabellini 2013-11-18 15:00 ` Mark Brown ` (3 subsequent siblings) 6 siblings, 0 replies; 186+ messages in thread From: Stefano Stabellini @ 2013-11-18 13:55 UTC (permalink / raw) To: linux-arm-kernel On Mon, 18 Nov 2013, Jon Masters wrote: > > We don't need to modify every driver and subsystem > > to support ACPI, only those necessary to support the minimal set of > > platforms using ACPI. ACPI is new in the arm space, and we can enforce > > quality standards on ACPI _now_ above what we're allowing for DT, and > > avoid future problems. > > This is key. It's not going to be ACPI everywhere. It's going to be ACPI > on server class systems. And later, maybe some client systems. But the > big push is from the server crowd. We need to build systems that in 5-10 > years time can still boot an older kernel. This can't be done without a > standardized/versioned enumeration/discovery mechanism like ACPI that > has an API enshrined in stone as far as compatibility. Device Tree is > wonderful, anyone can make a binding and use it. Or change the binding > in the next kernel release. Or...this doesn't work in the server space. > Server platforms aren't vertically welded shut like in the embedded > space, where DeviceTree has brought all kinds of benefits for those > building with a single kernel for many different targets, but has also > seen a huge amount of churn from one kernel to the next. If I counted > the number of times I've been told "just update your dtb"...then I would > be shivering in the corner a sadden wreck. You can't "just update your > dtb" on a server class system. You shouldn't. Isn't this a matter of ensuring backward compatibility for device tree support in the kernel? This topic has already been discussed and agreed upon at the minisummit. Also I think that most of the churn was due to the fact that device tree was new in linux-arm. My guess is that something similar could easily happen to acpi support for linux-arm too during the first couple of years of development. > But anyway, emotional plea aside, a very large number of ACPI systems > are coming. Yes, I've been pushing to get existing players to switch, > but that's because I know what is coming. And if you want certain other > players to appear in this space, you'll need to have ACPI for them, too. What systems? You haven't named any. Your basic argument is: "I know things you don't know, trust me". I don't think that is good enough. > AML includes code that is runtime interpreted, for things like power > button emulation and the like. You can't just translate this. This comes > up every few years - it's impractical. You'll end up having to ship both > DTB and ACPI tables for a system. Which means two tables for a platform > vendor to get right. You know what will happen - only one table with be > correct. No. Most likely they are going to be both wrong, except that DTB can be fixed. In my x86 years I have seen many broken ACPI tables that only work on Windows, because that's the only OS they were tested with. > Perhaps it seems that it will be the DTB that is more correct, > and this might be true this week, but by 2016 I *guarantee* you that the > ACPI table will be the one winning. I would be careful making statements like that: many high profile people risked similar predictions in the past about the success of a technology or the other and they failed spectacularly. ^ permalink raw reply [flat|nested] 186+ messages in thread
* ACPI vs DT at runtime 2013-11-18 5:19 ` Jon Masters ` (2 preceding siblings ...) 2013-11-18 13:55 ` Stefano Stabellini @ 2013-11-18 15:00 ` Mark Brown [not found] ` <20131118150052.GC24408-GFdadSzt00ze9xe1eoZjHA@public.gmane.org> 2013-11-18 15:28 ` Rob Herring ` (2 subsequent siblings) 6 siblings, 1 reply; 186+ messages in thread From: Mark Brown @ 2013-11-18 15:00 UTC (permalink / raw) To: linux-arm-kernel On Mon, Nov 18, 2013 at 12:19:18AM -0500, Jon Masters wrote: > has an API enshrined in stone as far as compatibility. Device Tree is > wonderful, anyone can make a binding and use it. Or change the binding > in the next kernel release. Or...this doesn't work in the server space. This isn't really a property of DT, it's a property of the way people have been using the DT - people have been running with baked in DTs on PowerPC and SPARC systems for quite some time now. It's not obvious how writing the data out in one format rather than another addresses this. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 836 bytes Desc: Digital signature URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20131118/feb59cb5/attachment.sig> ^ permalink raw reply [flat|nested] 186+ messages in thread
[parent not found: <20131118150052.GC24408-GFdadSzt00ze9xe1eoZjHA@public.gmane.org>]
* Re: ACPI vs DT at runtime 2013-11-18 15:00 ` Mark Brown @ 2013-11-18 19:13 ` Olof Johansson 0 siblings, 0 replies; 186+ messages in thread From: Olof Johansson @ 2013-11-18 19:13 UTC (permalink / raw) To: Mark Brown Cc: Jon Masters, linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r, devicetree-u79uwXL29TY76Z2rM5mHXA [adding back devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org] On Mon, Nov 18, 2013 at 03:00:52PM +0000, Mark Brown wrote: > On Mon, Nov 18, 2013 at 12:19:18AM -0500, Jon Masters wrote: > > > has an API enshrined in stone as far as compatibility. Device Tree is > > wonderful, anyone can make a binding and use it. Or change the binding > > in the next kernel release. Or...this doesn't work in the server space. > > This isn't really a property of DT, it's a property of the way people > have been using the DT - people have been running with baked in DTs on > PowerPC and SPARC systems for quite some time now. It's not obvious how > writing the data out in one format rather than another addresses this. +1. And we're now changing the way DT is approached in a manner that will solve this problem. I know people have been frustrated that they need to keep the DT in sync with the kernel. But we've always been upfront with the requirement, and why we've been having it. We're now changing this requirement, which should help sort out practically all of the concerns at hand. -Olof -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org More majordomo info at http://vger.kernel.org/majordomo-info.html ^ permalink raw reply [flat|nested] 186+ messages in thread
* ACPI vs DT at runtime @ 2013-11-18 19:13 ` Olof Johansson 0 siblings, 0 replies; 186+ messages in thread From: Olof Johansson @ 2013-11-18 19:13 UTC (permalink / raw) To: linux-arm-kernel [adding back devicetree at vger.kernel.org] On Mon, Nov 18, 2013 at 03:00:52PM +0000, Mark Brown wrote: > On Mon, Nov 18, 2013 at 12:19:18AM -0500, Jon Masters wrote: > > > has an API enshrined in stone as far as compatibility. Device Tree is > > wonderful, anyone can make a binding and use it. Or change the binding > > in the next kernel release. Or...this doesn't work in the server space. > > This isn't really a property of DT, it's a property of the way people > have been using the DT - people have been running with baked in DTs on > PowerPC and SPARC systems for quite some time now. It's not obvious how > writing the data out in one format rather than another addresses this. +1. And we're now changing the way DT is approached in a manner that will solve this problem. I know people have been frustrated that they need to keep the DT in sync with the kernel. But we've always been upfront with the requirement, and why we've been having it. We're now changing this requirement, which should help sort out practically all of the concerns at hand. -Olof ^ permalink raw reply [flat|nested] 186+ messages in thread
[parent not found: <20131118191336.GB5886-O5ziIzlqnXUVNXGz7ipsyg@public.gmane.org>]
* Re: ACPI vs DT at runtime 2013-11-18 19:13 ` Olof Johansson @ 2013-11-19 9:12 ` Richard Cochran -1 siblings, 0 replies; 186+ messages in thread From: Richard Cochran @ 2013-11-19 9:12 UTC (permalink / raw) To: Olof Johansson Cc: Mark Brown, Jon Masters, devicetree-u79uwXL29TY76Z2rM5mHXA, linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r On Mon, Nov 18, 2013 at 11:13:36AM -0800, Olof Johansson wrote: > > I know people have been frustrated that they need to keep the DT in sync with > the kernel. But we've always been upfront with the requirement, and why we've > been having it. We're now changing this requirement, which should help sort out > practically all of the concerns at hand. Sorry, but this really gets my goat. When have you been upfront about the unstable DT idea? Was it when you suddenly, retrospectively announced this as a fact? http://thread.gmane.org/gmane.linux.kernel/1532141 I asked nicely for a pointer to some documentation of this so-called decision, http://thread.gmane.org/gmane.linux.kernel/1532141 and all I could hear was the crickets. It really looks like you guys have been making this up as you went along. Thanks, Richard -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org More majordomo info at http://vger.kernel.org/majordomo-info.html ^ permalink raw reply [flat|nested] 186+ messages in thread
* ACPI vs DT at runtime @ 2013-11-19 9:12 ` Richard Cochran 0 siblings, 0 replies; 186+ messages in thread From: Richard Cochran @ 2013-11-19 9:12 UTC (permalink / raw) To: linux-arm-kernel On Mon, Nov 18, 2013 at 11:13:36AM -0800, Olof Johansson wrote: > > I know people have been frustrated that they need to keep the DT in sync with > the kernel. But we've always been upfront with the requirement, and why we've > been having it. We're now changing this requirement, which should help sort out > practically all of the concerns at hand. Sorry, but this really gets my goat. When have you been upfront about the unstable DT idea? Was it when you suddenly, retrospectively announced this as a fact? http://thread.gmane.org/gmane.linux.kernel/1532141 I asked nicely for a pointer to some documentation of this so-called decision, http://thread.gmane.org/gmane.linux.kernel/1532141 and all I could hear was the crickets. It really looks like you guys have been making this up as you went along. Thanks, Richard ^ permalink raw reply [flat|nested] 186+ messages in thread
* Re: ACPI vs DT at runtime 2013-11-19 9:12 ` Richard Cochran @ 2013-11-19 18:48 ` Olof Johansson -1 siblings, 0 replies; 186+ messages in thread From: Olof Johansson @ 2013-11-19 18:48 UTC (permalink / raw) To: Richard Cochran Cc: Mark Brown, Jon Masters, devicetree-u79uwXL29TY76Z2rM5mHXA, linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r, grant.likely-s3s/WqlpOiPyB63q8FvJNQ [Adding Grant] On Tue, Nov 19, 2013 at 10:12:17AM +0100, Richard Cochran wrote: > On Mon, Nov 18, 2013 at 11:13:36AM -0800, Olof Johansson wrote: > > > > I know people have been frustrated that they need to keep the DT in sync with > > the kernel. But we've always been upfront with the requirement, and why we've > > been having it. We're now changing this requirement, which should help sort out > > practically all of the concerns at hand. > > Sorry, but this really gets my goat. When have you been upfront about > the unstable DT idea? As I said, from the very beginning. It's why we decided to have the DTS hosted in the kernel tree as well. The approach has always been "we'll move it out eventually when things settle down", but that's always been pushed off so far. This is just a tangent and a distraction anyway: You should know by now that we've decided to keep backwards compatibility going forward, so any argument about why we did it differently before is leading nowhere. -Olof -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org More majordomo info at http://vger.kernel.org/majordomo-info.html ^ permalink raw reply [flat|nested] 186+ messages in thread
* ACPI vs DT at runtime @ 2013-11-19 18:48 ` Olof Johansson 0 siblings, 0 replies; 186+ messages in thread From: Olof Johansson @ 2013-11-19 18:48 UTC (permalink / raw) To: linux-arm-kernel [Adding Grant] On Tue, Nov 19, 2013 at 10:12:17AM +0100, Richard Cochran wrote: > On Mon, Nov 18, 2013 at 11:13:36AM -0800, Olof Johansson wrote: > > > > I know people have been frustrated that they need to keep the DT in sync with > > the kernel. But we've always been upfront with the requirement, and why we've > > been having it. We're now changing this requirement, which should help sort out > > practically all of the concerns at hand. > > Sorry, but this really gets my goat. When have you been upfront about > the unstable DT idea? As I said, from the very beginning. It's why we decided to have the DTS hosted in the kernel tree as well. The approach has always been "we'll move it out eventually when things settle down", but that's always been pushed off so far. This is just a tangent and a distraction anyway: You should know by now that we've decided to keep backwards compatibility going forward, so any argument about why we did it differently before is leading nowhere. -Olof ^ permalink raw reply [flat|nested] 186+ messages in thread
[parent not found: <20131119184827.GD20967-O5ziIzlqnXUVNXGz7ipsyg@public.gmane.org>]
* Re: ACPI vs DT at runtime 2013-11-19 18:48 ` Olof Johansson @ 2013-11-20 6:40 ` Richard Cochran -1 siblings, 0 replies; 186+ messages in thread From: Richard Cochran @ 2013-11-20 6:40 UTC (permalink / raw) To: Olof Johansson Cc: Mark Brown, Jon Masters, devicetree-u79uwXL29TY76Z2rM5mHXA, linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r, grant.likely-s3s/WqlpOiPyB63q8FvJNQ On Tue, Nov 19, 2013 at 10:48:27AM -0800, Olof Johansson wrote: > > This is just a tangent and a distraction anyway: You should know by > now that we've decided to keep backwards compatibility going forward, > so any argument about why we did it differently before is leading nowhere. Yes, I know it is tangent, but the tone in which you address people (like Jon Masters) who complain about DT quality is really not fair. When DT for arm was first proposed, I argued against it in vain. Since then, I have really, truly tried my best to keep on top of the DT discussions on the arm list, because everyone working on the arm platform will have to know DT intimately, whether they want to or not. Now, I never saw any proclamation or discussion about "DT is in flux" on the arm list. If I had, I surely would have complained, and loudly. AFAICT, this decision was made in rather private circles, but you talk as if this was abundantly clear. *It was not.* Or if it was announced in some way, just show me where. Otherwise, please stop the "we were upfront about this from day one" excuses. Thanks, Richard -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org More majordomo info at http://vger.kernel.org/majordomo-info.html ^ permalink raw reply [flat|nested] 186+ messages in thread
* ACPI vs DT at runtime @ 2013-11-20 6:40 ` Richard Cochran 0 siblings, 0 replies; 186+ messages in thread From: Richard Cochran @ 2013-11-20 6:40 UTC (permalink / raw) To: linux-arm-kernel On Tue, Nov 19, 2013 at 10:48:27AM -0800, Olof Johansson wrote: > > This is just a tangent and a distraction anyway: You should know by > now that we've decided to keep backwards compatibility going forward, > so any argument about why we did it differently before is leading nowhere. Yes, I know it is tangent, but the tone in which you address people (like Jon Masters) who complain about DT quality is really not fair. When DT for arm was first proposed, I argued against it in vain. Since then, I have really, truly tried my best to keep on top of the DT discussions on the arm list, because everyone working on the arm platform will have to know DT intimately, whether they want to or not. Now, I never saw any proclamation or discussion about "DT is in flux" on the arm list. If I had, I surely would have complained, and loudly. AFAICT, this decision was made in rather private circles, but you talk as if this was abundantly clear. *It was not.* Or if it was announced in some way, just show me where. Otherwise, please stop the "we were upfront about this from day one" excuses. Thanks, Richard ^ permalink raw reply [flat|nested] 186+ messages in thread
* Re: ACPI vs DT at runtime 2013-11-20 6:40 ` Richard Cochran @ 2013-11-21 18:16 ` Grant Likely -1 siblings, 0 replies; 186+ messages in thread From: Grant Likely @ 2013-11-21 18:16 UTC (permalink / raw) To: Richard Cochran, Olof Johansson Cc: Mark Brown, Jon Masters, devicetree-u79uwXL29TY76Z2rM5mHXA, linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r On Wed, 20 Nov 2013 07:40:57 +0100, Richard Cochran <richardcochran-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote: > On Tue, Nov 19, 2013 at 10:48:27AM -0800, Olof Johansson wrote: > > > > This is just a tangent and a distraction anyway: You should know by > > now that we've decided to keep backwards compatibility going forward, > > so any argument about why we did it differently before is leading nowhere. > > Yes, I know it is tangent, but the tone in which you address people > (like Jon Masters) who complain about DT quality is really not fair. > > When DT for arm was first proposed, I argued against it in vain. > Since then, I have really, truly tried my best to keep on top of the > DT discussions on the arm list, because everyone working on the arm > platform will have to know DT intimately, whether they want to or not. > > Now, I never saw any proclamation or discussion about "DT is in flux" > on the arm list. If I had, I surely would have complained, and loudly. > AFAICT, this decision was made in rather private circles, but you talk > as if this was abundantly clear. *It was not.* > > Or if it was announced in some way, just show me where. Otherwise, > please stop the "we were upfront about this from day one" excuses. No, I cannot point at any one place where it was stated outright. My memory is not that good. There were lots of times the stability of DT bindings was discussed, and I certainly have told people on the mailing list to keep their dtb updated while we are figuring out things like clock bindings and adding functionality. I'm sorry that it wasn't more clear. As has already been said in this thread, when the DT migration started, we didn't know how it should all look and work. It took time to figure out what was sane and what was not. g. -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org More majordomo info at http://vger.kernel.org/majordomo-info.html ^ permalink raw reply [flat|nested] 186+ messages in thread
* ACPI vs DT at runtime @ 2013-11-21 18:16 ` Grant Likely 0 siblings, 0 replies; 186+ messages in thread From: Grant Likely @ 2013-11-21 18:16 UTC (permalink / raw) To: linux-arm-kernel On Wed, 20 Nov 2013 07:40:57 +0100, Richard Cochran <richardcochran@gmail.com> wrote: > On Tue, Nov 19, 2013 at 10:48:27AM -0800, Olof Johansson wrote: > > > > This is just a tangent and a distraction anyway: You should know by > > now that we've decided to keep backwards compatibility going forward, > > so any argument about why we did it differently before is leading nowhere. > > Yes, I know it is tangent, but the tone in which you address people > (like Jon Masters) who complain about DT quality is really not fair. > > When DT for arm was first proposed, I argued against it in vain. > Since then, I have really, truly tried my best to keep on top of the > DT discussions on the arm list, because everyone working on the arm > platform will have to know DT intimately, whether they want to or not. > > Now, I never saw any proclamation or discussion about "DT is in flux" > on the arm list. If I had, I surely would have complained, and loudly. > AFAICT, this decision was made in rather private circles, but you talk > as if this was abundantly clear. *It was not.* > > Or if it was announced in some way, just show me where. Otherwise, > please stop the "we were upfront about this from day one" excuses. No, I cannot point at any one place where it was stated outright. My memory is not that good. There were lots of times the stability of DT bindings was discussed, and I certainly have told people on the mailing list to keep their dtb updated while we are figuring out things like clock bindings and adding functionality. I'm sorry that it wasn't more clear. As has already been said in this thread, when the DT migration started, we didn't know how it should all look and work. It took time to figure out what was sane and what was not. g. ^ permalink raw reply [flat|nested] 186+ messages in thread
* Re: ACPI vs DT at runtime 2013-11-20 6:40 ` Richard Cochran @ 2013-11-21 19:21 ` Russell King - ARM Linux -1 siblings, 0 replies; 186+ messages in thread From: Russell King - ARM Linux @ 2013-11-21 19:21 UTC (permalink / raw) To: Richard Cochran Cc: Olof Johansson, Jon Masters, devicetree-u79uwXL29TY76Z2rM5mHXA, Mark Brown, grant.likely-s3s/WqlpOiPyB63q8FvJNQ, linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r On Wed, Nov 20, 2013 at 07:40:57AM +0100, Richard Cochran wrote: > Now, I never saw any proclamation or discussion about "DT is in flux" > on the arm list. If I had, I surely would have complained, and loudly. > AFAICT, this decision was made in rather private circles, but you talk > as if this was abundantly clear. *It was not.* DT has been discussed several times over this year alone, which included discussions about the stability of bindings. Various people in those threads (including myself) have put their views forward. My position has been that if an interface ends up being published in a -final kernel, then it is part of the ABI, because a -final kernel is an end-product. It's a final release which says "we've done the development, it's finished for users use." If it's not then it shouldn't be in a -final kernel, or if it has to be there for development purposes, it needs to be hidden behind a "this is in development" label. I've said that several times in the DT discussions and I believe basically been ignored. Frankly, I've said my bit and I've given up caring. If no one wants to listen, my attitude now is to just shut up and let people learn their lessons the hard way. A bit like what I ended up doing with the clk API and the idiocracy over the "let's pass a NULL struct device and a system clock name because its simple" stuff which then caused people a lot of pain... and guess what, when done right (like the majority of cases today) it's a hell of a lot easier. People had to be left to find out for themselves that I was right. -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org More majordomo info at http://vger.kernel.org/majordomo-info.html ^ permalink raw reply [flat|nested] 186+ messages in thread
* ACPI vs DT at runtime @ 2013-11-21 19:21 ` Russell King - ARM Linux 0 siblings, 0 replies; 186+ messages in thread From: Russell King - ARM Linux @ 2013-11-21 19:21 UTC (permalink / raw) To: linux-arm-kernel On Wed, Nov 20, 2013 at 07:40:57AM +0100, Richard Cochran wrote: > Now, I never saw any proclamation or discussion about "DT is in flux" > on the arm list. If I had, I surely would have complained, and loudly. > AFAICT, this decision was made in rather private circles, but you talk > as if this was abundantly clear. *It was not.* DT has been discussed several times over this year alone, which included discussions about the stability of bindings. Various people in those threads (including myself) have put their views forward. My position has been that if an interface ends up being published in a -final kernel, then it is part of the ABI, because a -final kernel is an end-product. It's a final release which says "we've done the development, it's finished for users use." If it's not then it shouldn't be in a -final kernel, or if it has to be there for development purposes, it needs to be hidden behind a "this is in development" label. I've said that several times in the DT discussions and I believe basically been ignored. Frankly, I've said my bit and I've given up caring. If no one wants to listen, my attitude now is to just shut up and let people learn their lessons the hard way. A bit like what I ended up doing with the clk API and the idiocracy over the "let's pass a NULL struct device and a system clock name because its simple" stuff which then caused people a lot of pain... and guess what, when done right (like the majority of cases today) it's a hell of a lot easier. People had to be left to find out for themselves that I was right. ^ permalink raw reply [flat|nested] 186+ messages in thread
[parent not found: < 20131121192136.GA16735@n2100.arm.linux.org.uk>]
[parent not found: <20131121192136.GA16735-l+eeeJia6m9vn6HldHNs0ANdhmdF6hFW@public.gmane.org>]
* Re: ACPI vs DT at runtime 2013-11-21 19:21 ` Russell King - ARM Linux @ 2013-11-21 20:47 ` Grant Likely -1 siblings, 0 replies; 186+ messages in thread From: Grant Likely @ 2013-11-21 20:47 UTC (permalink / raw) To: Russell King - ARM Linux, Richard Cochran Cc: Olof Johansson, Jon Masters, devicetree-u79uwXL29TY76Z2rM5mHXA, Mark Brown, linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r On Thu, 21 Nov 2013 19:21:36 +0000, Russell King - ARM Linux <linux-lFZ/pmaqli7XmaaqVzeoHQ@public.gmane.org> wrote: > On Wed, Nov 20, 2013 at 07:40:57AM +0100, Richard Cochran wrote: > > Now, I never saw any proclamation or discussion about "DT is in flux" > > on the arm list. If I had, I surely would have complained, and loudly. > > AFAICT, this decision was made in rather private circles, but you talk > > as if this was abundantly clear. *It was not.* > > DT has been discussed several times over this year alone, which > included discussions about the stability of bindings. Various > people in those threads (including myself) have put their views > forward. > > My position has been that if an interface ends up being published in a > -final kernel, then it is part of the ABI, because a -final kernel is > an end-product. It's a final release which says "we've done the > development, it's finished for users use." If it's not then it shouldn't > be in a -final kernel, or if it has to be there for development purposes, > it needs to be hidden behind a "this is in development" label. > > I've said that several times in the DT discussions and I believe > basically been ignored. Frankly, I've said my bit and I've given up > caring. Umm. Not sure why you feel ignored. We're absolutely going for stability now. g. -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org More majordomo info at http://vger.kernel.org/majordomo-info.html ^ permalink raw reply [flat|nested] 186+ messages in thread
* ACPI vs DT at runtime @ 2013-11-21 20:47 ` Grant Likely 0 siblings, 0 replies; 186+ messages in thread From: Grant Likely @ 2013-11-21 20:47 UTC (permalink / raw) To: linux-arm-kernel On Thu, 21 Nov 2013 19:21:36 +0000, Russell King - ARM Linux <linux@arm.linux.org.uk> wrote: > On Wed, Nov 20, 2013 at 07:40:57AM +0100, Richard Cochran wrote: > > Now, I never saw any proclamation or discussion about "DT is in flux" > > on the arm list. If I had, I surely would have complained, and loudly. > > AFAICT, this decision was made in rather private circles, but you talk > > as if this was abundantly clear. *It was not.* > > DT has been discussed several times over this year alone, which > included discussions about the stability of bindings. Various > people in those threads (including myself) have put their views > forward. > > My position has been that if an interface ends up being published in a > -final kernel, then it is part of the ABI, because a -final kernel is > an end-product. It's a final release which says "we've done the > development, it's finished for users use." If it's not then it shouldn't > be in a -final kernel, or if it has to be there for development purposes, > it needs to be hidden behind a "this is in development" label. > > I've said that several times in the DT discussions and I believe > basically been ignored. Frankly, I've said my bit and I've given up > caring. Umm. Not sure why you feel ignored. We're absolutely going for stability now. g. ^ permalink raw reply [flat|nested] 186+ messages in thread
[parent not found: <20131121204704.E4487C40753-WNowdnHR2B42iJbIjFUEsiwD8/FfD2ys@public.gmane.org>]
* Re: ACPI vs DT at runtime 2013-11-21 20:47 ` Grant Likely @ 2013-11-22 11:43 ` Catalin Marinas -1 siblings, 0 replies; 186+ messages in thread From: Catalin Marinas @ 2013-11-22 11:43 UTC (permalink / raw) To: Grant Likely Cc: Russell King - ARM Linux, Richard Cochran, Olof Johansson, Jon Masters, Mark Brown, linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r, devicetree-u79uwXL29TY76Z2rM5mHXA On 21 November 2013 20:47, Grant Likely <grant.likely-s3s/WqlpOiPyB63q8FvJNQ@public.gmane.org> wrote: > On Thu, 21 Nov 2013 19:21:36 +0000, Russell King - ARM Linux <linux-lFZ/pmaqli7XmaaqVzeoHQ@public.gmane.org> wrote: >> On Wed, Nov 20, 2013 at 07:40:57AM +0100, Richard Cochran wrote: >> > Now, I never saw any proclamation or discussion about "DT is in flux" >> > on the arm list. If I had, I surely would have complained, and loudly. >> > AFAICT, this decision was made in rather private circles, but you talk >> > as if this was abundantly clear. *It was not.* >> >> DT has been discussed several times over this year alone, which >> included discussions about the stability of bindings. Various >> people in those threads (including myself) have put their views >> forward. >> >> My position has been that if an interface ends up being published in a >> -final kernel, then it is part of the ABI, because a -final kernel is >> an end-product. It's a final release which says "we've done the >> development, it's finished for users use." If it's not then it shouldn't >> be in a -final kernel, or if it has to be there for development purposes, >> it needs to be hidden behind a "this is in development" label. +1 >> I've said that several times in the DT discussions and I believe >> basically been ignored. Frankly, I've said my bit and I've given up >> caring. > > Umm. Not sure why you feel ignored. We're absolutely going for stability > now. What I was hoping for is a better way to enforce this by taking the dts files out of the kernel. I think that's the point where the bindings can become ABI. In the meantime we rely on contributors and reviewers making sure backwards compatibility is preserved. But I guess we'll eventually get there. -- Catalin -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org More majordomo info at http://vger.kernel.org/majordomo-info.html ^ permalink raw reply [flat|nested] 186+ messages in thread
* ACPI vs DT at runtime @ 2013-11-22 11:43 ` Catalin Marinas 0 siblings, 0 replies; 186+ messages in thread From: Catalin Marinas @ 2013-11-22 11:43 UTC (permalink / raw) To: linux-arm-kernel On 21 November 2013 20:47, Grant Likely <grant.likely@secretlab.ca> wrote: > On Thu, 21 Nov 2013 19:21:36 +0000, Russell King - ARM Linux <linux@arm.linux.org.uk> wrote: >> On Wed, Nov 20, 2013 at 07:40:57AM +0100, Richard Cochran wrote: >> > Now, I never saw any proclamation or discussion about "DT is in flux" >> > on the arm list. If I had, I surely would have complained, and loudly. >> > AFAICT, this decision was made in rather private circles, but you talk >> > as if this was abundantly clear. *It was not.* >> >> DT has been discussed several times over this year alone, which >> included discussions about the stability of bindings. Various >> people in those threads (including myself) have put their views >> forward. >> >> My position has been that if an interface ends up being published in a >> -final kernel, then it is part of the ABI, because a -final kernel is >> an end-product. It's a final release which says "we've done the >> development, it's finished for users use." If it's not then it shouldn't >> be in a -final kernel, or if it has to be there for development purposes, >> it needs to be hidden behind a "this is in development" label. +1 >> I've said that several times in the DT discussions and I believe >> basically been ignored. Frankly, I've said my bit and I've given up >> caring. > > Umm. Not sure why you feel ignored. We're absolutely going for stability > now. What I was hoping for is a better way to enforce this by taking the dts files out of the kernel. I think that's the point where the bindings can become ABI. In the meantime we rely on contributors and reviewers making sure backwards compatibility is preserved. But I guess we'll eventually get there. -- Catalin ^ permalink raw reply [flat|nested] 186+ messages in thread
[parent not found: <CAHkRjk5MstjD9JFk+co8k89i8geJBmSF6uObhGdmWSe0GJHo8g-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>]
* Re: ACPI vs DT at runtime 2013-11-22 11:43 ` Catalin Marinas @ 2013-11-22 12:00 ` Pantelis Antoniou -1 siblings, 0 replies; 186+ messages in thread From: Pantelis Antoniou @ 2013-11-22 12:00 UTC (permalink / raw) To: Catalin Marinas Cc: Grant Likely, Russell King - ARM Linux, Richard Cochran, Olof Johansson, Jon Masters, Mark Brown, linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r, devicetree-u79uwXL29TY76Z2rM5mHXA Hi On Nov 22, 2013, at 12:43 PM, Catalin Marinas wrote: > On 21 November 2013 20:47, Grant Likely <grant.likely-s3s/WqlpOiPyB63q8FvJNQ@public.gmane.org> wrote: >> On Thu, 21 Nov 2013 19:21:36 +0000, Russell King - ARM Linux <linux-lFZ/pmaqli7XmaaqVzeoHQ@public.gmane.org> wrote: >>> On Wed, Nov 20, 2013 at 07:40:57AM +0100, Richard Cochran wrote: >>>> Now, I never saw any proclamation or discussion about "DT is in flux" >>>> on the arm list. If I had, I surely would have complained, and loudly. >>>> AFAICT, this decision was made in rather private circles, but you talk >>>> as if this was abundantly clear. *It was not.* >>> >>> DT has been discussed several times over this year alone, which >>> included discussions about the stability of bindings. Various >>> people in those threads (including myself) have put their views >>> forward. >>> >>> My position has been that if an interface ends up being published in a >>> -final kernel, then it is part of the ABI, because a -final kernel is >>> an end-product. It's a final release which says "we've done the >>> development, it's finished for users use." If it's not then it shouldn't >>> be in a -final kernel, or if it has to be there for development purposes, >>> it needs to be hidden behind a "this is in development" label. > > +1 > >>> I've said that several times in the DT discussions and I believe >>> basically been ignored. Frankly, I've said my bit and I've given up >>> caring. >> >> Umm. Not sure why you feel ignored. We're absolutely going for stability >> now. > > What I was hoping for is a better way to enforce this by taking the > dts files out of the kernel. I think that's the point where the > bindings can become ABI. In the meantime we rely on contributors and > reviewers making sure backwards compatibility is preserved. But I > guess we'll eventually get there. > As one that's going to be dealing with this, please don't take the DTS files from the kernel. If you do this, I can guarantee that within a year almost no ARM board using DT will boot a mainline kernel. The reason is that vendors have enough trouble (and failing) tracking a single tree, adding yet another will just end to the vendor trees as far as the eye can see. Maybe, maybe, EVMs from silicon vendors will still boot, but I doubt any other customer board will work. > -- > Catalin > -- > To unsubscribe from this list: send the line "unsubscribe devicetree" in > the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org > More majordomo info at http://vger.kernel.org/majordomo-info.html Regards -- Pantelis -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org More majordomo info at http://vger.kernel.org/majordomo-info.html ^ permalink raw reply [flat|nested] 186+ messages in thread
* ACPI vs DT at runtime @ 2013-11-22 12:00 ` Pantelis Antoniou 0 siblings, 0 replies; 186+ messages in thread From: Pantelis Antoniou @ 2013-11-22 12:00 UTC (permalink / raw) To: linux-arm-kernel Hi On Nov 22, 2013, at 12:43 PM, Catalin Marinas wrote: > On 21 November 2013 20:47, Grant Likely <grant.likely@secretlab.ca> wrote: >> On Thu, 21 Nov 2013 19:21:36 +0000, Russell King - ARM Linux <linux@arm.linux.org.uk> wrote: >>> On Wed, Nov 20, 2013 at 07:40:57AM +0100, Richard Cochran wrote: >>>> Now, I never saw any proclamation or discussion about "DT is in flux" >>>> on the arm list. If I had, I surely would have complained, and loudly. >>>> AFAICT, this decision was made in rather private circles, but you talk >>>> as if this was abundantly clear. *It was not.* >>> >>> DT has been discussed several times over this year alone, which >>> included discussions about the stability of bindings. Various >>> people in those threads (including myself) have put their views >>> forward. >>> >>> My position has been that if an interface ends up being published in a >>> -final kernel, then it is part of the ABI, because a -final kernel is >>> an end-product. It's a final release which says "we've done the >>> development, it's finished for users use." If it's not then it shouldn't >>> be in a -final kernel, or if it has to be there for development purposes, >>> it needs to be hidden behind a "this is in development" label. > > +1 > >>> I've said that several times in the DT discussions and I believe >>> basically been ignored. Frankly, I've said my bit and I've given up >>> caring. >> >> Umm. Not sure why you feel ignored. We're absolutely going for stability >> now. > > What I was hoping for is a better way to enforce this by taking the > dts files out of the kernel. I think that's the point where the > bindings can become ABI. In the meantime we rely on contributors and > reviewers making sure backwards compatibility is preserved. But I > guess we'll eventually get there. > As one that's going to be dealing with this, please don't take the DTS files from the kernel. If you do this, I can guarantee that within a year almost no ARM board using DT will boot a mainline kernel. The reason is that vendors have enough trouble (and failing) tracking a single tree, adding yet another will just end to the vendor trees as far as the eye can see. Maybe, maybe, EVMs from silicon vendors will still boot, but I doubt any other customer board will work. > -- > Catalin > -- > To unsubscribe from this list: send the line "unsubscribe devicetree" in > the body of a message to majordomo at vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html Regards -- Pantelis ^ permalink raw reply [flat|nested] 186+ messages in thread
[parent not found: <97692EF2-013E-4E4B-BC16-E0915D67EFEC-wVdstyuyKrO8r51toPun2/C9HSW9iNxf@public.gmane.org>]
* Re: ACPI vs DT at runtime 2013-11-22 12:00 ` Pantelis Antoniou @ 2014-05-05 7:06 ` Alexander Holler -1 siblings, 0 replies; 186+ messages in thread From: Alexander Holler @ 2014-05-05 7:06 UTC (permalink / raw) To: Pantelis Antoniou, Catalin Marinas Cc: devicetree-u79uwXL29TY76Z2rM5mHXA, Russell King - ARM Linux, Richard Cochran, Grant Likely, Jon Masters, Mark Brown, Olof Johansson, linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r Am 22.11.2013 13:00, schrieb Pantelis Antoniou: > As one that's going to be dealing with this, please don't take the DTS > files from the kernel. > > If you do this, I can guarantee that within a year almost no ARM board using DT > will boot a mainline kernel. > > The reason is that vendors have enough trouble (and failing) tracking a single > tree, adding yet another will just end to the vendor trees as far as the eye can see. > > Maybe, maybe, EVMs from silicon vendors will still boot, but I doubt any other > customer board will work. A bit late (I don't follow the ML (or what happens in the ARM world) closely, but as I've recently read that ARM64 will go UEFI and ACPI, I wonder what was the reasoning behind that decision. Does anyone really assume we will become high quality UEFI and ACPI blobs from vendors? And such with reasonable support/update periods? For me that sounds like someone asked dreamers and was unable to adjust those answers in regard to reality. Regards, Alexander Holler -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org More majordomo info at http://vger.kernel.org/majordomo-info.html ^ permalink raw reply [flat|nested] 186+ messages in thread
* ACPI vs DT at runtime @ 2014-05-05 7:06 ` Alexander Holler 0 siblings, 0 replies; 186+ messages in thread From: Alexander Holler @ 2014-05-05 7:06 UTC (permalink / raw) To: linux-arm-kernel Am 22.11.2013 13:00, schrieb Pantelis Antoniou: > As one that's going to be dealing with this, please don't take the DTS > files from the kernel. > > If you do this, I can guarantee that within a year almost no ARM board using DT > will boot a mainline kernel. > > The reason is that vendors have enough trouble (and failing) tracking a single > tree, adding yet another will just end to the vendor trees as far as the eye can see. > > Maybe, maybe, EVMs from silicon vendors will still boot, but I doubt any other > customer board will work. A bit late (I don't follow the ML (or what happens in the ARM world) closely, but as I've recently read that ARM64 will go UEFI and ACPI, I wonder what was the reasoning behind that decision. Does anyone really assume we will become high quality UEFI and ACPI blobs from vendors? And such with reasonable support/update periods? For me that sounds like someone asked dreamers and was unable to adjust those answers in regard to reality. Regards, Alexander Holler ^ permalink raw reply [flat|nested] 186+ messages in thread
[parent not found: <53673866.9000105-SXC+2es9fhnfWeYVQQPykw@public.gmane.org>]
* Re: ACPI vs DT at runtime 2014-05-05 7:06 ` Alexander Holler @ 2014-05-05 14:41 ` Arnd Bergmann -1 siblings, 0 replies; 186+ messages in thread From: Arnd Bergmann @ 2014-05-05 14:41 UTC (permalink / raw) To: Alexander Holler Cc: Pantelis Antoniou, Catalin Marinas, devicetree-u79uwXL29TY76Z2rM5mHXA, Russell King - ARM Linux, Richard Cochran, Grant Likely, Jon Masters, Mark Brown, Olof Johansson, linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r On Monday 05 May 2014 09:06:14 Alexander Holler wrote: > > A bit late (I don't follow the ML (or what happens in the ARM world) > closely, but as I've recently read that ARM64 will go UEFI and ACPI, I > wonder what was the reasoning behind that decision. > > Does anyone really assume we will become high quality UEFI and ACPI > blobs from vendors? And such with reasonable support/update periods? > > For me that sounds like someone asked dreamers and was unable to adjust > those answers in regard to reality. Where did you read that? It's simply not true and we should make sure people stop spreading dangerous misinformation. Regarding UEFI, I don't expect that to change much for Linux, since it has very little visibility at runtime. UEFI makes sense for some systems, and we can support that easily. The license is a bit problematic, since it allows shipping a system without bootloader sources, but other boot loaders allow that as well, and a lot of companies ship pirated u-boot without sources, too. ACPI is a lot harder to support, as it conflicts with the normal DT probing method, and will be visible to a lot of drivers. I expect that we will see systems shipping with ACPI at some point, but so far, nobody has made a serious submission for supporting that, so it's likely a few years out, and it will only be a small subset of the shipping systems: basically anything that tries to look like an x86 PC server rather than an embedded system. There is ongoing work from Linaro to provide a base enablement of ACPI on ARM64. Those patches are looking harmless enough, but the current plan is to not merge them until there is an actual user who is submitting their platform specific code based on that, and not before we have clear rules about what systems should or should not be using ACPI. For all embedded systems, DT remains the way to pass data about nondiscoverable devices on arm64, and I expect that to include "server" machines based on embedded SoCs. Arnd -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org More majordomo info at http://vger.kernel.org/majordomo-info.html ^ permalink raw reply [flat|nested] 186+ messages in thread
* ACPI vs DT at runtime @ 2014-05-05 14:41 ` Arnd Bergmann 0 siblings, 0 replies; 186+ messages in thread From: Arnd Bergmann @ 2014-05-05 14:41 UTC (permalink / raw) To: linux-arm-kernel On Monday 05 May 2014 09:06:14 Alexander Holler wrote: > > A bit late (I don't follow the ML (or what happens in the ARM world) > closely, but as I've recently read that ARM64 will go UEFI and ACPI, I > wonder what was the reasoning behind that decision. > > Does anyone really assume we will become high quality UEFI and ACPI > blobs from vendors? And such with reasonable support/update periods? > > For me that sounds like someone asked dreamers and was unable to adjust > those answers in regard to reality. Where did you read that? It's simply not true and we should make sure people stop spreading dangerous misinformation. Regarding UEFI, I don't expect that to change much for Linux, since it has very little visibility at runtime. UEFI makes sense for some systems, and we can support that easily. The license is a bit problematic, since it allows shipping a system without bootloader sources, but other boot loaders allow that as well, and a lot of companies ship pirated u-boot without sources, too. ACPI is a lot harder to support, as it conflicts with the normal DT probing method, and will be visible to a lot of drivers. I expect that we will see systems shipping with ACPI at some point, but so far, nobody has made a serious submission for supporting that, so it's likely a few years out, and it will only be a small subset of the shipping systems: basically anything that tries to look like an x86 PC server rather than an embedded system. There is ongoing work from Linaro to provide a base enablement of ACPI on ARM64. Those patches are looking harmless enough, but the current plan is to not merge them until there is an actual user who is submitting their platform specific code based on that, and not before we have clear rules about what systems should or should not be using ACPI. For all embedded systems, DT remains the way to pass data about nondiscoverable devices on arm64, and I expect that to include "server" machines based on embedded SoCs. Arnd ^ permalink raw reply [flat|nested] 186+ messages in thread
* Re: ACPI vs DT at runtime 2014-05-05 14:41 ` Arnd Bergmann @ 2014-05-05 15:29 ` Alexander Holler -1 siblings, 0 replies; 186+ messages in thread From: Alexander Holler @ 2014-05-05 15:29 UTC (permalink / raw) To: Arnd Bergmann Cc: devicetree-u79uwXL29TY76Z2rM5mHXA, Russell King - ARM Linux, Catalin Marinas, Richard Cochran, Pantelis Antoniou, Grant Likely, Olof Johansson, Mark Brown, Jon Masters, linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r Am 05.05.2014 16:41, schrieb Arnd Bergmann: > On Monday 05 May 2014 09:06:14 Alexander Holler wrote: >> >> A bit late (I don't follow the ML (or what happens in the ARM world) >> closely, but as I've recently read that ARM64 will go UEFI and ACPI, I >> wonder what was the reasoning behind that decision. >> >> Does anyone really assume we will become high quality UEFI and ACPI >> blobs from vendors? And such with reasonable support/update periods? >> >> For me that sounds like someone asked dreamers and was unable to adjust >> those answers in regard to reality. > > Where did you read that? It's simply not true and we should make sure > people stop spreading dangerous misinformation. I've recently read Grant Likely's blog entry about armv8 servers: http://www.secretlab.ca/archives/27 (I've read the disclaimer too ;) ) > Regarding UEFI, I don't expect that to change much for Linux, since > it has very little visibility at runtime. UEFI makes sense for some > systems, and we can support that easily. The license is a bit problematic, > since it allows shipping a system without bootloader sources, but other > boot loaders allow that as well, and a lot of companies ship pirated > u-boot without sources, too. > > ACPI is a lot harder to support, as it conflicts with the normal DT > probing method, and will be visible to a lot of drivers. I expect > that we will see systems shipping with ACPI at some point, but > so far, nobody has made a serious submission for supporting that, > so it's likely a few years out, and it will only be a small subset > of the shipping systems: basically anything that tries to look like > an x86 PC server rather than an embedded system. > > There is ongoing work from Linaro to provide a base enablement of > ACPI on ARM64. Those patches are looking harmless enough, but the > current plan is to not merge them until there is an actual user > who is submitting their platform specific code based on that, and > not before we have clear rules about what systems should or should > not be using ACPI. > > For all embedded systems, DT remains the way to pass data about > nondiscoverable devices on arm64, and I expect that to include > "server" machines based on embedded SoCs. I usually avoid to talk about embedded systems as something different (e.g. than servers). I think such differentations don't make much sense anymore in times where people are getting in need of an administrator for their phones. ;) The problem I see is that if ARM requires UEFI and ACPI for general purpose ARMv8 servers, SOC vendors and the kernel will have to support that (I make the maybe silly assumption every ARMv8 SOC vendor wants to play in the server market). That means the kernel has to support it too. And nobody likes to support two types of something. So there is a requirement (on paper) for UEFI and ACPI (both likely closed blobs), but none for the open stuff. And when I now start to think about paper loving vogons, I don't need much imagination which type will be streamlined away. Regards, Alexander Holler -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org More majordomo info at http://vger.kernel.org/majordomo-info.html ^ permalink raw reply [flat|nested] 186+ messages in thread
* ACPI vs DT at runtime @ 2014-05-05 15:29 ` Alexander Holler 0 siblings, 0 replies; 186+ messages in thread From: Alexander Holler @ 2014-05-05 15:29 UTC (permalink / raw) To: linux-arm-kernel Am 05.05.2014 16:41, schrieb Arnd Bergmann: > On Monday 05 May 2014 09:06:14 Alexander Holler wrote: >> >> A bit late (I don't follow the ML (or what happens in the ARM world) >> closely, but as I've recently read that ARM64 will go UEFI and ACPI, I >> wonder what was the reasoning behind that decision. >> >> Does anyone really assume we will become high quality UEFI and ACPI >> blobs from vendors? And such with reasonable support/update periods? >> >> For me that sounds like someone asked dreamers and was unable to adjust >> those answers in regard to reality. > > Where did you read that? It's simply not true and we should make sure > people stop spreading dangerous misinformation. I've recently read Grant Likely's blog entry about armv8 servers: http://www.secretlab.ca/archives/27 (I've read the disclaimer too ;) ) > Regarding UEFI, I don't expect that to change much for Linux, since > it has very little visibility at runtime. UEFI makes sense for some > systems, and we can support that easily. The license is a bit problematic, > since it allows shipping a system without bootloader sources, but other > boot loaders allow that as well, and a lot of companies ship pirated > u-boot without sources, too. > > ACPI is a lot harder to support, as it conflicts with the normal DT > probing method, and will be visible to a lot of drivers. I expect > that we will see systems shipping with ACPI at some point, but > so far, nobody has made a serious submission for supporting that, > so it's likely a few years out, and it will only be a small subset > of the shipping systems: basically anything that tries to look like > an x86 PC server rather than an embedded system. > > There is ongoing work from Linaro to provide a base enablement of > ACPI on ARM64. Those patches are looking harmless enough, but the > current plan is to not merge them until there is an actual user > who is submitting their platform specific code based on that, and > not before we have clear rules about what systems should or should > not be using ACPI. > > For all embedded systems, DT remains the way to pass data about > nondiscoverable devices on arm64, and I expect that to include > "server" machines based on embedded SoCs. I usually avoid to talk about embedded systems as something different (e.g. than servers). I think such differentations don't make much sense anymore in times where people are getting in need of an administrator for their phones. ;) The problem I see is that if ARM requires UEFI and ACPI for general purpose ARMv8 servers, SOC vendors and the kernel will have to support that (I make the maybe silly assumption every ARMv8 SOC vendor wants to play in the server market). That means the kernel has to support it too. And nobody likes to support two types of something. So there is a requirement (on paper) for UEFI and ACPI (both likely closed blobs), but none for the open stuff. And when I now start to think about paper loving vogons, I don't need much imagination which type will be streamlined away. Regards, Alexander Holler ^ permalink raw reply [flat|nested] 186+ messages in thread
[parent not found: <5367AE6B.3010105-SXC+2es9fhnfWeYVQQPykw@public.gmane.org>]
* Re: ACPI vs DT at runtime 2014-05-05 15:29 ` Alexander Holler @ 2014-05-05 17:29 ` Arnd Bergmann -1 siblings, 0 replies; 186+ messages in thread From: Arnd Bergmann @ 2014-05-05 17:29 UTC (permalink / raw) To: Alexander Holler Cc: devicetree-u79uwXL29TY76Z2rM5mHXA, Russell King - ARM Linux, Catalin Marinas, Richard Cochran, Pantelis Antoniou, Grant Likely, Olof Johansson, Mark Brown, Jon Masters, linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r On Monday 05 May 2014 17:29:47 Alexander Holler wrote: > Am 05.05.2014 16:41, schrieb Arnd Bergmann: > > On Monday 05 May 2014 09:06:14 Alexander Holler wrote: > >> > >> A bit late (I don't follow the ML (or what happens in the ARM world) > >> closely, but as I've recently read that ARM64 will go UEFI and ACPI, I > >> wonder what was the reasoning behind that decision. > >> > >> Does anyone really assume we will become high quality UEFI and ACPI > >> blobs from vendors? And such with reasonable support/update periods? > >> > >> For me that sounds like someone asked dreamers and was unable to adjust > >> those answers in regard to reality. > > > > Where did you read that? It's simply not true and we should make sure > > people stop spreading dangerous misinformation. > > I've recently read Grant Likely's blog entry about armv8 servers: > http://www.secretlab.ca/archives/27 (I've read the disclaimer too ) Ok, that is fine. Everything he says there is ok, but it's easy to miss the point that he is only talking about general-purpose servers there. > > For all embedded systems, DT remains the way to pass data about > > nondiscoverable devices on arm64, and I expect that to include > > "server" machines based on embedded SoCs. > > I usually avoid to talk about embedded systems as something different > (e.g. than servers). I think such differentations don't make much sense > anymore in times where people are getting in need of an administrator > for their phones. It's the server people that see themselves as something different though. Which is funny because they came up with the idea to use ACPI in order to improve interoperability between hardware vendors, and now that they actually want to come out with systems, everything can already be interoperable, except that ACPI support is getting in the way. > The problem I see is that if ARM requires UEFI and ACPI for general > purpose ARMv8 servers, SOC vendors and the kernel will have to support > that (I make the maybe silly assumption every ARMv8 SOC vendor wants to > play in the server market). That means the kernel has to support it too. I don't think they are in a position to make that a requirement for servers in general. There is a boot architecture document that requires the use of ACPI for compliant systems. That doesn't prevent anyone from shipping a noncompliant system. I think it's similar to the SBSA specification: It's nice for companies to build a system compliant with that in theory, because then they get support for any OS that supports compliant systems, but in practice, I expect most of them to treat the spec as more of a suggestion and take shortcuts wherever it suits them. > And nobody likes to support two types of something. So there is a > requirement (on paper) for UEFI and ACPI (both likely closed blobs), but > none for the open stuff. And when I now start to think about paper > loving vogons, I don't need much imagination which type will be > streamlined away. I'm very strongly supporting the idea that we should not have two different kinds of device abstractions for a given SoC family. I also think we have two very distinct groups of SoC vendors here: * One side actively wants to use APCI, as they want to support MS Windows, and they have fast and simple general-purpose SoCs designed around the ACPI concepts and SBSA compliance. They wouldn't ship an open system anyway, and when they can show a reasonable implementation of ACPI that works on their systems, we will very likely merge that. * The other side has existing special-purpose SoC designs with ARM32, PowerPC, MIPS or other CPU cores and they want to migrate to ARM64 because everyone else is doing that too. They ship whatever their customers want, but they care little about Windows support, or strict standards compliance as long as their customers are happy. There is a lot of opposition to ACPI both in the customer base and the upstream Linux community for these machines, so these are likely to stay with DT for the foreseeable future. In fact, fear over fragmentation with ACPI on these systems one of the issues currently holding up merging ACPI for the first category. Arnd -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org More majordomo info at http://vger.kernel.org/majordomo-info.html ^ permalink raw reply [flat|nested] 186+ messages in thread
* ACPI vs DT at runtime @ 2014-05-05 17:29 ` Arnd Bergmann 0 siblings, 0 replies; 186+ messages in thread From: Arnd Bergmann @ 2014-05-05 17:29 UTC (permalink / raw) To: linux-arm-kernel On Monday 05 May 2014 17:29:47 Alexander Holler wrote: > Am 05.05.2014 16:41, schrieb Arnd Bergmann: > > On Monday 05 May 2014 09:06:14 Alexander Holler wrote: > >> > >> A bit late (I don't follow the ML (or what happens in the ARM world) > >> closely, but as I've recently read that ARM64 will go UEFI and ACPI, I > >> wonder what was the reasoning behind that decision. > >> > >> Does anyone really assume we will become high quality UEFI and ACPI > >> blobs from vendors? And such with reasonable support/update periods? > >> > >> For me that sounds like someone asked dreamers and was unable to adjust > >> those answers in regard to reality. > > > > Where did you read that? It's simply not true and we should make sure > > people stop spreading dangerous misinformation. > > I've recently read Grant Likely's blog entry about armv8 servers: > http://www.secretlab.ca/archives/27 (I've read the disclaimer too ) Ok, that is fine. Everything he says there is ok, but it's easy to miss the point that he is only talking about general-purpose servers there. > > For all embedded systems, DT remains the way to pass data about > > nondiscoverable devices on arm64, and I expect that to include > > "server" machines based on embedded SoCs. > > I usually avoid to talk about embedded systems as something different > (e.g. than servers). I think such differentations don't make much sense > anymore in times where people are getting in need of an administrator > for their phones. It's the server people that see themselves as something different though. Which is funny because they came up with the idea to use ACPI in order to improve interoperability between hardware vendors, and now that they actually want to come out with systems, everything can already be interoperable, except that ACPI support is getting in the way. > The problem I see is that if ARM requires UEFI and ACPI for general > purpose ARMv8 servers, SOC vendors and the kernel will have to support > that (I make the maybe silly assumption every ARMv8 SOC vendor wants to > play in the server market). That means the kernel has to support it too. I don't think they are in a position to make that a requirement for servers in general. There is a boot architecture document that requires the use of ACPI for compliant systems. That doesn't prevent anyone from shipping a noncompliant system. I think it's similar to the SBSA specification: It's nice for companies to build a system compliant with that in theory, because then they get support for any OS that supports compliant systems, but in practice, I expect most of them to treat the spec as more of a suggestion and take shortcuts wherever it suits them. > And nobody likes to support two types of something. So there is a > requirement (on paper) for UEFI and ACPI (both likely closed blobs), but > none for the open stuff. And when I now start to think about paper > loving vogons, I don't need much imagination which type will be > streamlined away. I'm very strongly supporting the idea that we should not have two different kinds of device abstractions for a given SoC family. I also think we have two very distinct groups of SoC vendors here: * One side actively wants to use APCI, as they want to support MS Windows, and they have fast and simple general-purpose SoCs designed around the ACPI concepts and SBSA compliance. They wouldn't ship an open system anyway, and when they can show a reasonable implementation of ACPI that works on their systems, we will very likely merge that. * The other side has existing special-purpose SoC designs with ARM32, PowerPC, MIPS or other CPU cores and they want to migrate to ARM64 because everyone else is doing that too. They ship whatever their customers want, but they care little about Windows support, or strict standards compliance as long as their customers are happy. There is a lot of opposition to ACPI both in the customer base and the upstream Linux community for these machines, so these are likely to stay with DT for the foreseeable future. In fact, fear over fragmentation with ACPI on these systems one of the issues currently holding up merging ACPI for the first category. Arnd ^ permalink raw reply [flat|nested] 186+ messages in thread
* Re: ACPI vs DT at runtime 2014-05-05 15:29 ` Alexander Holler @ 2014-05-06 15:37 ` Grant Likely -1 siblings, 0 replies; 186+ messages in thread From: Grant Likely @ 2014-05-06 15:37 UTC (permalink / raw) To: Alexander Holler, Arnd Bergmann Cc: devicetree, Russell King - ARM Linux, Catalin Marinas, Richard Cochran, Pantelis Antoniou, Jon Masters, Mark Brown, Olof Johansson, linux-arm-kernel On Mon, 05 May 2014 17:29:47 +0200, Alexander Holler <holler@ahsoftware.de> wrote: > Am 05.05.2014 16:41, schrieb Arnd Bergmann: > > On Monday 05 May 2014 09:06:14 Alexander Holler wrote: > >> > >> A bit late (I don't follow the ML (or what happens in the ARM world) > >> closely, but as I've recently read that ARM64 will go UEFI and ACPI, I > >> wonder what was the reasoning behind that decision. > >> > >> Does anyone really assume we will become high quality UEFI and ACPI > >> blobs from vendors? And such with reasonable support/update periods? > >> > >> For me that sounds like someone asked dreamers and was unable to adjust > >> those answers in regard to reality. > > > > Where did you read that? It's simply not true and we should make sure > > people stop spreading dangerous misinformation. > > I've recently read Grant Likely's blog entry about armv8 servers: > http://www.secretlab.ca/archives/27 (I've read the disclaimer too ;) ) The purpose of that blog post was to address the questions around ARM server architecture requirements including ACPI and UEFI, but there is a big gap between the requrement and what actually works now. ARM server hardware is going to be available well before UEFI and ACPI (especially ACPI) infrastructure has stablized. I was trying to lay a roadmap that acknowledges the gap and provides a way for vendors to ship hardware now that is supported by the mainline kernel. The constraints that are driving all of this on servers simply don't exist on embedded and mobile. There really is zero advantage to using ACPI if the only OS that will ever run on the device is Linux. g. ^ permalink raw reply [flat|nested] 186+ messages in thread
* ACPI vs DT at runtime @ 2014-05-06 15:37 ` Grant Likely 0 siblings, 0 replies; 186+ messages in thread From: Grant Likely @ 2014-05-06 15:37 UTC (permalink / raw) To: linux-arm-kernel On Mon, 05 May 2014 17:29:47 +0200, Alexander Holler <holler@ahsoftware.de> wrote: > Am 05.05.2014 16:41, schrieb Arnd Bergmann: > > On Monday 05 May 2014 09:06:14 Alexander Holler wrote: > >> > >> A bit late (I don't follow the ML (or what happens in the ARM world) > >> closely, but as I've recently read that ARM64 will go UEFI and ACPI, I > >> wonder what was the reasoning behind that decision. > >> > >> Does anyone really assume we will become high quality UEFI and ACPI > >> blobs from vendors? And such with reasonable support/update periods? > >> > >> For me that sounds like someone asked dreamers and was unable to adjust > >> those answers in regard to reality. > > > > Where did you read that? It's simply not true and we should make sure > > people stop spreading dangerous misinformation. > > I've recently read Grant Likely's blog entry about armv8 servers: > http://www.secretlab.ca/archives/27 (I've read the disclaimer too ;) ) The purpose of that blog post was to address the questions around ARM server architecture requirements including ACPI and UEFI, but there is a big gap between the requrement and what actually works now. ARM server hardware is going to be available well before UEFI and ACPI (especially ACPI) infrastructure has stablized. I was trying to lay a roadmap that acknowledges the gap and provides a way for vendors to ship hardware now that is supported by the mainline kernel. The constraints that are driving all of this on servers simply don't exist on embedded and mobile. There really is zero advantage to using ACPI if the only OS that will ever run on the device is Linux. g. ^ permalink raw reply [flat|nested] 186+ messages in thread
* Re: ACPI vs DT at runtime 2014-05-05 7:06 ` Alexander Holler @ 2014-05-06 15:27 ` Grant Likely -1 siblings, 0 replies; 186+ messages in thread From: Grant Likely @ 2014-05-06 15:27 UTC (permalink / raw) To: Alexander Holler, Pantelis Antoniou, Catalin Marinas Cc: devicetree, Russell King - ARM Linux, Richard Cochran, Olof Johansson, Mark Brown, Jon Masters, linux-arm-kernel On Mon, 05 May 2014 09:06:14 +0200, Alexander Holler <holler@ahsoftware.de> wrote: > Am 22.11.2013 13:00, schrieb Pantelis Antoniou: > > > As one that's going to be dealing with this, please don't take the DTS > > files from the kernel. > > > > If you do this, I can guarantee that within a year almost no ARM board using DT > > will boot a mainline kernel. > > > > The reason is that vendors have enough trouble (and failing) tracking a single > > tree, adding yet another will just end to the vendor trees as far as the eye can see. > > > > Maybe, maybe, EVMs from silicon vendors will still boot, but I doubt any other > > customer board will work. > > A bit late (I don't follow the ML (or what happens in the ARM world) > closely, but as I've recently read that ARM64 will go UEFI and ACPI, I > wonder what was the reasoning behind that decision. ARM64 will include support for UEFI an ACPI, but U-Boot and DT are not going away. Really the only market segment that will care about ACPI is ARM servers. Nobody else (embedded, mobile) needs to worry about it. g. ^ permalink raw reply [flat|nested] 186+ messages in thread
* ACPI vs DT at runtime @ 2014-05-06 15:27 ` Grant Likely 0 siblings, 0 replies; 186+ messages in thread From: Grant Likely @ 2014-05-06 15:27 UTC (permalink / raw) To: linux-arm-kernel On Mon, 05 May 2014 09:06:14 +0200, Alexander Holler <holler@ahsoftware.de> wrote: > Am 22.11.2013 13:00, schrieb Pantelis Antoniou: > > > As one that's going to be dealing with this, please don't take the DTS > > files from the kernel. > > > > If you do this, I can guarantee that within a year almost no ARM board using DT > > will boot a mainline kernel. > > > > The reason is that vendors have enough trouble (and failing) tracking a single > > tree, adding yet another will just end to the vendor trees as far as the eye can see. > > > > Maybe, maybe, EVMs from silicon vendors will still boot, but I doubt any other > > customer board will work. > > A bit late (I don't follow the ML (or what happens in the ARM world) > closely, but as I've recently read that ARM64 will go UEFI and ACPI, I > wonder what was the reasoning behind that decision. ARM64 will include support for UEFI an ACPI, but U-Boot and DT are not going away. Really the only market segment that will care about ACPI is ARM servers. Nobody else (embedded, mobile) needs to worry about it. g. ^ permalink raw reply [flat|nested] 186+ messages in thread
[parent not found: <20140506152725.E5B90C40959-WNowdnHR2B42iJbIjFUEsiwD8/FfD2ys@public.gmane.org>]
* Re: ACPI vs DT at runtime 2014-05-06 15:27 ` Grant Likely @ 2014-05-06 16:32 ` Olof Johansson -1 siblings, 0 replies; 186+ messages in thread From: Olof Johansson @ 2014-05-06 16:32 UTC (permalink / raw) To: Grant Likely Cc: Alexander Holler, Pantelis Antoniou, Catalin Marinas, devicetree-u79uwXL29TY76Z2rM5mHXA, Russell King - ARM Linux, Richard Cochran, Jon Masters, Mark Brown, linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r On Tue, May 6, 2014 at 8:27 AM, Grant Likely <grant.likely-s3s/WqlpOiPyB63q8FvJNQ@public.gmane.org> wrote: > On Mon, 05 May 2014 09:06:14 +0200, Alexander Holler <holler-SXC+2es9fhnfWeYVQQPykw@public.gmane.org> wrote: >> Am 22.11.2013 13:00, schrieb Pantelis Antoniou: >> >> > As one that's going to be dealing with this, please don't take the DTS >> > files from the kernel. >> > >> > If you do this, I can guarantee that within a year almost no ARM board using DT >> > will boot a mainline kernel. >> > >> > The reason is that vendors have enough trouble (and failing) tracking a single >> > tree, adding yet another will just end to the vendor trees as far as the eye can see. >> > >> > Maybe, maybe, EVMs from silicon vendors will still boot, but I doubt any other >> > customer board will work. >> >> A bit late (I don't follow the ML (or what happens in the ARM world) >> closely, but as I've recently read that ARM64 will go UEFI and ACPI, I >> wonder what was the reasoning behind that decision. > > ARM64 will include support for UEFI an ACPI, but U-Boot and DT are not > going away. Really the only market segment that will care about ACPI is > ARM servers. Nobody else (embedded, mobile) needs to worry about it. I do find it quite interesting to see what is actually launched by vendors though. The "enterprise" chipsets have not yet shown up. Or, rather, the only one that is out is X-Gene and it's not SBSA compliant and thus doesn't fall into the ACPI category. The AMD announcements yesterday clearly targets their chip to much broader markets than just enterprise ("high density servers" was the only market segment that overlaps somewhat with "enterprise" in their announcements). So, as Arnd and others have said for a while, it's definitely not a black and white picture we're looking at. The AMD chips, in particular, are targeted at mobile and embedded, but they share the non-CPU part of the SoC with x86. It'd be really interesting to hear what their plans are for software support of that, but they are so far absent from any discussions. I really hope they can crawl out of the woodwork and participate now that the roadmap is made public. -Olof -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org More majordomo info at http://vger.kernel.org/majordomo-info.html ^ permalink raw reply [flat|nested] 186+ messages in thread
* ACPI vs DT at runtime @ 2014-05-06 16:32 ` Olof Johansson 0 siblings, 0 replies; 186+ messages in thread From: Olof Johansson @ 2014-05-06 16:32 UTC (permalink / raw) To: linux-arm-kernel On Tue, May 6, 2014 at 8:27 AM, Grant Likely <grant.likely@secretlab.ca> wrote: > On Mon, 05 May 2014 09:06:14 +0200, Alexander Holler <holler@ahsoftware.de> wrote: >> Am 22.11.2013 13:00, schrieb Pantelis Antoniou: >> >> > As one that's going to be dealing with this, please don't take the DTS >> > files from the kernel. >> > >> > If you do this, I can guarantee that within a year almost no ARM board using DT >> > will boot a mainline kernel. >> > >> > The reason is that vendors have enough trouble (and failing) tracking a single >> > tree, adding yet another will just end to the vendor trees as far as the eye can see. >> > >> > Maybe, maybe, EVMs from silicon vendors will still boot, but I doubt any other >> > customer board will work. >> >> A bit late (I don't follow the ML (or what happens in the ARM world) >> closely, but as I've recently read that ARM64 will go UEFI and ACPI, I >> wonder what was the reasoning behind that decision. > > ARM64 will include support for UEFI an ACPI, but U-Boot and DT are not > going away. Really the only market segment that will care about ACPI is > ARM servers. Nobody else (embedded, mobile) needs to worry about it. I do find it quite interesting to see what is actually launched by vendors though. The "enterprise" chipsets have not yet shown up. Or, rather, the only one that is out is X-Gene and it's not SBSA compliant and thus doesn't fall into the ACPI category. The AMD announcements yesterday clearly targets their chip to much broader markets than just enterprise ("high density servers" was the only market segment that overlaps somewhat with "enterprise" in their announcements). So, as Arnd and others have said for a while, it's definitely not a black and white picture we're looking at. The AMD chips, in particular, are targeted at mobile and embedded, but they share the non-CPU part of the SoC with x86. It'd be really interesting to hear what their plans are for software support of that, but they are so far absent from any discussions. I really hope they can crawl out of the woodwork and participate now that the roadmap is made public. -Olof ^ permalink raw reply [flat|nested] 186+ messages in thread
* ACPI vs DT at runtime 2013-11-18 5:19 ` Jon Masters ` (3 preceding siblings ...) 2013-11-18 15:00 ` Mark Brown @ 2013-11-18 15:28 ` Rob Herring [not found] ` <5289A356.4060004-Zp4isUonpHBD60Wz+7aTrA@public.gmane.org> 2013-11-19 14:33 ` Grant Likely 6 siblings, 0 replies; 186+ messages in thread From: Rob Herring @ 2013-11-18 15:28 UTC (permalink / raw) To: linux-arm-kernel On Sun, Nov 17, 2013 at 11:19 PM, Jon Masters <jonathan@jonmasters.org> wrote: > Olof, thanks for starting this thread. Mark, thanks for the followup. > > Comments on both inline, below. But before I reply to the specific > points, let me add that this is clearly an emotional topic for many. > There are a great many companies involved in ARMv8 on servers, and a > great many have yet to say anything in public. I am trying to strike a > balance constantly by being fair to those who have announced and those > who have yet to do so. But regardless, we have one chance here to make a > good server platform that can challenge the incumbent architectures. If > I weren't utterly convinced of that, and of the need for such standards > as UEFI and ACPI, then I wouldn't be so vocal about it. Given who is > involved in this space, regardless of a decision to adopt ACPI now or > later, it is coming. It can be done right now, or not. > > I (and others) pushed 3 years ago for the adoption of ACPI. Dong, and > others instigated the legal processes that resulted in the movement of > ACPI under UEFI Forum recently, to become a fully open standard that can > be shaped - both by the Linux community, and by others. ACPI.next will > benefit from the same development process that has shaped UEFI standards > over the past few years, and most people here can easily get involved in > shaping that standard - as they can on x86 as well now. > > I am pushing for a few other things to become public that will help to > explain why ACPI is being adopted and provide a standardized description > of the ways in which it will be used/consumed. > > On 11/15/2013 04:57 AM, Mark Rutland wrote: >> On Fri, Nov 15, 2013 at 01:44:10AM +0000, Olof Johansson wrote: >>> The more I start to see early UEFI/ACPI code, the more I am certain >>> that we want none of that crap in the kernel. It's making things >>> considerably messier, while we're already very busy trying to convert >>> everything over and enable DT -- we'll be preempting that effort just >>> to add even more boilerplate everywhere and total progress will be >>> hurt. > > Firstly, I would note that I don't expect DeviceTree to go away. Only on > server class systems. I expect all server class ARMv8 systems in the > Enterprise/Cloud environment to boot using UEFI and ACPI. This is > certainly the case of most future design starts already underway. These > can either be supported properly, or not, but ignoring the impending > ACPI systems isn't practical. Translation won't work reliably either. > > For the record, I did suggest to Applied that the first posting of that > SATA driver not have the ACPI bits in (since we know it needs cleaning > up to use the key/value approaches already discussed, and so on), but > after chatting with Loc about it, it seemed reasonable to use the > opportunity to start a discussion - which seems to be on cue here. That and the Exynos SATA support are great examples of how ACPI won't help solve anything. Both are "standard AHCI" yet require lots of code at runtime that ACPI is simply not going abstract away. Even we had to do modifications for highbank due to an errata. What's to keep the next gen chips from changing because they will. New process technology will mean new phy which will no doubt have different programming or quirks. >> I'm of the opinion that the only way we should support ACPI is as a >> first-class citizen. > > There really isn't another way to do it in my opinion. > >> We don't need to modify every driver and subsystem >> to support ACPI, only those necessary to support the minimal set of >> platforms using ACPI. ACPI is new in the arm space, and we can enforce >> quality standards on ACPI _now_ above what we're allowing for DT, and >> avoid future problems. > > This is key. It's not going to be ACPI everywhere. It's going to be ACPI > on server class systems. And later, maybe some client systems. But the > big push is from the server crowd. We need to build systems that in 5-10 > years time can still boot an older kernel. This can't be done without a > standardized/versioned enumeration/discovery mechanism like ACPI that > has an API enshrined in stone as far as compatibility. Device Tree is > wonderful, anyone can make a binding and use it. Or change the binding > in the next kernel release. Or...this doesn't work in the server space. > Server platforms aren't vertically welded shut like in the embedded > space, where DeviceTree has brought all kinds of benefits for those > building with a single kernel for many different targets, but has also > seen a huge amount of churn from one kernel to the next. If I counted > the number of times I've been told "just update your dtb"...then I would > be shivering in the corner a sadden wreck. You can't "just update your > dtb" on a server class system. You shouldn't. I think people are being misled that ACPI somehow solves the problem of new systems just work. It doesn't. It is having a single platform, tons of legacy h/w or emulation of the h/w, and the ability to trap into the firmware. That all takes upfront design and verification requirements to achieve. This is not how the ARM world works. Yes, we have secret documents attempting to standardize things, but they are hardly sufficient. Using AHCI for SATA is specified, but the above example shows why this is insufficient. Granted, those chips were not designed to target any standardization doc, but I doubt anyone reads the doc and believes they are not already compliant. When it comes down to changing the kernel or spinning the Si, vendors are going to do the former. > But anyway, emotional plea aside, a very large number of ACPI systems > are coming. Yes, I've been pushing to get existing players to switch, > but that's because I know what is coming. And if you want certain other > players to appear in this space, you'll need to have ACPI for them, too. Well, first a large number of DT systems are coming because ACPI is simply not ready. Yes, some of the core ACPI support is getting in place, but until how to deal with it in drivers is worked out drivers are going to use DT. As this thread shows, there is currently nothing more than ideas thrown around of how to deal with both. >> There may even be things which we don't have to deal with at all on ACPI >> systems as used in servers (e.g. clock management), but perhaps we will >> if people see value in those elements. >> >>> The server guys really want UEFI for their boot protocols, >>> installation managers, etc, etc. That's fine, let them do that, but >>> that doesn't mean we need to bring the same APIs all the way into the >>> kernel. >>> >>> So, I'm strongly urging that whatever the server guys try to do, it >>> will in the end result in the ACPI data being translated into DT >>> equivalents, such that the kernel _only_ needs to handle data via DT. >> >> I'm not sure that translating ACPI tables to dt makes any sense. If AML >> is used (even sparingly), I do not believe that we can do any sensible >> conversion to device tree. My understanding is that AML includes >> functionality for modifying ACPI tables, and I don't see how we can >> possibly support that without having to add a lot of boilerplate to all >> the code handling AML to add a device tree backend... > > AML includes code that is runtime interpreted, for things like power > button emulation and the like. You can't just translate this. This comes > up every few years - it's impractical. You'll end up having to ship both > DTB and ACPI tables for a system. Which means two tables for a platform > vendor to get right. You know what will happen - only one table with be > correct. Perhaps it seems that it will be the DTB that is more correct, > and this might be true this week, but by 2016 I *guarantee* you that the > ACPI table will be the one winning. Perhaps we spend so much pointless effort on ACPI conversion rather than areas that really benefit end users that we win the battle and lose the war. Rob ^ permalink raw reply [flat|nested] 186+ messages in thread
[parent not found: <5289A356.4060004-Zp4isUonpHBD60Wz+7aTrA@public.gmane.org>]
* Re: ACPI vs DT at runtime 2013-11-18 5:19 ` Jon Masters @ 2013-11-18 19:09 ` Olof Johansson 2013-11-18 7:22 ` Richard Cochran ` (5 subsequent siblings) 6 siblings, 0 replies; 186+ messages in thread From: Olof Johansson @ 2013-11-18 19:09 UTC (permalink / raw) To: Jon Masters Cc: linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r, devicetree-u79uwXL29TY76Z2rM5mHXA, mark.rutland-5wv7dgnIgG8, grant.likely-s3s/WqlpOiPyB63q8FvJNQ, arnd-r2nGTMty4D4, robherring2-Re5JQEeQqe8AvxtiuMwx3w Jon, On Mon, Nov 18, 2013 at 12:19:18AM -0500, Jon Masters wrote: > Olof, thanks for starting this thread. Mark, thanks for the followup. Your mailer is dropping all ccs to your emails, so I didn't get a copy of this in my inbox. You might want to check the configuration at your end. I've added back the cc recipients. > Comments on both inline, below. But before I reply to the specific > points, let me add that this is clearly an emotional topic for many. I'm sorry that it's so emotional. Let's keep to technical arguments. > There are a great many companies involved in ARMv8 on servers, and a > great many have yet to say anything in public. I am trying to strike a > balance constantly by being fair to those who have announced and those > who have yet to do so. But regardless, we have one chance here to make a > good server platform that can challenge the incumbent architectures. If > I weren't utterly convinced of that, and of the need for such standards > as UEFI and ACPI, then I wouldn't be so vocal about it. Given who is > involved in this space, regardless of a decision to adopt ACPI now or > later, it is coming. It can be done right now, or not. And what I am saying here is that "not right now" is the right answer for the linux kernel. For technical reasons. > I (and others) pushed 3 years ago for the adoption of ACPI. Dong, and > others instigated the legal processes that resulted in the movement of > ACPI under UEFI Forum recently, to become a fully open standard that can > be shaped - both by the Linux community, and by others. ACPI.next will > benefit from the same development process that has shaped UEFI standards > over the past few years, and most people here can easily get involved in > shaping that standard - as they can on x86 as well now. > > I am pushing for a few other things to become public that will help to > explain why ACPI is being adopted and provide a standardized description > of the ways in which it will be used/consumed. Which in turn is DoS:ing linux development. Now we need to sign up for a third party committee to set the direction for the kernel? Sorry, that's not the way we do things around here. > On 11/15/2013 04:57 AM, Mark Rutland wrote: > > On Fri, Nov 15, 2013 at 01:44:10AM +0000, Olof Johansson wrote: > >> The more I start to see early UEFI/ACPI code, the more I am certain > >> that we want none of that crap in the kernel. It's making things > >> considerably messier, while we're already very busy trying to convert > >> everything over and enable DT -- we'll be preempting that effort just > >> to add even more boilerplate everywhere and total progress will be > >> hurt. > > Firstly, I would note that I don't expect DeviceTree to go away. Only on > server class systems. I expect all server class ARMv8 systems in the > Enterprise/Cloud environment to boot using UEFI and ACPI. This is > certainly the case of most future design starts already underway. These > can either be supported properly, or not, but ignoring the impending > ACPI systems isn't practical. Trust me, we're not going to ignore them, we want them supported. > Translation won't work reliably either. Nothing is going to work reliably with ACPI right now, period. It's a completely immature technology on ARM, and if we lock in hard to the current implementaitons we're all going to lose. Big. You have yet to address that part of the argument in any of your replies. It's taken us years to sort out device tree, and we've been able to cope with it by the fact that we have been able to change both sides of the border (both the DTB and the kernel). With ACPI, we're entering a hard lock-in on day one. Meanwhile the very first patches look considerably worse than any of the first device-tree ones did, and vendors are clearly not getting help from you. > For the record, I did suggest to Applied that the first posting of that > SATA driver not have the ACPI bits in (since we know it needs cleaning > up to use the key/value approaches already discussed, and so on), but > after chatting with Loc about it, it seemed reasonable to use the > opportunity to start a discussion - which seems to be on cue here. Nice. > > I'm of the opinion that the only way we should support ACPI is as a > > first-class citizen. > > There really isn't another way to do it in my opinion. There is. Apple, IBM and Sun obviously figured out how to ship enterprise systems without ACPI, didn't they? > > We don't need to modify every driver and subsystem > > to support ACPI, only those necessary to support the minimal set of > > platforms using ACPI. ACPI is new in the arm space, and we can enforce > > quality standards on ACPI _now_ above what we're allowing for DT, and > > avoid future problems. > > This is key. It's not going to be ACPI everywhere. It's going to be ACPI > on server class systems. And later, maybe some client systems. But the > big push is from the server crowd. Market segment is irrellevant to the discussion at hand. > We need to build systems that in 5-10 > years time can still boot an older kernel. This can't be done without a > standardized/versioned enumeration/discovery mechanism like ACPI that > has an API enshrined in stone as far as compatibility. Device Tree is > wonderful, anyone can make a binding and use it. Or change the binding > in the next kernel release. Clearly you haven't been following any of the recent development w.r.t. device tree and the policy changes on backwards compatibility. What makes you so sure that vendors won't do crazy custom stuff on top of ACPI? You seem confident that they'll be able to sort it out themselves. Initial data on the subject indicates the polar opposite. > Or...this doesn't work in the server space. > Server platforms aren't vertically welded shut like in the embedded > space, where DeviceTree has brought all kinds of benefits for those > building with a single kernel for many different targets, but has also > seen a huge amount of churn from one kernel to the next. If I counted > the number of times I've been told "just update your dtb"...then I would > be shivering in the corner a sadden wreck. You can't "just update your > dtb" on a server class system. You shouldn't. You know why you've been asked to update the device trees? Because everyone is trying to figure out how to make this all work in a good way. With ACPI, there's _no way_ to do any of that. And you think that's a good thing? It's not, because the alternative is to start littering the kernel with lots and lots of quirks and fixups. > But anyway, emotional plea aside, a very large number of ACPI systems > are coming. Yes, I've been pushing to get existing players to switch, > but that's because I know what is coming. And if you want certain other > players to appear in this space, you'll need to have ACPI for them, too. I think what concerns me the most about the current situation is exactly this. You've been scheming for several years now, and now when push comes to shove, it's obvious that the vendors have no idea what they're doing with ACPI. Whenever there's a discussion about it, we get thrown these kind of vague "oh you'll see what's coming" arguments. Sure, we will, but until we see these promised awesome things in public, we're going to base things on what we know and see. And what we've seen so far is not promising. It's looking like in the short to medium term, locking ourselves to ACPI, on any platforms, is going to be a huge mistake. ACPI long-term might be a great thing, once vendors have gone through a couple of product generations and everybody has learned how to use ACPI properly. Until then we're building up a huge technical debt that we'll have to carry forever. Implement ACPI if you want, but while all those things are sorted out, we'll continue shipping device tree. If you look at the Calxeda DT sources, they've been completely table for quite a while now. It can, and will, be done. > > There may even be things which we don't have to deal with at all on ACPI > > systems as used in servers (e.g. clock management), but perhaps we will > > if people see value in those elements. > > > >> The server guys really want UEFI for their boot protocols, > >> installation managers, etc, etc. That's fine, let them do that, but > >> that doesn't mean we need to bring the same APIs all the way into the > >> kernel. > >> > >> So, I'm strongly urging that whatever the server guys try to do, it > >> will in the end result in the ACPI data being translated into DT > >> equivalents, such that the kernel _only_ needs to handle data via DT. > > > > I'm not sure that translating ACPI tables to dt makes any sense. If AML > > is used (even sparingly), I do not believe that we can do any sensible > > conversion to device tree. My understanding is that AML includes > > functionality for modifying ACPI tables, and I don't see how we can > > possibly support that without having to add a lot of boilerplate to all > > the code handling AML to add a device tree backend... > > AML includes code that is runtime interpreted, for things like power > button emulation and the like. You can't just translate this. This comes > up every few years - it's impractical. You'll end up having to ship both > DTB and ACPI tables for a system. Which means two tables for a platform > vendor to get right. Nobody is talking about removing the AML pieces here. Keep them around, but bring them over to the DT implementation if you have to. > You know what will happen - only one table with be > correct. Perhaps it seems that it will be the DTB that is more correct, > and this might be true this week, but by 2016 I *guarantee* you that the > ACPI table will be the one winning. Actually, that's an excellent approach to the problem at hand and pretty the ideal outcome as far as I am concerned. Focus on DT now, enable ACPI as much as possible but it won't be right yet so don't rely on it. In a few years, when ACPI looks like it's sorted out and reliable, we can switch over to it. > > I think that trying to shoe-horn ACPI-derived information into device > > tree is fundamentally the wrong approach. I don't think it encourages > > best practices, and I don't think it's beneficial to the long term > > health of Linux or the ecosystem as a whole. > > It's going to be a messy thing to even attempt. Look, I wish we had a > time machine and could have done this whole thing years ago, but I'm not > sure it would have gone differently. ACPI is something a lot of people > emotionally hate. Again, I am not approaching this emotionally. I'm looking at the quality of the initial submissions (very poor and confused), the readiness of the kernel in general (none so far), the way the involved parties are doing development (away from the community and in their own little world). I also look at some of the bottlenecks we've had with device tree (reviewer bandwidth, slow-moving consensus/standards-driven approval process) and how it compares to the ACPI counterparts (standards forum). The conclusion is that we're about to embark onto something that isn't going to be done right in the short to medium term. It just isn't. The sooner we own up to that, the sooner we can course-correct and get back to something that's likely to work. The alternative is signing onto a setup that _will_ stumble right out of the door, which in turn will mean that the high-end ARM play will be off to a rough start instead of running as smoothly as possible. > In the Enterprise space myself and others *need* it > (along with UEFI) to have a scalable solution that doesn't result in an > onslaught of customer support calls, which a non-standards body backed > moving target of DTB will do. And besides all of the big boys are going > to be using ACPI whether it's liked much or not. I'm glad you've found your home with the big boys. Meanwhile, us low-lifes working on the kernel have a job to do, which is to make sure the lower parts of the stack will be successful on these new environments long-term, which might have short-term difficult trade-offs. ACPI is not realistic today, for all the reasons explained above. -Olof -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org More majordomo info at http://vger.kernel.org/majordomo-info.html ^ permalink raw reply [flat|nested] 186+ messages in thread
* ACPI vs DT at runtime @ 2013-11-18 19:09 ` Olof Johansson 0 siblings, 0 replies; 186+ messages in thread From: Olof Johansson @ 2013-11-18 19:09 UTC (permalink / raw) To: linux-arm-kernel Jon, On Mon, Nov 18, 2013 at 12:19:18AM -0500, Jon Masters wrote: > Olof, thanks for starting this thread. Mark, thanks for the followup. Your mailer is dropping all ccs to your emails, so I didn't get a copy of this in my inbox. You might want to check the configuration at your end. I've added back the cc recipients. > Comments on both inline, below. But before I reply to the specific > points, let me add that this is clearly an emotional topic for many. I'm sorry that it's so emotional. Let's keep to technical arguments. > There are a great many companies involved in ARMv8 on servers, and a > great many have yet to say anything in public. I am trying to strike a > balance constantly by being fair to those who have announced and those > who have yet to do so. But regardless, we have one chance here to make a > good server platform that can challenge the incumbent architectures. If > I weren't utterly convinced of that, and of the need for such standards > as UEFI and ACPI, then I wouldn't be so vocal about it. Given who is > involved in this space, regardless of a decision to adopt ACPI now or > later, it is coming. It can be done right now, or not. And what I am saying here is that "not right now" is the right answer for the linux kernel. For technical reasons. > I (and others) pushed 3 years ago for the adoption of ACPI. Dong, and > others instigated the legal processes that resulted in the movement of > ACPI under UEFI Forum recently, to become a fully open standard that can > be shaped - both by the Linux community, and by others. ACPI.next will > benefit from the same development process that has shaped UEFI standards > over the past few years, and most people here can easily get involved in > shaping that standard - as they can on x86 as well now. > > I am pushing for a few other things to become public that will help to > explain why ACPI is being adopted and provide a standardized description > of the ways in which it will be used/consumed. Which in turn is DoS:ing linux development. Now we need to sign up for a third party committee to set the direction for the kernel? Sorry, that's not the way we do things around here. > On 11/15/2013 04:57 AM, Mark Rutland wrote: > > On Fri, Nov 15, 2013 at 01:44:10AM +0000, Olof Johansson wrote: > >> The more I start to see early UEFI/ACPI code, the more I am certain > >> that we want none of that crap in the kernel. It's making things > >> considerably messier, while we're already very busy trying to convert > >> everything over and enable DT -- we'll be preempting that effort just > >> to add even more boilerplate everywhere and total progress will be > >> hurt. > > Firstly, I would note that I don't expect DeviceTree to go away. Only on > server class systems. I expect all server class ARMv8 systems in the > Enterprise/Cloud environment to boot using UEFI and ACPI. This is > certainly the case of most future design starts already underway. These > can either be supported properly, or not, but ignoring the impending > ACPI systems isn't practical. Trust me, we're not going to ignore them, we want them supported. > Translation won't work reliably either. Nothing is going to work reliably with ACPI right now, period. It's a completely immature technology on ARM, and if we lock in hard to the current implementaitons we're all going to lose. Big. You have yet to address that part of the argument in any of your replies. It's taken us years to sort out device tree, and we've been able to cope with it by the fact that we have been able to change both sides of the border (both the DTB and the kernel). With ACPI, we're entering a hard lock-in on day one. Meanwhile the very first patches look considerably worse than any of the first device-tree ones did, and vendors are clearly not getting help from you. > For the record, I did suggest to Applied that the first posting of that > SATA driver not have the ACPI bits in (since we know it needs cleaning > up to use the key/value approaches already discussed, and so on), but > after chatting with Loc about it, it seemed reasonable to use the > opportunity to start a discussion - which seems to be on cue here. Nice. > > I'm of the opinion that the only way we should support ACPI is as a > > first-class citizen. > > There really isn't another way to do it in my opinion. There is. Apple, IBM and Sun obviously figured out how to ship enterprise systems without ACPI, didn't they? > > We don't need to modify every driver and subsystem > > to support ACPI, only those necessary to support the minimal set of > > platforms using ACPI. ACPI is new in the arm space, and we can enforce > > quality standards on ACPI _now_ above what we're allowing for DT, and > > avoid future problems. > > This is key. It's not going to be ACPI everywhere. It's going to be ACPI > on server class systems. And later, maybe some client systems. But the > big push is from the server crowd. Market segment is irrellevant to the discussion at hand. > We need to build systems that in 5-10 > years time can still boot an older kernel. This can't be done without a > standardized/versioned enumeration/discovery mechanism like ACPI that > has an API enshrined in stone as far as compatibility. Device Tree is > wonderful, anyone can make a binding and use it. Or change the binding > in the next kernel release. Clearly you haven't been following any of the recent development w.r.t. device tree and the policy changes on backwards compatibility. What makes you so sure that vendors won't do crazy custom stuff on top of ACPI? You seem confident that they'll be able to sort it out themselves. Initial data on the subject indicates the polar opposite. > Or...this doesn't work in the server space. > Server platforms aren't vertically welded shut like in the embedded > space, where DeviceTree has brought all kinds of benefits for those > building with a single kernel for many different targets, but has also > seen a huge amount of churn from one kernel to the next. If I counted > the number of times I've been told "just update your dtb"...then I would > be shivering in the corner a sadden wreck. You can't "just update your > dtb" on a server class system. You shouldn't. You know why you've been asked to update the device trees? Because everyone is trying to figure out how to make this all work in a good way. With ACPI, there's _no way_ to do any of that. And you think that's a good thing? It's not, because the alternative is to start littering the kernel with lots and lots of quirks and fixups. > But anyway, emotional plea aside, a very large number of ACPI systems > are coming. Yes, I've been pushing to get existing players to switch, > but that's because I know what is coming. And if you want certain other > players to appear in this space, you'll need to have ACPI for them, too. I think what concerns me the most about the current situation is exactly this. You've been scheming for several years now, and now when push comes to shove, it's obvious that the vendors have no idea what they're doing with ACPI. Whenever there's a discussion about it, we get thrown these kind of vague "oh you'll see what's coming" arguments. Sure, we will, but until we see these promised awesome things in public, we're going to base things on what we know and see. And what we've seen so far is not promising. It's looking like in the short to medium term, locking ourselves to ACPI, on any platforms, is going to be a huge mistake. ACPI long-term might be a great thing, once vendors have gone through a couple of product generations and everybody has learned how to use ACPI properly. Until then we're building up a huge technical debt that we'll have to carry forever. Implement ACPI if you want, but while all those things are sorted out, we'll continue shipping device tree. If you look at the Calxeda DT sources, they've been completely table for quite a while now. It can, and will, be done. > > There may even be things which we don't have to deal with at all on ACPI > > systems as used in servers (e.g. clock management), but perhaps we will > > if people see value in those elements. > > > >> The server guys really want UEFI for their boot protocols, > >> installation managers, etc, etc. That's fine, let them do that, but > >> that doesn't mean we need to bring the same APIs all the way into the > >> kernel. > >> > >> So, I'm strongly urging that whatever the server guys try to do, it > >> will in the end result in the ACPI data being translated into DT > >> equivalents, such that the kernel _only_ needs to handle data via DT. > > > > I'm not sure that translating ACPI tables to dt makes any sense. If AML > > is used (even sparingly), I do not believe that we can do any sensible > > conversion to device tree. My understanding is that AML includes > > functionality for modifying ACPI tables, and I don't see how we can > > possibly support that without having to add a lot of boilerplate to all > > the code handling AML to add a device tree backend... > > AML includes code that is runtime interpreted, for things like power > button emulation and the like. You can't just translate this. This comes > up every few years - it's impractical. You'll end up having to ship both > DTB and ACPI tables for a system. Which means two tables for a platform > vendor to get right. Nobody is talking about removing the AML pieces here. Keep them around, but bring them over to the DT implementation if you have to. > You know what will happen - only one table with be > correct. Perhaps it seems that it will be the DTB that is more correct, > and this might be true this week, but by 2016 I *guarantee* you that the > ACPI table will be the one winning. Actually, that's an excellent approach to the problem at hand and pretty the ideal outcome as far as I am concerned. Focus on DT now, enable ACPI as much as possible but it won't be right yet so don't rely on it. In a few years, when ACPI looks like it's sorted out and reliable, we can switch over to it. > > I think that trying to shoe-horn ACPI-derived information into device > > tree is fundamentally the wrong approach. I don't think it encourages > > best practices, and I don't think it's beneficial to the long term > > health of Linux or the ecosystem as a whole. > > It's going to be a messy thing to even attempt. Look, I wish we had a > time machine and could have done this whole thing years ago, but I'm not > sure it would have gone differently. ACPI is something a lot of people > emotionally hate. Again, I am not approaching this emotionally. I'm looking at the quality of the initial submissions (very poor and confused), the readiness of the kernel in general (none so far), the way the involved parties are doing development (away from the community and in their own little world). I also look at some of the bottlenecks we've had with device tree (reviewer bandwidth, slow-moving consensus/standards-driven approval process) and how it compares to the ACPI counterparts (standards forum). The conclusion is that we're about to embark onto something that isn't going to be done right in the short to medium term. It just isn't. The sooner we own up to that, the sooner we can course-correct and get back to something that's likely to work. The alternative is signing onto a setup that _will_ stumble right out of the door, which in turn will mean that the high-end ARM play will be off to a rough start instead of running as smoothly as possible. > In the Enterprise space myself and others *need* it > (along with UEFI) to have a scalable solution that doesn't result in an > onslaught of customer support calls, which a non-standards body backed > moving target of DTB will do. And besides all of the big boys are going > to be using ACPI whether it's liked much or not. I'm glad you've found your home with the big boys. Meanwhile, us low-lifes working on the kernel have a job to do, which is to make sure the lower parts of the stack will be successful on these new environments long-term, which might have short-term difficult trade-offs. ACPI is not realistic today, for all the reasons explained above. -Olof ^ permalink raw reply [flat|nested] 186+ messages in thread
[parent not found: <20131118190929.GA5886-O5ziIzlqnXUVNXGz7ipsyg@public.gmane.org>]
* Re: ACPI vs DT at runtime 2013-11-18 19:09 ` Olof Johansson @ 2013-11-18 20:54 ` Jon Masters -1 siblings, 0 replies; 186+ messages in thread From: Jon Masters @ 2013-11-18 20:54 UTC (permalink / raw) To: Olof Johansson Cc: linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r, devicetree-u79uwXL29TY76Z2rM5mHXA, mark.rutland-5wv7dgnIgG8, grant.likely-s3s/WqlpOiPyB63q8FvJNQ, arnd-r2nGTMty4D4, robherring2-Re5JQEeQqe8AvxtiuMwx3w Hi Olof, On 11/18/2013 02:09 PM, Olof Johansson wrote: > Jon, > > On Mon, Nov 18, 2013 at 12:19:18AM -0500, Jon Masters wrote: >> Olof, thanks for starting this thread. Mark, thanks for the followup. > > Your mailer is dropping all ccs to your emails, so I didn't get a copy of this > in my inbox. You might want to check the configuration at your end. I need to shoot Thunderbird for all kinds of reasons unrelated to this. I actually am having to alternate with another laptop right now to do email because this Thunderbird build I am running is just so sluggish and nasty (and the other laptop setup is what is broken). But anyway, that's something I need to fix, thanks for fixing the CCs. > I've added back the cc recipients. > >> Comments on both inline, below. But before I reply to the specific >> points, let me add that this is clearly an emotional topic for many. > > I'm sorry that it's so emotional. Let's keep to technical arguments. I agree with you. I got worried on Friday when I saw a discussion effectively leading with (what I read as) "let's ban all ACPI", which really got me concerned. But then again, I've been in bed most of the weekend sick, so I probably miss-read your intention. I apologize. >> There are a great many companies involved in ARMv8 on servers, and a >> great many have yet to say anything in public. I am trying to strike a >> balance constantly by being fair to those who have announced and those >> who have yet to do so. But regardless, we have one chance here to make a >> good server platform that can challenge the incumbent architectures. If >> I weren't utterly convinced of that, and of the need for such standards >> as UEFI and ACPI, then I wouldn't be so vocal about it. Given who is >> involved in this space, regardless of a decision to adopt ACPI now or >> later, it is coming. It can be done right now, or not. > > And what I am saying here is that "not right now" is the right answer > for the linux kernel. For technical reasons. I believe we can skip a lot of other conversation if I can summarize something from this thread. Is it the case that you believe there is room for both codepaths to exist in the upstream kernel, and for ACPI to mature over time as it becomes "more ready"? If the above is the case, then I don't think we disagree at all! I don't want to kill DeviceTree, I just know (or think I do) that ACPI is going to be the dominant force on v8 server systems. It worries me if there's no way to let ACPI code be merged upstream until it's completely figured out. I hope I am reading the rest of the thread correctly and understand instead that you're saying there can be a path for both, and perhaps those of us who require ACPI can simply state that up front and work with partners to ensure support for those ACPI platforms is available - and binding fixes to the standard made - while those same server platforms might also be supported by a DeviceTree at the same time for a period of whatever transition is required. That seems totally acceptable. I don't see any reason why the same binary kernel image can't boot with either a DTB or an ACPI table and indeed that would be my preference. Some of us can require it be ACPI by policy, but others can build kernels that use DTB on v8 servers if that's what they need while the whole thing shakes itself out. >> In the Enterprise space myself and others *need* it >> (along with UEFI) to have a scalable solution that doesn't result in an >> onslaught of customer support calls, which a non-standards body backed >> moving target of DTB will do. And besides all of the big boys are going >> to be using ACPI whether it's liked much or not. > > I'm glad you've found your home with the big boys. Meanwhile, us low-lifes > working on the kernel have a job to do, which is to make sure the lower parts > of the stack will be successful on these new environments long-term, > which might have short-term difficult trade-offs. ACPI is not realistic > today, for all the reasons explained above. Gah. I didn't mean to come across as offensive. Just worried. I'm in an uncomfortable position that there are limits on what I can share about what people are doing. I don't like or enjoy this one bit. I am pushing for various things to change. I know it sounds like I'm sitting in a big room with a Dr. Evil style conference table going on, but that's not the reality. I *really* truly want ARM servers to be successful in the marketplace and I know it will only happen (longer term) with ACPI. But I agree the ACPI story is very much a work in progress right now. I just want to know that there can be an upstream dual/stack ACPI story while this is figured out - waiting years for that is going to be very unfortunate to the overall cause. I wouldn't sound so passionate about this if I weren't totally convinced of this reality. Jon. -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org More majordomo info at http://vger.kernel.org/majordomo-info.html ^ permalink raw reply [flat|nested] 186+ messages in thread
* ACPI vs DT at runtime @ 2013-11-18 20:54 ` Jon Masters 0 siblings, 0 replies; 186+ messages in thread From: Jon Masters @ 2013-11-18 20:54 UTC (permalink / raw) To: linux-arm-kernel Hi Olof, On 11/18/2013 02:09 PM, Olof Johansson wrote: > Jon, > > On Mon, Nov 18, 2013 at 12:19:18AM -0500, Jon Masters wrote: >> Olof, thanks for starting this thread. Mark, thanks for the followup. > > Your mailer is dropping all ccs to your emails, so I didn't get a copy of this > in my inbox. You might want to check the configuration at your end. I need to shoot Thunderbird for all kinds of reasons unrelated to this. I actually am having to alternate with another laptop right now to do email because this Thunderbird build I am running is just so sluggish and nasty (and the other laptop setup is what is broken). But anyway, that's something I need to fix, thanks for fixing the CCs. > I've added back the cc recipients. > >> Comments on both inline, below. But before I reply to the specific >> points, let me add that this is clearly an emotional topic for many. > > I'm sorry that it's so emotional. Let's keep to technical arguments. I agree with you. I got worried on Friday when I saw a discussion effectively leading with (what I read as) "let's ban all ACPI", which really got me concerned. But then again, I've been in bed most of the weekend sick, so I probably miss-read your intention. I apologize. >> There are a great many companies involved in ARMv8 on servers, and a >> great many have yet to say anything in public. I am trying to strike a >> balance constantly by being fair to those who have announced and those >> who have yet to do so. But regardless, we have one chance here to make a >> good server platform that can challenge the incumbent architectures. If >> I weren't utterly convinced of that, and of the need for such standards >> as UEFI and ACPI, then I wouldn't be so vocal about it. Given who is >> involved in this space, regardless of a decision to adopt ACPI now or >> later, it is coming. It can be done right now, or not. > > And what I am saying here is that "not right now" is the right answer > for the linux kernel. For technical reasons. I believe we can skip a lot of other conversation if I can summarize something from this thread. Is it the case that you believe there is room for both codepaths to exist in the upstream kernel, and for ACPI to mature over time as it becomes "more ready"? If the above is the case, then I don't think we disagree at all! I don't want to kill DeviceTree, I just know (or think I do) that ACPI is going to be the dominant force on v8 server systems. It worries me if there's no way to let ACPI code be merged upstream until it's completely figured out. I hope I am reading the rest of the thread correctly and understand instead that you're saying there can be a path for both, and perhaps those of us who require ACPI can simply state that up front and work with partners to ensure support for those ACPI platforms is available - and binding fixes to the standard made - while those same server platforms might also be supported by a DeviceTree at the same time for a period of whatever transition is required. That seems totally acceptable. I don't see any reason why the same binary kernel image can't boot with either a DTB or an ACPI table and indeed that would be my preference. Some of us can require it be ACPI by policy, but others can build kernels that use DTB on v8 servers if that's what they need while the whole thing shakes itself out. >> In the Enterprise space myself and others *need* it >> (along with UEFI) to have a scalable solution that doesn't result in an >> onslaught of customer support calls, which a non-standards body backed >> moving target of DTB will do. And besides all of the big boys are going >> to be using ACPI whether it's liked much or not. > > I'm glad you've found your home with the big boys. Meanwhile, us low-lifes > working on the kernel have a job to do, which is to make sure the lower parts > of the stack will be successful on these new environments long-term, > which might have short-term difficult trade-offs. ACPI is not realistic > today, for all the reasons explained above. Gah. I didn't mean to come across as offensive. Just worried. I'm in an uncomfortable position that there are limits on what I can share about what people are doing. I don't like or enjoy this one bit. I am pushing for various things to change. I know it sounds like I'm sitting in a big room with a Dr. Evil style conference table going on, but that's not the reality. I *really* truly want ARM servers to be successful in the marketplace and I know it will only happen (longer term) with ACPI. But I agree the ACPI story is very much a work in progress right now. I just want to know that there can be an upstream dual/stack ACPI story while this is figured out - waiting years for that is going to be very unfortunate to the overall cause. I wouldn't sound so passionate about this if I weren't totally convinced of this reality. Jon. ^ permalink raw reply [flat|nested] 186+ messages in thread
[parent not found: <528A7EA0.9050101-Zp4isUonpHBD60Wz+7aTrA@public.gmane.org>]
* Re: ACPI vs DT at runtime 2013-11-18 20:54 ` Jon Masters @ 2013-11-18 21:50 ` Olof Johansson -1 siblings, 0 replies; 186+ messages in thread From: Olof Johansson @ 2013-11-18 21:50 UTC (permalink / raw) To: Jon Masters Cc: linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r, devicetree-u79uwXL29TY76Z2rM5mHXA, mark.rutland-5wv7dgnIgG8, grant.likely-s3s/WqlpOiPyB63q8FvJNQ, arnd-r2nGTMty4D4, robherring2-Re5JQEeQqe8AvxtiuMwx3w Hi, On Mon, Nov 18, 2013 at 03:54:56PM -0500, Jon Masters wrote: > Hi Olof, > > On 11/18/2013 02:09 PM, Olof Johansson wrote: > > Jon, > > > > On Mon, Nov 18, 2013 at 12:19:18AM -0500, Jon Masters wrote: > >> Olof, thanks for starting this thread. Mark, thanks for the followup. > > > > Your mailer is dropping all ccs to your emails, so I didn't get a copy of this > > in my inbox. You might want to check the configuration at your end. > > I need to shoot Thunderbird for all kinds of reasons unrelated to this. > I actually am having to alternate with another laptop right now to do > email because this Thunderbird build I am running is just so sluggish > and nasty (and the other laptop setup is what is broken). But anyway, > that's something I need to fix, thanks for fixing the CCs. > > > I've added back the cc recipients. > > > >> Comments on both inline, below. But before I reply to the specific > >> points, let me add that this is clearly an emotional topic for many. > > > > I'm sorry that it's so emotional. Let's keep to technical arguments. > > I agree with you. I got worried on Friday when I saw a discussion > effectively leading with (what I read as) "let's ban all ACPI", which > really got me concerned. But then again, I've been in bed most of the > weekend sick, so I probably miss-read your intention. I apologize. My stance is the same as last week: ACPI is the wrong tool for the job at this time on ARM. The job in question is kernel and device runtime configuration. In the future, it might be more suitable, but likely not for at least a couple of years, maybe more. Making strict statements about its use in the future seems counterproductive at this time since there's no guarantee that it'll reach that point in a given timeframe. Maybe it will for some firmware vendors and platform vendors, while for others it won't, etc. > >> There are a great many companies involved in ARMv8 on servers, and a > >> great many have yet to say anything in public. I am trying to strike a > >> balance constantly by being fair to those who have announced and those > >> who have yet to do so. But regardless, we have one chance here to make a > >> good server platform that can challenge the incumbent architectures. If > >> I weren't utterly convinced of that, and of the need for such standards > >> as UEFI and ACPI, then I wouldn't be so vocal about it. Given who is > >> involved in this space, regardless of a decision to adopt ACPI now or > >> later, it is coming. It can be done right now, or not. > > > > And what I am saying here is that "not right now" is the right answer > > for the linux kernel. For technical reasons. > > I believe we can skip a lot of other conversation if I can summarize > something from this thread. Is it the case that you believe there is > room for both codepaths to exist in the upstream kernel, and for ACPI to > mature over time as it becomes "more ready"? As my original email said, I don't think there's a reason to pick up and pollute the whole kernel with double code paths at this time, while the vendors using ACPI is still trying to figure out what to do and how to do it. It's better to keep it out of the kernel, especially since it will require either re-abstracting all drivers and subsystems, or adding dual code paths to them for platform support that is likely to change. Until then, if someone wants to boot with ACPI, then the best path would be to translate as much of the simple data over to device tree and boot with that as the in-kernel abstraction layer. That can be done at boot or by crafting static device trees. Likely the first few generations of hardware will not have elaborate complex AML-based ACPI workarounds for stuff in the first place, so chances are this will not be a big issue. If, down the road, ACPI seems to have their act together, have worked out their kinks and reached a usable stable platform, then we can consider bringing in the parts of it that doesn't make the kernel explode in complexity and messiness. When this will be is impossible to predict today, but I expect it to take a couple of years and some generations of hardware. > If the above is the case, then I don't think we disagree at all! I don't > want to kill DeviceTree, I just know (or think I do) that ACPI is going > to be the dominant force on v8 server systems. It worries me if there's > no way to let ACPI code be merged upstream until it's completely figured > out. I hope I am reading the rest of the thread correctly and understand > instead that you're saying there can be a path for both, and perhaps > those of us who require ACPI can simply state that up front and work > with partners to ensure support for those ACPI platforms is available - > and binding fixes to the standard made - while those same server > platforms might also be supported by a DeviceTree at the same time for a > period of whatever transition is required. That seems totally > acceptable. I don't see any reason why the same binary kernel image > can't boot with either a DTB or an ACPI table and indeed that would be > my preference. Some of us can require it be ACPI by policy, but others > can build kernels that use DTB on v8 servers if that's what they need > while the whole thing shakes itself out. Again, merging a substantial amount of ACPI enablement is premature for the reasons already stated in the thread; it adds complexity and is likely to churn several times as vendors figure out just how to work with it. The two examples at hand (APM SATA and Exynos AHCI) both indicate that. While vendors are free to implement it in their firmware, we are much better off not relying on it right now. ACPI was messy on x86 in the beginning too. Luckily we have an alternative that will get the work done while the rest is being worked out. So, if we're not going to merge the ACPI-enabling code yet, mandating ACPI for booting isn't going to work if you expect to rely on native-all-the-way-through-the-kernel ACPI implementation. It will however work to some extent for the ACPI-to-DT approach, given that the platforms are kept reasonably simplistic. And if it doesn't, we can fall back to static DT and native implementation of whatever stuff ACPI would have abstracted for us (clock drivers, reset drivers) if we really have to. -Olof -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org More majordomo info at http://vger.kernel.org/majordomo-info.html ^ permalink raw reply [flat|nested] 186+ messages in thread
* ACPI vs DT at runtime @ 2013-11-18 21:50 ` Olof Johansson 0 siblings, 0 replies; 186+ messages in thread From: Olof Johansson @ 2013-11-18 21:50 UTC (permalink / raw) To: linux-arm-kernel Hi, On Mon, Nov 18, 2013 at 03:54:56PM -0500, Jon Masters wrote: > Hi Olof, > > On 11/18/2013 02:09 PM, Olof Johansson wrote: > > Jon, > > > > On Mon, Nov 18, 2013 at 12:19:18AM -0500, Jon Masters wrote: > >> Olof, thanks for starting this thread. Mark, thanks for the followup. > > > > Your mailer is dropping all ccs to your emails, so I didn't get a copy of this > > in my inbox. You might want to check the configuration at your end. > > I need to shoot Thunderbird for all kinds of reasons unrelated to this. > I actually am having to alternate with another laptop right now to do > email because this Thunderbird build I am running is just so sluggish > and nasty (and the other laptop setup is what is broken). But anyway, > that's something I need to fix, thanks for fixing the CCs. > > > I've added back the cc recipients. > > > >> Comments on both inline, below. But before I reply to the specific > >> points, let me add that this is clearly an emotional topic for many. > > > > I'm sorry that it's so emotional. Let's keep to technical arguments. > > I agree with you. I got worried on Friday when I saw a discussion > effectively leading with (what I read as) "let's ban all ACPI", which > really got me concerned. But then again, I've been in bed most of the > weekend sick, so I probably miss-read your intention. I apologize. My stance is the same as last week: ACPI is the wrong tool for the job at this time on ARM. The job in question is kernel and device runtime configuration. In the future, it might be more suitable, but likely not for at least a couple of years, maybe more. Making strict statements about its use in the future seems counterproductive at this time since there's no guarantee that it'll reach that point in a given timeframe. Maybe it will for some firmware vendors and platform vendors, while for others it won't, etc. > >> There are a great many companies involved in ARMv8 on servers, and a > >> great many have yet to say anything in public. I am trying to strike a > >> balance constantly by being fair to those who have announced and those > >> who have yet to do so. But regardless, we have one chance here to make a > >> good server platform that can challenge the incumbent architectures. If > >> I weren't utterly convinced of that, and of the need for such standards > >> as UEFI and ACPI, then I wouldn't be so vocal about it. Given who is > >> involved in this space, regardless of a decision to adopt ACPI now or > >> later, it is coming. It can be done right now, or not. > > > > And what I am saying here is that "not right now" is the right answer > > for the linux kernel. For technical reasons. > > I believe we can skip a lot of other conversation if I can summarize > something from this thread. Is it the case that you believe there is > room for both codepaths to exist in the upstream kernel, and for ACPI to > mature over time as it becomes "more ready"? As my original email said, I don't think there's a reason to pick up and pollute the whole kernel with double code paths at this time, while the vendors using ACPI is still trying to figure out what to do and how to do it. It's better to keep it out of the kernel, especially since it will require either re-abstracting all drivers and subsystems, or adding dual code paths to them for platform support that is likely to change. Until then, if someone wants to boot with ACPI, then the best path would be to translate as much of the simple data over to device tree and boot with that as the in-kernel abstraction layer. That can be done at boot or by crafting static device trees. Likely the first few generations of hardware will not have elaborate complex AML-based ACPI workarounds for stuff in the first place, so chances are this will not be a big issue. If, down the road, ACPI seems to have their act together, have worked out their kinks and reached a usable stable platform, then we can consider bringing in the parts of it that doesn't make the kernel explode in complexity and messiness. When this will be is impossible to predict today, but I expect it to take a couple of years and some generations of hardware. > If the above is the case, then I don't think we disagree at all! I don't > want to kill DeviceTree, I just know (or think I do) that ACPI is going > to be the dominant force on v8 server systems. It worries me if there's > no way to let ACPI code be merged upstream until it's completely figured > out. I hope I am reading the rest of the thread correctly and understand > instead that you're saying there can be a path for both, and perhaps > those of us who require ACPI can simply state that up front and work > with partners to ensure support for those ACPI platforms is available - > and binding fixes to the standard made - while those same server > platforms might also be supported by a DeviceTree at the same time for a > period of whatever transition is required. That seems totally > acceptable. I don't see any reason why the same binary kernel image > can't boot with either a DTB or an ACPI table and indeed that would be > my preference. Some of us can require it be ACPI by policy, but others > can build kernels that use DTB on v8 servers if that's what they need > while the whole thing shakes itself out. Again, merging a substantial amount of ACPI enablement is premature for the reasons already stated in the thread; it adds complexity and is likely to churn several times as vendors figure out just how to work with it. The two examples at hand (APM SATA and Exynos AHCI) both indicate that. While vendors are free to implement it in their firmware, we are much better off not relying on it right now. ACPI was messy on x86 in the beginning too. Luckily we have an alternative that will get the work done while the rest is being worked out. So, if we're not going to merge the ACPI-enabling code yet, mandating ACPI for booting isn't going to work if you expect to rely on native-all-the-way-through-the-kernel ACPI implementation. It will however work to some extent for the ACPI-to-DT approach, given that the platforms are kept reasonably simplistic. And if it doesn't, we can fall back to static DT and native implementation of whatever stuff ACPI would have abstracted for us (clock drivers, reset drivers) if we really have to. -Olof ^ permalink raw reply [flat|nested] 186+ messages in thread
* Re: ACPI vs DT at runtime 2013-11-18 19:09 ` Olof Johansson @ 2013-11-18 21:32 ` Grant Likely -1 siblings, 0 replies; 186+ messages in thread From: Grant Likely @ 2013-11-18 21:32 UTC (permalink / raw) To: Olof Johansson, Jon Masters Cc: linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r, devicetree-u79uwXL29TY76Z2rM5mHXA, mark.rutland-5wv7dgnIgG8, arnd-r2nGTMty4D4, robherring2-Re5JQEeQqe8AvxtiuMwx3w On Mon, 18 Nov 2013 11:09:29 -0800, Olof Johansson <olof-nZhT3qVonbNeoWH0uzbU5w@public.gmane.org> wrote: > On Mon, Nov 18, 2013 at 12:19:18AM -0500, Jon Masters wrote: > > I'm looking at the quality of the initial submissions (very poor and > confused), the readiness of the kernel in general (none so far), > the way the involved parties are doing development (away from the > community and in their own little world). I also look at some of the > bottlenecks we've had with device tree (reviewer bandwidth, slow-moving > consensus/standards-driven approval process) and how it compares to the > ACPI counterparts (standards forum). > > The conclusion is that we're about to embark onto something that isn't > going to be done right in the short to medium term. It just isn't. The > sooner we own up to that, the sooner we can course-correct and get back > to something that's likely to work. > > The alternative is signing onto a setup that _will_ stumble right out > of the door, which in turn will mean that the high-end ARM play will be > off to a rough start instead of running as smoothly as possible. I completely agree here. The DT conversion was hard and it took a lot of years. There was a lot of getting the code into shape and a lot of people trying to get their heads around it. ACPI is exactly the same problem. We don't know what we're doing and we don't know how to do it yet. I fully support getting ACPI up on ARM and the current work is good. However, it cannot short-circuit the kernel development process. Absolutely, push back hard on the ACPI and UEFI patches where the code is not ready. g. -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org More majordomo info at http://vger.kernel.org/majordomo-info.html ^ permalink raw reply [flat|nested] 186+ messages in thread
* ACPI vs DT at runtime @ 2013-11-18 21:32 ` Grant Likely 0 siblings, 0 replies; 186+ messages in thread From: Grant Likely @ 2013-11-18 21:32 UTC (permalink / raw) To: linux-arm-kernel On Mon, 18 Nov 2013 11:09:29 -0800, Olof Johansson <olof@lixom.net> wrote: > On Mon, Nov 18, 2013 at 12:19:18AM -0500, Jon Masters wrote: > > I'm looking at the quality of the initial submissions (very poor and > confused), the readiness of the kernel in general (none so far), > the way the involved parties are doing development (away from the > community and in their own little world). I also look at some of the > bottlenecks we've had with device tree (reviewer bandwidth, slow-moving > consensus/standards-driven approval process) and how it compares to the > ACPI counterparts (standards forum). > > The conclusion is that we're about to embark onto something that isn't > going to be done right in the short to medium term. It just isn't. The > sooner we own up to that, the sooner we can course-correct and get back > to something that's likely to work. > > The alternative is signing onto a setup that _will_ stumble right out > of the door, which in turn will mean that the high-end ARM play will be > off to a rough start instead of running as smoothly as possible. I completely agree here. The DT conversion was hard and it took a lot of years. There was a lot of getting the code into shape and a lot of people trying to get their heads around it. ACPI is exactly the same problem. We don't know what we're doing and we don't know how to do it yet. I fully support getting ACPI up on ARM and the current work is good. However, it cannot short-circuit the kernel development process. Absolutely, push back hard on the ACPI and UEFI patches where the code is not ready. g. ^ permalink raw reply [flat|nested] 186+ messages in thread
* ACPI vs DT at runtime 2013-11-18 21:32 ` Grant Likely (?) @ 2013-11-18 22:47 ` David Goodenough 2013-11-19 12:48 ` Arnd Bergmann 2013-11-21 18:23 ` Grant Likely -1 siblings, 2 replies; 186+ messages in thread From: David Goodenough @ 2013-11-18 22:47 UTC (permalink / raw) To: linux-arm-kernel On Monday 18 Nov 2013, Grant Likely wrote: > On Mon, 18 Nov 2013 11:09:29 -0800, Olof Johansson <olof@lixom.net> wrote: > > On Mon, Nov 18, 2013 at 12:19:18AM -0500, Jon Masters wrote: > > > > I'm looking at the quality of the initial submissions (very poor and > > confused), the readiness of the kernel in general (none so far), > > the way the involved parties are doing development (away from the > > community and in their own little world). I also look at some of the > > bottlenecks we've had with device tree (reviewer bandwidth, slow-moving > > consensus/standards-driven approval process) and how it compares to the > > ACPI counterparts (standards forum). > > > > The conclusion is that we're about to embark onto something that isn't > > going to be done right in the short to medium term. It just isn't. The > > sooner we own up to that, the sooner we can course-correct and get back > > to something that's likely to work. > > > > The alternative is signing onto a setup that _will_ stumble right out > > of the door, which in turn will mean that the high-end ARM play will be > > off to a rough start instead of running as smoothly as possible. > > I completely agree here. The DT conversion was hard and it took a lot of > years. There was a lot of getting the code into shape and a lot of > people trying to get their heads around it. ACPI is exactly the same > problem. We don't know what we're doing and we don't know how to do it > yet. > > I fully support getting ACPI up on ARM and the current work is good. > However, it cannot short-circuit the kernel development process. > Absolutely, push back hard on the ACPI and UEFI patches where the code > is not ready. > > g. > > _______________________________________________ > linux-arm-kernel mailing list > linux-arm-kernel at lists.infradead.org > http://lists.infradead.org/mailman/listinfo/linux-arm-kernel Would it not be possible to have ACPI read the hardware configuration from the DT, and provide whatever services it wants, while also allowing the kernel to retain the DT for its hardware config? I suppose the only thing that would be needed would be some way to mark paricular bits of hardware (I am largely thinking of the things lmsensors deals with) as being used by ACPI and being off limits to the kernel. David ^ permalink raw reply [flat|nested] 186+ messages in thread
* Re: ACPI vs DT at runtime 2013-11-18 22:47 ` David Goodenough @ 2013-11-19 12:48 ` Arnd Bergmann 2013-11-21 18:23 ` Grant Likely 1 sibling, 0 replies; 186+ messages in thread From: Arnd Bergmann @ 2013-11-19 12:48 UTC (permalink / raw) To: linux-arm-kernel Cc: mark.rutland, devicetree, David Goodenough, Grant Likely, Jon Masters, Olof Johansson On Monday 18 November 2013, David Goodenough wrote: > Would it not be possible to have ACPI read the hardware configuration > from the DT, and provide whatever services it wants, while also allowing > the kernel to retain the DT for its hardware config? I suppose the only > thing that would be needed would be some way to mark paricular bits of > hardware (I am largely thinking of the things lmsensors deals with) as > being used by ACPI and being off limits to the kernel. While that may be possible, I don't see what problem that solves. Nobody has so far explained what problem they want to solve by using ACPI. The only reason we are discussing this is Jon's statement that "everybody will use it". For any specific thing you might want to do in ACPI while leaving the rest in DT, I suspect there is an easier solution in using just DT. Since you seem to have something specific in mind, can you elaborate on why you think lmsensors (or any other device you can think of) would benefit from ACPI? Arnd ^ permalink raw reply [flat|nested] 186+ messages in thread
* ACPI vs DT at runtime @ 2013-11-19 12:48 ` Arnd Bergmann 0 siblings, 0 replies; 186+ messages in thread From: Arnd Bergmann @ 2013-11-19 12:48 UTC (permalink / raw) To: linux-arm-kernel On Monday 18 November 2013, David Goodenough wrote: > Would it not be possible to have ACPI read the hardware configuration > from the DT, and provide whatever services it wants, while also allowing > the kernel to retain the DT for its hardware config? I suppose the only > thing that would be needed would be some way to mark paricular bits of > hardware (I am largely thinking of the things lmsensors deals with) as > being used by ACPI and being off limits to the kernel. While that may be possible, I don't see what problem that solves. Nobody has so far explained what problem they want to solve by using ACPI. The only reason we are discussing this is Jon's statement that "everybody will use it". For any specific thing you might want to do in ACPI while leaving the rest in DT, I suspect there is an easier solution in using just DT. Since you seem to have something specific in mind, can you elaborate on why you think lmsensors (or any other device you can think of) would benefit from ACPI? Arnd ^ permalink raw reply [flat|nested] 186+ messages in thread
* ACPI vs DT at runtime 2013-11-19 12:48 ` Arnd Bergmann (?) @ 2013-11-19 13:34 ` David Goodenough 2013-11-19 16:52 ` Arnd Bergmann -1 siblings, 1 reply; 186+ messages in thread From: David Goodenough @ 2013-11-19 13:34 UTC (permalink / raw) To: linux-arm-kernel On Tuesday 19 Nov 2013, Arnd Bergmann wrote: > On Monday 18 November 2013, David Goodenough wrote: > > Would it not be possible to have ACPI read the hardware configuration > > from the DT, and provide whatever services it wants, while also allowing > > the kernel to retain the DT for its hardware config? I suppose the only > > thing that would be needed would be some way to mark paricular bits of > > hardware (I am largely thinking of the things lmsensors deals with) as > > being used by ACPI and being off limits to the kernel. > > While that may be possible, I don't see what problem that solves. Nobody > has so far explained what problem they want to solve by using ACPI. The > only reason we are discussing this is Jon's statement that "everybody > will use it". For any specific thing you might want to do in ACPI while > leaving the rest in DT, I suspect there is an easier solution in using > just DT. It strikes me that ACPI is really two things, a provider of configuration information and a provider of power management services. The first of these is - on ARM - more or less duplicated by DT, and so rather than having to go through the excercise of modifying the kernel to support both sources of configuration information, I am suggesting making not just the kernel and uboot (or whatever boot loader) use DT, but also ACPI. So the ACPI module for an ARM box would not have separate config information coded into it, but rather would either read the DT from the same place as the bootloader/kernel, or act as the source of the DT for the bootloader /kernel. This way the kernel does not have to be modified again, and can simply use DT whether ACPI is present or not. > > Since you seem to have something specific in mind, can you elaborate on > why you think lmsensors (or any other device you can think of) would > benefit from ACPI? Its the other way around. lmsensors often fights with ACPI in the x86 world for control of sensors and fans, and on x86 motherboards they do silly tricks like hiding I2C busses from the kernel so that ACPI can have sole control. Thus lmsensors (which on x86 boxes could use a source of information like DT as busses like I2C provide no chip ID services) needs to know which sensor chips are being used or controlled by ACPI so that it does not interfere. David > > Arnd > > _______________________________________________ > linux-arm-kernel mailing list > linux-arm-kernel at lists.infradead.org > http://lists.infradead.org/mailman/listinfo/linux-arm-kernel ^ permalink raw reply [flat|nested] 186+ messages in thread
* ACPI vs DT at runtime 2013-11-19 13:34 ` David Goodenough @ 2013-11-19 16:52 ` Arnd Bergmann 0 siblings, 0 replies; 186+ messages in thread From: Arnd Bergmann @ 2013-11-19 16:52 UTC (permalink / raw) To: linux-arm-kernel On Tuesday 19 November 2013, David Goodenough wrote: > On Tuesday 19 Nov 2013, Arnd Bergmann wrote: > > On Monday 18 November 2013, David Goodenough wrote: > > > Would it not be possible to have ACPI read the hardware configuration > > > from the DT, and provide whatever services it wants, while also allowing > > > the kernel to retain the DT for its hardware config? I suppose the only > > > thing that would be needed would be some way to mark paricular bits of > > > hardware (I am largely thinking of the things lmsensors deals with) as > > > being used by ACPI and being off limits to the kernel. > > > > While that may be possible, I don't see what problem that solves. Nobody > > has so far explained what problem they want to solve by using ACPI. The > > only reason we are discussing this is Jon's statement that "everybody > > will use it". For any specific thing you might want to do in ACPI while > > leaving the rest in DT, I suspect there is an easier solution in using > > just DT. > > It strikes me that ACPI is really two things, a provider of configuration > information and a provider of power management services. As the acronym says, yes ;-) > The first of > these is - on ARM - more or less duplicated by DT, and so rather than having > to go through the excercise of modifying the kernel to support both sources > of configuration information, I am suggesting making not just the kernel > and uboot (or whatever boot loader) use DT, but also ACPI. So the ACPI > module for an ARM box would not have separate config information coded > into it, but rather would either read the DT from the same place as > the bootloader/kernel, or act as the source of the DT for the bootloader > /kernel. This way the kernel does not have to be modified again, and > can simply use DT whether ACPI is present or not. Well, this is what Olof suggested, and it may or may not be possible, depending on what kind of data people actually want to put into ACPI here. > > Since you seem to have something specific in mind, can you elaborate on > > why you think lmsensors (or any other device you can think of) would > > benefit from ACPI? > Its the other way around. lmsensors often fights with ACPI in the x86 > world for control of sensors and fans, and on x86 motherboards they do > silly tricks like hiding I2C busses from the kernel so that ACPI can > have sole control. Thus lmsensors (which on x86 boxes could use a source > of information like DT as busses like I2C provide no chip ID services) needs > to know which sensor chips are being used or controlled by ACPI so that it > does not interfere. Ah, I see. I suppose on a server, those sensors are part of the BMC anyway and are accessible through IPMI only, so I'd hope that wouldn't be an issue. Arnd ^ permalink raw reply [flat|nested] 186+ messages in thread
* ACPI vs DT at runtime 2013-11-18 22:47 ` David Goodenough 2013-11-19 12:48 ` Arnd Bergmann @ 2013-11-21 18:23 ` Grant Likely 1 sibling, 0 replies; 186+ messages in thread From: Grant Likely @ 2013-11-21 18:23 UTC (permalink / raw) To: linux-arm-kernel On Mon, 18 Nov 2013 22:47:03 +0000, David Goodenough <david.goodenough@btconnect.com> wrote: > On Monday 18 Nov 2013, Grant Likely wrote: > > I fully support getting ACPI up on ARM and the current work is good. > > However, it cannot short-circuit the kernel development process. > > Absolutely, push back hard on the ACPI and UEFI patches where the code > > is not ready. > > Would it not be possible to have ACPI read the hardware configuration > from the DT, and provide whatever services it wants, while also allowing > the kernel to retain the DT for its hardware config? I suppose the only > thing that would be needed would be some way to mark paricular bits of > hardware (I am largely thinking of the things lmsensors deals with) as > being used by ACPI and being off limits to the kernel. I don't think there's a lot of interesting work there. It is more interesting to me to boot DT-only for production, but be able to use those same systems to develop and mature the ACPI support as quickly as possible. That is essentially what is being done right now by the Linaro ACPI team on the Versatile Express. g. ^ permalink raw reply [flat|nested] 186+ messages in thread
* ACPI vs DT at runtime 2013-11-18 5:19 ` Jon Masters ` (5 preceding siblings ...) [not found] ` <5289A356.4060004-Zp4isUonpHBD60Wz+7aTrA@public.gmane.org> @ 2013-11-19 14:33 ` Grant Likely 6 siblings, 0 replies; 186+ messages in thread From: Grant Likely @ 2013-11-19 14:33 UTC (permalink / raw) To: linux-arm-kernel On Mon, 18 Nov 2013 00:19:18 -0500, Jon Masters <jonathan@jonmasters.org> wrote: > > I think that trying to shoe-horn ACPI-derived information into device > > tree is fundamentally the wrong approach. I don't think it encourages > > best practices, and I don't think it's beneficial to the long term > > health of Linux or the ecosystem as a whole. > > It's going to be a messy thing to even attempt. Look, I wish we had a > time machine and could have done this whole thing years ago, but I'm not > sure it would have gone differently. ACPI is something a lot of people > emotionally hate. In the Enterprise space myself and others *need* it > (along with UEFI) to have a scalable solution that doesn't result in an > onslaught of customer support calls, which a non-standards body backed > moving target of DTB will do. I think that sells our entire community short. The Linux kernel itself is nowhere near standards body backed, and the userspace ABI is absolutely stable. It's stable because we've made stability a priority. Linus and others have been vocal about it, and maintainers have enforced it. Suggesting the lack of a standards body means we're left with a moving target is clearly not true. As much as we hoped ARM ACPI support would be complete by now and merged into the kernel, it isn't. I really can't fault (or expect) any hardware vendor to ship only ACPI when support for it isn't in mainline. As for DT, we discussed DT stability at length in Edinburgh. We've made the commitment to support shipped hardware. If hardware ships with a DT that boots on mainline, then we will not break it. > And besides all of the big boys are going > to be using ACPI whether it's liked much or not. I have to call that statement out as over the line. It comes across as attempting to shame maintainers into accepting ACPI, and further implies that non-ACPI users are not "big boys" and therefore just playing around. That is not okay. The ACPI support patches must satisfy maintainers before they will be accepted. This is normal and we've done this before. The current patches raise serious concerns, but they're also generating constructive feedback. If ACPI isn't there in time then we can support the hardware with DT, whether it is provided by the firmware (preferred), or shipped with the kernel. g. ^ permalink raw reply [flat|nested] 186+ messages in thread
[parent not found: <CAOesGMjKeRb=fFJM0MabDihbEiCGM4EqW9D5i_6-RFxTnpB4Qw-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>]
* Re: ACPI vs DT at runtime 2013-11-15 1:44 ` Olof Johansson @ 2013-11-15 20:58 ` Arnd Bergmann -1 siblings, 0 replies; 186+ messages in thread From: Arnd Bergmann @ 2013-11-15 20:58 UTC (permalink / raw) To: Olof Johansson Cc: devicetree-u79uwXL29TY76Z2rM5mHXA, linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r, Grant Likely, Rob Herring On Friday 15 November 2013, Olof Johansson wrote: > So, I'm strongly urging that whatever the server guys try to do, it > will in the end result in the ACPI data being translated into DT > equivalents, such that the kernel only needs to handle data via DT. I don't think that a translation layer is the answer, I see the problem more in things that cannot be translated automatically. The parts that are similar enough to allow translation could also just be handled by a thin abstraction layer in the kernel, which I think we will see on embedded x86 with DT-in-ACPI-syntax. I think we can still treat ACPI on ARM64 as a beginner's mistake and provide hand-written DT blobs for the few systems that start shipping with that. The main reason for doing it in the first place was the expected number of Windows RT servers, but WinRT isn't doing well at the moment, so it's not unreasonable to assume it's going the same way as WinRT tablets. During the kernel summit, Grant (as one of the proponents of doing ACPI on ARM) already mentioned that he only sees this as viable on PC-like systems. My feeling is that when (if?) AMD or someone else comes out with a server system where they basically replace the x86 core with an ARM one but keep the system design, there won't be much to describe in terms of internal components anyway, and also no need to translate a lot of device information -- everything is already a PCI device in that case and does not get handled through the platform bus. However, until we see code or system-level specs for such a system, I'd rather keep ACPI out of the ARM kernel so we don't give people the wrong ideas. Arnd -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org More majordomo info at http://vger.kernel.org/majordomo-info.html ^ permalink raw reply [flat|nested] 186+ messages in thread
* ACPI vs DT at runtime @ 2013-11-15 20:58 ` Arnd Bergmann 0 siblings, 0 replies; 186+ messages in thread From: Arnd Bergmann @ 2013-11-15 20:58 UTC (permalink / raw) To: linux-arm-kernel On Friday 15 November 2013, Olof Johansson wrote: > So, I'm strongly urging that whatever the server guys try to do, it > will in the end result in the ACPI data being translated into DT > equivalents, such that the kernel only needs to handle data via DT. I don't think that a translation layer is the answer, I see the problem more in things that cannot be translated automatically. The parts that are similar enough to allow translation could also just be handled by a thin abstraction layer in the kernel, which I think we will see on embedded x86 with DT-in-ACPI-syntax. I think we can still treat ACPI on ARM64 as a beginner's mistake and provide hand-written DT blobs for the few systems that start shipping with that. The main reason for doing it in the first place was the expected number of Windows RT servers, but WinRT isn't doing well at the moment, so it's not unreasonable to assume it's going the same way as WinRT tablets. During the kernel summit, Grant (as one of the proponents of doing ACPI on ARM) already mentioned that he only sees this as viable on PC-like systems. My feeling is that when (if?) AMD or someone else comes out with a server system where they basically replace the x86 core with an ARM one but keep the system design, there won't be much to describe in terms of internal components anyway, and also no need to translate a lot of device information -- everything is already a PCI device in that case and does not get handled through the platform bus. However, until we see code or system-level specs for such a system, I'd rather keep ACPI out of the ARM kernel so we don't give people the wrong ideas. Arnd ^ permalink raw reply [flat|nested] 186+ messages in thread
[parent not found: <201311152158.32644.arnd-r2nGTMty4D4@public.gmane.org>]
* Re: ACPI vs DT at runtime 2013-11-15 20:58 ` Arnd Bergmann @ 2013-11-15 21:44 ` Olof Johansson -1 siblings, 0 replies; 186+ messages in thread From: Olof Johansson @ 2013-11-15 21:44 UTC (permalink / raw) To: Arnd Bergmann Cc: devicetree-u79uwXL29TY76Z2rM5mHXA, linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r, Grant Likely, Rob Herring On Fri, Nov 15, 2013 at 12:58 PM, Arnd Bergmann <arnd-r2nGTMty4D4@public.gmane.org> wrote: > On Friday 15 November 2013, Olof Johansson wrote: >> So, I'm strongly urging that whatever the server guys try to do, it >> will in the end result in the ACPI data being translated into DT >> equivalents, such that the kernel only needs to handle data via DT. > > I don't think that a translation layer is the answer, I see the problem > more in things that cannot be translated automatically. The parts that > are similar enough to allow translation could also just be handled by > a thin abstraction layer in the kernel, which I think we will see > on embedded x86 with DT-in-ACPI-syntax. I'm not so sure that converting everything yet again to another abstraction layer is a good solution. We've got one level of abstraction today -- DT. And we've got the un-abstracted layer of platform devices. Churning all drivers yet again seems like the wrong way to do this. For things that we can pre-populate instead of adding runtime abstraction, we should. > I think we can still treat ACPI on ARM64 as a beginner's mistake and > provide hand-written DT blobs for the few systems that start shipping > with that. I think we can do better -- we can ask those vendors to not ship ACPI at all, and ship DT themselves (together with us for review, etc). Especially since doing a broken ACPI implementation today _just for us_ will just distract them. If they need one for RT, fine. As I mentioned elsewhere, shipping a flashed DTB is no different from shipping ACPI from a future-proof point of view; we'll end up overriding either at some point once we figure out things better. > The main reason for doing it in the first place was the > expected number of Windows RT servers, but WinRT isn't doing well > at the moment, so it's not unreasonable to assume it's going the same > way as WinRT tablets. It's sort of impossible to tell today. Since there are no ARM64 servers on the market, there's no market for RT on them. Nor are there any machines that can be acquired to look at how they implemented stuff. And the silicon vendors who have started doing some of this work are mostly doing it in secret on their own. > During the kernel summit, Grant (as one of the proponents of doing > ACPI on ARM) already mentioned that he only sees this as viable > on PC-like systems. My feeling is that when (if?) AMD or someone else > comes out with a server system where they basically replace the > x86 core with an ARM one but keep the system design, there won't > be much to describe in terms of internal components anyway, and also > no need to translate a lot of device information -- everything is > already a PCI device in that case and does not get handled through > the platform bus. i2c devices and several other things are not probable, either are ECs on LPC, etc. All of those mostly fall into the category of simple-to-describe-in-any-format though. > However, until we see code or system-level specs > for such a system, I'd rather keep ACPI out of the ARM kernel so we > don't give people the wrong ideas. Strong agreement from me. -Olof -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org More majordomo info at http://vger.kernel.org/majordomo-info.html ^ permalink raw reply [flat|nested] 186+ messages in thread
* ACPI vs DT at runtime @ 2013-11-15 21:44 ` Olof Johansson 0 siblings, 0 replies; 186+ messages in thread From: Olof Johansson @ 2013-11-15 21:44 UTC (permalink / raw) To: linux-arm-kernel On Fri, Nov 15, 2013 at 12:58 PM, Arnd Bergmann <arnd@arndb.de> wrote: > On Friday 15 November 2013, Olof Johansson wrote: >> So, I'm strongly urging that whatever the server guys try to do, it >> will in the end result in the ACPI data being translated into DT >> equivalents, such that the kernel only needs to handle data via DT. > > I don't think that a translation layer is the answer, I see the problem > more in things that cannot be translated automatically. The parts that > are similar enough to allow translation could also just be handled by > a thin abstraction layer in the kernel, which I think we will see > on embedded x86 with DT-in-ACPI-syntax. I'm not so sure that converting everything yet again to another abstraction layer is a good solution. We've got one level of abstraction today -- DT. And we've got the un-abstracted layer of platform devices. Churning all drivers yet again seems like the wrong way to do this. For things that we can pre-populate instead of adding runtime abstraction, we should. > I think we can still treat ACPI on ARM64 as a beginner's mistake and > provide hand-written DT blobs for the few systems that start shipping > with that. I think we can do better -- we can ask those vendors to not ship ACPI at all, and ship DT themselves (together with us for review, etc). Especially since doing a broken ACPI implementation today _just for us_ will just distract them. If they need one for RT, fine. As I mentioned elsewhere, shipping a flashed DTB is no different from shipping ACPI from a future-proof point of view; we'll end up overriding either at some point once we figure out things better. > The main reason for doing it in the first place was the > expected number of Windows RT servers, but WinRT isn't doing well > at the moment, so it's not unreasonable to assume it's going the same > way as WinRT tablets. It's sort of impossible to tell today. Since there are no ARM64 servers on the market, there's no market for RT on them. Nor are there any machines that can be acquired to look at how they implemented stuff. And the silicon vendors who have started doing some of this work are mostly doing it in secret on their own. > During the kernel summit, Grant (as one of the proponents of doing > ACPI on ARM) already mentioned that he only sees this as viable > on PC-like systems. My feeling is that when (if?) AMD or someone else > comes out with a server system where they basically replace the > x86 core with an ARM one but keep the system design, there won't > be much to describe in terms of internal components anyway, and also > no need to translate a lot of device information -- everything is > already a PCI device in that case and does not get handled through > the platform bus. i2c devices and several other things are not probable, either are ECs on LPC, etc. All of those mostly fall into the category of simple-to-describe-in-any-format though. > However, until we see code or system-level specs > for such a system, I'd rather keep ACPI out of the ARM kernel so we > don't give people the wrong ideas. Strong agreement from me. -Olof ^ permalink raw reply [flat|nested] 186+ messages in thread
[parent not found: <CAOesGMhkCn2zeJj_ZZAZu_wJya-4evWEqNHpVJEpjxzWHVWY3A-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>]
* Re: ACPI vs DT at runtime 2013-11-15 21:44 ` Olof Johansson @ 2013-11-17 17:18 ` Stefano Stabellini -1 siblings, 0 replies; 186+ messages in thread From: Stefano Stabellini @ 2013-11-17 17:18 UTC (permalink / raw) To: Olof Johansson Cc: Arnd Bergmann, Grant Likely, devicetree-u79uwXL29TY76Z2rM5mHXA, linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r On Fri, 15 Nov 2013, Olof Johansson wrote: > On Fri, Nov 15, 2013 at 12:58 PM, Arnd Bergmann <arnd-r2nGTMty4D4@public.gmane.org> wrote: > > On Friday 15 November 2013, Olof Johansson wrote: > >> So, I'm strongly urging that whatever the server guys try to do, it > >> will in the end result in the ACPI data being translated into DT > >> equivalents, such that the kernel only needs to handle data via DT. > > > > I don't think that a translation layer is the answer, I see the problem > > more in things that cannot be translated automatically. The parts that > > are similar enough to allow translation could also just be handled by > > a thin abstraction layer in the kernel, which I think we will see > > on embedded x86 with DT-in-ACPI-syntax. > > I'm not so sure that converting everything yet again to another > abstraction layer is a good solution. We've got one level of > abstraction today -- DT. And we've got the un-abstracted layer of > platform devices. Churning all drivers yet again seems like the wrong > way to do this. For things that we can pre-populate instead of adding > runtime abstraction, we should. Simply using DT would help avoiding the awkward situation where a driver of a device only works with one of the two description formats and not the other. > > I think we can still treat ACPI on ARM64 as a beginner's mistake and > > provide hand-written DT blobs for the few systems that start shipping > > with that. > > I think we can do better -- we can ask those vendors to not ship ACPI > at all, and ship DT themselves (together with us for review, etc). They can ship with ACPI if they want to, what is important is that they ship with device tree too. Encouraging them to do that is definitely the right thing to do today, regardless of the medium to long term ACPI strategy for the Linux kernel. > Especially since doing a broken ACPI implementation today _just for > us_ will just distract them. If they need one for RT, fine. As I > mentioned elsewhere, shipping a flashed DTB is no different from > shipping ACPI from a future-proof point of view; we'll end up > overriding either at some point once we figure out things better. Well said. -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org More majordomo info at http://vger.kernel.org/majordomo-info.html ^ permalink raw reply [flat|nested] 186+ messages in thread
* ACPI vs DT at runtime @ 2013-11-17 17:18 ` Stefano Stabellini 0 siblings, 0 replies; 186+ messages in thread From: Stefano Stabellini @ 2013-11-17 17:18 UTC (permalink / raw) To: linux-arm-kernel On Fri, 15 Nov 2013, Olof Johansson wrote: > On Fri, Nov 15, 2013 at 12:58 PM, Arnd Bergmann <arnd@arndb.de> wrote: > > On Friday 15 November 2013, Olof Johansson wrote: > >> So, I'm strongly urging that whatever the server guys try to do, it > >> will in the end result in the ACPI data being translated into DT > >> equivalents, such that the kernel only needs to handle data via DT. > > > > I don't think that a translation layer is the answer, I see the problem > > more in things that cannot be translated automatically. The parts that > > are similar enough to allow translation could also just be handled by > > a thin abstraction layer in the kernel, which I think we will see > > on embedded x86 with DT-in-ACPI-syntax. > > I'm not so sure that converting everything yet again to another > abstraction layer is a good solution. We've got one level of > abstraction today -- DT. And we've got the un-abstracted layer of > platform devices. Churning all drivers yet again seems like the wrong > way to do this. For things that we can pre-populate instead of adding > runtime abstraction, we should. Simply using DT would help avoiding the awkward situation where a driver of a device only works with one of the two description formats and not the other. > > I think we can still treat ACPI on ARM64 as a beginner's mistake and > > provide hand-written DT blobs for the few systems that start shipping > > with that. > > I think we can do better -- we can ask those vendors to not ship ACPI > at all, and ship DT themselves (together with us for review, etc). They can ship with ACPI if they want to, what is important is that they ship with device tree too. Encouraging them to do that is definitely the right thing to do today, regardless of the medium to long term ACPI strategy for the Linux kernel. > Especially since doing a broken ACPI implementation today _just for > us_ will just distract them. If they need one for RT, fine. As I > mentioned elsewhere, shipping a flashed DTB is no different from > shipping ACPI from a future-proof point of view; we'll end up > overriding either at some point once we figure out things better. Well said. ^ permalink raw reply [flat|nested] 186+ messages in thread
[parent not found: <alpine.DEB.2.02.1311171705130.4714-7Z66fg9igcxYtxbxJUhB2Dgeux46jI+i@public.gmane.org>]
* Re: ACPI vs DT at runtime 2013-11-17 17:18 ` Stefano Stabellini @ 2013-11-17 18:10 ` Arnd Bergmann -1 siblings, 0 replies; 186+ messages in thread From: Arnd Bergmann @ 2013-11-17 18:10 UTC (permalink / raw) To: Stefano Stabellini Cc: Olof Johansson, Grant Likely, devicetree-u79uwXL29TY76Z2rM5mHXA, linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r On Sunday 17 November 2013 17:18:03 Stefano Stabellini wrote: > On Fri, 15 Nov 2013, Olof Johansson wrote: > > On Fri, Nov 15, 2013 at 12:58 PM, Arnd Bergmann <arnd-r2nGTMty4D4@public.gmane.org> wrote: > > > On Friday 15 November 2013, Olof Johansson wrote: > > >> So, I'm strongly urging that whatever the server guys try to do, it > > >> will in the end result in the ACPI data being translated into DT > > >> equivalents, such that the kernel only needs to handle data via DT. > > > > > > I don't think that a translation layer is the answer, I see the problem > > > more in things that cannot be translated automatically. The parts that > > > are similar enough to allow translation could also just be handled by > > > a thin abstraction layer in the kernel, which I think we will see > > > on embedded x86 with DT-in-ACPI-syntax. > > > > I'm not so sure that converting everything yet again to another > > abstraction layer is a good solution. We've got one level of > > abstraction today -- DT. And we've got the un-abstracted layer of > > platform devices. Churning all drivers yet again seems like the wrong > > way to do this. For things that we can pre-populate instead of adding > > runtime abstraction, we should. My point was not that everything would be good if we change the kernel this way, it clearly wouldn't. I think the problem is more the parts for which neither an automated translation nor a unified driver level interface would work well. > Simply using DT would help avoiding the awkward situation where a driver > of a device only works with one of the two description formats and not > the other. Yes, but remember that Intel still have the problem on their embedded systems, and will want to solve them. For ARM Linux I agree that we're better off not having to change all the drivers again for this, but we will have a growing number of drivers that are shared with ACPI based x86 SoCs. At least there are only one or two vendors of those chips ;-) > > > I think we can still treat ACPI on ARM64 as a beginner's mistake and > > > provide hand-written DT blobs for the few systems that start shipping > > > with that. > > > > I think we can do better -- we can ask those vendors to not ship ACPI > > at all, and ship DT themselves (together with us for review, etc). > > They can ship with ACPI if they want to, what is important is that they > ship with device tree too. > Encouraging them to do that is definitely the right thing to do today, > regardless of the medium to long term ACPI strategy for the Linux > kernel. I'm skeptical about getting people to ship both, except if they want to support multiple operating systems. For those vendors we are talking to, we are possibly able to convince them to drop ACPI for Linux based servers. The bigger problem is system vendors we don't talk to. They are going to to do any number of crazy things in their private kernels: * Board files * Hardcoded platform devices with no multiplatform support * Custom hypervisor (EL2 or EL3) interfaces for probing * FEX * ACPI * Some other firmware ported over from their MIPS products * Incompatible Open Firmware * Incompatible DT extensions * ... The only thing we really have a handle on is stuff that gets submitted for inclusion into Linux. One would hope that this would include any server platform, but I think the people trying get into that market are still learning about how to do these things. > > Especially since doing a broken ACPI implementation today _just for > > us_ will just distract them. If they need one for RT, fine. As I > > mentioned elsewhere, shipping a flashed DTB is no different from > > shipping ACPI from a future-proof point of view; we'll end up > > overriding either at some point once we figure out things better. > > Well said. +1 Arnd -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org More majordomo info at http://vger.kernel.org/majordomo-info.html ^ permalink raw reply [flat|nested] 186+ messages in thread
* ACPI vs DT at runtime @ 2013-11-17 18:10 ` Arnd Bergmann 0 siblings, 0 replies; 186+ messages in thread From: Arnd Bergmann @ 2013-11-17 18:10 UTC (permalink / raw) To: linux-arm-kernel On Sunday 17 November 2013 17:18:03 Stefano Stabellini wrote: > On Fri, 15 Nov 2013, Olof Johansson wrote: > > On Fri, Nov 15, 2013 at 12:58 PM, Arnd Bergmann <arnd@arndb.de> wrote: > > > On Friday 15 November 2013, Olof Johansson wrote: > > >> So, I'm strongly urging that whatever the server guys try to do, it > > >> will in the end result in the ACPI data being translated into DT > > >> equivalents, such that the kernel only needs to handle data via DT. > > > > > > I don't think that a translation layer is the answer, I see the problem > > > more in things that cannot be translated automatically. The parts that > > > are similar enough to allow translation could also just be handled by > > > a thin abstraction layer in the kernel, which I think we will see > > > on embedded x86 with DT-in-ACPI-syntax. > > > > I'm not so sure that converting everything yet again to another > > abstraction layer is a good solution. We've got one level of > > abstraction today -- DT. And we've got the un-abstracted layer of > > platform devices. Churning all drivers yet again seems like the wrong > > way to do this. For things that we can pre-populate instead of adding > > runtime abstraction, we should. My point was not that everything would be good if we change the kernel this way, it clearly wouldn't. I think the problem is more the parts for which neither an automated translation nor a unified driver level interface would work well. > Simply using DT would help avoiding the awkward situation where a driver > of a device only works with one of the two description formats and not > the other. Yes, but remember that Intel still have the problem on their embedded systems, and will want to solve them. For ARM Linux I agree that we're better off not having to change all the drivers again for this, but we will have a growing number of drivers that are shared with ACPI based x86 SoCs. At least there are only one or two vendors of those chips ;-) > > > I think we can still treat ACPI on ARM64 as a beginner's mistake and > > > provide hand-written DT blobs for the few systems that start shipping > > > with that. > > > > I think we can do better -- we can ask those vendors to not ship ACPI > > at all, and ship DT themselves (together with us for review, etc). > > They can ship with ACPI if they want to, what is important is that they > ship with device tree too. > Encouraging them to do that is definitely the right thing to do today, > regardless of the medium to long term ACPI strategy for the Linux > kernel. I'm skeptical about getting people to ship both, except if they want to support multiple operating systems. For those vendors we are talking to, we are possibly able to convince them to drop ACPI for Linux based servers. The bigger problem is system vendors we don't talk to. They are going to to do any number of crazy things in their private kernels: * Board files * Hardcoded platform devices with no multiplatform support * Custom hypervisor (EL2 or EL3) interfaces for probing * FEX * ACPI * Some other firmware ported over from their MIPS products * Incompatible Open Firmware * Incompatible DT extensions * ... The only thing we really have a handle on is stuff that gets submitted for inclusion into Linux. One would hope that this would include any server platform, but I think the people trying get into that market are still learning about how to do these things. > > Especially since doing a broken ACPI implementation today _just for > > us_ will just distract them. If they need one for RT, fine. As I > > mentioned elsewhere, shipping a flashed DTB is no different from > > shipping ACPI from a future-proof point of view; we'll end up > > overriding either at some point once we figure out things better. > > Well said. +1 Arnd ^ permalink raw reply [flat|nested] 186+ messages in thread
[parent not found: < CAOesGMiYyOcvr3Aqs-p8zc=XDwJM9NZtNxtxrTZssc6F=siZCw@mail.gmail.com>]
* Re: ACPI vs DT at runtime 2013-11-17 18:10 ` Arnd Bergmann @ 2013-11-17 22:20 ` Olof Johansson -1 siblings, 0 replies; 186+ messages in thread From: Olof Johansson @ 2013-11-17 22:20 UTC (permalink / raw) To: Arnd Bergmann Cc: Stefano Stabellini, Grant Likely, devicetree-u79uwXL29TY76Z2rM5mHXA, linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r On Sun, Nov 17, 2013 at 10:10 AM, Arnd Bergmann <arnd-r2nGTMty4D4@public.gmane.org> wrote: > On Sunday 17 November 2013 17:18:03 Stefano Stabellini wrote: >> On Fri, 15 Nov 2013, Olof Johansson wrote: >> > On Fri, Nov 15, 2013 at 12:58 PM, Arnd Bergmann <arnd-r2nGTMty4D4@public.gmane.org> wrote: >> > > On Friday 15 November 2013, Olof Johansson wrote: >> > >> So, I'm strongly urging that whatever the server guys try to do, it >> > >> will in the end result in the ACPI data being translated into DT >> > >> equivalents, such that the kernel only needs to handle data via DT. >> > > >> > > I don't think that a translation layer is the answer, I see the problem >> > > more in things that cannot be translated automatically. The parts that >> > > are similar enough to allow translation could also just be handled by >> > > a thin abstraction layer in the kernel, which I think we will see >> > > on embedded x86 with DT-in-ACPI-syntax. >> > >> > I'm not so sure that converting everything yet again to another >> > abstraction layer is a good solution. We've got one level of >> > abstraction today -- DT. And we've got the un-abstracted layer of >> > platform devices. Churning all drivers yet again seems like the wrong >> > way to do this. For things that we can pre-populate instead of adding >> > runtime abstraction, we should. > > My point was not that everything would be good if we change the kernel > this way, it clearly wouldn't. I think the problem is more the parts > for which neither an automated translation nor a unified driver level > interface would work well. Do you have predictions for what those areas would be? Chances are that at least the initial ones can be handled with the methods we already have today such as quirks and the like. Once we've seen enough of them, we'll have more knowledge of what a new solution really needs to cover. Speculating prematurely will likely give us the wrong abstractions (and/or at too high a level, causing extra work and churn for everybody). I think we agree that holding off is the right answer, just maybe not (yet) what the actual solution might be when we start to need it. :) >> Simply using DT would help avoiding the awkward situation where a driver >> of a device only works with one of the two description formats and not >> the other. > > Yes, but remember that Intel still have the problem on their embedded > systems, and will want to solve them. > > For ARM Linux I agree that we're better off not having to change all > the drivers again for this, but we will have a growing number of > drivers that are shared with ACPI based x86 SoCs. At least there are > only one or two vendors of those chips ;-) Well, you menion DT-in-ACPI above. If they're really exploring that path then a lot will sort itself out from there. Making a decision to hold off with ACPI for ARM will help get everybody on the same page if they're already considering a solution along those lines. >> > > I think we can still treat ACPI on ARM64 as a beginner's mistake and >> > > provide hand-written DT blobs for the few systems that start shipping >> > > with that. >> > >> > I think we can do better -- we can ask those vendors to not ship ACPI >> > at all, and ship DT themselves (together with us for review, etc). Yep, and together for review is a critical part. I'm not saying that the ideal solution is a flashed DTB, but it's better than ACPI. A flashed DTB that's _easy to update_ as part of an OS install would probably be one of the best solutions we could ask for though. >> They can ship with ACPI if they want to, what is important is that they >> ship with device tree too. >> Encouraging them to do that is definitely the right thing to do today, >> regardless of the medium to long term ACPI strategy for the Linux >> kernel. > > I'm skeptical about getting people to ship both, except if they > want to support multiple operating systems. For those vendors > we are talking to, we are possibly able to convince them to drop > ACPI for Linux based servers. +1. Especially if their initial focus is just on linux and not on enabling RT on the same set of machines (with the same firmware). > The bigger problem is system vendors > we don't talk to. They are going to to do any number of crazy things > in their private kernels: > > * Board files > * Hardcoded platform devices with no multiplatform support > * Custom hypervisor (EL2 or EL3) interfaces for probing > * FEX > * ACPI > * Some other firmware ported over from their MIPS products > * Incompatible Open Firmware > * Incompatible DT extensions > * ... Given that we have a documented boot protocol today, it shouldn't matter much if someone ports over some MIPS firmware (we did add OF client interface to CFE at PA Semi, and that worked well for us :-). Most of the others listed above can hopefully be avoided by us having appropriate solutions in-kernel today that they can reuse. I.e. FEX happened because DT didn't exist at the time. ACPI is a big problem here in that sense: Vendors have been told to use it, but there's no infrastructure, and even if it would be there it would be immature and we don't really know what we want from it. Board files and hardcoded devices are things we've dealt with already and know what to do with, so I'm less worried about that. And finally, custom firmware interfaces should hopefully be rare given the reference PSCI implementation from ARM, but we can deal with it if we have to. > The only thing we really have a handle on is stuff that gets submitted > for inclusion into Linux. One would hope that this would include > any server platform, but I think the people trying get into that > market are still learning about how to do these things. Yes, we're likely to see some false starts, or even successful starts done wrong. Hopefully we can catch them early and get them onto a better track quickly. Especially once they realize they really do want/need upstream support for their platforms. I do hope we'll start to see more from the vendors that are working on silicon soon, or things run the risk of getting really messy. :( >> > Especially since doing a broken ACPI implementation today _just for >> > us_ will just distract them. If they need one for RT, fine. As I >> > mentioned elsewhere, shipping a flashed DTB is no different from >> > shipping ACPI from a future-proof point of view; we'll end up >> > overriding either at some point once we figure out things better. >> >> Well said. > > +1 -Olof -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org More majordomo info at http://vger.kernel.org/majordomo-info.html ^ permalink raw reply [flat|nested] 186+ messages in thread
* ACPI vs DT at runtime @ 2013-11-17 22:20 ` Olof Johansson 0 siblings, 0 replies; 186+ messages in thread From: Olof Johansson @ 2013-11-17 22:20 UTC (permalink / raw) To: linux-arm-kernel On Sun, Nov 17, 2013 at 10:10 AM, Arnd Bergmann <arnd@arndb.de> wrote: > On Sunday 17 November 2013 17:18:03 Stefano Stabellini wrote: >> On Fri, 15 Nov 2013, Olof Johansson wrote: >> > On Fri, Nov 15, 2013 at 12:58 PM, Arnd Bergmann <arnd@arndb.de> wrote: >> > > On Friday 15 November 2013, Olof Johansson wrote: >> > >> So, I'm strongly urging that whatever the server guys try to do, it >> > >> will in the end result in the ACPI data being translated into DT >> > >> equivalents, such that the kernel only needs to handle data via DT. >> > > >> > > I don't think that a translation layer is the answer, I see the problem >> > > more in things that cannot be translated automatically. The parts that >> > > are similar enough to allow translation could also just be handled by >> > > a thin abstraction layer in the kernel, which I think we will see >> > > on embedded x86 with DT-in-ACPI-syntax. >> > >> > I'm not so sure that converting everything yet again to another >> > abstraction layer is a good solution. We've got one level of >> > abstraction today -- DT. And we've got the un-abstracted layer of >> > platform devices. Churning all drivers yet again seems like the wrong >> > way to do this. For things that we can pre-populate instead of adding >> > runtime abstraction, we should. > > My point was not that everything would be good if we change the kernel > this way, it clearly wouldn't. I think the problem is more the parts > for which neither an automated translation nor a unified driver level > interface would work well. Do you have predictions for what those areas would be? Chances are that at least the initial ones can be handled with the methods we already have today such as quirks and the like. Once we've seen enough of them, we'll have more knowledge of what a new solution really needs to cover. Speculating prematurely will likely give us the wrong abstractions (and/or at too high a level, causing extra work and churn for everybody). I think we agree that holding off is the right answer, just maybe not (yet) what the actual solution might be when we start to need it. :) >> Simply using DT would help avoiding the awkward situation where a driver >> of a device only works with one of the two description formats and not >> the other. > > Yes, but remember that Intel still have the problem on their embedded > systems, and will want to solve them. > > For ARM Linux I agree that we're better off not having to change all > the drivers again for this, but we will have a growing number of > drivers that are shared with ACPI based x86 SoCs. At least there are > only one or two vendors of those chips ;-) Well, you menion DT-in-ACPI above. If they're really exploring that path then a lot will sort itself out from there. Making a decision to hold off with ACPI for ARM will help get everybody on the same page if they're already considering a solution along those lines. >> > > I think we can still treat ACPI on ARM64 as a beginner's mistake and >> > > provide hand-written DT blobs for the few systems that start shipping >> > > with that. >> > >> > I think we can do better -- we can ask those vendors to not ship ACPI >> > at all, and ship DT themselves (together with us for review, etc). Yep, and together for review is a critical part. I'm not saying that the ideal solution is a flashed DTB, but it's better than ACPI. A flashed DTB that's _easy to update_ as part of an OS install would probably be one of the best solutions we could ask for though. >> They can ship with ACPI if they want to, what is important is that they >> ship with device tree too. >> Encouraging them to do that is definitely the right thing to do today, >> regardless of the medium to long term ACPI strategy for the Linux >> kernel. > > I'm skeptical about getting people to ship both, except if they > want to support multiple operating systems. For those vendors > we are talking to, we are possibly able to convince them to drop > ACPI for Linux based servers. +1. Especially if their initial focus is just on linux and not on enabling RT on the same set of machines (with the same firmware). > The bigger problem is system vendors > we don't talk to. They are going to to do any number of crazy things > in their private kernels: > > * Board files > * Hardcoded platform devices with no multiplatform support > * Custom hypervisor (EL2 or EL3) interfaces for probing > * FEX > * ACPI > * Some other firmware ported over from their MIPS products > * Incompatible Open Firmware > * Incompatible DT extensions > * ... Given that we have a documented boot protocol today, it shouldn't matter much if someone ports over some MIPS firmware (we did add OF client interface to CFE at PA Semi, and that worked well for us :-). Most of the others listed above can hopefully be avoided by us having appropriate solutions in-kernel today that they can reuse. I.e. FEX happened because DT didn't exist at the time. ACPI is a big problem here in that sense: Vendors have been told to use it, but there's no infrastructure, and even if it would be there it would be immature and we don't really know what we want from it. Board files and hardcoded devices are things we've dealt with already and know what to do with, so I'm less worried about that. And finally, custom firmware interfaces should hopefully be rare given the reference PSCI implementation from ARM, but we can deal with it if we have to. > The only thing we really have a handle on is stuff that gets submitted > for inclusion into Linux. One would hope that this would include > any server platform, but I think the people trying get into that > market are still learning about how to do these things. Yes, we're likely to see some false starts, or even successful starts done wrong. Hopefully we can catch them early and get them onto a better track quickly. Especially once they realize they really do want/need upstream support for their platforms. I do hope we'll start to see more from the vendors that are working on silicon soon, or things run the risk of getting really messy. :( >> > Especially since doing a broken ACPI implementation today _just for >> > us_ will just distract them. If they need one for RT, fine. As I >> > mentioned elsewhere, shipping a flashed DTB is no different from >> > shipping ACPI from a future-proof point of view; we'll end up >> > overriding either at some point once we figure out things better. >> >> Well said. > > +1 -Olof ^ permalink raw reply [flat|nested] 186+ messages in thread
[parent not found: <CAOesGMiYyOcvr3Aqs-p8zc=XDwJM9NZtNxtxrTZssc6F=siZCw-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>]
* Re: ACPI vs DT at runtime 2013-11-17 22:20 ` Olof Johansson @ 2013-11-18 8:45 ` Arnd Bergmann -1 siblings, 0 replies; 186+ messages in thread From: Arnd Bergmann @ 2013-11-18 8:45 UTC (permalink / raw) To: Olof Johansson Cc: Stefano Stabellini, Grant Likely, devicetree-u79uwXL29TY76Z2rM5mHXA, linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r On Sunday 17 November 2013, Olof Johansson wrote: > On Sun, Nov 17, 2013 at 10:10 AM, Arnd Bergmann <arnd-r2nGTMty4D4@public.gmane.org> wrote: > > On Sunday 17 November 2013 17:18:03 Stefano Stabellini wrote: > > > > My point was not that everything would be good if we change the kernel > > this way, it clearly wouldn't. I think the problem is more the parts > > for which neither an automated translation nor a unified driver level > > interface would work well. > > Do you have predictions for what those areas would be? Chances are > that at least the initial ones can be handled with the methods we > already have today such as quirks and the like. I think all DT references that take the form of <&phandle arg1 ...> are problematic because in ACPI the same things tend to expressed by a single number (irq, dma, gpio, ...) or just a reference with no arguments (don't have an example here). Another difference is things that are numbered on one side but named on the other. In DT we have an inconsistent mix of the two, e.g. DMA requests must be named (per device) while IRQs must be numbered (per device) and may additionally be named. Finally, anything that needs run-time interpretation of AML is fundamentally hard because the AML would refer to objects that don't exist when you don't boot from ACPI. This gets worse if you need to pass ACPI identifiers into EL3 firmware. Because of this, anything related to runtime PM scares me at the moment, because there are two conflicting ways to do it: As we discussed before, the correct way to do this in ACPI is to hide it all from the OS in AML bytecode and EL2/EL3 firmware calls, but this may not be possible on all systems and it prevents us from translating into a format that the drivers can use to call our regulator/clk/pmdomain interfaces. Intel's embedded systems will likely get around this by defining ACPI representations of our existing DT bindings for these subsystems, which would be possible to translate automatically, but it seems very silly to use those on servers. > Once we've seen enough of them, we'll have more knowledge of what a > new solution really needs to cover. Speculating prematurely will > likely give us the wrong abstractions (and/or at too high a level, > causing extra work and churn for everybody). I think we agree that > holding off is the right answer, just maybe not (yet) what the actual > solution might be when we start to need it. :) Yes. Especially for the runtime-pm stuff, someone should probably try both methods on a couple of systems and then decide which one of them everybody should use. Unfortunately that alone is going to bind reviewer resources and take a significant amount of time. > >> Simply using DT would help avoiding the awkward situation where a driver > >> of a device only works with one of the two description formats and not > >> the other. > > > > Yes, but remember that Intel still have the problem on their embedded > > systems, and will want to solve them. > > > > For ARM Linux I agree that we're better off not having to change all > > the drivers again for this, but we will have a growing number of > > drivers that are shared with ACPI based x86 SoCs. At least there are > > only one or two vendors of those chips ;-) > > Well, you menion DT-in-ACPI above. If they're really exploring that > path then a lot will sort itself out from there. Making a decision to > hold off with ACPI for ARM will help get everybody on the same page if > they're already considering a solution along those lines. Possibly, but x86 extending into deeply embedded may also have different requirements to ARM extending into servers, even if both want to use ACPI to get there. Some parts will overlap, others won't, and I suspect that there is more in the second category than people are hoping for. > >> > > I think we can still treat ACPI on ARM64 as a beginner's mistake and > >> > > provide hand-written DT blobs for the few systems that start shipping > >> > > with that. > >> > > >> > I think we can do better -- we can ask those vendors to not ship ACPI > >> > at all, and ship DT themselves (together with us for review, etc). > > Yep, and together for review is a critical part. I'm not saying that > the ideal solution is a flashed DTB, but it's better than ACPI. A > flashed DTB that's _easy to update_ as part of an OS install would > probably be one of the best solutions we could ask for though. Right: the assumption on the DT boot interfaces is that board designers make mistakes and are working on moving targets, so we need ways to update the DTB. By contrast, the assumption on ACPI is that server firmware authors know what they are doing and you shouldn't let anyone else mess with the ACPI bits because doing so might damage your hardware. We're in trouble if the second assumption turns out wrong. > > The bigger problem is system vendors > > we don't talk to. They are going to to do any number of crazy things > > in their private kernels: > > > > * Board files > > * Hardcoded platform devices with no multiplatform support > > * Custom hypervisor (EL2 or EL3) interfaces for probing > > * FEX > > * ACPI > > * Some other firmware ported over from their MIPS products > > * Incompatible Open Firmware > > * Incompatible DT extensions > > * ... > > Given that we have a documented boot protocol today, it shouldn't > matter much if someone ports over some MIPS firmware (we did add OF > client interface to CFE at PA Semi, and that worked well for us :-). > Most of the others listed above can hopefully be avoided by us having > appropriate solutions in-kernel today that they can reuse. I.e. FEX > happened because DT didn't exist at the time. > > ACPI is a big problem here in that sense: Vendors have been told to > use it, but there's no infrastructure, and even if it would be there > it would be immature and we don't really know what we want from it. > > Board files and hardcoded devices are things we've dealt with already > and know what to do with, so I'm less worried about that. And finally, > custom firmware interfaces should hopefully be rare given the > reference PSCI implementation from ARM, but we can deal with it if we > have to. Yes, the only real worry is if someone does their own firmware interfaces the way that Sony did on the PS3, which definitely requires custom APIs in the kernel. All others can be handled in some way by ignoring the provided interfaces and replacing them with DT. We might need some boot wrapper for cases where someone ignored the documented boot interfaces, but that would only be likely for systems designed for another OS. Arnd -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org More majordomo info at http://vger.kernel.org/majordomo-info.html ^ permalink raw reply [flat|nested] 186+ messages in thread
* ACPI vs DT at runtime @ 2013-11-18 8:45 ` Arnd Bergmann 0 siblings, 0 replies; 186+ messages in thread From: Arnd Bergmann @ 2013-11-18 8:45 UTC (permalink / raw) To: linux-arm-kernel On Sunday 17 November 2013, Olof Johansson wrote: > On Sun, Nov 17, 2013 at 10:10 AM, Arnd Bergmann <arnd@arndb.de> wrote: > > On Sunday 17 November 2013 17:18:03 Stefano Stabellini wrote: > > > > My point was not that everything would be good if we change the kernel > > this way, it clearly wouldn't. I think the problem is more the parts > > for which neither an automated translation nor a unified driver level > > interface would work well. > > Do you have predictions for what those areas would be? Chances are > that at least the initial ones can be handled with the methods we > already have today such as quirks and the like. I think all DT references that take the form of <&phandle arg1 ...> are problematic because in ACPI the same things tend to expressed by a single number (irq, dma, gpio, ...) or just a reference with no arguments (don't have an example here). Another difference is things that are numbered on one side but named on the other. In DT we have an inconsistent mix of the two, e.g. DMA requests must be named (per device) while IRQs must be numbered (per device) and may additionally be named. Finally, anything that needs run-time interpretation of AML is fundamentally hard because the AML would refer to objects that don't exist when you don't boot from ACPI. This gets worse if you need to pass ACPI identifiers into EL3 firmware. Because of this, anything related to runtime PM scares me at the moment, because there are two conflicting ways to do it: As we discussed before, the correct way to do this in ACPI is to hide it all from the OS in AML bytecode and EL2/EL3 firmware calls, but this may not be possible on all systems and it prevents us from translating into a format that the drivers can use to call our regulator/clk/pmdomain interfaces. Intel's embedded systems will likely get around this by defining ACPI representations of our existing DT bindings for these subsystems, which would be possible to translate automatically, but it seems very silly to use those on servers. > Once we've seen enough of them, we'll have more knowledge of what a > new solution really needs to cover. Speculating prematurely will > likely give us the wrong abstractions (and/or at too high a level, > causing extra work and churn for everybody). I think we agree that > holding off is the right answer, just maybe not (yet) what the actual > solution might be when we start to need it. :) Yes. Especially for the runtime-pm stuff, someone should probably try both methods on a couple of systems and then decide which one of them everybody should use. Unfortunately that alone is going to bind reviewer resources and take a significant amount of time. > >> Simply using DT would help avoiding the awkward situation where a driver > >> of a device only works with one of the two description formats and not > >> the other. > > > > Yes, but remember that Intel still have the problem on their embedded > > systems, and will want to solve them. > > > > For ARM Linux I agree that we're better off not having to change all > > the drivers again for this, but we will have a growing number of > > drivers that are shared with ACPI based x86 SoCs. At least there are > > only one or two vendors of those chips ;-) > > Well, you menion DT-in-ACPI above. If they're really exploring that > path then a lot will sort itself out from there. Making a decision to > hold off with ACPI for ARM will help get everybody on the same page if > they're already considering a solution along those lines. Possibly, but x86 extending into deeply embedded may also have different requirements to ARM extending into servers, even if both want to use ACPI to get there. Some parts will overlap, others won't, and I suspect that there is more in the second category than people are hoping for. > >> > > I think we can still treat ACPI on ARM64 as a beginner's mistake and > >> > > provide hand-written DT blobs for the few systems that start shipping > >> > > with that. > >> > > >> > I think we can do better -- we can ask those vendors to not ship ACPI > >> > at all, and ship DT themselves (together with us for review, etc). > > Yep, and together for review is a critical part. I'm not saying that > the ideal solution is a flashed DTB, but it's better than ACPI. A > flashed DTB that's _easy to update_ as part of an OS install would > probably be one of the best solutions we could ask for though. Right: the assumption on the DT boot interfaces is that board designers make mistakes and are working on moving targets, so we need ways to update the DTB. By contrast, the assumption on ACPI is that server firmware authors know what they are doing and you shouldn't let anyone else mess with the ACPI bits because doing so might damage your hardware. We're in trouble if the second assumption turns out wrong. > > The bigger problem is system vendors > > we don't talk to. They are going to to do any number of crazy things > > in their private kernels: > > > > * Board files > > * Hardcoded platform devices with no multiplatform support > > * Custom hypervisor (EL2 or EL3) interfaces for probing > > * FEX > > * ACPI > > * Some other firmware ported over from their MIPS products > > * Incompatible Open Firmware > > * Incompatible DT extensions > > * ... > > Given that we have a documented boot protocol today, it shouldn't > matter much if someone ports over some MIPS firmware (we did add OF > client interface to CFE at PA Semi, and that worked well for us :-). > Most of the others listed above can hopefully be avoided by us having > appropriate solutions in-kernel today that they can reuse. I.e. FEX > happened because DT didn't exist at the time. > > ACPI is a big problem here in that sense: Vendors have been told to > use it, but there's no infrastructure, and even if it would be there > it would be immature and we don't really know what we want from it. > > Board files and hardcoded devices are things we've dealt with already > and know what to do with, so I'm less worried about that. And finally, > custom firmware interfaces should hopefully be rare given the > reference PSCI implementation from ARM, but we can deal with it if we > have to. Yes, the only real worry is if someone does their own firmware interfaces the way that Sony did on the PS3, which definitely requires custom APIs in the kernel. All others can be handled in some way by ignoring the provided interfaces and replacing them with DT. We might need some boot wrapper for cases where someone ignored the documented boot interfaces, but that would only be likely for systems designed for another OS. Arnd ^ permalink raw reply [flat|nested] 186+ messages in thread
* ACPI vs DT at runtime 2013-11-18 8:45 ` Arnd Bergmann (?) @ 2013-11-18 17:33 ` Jon Masters 2013-11-18 17:38 ` Russell King - ARM Linux ` (2 more replies) -1 siblings, 3 replies; 186+ messages in thread From: Jon Masters @ 2013-11-18 17:33 UTC (permalink / raw) To: linux-arm-kernel On 11/18/2013 03:45 AM, Arnd Bergmann wrote: > On Sunday 17 November 2013, Olof Johansson wrote: >> Yep, and together for review is a critical part. I'm not saying that >> the ideal solution is a flashed DTB, but it's better than ACPI. A >> flashed DTB that's _easy to update_ as part of an OS install would >> probably be one of the best solutions we could ask for though. > > Right: the assumption on the DT boot interfaces is that board designers > make mistakes and are working on moving targets, so we need ways to update > the DTB. By contrast, the assumption on ACPI is that server firmware > authors know what they are doing and you shouldn't let anyone else mess > with the ACPI bits because doing so might damage your hardware. We're > in trouble if the second assumption turns out wrong. In the server space we *never* ship updated ACPI tables in Red Hat products, and we never would ship updated tables as part of the OS. Platform data is platform data. It belongs to the vendor shipping the system, never to the OS. Yes, there are workarounds for bugs but on the whole you do in fact count on server vendors not to screw it up, and if they do then it is up to them to ship a BIOS update for their hardware. In the Fedora space, even on 32-bit, we tried to not get in the business of shipping DeviceTree blobs (way back when) that should be shipped by the platform, but alas many systems don't have flash to store the DTB. Coupled with the moving target we're dealing with there...things have been ugly. In the v8 server space, there will be no shipping of platform data. It will be ACPI tables passed in via UEFI, never updated by the OS, and owned wholly by the platform vendor. Jon. ^ permalink raw reply [flat|nested] 186+ messages in thread
* ACPI vs DT at runtime 2013-11-18 17:33 ` Jon Masters @ 2013-11-18 17:38 ` Russell King - ARM Linux [not found] ` <528A4F5F.7080104-Zp4isUonpHBD60Wz+7aTrA@public.gmane.org> 2013-11-21 18:26 ` Grant Likely 2 siblings, 0 replies; 186+ messages in thread From: Russell King - ARM Linux @ 2013-11-18 17:38 UTC (permalink / raw) To: linux-arm-kernel On Mon, Nov 18, 2013 at 12:33:19PM -0500, Jon Masters wrote: > In the server space we *never* ship updated ACPI tables in Red Hat > products, and we never would ship updated tables as part of the OS. > Platform data is platform data. It belongs to the vendor shipping the > system, never to the OS. Yes, there are workarounds for bugs but on the > whole you do in fact count on server vendors not to screw it up, and if > they do then it is up to them to ship a BIOS update for their hardware. ... which is why my nightly autoboot tests regularly fail if I undock and redock the laptop, and forget to manually rebind the serial port... because the vendor supplied ACPI tables seem to be broken, and there's zero interest from the vendor to fix such an issue. They're certainly not going to fix it based on one report from an end user using an obscure operating system which seems not to have any support in mainline for such oeprations in any case. Linux sucks sometimes - it's not all roses. ^ permalink raw reply [flat|nested] 186+ messages in thread
[parent not found: <528A4F5F.7080104-Zp4isUonpHBD60Wz+7aTrA@public.gmane.org>]
* Re: ACPI vs DT at runtime 2013-11-18 17:33 ` Jon Masters @ 2013-11-18 19:21 ` Olof Johansson [not found] ` <528A4F5F.7080104-Zp4isUonpHBD60Wz+7aTrA@public.gmane.org> 2013-11-21 18:26 ` Grant Likely 2 siblings, 0 replies; 186+ messages in thread From: Olof Johansson @ 2013-11-18 19:21 UTC (permalink / raw) To: Jon Masters Cc: linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r, devicetree-u79uwXL29TY76Z2rM5mHXA On Mon, Nov 18, 2013 at 12:33:19PM -0500, Jon Masters wrote: > On 11/18/2013 03:45 AM, Arnd Bergmann wrote: > > On Sunday 17 November 2013, Olof Johansson wrote: > > >> Yep, and together for review is a critical part. I'm not saying that > >> the ideal solution is a flashed DTB, but it's better than ACPI. A > >> flashed DTB that's _easy to update_ as part of an OS install would > >> probably be one of the best solutions we could ask for though. > > > > Right: the assumption on the DT boot interfaces is that board designers > > make mistakes and are working on moving targets, so we need ways to update > > the DTB. By contrast, the assumption on ACPI is that server firmware > > authors know what they are doing and you shouldn't let anyone else mess > > with the ACPI bits because doing so might damage your hardware. We're > > in trouble if the second assumption turns out wrong. > > In the server space we *never* ship updated ACPI tables in Red Hat > products, and we never would ship updated tables as part of the OS. > Platform data is platform data. It belongs to the vendor shipping the > system, never to the OS. Yes, there are workarounds for bugs but on the > whole you do in fact count on server vendors not to screw it up, and if > they do then it is up to them to ship a BIOS update for their hardware. And in x86 land these days, they mostly don't screw it up because they've been doing this for years and years. On ARM we've got a dozen new vendors who have never done any of this before (and neither have we), and we're all going to screw it up. Denying that buys us nothing, planning for it in a manner that we can recover from the worst screwups without paying for it forever is the best way forward. > In the Fedora space, even on 32-bit, we tried to not get in the business > of shipping DeviceTree blobs (way back when) that should be shipped by > the platform, but alas many systems don't have flash to store the DTB. Well, duh, that was what we, as the kernel community, had mandated at the time. > Coupled with the moving target we're dealing with there...things have > been ugly. In the v8 server space, there will be no shipping of platform > data. It will be ACPI tables passed in via UEFI, never updated by the > OS, and owned wholly by the platform vendor. Everything is a moving target on ARMv8 today. ACPI isn't going to change that. -Olof -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org More majordomo info at http://vger.kernel.org/majordomo-info.html ^ permalink raw reply [flat|nested] 186+ messages in thread
* ACPI vs DT at runtime @ 2013-11-18 19:21 ` Olof Johansson 0 siblings, 0 replies; 186+ messages in thread From: Olof Johansson @ 2013-11-18 19:21 UTC (permalink / raw) To: linux-arm-kernel On Mon, Nov 18, 2013 at 12:33:19PM -0500, Jon Masters wrote: > On 11/18/2013 03:45 AM, Arnd Bergmann wrote: > > On Sunday 17 November 2013, Olof Johansson wrote: > > >> Yep, and together for review is a critical part. I'm not saying that > >> the ideal solution is a flashed DTB, but it's better than ACPI. A > >> flashed DTB that's _easy to update_ as part of an OS install would > >> probably be one of the best solutions we could ask for though. > > > > Right: the assumption on the DT boot interfaces is that board designers > > make mistakes and are working on moving targets, so we need ways to update > > the DTB. By contrast, the assumption on ACPI is that server firmware > > authors know what they are doing and you shouldn't let anyone else mess > > with the ACPI bits because doing so might damage your hardware. We're > > in trouble if the second assumption turns out wrong. > > In the server space we *never* ship updated ACPI tables in Red Hat > products, and we never would ship updated tables as part of the OS. > Platform data is platform data. It belongs to the vendor shipping the > system, never to the OS. Yes, there are workarounds for bugs but on the > whole you do in fact count on server vendors not to screw it up, and if > they do then it is up to them to ship a BIOS update for their hardware. And in x86 land these days, they mostly don't screw it up because they've been doing this for years and years. On ARM we've got a dozen new vendors who have never done any of this before (and neither have we), and we're all going to screw it up. Denying that buys us nothing, planning for it in a manner that we can recover from the worst screwups without paying for it forever is the best way forward. > In the Fedora space, even on 32-bit, we tried to not get in the business > of shipping DeviceTree blobs (way back when) that should be shipped by > the platform, but alas many systems don't have flash to store the DTB. Well, duh, that was what we, as the kernel community, had mandated at the time. > Coupled with the moving target we're dealing with there...things have > been ugly. In the v8 server space, there will be no shipping of platform > data. It will be ACPI tables passed in via UEFI, never updated by the > OS, and owned wholly by the platform vendor. Everything is a moving target on ARMv8 today. ACPI isn't going to change that. -Olof ^ permalink raw reply [flat|nested] 186+ messages in thread
* ACPI vs DT at runtime 2013-11-18 17:33 ` Jon Masters 2013-11-18 17:38 ` Russell King - ARM Linux [not found] ` <528A4F5F.7080104-Zp4isUonpHBD60Wz+7aTrA@public.gmane.org> @ 2013-11-21 18:26 ` Grant Likely 2 siblings, 0 replies; 186+ messages in thread From: Grant Likely @ 2013-11-21 18:26 UTC (permalink / raw) To: linux-arm-kernel On Mon, 18 Nov 2013 12:33:19 -0500, Jon Masters <jonathan@jonmasters.org> wrote: > On 11/18/2013 03:45 AM, Arnd Bergmann wrote: > > On Sunday 17 November 2013, Olof Johansson wrote: > > >> Yep, and together for review is a critical part. I'm not saying that > >> the ideal solution is a flashed DTB, but it's better than ACPI. A > >> flashed DTB that's _easy to update_ as part of an OS install would > >> probably be one of the best solutions we could ask for though. > > > > Right: the assumption on the DT boot interfaces is that board designers > > make mistakes and are working on moving targets, so we need ways to update > > the DTB. By contrast, the assumption on ACPI is that server firmware > > authors know what they are doing and you shouldn't let anyone else mess > > with the ACPI bits because doing so might damage your hardware. We're > > in trouble if the second assumption turns out wrong. > > In the server space we *never* ship updated ACPI tables in Red Hat > products, and we never would ship updated tables as part of the OS. > Platform data is platform data. It belongs to the vendor shipping the > system, never to the OS. Yes, there are workarounds for bugs but on the > whole you do in fact count on server vendors not to screw it up, and if > they do then it is up to them to ship a BIOS update for their hardware. Agreed, shipping tables with RHEL is insane. If DT is used on the servers, then the firmware needs to provide the DT, with the option to override only when *absolutely* necessary. g. ^ permalink raw reply [flat|nested] 186+ messages in thread
* Re: ACPI vs DT at runtime 2013-11-17 18:10 ` Arnd Bergmann @ 2013-11-18 15:04 ` Mark Brown -1 siblings, 0 replies; 186+ messages in thread From: Mark Brown @ 2013-11-18 15:04 UTC (permalink / raw) To: Arnd Bergmann Cc: Stefano Stabellini, Olof Johansson, Grant Likely, linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r, devicetree-u79uwXL29TY76Z2rM5mHXA [-- Attachment #1: Type: text/plain, Size: 624 bytes --] On Sun, Nov 17, 2013 at 07:10:51PM +0100, Arnd Bergmann wrote: > On Sunday 17 November 2013 17:18:03 Stefano Stabellini wrote: > > Simply using DT would help avoiding the awkward situation where a driver > > of a device only works with one of the two description formats and not > > the other. > Yes, but remember that Intel still have the problem on their embedded > systems, and will want to solve them. Has it been confirmed that Intel are going with ACPI for their embedded devices rather than SFI? That would be nice given how awful SFI is and I have heard that before but I'm not sure I've seen anything official. [-- Attachment #2: Digital signature --] [-- Type: application/pgp-signature, Size: 836 bytes --] ^ permalink raw reply [flat|nested] 186+ messages in thread
* ACPI vs DT at runtime @ 2013-11-18 15:04 ` Mark Brown 0 siblings, 0 replies; 186+ messages in thread From: Mark Brown @ 2013-11-18 15:04 UTC (permalink / raw) To: linux-arm-kernel On Sun, Nov 17, 2013 at 07:10:51PM +0100, Arnd Bergmann wrote: > On Sunday 17 November 2013 17:18:03 Stefano Stabellini wrote: > > Simply using DT would help avoiding the awkward situation where a driver > > of a device only works with one of the two description formats and not > > the other. > Yes, but remember that Intel still have the problem on their embedded > systems, and will want to solve them. Has it been confirmed that Intel are going with ACPI for their embedded devices rather than SFI? That would be nice given how awful SFI is and I have heard that before but I'm not sure I've seen anything official. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 836 bytes Desc: Digital signature URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20131118/965930a8/attachment.sig> ^ permalink raw reply [flat|nested] 186+ messages in thread
* Re: ACPI vs DT at runtime 2013-11-18 15:04 ` Mark Brown @ 2013-11-18 15:10 ` Arnd Bergmann -1 siblings, 0 replies; 186+ messages in thread From: Arnd Bergmann @ 2013-11-18 15:10 UTC (permalink / raw) To: Mark Brown Cc: Olof Johansson, Grant Likely, devicetree, linux-arm-kernel, Stefano Stabellini On Monday 18 November 2013, Mark Brown wrote: > On Sun, Nov 17, 2013 at 07:10:51PM +0100, Arnd Bergmann wrote: > > On Sunday 17 November 2013 17:18:03 Stefano Stabellini wrote: > > > > Simply using DT would help avoiding the awkward situation where a driver > > > of a device only works with one of the two description formats and not > > > the other. > > > Yes, but remember that Intel still have the problem on their embedded > > systems, and will want to solve them. > > Has it been confirmed that Intel are going with ACPI for their embedded > devices rather than SFI? That would be nice given how awful SFI is and > I have heard that before but I'm not sure I've seen anything official. Possibly not all of Intel agrees to that, but I think that's what I've heard from Darrent Hart and David Woodhouse. I doubt you can get an "official" confirmation about it. I also don't know if there is a follow-up for the Intel CE4100 that started using DT[1]. Arnd [1] arch/x86/platform/ce4100/falconfalls.dts ^ permalink raw reply [flat|nested] 186+ messages in thread
* ACPI vs DT at runtime @ 2013-11-18 15:10 ` Arnd Bergmann 0 siblings, 0 replies; 186+ messages in thread From: Arnd Bergmann @ 2013-11-18 15:10 UTC (permalink / raw) To: linux-arm-kernel On Monday 18 November 2013, Mark Brown wrote: > On Sun, Nov 17, 2013 at 07:10:51PM +0100, Arnd Bergmann wrote: > > On Sunday 17 November 2013 17:18:03 Stefano Stabellini wrote: > > > > Simply using DT would help avoiding the awkward situation where a driver > > > of a device only works with one of the two description formats and not > > > the other. > > > Yes, but remember that Intel still have the problem on their embedded > > systems, and will want to solve them. > > Has it been confirmed that Intel are going with ACPI for their embedded > devices rather than SFI? That would be nice given how awful SFI is and > I have heard that before but I'm not sure I've seen anything official. Possibly not all of Intel agrees to that, but I think that's what I've heard from Darrent Hart and David Woodhouse. I doubt you can get an "official" confirmation about it. I also don't know if there is a follow-up for the Intel CE4100 that started using DT[1]. Arnd [1] arch/x86/platform/ce4100/falconfalls.dts ^ permalink raw reply [flat|nested] 186+ messages in thread
[parent not found: < 201311181610.33105.arnd@arndb.de>]
[parent not found: <201311181610.33105.arnd-r2nGTMty4D4@public.gmane.org>]
* Re: ACPI vs DT at runtime 2013-11-18 15:10 ` Arnd Bergmann @ 2013-11-18 21:38 ` Grant Likely -1 siblings, 0 replies; 186+ messages in thread From: Grant Likely @ 2013-11-18 21:38 UTC (permalink / raw) To: Arnd Bergmann, Mark Brown Cc: Stefano Stabellini, Olof Johansson, linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r, devicetree-u79uwXL29TY76Z2rM5mHXA On Mon, 18 Nov 2013 16:10:32 +0100, Arnd Bergmann <arnd-r2nGTMty4D4@public.gmane.org> wrote: > On Monday 18 November 2013, Mark Brown wrote: > > On Sun, Nov 17, 2013 at 07:10:51PM +0100, Arnd Bergmann wrote: > > > On Sunday 17 November 2013 17:18:03 Stefano Stabellini wrote: > > > > > > Simply using DT would help avoiding the awkward situation where a driver > > > > of a device only works with one of the two description formats and not > > > > the other. > > > > > Yes, but remember that Intel still have the problem on their embedded > > > systems, and will want to solve them. > > > > Has it been confirmed that Intel are going with ACPI for their embedded > > devices rather than SFI? That would be nice given how awful SFI is and > > I have heard that before but I'm not sure I've seen anything official. > > Possibly not all of Intel agrees to that, but I think that's what I've > heard from Darrent Hart and David Woodhouse. I doubt you can get an > "official" confirmation about it. I also don't know if there is a follow-up > for the Intel CE4100 that started using DT[1]. Darren is using it to enable Minnowboard, and there is active work on the GPIO, SPI and other subsystems to bring in ACPI support. g. -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org More majordomo info at http://vger.kernel.org/majordomo-info.html ^ permalink raw reply [flat|nested] 186+ messages in thread
* ACPI vs DT at runtime @ 2013-11-18 21:38 ` Grant Likely 0 siblings, 0 replies; 186+ messages in thread From: Grant Likely @ 2013-11-18 21:38 UTC (permalink / raw) To: linux-arm-kernel On Mon, 18 Nov 2013 16:10:32 +0100, Arnd Bergmann <arnd@arndb.de> wrote: > On Monday 18 November 2013, Mark Brown wrote: > > On Sun, Nov 17, 2013 at 07:10:51PM +0100, Arnd Bergmann wrote: > > > On Sunday 17 November 2013 17:18:03 Stefano Stabellini wrote: > > > > > > Simply using DT would help avoiding the awkward situation where a driver > > > > of a device only works with one of the two description formats and not > > > > the other. > > > > > Yes, but remember that Intel still have the problem on their embedded > > > systems, and will want to solve them. > > > > Has it been confirmed that Intel are going with ACPI for their embedded > > devices rather than SFI? That would be nice given how awful SFI is and > > I have heard that before but I'm not sure I've seen anything official. > > Possibly not all of Intel agrees to that, but I think that's what I've > heard from Darrent Hart and David Woodhouse. I doubt you can get an > "official" confirmation about it. I also don't know if there is a follow-up > for the Intel CE4100 that started using DT[1]. Darren is using it to enable Minnowboard, and there is active work on the GPIO, SPI and other subsystems to bring in ACPI support. g. ^ permalink raw reply [flat|nested] 186+ messages in thread
* Re: ACPI vs DT at runtime 2013-11-15 1:44 ` Olof Johansson @ 2013-11-18 23:25 ` Leif Lindholm -1 siblings, 0 replies; 186+ messages in thread From: Leif Lindholm @ 2013-11-18 23:25 UTC (permalink / raw) To: Olof Johansson Cc: devicetree-u79uwXL29TY76Z2rM5mHXA, linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r, Grant Likely, Arnd Bergmann Hi Olof, Just in case this thread fails to reach its predicted triple-digits, I would like to revisit something you mentioned in this original email and then didn't expand on. On Thu, Nov 14, 2013 at 05:44:10PM -0800, Olof Johansson wrote: > The more I start to see early UEFI/ACPI code, the more I am certain > that we want none of that crap in the kernel. It's making things > considerably messier, while we're already very busy trying to convert > everything over and enable DT -- we'll be preempting that effort just > to add even more boilerplate everywhere and total progress will be > hurt. > > The server guys really want UEFI for their boot protocols, > installation managers, etc, etc. That's fine, let them do that, but > that doesn't mean we need to bring the same APIs all the way into the > kernel. There is zero dependency on ACPI in the UEFI support code, or indeed in UEFI itself. Both runtime services support and stub loader have been designed hardware-description agnostic. Are you saying that we should not support the kernel interfaces to UEFI on ARM*, or are you simply mentioning it in passing because it is the bit responsible for populating the pointer to the ACPI tables? / Leif -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org More majordomo info at http://vger.kernel.org/majordomo-info.html ^ permalink raw reply [flat|nested] 186+ messages in thread
* ACPI vs DT at runtime @ 2013-11-18 23:25 ` Leif Lindholm 0 siblings, 0 replies; 186+ messages in thread From: Leif Lindholm @ 2013-11-18 23:25 UTC (permalink / raw) To: linux-arm-kernel Hi Olof, Just in case this thread fails to reach its predicted triple-digits, I would like to revisit something you mentioned in this original email and then didn't expand on. On Thu, Nov 14, 2013 at 05:44:10PM -0800, Olof Johansson wrote: > The more I start to see early UEFI/ACPI code, the more I am certain > that we want none of that crap in the kernel. It's making things > considerably messier, while we're already very busy trying to convert > everything over and enable DT -- we'll be preempting that effort just > to add even more boilerplate everywhere and total progress will be > hurt. > > The server guys really want UEFI for their boot protocols, > installation managers, etc, etc. That's fine, let them do that, but > that doesn't mean we need to bring the same APIs all the way into the > kernel. There is zero dependency on ACPI in the UEFI support code, or indeed in UEFI itself. Both runtime services support and stub loader have been designed hardware-description agnostic. Are you saying that we should not support the kernel interfaces to UEFI on ARM*, or are you simply mentioning it in passing because it is the bit responsible for populating the pointer to the ACPI tables? / Leif ^ permalink raw reply [flat|nested] 186+ messages in thread
[parent not found: <20131118232536.GF1567-GZEopFhza0F985/tl1ce8aaDwS/vmuI7@public.gmane.org>]
* Re: ACPI vs DT at runtime 2013-11-18 23:25 ` Leif Lindholm @ 2013-11-18 23:29 ` Olof Johansson -1 siblings, 0 replies; 186+ messages in thread From: Olof Johansson @ 2013-11-18 23:29 UTC (permalink / raw) To: Leif Lindholm Cc: devicetree-u79uwXL29TY76Z2rM5mHXA, linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r, Grant Likely, Arnd Bergmann Hej, On Mon, Nov 18, 2013 at 3:25 PM, Leif Lindholm <leif.lindholm-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org> wrote: > Hi Olof, > > Just in case this thread fails to reach its predicted triple-digits, I > would like to revisit something you mentioned in this original email > and then didn't expand on. > > On Thu, Nov 14, 2013 at 05:44:10PM -0800, Olof Johansson wrote: >> The more I start to see early UEFI/ACPI code, the more I am certain >> that we want none of that crap in the kernel. It's making things >> considerably messier, while we're already very busy trying to convert >> everything over and enable DT -- we'll be preempting that effort just >> to add even more boilerplate everywhere and total progress will be >> hurt. >> >> The server guys really want UEFI for their boot protocols, >> installation managers, etc, etc. That's fine, let them do that, but >> that doesn't mean we need to bring the same APIs all the way into the >> kernel. > > There is zero dependency on ACPI in the UEFI support code, or indeed in > UEFI itself. Both runtime services support and stub loader have been > designed hardware-description agnostic. > > Are you saying that we should not support the kernel interfaces to UEFI > on ARM*, or are you simply mentioning it in passing because it is the > bit responsible for populating the pointer to the ACPI tables? Good question. UEFI and ACPI usually gets grouped together when they really are separate (even though ACPI _without_ UEFI is highly unlikely). So, to clarify: What I meant with the above is that UEFI as a bootloader is fine as far as I am concerned. I'm also in general ok with the introduction of efivars that you're doing, etc. -Olof -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org More majordomo info at http://vger.kernel.org/majordomo-info.html ^ permalink raw reply [flat|nested] 186+ messages in thread
* ACPI vs DT at runtime @ 2013-11-18 23:29 ` Olof Johansson 0 siblings, 0 replies; 186+ messages in thread From: Olof Johansson @ 2013-11-18 23:29 UTC (permalink / raw) To: linux-arm-kernel Hej, On Mon, Nov 18, 2013 at 3:25 PM, Leif Lindholm <leif.lindholm@linaro.org> wrote: > Hi Olof, > > Just in case this thread fails to reach its predicted triple-digits, I > would like to revisit something you mentioned in this original email > and then didn't expand on. > > On Thu, Nov 14, 2013 at 05:44:10PM -0800, Olof Johansson wrote: >> The more I start to see early UEFI/ACPI code, the more I am certain >> that we want none of that crap in the kernel. It's making things >> considerably messier, while we're already very busy trying to convert >> everything over and enable DT -- we'll be preempting that effort just >> to add even more boilerplate everywhere and total progress will be >> hurt. >> >> The server guys really want UEFI for their boot protocols, >> installation managers, etc, etc. That's fine, let them do that, but >> that doesn't mean we need to bring the same APIs all the way into the >> kernel. > > There is zero dependency on ACPI in the UEFI support code, or indeed in > UEFI itself. Both runtime services support and stub loader have been > designed hardware-description agnostic. > > Are you saying that we should not support the kernel interfaces to UEFI > on ARM*, or are you simply mentioning it in passing because it is the > bit responsible for populating the pointer to the ACPI tables? Good question. UEFI and ACPI usually gets grouped together when they really are separate (even though ACPI _without_ UEFI is highly unlikely). So, to clarify: What I meant with the above is that UEFI as a bootloader is fine as far as I am concerned. I'm also in general ok with the introduction of efivars that you're doing, etc. -Olof ^ permalink raw reply [flat|nested] 186+ messages in thread
[parent not found: <CAOesGMh373ZsLzoGHJm+xV3uFVjh2CBSA8SXY4PA+VxL3a5W1w-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>]
* Re: ACPI vs DT at runtime 2013-11-18 23:29 ` Olof Johansson @ 2013-11-18 23:34 ` Leif Lindholm -1 siblings, 0 replies; 186+ messages in thread From: Leif Lindholm @ 2013-11-18 23:34 UTC (permalink / raw) To: Olof Johansson Cc: devicetree-u79uwXL29TY76Z2rM5mHXA, linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r, Grant Likely, Arnd Bergmann Hej, On Mon, Nov 18, 2013 at 03:29:58PM -0800, Olof Johansson wrote: > >> The server guys really want UEFI for their boot protocols, > >> installation managers, etc, etc. That's fine, let them do that, but > >> that doesn't mean we need to bring the same APIs all the way into the > >> kernel. > > > > There is zero dependency on ACPI in the UEFI support code, or indeed in > > UEFI itself. Both runtime services support and stub loader have been > > designed hardware-description agnostic. > > > > Are you saying that we should not support the kernel interfaces to UEFI > > on ARM*, or are you simply mentioning it in passing because it is the > > bit responsible for populating the pointer to the ACPI tables? > > Good question. UEFI and ACPI usually gets grouped together when they > really are separate (even though ACPI _without_ UEFI is highly > unlikely). > > So, to clarify: What I meant with the above is that UEFI as a > bootloader is fine as far as I am concerned. I'm also in general ok > with the introduction of efivars that you're doing, etc. Thank you for this clarification. / Leif -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org More majordomo info at http://vger.kernel.org/majordomo-info.html ^ permalink raw reply [flat|nested] 186+ messages in thread
* ACPI vs DT at runtime @ 2013-11-18 23:34 ` Leif Lindholm 0 siblings, 0 replies; 186+ messages in thread From: Leif Lindholm @ 2013-11-18 23:34 UTC (permalink / raw) To: linux-arm-kernel Hej, On Mon, Nov 18, 2013 at 03:29:58PM -0800, Olof Johansson wrote: > >> The server guys really want UEFI for their boot protocols, > >> installation managers, etc, etc. That's fine, let them do that, but > >> that doesn't mean we need to bring the same APIs all the way into the > >> kernel. > > > > There is zero dependency on ACPI in the UEFI support code, or indeed in > > UEFI itself. Both runtime services support and stub loader have been > > designed hardware-description agnostic. > > > > Are you saying that we should not support the kernel interfaces to UEFI > > on ARM*, or are you simply mentioning it in passing because it is the > > bit responsible for populating the pointer to the ACPI tables? > > Good question. UEFI and ACPI usually gets grouped together when they > really are separate (even though ACPI _without_ UEFI is highly > unlikely). > > So, to clarify: What I meant with the above is that UEFI as a > bootloader is fine as far as I am concerned. I'm also in general ok > with the introduction of efivars that you're doing, etc. Thank you for this clarification. / Leif ^ permalink raw reply [flat|nested] 186+ messages in thread
end of thread, other threads:[~2014-05-06 16:32 UTC | newest] Thread overview: 186+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2013-11-15 1:44 ACPI vs DT at runtime Olof Johansson 2013-11-15 1:44 ` Olof Johansson 2013-11-15 9:57 ` Mark Rutland 2013-11-15 9:57 ` Mark Rutland [not found] ` <20131115175241. GB27174@quad.lixom.net> [not found] ` <20131115095717.GC1709-NuALmloUBlrZROr8t4l/smS4ubULX0JqMm0uRHvK7Nw@public.gmane.org> 2013-11-15 17:52 ` Olof Johansson 2013-11-15 17:52 ` Olof Johansson 2013-11-15 18:13 ` David Goodenough 2013-11-21 16:15 ` Grant Likely 2013-11-18 17:47 ` Jon Masters 2013-11-18 17:47 ` Jon Masters [not found] ` <20131115175241.GB27174-O5ziIzlqnXUVNXGz7ipsyg@public.gmane.org> 2013-11-15 18:08 ` Russell King - ARM Linux 2013-11-15 18:08 ` Russell King - ARM Linux [not found] ` <20131115180832.GR16735-l+eeeJia6m9vn6HldHNs0ANdhmdF6hFW@public.gmane.org> 2013-11-15 18:42 ` Olof Johansson 2013-11-15 18:42 ` Olof Johansson 2013-11-15 19:56 ` Arnd Bergmann 2013-11-15 19:56 ` Arnd Bergmann [not found] ` <201311152056.47846.arnd-r2nGTMty4D4@public.gmane.org> 2013-11-15 23:21 ` Russell King - ARM Linux 2013-11-15 23:21 ` Russell King - ARM Linux [not found] ` <20131115232109.GT16735-l+eeeJia6m9vn6HldHNs0ANdhmdF6hFW@public.gmane.org> 2013-11-18 15:05 ` Arnd Bergmann 2013-11-18 15:05 ` Arnd Bergmann [not found] ` <201311181605.37300.arnd-r2nGTMty4D4@public.gmane.org> 2013-11-18 15:19 ` Russell King - ARM Linux 2013-11-18 15:19 ` Russell King - ARM Linux 2013-11-18 15:46 ` Arnd Bergmann 2013-11-18 15:46 ` Arnd Bergmann 2013-11-21 16:10 ` Grant Likely 2013-11-21 16:10 ` Grant Likely [not found] ` <20131121161037.C528CC406A3-WNowdnHR2B42iJbIjFUEsiwD8/FfD2ys@public.gmane.org> 2013-11-21 18:26 ` Arnd Bergmann 2013-11-21 18:26 ` Arnd Bergmann 2013-11-21 19:40 ` Mark Brown 2013-11-21 19:40 ` Mark Brown [not found] ` <20131118151900.GF16735@ n2100.arm.linux.org.uk> [not found] ` <20131118151900.GF16735-l+eeeJia6m9vn6HldHNs0ANdhmdF6hFW@public.gmane.org> 2013-11-21 16:11 ` Grant Likely 2013-11-21 16:11 ` Grant Likely 2013-11-21 16:00 ` Grant Likely 2013-11-21 16:00 ` Grant Likely 2013-11-19 11:30 ` Mark Rutland 2013-11-19 11:30 ` Mark Rutland 2013-11-19 11:35 ` Mark Rutland 2013-11-19 11:35 ` Mark Rutland [not found] ` <20131119113557.GI5914-NuALmloUBlrZROr8t4l/smS4ubULX0JqMm0uRHvK7Nw@public.gmane.org> 2013-11-19 11:51 ` Leif Lindholm 2013-11-19 11:51 ` Leif Lindholm [not found] ` <20131119113015.GH5914-NuALmloUBlrZROr8t4l/smS4ubULX0JqMm0uRHvK7Nw@public.gmane.org> 2013-11-19 11:57 ` Russell King - ARM Linux 2013-11-19 11:57 ` Russell King - ARM Linux 2013-11-19 13:56 ` Stefano Stabellini 2013-11-19 13:56 ` Stefano Stabellini 2013-11-19 14:38 ` Mark Rutland 2013-11-19 14:38 ` Mark Rutland [not found] ` <20131119143840.GN5914-NuALmloUBlrZROr8t4l/smS4ubULX0JqMm0uRHvK7Nw@public.gmane.org> 2013-11-19 14:59 ` Leif Lindholm 2013-11-19 14:59 ` Leif Lindholm 2013-11-19 18:23 ` Olof Johansson 2013-11-19 18:23 ` Olof Johansson 2013-11-19 14:05 ` Arnd Bergmann 2013-11-19 14:05 ` Arnd Bergmann 2013-11-19 15:21 ` Mark Rutland 2013-11-19 15:21 ` Mark Rutland [not found] ` <20131119152157.GO5914-NuALmloUBlrZROr8t4l/smS4ubULX0JqMm0uRHvK7Nw@public.gmane.org> 2013-11-19 16:19 ` Arnd Bergmann 2013-11-19 16:19 ` Arnd Bergmann 2013-11-19 18:34 ` Olof Johansson 2013-11-19 18:34 ` Olof Johansson 2013-11-19 19:06 ` Tom Rini 2013-11-19 19:06 ` Tom Rini 2013-11-19 18:19 ` Olof Johansson 2013-11-19 18:19 ` Olof Johansson [not found] ` <20131119181959.GA20967-O5ziIzlqnXUVNXGz7ipsyg@public.gmane.org> 2013-11-21 16:37 ` Grant Likely 2013-11-21 16:37 ` Grant Likely 2013-11-21 16:29 ` Grant Likely 2013-11-21 16:29 ` Grant Likely [not found] ` <20131121170122. GB22960@srcf.ucam.org> [not found] ` <20131121170122.GB22960-1xO5oi07KQx4cg9Nei1l7Q@public.gmane.org> 2013-11-21 18:38 ` Grant Likely 2013-11-21 18:38 ` Grant Likely [not found] ` <20131121162944.F087FC406A3-WNowdnHR2B42iJbIjFUEsiwD8/FfD2ys@public.gmane.org> 2013-11-21 17:01 ` Matthew Garrett 2013-11-21 17:01 ` Matthew Garrett 2013-11-21 17:58 ` Olof Johansson 2013-11-21 17:58 ` Olof Johansson [not found] ` <20131121175822.GA9590-O5ziIzlqnXUVNXGz7ipsyg@public.gmane.org> 2013-11-21 18:19 ` Matthew Garrett 2013-11-21 18:19 ` Matthew Garrett 2013-11-21 18:33 ` Arnd Bergmann 2013-11-21 18:33 ` Arnd Bergmann 2013-11-21 18:54 ` Russell King - ARM Linux 2013-11-21 18:54 ` Russell King - ARM Linux [not found] ` <20131121185408.GX16735-l+eeeJia6m9vn6HldHNs0ANdhmdF6hFW@public.gmane.org> 2013-11-21 18:59 ` Olof Johansson 2013-11-21 18:59 ` Olof Johansson [not found] ` <CAOesGMgzUSMDy99XojipfRd5OM88UhfbCYO0aoc5m-Q8Fwnddg-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org> 2013-11-21 19:01 ` Russell King - ARM Linux 2013-11-21 19:01 ` Russell King - ARM Linux [not found] ` <20131121190126.GZ16735-l+eeeJia6m9vn6HldHNs0ANdhmdF6hFW@public.gmane.org> 2013-11-21 19:31 ` Olof Johansson 2013-11-21 19:31 ` Olof Johansson [not found] ` < CAOesGMgzUSMDy99XojipfRd5OM88UhfbCYO0aoc5m-Q8Fwnddg@mail.gmail.com> [not found] ` < 20131121190126.GZ16735@n2100.arm.linux.org.uk> [not found] ` < CAOesGMgxGq1Zmo+Dq-Rmy2F02-=12yUzB0AKn35yK2j3CacNRQ@mail.gmail.com> [not found] ` <CAOesGMgxGq1Zmo+Dq-Rmy2F02-=12yUzB0AKn35yK2j3CacNRQ-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org> 2013-11-21 20:44 ` Grant Likely 2013-11-21 20:44 ` Grant Likely 2013-11-21 18:53 ` Mark Brown 2013-11-21 18:53 ` Mark Brown 2013-11-15 18:28 ` Jason Gunthorpe 2013-11-15 18:28 ` Jason Gunthorpe [not found] ` <20131115182826.GB14920-ePGOBjL8dl3ta4EC/59zMFaTQe2KTcn/@public.gmane.org> 2013-11-15 18:57 ` Arnd Bergmann 2013-11-15 18:57 ` Arnd Bergmann 2013-11-20 13:49 ` Grant Likely 2013-11-20 13:49 ` Grant Likely [not found] ` <20131120134942.95DBFC4079D-WNowdnHR2B42iJbIjFUEsiwD8/FfD2ys@public.gmane.org> 2013-11-20 17:43 ` Stefano Stabellini 2013-11-20 17:43 ` Stefano Stabellini [not found] ` <alpine.DEB.2.02.1311201737410.3198-7Z66fg9igcxYtxbxJUhB2Dgeux46jI+i@public.gmane.org> 2013-11-20 17:47 ` Olof Johansson 2013-11-20 17:47 ` Olof Johansson 2013-11-18 5:19 ` Jon Masters 2013-11-18 5:26 ` Jon Masters [not found] ` <5289A4F3.5040203-Zp4isUonpHBD60Wz+7aTrA@public.gmane.org> 2013-11-18 19:25 ` Olof Johansson 2013-11-18 19:25 ` Olof Johansson [not found] ` <20131118192552.GD5886-O5ziIzlqnXUVNXGz7ipsyg@public.gmane.org> 2013-11-18 20:43 ` Jon Masters 2013-11-18 20:43 ` Jon Masters [not found] ` <528A7BFD.4020303-Zp4isUonpHBD60Wz+7aTrA@public.gmane.org> 2013-11-18 21:25 ` Olof Johansson 2013-11-18 21:25 ` Olof Johansson 2013-11-18 7:22 ` Richard Cochran 2013-11-18 13:55 ` Stefano Stabellini 2013-11-18 15:00 ` Mark Brown [not found] ` <20131118150052.GC24408-GFdadSzt00ze9xe1eoZjHA@public.gmane.org> 2013-11-18 19:13 ` Olof Johansson 2013-11-18 19:13 ` Olof Johansson [not found] ` <20131118191336.GB5886-O5ziIzlqnXUVNXGz7ipsyg@public.gmane.org> 2013-11-19 9:12 ` Richard Cochran 2013-11-19 9:12 ` Richard Cochran 2013-11-19 18:48 ` Olof Johansson 2013-11-19 18:48 ` Olof Johansson [not found] ` <20131119184827.GD20967-O5ziIzlqnXUVNXGz7ipsyg@public.gmane.org> 2013-11-20 6:40 ` Richard Cochran 2013-11-20 6:40 ` Richard Cochran 2013-11-21 18:16 ` Grant Likely 2013-11-21 18:16 ` Grant Likely 2013-11-21 19:21 ` Russell King - ARM Linux 2013-11-21 19:21 ` Russell King - ARM Linux [not found] ` < 20131121192136.GA16735@n2100.arm.linux.org.uk> [not found] ` <20131121192136.GA16735-l+eeeJia6m9vn6HldHNs0ANdhmdF6hFW@public.gmane.org> 2013-11-21 20:47 ` Grant Likely 2013-11-21 20:47 ` Grant Likely [not found] ` <20131121204704.E4487C40753-WNowdnHR2B42iJbIjFUEsiwD8/FfD2ys@public.gmane.org> 2013-11-22 11:43 ` Catalin Marinas 2013-11-22 11:43 ` Catalin Marinas [not found] ` <CAHkRjk5MstjD9JFk+co8k89i8geJBmSF6uObhGdmWSe0GJHo8g-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org> 2013-11-22 12:00 ` Pantelis Antoniou 2013-11-22 12:00 ` Pantelis Antoniou [not found] ` <97692EF2-013E-4E4B-BC16-E0915D67EFEC-wVdstyuyKrO8r51toPun2/C9HSW9iNxf@public.gmane.org> 2014-05-05 7:06 ` Alexander Holler 2014-05-05 7:06 ` Alexander Holler [not found] ` <53673866.9000105-SXC+2es9fhnfWeYVQQPykw@public.gmane.org> 2014-05-05 14:41 ` Arnd Bergmann 2014-05-05 14:41 ` Arnd Bergmann 2014-05-05 15:29 ` Alexander Holler 2014-05-05 15:29 ` Alexander Holler [not found] ` <5367AE6B.3010105-SXC+2es9fhnfWeYVQQPykw@public.gmane.org> 2014-05-05 17:29 ` Arnd Bergmann 2014-05-05 17:29 ` Arnd Bergmann 2014-05-06 15:37 ` Grant Likely 2014-05-06 15:37 ` Grant Likely 2014-05-06 15:27 ` Grant Likely 2014-05-06 15:27 ` Grant Likely [not found] ` <20140506152725.E5B90C40959-WNowdnHR2B42iJbIjFUEsiwD8/FfD2ys@public.gmane.org> 2014-05-06 16:32 ` Olof Johansson 2014-05-06 16:32 ` Olof Johansson 2013-11-18 15:28 ` Rob Herring [not found] ` <5289A356.4060004-Zp4isUonpHBD60Wz+7aTrA@public.gmane.org> 2013-11-18 19:09 ` Olof Johansson 2013-11-18 19:09 ` Olof Johansson [not found] ` <20131118190929.GA5886-O5ziIzlqnXUVNXGz7ipsyg@public.gmane.org> 2013-11-18 20:54 ` Jon Masters 2013-11-18 20:54 ` Jon Masters [not found] ` <528A7EA0.9050101-Zp4isUonpHBD60Wz+7aTrA@public.gmane.org> 2013-11-18 21:50 ` Olof Johansson 2013-11-18 21:50 ` Olof Johansson 2013-11-18 21:32 ` Grant Likely 2013-11-18 21:32 ` Grant Likely 2013-11-18 22:47 ` David Goodenough 2013-11-19 12:48 ` Arnd Bergmann 2013-11-19 12:48 ` Arnd Bergmann 2013-11-19 13:34 ` David Goodenough 2013-11-19 16:52 ` Arnd Bergmann 2013-11-21 18:23 ` Grant Likely 2013-11-19 14:33 ` Grant Likely [not found] ` <CAOesGMjKeRb=fFJM0MabDihbEiCGM4EqW9D5i_6-RFxTnpB4Qw-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org> 2013-11-15 20:58 ` Arnd Bergmann 2013-11-15 20:58 ` Arnd Bergmann [not found] ` <201311152158.32644.arnd-r2nGTMty4D4@public.gmane.org> 2013-11-15 21:44 ` Olof Johansson 2013-11-15 21:44 ` Olof Johansson [not found] ` <CAOesGMhkCn2zeJj_ZZAZu_wJya-4evWEqNHpVJEpjxzWHVWY3A-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org> 2013-11-17 17:18 ` Stefano Stabellini 2013-11-17 17:18 ` Stefano Stabellini [not found] ` <alpine.DEB.2.02.1311171705130.4714-7Z66fg9igcxYtxbxJUhB2Dgeux46jI+i@public.gmane.org> 2013-11-17 18:10 ` Arnd Bergmann 2013-11-17 18:10 ` Arnd Bergmann [not found] ` < CAOesGMiYyOcvr3Aqs-p8zc=XDwJM9NZtNxtxrTZssc6F=siZCw@mail.gmail.com> 2013-11-17 22:20 ` Olof Johansson 2013-11-17 22:20 ` Olof Johansson [not found] ` <CAOesGMiYyOcvr3Aqs-p8zc=XDwJM9NZtNxtxrTZssc6F=siZCw-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org> 2013-11-18 8:45 ` Arnd Bergmann 2013-11-18 8:45 ` Arnd Bergmann 2013-11-18 17:33 ` Jon Masters 2013-11-18 17:38 ` Russell King - ARM Linux [not found] ` <528A4F5F.7080104-Zp4isUonpHBD60Wz+7aTrA@public.gmane.org> 2013-11-18 19:21 ` Olof Johansson 2013-11-18 19:21 ` Olof Johansson 2013-11-21 18:26 ` Grant Likely 2013-11-18 15:04 ` Mark Brown 2013-11-18 15:04 ` Mark Brown 2013-11-18 15:10 ` Arnd Bergmann 2013-11-18 15:10 ` Arnd Bergmann [not found] ` < 201311181610.33105.arnd@arndb.de> [not found] ` <201311181610.33105.arnd-r2nGTMty4D4@public.gmane.org> 2013-11-18 21:38 ` Grant Likely 2013-11-18 21:38 ` Grant Likely 2013-11-18 23:25 ` Leif Lindholm 2013-11-18 23:25 ` Leif Lindholm [not found] ` <20131118232536.GF1567-GZEopFhza0F985/tl1ce8aaDwS/vmuI7@public.gmane.org> 2013-11-18 23:29 ` Olof Johansson 2013-11-18 23:29 ` Olof Johansson [not found] ` <CAOesGMh373ZsLzoGHJm+xV3uFVjh2CBSA8SXY4PA+VxL3a5W1w-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org> 2013-11-18 23:34 ` Leif Lindholm 2013-11-18 23:34 ` Leif Lindholm
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.