sparc scsi esp depends on pci & hangs on boot

Hi ppl,

just reporting on 2.6.0-test1 on sparcs:

i am trying to compile linux-2.6.0-test1-{mm1,mm2,ac1,ac2) on 2 differents sparcs, both latest debian sid & gcc-3.2.3:

ultra enterprise 1 (sun4u sparc64)
sparc station 4 (sun4m sparc32)

on both i need to enable PCI support even when these boxes doesn't have a PCI bus, i think the main bus is SBUS and i get errors when compiling the Sun ESP scsi controller about functions for DMA depending on PCI. I don't think is convenient for these old boxes having support for PCI because enlarge the kernel and it really doesn't have that type of bus.

And when i enable PCI support the sparc32 compiles fine but hangs inmediately on boot. The sparc64 doesn't compile with ac2 patch:

arch/sparc64/kernel/built-in.o(.init.text+0x3bcc): In function `pdev_cookie_fillin':
: referencia a `pci_remove_bus_device' sin definir
make: *** [vmlinux] Error 1

The others mentioned kernels hangs when booting.

Yes, i have selected proper configuration for the CONFIG_INPUT_*=y layer, CONFIG_VT_CONSOLE=y, CONFIG_HW_CONSOLE=y and CONFIG_PROM_CONSOLE=y.

I even tried both CONFIG_FRAMEBUFFER_CONSOLE set to y/n

Any help will be apreciated as i really want the 2.6 kernels support both sparc32 and sparc64 boxes, googling i found osinvestor.com/sparc but is down and in the sparclinux archives there are patches but they appear to be applied on linus 2.6.0-test1 kernel.

Thanks.

-solca

I'll look into sparc32 problems when I get from Canada.

-- Pete

good.

converting the esp scsi driver to sbus without
pci requirement is the right step IMO. Maybe
the scsi people can comment on this.

-solca

No, the problem is that SCSI DMA transfer direction macros are defined in terms of PCI ones. That's all, it's a minor issue and probably easily solved.

these are the ofending messages:

