Re: Request review of device tree documentation
On Sun, 2010-06-13 at 23:13 -0600, Grant Likely wrote: We use that to suck the device-tree, which we flatten, and then re-enter the kernel with the common entry interface. I don't think I want to do the same on ARM. I'd rather have the prom_init stuff in a boot wrapper, or have OFW itself generate the flat representation before booting the kernel. But then it's no longer OF. IE. A compliant OF implementation provides a client interface API :-) This is going to be especially important if Mitch wants to keep OF alive. I suppose it could be done via a wrapper like prom_init, which flattens the tree, and sticks somewhere in a property the address of the OF client interface callback though it's a tad awkward. If well defined, I suppose Mitch might even be able to make his OF natively boot kernels that way but that's of course up to him. I'm trying to constrain the number of things that could go wrong by defining only one way for getting the device tree data into the kernel. I understand, and the flattened method is the most versatile, I'm just pointing out the situation here :-) Right. We don't need to use OFW/RTAS to handle this use case. Definitely not. It will depend on whatever hypervisor interface is implemented in a given environment. Though I do like the idea of passing precompiled bits of .dtb around for hotplug :-) We could make that a standard way of KVM to do things in embedded space. Cheers, Ben. ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: Request review of device tree documentation
Benjamin Herrenschmidt wrote: On Sun, 2010-06-13 at 23:13 -0600, Grant Likely wrote: We use that to suck the device-tree, which we flatten, and then re-enter the kernel with the common entry interface. I don't think I want to do the same on ARM. I'd rather have the prom_init stuff in a boot wrapper, or have OFW itself generate the flat representation before booting the kernel. But then it's no longer OF. IE. A compliant OF implementation provides a client interface API :-) This is going to be especially important if Mitch wants to keep OF alive. I suppose it could be done via a wrapper like prom_init, which flattens the tree, and sticks somewhere in a property the address of the OF client interface callback though it's a tad awkward. If well defined, I suppose Mitch might even be able to make his OF natively boot kernels that way but that's of course up to him. I'm willing to create a flattened tree. I can provide both a client interface and a flattened tree. The kernel probably won't use the client interface to any significant extent. Way back in the misty annals of history, I dreamed of having a common interface between firmware and OSs. That didn't happen. Every OS insisted on defining its own interface and creating a custom bootloader, or in some cases a half dozen of them. I'm trying to constrain the number of things that could go wrong by defining only one way for getting the device tree data into the kernel. I understand, and the flattened method is the most versatile, I'm just pointing out the situation here :-) Right. We don't need to use OFW/RTAS to handle this use case. Definitely not. It will depend on whatever hypervisor interface is implemented in a given environment. Though I do like the idea of passing precompiled bits of .dtb around for hotplug :-) We could make that a standard way of KVM to do things in embedded space. Cheers, Ben. ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: Request review of device tree documentation
Russell King - ARM Linux wrote: On Sun, Jun 13, 2010 at 11:23:45PM -0600, Grant Likely wrote: Or perhaps the MMU and caches can be turned off for the duration of the callback. I don't have the details of ARM MMUs and caches reloaded into my head yet. Maybe next week... We've had these kinds of questions in the past. Doing what you're asking above is not really an option - it requires: 1. disable all IRQs 2. setup 1:1 MMU mappings for code to turn off MMU (requires new page table) 3. disable imprecise exceptions 4. flush caches and TLBS 5. jump to 1:1 mapping area for code to disable MMU 6. disable caches and mmu 7. call function 8. flush caches and TLBs 9. re-enable caches and mmu 10. re-enable imprecise exceptions 11. switch back to original MMU mappings 12. re-enable all IRQs This is fine if you don't care at all about interrupt latency. Unfortunately, most people do care about interrupt latency because that directly affects interactivity and system performance. The called function could not enable interrupts or exceptions - as the CPU vectors are in virtual space, disabling the MMU effectively makes them disappear. Moreover, with the MMU and caches disabled, the CPU performance is extremely poor, so the called function will run slowly. So, disabling the MMU isn't really viable. None of this is a deal-breaker for the kind of debugging tasks that are the primary use case for the callback. Now, if the external code was fully PIC, we could then run it with the MMU enabled. However, this wouldn't really help - the external code could not access any devices without knowledge of how the kernel setup the V:P translations. So you'd need to pass some kind of data structure giving locations of devices to the called code - but then what if the kernel doesn't have the device mapped? ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: Request review of device tree documentation
On Sun, Jun 13, 2010 at 11:23:45PM -0600, Grant Likely wrote: Or perhaps the MMU and caches can be turned off for the duration of the callback. I don't have the details of ARM MMUs and caches reloaded into my head yet. Maybe next week... We've had these kinds of questions in the past. Doing what you're asking above is not really an option - it requires: 1. disable all IRQs 2. setup 1:1 MMU mappings for code to turn off MMU (requires new page table) 3. disable imprecise exceptions 4. flush caches and TLBS 5. jump to 1:1 mapping area for code to disable MMU 6. disable caches and mmu 7. call function 8. flush caches and TLBs 9. re-enable caches and mmu 10. re-enable imprecise exceptions 11. switch back to original MMU mappings 12. re-enable all IRQs This is fine if you don't care at all about interrupt latency. Unfortunately, most people do care about interrupt latency because that directly affects interactivity and system performance. The called function could not enable interrupts or exceptions - as the CPU vectors are in virtual space, disabling the MMU effectively makes them disappear. Moreover, with the MMU and caches disabled, the CPU performance is extremely poor, so the called function will run slowly. So, disabling the MMU isn't really viable. Now, if the external code was fully PIC, we could then run it with the MMU enabled. However, this wouldn't really help - the external code could not access any devices without knowledge of how the kernel setup the V:P translations. So you'd need to pass some kind of data structure giving locations of devices to the called code - but then what if the kernel doesn't have the device mapped? ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: Port Linux to ML510
If any changes w.r.t board then John Linn (XILINX) should be able to provide some pointers. 2010/6/11 kostas padarnitsas kpad...@hotmail.com Hi Srikant, Thanks for your help. I checked the driver versions and they seem ok. The problem is that when I download the linux image the program counter is not set to the address of boot sector of linux kernel, so linux doesn't boot. On the other hand with the ML507 everything works perfectly. Any idea?? Thanks in advance, Kostas -- Date: Thu, 10 Jun 2010 12:34:56 +0530 Subject: Re: Port Linux to ML510 From: skrishna...@gmail.com To: kpad...@hotmail.com CC: linuxppc-dev@lists.ozlabs.org Hi kostas, You need to verify that the driver version of serial and Ethernet (probably X-LLTEMAC) provided in the virtex440.dts matches version used in kernel. Look for compatible = version in the drivers. You can probably use EDK 11.2 as it is the latest from Xilinx. Have you generated your own DTS and Bitstream (download.bit) files ? If not then you should look for suitable download.bit for you kernel. -Srikant 2010/6/10 kostas padarnitsas kpad...@hotmail.com Hello, I am trying to port Linux to PowerPC on the ML510 Xilinx board. I am using EDK 10.1.3 to build the hardware and also device tree generator and the linux kernel from xilinx git. I followed the tutorial from http://xilinx.wikidot.com/powerpc-linux but I have no output. I have attached my .mhs file and the .dts. Any ideas what may cause this problem because I did the same thing with ML507 and it was working perfectly? Thanks in advance, Kostas -- Your E-mail and More On-the-Go. Get Windows Live Hotmail Free. Sign up now. https://signup.live.com/signup.aspx?id=60969 ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev -- The Good You Do, The Best You GET Regards Srikanth Krishnakar ** -- Hotmail: Free, trusted and rich email service. Get it now.https://signup.live.com/signup.aspx?id=60969 -- The Good You Do, The Best You GET Regards Srikanth Krishnakar ** ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: Request review of device tree documentation
On Sun, Jun 13, 2010 at 09:45:50PM -1000, Mitch Bradley wrote: None of this is a deal-breaker for the kind of debugging tasks that are the primary use case for the callback. Would you mind explaining what kind of tasks these callbacks will be used for? ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: Request review of device tree documentation
On Mon, 2010-06-14 at 10:25 +0100, Russell King - ARM Linux wrote: On Sun, Jun 13, 2010 at 09:45:50PM -1000, Mitch Bradley wrote: None of this is a deal-breaker for the kind of debugging tasks that are the primary use case for the callback. Would you mind explaining what kind of tasks these callbacks will be used for? That's one of the thing I'm touching on in my previous reply... (For those who didn't quite follow, the discussion here is about allowing a real Open Firmware implementation on ARM with the feature of leaving OF alive while the OS is up, which is something sparc does but we never supported on ppc). Ideally, if you keep open firmware alive, you can drop into it when the kernel crashes for example, or in some other circumstances. However, there's a lot of room for abuse here and I'm worried that if it becomes widespread, we'll start seeing vendors use that as a way to do some kind of HAL and hide various platform methods in there (clock control, nvram, etc...). Another option Mitch mentioned is to have the f-code interpreter (f-code is OF tokenized forth format) in the kernel, but that doesn't completely solve the problem of providing it with appropriate virtual mappings, arbitrating access to HW resources, etc etc etc OF as a FW/bootloader is great. OF alive along with the OS can be a nice debugging tool under some circumstances but I am a bit more dubious as to whether that's going to work out in practice. But I'd like to -not- see it abused as some kind of HAL. Cheers, Ben. ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: Request review of device tree documentation
On Mon, Jun 14, 2010 at 07:36:10PM +1000, Benjamin Herrenschmidt wrote: However, there's a lot of room for abuse here and I'm worried that if it becomes widespread, we'll start seeing vendors use that as a way to do some kind of HAL and hide various platform methods in there (clock control, nvram, etc...). This is what I'm worried about too. As I said in my first reply in this thread, calling out from the kernel will kill performance due to the time taken to shut down the caches and MMU, which can only be done safely with all exceptions turned off. The only time that it can be seriously considered is if you're calling out to reboot, shutdown or kexec. ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: Request review of device tree documentation
On Sun, Jun 13, 2010 at 11:02:15PM -0600, Grant Likely wrote: [sni] That's sort of a self-fulfilling prophecy. If the OS doesn't trust the firmware, there is no pressure for the firmware to get it right. Firmware will not get it right. Period. There will always be something wrong. It is never right on PCs. It will never be right on the other architectures. Yes, yes, yes. And there is a great deal of empirical evidence to back that assertion. That goes for OSes too, but upgrading an OS isn't as risky as upgrading firmware. That isn't to say that it can't be close, but every firmware feature that the OS depends on is a feature that could force a risky firmware upgrade when the bug in it is discovered. Indeed. In fact, the general rule of thumb is really put as much as possible into the most easily replaced layer of the stack. This is, incidentally, why I've always been dubious about simple firmwares supplying a flattened device tree rather than including the device tree template in the kernel, cuboot style. I'm also convinced that the economics are all wrong for getting it right when talking about firmware. Manufactures don't care about firmware; they care about selling boxes. Customers don't care about firmware, they care about the operating system (well, that's not true either, they care about applications). For manufactures, once it can boot the real operating system, there is little to no incentive to spend any more money on firmware when the money can be better spent on either the next product or the adding features to the operating system of the existing product. In fact, spending money on firmware is actually *more risky* one a product ships, because if a firmware upgrade goes bad, then that means product returned for repair at the factory. A good analysis. The other side of this, is that for an OS, if you rely on the firmware to do X, it will work when the firmware gets it right. If you do X yourself, it will work whether or not the firmware gets it right. This means that if there's even one firmware you have to deal with out there that gets X wrong, you have to do it yourself and then there is little to no incentive to rely on firmware even in the cases where it does get it right. In fact there's a disincentive, because then you have two different code paths to test and maintain. -- David Gibson| I'll have my music baroque, and my code david AT gibson.dropbear.id.au | minimalist, thank you. NOT _the_ _other_ | _way_ _around_! http://www.ozlabs.org/~dgibson ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: Request review of device tree documentation
Russell King - ARM Linux wrote: On Mon, Jun 14, 2010 at 07:36:10PM +1000, Benjamin Herrenschmidt wrote: However, there's a lot of room for abuse here and I'm worried that if it becomes widespread, we'll start seeing vendors use that as a way to do some kind of HAL and hide various platform methods in there (clock control, nvram, etc...). This is what I'm worried about too. As I said in my first reply in this thread, calling out from the kernel will kill performance due to the time taken to shut down the caches and MMU, which can only be done safely with all exceptions turned off. Some applications use ARM (or other embedded-ish CPU) as opposed to x86 PCs, to get predictable and reasonable interrupt latency. x86 PCs sometimes have unpredictable interrupt latency due to those mystery interrupts that the BIOS handles and the OS can't see or block. It's a different cause, but let's not duplicate the symptom where it isn't wanted. Even if opaque firmware callouts were fast, it would be an issue with real-time kernels if they couldn't depend on that as an auditable fact. -- Jamie ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: Request review of device tree documentation
On Mon, Jun 14, 2010 at 8:59 AM, Nicolas Pitre n...@fluxnic.net wrote: On Mon, 14 Jun 2010, David Gibson wrote: On Sun, Jun 13, 2010 at 11:02:15PM -0600, Grant Likely wrote: Indeed. In fact, the general rule of thumb is really put as much as possible into the most easily replaced layer of the stack. This is, incidentally, why I've always been dubious about simple firmwares supplying a flattened device tree rather than including the device tree template in the kernel, cuboot style. The biggest advantage, IMHO, for adding DT to ARM, is actually to decouple the hardware config information and the kernel. If in the end the DT has to be shipped in the kernel then we're losing all this advantage over the current state of things on ARM which still works pretty well otherwise. In the best case, the simple firmware simply has to retrieve the flattened device tree from flash, and pass it to the kernel just like some anonymous blob. And the simple firmware only needs to provide a way for that DT blob to be updatable, like through an upload of a replacement blob that was prepared offline. Just like a ramdisk image or the like. That doesn't need to be fancier than that, and the goal of having the DT data tied to the hardware instead of the kernel is achieved. exactly right. g. ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: Request review of device tree documentation
On Mon, Jun 14, 2010 at 7:51 AM, Nicolas Pitre n...@fluxnic.net wrote: On Sun, 13 Jun 2010, Grant Likely wrote: [cc'ing linux-arm-kernel] On Sat, Jun 12, 2010 at 11:59 PM, Benjamin Herrenschmidt BTW. I notice no ARM list is CCed on this discussion ... maybe we should fix that ? cc'ing linux-arm-kernel in all my replies I'm afraid this won't be enough. I'm seeing a stream of frightening crazy talk involving ARM and some other stuff I still can't make head and tail of. So, before you get a wholesale NAK on everything from me, please I'd suggest you guys rewind a bit now that the ARM list is in CC and just explain what this is all about and why we should feel concerned. Then maybe the ARM savvy people amongst us could suggest more appropriate approaches? The discussion *started* with a request to review this document: http://devicetree.org/Device_Tree_Usage Which is in early draft form (which is why the arm list wasn't initially cc'd. I was soliciting feedback from the current device tree users. A second request for review will go out after rework is done to the document). In one of the reply threads Mitch stated that he is working on an ARM project that will use Open Firmware as the bootloader, and that he'd like the ability to keep OFW available after the kernel is booted which is something currently done on both Sparc and OLPC x86. Mitch will correct me if I'm made any misrepresentations here. Conceptually I'm not opposed to allowing OFW to stay resident providing that it does not impose new requirements on the boot interface (the kernel would still need to be handed the flattened representation of the device tree) and that the code to do so is well contained in the kernel. The devil is of course in the details on how feasible it is to accomplish. ARM machines with Open Firmware are going to be the minority, so I'm not interested in doing anything special or out of the ordinary specifically to support it. g. -- Grant Likely, B.Sc., P.Eng. Secret Lab Technologies Ltd. ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: Request review of device tree documentation
Nicolas Pitre wrote: On Mon, 14 Jun 2010, David Gibson wrote: On Sun, Jun 13, 2010 at 11:02:15PM -0600, Grant Likely wrote: [sni] That's sort of a self-fulfilling prophecy. If the OS doesn't trust the firmware, there is no pressure for the firmware to get it right. Firmware will not get it right. Period. There will always be something wrong. It is never right on PCs. It will never be right on the other architectures. Yes, yes, yes. And there is a great deal of empirical evidence to back that assertion. That goes for OSes too, but upgrading an OS isn't as risky as upgrading firmware. That isn't to say that it can't be close, but every firmware feature that the OS depends on is a feature that could force a risky firmware upgrade when the bug in it is discovered. Indeed. In fact, the general rule of thumb is really put as much as possible into the most easily replaced layer of the stack. This is, incidentally, why I've always been dubious about simple firmwares supplying a flattened device tree rather than including the device tree template in the kernel, cuboot style. The biggest advantage, IMHO, for adding DT to ARM, is actually to decouple the hardware config information and the kernel. If in the end the DT has to be shipped in the kernel then we're losing all this advantage over the current state of things on ARM which still works pretty well otherwise. In the best case, the simple firmware simply has to retrieve the flattened device tree from flash, and pass it to the kernel just like some anonymous blob. And the simple firmware only needs to provide a way for that DT blob to be updatable, like through an upload of a replacement blob that was prepared offline. Just like a ramdisk image or the like. That doesn't need to be fancier than that, and the goal of having the DT data tied to the hardware instead of the kernel is achieved. Imho that puts the DT in a similar category as initrd/initramfs, from the bootloader's point of view. It's another blob whose address is passed to the kernel, just like initrd. Some bootloaders can't update blobs independently for technical reasons, or to be minimal. A device I'm using does kernel updates by updating the whole romfs boot image, which contains the kernel and other auxiliary blobs used for booting (splash screen, early irq handlers etc.) as well as the root filesystem. It is done that way to pack everything together in the small flash, and because the NOR flash eraseblocks are too large relative to the whole flash size to use separate partitions for kernel, boot filesystem and other blobs for booting. Dedicating a 64kiB eraseblock out of 2MB just for a small DT would be quite wasteful. Dedicating two to make it powerfail-safe would be even worse. So requiring that a bootloader can update the DT _independently_ of everything else is a bit much for some devices. But requiring that it's generally treated like other separate blob, i.e. in a similar way to initrd, and the kernel image itself, seems not unreasonable. Like initrd, some people will find they need to compile it in to the kernel image to fit some bootloader they can't change, or daren't risk changing in already rolled out devices that they want to update to a DT-using kernel. I won't be surprised if I see some vendor SDK containing a kernel patch to early-parse the bootloader-supplied ROMFS image to extract devicetree.bin.gz at some point :-) We can discourage that sort of thing (but not prevent it) by ensuring the open source bootloaders support a DT blob as easily as possible. -- Jamie ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: Request review of device tree documentation
In message: 20100614124438.gf9...@yookeroo David Gibson da...@gibson.dropbear.id.au writes: : On Sun, Jun 13, 2010 at 11:02:15PM -0600, Grant Likely wrote: : [sni] : That's sort of a self-fulfilling prophecy. If the OS doesn't trust the : firmware, there is no pressure for the firmware to get it right. : : Firmware will not get it right. Period. There will always be : something wrong. It is never right on PCs. It will never be right on : the other architectures. : : Yes, yes, yes. And there is a great deal of empirical evidence to : back that assertion. While I'll be the first to agree with that, there's also a great deal of empirical evidence to suggest that they get it right enough often enough. Otherwise nothing would boot and everything would be broken. : That goes for OSes too, but upgrading an OS : isn't as risky as upgrading firmware. That isn't to say that it can't : be close, but every firmware feature that the OS depends on is a : feature that could force a risky firmware upgrade when the bug in it : is discovered. : : Indeed. In fact, the general rule of thumb is really put as much as : possible into the most easily replaced layer of the stack. This is, : incidentally, why I've always been dubious about simple firmwares : supplying a flattened device tree rather than including the device : tree template in the kernel, cuboot style. The down side of cuboot style is that your kernel will boot on fewer boards. The firmware enables more generic kernels. : I'm also convinced that the economics are all wrong for getting it : right when talking about firmware. Manufactures don't care about : firmware; they care about selling boxes. Customers don't care about : firmware, they care about the operating system (well, that's not true : either, they care about applications). For manufactures, once it can : boot the real operating system, there is little to no incentive to : spend any more money on firmware when the money can be better spent on : either the next product or the adding features to the operating system : of the existing product. In fact, spending money on firmware is : actually *more risky* one a product ships, because if a firmware : upgrade goes bad, then that means product returned for repair at the : factory. : : A good analysis. The other side of this, is that for an OS, if you : rely on the firmware to do X, it will work when the firmware gets it : right. If you do X yourself, it will work whether or not the firmware : gets it right. This means that if there's even one firmware you have : to deal with out there that gets X wrong, you have to do it yourself : and then there is little to no incentive to rely on firmware even in : the cases where it does get it right. In fact there's a disincentive, : because then you have two different code paths to test and maintain. Two comments: (1) You are assuming that you are in a position to do 'X' right which isn't always possible (in this case, it is impossible to do generically, but can be done specifically for a given board if you know enough about the board) and (2) In this case, the wrapped fdt path uses the same path as the get the fdt from the firmware. Warner ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: Request review of device tree documentation
On Mon, Jun 14, 2010 at 9:58 AM, Nicolas Pitre n...@fluxnic.net wrote: On Mon, 14 Jun 2010, Grant Likely wrote: The discussion *started* with a request to review this document: http://devicetree.org/Device_Tree_Usage Which is in early draft form (which is why the arm list wasn't initially cc'd. I was soliciting feedback from the current device tree users. A second request for review will go out after rework is done to the document). I'm therefore assuming I can safely ignore it for now then. Correct. I'll let Mitch answer the rest of your questions. g. ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: Request review of device tree documentation
On Mon, 14 Jun 2010, Grant Likely wrote: The discussion *started* with a request to review this document: http://devicetree.org/Device_Tree_Usage Which is in early draft form (which is why the arm list wasn't initially cc'd. I was soliciting feedback from the current device tree users. A second request for review will go out after rework is done to the document). I'm therefore assuming I can safely ignore it for now then. In one of the reply threads Mitch stated that he is working on an ARM project that will use Open Firmware as the bootloader, and that he'd like the ability to keep OFW available after the kernel is booted which is something currently done on both Sparc and OLPC x86. Mitch will correct me if I'm made any misrepresentations here. OK... but what does keep OFW available mean? And what for? Conceptually I'm not opposed to allowing OFW to stay resident providing that it does not impose new requirements on the boot interface (the kernel would still need to be handed the flattened representation of the device tree) and that the code to do so is well contained in the kernel. The devil is of course in the details on how feasible it is to accomplish. Well, you'd need to tell the kernel about what memory area not to touch (given that memory is not in some area the kernel will touch anyway when it is in its early boot stage and still not smart enough to avoid it). Then you'll need special code to perform those steps RMK already mentioned. This is a bit like the low-level code for suspend/resume support is doing. This is of course if I'm still guessing right about the whole purpose of this. ARM machines with Open Firmware are going to be the minority, so I'm not interested in doing anything special or out of the ordinary specifically to support it. This certainly doesn't have to involve the core kernel. A special module may even be sufficient to keep the complexity localized. Just like low-level suspend/resume code is per SOC already anyway. But again, what for? Nicolas ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: Request review of device tree documentation
On Mon, 14 Jun 2010, Jamie Lokier wrote: Nicolas Pitre wrote: On Mon, 14 Jun 2010, David Gibson wrote: On Sun, Jun 13, 2010 at 11:02:15PM -0600, Grant Likely wrote: [sni] That's sort of a self-fulfilling prophecy. If the OS doesn't trust the firmware, there is no pressure for the firmware to get it right. Firmware will not get it right. Period. There will always be something wrong. It is never right on PCs. It will never be right on the other architectures. Yes, yes, yes. And there is a great deal of empirical evidence to back that assertion. That goes for OSes too, but upgrading an OS isn't as risky as upgrading firmware. That isn't to say that it can't be close, but every firmware feature that the OS depends on is a feature that could force a risky firmware upgrade when the bug in it is discovered. Indeed. In fact, the general rule of thumb is really put as much as possible into the most easily replaced layer of the stack. This is, incidentally, why I've always been dubious about simple firmwares supplying a flattened device tree rather than including the device tree template in the kernel, cuboot style. The biggest advantage, IMHO, for adding DT to ARM, is actually to decouple the hardware config information and the kernel. If in the end the DT has to be shipped in the kernel then we're losing all this advantage over the current state of things on ARM which still works pretty well otherwise. In the best case, the simple firmware simply has to retrieve the flattened device tree from flash, and pass it to the kernel just like some anonymous blob. And the simple firmware only needs to provide a way for that DT blob to be updatable, like through an upload of a replacement blob that was prepared offline. Just like a ramdisk image or the like. That doesn't need to be fancier than that, and the goal of having the DT data tied to the hardware instead of the kernel is achieved. Imho that puts the DT in a similar category as initrd/initramfs, from the bootloader's point of view. It's another blob whose address is passed to the kernel, just like initrd. Exact. Some bootloaders can't update blobs independently for technical reasons, or to be minimal. A device I'm using does kernel updates by updating the whole romfs boot image, which contains the kernel and other auxiliary blobs used for booting (splash screen, early irq handlers etc.) as well as the root filesystem. It is done that way to pack everything together in the small flash, and because the NOR flash eraseblocks are too large relative to the whole flash size to use separate partitions for kernel, boot filesystem and other blobs for booting. If you already have to update everything at once already anyway, then the DT blob just has to be in that update. No need to do otherwise if you can't do better than that for the kernel alone. Dedicating a 64kiB eraseblock out of 2MB just for a small DT would be quite wasteful. Dedicating two to make it powerfail-safe would be even worse. I hardly see how you can be power fail safe with your update-everything-at-once condition above anyway. Furthermore, if the DT is updated by the bootloader, then that means you're not running a live system at that point. If power fails during the DT update, then you simply have to re-update it when power is back to allow a successful boot of the kernel afterwards. So requiring that a bootloader can update the DT _independently_ of everything else is a bit much for some devices. In my opinion, this use case you're illustrating above simply could continue to _not_ use DT at all. If your NOR flash is so small that you cannot spare some extra erase blocks, then this is a deeply embedded profile the current DT-on-ARM push is not really meant for. You would be much better with a minimally configured kernel with all the hardware info statically compiled into the kernel and get away without all the DT parsing code altogether, like you're already doing today. While I think DT for ARM has advantages, I don't see us dropping the legacy ARM methods anytime soon, especially for existing or extremely constrained targets. Nicolas ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: Request review of device tree documentation
On Mon, Jun 14, 2010 at 10:02 AM, Jamie Lokier ja...@shareable.org wrote: Nicolas Pitre wrote: On Mon, 14 Jun 2010, David Gibson wrote: On Sun, Jun 13, 2010 at 11:02:15PM -0600, Grant Likely wrote: [sni] That's sort of a self-fulfilling prophecy. If the OS doesn't trust the firmware, there is no pressure for the firmware to get it right. Firmware will not get it right. Period. There will always be something wrong. It is never right on PCs. It will never be right on the other architectures. Yes, yes, yes. And there is a great deal of empirical evidence to back that assertion. That goes for OSes too, but upgrading an OS isn't as risky as upgrading firmware. That isn't to say that it can't be close, but every firmware feature that the OS depends on is a feature that could force a risky firmware upgrade when the bug in it is discovered. Indeed. In fact, the general rule of thumb is really put as much as possible into the most easily replaced layer of the stack. This is, incidentally, why I've always been dubious about simple firmwares supplying a flattened device tree rather than including the device tree template in the kernel, cuboot style. The biggest advantage, IMHO, for adding DT to ARM, is actually to decouple the hardware config information and the kernel. If in the end the DT has to be shipped in the kernel then we're losing all this advantage over the current state of things on ARM which still works pretty well otherwise. In the best case, the simple firmware simply has to retrieve the flattened device tree from flash, and pass it to the kernel just like some anonymous blob. And the simple firmware only needs to provide a way for that DT blob to be updatable, like through an upload of a replacement blob that was prepared offline. Just like a ramdisk image or the like. That doesn't need to be fancier than that, and the goal of having the DT data tied to the hardware instead of the kernel is achieved. Imho that puts the DT in a similar category as initrd/initramfs, from the bootloader's point of view. It's another blob whose address is passed to the kernel, just like initrd. Some bootloaders can't update blobs independently for technical reasons, or to be minimal. A device I'm using does kernel updates by updating the whole romfs boot image, which contains the kernel and other auxiliary blobs used for booting (splash screen, early irq handlers etc.) as well as the root filesystem. It is done that way to pack everything together in the small flash, and because the NOR flash eraseblocks are too large relative to the whole flash size to use separate partitions for kernel, boot filesystem and other blobs for booting. This is totally fine. I've got no problem with a specific firmware requiring everything (kernel,dt,rootfs) packed into a single image file. Packing the image can be done at OS install time (instead of prebuilding it) if the system builder want to retain the independent hardware configuration aspects of using the device tree. Dedicating a 64kiB eraseblock out of 2MB just for a small DT would be quite wasteful. Dedicating two to make it powerfail-safe would be even worse. So requiring that a bootloader can update the DT _independently_ of everything else is a bit much for some devices. Independent update of the DT is a useful feature, but it is certainly not a hard requirement. It's a far more likely use-case if the kernel and DT is stored on a filesystem instead of bare NOR flash. But requiring that it's generally treated like other separate blob, i.e. in a similar way to initrd, and the kernel image itself, seems not unreasonable. Like initrd, some people will find they need to compile it in to the kernel image to fit some bootloader they can't change, or daren't risk changing in already rolled out devices that they want to update to a DT-using kernel. Yes, I fully expect that. Fortunately the situation is better than it was with powerpc. Since the machine id is being retained, a DT-enabled kernel can continue to support non-DT systems. There will not be a flag day to cut everything over to a new boot interface. g. -- Grant Likely, B.Sc., P.Eng. Secret Lab Technologies Ltd. ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: Request review of device tree documentation
On Mon, Jun 14, 2010 at 10:23 AM, Nicolas Pitre n...@fluxnic.net wrote: On Mon, 14 Jun 2010, Jamie Lokier wrote: So requiring that a bootloader can update the DT _independently_ of everything else is a bit much for some devices. In my opinion, this use case you're illustrating above simply could continue to _not_ use DT at all. If your NOR flash is so small that you cannot spare some extra erase blocks, then this is a deeply embedded profile the current DT-on-ARM push is not really meant for. You would be much better with a minimally configured kernel with all the hardware info statically compiled into the kernel and get away without all the DT parsing code altogether, like you're already doing today. While I think DT for ARM has advantages, I don't see us dropping the legacy ARM methods anytime soon, especially for existing or extremely constrained targets. I completely agree. g. ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: Request review of device tree documentation
Grant Likely wrote: Like initrd, some people will find they need to compile it in to the kernel image to fit some bootloader they can't change, or daren't risk changing in already rolled out devices that they want to update to a DT-using kernel. Yes, I fully expect that. Fortunately the situation is better than it was with powerpc. Since the machine id is being retained, a DT-enabled kernel can continue to support non-DT systems. There will not be a flag day to cut everything over to a new boot interface. That's excellent, thank you. I was a bit unsure about how that was going. -- Jamie ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: Request review of device tree documentation
I shall try to clarify this discussion. There are actually two different things being discussed. The first is, I hope, not too controversial. The second is so controversial as to be a hopeless cause. First, the primary use case for keeping OFW alive is for debugging purposes. OFW remains resident in memory so that, if the OS is set to allow it (not the default), a hot-key freezes the OS and enters OFW, where a human can inspect the state of devices and OS data structures. A high skill level is required, so it's okay if some fiddling is necessary to find or establish virtual addresses or do similar magic . In my career of working closely with hardware manufacturers, I and others have found this feature to be extremely helpful. Often it has resulted in the resolution of difficult problems that were blocking the ability to ship the product - problems that resisted other kernel debugging techniques. The second topic is the hypothetical use of OFW as a HAL. That will not happen for several reasons. The opposition to the idea is widespread and deeply held, and there are good arguments to support that opposition. Furthermore, the economic conditions necessary for the creation of such a HAL do not exist in the ARM world, nor indeed in the Linux world in general. (The necessary condition is the ability for one company to impose a substantial change by fiat - essentially a monopoly position.) Shall we agree, then, that any further discussion of the HAL issue is just for fun, and that nobody needs to feel threatened that it would actually happen? The potential for vendors breaking out of the debugging use case and turning it into a HAL is miniscule, because a) The callback is disabled by default b) The technical challenges of the callback interface limit its applicability to specific wizard user scenarios c) OFW is unlikely to achieve sufficient market penetration for the HAL thing to be worth doing ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: Request review of device tree documentation
On Mon, 14 Jun 2010, Mitch Bradley wrote: First, the primary use case for keeping OFW alive is for debugging purposes. OFW remains resident in memory so that, if the OS is set to allow it (not the default), a hot-key freezes the OS and enters OFW, where a human can inspect the state of devices and OS data structures. A high skill level is required, so it's okay if some fiddling is necessary to find or establish virtual addresses or do similar magic . Why would you impose such pain on yourself in order to try to make OFW a viable debugging tool on ARM for live kernels, while you can achieve the same and more much less intrusively and so much more safely with a JTAG based debugger? If the cost of a JTAG solution is a concern, you can order USB based JTAG dongles on the net for less than $30 and use them with OpenOCD[1]. Otherwise, what's wrong with already supported kgdb, or even kdb? [1] http://openocd.berlios.de/web/ Nicolas ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: Request review of device tree documentation
Nicolas Pitre wrote: On Mon, 14 Jun 2010, Mitch Bradley wrote: First, the primary use case for keeping OFW alive is for debugging purposes. OFW remains resident in memory so that, if the OS is set to allow it (not the default), a hot-key freezes the OS and enters OFW, where a human can inspect the state of devices and OS data structures. A high skill level is required, so it's okay if some fiddling is necessary to find or establish virtual addresses or do similar magic . Why would you impose such pain on yourself in order to try to make OFW a viable debugging tool on ARM for live kernels, while you can achieve the same and more much less intrusively and so much more safely with a JTAG based debugger? If the cost of a JTAG solution is a concern, you can order USB based JTAG dongles on the net for less than $30 and use them with OpenOCD[1]. If OFW is present on the machine, when a customer reports a problem I can tell them to do x and y and z and tell me what they see. In this manner, I have often solved difficult problems in minutes or hours. Arranging for a JTAG dongle to appear at the customer site, then getting it set up and the necessary software installed and configured on a suitable host system, typically requires several days at best, plus potentially a lot of fiddling depending on what sort of host system the customer happens to have. The phrase impose such pain on yourself presupposes that the technical challenges are much harder than they actually are. In fact, most of the pain comes from dealing with the yuck, why would you ever want to do that argument. I first experienced that argument in 1982, when Tom Lyon - Sun's Unix driver expert at the time - threatened to scratch my disk if I ported Forth to the Sun 1 machine. Tom later recanted and said that he was very glad that I had done so, after I used it to solve several stop-ship problems that came close to killing the company. Otherwise, what's wrong with already supported kgdb, or even kdb? [1] http://openocd.berlios.de/web/ Requires setup. The power of it's just there, flip a switch to turn it on has to be experienced in the heat of battle to be appreciated. The other difference is that conventional debuggers focus on the problem of inspecting and controlling the execution of preexisting programs, instead of on the problem of constructing quick tests to test hypotheses. While it is possible to use them to poke around, it quickly becomes cumbersome if you need to do anything more complicated than just looking. OFW's built-in programming language is particularly well suited for making little test loops on-the-fly. Also, OFW has drivers for most of all of the system's hardware, and those drivers are independently developed from the Linux drivers. That often serves as a valuable second opinion to help discover the root cause of hardware misbehavior. Nicolas ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: Request review of device tree documentation
On Mon, 14 Jun 2010, Mitch Bradley wrote: Nicolas Pitre wrote: On Mon, 14 Jun 2010, Mitch Bradley wrote: First, the primary use case for keeping OFW alive is for debugging purposes. OFW remains resident in memory so that, if the OS is set to allow it (not the default), a hot-key freezes the OS and enters OFW, where a human can inspect the state of devices and OS data structures. A high skill level is required, so it's okay if some fiddling is necessary to find or establish virtual addresses or do similar magic . Why would you impose such pain on yourself in order to try to make OFW a viable debugging tool on ARM for live kernels, while you can achieve the same and more much less intrusively and so much more safely with a JTAG based debugger? If the cost of a JTAG solution is a concern, you can order USB based JTAG dongles on the net for less than $30 and use them with OpenOCD[1]. If OFW is present on the machine, when a customer reports a problem I can tell them to do x and y and z and tell me what they see. In this manner, I have often solved difficult problems in minutes or hours. That's assuming OFW is still intact somewhere and unaffected by said problem. Arranging for a JTAG dongle to appear at the customer site, then getting it set up and the necessary software installed and configured on a suitable host system, typically requires several days at best, plus potentially a lot of fiddling depending on what sort of host system the customer happens to have. Well, if I may use the SheevaPlug as an example, the actual FT2232 chip currently used in most of those USB-JTAG dongle was provided directly on the board. So you have this standard mini-B type USB connector on the side of the device from which you get both a serial console and a JTAG interface. All you need is a standard USB cable, just like the one you get with a MP3 player or a digital camera, so there are plenty of those around. Software wise, people have provided self contained packages containing OpenOCD, the necessary recovery binary images, and a script to bind it all into a nice debricking utility for when you blow your flash content away. Oh and OpenOCD runs on Linux, Mac OS as well as Windows. So there are ways to customize things and make this really straight forward to users. But in the SheevaPlug case this ease of use was also planned further by integrating easy JTAG access into the hardware design. And a couple other ARM boards out there are doing the same thing too. The phrase impose such pain on yourself presupposes that the technical challenges are much harder than they actually are. In fact, most of the pain comes from dealing with the yuck, why would you ever want to do that argument. I first experienced that argument in 1982, when Tom Lyon - Sun's Unix driver expert at the time - threatened to scratch my disk if I ported Forth to the Sun 1 machine. Tom later recanted and said that he was very glad that I had done so, after I used it to solve several stop-ship problems that came close to killing the company. Sure. Pioneering solutions to save your life is always worth the pain. But in this case some solutions were already developed and in use today. So all you'll be doing here is sort of reinventing the wheel with the only major benefit that it is a wheel that you're familiar with, while the rest of the crowd is using another one already. Otherwise, what's wrong with already supported kgdb, or even kdb? [1] http://openocd.berlios.de/web/ Requires setup. The power of it's just there, flip a switch to turn it on has to be experienced in the heat of battle to be appreciated. Sure... when 1) the switch does still work even after damage was incurred, and 2) you have someone on-site with the appropriate knowledge for it. The other difference is that conventional debuggers focus on the problem of inspecting and controlling the execution of preexisting programs, instead of on the problem of constructing quick tests to test hypotheses. While it is possible to use them to poke around, it quickly becomes cumbersome if you need to do anything more complicated than just looking. OFW's built-in programming language is particularly well suited for making little test loops on-the-fly. Just for completeness, OpenOCD is not itself a debugger. It is a mean to provide a GDB remote debugging interface amongst other things. It has its own interface that can be used autonomously, and if I'm not mistaken there is even a web interface to it. And OpenOCD can be scripted (it contains a TCL interpreter). So you can do all sorts of things with it. The most popular usage is to reflash a hosed system. I even saw someone use a modified OpenOCD version to wait until the CPU entered a particular function, have it single-stepped, and get statistics on cache hits and misses on a
Re: Request review of device tree documentation
On Sun, Jun 13, 2010 at 11:36:57PM -0600, Grant Likely wrote: On Sun, Jun 13, 2010 at 2:29 AM, Benjamin Herrenschmidt b...@kernel.crashing.org wrote: On Sat, 2010-06-12 at 20:45 -1000, Mitch Bradley wrote: Either fought or embraced. To the extent that it is possible to focus solely on Linux and ARM, one could image doing a good HAL. That will come with a huge amount of comunity resistance sadly, but I can imagine distros liking it. In general, I much prefer having all the necessary native drivers in the kernel, and the device-tree to provide the right representation, and avoid trying to abstract methods via a HAL. It's the Linux philosophy as much as possible (even when defeated by ACPI). But if we're going to be forced by vendors into HALs, we can also make sure that whatever they come up with is half reasonable :-) I think there is more to be concerned about regarding binary blobs than HALs. Many of the new SoCs require closed binaries to use all the hardware right now (graphics cores in particular). Board vendors seem to be taking the plunge and modifying the kernel rather than trying to create a HAL for driving board specific features. In my view HALs are a bad idea, they constrain you to one calling method and make it difficult to evolve support in the kernel. I belive it is part of the reason that we've always tried to avoid a standardised kernel driver interface. -- Ben Q: What's a light-year? A: One-third less calories than a regular year. ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: Request review of device tree documentation
On Mon, Jun 14, 2010 at 03:40:19PM -0400, Nicolas Pitre wrote: On Mon, 14 Jun 2010, Mitch Bradley wrote: Arranging for a JTAG dongle to appear at the customer site, then getting it set up and the necessary software installed and configured on a suitable host system, typically requires several days at best, plus potentially a lot of fiddling depending on what sort of host system the customer happens to have. Well, if I may use the SheevaPlug as an example, the actual FT2232 chip currently used in most of those USB-JTAG dongle was provided directly on the board. So you have this standard mini-B type USB connector on the side of the device from which you get both a serial console and a JTAG interface. All you need is a standard USB cable, just like the one you get with a MP3 player or a digital camera, so there are plenty of those around. The other thing here is of course that if JTAG is a problem serial or other console access is likely to also be a problem - it's likely to not be physically present and at least as painful to set up as JTAG. ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH 0/2 v2] mpc5200 ac97 gpio reset
These patches reimplement the reset fuction in the ac97 to use gpio pins instead of using the mpc5200 ac97 reset functionality in the psc. This avoids a problem in which attached ac97 devices go into test mode appear unresponsive. These patches were tested on a pcm030 baseboard and on custom hardware with a wm9715 audio codec/touchscreen controller. Eric Millbrandt --- changes since v1 - Refactored to manipulate port_config and gpio pins internally instead of exporting an API. - Amended commit message with comments from Mark Brown - Refactored to move the port_config manipulation to platform code. - Remove the gpio pins from the device-tree Eric Millbrandt (2): powerpc/5200: add mpc5200_psc_ac97_gpio_reset sound/soc: mpc5200_psc_ac97: Use gpio pins for cold reset arch/powerpc/include/asm/mpc52xx.h |1 + arch/powerpc/platforms/52xx/mpc52xx_common.c | 103 ++ sound/soc/fsl/mpc5200_psc_ac97.c | 33 +++- 3 files changed, 133 insertions(+), 4 deletions(-) -DISCLAIMER: an automatically appended disclaimer may follow. By posting- -to a public e-mail mailing list I hereby grant permission to distribute- -and copy this message.- This e-mail and the information, including any attachments, it contains are intended to be a confidential communication only to the person or entity to whom it is addressed and may contain information that is privileged. If the reader of this message is not the intended recipient, you are hereby notified that any dissemination, distribution or copying of this communication is strictly prohibited. If you have received this communication in error, please immediately notify the sender and destroy the original message. Thank you. Please consider the environment before printing this email. ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH 1/2 v2] powerpc/5200: add mpc5200_psc_ac97_gpio_reset
Work around a silicon bug in the ac97 reset functionality of the
mpc5200(b). The implementation of the ac97 cold reset is flawed.
If the sync and output lines are high when reset is asserted the
attached ac97 device may go into test mode. Avoid this by
reconfiguring the psc to gpio mode and generating the reset manually.
From MPC5200B User's Manual:
Some AC97 devices goes to a test mode, if the Sync line is high
during the Res line is low (reset phase). To avoid this behavior the
Sync line must be also forced to zero during the reset phase. To do
that, the pin muxing should switch to GPIO mode and the GPIO control
register should be used to control the output lines.
Signed-off-by: Eric Millbrandt emillbra...@dekaresearch.com
---
changes since v1
- Refactored to manipulate port_config and gpio pins internally instead of
exporting an API.
arch/powerpc/include/asm/mpc52xx.h |1 +
arch/powerpc/platforms/52xx/mpc52xx_common.c | 103 ++
2 files changed, 104 insertions(+), 0 deletions(-)
diff --git a/arch/powerpc/include/asm/mpc52xx.h
b/arch/powerpc/include/asm/mpc52xx.h
index b664ce7..1f41382 100644
--- a/arch/powerpc/include/asm/mpc52xx.h
+++ b/arch/powerpc/include/asm/mpc52xx.h
@@ -271,6 +271,7 @@ struct mpc52xx_intr {
/* mpc52xx_common.c */
extern void mpc5200_setup_xlb_arbiter(void);
extern void mpc52xx_declare_of_platform_devices(void);
+extern int mpc5200_psc_ac97_gpio_reset(int psc_number);
extern void mpc52xx_map_common_devices(void);
extern int mpc52xx_set_psc_clkdiv(int psc_id, int clkdiv);
extern unsigned int mpc52xx_get_xtal_freq(struct device_node *node);
diff --git a/arch/powerpc/platforms/52xx/mpc52xx_common.c
b/arch/powerpc/platforms/52xx/mpc52xx_common.c
index a46bad0..a9866fa 100644
--- a/arch/powerpc/platforms/52xx/mpc52xx_common.c
+++ b/arch/powerpc/platforms/52xx/mpc52xx_common.c
@@ -12,9 +12,11 @@
#undef DEBUG
+#include linux/gpio.h
#include linux/kernel.h
#include linux/spinlock.h
#include linux/of_platform.h
+#include linux/of_gpio.h
#include asm/io.h
#include asm/prom.h
#include asm/mpc52xx.h
@@ -37,6 +39,11 @@ static struct of_device_id mpc52xx_bus_ids[] __initdata = {
{}
};
+static struct of_device_id mpc52xx_gpio_simple[] = {
+ { .compatible = fsl,mpc5200-gpio, },
+ {}
+};
+
/*
* This variable is mapped in mpc52xx_map_wdt() and used in mpc52xx_restart().
* Permanent mapping is required because mpc52xx_restart() can be called
@@ -82,6 +89,13 @@ mpc5200_setup_xlb_arbiter(void)
iounmap(xlb);
}
+/*
+ * This variable is mapped in mpc52xx_write_port_config() and
+ * mpc52xx_read_port_config().
+ */
+DEFINE_SPINLOCK(mpc52xx_gpio_lock);
+static u32 __iomem *port_config;
+
/**
* mpc52xx_declare_of_platform_devices: register internal devices and children
* of the localplus bus to the of_platform
@@ -117,6 +131,7 @@ void __init
mpc52xx_map_common_devices(void)
{
struct device_node *np;
+ const u32 *regaddr;
/* mpc52xx_wdt is mapped here and used in mpc52xx_restart,
* possibly from a interrupt context. wdt is only implement
@@ -135,6 +150,13 @@ mpc52xx_map_common_devices(void)
np = of_find_matching_node(NULL, mpc52xx_cdm_ids);
mpc52xx_cdm = of_iomap(np, 0);
of_node_put(np);
+
+ /* port_config register */
+ np = of_find_matching_node(NULL, mpc52xx_gpio_simple);
+ regaddr = of_get_address(np, 0, NULL, NULL);
+ port_config = ioremap((u32) of_translate_address(np, regaddr), 0x4);
+
+ of_node_put(np);
}
/**
@@ -233,3 +255,84 @@ mpc52xx_restart(char *cmd)
while (1);
}
+
+#define PSC1_RESET 254
+#define PSC1_SYNC 244
+#define PSC1_SDATA_OUT 246
+#define PSC2_RESET 253
+#define PSC2_SYNC 240
+#define PSC2_SDATA_OUT 242
+#define MPC52xx_GPIO_PSC1_MASK 0x7
+#define MPC52xx_GPIO_PSC2_MASK (0x74)
+
+/**
+ * mpc5200_psc_ac97_gpio_reset: Use gpio pins to reset the ac97 bus
+ *
+ * @psc: psc number to reset (only psc 1 and 2 support ac97)
+ */
+int mpc5200_psc_ac97_gpio_reset(int psc_number)
+{
+ unsigned long flags;
+ u32 gpio;
+ u32 mux;
+ int out;
+ int reset;
+ int sync;
+
+ if (!port_config)
+ return -ENODEV;
+
+ switch (psc_number) {
+ case 0:
+ reset = PSC1_RESET; /* AC97_1_RES */
+ sync= PSC1_SYNC;/* AC97_1_SYNC */
+ out = PSC1_SDATA_OUT; /* AC97_1_SDATA_OUT */
+ gpio= MPC52xx_GPIO_PSC1_MASK;
+ break;
+ case 1:
+ reset = PSC2_RESET; /* AC97_2_RES */
+ sync= PSC2_SYNC;/* AC97_2_SYNC */
+ out = PSC2_SDATA_OUT; /* AC97_2_SDATA_OUT */
+ gpio= MPC52xx_GPIO_PSC2_MASK;
+ break;
+ default:
+ printk(KERN_ERR __FILE__ :
+
[PATCH 2/2 v3] sound/soc: mpc5200_psc_ac97: Use gpio pins for cold reset
Call the gpio reset platform function instead of using the flawed
ac97 functionality of the MPC5200(b)
From MPC5200B User's Manual:
Some AC97 devices goes to a test mode, if the Sync line is high
during the Res line is low (reset phase). To avoid this behavior the
Sync line must be also forced to zero during the reset phase. To do
that, the pin muxing should switch to GPIO mode and the GPIO control
register should be used to control the output lines.
Signed-off-by: Eric Millbrandt emillbra...@dekaresearch.com
---
changes since v1
- Amended with comments from Mark Brown
- Fall back to the original reset implementation if no gpio pins are defined
in the device tree
changes since v2
- Refactored to move the port_config manipulation to platform code.
- Remove the gpio pins from the device-tree
sound/soc/fsl/mpc5200_psc_ac97.c | 33 +
1 files changed, 29 insertions(+), 4 deletions(-)
diff --git a/sound/soc/fsl/mpc5200_psc_ac97.c b/sound/soc/fsl/mpc5200_psc_ac97.c
index e2ee220..380a127 100644
--- a/sound/soc/fsl/mpc5200_psc_ac97.c
+++ b/sound/soc/fsl/mpc5200_psc_ac97.c
@@ -20,6 +20,7 @@
#include asm/time.h
#include asm/delay.h
+#include asm/mpc52xx.h
#include asm/mpc52xx_psc.h
#include mpc5200_dma.h
@@ -100,19 +101,43 @@ static void psc_ac97_warm_reset(struct snd_ac97 *ac97)
{
struct mpc52xx_psc __iomem *regs = psc_dma-psc_regs;
+ mutex_lock(psc_dma-mutex);
+
out_be32(regs-sicr, psc_dma-sicr | MPC52xx_PSC_SICR_AWR);
udelay(3);
out_be32(regs-sicr, psc_dma-sicr);
+
+ mutex_unlock(psc_dma-mutex);
}
+#define MPC52xx_PSC_SICR_ACRB (0x8 24)
static void psc_ac97_cold_reset(struct snd_ac97 *ac97)
{
struct mpc52xx_psc __iomem *regs = psc_dma-psc_regs;
- /* Do a cold reset */
- out_8(regs-op1, MPC52xx_PSC_OP_RES);
- udelay(10);
- out_8(regs-op0, MPC52xx_PSC_OP_RES);
+ mutex_lock(psc_dma-mutex);
+
+ switch (psc_dma-id) {
+ case 0:
+ case 1:
+ mpc5200_psc_ac97_gpio_reset(psc_dma-id);
+ dev_info(psc_dma-dev, cold reset\n);
+
+ /* Notify the PSC that a reset has occurred */
+ out_be32(regs-sicr, psc_dma-sicr | MPC52xx_PSC_SICR_ACRB);
+
+ /* Re-enable RX and TX */
+ out_8(regs-command, MPC52xx_PSC_TX_ENABLE |
MPC52xx_PSC_RX_ENABLE);
+
+ break;
+ default:
+ dev_err(psc_dma-dev,
+ Unable to determine PSC, no cold-reset will be
+ performed\n);
+ }
+
+ mutex_unlock(psc_dma-mutex);
+
msleep(1);
psc_ac97_warm_reset(ac97);
}
--
-DISCLAIMER: an automatically appended disclaimer may follow. By posting-
-to a public e-mail mailing list I hereby grant permission to distribute-
-and copy this message.-
1.6.3.1
This e-mail and the information, including any attachments, it contains are
intended to be a confidential communication only to the person or entity to
whom it is addressed and may contain information that is privileged. If the
reader of this message is not the intended recipient, you are hereby notified
that any dissemination, distribution or copying of this communication is
strictly prohibited. If you have received this communication in error, please
immediately notify the sender and destroy the original message.
Thank you.
Please consider the environment before printing this email.
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH 0/2 v2] mpc5200 ac97 gpio reset
On Mon, Jun 14, 2010 at 3:55 PM, Eric Millbrandt emillbra...@dekaresearch.com wrote: These patches reimplement the reset fuction in the ac97 to use gpio pins instead of using the mpc5200 ac97 reset functionality in the psc. This avoids a problem in which attached ac97 devices go into test mode appear unresponsive. These patches were tested on a pcm030 baseboard and on custom hardware with a wm9715 audio codec/touchscreen controller. Eric Millbrandt --- changes since v1 - Refactored to manipulate port_config and gpio pins internally instead of exporting an API. - Amended commit message with comments from Mark Brown - Refactored to move the port_config manipulation to platform code. - Remove the gpio pins from the device-tree Eric Millbrandt (2): powerpc/5200: add mpc5200_psc_ac97_gpio_reset sound/soc: mpc5200_psc_ac97: Use gpio pins for cold reset arch/powerpc/include/asm/mpc52xx.h | 1 + arch/powerpc/platforms/52xx/mpc52xx_common.c | 103 ++ sound/soc/fsl/mpc5200_psc_ac97.c | 33 +++- 3 files changed, 133 insertions(+), 4 deletions(-) -DISCLAIMER: an automatically appended disclaimer may follow. By posting- -to a public e-mail mailing list I hereby grant permission to distribute- -and copy this message.- Hahahahaha! You're disclaimer to the disclaimer is awesome. g. This e-mail and the information, including any attachments, it contains are intended to be a confidential communication only to the person or entity to whom it is addressed and may contain information that is privileged. If the reader of this message is not the intended recipient, you are hereby notified that any dissemination, distribution or copying of this communication is strictly prohibited. If you have received this communication in error, please immediately notify the sender and destroy the original message. Thank you. Please consider the environment before printing this email. -- Grant Likely, B.Sc., P.Eng. Secret Lab Technologies Ltd. ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH 2/2 v3] sound/soc: mpc5200_psc_ac97: Use gpio pins for cold reset
On Mon, Jun 14, 2010 at 3:55 PM, Eric Millbrandt
emillbra...@dekaresearch.com wrote:
Call the gpio reset platform function instead of using the flawed
ac97 functionality of the MPC5200(b)
From MPC5200B User's Manual:
Some AC97 devices goes to a test mode, if the Sync line is high
during the Res line is low (reset phase). To avoid this behavior the
Sync line must be also forced to zero during the reset phase. To do
that, the pin muxing should switch to GPIO mode and the GPIO control
register should be used to control the output lines.
Signed-off-by: Eric Millbrandt emillbra...@dekaresearch.com
---
changes since v1
- Amended with comments from Mark Brown
- Fall back to the original reset implementation if no gpio pins are defined
in the device tree
changes since v2
- Refactored to move the port_config manipulation to platform code.
- Remove the gpio pins from the device-tree
sound/soc/fsl/mpc5200_psc_ac97.c | 33 +
1 files changed, 29 insertions(+), 4 deletions(-)
diff --git a/sound/soc/fsl/mpc5200_psc_ac97.c
b/sound/soc/fsl/mpc5200_psc_ac97.c
index e2ee220..380a127 100644
--- a/sound/soc/fsl/mpc5200_psc_ac97.c
+++ b/sound/soc/fsl/mpc5200_psc_ac97.c
@@ -20,6 +20,7 @@
#include asm/time.h
#include asm/delay.h
+#include asm/mpc52xx.h
#include asm/mpc52xx_psc.h
#include mpc5200_dma.h
@@ -100,19 +101,43 @@ static void psc_ac97_warm_reset(struct snd_ac97 *ac97)
{
struct mpc52xx_psc __iomem *regs = psc_dma-psc_regs;
+ mutex_lock(psc_dma-mutex);
+
out_be32(regs-sicr, psc_dma-sicr | MPC52xx_PSC_SICR_AWR);
udelay(3);
out_be32(regs-sicr, psc_dma-sicr);
+
+ mutex_unlock(psc_dma-mutex);
}
+#define MPC52xx_PSC_SICR_ACRB (0x8 24)
Put this #define with the rest of the MPC52xx_PSC_SICR_* #defines.
static void psc_ac97_cold_reset(struct snd_ac97 *ac97)
{
struct mpc52xx_psc __iomem *regs = psc_dma-psc_regs;
- /* Do a cold reset */
- out_8(regs-op1, MPC52xx_PSC_OP_RES);
- udelay(10);
- out_8(regs-op0, MPC52xx_PSC_OP_RES);
+ mutex_lock(psc_dma-mutex);
+
+ switch (psc_dma-id) {
+ case 0:
+ case 1:
+ mpc5200_psc_ac97_gpio_reset(psc_dma-id);
+ dev_info(psc_dma-dev, cold reset\n);
+
+ /* Notify the PSC that a reset has occurred */
+ out_be32(regs-sicr, psc_dma-sicr | MPC52xx_PSC_SICR_ACRB);
+
+ /* Re-enable RX and TX */
+ out_8(regs-command, MPC52xx_PSC_TX_ENABLE |
MPC52xx_PSC_RX_ENABLE);
+
+ break;
+ default:
+ dev_err(psc_dma-dev,
+ Unable to determine PSC, no cold-reset will be
+ performed\n);
+ }
You can drop the switch block and the error message. You do exactly
the same thing in the common code. Just call
mpc5200_psc_ac97_gpio_reset() unconditionally.
Otherwise, this version looks pretty good. After you've respun both
patches (I've got comments to make on the other too), and if it's okay
by Mark, then I can merge both patches through my tree.
Cheers,
g.
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH 1/2 v2] powerpc/5200: add mpc5200_psc_ac97_gpio_reset
On Mon, Jun 14, 2010 at 3:55 PM, Eric Millbrandt
emillbra...@dekaresearch.com wrote:
Work around a silicon bug in the ac97 reset functionality of the
mpc5200(b). The implementation of the ac97 cold reset is flawed.
If the sync and output lines are high when reset is asserted the
attached ac97 device may go into test mode. Avoid this by
reconfiguring the psc to gpio mode and generating the reset manually.
From MPC5200B User's Manual:
Some AC97 devices goes to a test mode, if the Sync line is high
during the Res line is low (reset phase). To avoid this behavior the
Sync line must be also forced to zero during the reset phase. To do
that, the pin muxing should switch to GPIO mode and the GPIO control
register should be used to control the output lines.
Signed-off-by: Eric Millbrandt emillbra...@dekaresearch.com
---
changes since v1
- Refactored to manipulate port_config and gpio pins internally instead of
exporting an API.
arch/powerpc/include/asm/mpc52xx.h | 1 +
arch/powerpc/platforms/52xx/mpc52xx_common.c | 103
++
2 files changed, 104 insertions(+), 0 deletions(-)
diff --git a/arch/powerpc/include/asm/mpc52xx.h
b/arch/powerpc/include/asm/mpc52xx.h
index b664ce7..1f41382 100644
--- a/arch/powerpc/include/asm/mpc52xx.h
+++ b/arch/powerpc/include/asm/mpc52xx.h
@@ -271,6 +271,7 @@ struct mpc52xx_intr {
/* mpc52xx_common.c */
extern void mpc5200_setup_xlb_arbiter(void);
extern void mpc52xx_declare_of_platform_devices(void);
+extern int mpc5200_psc_ac97_gpio_reset(int psc_number);
extern void mpc52xx_map_common_devices(void);
extern int mpc52xx_set_psc_clkdiv(int psc_id, int clkdiv);
extern unsigned int mpc52xx_get_xtal_freq(struct device_node *node);
diff --git a/arch/powerpc/platforms/52xx/mpc52xx_common.c
b/arch/powerpc/platforms/52xx/mpc52xx_common.c
index a46bad0..a9866fa 100644
--- a/arch/powerpc/platforms/52xx/mpc52xx_common.c
+++ b/arch/powerpc/platforms/52xx/mpc52xx_common.c
@@ -12,9 +12,11 @@
#undef DEBUG
+#include linux/gpio.h
#include linux/kernel.h
#include linux/spinlock.h
#include linux/of_platform.h
+#include linux/of_gpio.h
#include asm/io.h
#include asm/prom.h
#include asm/mpc52xx.h
@@ -37,6 +39,11 @@ static struct of_device_id mpc52xx_bus_ids[] __initdata = {
{}
};
+static struct of_device_id mpc52xx_gpio_simple[] = {
+ { .compatible = fsl,mpc5200-gpio, },
+ {}
+};
+
/*
* This variable is mapped in mpc52xx_map_wdt() and used in mpc52xx_restart().
* Permanent mapping is required because mpc52xx_restart() can be called
@@ -82,6 +89,13 @@ mpc5200_setup_xlb_arbiter(void)
iounmap(xlb);
}
+/*
+ * This variable is mapped in mpc52xx_write_port_config() and
+ * mpc52xx_read_port_config().
+ */
+DEFINE_SPINLOCK(mpc52xx_gpio_lock);
You don't need to define a new spin lock. Hold the spin lock already
defined in mpc52xx_gpio.c (see below)
+static u32 __iomem *port_config;
+
/**
* mpc52xx_declare_of_platform_devices: register internal devices and children
* of the localplus bus to the of_platform
@@ -117,6 +131,7 @@ void __init
mpc52xx_map_common_devices(void)
{
struct device_node *np;
+ const u32 *regaddr;
/* mpc52xx_wdt is mapped here and used in mpc52xx_restart,
* possibly from a interrupt context. wdt is only implement
@@ -135,6 +150,13 @@ mpc52xx_map_common_devices(void)
np = of_find_matching_node(NULL, mpc52xx_cdm_ids);
mpc52xx_cdm = of_iomap(np, 0);
of_node_put(np);
+
+ /* port_config register */
+ np = of_find_matching_node(NULL, mpc52xx_gpio_simple);
+ regaddr = of_get_address(np, 0, NULL, NULL);
+ port_config = ioremap((u32) of_translate_address(np, regaddr), 0x4);
+
+ of_node_put(np);
}
/**
@@ -233,3 +255,84 @@ mpc52xx_restart(char *cmd)
while (1);
}
+
+#define PSC1_RESET 254
+#define PSC1_SYNC 244
+#define PSC1_SDATA_OUT 246
+#define PSC2_RESET 253
+#define PSC2_SYNC 240
+#define PSC2_SDATA_OUT 242
These numbers are dynamically assigned. You cannot rely on them being
fixed. You'll need to use the hardware GPIO numbers.
However, as long as you're holding the existing gpio_lock, I've got no
problem with you sidestepping the GPIO api and accessing the registers
directly. It doesn't need to integrate with the gpio api because the
value of those GPIO signals is irrelevant after port_config is
switched back to PSC ac97 mode. (Just make sure you use
setbits32()/clrbits32() so you don't disturb the other GPIO line
settings.)
Cheers,
g.
+#define MPC52xx_GPIO_PSC1_MASK 0x7
+#define MPC52xx_GPIO_PSC2_MASK (0x74)
+
+/**
+ * mpc5200_psc_ac97_gpio_reset: Use gpio pins to reset the ac97 bus
+ *
+ * @psc: psc number to reset (only psc 1 and 2 support ac97)
+ */
+int mpc5200_psc_ac97_gpio_reset(int psc_number)
+{
+ unsigned long flags;
+
Re: [Patch 0/5] PPC64-HWBKPT: Hardware Breakpoint interfaces - ver XXII
On Fri, Jun 04, 2010 at 12:21:45PM +0530, K.Prasad wrote: Meanwhile I tested the per-cpu breakpoints with the new emulate_step patch (refer linuxppc-dev message-id: 20100602112903.gb30...@brick.ozlabs.ibm.com) and they continue to fail due to emulate_step() failure, in my case, on a lwz r0,0(r28) instruction. You need to pass the instruction word to emulate_step(), not the instruction address. Also you need to have the full GPR set available. The patch below fixes these problems. I'll fold these changes into your patch 2/5. Paul. --- diff --git a/arch/powerpc/kernel/exceptions-64s.S b/arch/powerpc/kernel/exceptions-64s.S index 3e423fb..f53029a 100644 --- a/arch/powerpc/kernel/exceptions-64s.S +++ b/arch/powerpc/kernel/exceptions-64s.S @@ -828,6 +828,7 @@ END_FW_FTR_SECTION_IFCLR(FW_FEATURE_ISERIES) /* We have a data breakpoint exception - handle it */ handle_dabr_fault: + bl .save_nvgprs ld r4,_DAR(r1) ld r5,_DSISR(r1) addir3,r1,STACK_FRAME_OVERHEAD diff --git a/arch/powerpc/kernel/hw_breakpoint.c b/arch/powerpc/kernel/hw_breakpoint.c index ef70cf0..489049c 100644 --- a/arch/powerpc/kernel/hw_breakpoint.c +++ b/arch/powerpc/kernel/hw_breakpoint.c @@ -35,6 +35,7 @@ #include asm/hw_breakpoint.h #include asm/processor.h #include asm/sstep.h +#include asm/uaccess.h /* * Stores the breakpoints currently in use on each breakpoint address @@ -203,6 +204,7 @@ int __kprobes hw_breakpoint_handler(struct die_args *args) int stepped = 1; struct arch_hw_breakpoint *info; unsigned long dar = regs-dar; + unsigned int instr; /* Disable breakpoints during exception handling */ set_dabr(0); @@ -255,7 +257,11 @@ int __kprobes hw_breakpoint_handler(struct die_args *args) goto out; } - stepped = emulate_step(regs, regs-nip); + stepped = 0; + instr = 0; + if (!__get_user_inatomic(instr, (unsigned int *) regs-nip)) + stepped = emulate_step(regs, instr); + /* * emulate_step() could not execute it. We've failed in reliably * handling the hw-breakpoint. Unregister it and throw a warning ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: Request review of device tree documentation
On Mon, Jun 14, 2010 at 10:59:20AM -0400, Nicolas Pitre wrote: On Mon, 14 Jun 2010, David Gibson wrote: On Sun, Jun 13, 2010 at 11:02:15PM -0600, Grant Likely wrote: [sni] That's sort of a self-fulfilling prophecy. If the OS doesn't trust the firmware, there is no pressure for the firmware to get it right. Firmware will not get it right. Period. There will always be something wrong. It is never right on PCs. It will never be right on the other architectures. Yes, yes, yes. And there is a great deal of empirical evidence to back that assertion. That goes for OSes too, but upgrading an OS isn't as risky as upgrading firmware. That isn't to say that it can't be close, but every firmware feature that the OS depends on is a feature that could force a risky firmware upgrade when the bug in it is discovered. Indeed. In fact, the general rule of thumb is really put as much as possible into the most easily replaced layer of the stack. This is, incidentally, why I've always been dubious about simple firmwares supplying a flattened device tree rather than including the device tree template in the kernel, cuboot style. The biggest advantage, IMHO, for adding DT to ARM, is actually to decouple the hardware config information and the kernel. If in the end the DT has to be shipped in the kernel then we're losing all this advantage over the current state of things on ARM which still works pretty well otherwise. Right, which is why I'm just dubious, not dead against it. If firmware supplies a device tree that's so awful you have to replace most of it, then you haven't won much over having a kernel wrapper which uses ad-hoc logic to detect the board type from whatever random clues the firmware leaves and selects a device tree from it's library of them based on that. On ARM this sort of approach is probably more effective than powerpc, even, since you could use the machine number to select from a bag of canned device trees and still have a multi-board kernel. In the best case, the simple firmware simply has to retrieve the flattened device tree from flash, and pass it to the kernel just like some anonymous blob. And the simple firmware only needs to provide a way for that DT blob to be updatable, like through an upload of a replacement blob that was prepared offline. Just like a ramdisk image or the like. Yes, having the firmware DT independently updateable makes most of my concerns about it go away. -- David Gibson| I'll have my music baroque, and my code david AT gibson.dropbear.id.au | minimalist, thank you. NOT _the_ _other_ | _way_ _around_! http://www.ozlabs.org/~dgibson ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH] powerpc: Fix mpic_resume on early G5 macs
On Sat, 2010-06-12 at 21:36 -0400, Alastair Bridgewater wrote:
mpic_resume() on G5 macs blindly dereferences mpic-fixups, but
it may legitimately be NULL (as on PowerMac7,2). Add an explicit
check.
This fixes susend-to-disk with one processor (maxcpus=1) for me.
Thanks. Patch is terribly mangled tho (word wrapped and tabs have been
replaced with spaces). I fixed it up manually but check your email setup
next time.
Cheers,
Ben.
Signed-off-by: Alastair Bridgewater alastair.bridgewa...@gmail.com
---
diff --git a/arch/powerpc/sysdev/mpic.c b/arch/powerpc/sysdev/mpic.c
index 4fd57ab..28668ba 100644
--- a/arch/powerpc/sysdev/mpic.c
+++ b/arch/powerpc/sysdev/mpic.c
@@ -1666,7 +1666,7 @@ static int mpic_resume(struct sys_device *dev)
mpic-save_data[i].dest);
#ifdef CONFIG_MPIC_U3_HT_IRQS
- {
+ if (mpic-fixups) {
struct mpic_irq_fixup *fixup = mpic-fixups[i];
if (fixup-base) {
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
