Menu
▾
▴
linux-apus-devel
|
From: Matthew W. <wi...@de...> - 2003-09-29 14:03:16
|
On Mon, Sep 29, 2003 at 02:53:16PM +0200, Roman Zippel wrote: > Hi, > > On Mon, 29 Sep 2003, Geert Uytterhoeven wrote: > > > > Are there any Amiga cards that are 720 based? > > > > I don't know for sure. Probably not (cfr. above). > > The ppc boards have a 770. In the APUS tree we currently have a modified > ncr53c8xx driver, that sort of seems to work. The biggest problem seems to > be the incoherent memory interface. ... Ah ;-) So where do I find the APUS tree? From digging around on the web (man, there's a lot of broken links in the APUS faq ...), it seems to be its own sourceforge project that hasn't switched to working on 2.6 yet, is this correct? Now that ncr53c8xx is non-PCI only, it should cause the absolute minimum of wailing & gnashing of teeth to convert it to use the non-coherent dma device API. It would benefit PA-RISC too as we have two models (735 and 755) that have NCR720 chips and a non-coherent architecture. Right now, they use the 53c700 driver, but it'd be better to use the ncr53c8xx driver, of course. Are any APUS people interested in working on this? -- "It's not Hollywood. War is real, war is primarily not about defeat or victory, it is about death. I've seen thousands and thousands of dead bodies. Do you think I want to have an academic debate on this subject?" -- Robert Fisk |
|
From: Geert U. <ge...@li...> - 2003-09-29 14:04:04
|
On Mon, 29 Sep 2003, Matthew Wilcox wrote:
> On Mon, Sep 29, 2003 at 02:53:16PM +0200, Roman Zippel wrote:
> > The ppc boards have a 770. In the APUS tree we currently have a modified
> > ncr53c8xx driver, that sort of seems to work. The biggest problem seems to
> > be the incoherent memory interface.
>
> ... Ah ;-) So where do I find the APUS tree? From digging around on
> the web (man, there's a lot of broken links in the APUS faq ...), it
> seems to be its own sourceforge project that hasn't switched to working
> on 2.6 yet, is this correct?
The APUS tree is indeed at SourceForge. Most recent version (not counting
Roman's hard disk :-) is 2.4.22.
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@li...
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
|
|
From: Roman Z. <zi...@li...> - 2003-09-29 16:56:46
|
Hi, On Mon, 29 Sep 2003, Matthew Wilcox wrote: > ... Ah ;-) So where do I find the APUS tree? From digging around on > the web (man, there's a lot of broken links in the APUS faq ...), it It's also quite old... :) > seems to be its own sourceforge project that hasn't switched to working > on 2.6 yet, is this correct? Yes. My 2.6 tree currently dies at the first exec. > Now that ncr53c8xx is non-PCI only, it should cause the absolute minimum > of wailing & gnashing of teeth to convert it to use the non-coherent > dma device API. Um, which one is the current right dma device API? bye, Roman |
|
From: Matthew W. <wi...@de...> - 2003-09-29 16:28:52
|
On Mon, Sep 29, 2003 at 06:24:14PM +0200, Roman Zippel wrote: > > Now that ncr53c8xx is non-PCI only, it should cause the absolute minimum > > of wailing & gnashing of teeth to convert it to use the non-coherent > > dma device API. > > Um, which one is the current right dma device API? The one in Documentation/DMA-API.txt. It looks like PowerPC hasn't got an implementation of this yet -- is APUS the only non-coherent PowerPC subport? -- "It's not Hollywood. War is real, war is primarily not about defeat or victory, it is about death. I've seen thousands and thousands of dead bodies. Do you think I want to have an academic debate on this subject?" -- Robert Fisk |
|
From: Grant G. <gru...@pa...> - 2003-09-29 20:56:05
|
On Mon, Sep 29, 2003 at 05:27:49PM +0100, Matthew Wilcox wrote:
> > Um, which one is the current right dma device API?
>
> The one in Documentation/DMA-API.txt.
Matthew, which version of the source tree?
2.4.22 and 2.6.x versions of this file are not identical.
grundler@gsyprf3:/usr/src$ diff linux-2.?/Documentation/DMA-mapping.txt | wc -l
117
grundler@gsyprf3:/usr/src$ wc -l linux-2.?/Documentation/DMA-mapping.txt
798 linux-2.4/Documentation/DMA-mapping.txt
828 linux-2.5/Documentation/DMA-mapping.txt
1626 total
thanks,
grant
|
|
From: James B. <Jam...@st...> - 2003-09-29 21:19:27
|
On Mon, 2003-09-29 at 15:55, Grant Grundler wrote: > On Mon, Sep 29, 2003 at 05:27:49PM +0100, Matthew Wilcox wrote: > > > Um, which one is the current right dma device API? > > > > The one in Documentation/DMA-API.txt. > > Matthew, which version of the source tree? > 2.4.22 and 2.6.x versions of this file are not identical. > > grundler@gsyprf3:/usr/src$ diff linux-2.?/Documentation/DMA-mapping.txt | wc -l > 117 > grundler@gsyprf3:/usr/src$ wc -l linux-2.?/Documentation/DMA-mapping.txt > 798 linux-2.4/Documentation/DMA-mapping.txt > 828 linux-2.5/Documentation/DMA-mapping.txt > 1626 total DMA-mapping.txt is only the pci_ DMA API. The ncr53c8xx doesn't use that any more. It only uses the generic DMA API, which is documented in DMA-API.txt like willy said, and is only in 2.6 (not 2.4). James |
|
From: Grant G. <gru...@pa...> - 2003-09-30 17:23:14
|
On Mon, Sep 29, 2003 at 04:00:10PM -0500, James Bottomley wrote: > DMA-mapping.txt is only the pci_ DMA API. Doh! yes...misread willy's comment. sorry. grant |
|
From: Rene B. <re...@we...> - 2003-09-29 21:27:09
|
On 2003.09.29 15:33 Matthew Wilcox wrote: > ... Ah ;-) So where do I find the APUS tree? From digging around on > the web (man, there's a lot of broken links in the APUS faq ...), it > seems to be its own sourceforge project that hasn't switched to working > on 2.6 yet, is this correct? >=20 > Now that ncr53c8xx is non-PCI only, it should cause the absolute minimu= m > of wailing & gnashing of teeth to convert it to use the non-coherent > dma device API. It would benefit PA-RISC too as we have two models > (735 and 755) that have NCR720 chips and a non-coherent architecture. > Right now, they use the 53c700 driver, but it'd be better to use the > ncr53c8xx driver, of course. >=20 > Are any APUS people interested in working on this? Hello! I'm the one who getting the 53c770 driver working on APUS. The driver is=20 based on the code from the ncr53c8xx driver which I found on a 2.4.16=20 kernel (maybe it was an other kernel version, I'm not really sure=20 anymore). In newer kernels the ncr53c8xx drivers are replaced by sym53c8x= x=20 which uses a different and more complicated architecture. In my opinion, the best is to create a seperate 53c720/770 driver based o= n=20 the 53c770 from APUS or ncr53c8xx. I guess the 53c770 from APUS should=20 work (with some changes) on a 720 (or similar), because the 770 was=20 designed to replace the 720. But I don't know anything about 735 and 755. But the APUS driver is a really big "patchwork", has some problems and=20 needs a clean-up. And I haven't worked on the driver since a year due to=20 lack of time, sorry. I still have lack of time, but if there are any questions, I will help. I= t=20 will be nice to have a native 720/770 driver... And maybe, if someone=20 tries to port this driver to a PA, I have to go for it... Ciao, Ren=E8 |
|
From: Matthew W. <wi...@de...> - 2003-09-30 02:21:52
|
On Mon, Sep 29, 2003 at 11:25:01PM +0200, Rene Brothuhn wrote: > I'm the one who getting the 53c770 driver working on APUS. The driver is Good to hear from you. Let me just clear up a couple of misunderstandings... > based on the code from the ncr53c8xx driver which I found on a 2.4.16 > kernel (maybe it was an other kernel version, I'm not really sure > anymore). In newer kernels the ncr53c8xx drivers are replaced by sym53c8xx > which uses a different and more complicated architecture. The sym53c8xx driver doesn't support all the chips that ncr53c8xx supported (mostly earlier chips like 810). Now there's the sym53c8xx_2 driver that supports all the 8xx chips. In 2.6, we've now eliminated all PCI stuff from ncr53c8xx (and it should probably be renamed to ncr53c7xx, but I actually have a slightly different plan for renaming it that needs other work to happen first). > In my opinion, the best is to create a seperate 53c720/770 driver based on > the 53c770 from APUS or ncr53c8xx. I guess the 53c770 from APUS should > work (with some changes) on a 720 (or similar), because the 770 was > designed to replace the 720. But I don't know anything about 735 and 755. The HP 735/755 workstations have an NCR720 chip as part of their `core IO'. It appears as a parisc_device. They have a PCX-T CPU which has no way to allocate coherent memory. > But the APUS driver is a really big "patchwork", has some problems and > needs a clean-up. And I haven't worked on the driver since a year due to > lack of time, sorry. > > I still have lack of time, but if there are any questions, I will help. It > will be nice to have a native 720/770 driver... And maybe, if someone > tries to port this driver to a PA, I have to go for it... OK. I think the right path forward here is: - I port the ncr53c8xx to use the non-coherent DMA interfaces. - Someone converts the zorro device to embed the struct device. - Someone implements the non-coherent DMA interfaces for PowerPC. - Someone adds a zorro720 driver (see NCR_Q720 and zalon for inspiration) that's simply a glue layer from zorro to ncr720. -- "It's not Hollywood. War is real, war is primarily not about defeat or victory, it is about death. I've seen thousands and thousands of dead bodies. Do you think I want to have an academic debate on this subject?" -- Robert Fisk |
|
From: Geert U. <ge...@li...> - 2003-09-30 08:21:23
|
On Tue, 30 Sep 2003, Matthew Wilcox wrote:
> - Someone converts the zorro device to embed the struct device.
I'm working on this. I have code that works on UML using a fake list of Zorro
devices, but so far I haven't modified any Zorro driver code.
BTW, A4000T SCSI is builtin, not Zorro, so we need a platform device for that.
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@li...
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
|
|
From: James B. <Jam...@st...> - 2003-09-30 13:48:28
|
On Tue, 2003-09-30 at 03:21, Geert Uytterhoeven wrote: > BTW, A4000T SCSI is builtin, not Zorro, so we need a platform device for that. That depends on how you want it to work. On parisc, the Lasi (SCSI and other) devices are technically "platform" in that they're all ASIC'd together and soldered on to the main board. However, it was easier to create a parisc_bus type and lump them all under it than to use a platform device....however, we did this in the very early days of the generic device, a platform device might be more appropriate now. James |
|
From: Matthew W. <wi...@de...> - 2003-09-30 13:59:19
|
On Tue, Sep 30, 2003 at 08:47:11AM -0500, James Bottomley wrote: > On Tue, 2003-09-30 at 03:21, Geert Uytterhoeven wrote: > > BTW, A4000T SCSI is builtin, not Zorro, so we need a platform device for that. > > That depends on how you want it to work. On parisc, the Lasi (SCSI and > other) devices are technically "platform" in that they're all ASIC'd > together and soldered on to the main board. However, it was easier to > create a parisc_bus type and lump them all under it than to use a > platform device....however, we did this in the very early days of the > generic device, a platform device might be more appropriate now. It makes a lot of sense to treat all the devices that firmware tells us about as parisc_devices since we treat them all the same way. If we were stepping over ourselves saying "well, yes, this is a pluggable device and therefore we have to access it like that, but this one's on the motherboard and therefore we treat it like that", I'd agree. But all these devices are in the same namespace, firmware tells us about all of them in the same way, so I think we should continue with the parisc_device. From a historical perspective, we've had parisc_devices in one form or another since the very start of the project. They were called hp_devices until about August 2001. See http://ftp.parisc-linux.org/patches/parisc_device-2.diff for the conversion. I don't know much about Amiga/Zorro. Maybe it'd make sense for Amiga platform devices to be faked as zorro_devices, but I doubt it. In any case, the 4000T SCSI is a 53c710, not a 720. -- "It's not Hollywood. War is real, war is primarily not about defeat or victory, it is about death. I've seen thousands and thousands of dead bodies. Do you think I want to have an academic debate on this subject?" -- Robert Fisk |
|
From: James B. <Jam...@st...> - 2003-09-30 15:33:45
|
On Tue, 2003-09-30 at 08:59, Matthew Wilcox wrote: > It makes a lot of sense to treat all the devices that firmware tells us > about as parisc_devices since we treat them all the same way. If we > were stepping over ourselves saying "well, yes, this is a pluggable > device and therefore we have to access it like that, but this one's > on the motherboard and therefore we treat it like that", I'd agree. > But all these devices are in the same namespace, firmware tells us > about all of them in the same way, so I think we should continue with > the parisc_device. Yes, I was just musing about the way we did it. In theory, the difference between a "platform" device and a generic device is that a generic device has a bus, and a platform one doesn't. The platform_device also has a resource pointer and a few other bits and pieces the generic device doesn't. What I did for PA was to create a parisc bus type, and attach all the inventoried hardware to it. This blurs the bus distinction in generic device because we have several inventoried buses: Runway, GSC, LASI etc. that are all lumped under the parisc bus. I was just wondering if it wouldn't make more sense now for us to be using platform devices too... James > >From a historical perspective, we've had parisc_devices in > one form or another since the very start of the project. > They were called hp_devices until about August 2001. See > http://ftp.parisc-linux.org/patches/parisc_device-2.diff for the > conversion. > > I don't know much about Amiga/Zorro. Maybe it'd make sense for Amiga > platform devices to be faked as zorro_devices, but I doubt it. In > any case, the 4000T SCSI is a 53c710, not a 720. > > -- > "It's not Hollywood. War is real, war is primarily not about defeat or > victory, it is about death. I've seen thousands and thousands of dead bodies. > Do you think I want to have an academic debate on this subject?" -- Robert Fisk |
|
From: Grant G. <gru...@pa...> - 2003-09-30 19:03:31
|
On Tue, Sep 30, 2003 at 10:32:23AM -0500, James Bottomley wrote: > What I did for PA was to create a parisc bus type, and attach all the > inventoried hardware to it. This blurs the bus distinction in generic > device because we have several inventoried buses: Runway, GSC, LASI etc. > that are all lumped under the parisc bus. All those busses conform to the HP IO ADC and thus could be considered the same type of bus. Except for LASI, the above makes sense to me. LASI isn't a bus. This would be a candidate for "platform device" since it's bridge-like device with integrate sub-devices. EISA bridge chips might be a similar case. > I was just wondering if it wouldn't make more sense now for us to be > using platform devices too... I don't understand "platform devices" vs "PCI devices" unless we are talking about "custom", arch specific bridge chips. A GSC device is a GSC device regardless of which board it's soldered to. That's not the case for PCI? grant |
|
From: Rene B. <re...@we...> - 2003-09-30 14:01:41
|
On 2003.09.30 04:21 Matthew Wilcox wrote: > The sym53c8xx driver doesn't support all the chips that ncr53c8xx > supported (mostly earlier chips like 810). Now there's the sym53c8xx_2 > driver that supports all the 8xx chips. In 2.6, we've now eliminated a= ll > PCI stuff from ncr53c8xx (and it should probably be renamed to ncr53c7x= x, > but I actually have a slightly different plan for renaming it that need= s > other work to happen first). Fine, the pci-stuff is removed from the driver. This makes it easier to=20 adapt the driver to non-pci machines. I have looked in the ncr53c8xx driver from 2.6 and there is mentioned tha= t=20 "interrupt on the fly" is not working correctly for 720. Also=20 sym53c8xx_defs.h is included and so the registerset from a 810 is used,=20 but the 720/770 registers are slightly different. Is the NCR_Q720 or zalon driver working? >=20 > OK. I think the right path forward here is: >=20 > - I port the ncr53c8xx to use the non-coherent DMA interfaces. > - Someone converts the zorro device to embed the struct device. > - Someone implements the non-coherent DMA interfaces for PowerPC. So, maybe I can do that at least for APUS, because some of the needed=20 interfaces I already created as a "dirty-hack" inside the 53c770 driver.=20 But the mean problem is, that there is no working 2.6 kernel for APUS...=20 The other problem is time, but maybe I find some hours on weekend... > - Someone adds a zorro720 driver (see NCR_Q720 and zalon for > inspiration) > that's simply a glue layer from zorro to ncr720. If the rest is working, something like this should not be a big problem..= . Ciao, Ren=E8 |
|
From: Matthew W. <wi...@de...> - 2003-09-30 14:33:05
|
On Tue, Sep 30, 2003 at 03:59:32PM +0200, Rene Brothuhn wrote: > I have looked in the ncr53c8xx driver from 2.6 and there is mentioned that > "interrupt on the fly" is not working correctly for 720. Also > sym53c8xx_defs.h is included and so the registerset from a 810 is used, > but the 720/770 registers are slightly different. > Is the NCR_Q720 or zalon driver working? Yes, they're both working fine. I went over the 770 register definitions the other night and only found one difference between the names of the definitions in the sym53c8xx_defs file and the 770 PDF and that was: -/*3a*/ u_char nc_sbr; +/*3a*/ u_char nc_sbr; /* dwt on 720 */ This is the DMA watchdog timer, but it's not actually used by the driver. It's a `scratch byte register' on the 895. Some of the `reserved' fields in the 770 register definition have names, but they were only ever touched if the chip was a sufficiently recent revision. BTW, I couldn't see a document for the 720 chip on the LSI site -- only the 710 and 770. I presume I won't go far wrong treating them the same. > > - Someone implements the non-coherent DMA interfaces for PowerPC. > > So, maybe I can do that at least for APUS, because some of the needed > interfaces I already created as a "dirty-hack" inside the 53c770 driver. > But the mean problem is, that there is no working 2.6 kernel for APUS... > The other problem is time, but maybe I find some hours on weekend... Yeah, no hurry. I don't think we have to get this done before 2.6.0 is out -- after all, it's only a driver. -- "It's not Hollywood. War is real, war is primarily not about defeat or victory, it is about death. I've seen thousands and thousands of dead bodies. Do you think I want to have an academic debate on this subject?" -- Robert Fisk |
|
From: Rene B. <re...@we...> - 2003-10-07 20:24:28
|
Hello! On 2003.09.30 16:32 Matthew Wilcox wrote: > On Tue, Sep 30, 2003 at 03:59:32PM +0200, Rene Brothuhn wrote: > > but the 720/770 registers are slightly different. > > Is the NCR_Q720 or zalon driver working? >=20 > Yes, they're both working fine. >=20 > I went over the 770 register definitions the other night and only found > one difference between the names of the definitions in the sym53c8xx_de= fs > file and the 770 PDF and that was: >=20 > -/*3a*/ u_char nc_sbr; > +/*3a*/ u_char nc_sbr; /* dwt on 720 */ >=20 > This is the DMA watchdog timer, but it's not actually used by the drive= r. > It's a `scratch byte register' on the 895. Some of the `reserved' > fields in the 770 register definition have names, but they were only > ever touched if the chip was a sufficiently recent revision. >=20 > BTW, I couldn't see a document for the 720 chip on the LSI site -- only > the 710 and 770. I presume I won't go far wrong treating them the same= . Sorry for reacting so late. I also have no doc for the 720, but I think=20 the differences between 770 and 720 are not so big. I'm sure there are a lot more differences between the 8xx and 720/770. No= t=20 only the registers or register names but also the bits inside some=20 registers are slightly different. I have some PDF's on which the differences between the chips are=20 described. It seems that these docs are not available anymore on the LSI=20 site. I'll send it directly to you, because the size is to much for the=20 list. I hope this will help you. I have looked into the driver a little bit last weekend and I guess it=20 should be possible to provide a 770 definition into the driver. But first= =20 I have to got a workable 2.6 kernel... Ciao, Ren=E8 |
|
From: Roman Z. <zi...@li...> - 2003-09-30 14:55:29
|
Hi, On Tue, 30 Sep 2003, Rene Brothuhn wrote: > But the mean problem is, that there is no working 2.6 kernel for APUS... That's not really true anymore, it boots here now. :-) bye, Roman |
|
From: Rene B. <re...@we...> - 2003-10-07 20:26:30
|
Hello! On 2003.09.30 16:55 Roman Zippel wrote: > Hi, >=20 > On Tue, 30 Sep 2003, Rene Brothuhn wrote: >=20 > > But the mean problem is, that there is no working 2.6 kernel for > APUS... >=20 > That's not really true anymore, it boots here now. :-) Sounds nice! Where can I get the working sources? Ciao, Ren=E8 |
Thanks for helping keep SourceForge clean.
X