| Submitter | Myles Watson |
|---|---|
| Date | 2009-10-21 22:07:58 |
| Message ID | <2831fecf0910211507k44856b2bl54ebd9d17a84df5@mail.gmail.com> |
| Download | mbox | patch |
| Permalink | /patch/459/ |
| State | RFC |
| Headers | show |
Comments
Myles Watson wrote: > The attached patch fixes booting for arima/hdama. > > How should we really fix it? In v3 didn't we just scrap type 2 > accesses all together? We can keep the type 2 support code, but the auto detection at run time makes absolutely no sense. I sent a patch for this some days ago, but I think Carl-Daniel didn't have too much success with it on his board. Stefan
> > How should we really fix it? In v3 didn't we just scrap type 2 > > accesses all together? > We can keep the type 2 support code, but the auto detection at run time > makes absolutely no sense. > > I sent a patch for this some days ago, but I think Carl-Daniel didn't > have too much success with it on his board. Maybe we could simplify it a little and try again. It looks like the rs690 changes were pretty extensive. Thanks, Myles
Myles Watson wrote: >>> How should we really fix it? In v3 didn't we just scrap type 2 >>> accesses all together? >>> >> We can keep the type 2 support code, but the auto detection at run time >> makes absolutely no sense. >> >> I sent a patch for this some days ago, but I think Carl-Daniel didn't >> have too much success with it on his board. >> > Maybe we could simplify it a little and try again. It looks like the rs690 > changes were pretty extensive. > > Generally, we should also change the mainboard code to access pci devices in ->init, not in ->enable. This should solve the issues. Then, dropping auto detect could be the next step.
> Myles Watson wrote: > >>> How should we really fix it? In v3 didn't we just scrap type 2 > >>> accesses all together? > >>> > >> We can keep the type 2 support code, but the auto detection at run time > >> makes absolutely no sense. > >> > >> I sent a patch for this some days ago, but I think Carl-Daniel didn't > >> have too much success with it on his board. > >> > > Maybe we could simplify it a little and try again. It looks like the > rs690 > > changes were pretty extensive. > > > > > Generally, we should also change the mainboard code to access pci > devices in ->init, not in ->enable. This should solve the issues. I thought enable was run at the very beginning, before scan, while init was run at the end. That seems like a hard conversion to make. Thanks, Myles
> Myles Watson wrote: > > The attached patch fixes booting for arima/hdama. > > > > How should we really fix it? In v3 didn't we just scrap type 2 > > accesses all together? > We can keep the type 2 support code, but the auto detection at run time > makes absolutely no sense. The auto detection code is the only place the type 2 struct is referenced. Thanks, Myles
Myles Watson wrote: > I thought enable was run at the very beginning, before scan, while init was > run at the end. Yes. > That seems like a hard conversion to make. > > Why? Stefan
On Thu, Oct 22, 2009 at 9:36 AM, Stefan Reinauer <stepan@coresystems.de>wrote: > Myles Watson wrote: > > I thought enable was run at the very beginning, before scan, while init > was > > run at the end. > Yes. > > > That seems like a hard conversion to make. > > > > > Why? I thought that some of the PCI accesses were to set things up before scanning the bus and reading the resources. If we change the order drastically, we will probably break all kinds of assumptions. Thanks, Myles
On 22.10.2009 09:57, Stefan Reinauer wrote: > Myles Watson wrote: > >> The attached patch fixes booting for arima/hdama. >> >> How should we really fix it? In v3 didn't we just scrap type 2 >> accesses all together? >> > We can keep the type 2 support code, but the auto detection at run time > makes absolutely no sense. > > I sent a patch for this some days ago, but I think Carl-Daniel didn't > have too much success with it on his board. > Yes, if I applied the complete patch, the board was hanging. If I applied parts of the patch (the rs690 part), the board still was hanging, but I think that was due to a device tree code bug/limitation. I can dig up the details if you want, becase the patch itself looked desirable. Regards, Carl-Daniel
Patch
Index: svn/src/arch/i386/lib/pci_ops_auto.c =================================================================== --- svn.orig/src/arch/i386/lib/pci_ops_auto.c +++ svn/src/arch/i386/lib/pci_ops_auto.c @@ -47,6 +47,9 @@ const struct pci_bus_operations *pci_che { unsigned int tmp; + printk_debug("%s\n", __func__); + printk_debug("PCI: Forcing configuration type 1\n"); + return &pci_cf8_conf1; /* * Check if configuration type 1 works. */