Hello,
I have uploaded 2 patches against latest kernels 2.4.13 and 2.2.20.
ftp://ftp.tux.org/pub/roudier/drivers/linux/experimental/sym-2.1.16a-for-linux-2.4.13.patch.gz
ftp://ftp.tux.org/pub/roudier/drivers/linux/experimental/sym-2.1.16b-for-linux-2.2.20.patch.gz
Btw, the patches are experimental but the driver that is embedded in them
should work just fine. :-)
The patch against linux-2.4.13 has been sent to Alan Cox for inclusion in
newer stable kernels. Alan wants to test it on his machines which is a
good thing. Anyway, those patches just add the new driver version to
kernel tree and leave stock sym53c8xx and ncr53c8xx in place.
Any report, especially on large memory machines using 64 bit DMA (2.4
kernels + PCI DAC capable controllers only), is welcome. I can't test 64
bit DMA, since my fatest machine has only 512 MB of memory.
To configure the driver, you must select "SYM53C8XX version 2 driver" from
kernel config. For large memory machines, a new "DMA addressing mode"
option is to be configured as follows (help texts have been added to
Configure.help):
Value 0: 32 bit DMA addressing
Value 1: 40 bit DMA addressing (upper 24 bytes set to zero)
Value 2: 64 bit DMA addressing limited to 16 segments of 4 GB (64 GB) max.
G?rard.
G?rard Roudier wrote:
> The patch against linux-2.4.13 has been sent to Alan Cox for inclusion in
> newer stable kernels. Alan wants to test it on his machines which is a
> good thing. Anyway, those patches just add the new driver version to
> kernel tree and leave stock sym53c8xx and ncr53c8xx in place.
Are the older sym/ncr drivers going away in 2.5?
> Any report, especially on large memory machines using 64 bit DMA (2.4
> kernels + PCI DAC capable controllers only), is welcome. I can't test 64
> bit DMA, since my fatest machine has only 512 MB of memory.
>
> To configure the driver, you must select "SYM53C8XX version 2 driver" from
> kernel config. For large memory machines, a new "DMA addressing mode"
> option is to be configured as follows (help texts have been added to
> Configure.help):
>
> Value 0: 32 bit DMA addressing
> Value 1: 40 bit DMA addressing (upper 24 bytes set to zero)
> Value 2: 64 bit DMA addressing limited to 16 segments of 4 GB (64 GB) max.
Are you using the new pci64 API under 2.4.x?
Thanks,
Jeff
--
Jeff Garzik | Only so many songs can be sung
Building 1024 | with two lips, two lungs, and one tongue.
MandrakeSoft | - nomeansno
On Sun, 4 Nov 2001, Jeff Garzik wrote:
> G?rard Roudier wrote:
> > The patch against linux-2.4.13 has been sent to Alan Cox for inclusion in
> > newer stable kernels. Alan wants to test it on his machines which is a
> > good thing. Anyway, those patches just add the new driver version to
> > kernel tree and leave stock sym53c8xx and ncr53c8xx in place.
>
> Are the older sym/ncr drivers going away in 2.5?
>
>
> > Any report, especially on large memory machines using 64 bit DMA (2.4
> > kernels + PCI DAC capable controllers only), is welcome. I can't test 64
> > bit DMA, since my fatest machine has only 512 MB of memory.
> >
> > To configure the driver, you must select "SYM53C8XX version 2 driver" from
> > kernel config. For large memory machines, a new "DMA addressing mode"
> > option is to be configured as follows (help texts have been added to
> > Configure.help):
> >
> > Value 0: 32 bit DMA addressing
> > Value 1: 40 bit DMA addressing (upper 24 bytes set to zero)
> > Value 2: 64 bit DMA addressing limited to 16 segments of 4 GB (64 GB) max.
>
> Are you using the new pci64 API under 2.4.x?
Didn't see any. Only the dma_addr_t thing can be 32 bit or 64 bit
depending on some magic. Apart this, the driver is asking for the
appropriate dma mask given the configured dma adressing mode.
G?rard.
PS: There is some pci64* API on some arch., but nobody will want to
ever use it, in my opinion.
I missed to reply to your 1rst question.
On Sun, 4 Nov 2001, Jeff Garzik wrote:
> G?rard Roudier wrote:
> > The patch against linux-2.4.13 has been sent to Alan Cox for inclusion in
> > newer stable kernels. Alan wants to test it on his machines which is a
> > good thing. Anyway, those patches just add the new driver version to
> > kernel tree and leave stock sym53c8xx and ncr53c8xx in place.
>
> Are the older sym/ncr drivers going away in 2.5?
There is no valuable reasons to remove them in a hurry. But sym version 2
is intended to be a replacement of those both old driver versions. This
has to be proven so prior to removing previous stuff, in my opinion. Note
that Linus may decide differently, but for now he has accepted redundant
drivers in his tree (some seems even to stay here forever:-) ).
[...]
Regards,
G?rard.
On Sun, Nov 04 2001, G?rard Roudier wrote:
>
>
> On Sun, 4 Nov 2001, Jeff Garzik wrote:
>
> > G?rard Roudier wrote:
> > > The patch against linux-2.4.13 has been sent to Alan Cox for inclusion in
> > > newer stable kernels. Alan wants to test it on his machines which is a
> > > good thing. Anyway, those patches just add the new driver version to
> > > kernel tree and leave stock sym53c8xx and ncr53c8xx in place.
> >
> > Are the older sym/ncr drivers going away in 2.5?
> >
> >
> > > Any report, especially on large memory machines using 64 bit DMA (2.4
> > > kernels + PCI DAC capable controllers only), is welcome. I can't test 64
> > > bit DMA, since my fatest machine has only 512 MB of memory.
> > >
> > > To configure the driver, you must select "SYM53C8XX version 2 driver" from
> > > kernel config. For large memory machines, a new "DMA addressing mode"
> > > option is to be configured as follows (help texts have been added to
> > > Configure.help):
> > >
> > > Value 0: 32 bit DMA addressing
> > > Value 1: 40 bit DMA addressing (upper 24 bytes set to zero)
> > > Value 2: 64 bit DMA addressing limited to 16 segments of 4 GB (64 GB) max.
> >
> > Are you using the new pci64 API under 2.4.x?
>
> Didn't see any. Only the dma_addr_t thing can be 32 bit or 64 bit
> depending on some magic. Apart this, the driver is asking for the
> appropriate dma mask given the configured dma adressing mode.
I've looked over the sym-2 and it is using pci_map_sg so it's 64-bit
safe for sg transfers at least. For non-sg requests you are using
pci_map_single, but you can't do any better because the mid layer is
handing you virtual addresses in request_buffer currently anyways...
> PS: There is some pci64* API on some arch., but nobody will want to
> ever use it, in my opinion.
You are doing it right :-)
--
Jens Axboe
On Sun, 4 Nov 2001, Jens Axboe wrote:
> On Sun, Nov 04 2001, G?rard Roudier wrote:
> >
> >
> > On Sun, 4 Nov 2001, Jeff Garzik wrote:
> >
> > > G?rard Roudier wrote:
> > > > The patch against linux-2.4.13 has been sent to Alan Cox for inclusion in
> > > > newer stable kernels. Alan wants to test it on his machines which is a
> > > > good thing. Anyway, those patches just add the new driver version to
> > > > kernel tree and leave stock sym53c8xx and ncr53c8xx in place.
> > >
> > > Are the older sym/ncr drivers going away in 2.5?
> > >
> > >
> > > > Any report, especially on large memory machines using 64 bit DMA (2.4
> > > > kernels + PCI DAC capable controllers only), is welcome. I can't test 64
> > > > bit DMA, since my fatest machine has only 512 MB of memory.
> > > >
> > > > To configure the driver, you must select "SYM53C8XX version 2 driver" from
> > > > kernel config. For large memory machines, a new "DMA addressing mode"
> > > > option is to be configured as follows (help texts have been added to
> > > > Configure.help):
> > > >
> > > > Value 0: 32 bit DMA addressing
> > > > Value 1: 40 bit DMA addressing (upper 24 bytes set to zero)
> > > > Value 2: 64 bit DMA addressing limited to 16 segments of 4 GB (64 GB) max.
> > >
> > > Are you using the new pci64 API under 2.4.x?
> >
> > Didn't see any. Only the dma_addr_t thing can be 32 bit or 64 bit
> > depending on some magic. Apart this, the driver is asking for the
> > appropriate dma mask given the configured dma adressing mode.
>
> I've looked over the sym-2 and it is using pci_map_sg so it's 64-bit
> safe for sg transfers at least. For non-sg requests you are using
> pci_map_single, but you can't do any better because the mid layer is
> handing you virtual addresses in request_buffer currently anyways...
If there is some platform-specific thing that allows to handle map_single
more right:), I can go with it. Would be fine to get IA64 and Alpha
actually PCI-64 bit safe even by using some software shoehorn for that. :)
> > PS: There is some pci64* API on some arch., but nobody will want to
> > ever use it, in my opinion.
>
> You are doing it right :-)
You mean as right as possible? :)
G?rard.
On Sun, Nov 04 2001, G?rard Roudier wrote:
> > > Didn't see any. Only the dma_addr_t thing can be 32 bit or 64 bit
> > > depending on some magic. Apart this, the driver is asking for the
> > > appropriate dma mask given the configured dma adressing mode.
> >
> > I've looked over the sym-2 and it is using pci_map_sg so it's 64-bit
> > safe for sg transfers at least. For non-sg requests you are using
> > pci_map_single, but you can't do any better because the mid layer is
> > handing you virtual addresses in request_buffer currently anyways...
>
> If there is some platform-specific thing that allows to handle map_single
> more right:), I can go with it. Would be fine to get IA64 and Alpha
> actually PCI-64 bit safe even by using some software shoehorn for that. :)
IA64 and Alpha is fine, the problem with the non-sg request is just
32-bit archs with highmem support. For that we need to pass in
page/offset values instead of a virtual address.
> > > PS: There is some pci64* API on some arch., but nobody will want to
> > > ever use it, in my opinion.
> >
> > You are doing it right :-)
>
> You mean as right as possible? :)
Indeed :-)
--
Jens Axboe
On Mon, 5 Nov 2001, Jens Axboe wrote:
> IA64 and Alpha is fine, the problem with the non-sg request is just
> 32-bit archs with highmem support. For that we need to pass in
> page/offset values instead of a virtual address.
So, all targetted platforms should be just fine. :)
I donnot like a lot highmem things, but I would want those ones to be fine
too with 64 bit DMA, at least in theory. Will try to understand the
related stuff from kernel 2.4.13.
Thanks a lot for the clarification.
G?rard.