In file included from include/asm/dma-mapping.h:1,
from include/linux/dma-mapping.h:13,
from include/scsi/scsi_cmnd.h:4,
from drivers/scsi/scsi.h:20,
from drivers/scsi/scsi.c:57:
include/asm-generic/dma-mapping.h: In function `dma_supported':
include/asm-generic/dma-mapping.h:19: `pci_bus_type' undeclared (first use in this function) include/asm-generic/dma-mapping.h:19: (Each undeclared identifier is reported only once include/asm-generic/dma-mapping.h:19: for each function it appears in.) include/asm-generic/dma-mapping.h: In function `dma_set_mask':
include/asm-generic/dma-mapping.h:27: pci_bus_type' undeclared (first use in this function) include/asm-generic/dma-mapping.h: In function dma_alloc_coherent':
include/asm-generic/dma-mapping.h:36: pci_bus_type' undeclared (first use in this function) include/asm-generic/dma-mapping.h: In function dma_free_coherent':
include/asm-generic/dma-mapping.h:45: pci_bus_type' undeclared (first use in this function) include/asm-generic/dma-mapping.h: In function dma_map_single':
include/asm-generic/dma-mapping.h:54: pci_bus_type' undeclared (first use in this function) include/asm-generic/dma-mapping.h: In function dma_unmap_single':
include/asm-generic/dma-mapping.h:63: pci_bus_type' undeclared (first use in this function) include/asm-generic/dma-mapping.h: In function dma_map_page':
include/asm-generic/dma-mapping.h:73: pci_bus_type' undeclared (first use in this function) include/asm-generic/dma-mapping.h: In function dma_unmap_page':
include/asm-generic/dma-mapping.h:82: pci_bus_type' undeclared (first use in this function) include/asm-generic/dma-mapping.h: In function dma_map_sg':
include/asm-generic/dma-mapping.h:91: pci_bus_type' undeclared (first use in this function) include/asm-generic/dma-mapping.h: In function dma_unmap_sg':
include/asm-generic/dma-mapping.h:100: pci_bus_type' undeclared (first use in this function) include/asm-generic/dma-mapping.h: In function dma_sync_single':
include/asm-generic/dma-mapping.h:109: pci_bus_type' undeclared (first use in this function) include/asm-generic/dma-mapping.h: In function dma_sync_sg':
include/asm-generic/dma-mapping.h:118: `pci_bus_type' undeclared (first use in this function) make[2]: *** [drivers/scsi/scsi.o] Error 1
make[1]: *** [drivers/scsi] Error 2
make: *** [drivers] Error 2

-solca

That's not true, there's not really any SCSI DMA transfer direction macros anymore, but scsi now uses the generic enum dma_direction directly.

Sparc unfortunately defines the new DMA API in terms of the PCI DMA API which gets you this mess.

Sparc did not do this, the person coding up the new DMA API decided it was a good idea to implement the generic version this way. :-)

I think it's rediculious that I have to implement the whole new DMA API abstraction thing just to get rid of this PCI dependency.

Why don't we put the enum dma_direction somewhere else? Some linux/foo.h header that doesn't require asm/dma*.h

Putting it into linux/dma-mapping.h is fine with me, but I expect to see more users of the dma-mapping API soon..

And unlike this particular scsi layer usage, such drivers will be dependant upon things like CONFIG_PCI and thus won't get compiled in unless CONFIG_PCI has been enabled in the kernel configuration.

The enumeration can go into some common area that doesn't care about the dma-mapping.h actual implementation.

And linux/dma-mapping.h is a bad name to use, call it dma-dir.h or something, because linux/dma-mapping.h would need to include asm/dma-mapping.h which is what we're trying to avoid here.

Umm, no. The whole idea of the DMA mapping API is that it's independant of the underlying bus. Think of usb or ieee1394 drivers doing direct DMA independant of the bus the underlying host adapter uses.

We don't try to avoid that. You should at least make them sparc dma mapping API noops for !CONFIG_PCI because it's assume you always include the header - whether you can actually use the functionaly depends on whether your bus supports this API.

No USB or IEEE1394 on SBUS sparcs, so again no problem.

My point still holds, please put this enumeration into a truly generic place that doesn't depend upon the actual implementation.

linux/dma-dir.h or even linux/device.h seem the most logical place (we put the PCI ones in pci.h, and pci.h can be included cleanly even when CONFIG_PCI is disabled, consider that), then we make linux/dma-mapping.h and scsi/scsi_{cmnd,request}.h include this linux/{device,dma-dir}.h file.

I don't see why this is a problem. Either do this, or fix asm-generic/dma-mapping.h which is not GENERIC because it depends upon something SPECIFIC, specifically PCI.

The latter is what need to be done.

I'll do the following for now.

# This is a BitKeeper generated patch for the following project:
# Project Name: Linux kernel tree
# This patch format is intended for GNU patch command version 2.5 or higher. # This patch includes the following deltas:
# ChangeSet 1.1518 -> 1.1519
# include/asm-sparc64/dma-mapping.h 1.1 -> 1.2
# include/asm-sparc/dma-mapping.h 1.1 -> 1.2
#
# The following is the BitKeeper ChangeSet Log
# --------------------------------------------
# 03/07/23 [email protected] 1.1519
# [SPARC]: Do not include asm-generic/dma-mapping.h if !CONFIG_PCI. # --------------------------------------------
#

diff -Nru a/include/asm-sparc/dma-mapping.h b/include/asm-sparc/dma-mapping.h
@@ -1 +1,5 @@
+#include <linux/config.h>
+
+#ifdef CONFIG_PCI
 #include <asm-generic/dma-mapping.h>
+#endif

diff -Nru a/include/asm-sparc64/dma-mapping.h b/include/asm-sparc64/dma-mapping.h
@@ -1 +1,5 @@
+#include <linux/config.h>
+
+#ifdef CONFIG_PCI
 #include <asm-generic/dma-mapping.h>
+#endif

FYI i had compile both sparc32/sparc64 with these patch and finally that fu**ing PCI dependency is gone! thank you :)

This should be done in asm-generic/dma-mapping.h IMHO with others archs in mind.

-solca

Yep, that's what I did for m68k as well (inspired by s390 which never has PCI and thus an empty dma-mapping.h).

Gr{oetje,eeting}s,

Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- [email protected]

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

I originally though the whole idea was to remove the PCI dependency.

-solca

There is no pci depency in the scsi core or drivers. The only problem is that the dma-mapping.h implementation used by sparc imposes an artifical PCI depency that needs to be removed.

If you want to help fix asm-generic/dma-mapping.h to be noops if !CONFIG_PCI or even better make it always noops and add an asm-generic/dma-mapping-in-terms-of-pci.h for those who want them to map to PCI.

if !CONFIG_PCI -> noops
else include asm-generic/dma-mapping.h

That seems doable, but..
just arm, i386 & parisc have their own dma-mapping.h everything else includes the generic one (pci dependant). With this model what happens if a box had more than one bus type (if technically possible)?

-solca

If the architecture wants to support such situations, then the implementation needs to vector off to different operations based upon the actual bus type.

Even though technically devices having SBUS and PCI variants could do this, none do currently, and also I do not use the generic device model in the SBUS layer, therefore I'm not going to add such multi-bus support to what Sparc uses for dma-mapping.h

If someone is bored and willing to do all of the generic device and ->dma_ops work for Sparc and SBUS, feel free to send me some patches. Otherwise, it won't get done :-)

Ouch - As I mentioned a few days ago, the Ex000 range can have a mixture of SBUS and PCI. This configuration is becoming increasingly common as these machines are upgraded to attach to SAN stuff and other FCAL variants for which there is no SBUS card.

Please take a few moments to keep this, it works at the moment.

So what?

Nothing I have said prevents these systems from fully working.

Because I won't move SBUS over to generic struct device, none of the SBUS device drivers will change either, therefore everything works as it does today.

What's the problem?

In that case none, but your original message implied that this did not exist and would not be supported.

Maybe I misunderstood what you meant.

OTOH, (if !SBUS) might screw up ?.

Look, SBUS does _NOT_ use the generic device abstraction. Therefore all SBUS drivers call into the sbus_* DMA operations directly.

Everything just works, as it always has, and it's not going to break any time soon.

What I'm saying is that I'm not going to move the SBUS layer over to use generic devices.

ok, i understand now. Theorically could be nice the new API, i better stick with the current per-bus-drivers.

:) fine with me.

-solca