On Tue, Dec 11, 2007 at 11:27:24AM +1100, Benjamin Herrenschmidt wrote:
> > The GT-64111 system controller doesn't provide any kind of mapping
> > functionality that would help here. So legacy port addressing can only
> > work by exploiting aliases due to incomplete decoding of legacy ioport
> >
> The GT-64111 system controller doesn't provide any kind of mapping
> functionality that would help here. So legacy port addressing can only
> work by exploiting aliases due to incomplete decoding of legacy ioport
> addreses by the VT82C586 - but direct addressing is impossible.
Ok, that explai
On Mon, 2007-12-10 at 23:07 +, Alan Cox wrote:
> > Forcing controllers into native mode tends to be something that really
> > only works on -some- controllers. I'm happy to have a hack to try to do
> > that on all of them on powermacs, because the range of controllers that
> > might not be in
On Tue, Dec 11, 2007 at 07:43:03AM +1100, Benjamin Herrenschmidt wrote:
> > > :00:09.1 IDE interface: VIA Technologies, Inc.
> > > VT82C586A/B/VT82C686/A/B/VT823x/A/C PIPC Bus Master IDE (rev 06)
> > > (prog-if 8a [Master SecP PriP])
> > > Flags: bus master, fast Back2Back, medium devs
> Forcing controllers into native mode tends to be something that really
> only works on -some- controllers. I'm happy to have a hack to try to do
> that on all of them on powermacs, because the range of controllers that
> might not be in native mode in the first place there is pretty small,
> and
On Mon, 2007-12-10 at 15:47 +, Ralf Baechle wrote:
>
>
> > :00:09.1 IDE interface: VIA Technologies, Inc.
> > VT82C586A/B/VT82C686/A/B/VT823x/A/C PIPC Bus Master IDE (rev 06)
> > (prog-if 8a [Master SecP PriP])
> > Flags: bus master, fast Back2Back, medium devsel, latency 64
> >
On Mon, 2007-12-10 at 15:01 +, Alan Cox wrote:
>
> If the hardware cannot map the low PCI space then set
> CONFIG_NO_ATA_LEGACY and the ATA layer will leave legacy ports alone.
> Unfortunately its not clear we can make that mode try and force
> controllers into native. We could try that if th
On Mon, Dec 10, 2007 at 03:01:26PM +, Alan Cox wrote:
> > It seems the whole MIPS resource managment is complicated enough (out of
> > necessity) that only a few people actually grok it. Ioports being
> > actually memory mapped on MIPS only makes the confusion worse, sigh.
>
> If the hardwar
> It seems the whole MIPS resource managment is complicated enough (out of
> necessity) that only a few people actually grok it. Ioports being
> actually memory mapped on MIPS only makes the confusion worse, sigh.
If the hardware cannot map the low PCI space then set
CONFIG_NO_ATA_LEGACY and the
On Mon, Dec 10, 2007 at 11:20:50AM +, Alan Cox wrote:
> > To be totally correct, we still need to also revert
> > commit fd6e732186ab522c812ab19c2c5e5befb8ec8115 which
> > is bogus.
>
> Agreed but that would cause an revert on an obscure MIPS platform which
> is apparently now a thoughtcrime
Mailing List ,
> Greg KH <[EMAIL PROTECTED]>,
> Linus Torvalds <[EMAIL PROTECTED]>,
> Bartlomiej Zolnierkiewicz <[EMAIL PROTECTED]>
> Subject: Re: Please revert: PCI: fix IDE legacy mode resources
> Content-Type: text/plain
>
> powerpc: Fix IDE
On Sun, Dec 09, 2007 at 06:24:51PM +1100, Benjamin Herrenschmidt wrote:
> If that is the case though (that is it can't issue low ioport cycles),
> how would have the fd6e7321... worked in the first place ? Hrm...
> strange. My understanding is that all that patch does is put junk in the
> pci_dev
On Mon, 10 Dec 2007 15:29:22 +1100
Benjamin Herrenschmidt <[EMAIL PROTECTED]> wrote:
> powerpc: Fix IDE legacy vs. native fixups
>
> PowerMac and CHRP/BriQ platforms have quirks to switch some IDE
> controllers from legacy mode to fully native mode. Those quirks
> however will not work properly a
powerpc: Fix IDE legacy vs. native fixups
PowerMac and CHRP/BriQ platforms have quirks to switch some IDE
controllers from legacy mode to fully native mode. Those quirks
however will not work properly anymore due to a change to the
generic code to better handle legacy IDE resources.
This fixes it
On Sun, 2007-12-09 at 22:23 +, Alan Cox wrote:
>
> I think the generic code is right, up to the MIPS stuff. What the MIPS
> stuff is doing wants looking at further. If it simply can't address
> legacy ports them it should set
Yes, well, we -do- need to remove the pcibios_resource_to_bus() th
> Quite possibly, though as I said in practice, what we did so far
> happened to "just work" on pretty much everything we were faced with
> (which iirc is basically winbond and VIA controllers, possibly a few
> others).
>
> Anyway, I'll scrub around. Again, I'm not saying the approach is wrong
> i
On Sun, 2007-12-09 at 13:39 +, Alan Cox wrote:
> > > In fact, I see a deeper problem with Bart's original patch that moved
> > > the "fixup" the PCI probe.
> >
> > I don't remember changing anything there, could you remind me what it was
> > exactly (commit number or patch name)?
>
> I'm pre
On Sun, 2007-12-09 at 13:38 +, Alan Cox wrote:
> > has, I don't know for sure), we have a quirk that puts those
> controller
> > back into native mode. But so far, those quirks didn't change the
> > resources as they were supposed to contain the proper BAR values
> that
> > would, from then, b
> > In fact, I see a deeper problem with Bart's original patch that moved
> > the "fixup" the PCI probe.
>
> I don't remember changing anything there, could you remind me what it was
> exactly (commit number or patch name)?
I'm pretty sure he means the code I added a while ago to actually correct
> The code now replaces the content of the resource structures with the
> hard-decoded legacy addresses for any IDE controller in legacy mode,
> just losing whatever was there (the real BAR value).
This is correct behaviour. It checks the port is in legacy mode. If the
port is in legacy mode the B
On Sunday 09 December 2007, Benjamin Herrenschmidt wrote:
>
> > If that is the case though (that is it can't issue low ioport cycles),
> > how would have the fd6e7321... worked in the first place ? Hrm...
> > strange. My understanding is that all that patch does is put junk in the
> > pci_dev res
> If that is the case though (that is it can't issue low ioport cycles),
> how would have the fd6e7321... worked in the first place ? Hrm...
> strange. My understanding is that all that patch does is put junk in the
> pci_dev resource structures :-) Maybe that's enough to cause the PCI
> layer la
On Sun, 2007-12-09 at 02:12 +, Ralf Baechle wrote:
> So where do we stand with this?
>
> As I understand the Cobalt system controller it is not possible to address
> ioport addresses below 0x1000 at all on the PCI bus of the GT-64111.
> As such I think the best solution is a GT-64111-spec
On Thu, Dec 06, 2007 at 05:24:22PM +1100, Benjamin Herrenschmidt wrote:
> On Thu, 2007-12-06 at 14:58 +0900, Yoichi Yuasa wrote:
> > > What I don't understand is thus why you are calling resource_to_bus
> > on 0x1f0
> > > which is -not- a resource value, but is already a BAR value...
> >
> > 0x1f
On Thu, Dec 06, 2007 at 12:32:54PM +, Ralf Baechle wrote:
> > > What I don't understand is thus why you are calling resource_to_bus on
> > > 0x1f0
> > > which is -not- a resource value, but is already a BAR value...
> >
> > 0x1f0 is resource value on MIPS Cobalt.
> > All RAW BAR values conta
On Thu, Dec 06, 2007 at 02:58:13PM +0900, Yoichi Yuasa wrote:
> > What I don't understand is thus why you are calling resource_to_bus on 0x1f0
> > which is -not- a resource value, but is already a BAR value...
>
> 0x1f0 is resource value on MIPS Cobalt.
> All RAW BAR values contain the offset(0x1
On Thu, 2007-12-06 at 14:58 +0900, Yoichi Yuasa wrote:
> > What I don't understand is thus why you are calling resource_to_bus
> on 0x1f0
> > which is -not- a resource value, but is already a BAR value...
>
> 0x1f0 is resource value on MIPS Cobalt.
> All RAW BAR values contain the offset(0x10
On Thu, 06 Dec 2007 16:04:07 +1100
Benjamin Herrenschmidt <[EMAIL PROTECTED]> wrote:
>
> On Thu, 2007-12-06 at 13:34 +0900, Yoichi Yuasa wrote:
> > > I don't understand how his fix can work on MIPS nor why the previous
> > > code didn't, but I don't know how MIPS does its remapping tricks,
> > >
On Thu, 06 Dec 2007 11:10:18 +1100
Benjamin Herrenschmidt <[EMAIL PROTECTED]> wrote:
> The commit below that was merged in october looks bogus to me.
>
> At this stage in the PCI probe, the pci_dev->resource's contain RAW bar
> values, that is bus values..
>
> A PCI legacy IDE controller that ha
On Thu, 2007-12-06 at 13:34 +0900, Yoichi Yuasa wrote:
> > I don't understand how his fix can work on MIPS nor why the previous
> > code didn't, but I don't know how MIPS does its remapping tricks,
> > however it will definitely -not- work on powerpc (and will break a
> > couple of machines out th
The commit below that was merged in october looks bogus to me.
At this stage in the PCI probe, the pci_dev->resource's contain RAW bar
values, that is bus values..
A PCI legacy IDE controller that hard decodes 0x1f0 etc... does such as
bus values as well. That is, the resources should contain 0x
31 matches
Mail list logo
