| Message ID | 20130812230408.GA4420@roeck-us.net |
|---|---|
| State | New |
| Headers | show |
On Mon, Aug 12, 2013 at 04:04:08PM -0700, Guenter Roeck wrote: > Hacked diff is below. Can I write that up as clean patch and submit it, > or do we need a test on real hardware ? Well, if we want to ensure that it is really correct, the sensible thing to do is to try it on real hardware, otherwise we're risking yet another change to this. Earlier in this thread, some people said that they have the hardware, so it shouldn't be that difficult to get it tested on real stuff.
On 14 August 2013 11:33, Russell King - ARM Linux <linux@arm.linux.org.uk> wrote: > On Mon, Aug 12, 2013 at 04:04:08PM -0700, Guenter Roeck wrote: >> Hacked diff is below. Can I write that up as clean patch and submit it, >> or do we need a test on real hardware ? > > Well, if we want to ensure that it is really correct, the sensible thing > to do is to try it on real hardware, otherwise we're risking yet another > change to this. > > Earlier in this thread, some people said that they have the hardware, so > it shouldn't be that difficult to get it tested on real stuff. Yes, I definitely think we should test on the hardware before we land yet another change to this PCI code that hasn't really been thoroughly tested on anything. I have the board/backplane on my desk but it'll be later in the week before I can do the testing (currently still messing with uboot config to get it to actually boot a kernel). thanks -- PMM
On Wed, Aug 14, 2013 at 01:44:44PM +0100, Peter Maydell wrote: > On 14 August 2013 11:33, Russell King - ARM Linux > <linux@arm.linux.org.uk> wrote: > > On Mon, Aug 12, 2013 at 04:04:08PM -0700, Guenter Roeck wrote: > >> Hacked diff is below. Can I write that up as clean patch and submit it, > >> or do we need a test on real hardware ? > > > > Well, if we want to ensure that it is really correct, the sensible thing > > to do is to try it on real hardware, otherwise we're risking yet another > > change to this. > > > > Earlier in this thread, some people said that they have the hardware, so > > it shouldn't be that difficult to get it tested on real stuff. > > Yes, I definitely think we should test on the hardware before we > land yet another change to this PCI code that hasn't really been > thoroughly tested on anything. I have the board/backplane on my > desk but it'll be later in the week before I can do the testing > (currently still messing with uboot config to get it to actually > boot a kernel). Realview or Versatile? I still need to sort out Realview. The alternative is - I have both the Realview EB and Versatile PB926 here, but no backplane (it wasn't deemed to be necessary for me to have such a thing.) If someone wants to donate a backplane...
On 14 August 2013 13:49, Russell King - ARM Linux <linux@arm.linux.org.uk> wrote: > On Wed, Aug 14, 2013 at 01:44:44PM +0100, Peter Maydell wrote: >> Yes, I definitely think we should test on the hardware before we >> land yet another change to this PCI code that hasn't really been >> thoroughly tested on anything. I have the board/backplane on my >> desk but it'll be later in the week before I can do the testing >> (currently still messing with uboot config to get it to actually >> boot a kernel). > > Realview or Versatile? I still need to sort out Realview. PB926, so versatile. Let's get that one straightened out first, since at the moment the kernel has no realview PCI support at all. I should be able to get a PB1176 to go in the backplane for testing that, though. -- PMM
On 08/14/2013 05:44 AM, Peter Maydell wrote: > On 14 August 2013 11:33, Russell King - ARM Linux > <linux@arm.linux.org.uk> wrote: >> On Mon, Aug 12, 2013 at 04:04:08PM -0700, Guenter Roeck wrote: >>> Hacked diff is below. Can I write that up as clean patch and submit it, >>> or do we need a test on real hardware ? >> >> Well, if we want to ensure that it is really correct, the sensible thing >> to do is to try it on real hardware, otherwise we're risking yet another >> change to this. >> >> Earlier in this thread, some people said that they have the hardware, so >> it shouldn't be that difficult to get it tested on real stuff. > > Yes, I definitely think we should test on the hardware before we > land yet another change to this PCI code that hasn't really been > thoroughly tested on anything. I have the board/backplane on my Agreed. > desk but it'll be later in the week before I can do the testing > (currently still messing with uboot config to get it to actually > boot a kernel). > That would be great. Thanks a lot for your help! Guenter
Hello all, my name is Dacian and I'm new on this mailing list. I would like to visualize during execution the addresses of the instruction currently been executed, the address of the memory being read and being written by the same execution if it applies. has anyone tried this before maybe is already implemented. best regards, dacian
diff --git a/arch/arm/mach-versatile/pci.c b/arch/arm/mach-versatile/pci.c index e92e5e0..53b4208 100644 --- a/arch/arm/mach-versatile/pci.c +++ b/arch/arm/mach-versatile/pci.c @@ -333,7 +333,11 @@ static int __init versatile_map_irq(const struct pci_dev *dev, u8 slot, u8 pin) * 26 1 IRQ_SIC_PCI2 * 27 1 IRQ_SIC_PCI3 */ +#if 0 irq = IRQ_SIC_PCI0 + ((slot - 24 + pin - 1) & 3); +#else + irq = IRQ_SIC_PCI0 + ((slot + 2 + pin - 1) & 3); +#endif return irq; }