Re: Reverting old hack

[Yoichi Yuasa <yuasa@linux-mips.org>]

On Mon, 22 Feb 2010 17:15:24 -0700
Bjorn Helgaas <bjorn.helgaas@hp.com> wrote:

> On Monday 22 February 2010 04:51:43 pm Yoichi Yuasa wrote:
> > Hi Bjorn,
> > 
> > On Mon, 22 Feb 2010 13:55:28 -0700
> > Bjorn Helgaas <bjorn.helgaas@hp.com> wrote:
> > 
> > > On Sunday 21 February 2010 12:45:31 am Yoichi Yuasa wrote:
> > > > > I'd like to understand the PCI architecture of Cobalt better.  Would you
> > > > > mind turning on CONFIG_PCI_DEBUG and posting the dmesg log?
> > > > 
> > > > If you want to know what happen, you can see my old e-mail. 
> > > > 
> > > > http://marc.info/?l=linux-kernel&m=118792430424186&w=2
> > > 
> > > There's not much detail there.  It would save me a lot of time if
> > > you could collect the complete dmesg log, /proc/iomem, and /proc/ioports.
> > 
> > It cannot boot without old hack.
> 
> I know; I meant that the information from a kernel with the old
> hack would be useful.  But I think I'm starting to understand anyway.
> 
> The Linux I/O port number space is defined here:
> 
>     static struct resource cobalt_io_resource = {
>         .start  = 0x1000,
>         .end    = GT_DEF_PCI0_IO_SIZE - 1,  /* 0x1ffffff */
> 
> [As an aside, I'm not sure 0x1000 is the correct start -- for example,
> I think Linux I/O port 0x1f0 is forwarded by the host bridge.]

This is the space(0x0-0xfff) for the fixed address devices(PIC, RTC, DMA(just reserved)...). 

$ cat /proc/ioports                                                      
00000000-0000001f : reserved                                                    
00000020-00000021 : pic1                                                        
00000060-0000006f : reserved                                                    
00000070-00000077 : rtc_cmos                                                    
  00000070-00000077 : rtc0                                                      
00000080-0000008f : reserved                                                    
000000a0-000000a1 : pic2                                                        
000000c0-000000df : reserved                                                    
00000170-00000177 : pata_via                                                    
000001f0-000001f7 : pata_via                                                    
00000376-00000376 : pata_via                                                    
000003f6-000003f6 : pata_via                                                    
00001000-01ffffff : PCI I/O                                                     
  00001000-0000107f : 0000:00:07.0                                              
    00001000-0000107f : tulip                                                   
  00001080-000010ff : 0000:00:0c.0                                              
    00001080-000010ff : tulip                                                   
  00001400-0000141f : 0000:00:09.2                                              
  00001420-0000142f : 0000:00:09.1                                              
    00001420-0000142f : pata_via
 
> The corresponding PCI I/O port numbers are determined by the PCI
> I/O decoder address, so I agree that we need the io_offset to convert
> between the Linux port numbers and ports that appear on the PCI bus.
> 
> I think the IDE device is a problem because pci_setup_device() fills
> in legacy resources with ports 0x1f0-0x1f7, etc.  We expect those
> resources to contain PCI bus addresses at this point, but we could
> never see those addresses on the Cobalt PCI bus (we would only see
> things in the range 0x10000000-0x11ffffff).
> 
> When we convert 0x1f0 with pcibios_bus_to_resource() (or with
> pcibios_fixup_device_resources() without the IORESOURCE_PCI_FIXED
> hack), we get 0x1f0 + 0xf0000000 == 0xf00001f0, when we want 0x1f0
> instead.
> 
> > pata_via 0000:00:09.1: BAR 0: can't reserve [io  0xf00001f0-0xf00001f7]
> 
> I still don't know the best way to fix this, but does this make sense
> so far?

That makes sense.

Yoichi