Re: [PATCH 4/8] FMC: add documentation for the core
> Acked-by: Rob Landley Thanks. > What is this *note thingy:: syntax? It recurs a lot. Some sort of > reference into the PDF you started out with a link to, maybe? My documentation is texinfo and this is the ASCII output, manually split into different files. I fixed some of the internal references when I noted them. But since it's manual work, I didn't do it carefully. I suspect I'll need to V2 for some reason anyways. > A basic concept of this framework is that you have a 70x75 PCB? Is this > part of that ANSI-VITA standard? Yes. the form-factor is fixed, like PC104 in the PC world. Here's the jpg of a carrier: http://www.ohwr.org/attachments/download/552 (from http://www.ohwr.org/projects/spec/wiki). And here's the jpg of a mezzanine: http://www.ohwr.org/attachments/download/833/FmcAdc100M14b4cha_top_small.JPG You find more on the net, also from commercial vendors. >> +FMC, as such, is not a bus in the usual meaning of the term, because >> +most carriers have only one connector, and carriers with several >> +connectors have completely separate electrical connections to them. >> +This package, however, implements a bus as a software abstraction. > > USB is point to point connections with switches in between. It's still > got B in the acronym. I'm not sure what you're saying here. FMC has no switches, no hotplug, not even shared wires like ISA. I took a while to explain some hardware guys that it ought to be a "bus" in software. That's why I have the paragraph. >> +What is SDB >> +*** >> + >> +SDB (Self Describing Bus) is a set of data structures that we use for >> +enumerating the internal structure of an FPGA image. We also use it >> as >> +a filesystem inside the FMC EEPROM. > > Are you trying to document infrastructure to implement a standard, or a > bespoke driver for a specific piece of hardware? How much of this is > generic? Are there other vendors who might someday want to use this > code? SDB is already implemented and is generic. We enumerate the devices inside the FPGA already, and it only costs a few lines of VHDL (using the support files by Wesley Terpstra) to describe your own FPGA design. Wesley even discovers and enumerates devices over the Ethernet, by means of Ethernet-driven device access and SDB-aware host code -- all code is published. The SDB specification is discussed in a mailing list and is public (http://www.ohwr.org/attachments/download/1486/sdb-1.0.pdf). By having 64-bit vendor identifiers we encourage anyone who finds SDB useful to become a vendor. There are a few vendors already, although I admit the early adopters are involved in the same set of projects. > Anyway, no serious objection, but I note that reading to this point I > didn't feel I had enough information to wrap my head around what it's > for. It's documentation by people who already know this stuff, for > people who already know this stuff. (There's a long tradition of that. > Oh well.) I'm aware of this. But it's the same if you read USB documentation without ever seeing one such device (I remember the feeling :). FMC is not common on the shelf, but it is already renown in high-profile I/O environments. Thanks /alessandro -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
tip/x86/amba
Hello Peter and maintainers. I wonder what are the plans for the branch x86/amba, part of the tip repository. Of the 7 patches in that branch, 2 are already upstream and the other 5 rebase perfectly (only conflicts are in the header stanzas). This is the reverse log from next to my current working tree: 0e7e31f DMA: PL330: use prefix in reg names to build under x86 1e8486a watchdog: sp805_wdt depends on ARM 6417077 mmc: Use the new 52b9f4e drivers/amba: add support for a PCI bridge d8d2313 x86: add CONFIG_ARM_AMBA, selected by STA2X11 They all have the proper acked and signed-off, as well as references to the original mailing list message by my mate Davide who submitted them. Shall I just wait for you to merge or shall I repost to the mailing lists? In the latte case, with or without the various ack/signoff? Thanks /alessandro -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: tip/x86/amba
>> I wonder what are the plans for the branch x86/amba, part of the tip >> repository. Of the 7 patches in that branch, 2 are already upstream >> and the other 5 rebase perfectly (only conflicts are in the header >> stanzas). This is the reverse log from next to my current working tree: >> >> 0e7e31f DMA: PL330: use prefix in reg names to build under x86 >> 1e8486a watchdog: sp805_wdt depends on ARM >> 6417077 mmc: Use the new >> 52b9f4e drivers/amba: add support for a PCI bridge >> d8d2313 x86: add CONFIG_ARM_AMBA, selected by STA2X11 > We have been waiting for you to sort out the breakages and let us know > that the problems has been resolved. Sorry, [...] Nothing to be sorry. Thanks for you patience. > What are the upstream commits? These are the ones in your branch: morgana% gitlog --reverse master..tip/x86/amba e4093bd DMA: PL330: use prefix in reg names to build under x86 f5cfd23 pl080.h: moved from arm/include/asm/hardware to include/linux/amba/ f449ac1 watchdog: sp805_wdt depends on ARM ab189b1 mmci: replace readsl/writesl with ioread32_rep/iowrite32_rep e61094e mmc: Use the new e7c1371 drivers/amba: add support for a PCI bridge 5be5a01 x86: add CONFIG_ARM_AMBA, selected by STA2X11 Of those I see one in next (through the slave-dma/next branch): 3a95b9f pl080.h: moved from arm/include/asm/hardware to include/linux/amba/ and one in master: 4b85da0 ARM: 7596/1: mmci: replace readsl/writesl with ioread32_rep/iowrite32_rep For the other ones the conflicts are only in the #include stanzas. Even with current master No error or warning is then when enabling CONFIG_ARM_AMBA under x86, even replying y or m to every new question. (There are two sta2x11 warnings, unrelated to amba, that I'll post a fix for RSN). Shall I repost the current version, send privately or have them somewhere for you to pull from? Thanks /alessandro -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH V5 1/5] DMA: PL330: use prefix in reg names to build under x86
This driver would not compile if ARM_AMBA is selected under x86,
because "CS" and "DS" are already defined there. But AMBA
is used in the x86 world by a PCI-to-AMBA bridge, to be submitted.
The patch just adds the "PL330_" prefix to all registers,
so it can be built by randomconfig after ARM_AMBA appears within x86.
No other technical changes have been performed.
The patch was build-tested only.
Signed-off-by: Alessandro Rubini
Acked-by: Giancarlo Asnaghi
Signed-off-by: Davide Ciminaghi
Acked-by: Jassi Brar
Signed-off-by: H. Peter Anvin
---
@Jassi: I repost this after rebasing, on hpa's suggestion.
drivers/dma/pl330.c | 107 ++-
1 files changed, 54 insertions(+), 53 deletions(-)
diff --git a/drivers/dma/pl330.c b/drivers/dma/pl330.c
index 7181531..b45cbe0 100644
--- a/drivers/dma/pl330.c
+++ b/drivers/dma/pl330.c
@@ -70,7 +70,7 @@ enum pl330_reqtype {
};
/* Register and Bit field Definitions */
-#define DS 0x0
+#define PL330_DS 0x0
#define DS_ST_STOP 0x0
#define DS_ST_EXEC 0x1
#define DS_ST_CMISS0x2
@@ -84,33 +84,33 @@ enum pl330_reqtype {
#define DS_ST_FLTCMP 0xe
#define DS_ST_FAULT0xf
-#define DPC0x4
-#define INTEN 0x20
-#define ES 0x24
-#define INTSTATUS 0x28
-#define INTCLR 0x2c
-#define FSM0x30
-#define FSC0x34
-#define FTM0x38
+#define PL330_DPC 0x4
+#define PL330_INTEN0x20
+#define PL330_ES 0x24
+#define PL330_INTSTATUS0x28
+#define PL330_INTCLR 0x2c
+#define PL330_FSM 0x30
+#define PL330_FSC 0x34
+#define PL330_FTM 0x38
#define _FTC 0x40
-#define FTC(n) (_FTC + (n)*0x4)
+#define PL330_FTC(n) (_FTC + (n)*0x4)
#define _CS0x100
-#define CS(n) (_CS + (n)*0x8)
+#define PL330_CS(n)(_CS + (n)*0x8)
#define CS_CNS (1 << 21)
#define _CPC 0x104
-#define CPC(n) (_CPC + (n)*0x8)
+#define PL330_CPC(n) (_CPC + (n)*0x8)
#define _SA0x400
-#define SA(n) (_SA + (n)*0x20)
+#define PL330_SA(n)(_SA + (n)*0x20)
#define _DA0x404
-#define DA(n) (_DA + (n)*0x20)
+#define PL330_DA(n)(_DA + (n)*0x20)
#define _CC0x408
-#define CC(n) (_CC + (n)*0x20)
+#define PL330_CC(n)(_CC + (n)*0x20)
#define CC_SRCINC (1 << 0)
#define CC_DSTINC (1 << 14)
@@ -131,24 +131,24 @@ enum pl330_reqtype {
#define CC_SWAP_SHFT 28
#define _LC0 0x40c
-#define LC0(n) (_LC0 + (n)*0x20)
+#define PL330_LC0(n) (_LC0 + (n)*0x20)
#define _LC1 0x410
-#define LC1(n) (_LC1 + (n)*0x20)
+#define PL330_LC1(n) (_LC1 + (n)*0x20)
-#define DBGSTATUS 0xd00
+#define PL330_DBGSTATUS0xd00
#define DBG_BUSY (1 << 0)
-#define DBGCMD 0xd04
-#define DBGINST0 0xd08
-#define DBGINST1 0xd0c
+#define PL330_DBGCMD 0xd04
+#define PL330_DBGINST0 0xd08
+#define PL330_DBGINST1 0xd0c
-#define CR00xe00
-#define CR10xe04
-#define CR20xe08
-#define CR30xe0c
-#define CR40xe10
-#define CRD0xe14
+#define PL330_CR0 0xe00
+#define PL330_CR1 0xe04
+#define PL330_CR2 0xe08
+#define PL330_CR3 0xe0c
+#define PL330_CR4 0xe10
+#define PL330_CRD 0xe14
#define PERIPH_ID 0xfe0
#define PERIPH_REV_SHIFT 20
@@ -1022,7 +1022,7 @@ static bool _until_dmac_idle(struct pl330_thread *thrd)
do {
/* Until Manager is Idle */
- if (!(readl(regs + DBGSTATUS) & DBG_BUSY))
+ if (!(readl(regs + PL330_DBGSTATUS) & DBG_BUSY))
break;
cpu_relax();
@@ -1045,10 +1045,10 @@ static inline void _execute_DBGINSN(struct pl330_thread
*thrd,
val |= (1 << 0);
val |= (thrd->id << 8); /* Channel Number */
}
- writel(val, regs + DBGINST0);
+ writel(val, regs + PL330_DBGINST0);
val = *((u32 *)&insn[2]);
- writel(val, regs + DBGINST1);
+ writel(val, regs + PL330_DBGINST1);
/* If timed out due to halted state-machine */
if (_until_dmac_idle(thrd)) {
@@ -1057,7 +1057,7 @@ static inl
[PATCH V5 0/5] x86: a bridge from PCI to AMBA
This is a repost of patches I sent quite some time ago and are available from the "tip" repository, as branch "x86/amba" based on v3.7. That branch includes 7 patches but two of them are already upstream. Some of the other 5 had minor conflicts during rebase, but only in the initial "#include" area. I repost as Peter Anvin suggested. The commits in the tip repository included both hpa's signed off (which I left in) and the reference to the previous lkml message, which I removed as it is not current by the time this message exists. Some acked-by we received on the mailing list are not in the patch set because they are missing from tip::x86/amba which is authoritative. Alessandro Rubini (5): DMA: PL330: use prefix in reg names to build under x86 watchdog: sp805_wdt depends on ARM mmc: Use the new drivers/amba: add support for a PCI bridge x86: add CONFIG_ARM_AMBA, selected by STA2X11 arch/x86/Kconfig|4 ++ drivers/Kconfig |2 + drivers/amba/Kconfig| 10 drivers/amba/Makefile |1 + drivers/amba/pci-amba.c | 93 + drivers/dma/pl330.c | 107 ++- drivers/mmc/host/mmci.c |2 +- drivers/mmc/host/msm_sdcc.c |2 +- drivers/mmc/host/mvsdio.c |2 +- drivers/mmc/host/mxcmmc.c |2 +- drivers/mmc/host/pxamci.c |3 +- drivers/watchdog/Kconfig|2 +- 12 files changed, 170 insertions(+), 60 deletions(-) create mode 100644 drivers/amba/Kconfig create mode 100644 drivers/amba/pci-amba.c -- 1.7.7.2 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH V5 3/5] mmc: Use the new
For portability, use . Signed-off-by: Alessandro Rubini Acked-by: Giancarlo Asnaghi Acked-by: David Brown Signed-off-by: H. Peter Anvin --- @David: I repost this after rebasing, on hpa's suggestion. drivers/mmc/host/mmci.c |2 +- drivers/mmc/host/msm_sdcc.c |2 +- drivers/mmc/host/mvsdio.c |2 +- drivers/mmc/host/mxcmmc.c |2 +- drivers/mmc/host/pxamci.c |3 +-- 5 files changed, 5 insertions(+), 6 deletions(-) diff --git a/drivers/mmc/host/mmci.c b/drivers/mmc/host/mmci.c index 372e921..a47aa70 100644 --- a/drivers/mmc/host/mmci.c +++ b/drivers/mmc/host/mmci.c @@ -34,11 +34,11 @@ #include #include #include +#include #include #include #include -#include #include "mmci.h" diff --git a/drivers/mmc/host/msm_sdcc.c b/drivers/mmc/host/msm_sdcc.c index 7c0af0e..aa61b79 100644 --- a/drivers/mmc/host/msm_sdcc.c +++ b/drivers/mmc/host/msm_sdcc.c @@ -37,10 +37,10 @@ #include #include #include +#include #include #include -#include #include #include diff --git a/drivers/mmc/host/mvsdio.c b/drivers/mmc/host/mvsdio.c index 145cdaf..53a1224 100644 --- a/drivers/mmc/host/mvsdio.c +++ b/drivers/mmc/host/mvsdio.c @@ -23,11 +23,11 @@ #include #include #include +#include #include #include #include -#include #include #include diff --git a/drivers/mmc/host/mxcmmc.c b/drivers/mmc/host/mxcmmc.c index a72936e..8ce7e73 100644 --- a/drivers/mmc/host/mxcmmc.c +++ b/drivers/mmc/host/mxcmmc.c @@ -34,10 +34,10 @@ #include #include #include +#include #include #include -#include #include #include diff --git a/drivers/mmc/host/pxamci.c b/drivers/mmc/host/pxamci.c index 2b2f65a..6fa54a9 100644 --- a/drivers/mmc/host/pxamci.c +++ b/drivers/mmc/host/pxamci.c @@ -33,8 +33,7 @@ #include #include #include - -#include +#include #include #include -- 1.7.7.2 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH V5 2/5] watchdog: sp805_wdt depends on ARM
The SP805 driver is only used by the Spear machines, and uses writel_relaxed, which is not available on all architectures. The dependency from CONFIG_ARM avoids compilation problems under randomconfig when CONFIG_ARM_AMBA is enabled for x86 builds. Signed-off-by: Alessandro Rubini Acked-by: Giancarlo Asnaghi Signed-off-by: Davide Ciminaghi Acked-by: Wim Van Sebroeck Signed-off-by: H. Peter Anvin --- @Wim: I repost this after rebasing, on hpa's suggestion. drivers/watchdog/Kconfig |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/drivers/watchdog/Kconfig b/drivers/watchdog/Kconfig index 83ac1f7..e89fc31 100644 --- a/drivers/watchdog/Kconfig +++ b/drivers/watchdog/Kconfig @@ -109,7 +109,7 @@ config WM8350_WATCHDOG config ARM_SP805_WATCHDOG tristate "ARM SP805 Watchdog" - depends on ARM_AMBA + depends on ARM && ARM_AMBA select WATCHDOG_CORE help ARM Primecell SP805 Watchdog timer. This will reboot your system when -- 1.7.7.2 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH V5 5/5] x86: add CONFIG_ARM_AMBA, selected by STA2X11
The sta2x11 I/O Hub is a bridge from PCIe to AMBA. It reuses a number of amba drivers and needs to activate core bus support. Signed-off-by: Alessandro Rubini Acked-by: Giancarlo Asnaghi Signed-off-by: H. Peter Anvin --- arch/x86/Kconfig |4 1 files changed, 4 insertions(+), 0 deletions(-) diff --git a/arch/x86/Kconfig b/arch/x86/Kconfig index b11f082..fc06c25 100644 --- a/arch/x86/Kconfig +++ b/arch/x86/Kconfig @@ -548,6 +548,7 @@ config STA2X11 select SWIOTLB select MFD_STA2X11 select ARCH_REQUIRE_GPIOLIB + select ARM_AMBA default n ---help--- This adds support for boards based on the STA2X11 IO-Hub, @@ -2271,6 +2272,9 @@ config TS5500 endif # X86_32 +config ARM_AMBA +bool + config AMD_NB def_bool y depends on CPU_SUP_AMD && PCI -- 1.7.7.2 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH V5 4/5] drivers/amba: add support for a PCI bridge
This is a PCI driver that registers AMBA devices for the range of
supported devices. It is currently used by STA2X11, which exports
AMBA peripherals under PCIe. The original AMBA drivers work with no
changes or minimal ones.
Signed-off-by: Alessandro Rubini
Acked-by: Giancarlo Asnaghi
Cc: Russell King
Cc: Alan Cox
Signed-off-by: H. Peter Anvin
---
@Russell, Alan: I repost this after rebasing, on hpa's suggestion.
drivers/Kconfig |2 +
drivers/amba/Kconfig| 10 +
drivers/amba/Makefile |1 +
drivers/amba/pci-amba.c | 93 +++
4 files changed, 106 insertions(+), 0 deletions(-)
create mode 100644 drivers/amba/Kconfig
create mode 100644 drivers/amba/pci-amba.c
diff --git a/drivers/Kconfig b/drivers/Kconfig
index 202fa6d..e17144d 100644
--- a/drivers/Kconfig
+++ b/drivers/Kconfig
@@ -162,4 +162,6 @@ source "drivers/irqchip/Kconfig"
source "drivers/ipack/Kconfig"
+source "drivers/amba/Kconfig"
+
endmenu
diff --git a/drivers/amba/Kconfig b/drivers/amba/Kconfig
new file mode 100644
index 000..b5b5aca
--- /dev/null
+++ b/drivers/amba/Kconfig
@@ -0,0 +1,10 @@
+
+config PCI_AMBA
+ tristate "PCI-to-AMBA bridge"
+ depends on ARM_AMBA && PCI
+ ---help---
+ This compiles a PCI driver that registers AMBA devices, so
+ the respective AMBA driver can be used unchanged if you have
+ a PCI to amba bridge. This is required for STA2X11 support.
+
+ If uncertain, choose N.
diff --git a/drivers/amba/Makefile b/drivers/amba/Makefile
index 66e81c2..d30e947 100644
--- a/drivers/amba/Makefile
+++ b/drivers/amba/Makefile
@@ -1,2 +1,3 @@
obj-$(CONFIG_ARM_AMBA) += bus.o
+obj-$(CONFIG_PCI_AMBA) += pci-amba.o
obj-$(CONFIG_TEGRA_AHB)+= tegra-ahb.o
diff --git a/drivers/amba/pci-amba.c b/drivers/amba/pci-amba.c
new file mode 100644
index 000..ff46575
--- /dev/null
+++ b/drivers/amba/pci-amba.c
@@ -0,0 +1,93 @@
+/*
+ * Support for AMBA devices (both APB and AHB) behind a PCI bridge
+ * Copyright 2012 ST Microelectronics (Alessandro Rubini)
+ * GNU GPL version 2.
+ */
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+static int pci_amba_probe(struct pci_dev *pdev,
+const struct pci_device_id *id)
+{
+ struct amba_device *adev;
+ char *name;
+ int ret;
+
+ pci_enable_msi(pdev);
+ ret = pci_enable_device(pdev);
+ if (ret)
+ return ret;
+
+ /* Create a name: each of them must be different */
+ name = devm_kzalloc(&pdev->dev, strlen(dev_name(&pdev->dev)) + 6,
+ GFP_KERNEL);
+ sprintf(name, "amba-%s", dev_name(&pdev->dev));
+
+ /* Simply build an amba device and register it */
+ adev = amba_device_alloc(name, pdev->resource[0].start, SZ_4K);
+ if (!adev)
+ return -ENOMEM;
+ adev->irq[0] = pdev->irq;
+
+ /* This bridge can host both APB and AHB devices, so set master */
+ pci_set_master(pdev);
+ if (pdev->vendor == PCI_VENDOR_ID_STMICRO) {
+ /* Under sta2x11, DMA is there but limited to 512M */
+ adev->dma_mask = SZ_512M - 1;
+ adev->dev.coherent_dma_mask = SZ_512M - 1;
+ }
+
+ adev->dev.platform_data = pdev->dev.platform_data;
+ pci_set_drvdata(pdev, adev);
+
+ return amba_device_add(adev, &pdev->resource[0]);
+};
+
+static void pci_amba_remove(struct pci_dev *pdev)
+{
+ struct amba_device *adev = pci_get_drvdata(pdev);
+ amba_device_unregister(adev);
+ pci_disable_msi(pdev);
+}
+
+static DEFINE_PCI_DEVICE_TABLE(pci_amba_table) = {
+ {PCI_VDEVICE(STMICRO, PCI_DEVICE_ID_STMICRO_UART_HWFC)},
+ {PCI_VDEVICE(STMICRO, PCI_DEVICE_ID_STMICRO_UART_NO_HWFC)},
+ {PCI_VDEVICE(STMICRO, PCI_DEVICE_ID_STMICRO_SOC_DMA)},
+ {PCI_VDEVICE(STMICRO, PCI_DEVICE_ID_STMICRO_I2C)},
+ {PCI_VDEVICE(STMICRO, PCI_DEVICE_ID_STMICRO_SPI_HS)},
+ {PCI_VDEVICE(STMICRO, PCI_DEVICE_ID_STMICRO_SDIO_EMMC)},
+ {PCI_VDEVICE(STMICRO, PCI_DEVICE_ID_STMICRO_SDIO)},
+ {PCI_VDEVICE(STMICRO, PCI_DEVICE_ID_STMICRO_AUDIO_ROUTER_DMA)},
+ {PCI_VDEVICE(STMICRO, PCI_DEVICE_ID_STMICRO_AUDIO_ROUTER_MSPS)},
+ {0,}
+};
+
+static struct pci_driver pci_amba_driver = {
+ .name = "pci-amba",
+ .id_table = pci_amba_table,
+ .probe = pci_amba_probe,
+ .remove = pci_amba_remove,
+};
+
+static int __init pci_amba_init(void)
+{
+ return pci_register_driver(&pci_amba_driver);
+}
+
+static void __exit pci_amba_exit(void)
+{
+ pci_unregister_driver(&pci_amba_driver);
+}
+
+module_init(pci_amba_init);
+module_exit(pci_amba_exit);
+
+MODULE_LICENSE("GPL");
--
[PATCH V6 0/5] x86: a bridge from PCI to AMBA
V6: I also put in the acked-by we received on the mailing list and were missing from tip::x86/amba. V5: This is a repost of patches I sent quite some time ago and are available from the "tip" repository, as branch "x86/amba" based on v3.7. That branch includes 7 patches but two of them are already upstream. Some of the other 5 had minor conflicts during rebase, but only in the initial "#include" area. I repost as Peter Anvin suggested. The commits in the tip repository included both hpa's signed off (which I left in) and the reference to the previous lkml message, which I removed as it is not current by the time this message exists. Alessandro Rubini (5): DMA: PL330: use prefix in reg names to build under x86 watchdog: sp805_wdt depends on ARM mmc: Use the new drivers/amba: add support for a PCI bridge x86: add CONFIG_ARM_AMBA, selected by STA2X11 arch/x86/Kconfig|4 ++ drivers/Kconfig |2 + drivers/amba/Kconfig| 10 drivers/amba/Makefile |1 + drivers/amba/pci-amba.c | 93 + drivers/dma/pl330.c | 107 ++- drivers/mmc/host/mmci.c |2 +- drivers/mmc/host/msm_sdcc.c |2 +- drivers/mmc/host/mvsdio.c |2 +- drivers/mmc/host/mxcmmc.c |2 +- drivers/mmc/host/pxamci.c |3 +- drivers/watchdog/Kconfig|2 +- 12 files changed, 170 insertions(+), 60 deletions(-) create mode 100644 drivers/amba/Kconfig create mode 100644 drivers/amba/pci-amba.c -- 1.7.7.2 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH V6 2/5] watchdog: sp805_wdt depends on ARM
The SP805 driver is only used by the Spear machines, and uses writel_relaxed, which is not available on all architectures. The dependency from CONFIG_ARM avoids compilation problems under randomconfig when CONFIG_ARM_AMBA is enabled for x86 builds. Signed-off-by: Alessandro Rubini Acked-by: Giancarlo Asnaghi Signed-off-by: Davide Ciminaghi Acked-by: Wim Van Sebroeck Acked-by: Linus Walleij Acked-by: Viresh Kumar Signed-off-by: H. Peter Anvin --- @Wim, Viresh, Linus: I repost this after rebasing, on hpa's suggestion. Viresh's ack: http://lkml.org/lkml/2012/11/23/296 Linus' ack: http://lkml.org/lkml/2012/11/28/259 drivers/watchdog/Kconfig |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/drivers/watchdog/Kconfig b/drivers/watchdog/Kconfig index 83ac1f7..e89fc31 100644 --- a/drivers/watchdog/Kconfig +++ b/drivers/watchdog/Kconfig @@ -109,7 +109,7 @@ config WM8350_WATCHDOG config ARM_SP805_WATCHDOG tristate "ARM SP805 Watchdog" - depends on ARM_AMBA + depends on ARM && ARM_AMBA select WATCHDOG_CORE help ARM Primecell SP805 Watchdog timer. This will reboot your system when -- 1.7.7.2 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH V6 3/5] mmc: Use the new
For portability, use . Signed-off-by: Alessandro Rubini Acked-by: Giancarlo Asnaghi Acked-by: David Brown Acked-by: Linus Walleij Acked-by: Viresh Kumar Signed-off-by: H. Peter Anvin --- @David, Viresh, Linus: I repost this after rebasing, on hpa's suggestion. Viresh' ack: http://lkml.org/lkml/2012/11/23/328 Linus' ack: http://lkml.org/lkml/2012/12/1/105 drivers/mmc/host/mmci.c |2 +- drivers/mmc/host/msm_sdcc.c |2 +- drivers/mmc/host/mvsdio.c |2 +- drivers/mmc/host/mxcmmc.c |2 +- drivers/mmc/host/pxamci.c |3 +-- 5 files changed, 5 insertions(+), 6 deletions(-) diff --git a/drivers/mmc/host/mmci.c b/drivers/mmc/host/mmci.c index 372e921..a47aa70 100644 --- a/drivers/mmc/host/mmci.c +++ b/drivers/mmc/host/mmci.c @@ -34,11 +34,11 @@ #include #include #include +#include #include #include #include -#include #include "mmci.h" diff --git a/drivers/mmc/host/msm_sdcc.c b/drivers/mmc/host/msm_sdcc.c index 7c0af0e..aa61b79 100644 --- a/drivers/mmc/host/msm_sdcc.c +++ b/drivers/mmc/host/msm_sdcc.c @@ -37,10 +37,10 @@ #include #include #include +#include #include #include -#include #include #include diff --git a/drivers/mmc/host/mvsdio.c b/drivers/mmc/host/mvsdio.c index 145cdaf..53a1224 100644 --- a/drivers/mmc/host/mvsdio.c +++ b/drivers/mmc/host/mvsdio.c @@ -23,11 +23,11 @@ #include #include #include +#include #include #include #include -#include #include #include diff --git a/drivers/mmc/host/mxcmmc.c b/drivers/mmc/host/mxcmmc.c index a72936e..8ce7e73 100644 --- a/drivers/mmc/host/mxcmmc.c +++ b/drivers/mmc/host/mxcmmc.c @@ -34,10 +34,10 @@ #include #include #include +#include #include #include -#include #include #include diff --git a/drivers/mmc/host/pxamci.c b/drivers/mmc/host/pxamci.c index 2b2f65a..6fa54a9 100644 --- a/drivers/mmc/host/pxamci.c +++ b/drivers/mmc/host/pxamci.c @@ -33,8 +33,7 @@ #include #include #include - -#include +#include #include #include -- 1.7.7.2 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH V6 1/5] DMA: PL330: use prefix in reg names to build under x86
This driver would not compile if ARM_AMBA is selected under x86,
because "CS" and "DS" are already defined there. But AMBA
is used in the x86 world by a PCI-to-AMBA bridge, to be submitted.
The patch just adds the "PL330_" prefix to all registers,
so it can be built by randomconfig after ARM_AMBA appears within x86.
No other technical changes have been performed.
The patch was build-tested only.
Signed-off-by: Alessandro Rubini
Acked-by: Giancarlo Asnaghi
Signed-off-by: Davide Ciminaghi
Acked-by: Jassi Brar
Acked-by: Linus Walleij
Acked-by: Vinod Koul
Signed-off-by: H. Peter Anvin
---
@Jassi, Linus, Vinod: I repost this after rebasing, on hpa's suggestion.
Linus' ack: http://lkml.org/lkml/2012/9/16/93
Vinod's ack: http://lkml.org/lkml/2012/9/16/271
drivers/dma/pl330.c | 107 ++-
1 files changed, 54 insertions(+), 53 deletions(-)
diff --git a/drivers/dma/pl330.c b/drivers/dma/pl330.c
index 7181531..b45cbe0 100644
--- a/drivers/dma/pl330.c
+++ b/drivers/dma/pl330.c
@@ -70,7 +70,7 @@ enum pl330_reqtype {
};
/* Register and Bit field Definitions */
-#define DS 0x0
+#define PL330_DS 0x0
#define DS_ST_STOP 0x0
#define DS_ST_EXEC 0x1
#define DS_ST_CMISS0x2
@@ -84,33 +84,33 @@ enum pl330_reqtype {
#define DS_ST_FLTCMP 0xe
#define DS_ST_FAULT0xf
-#define DPC0x4
-#define INTEN 0x20
-#define ES 0x24
-#define INTSTATUS 0x28
-#define INTCLR 0x2c
-#define FSM0x30
-#define FSC0x34
-#define FTM0x38
+#define PL330_DPC 0x4
+#define PL330_INTEN0x20
+#define PL330_ES 0x24
+#define PL330_INTSTATUS0x28
+#define PL330_INTCLR 0x2c
+#define PL330_FSM 0x30
+#define PL330_FSC 0x34
+#define PL330_FTM 0x38
#define _FTC 0x40
-#define FTC(n) (_FTC + (n)*0x4)
+#define PL330_FTC(n) (_FTC + (n)*0x4)
#define _CS0x100
-#define CS(n) (_CS + (n)*0x8)
+#define PL330_CS(n)(_CS + (n)*0x8)
#define CS_CNS (1 << 21)
#define _CPC 0x104
-#define CPC(n) (_CPC + (n)*0x8)
+#define PL330_CPC(n) (_CPC + (n)*0x8)
#define _SA0x400
-#define SA(n) (_SA + (n)*0x20)
+#define PL330_SA(n)(_SA + (n)*0x20)
#define _DA0x404
-#define DA(n) (_DA + (n)*0x20)
+#define PL330_DA(n)(_DA + (n)*0x20)
#define _CC0x408
-#define CC(n) (_CC + (n)*0x20)
+#define PL330_CC(n)(_CC + (n)*0x20)
#define CC_SRCINC (1 << 0)
#define CC_DSTINC (1 << 14)
@@ -131,24 +131,24 @@ enum pl330_reqtype {
#define CC_SWAP_SHFT 28
#define _LC0 0x40c
-#define LC0(n) (_LC0 + (n)*0x20)
+#define PL330_LC0(n) (_LC0 + (n)*0x20)
#define _LC1 0x410
-#define LC1(n) (_LC1 + (n)*0x20)
+#define PL330_LC1(n) (_LC1 + (n)*0x20)
-#define DBGSTATUS 0xd00
+#define PL330_DBGSTATUS0xd00
#define DBG_BUSY (1 << 0)
-#define DBGCMD 0xd04
-#define DBGINST0 0xd08
-#define DBGINST1 0xd0c
+#define PL330_DBGCMD 0xd04
+#define PL330_DBGINST0 0xd08
+#define PL330_DBGINST1 0xd0c
-#define CR00xe00
-#define CR10xe04
-#define CR20xe08
-#define CR30xe0c
-#define CR40xe10
-#define CRD0xe14
+#define PL330_CR0 0xe00
+#define PL330_CR1 0xe04
+#define PL330_CR2 0xe08
+#define PL330_CR3 0xe0c
+#define PL330_CR4 0xe10
+#define PL330_CRD 0xe14
#define PERIPH_ID 0xfe0
#define PERIPH_REV_SHIFT 20
@@ -1022,7 +1022,7 @@ static bool _until_dmac_idle(struct pl330_thread *thrd)
do {
/* Until Manager is Idle */
- if (!(readl(regs + DBGSTATUS) & DBG_BUSY))
+ if (!(readl(regs + PL330_DBGSTATUS) & DBG_BUSY))
break;
cpu_relax();
@@ -1045,10 +1045,10 @@ static inline void _execute_DBGINSN(struct pl330_thread
*thrd,
val |= (1 << 0);
val |= (thrd->id << 8); /* Channel Number */
}
- writel(val, regs + DBGINST0);
+ writel(val, regs + PL330_DBGINST0);
val = *((u32 *)&insn[2]);
- writel(val, regs + DBGINST1);
+
[PATCH V6 4/5] drivers/amba: add support for a PCI bridge
This is a PCI driver that registers AMBA devices for the range of
supported devices. It is currently used by STA2X11, which exports
AMBA peripherals under PCIe. The original AMBA drivers work with no
changes or minimal ones.
Signed-off-by: Alessandro Rubini
Acked-by: Giancarlo Asnaghi
Cc: Russell King
Cc: Alan Cox
Signed-off-by: H. Peter Anvin
---
@Russell, Alan: I repost this again, on hpa's suggestion,
as I filled more acked-by in some patches of this set, but not this one.
drivers/Kconfig |2 +
drivers/amba/Kconfig| 10 +
drivers/amba/Makefile |1 +
drivers/amba/pci-amba.c | 93 +++
4 files changed, 106 insertions(+), 0 deletions(-)
create mode 100644 drivers/amba/Kconfig
create mode 100644 drivers/amba/pci-amba.c
diff --git a/drivers/Kconfig b/drivers/Kconfig
index 202fa6d..e17144d 100644
--- a/drivers/Kconfig
+++ b/drivers/Kconfig
@@ -162,4 +162,6 @@ source "drivers/irqchip/Kconfig"
source "drivers/ipack/Kconfig"
+source "drivers/amba/Kconfig"
+
endmenu
diff --git a/drivers/amba/Kconfig b/drivers/amba/Kconfig
new file mode 100644
index 000..b5b5aca
--- /dev/null
+++ b/drivers/amba/Kconfig
@@ -0,0 +1,10 @@
+
+config PCI_AMBA
+ tristate "PCI-to-AMBA bridge"
+ depends on ARM_AMBA && PCI
+ ---help---
+ This compiles a PCI driver that registers AMBA devices, so
+ the respective AMBA driver can be used unchanged if you have
+ a PCI to amba bridge. This is required for STA2X11 support.
+
+ If uncertain, choose N.
diff --git a/drivers/amba/Makefile b/drivers/amba/Makefile
index 66e81c2..d30e947 100644
--- a/drivers/amba/Makefile
+++ b/drivers/amba/Makefile
@@ -1,2 +1,3 @@
obj-$(CONFIG_ARM_AMBA) += bus.o
+obj-$(CONFIG_PCI_AMBA) += pci-amba.o
obj-$(CONFIG_TEGRA_AHB)+= tegra-ahb.o
diff --git a/drivers/amba/pci-amba.c b/drivers/amba/pci-amba.c
new file mode 100644
index 000..ff46575
--- /dev/null
+++ b/drivers/amba/pci-amba.c
@@ -0,0 +1,93 @@
+/*
+ * Support for AMBA devices (both APB and AHB) behind a PCI bridge
+ * Copyright 2012 ST Microelectronics (Alessandro Rubini)
+ * GNU GPL version 2.
+ */
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+static int pci_amba_probe(struct pci_dev *pdev,
+const struct pci_device_id *id)
+{
+ struct amba_device *adev;
+ char *name;
+ int ret;
+
+ pci_enable_msi(pdev);
+ ret = pci_enable_device(pdev);
+ if (ret)
+ return ret;
+
+ /* Create a name: each of them must be different */
+ name = devm_kzalloc(&pdev->dev, strlen(dev_name(&pdev->dev)) + 6,
+ GFP_KERNEL);
+ sprintf(name, "amba-%s", dev_name(&pdev->dev));
+
+ /* Simply build an amba device and register it */
+ adev = amba_device_alloc(name, pdev->resource[0].start, SZ_4K);
+ if (!adev)
+ return -ENOMEM;
+ adev->irq[0] = pdev->irq;
+
+ /* This bridge can host both APB and AHB devices, so set master */
+ pci_set_master(pdev);
+ if (pdev->vendor == PCI_VENDOR_ID_STMICRO) {
+ /* Under sta2x11, DMA is there but limited to 512M */
+ adev->dma_mask = SZ_512M - 1;
+ adev->dev.coherent_dma_mask = SZ_512M - 1;
+ }
+
+ adev->dev.platform_data = pdev->dev.platform_data;
+ pci_set_drvdata(pdev, adev);
+
+ return amba_device_add(adev, &pdev->resource[0]);
+};
+
+static void pci_amba_remove(struct pci_dev *pdev)
+{
+ struct amba_device *adev = pci_get_drvdata(pdev);
+ amba_device_unregister(adev);
+ pci_disable_msi(pdev);
+}
+
+static DEFINE_PCI_DEVICE_TABLE(pci_amba_table) = {
+ {PCI_VDEVICE(STMICRO, PCI_DEVICE_ID_STMICRO_UART_HWFC)},
+ {PCI_VDEVICE(STMICRO, PCI_DEVICE_ID_STMICRO_UART_NO_HWFC)},
+ {PCI_VDEVICE(STMICRO, PCI_DEVICE_ID_STMICRO_SOC_DMA)},
+ {PCI_VDEVICE(STMICRO, PCI_DEVICE_ID_STMICRO_I2C)},
+ {PCI_VDEVICE(STMICRO, PCI_DEVICE_ID_STMICRO_SPI_HS)},
+ {PCI_VDEVICE(STMICRO, PCI_DEVICE_ID_STMICRO_SDIO_EMMC)},
+ {PCI_VDEVICE(STMICRO, PCI_DEVICE_ID_STMICRO_SDIO)},
+ {PCI_VDEVICE(STMICRO, PCI_DEVICE_ID_STMICRO_AUDIO_ROUTER_DMA)},
+ {PCI_VDEVICE(STMICRO, PCI_DEVICE_ID_STMICRO_AUDIO_ROUTER_MSPS)},
+ {0,}
+};
+
+static struct pci_driver pci_amba_driver = {
+ .name = "pci-amba",
+ .id_table = pci_amba_table,
+ .probe = pci_amba_probe,
+ .remove = pci_amba_remove,
+};
+
+static int __init pci_amba_init(void)
+{
+ return pci_register_driver(&pci_amba_driver);
+}
+
+static void __exit pci_amba_exit(void)
+{
+ pci_unregister_driver(&pci_amba_driver);
+}
+
+module_init(pci_amba_init);
+module
[PATCH V6 5/5] x86: add CONFIG_ARM_AMBA, selected by STA2X11
The sta2x11 I/O Hub is a bridge from PCIe to AMBA. It reuses a number of amba drivers and needs to activate core bus support. Signed-off-by: Alessandro Rubini Acked-by: Giancarlo Asnaghi Signed-off-by: H. Peter Anvin --- arch/x86/Kconfig |4 1 files changed, 4 insertions(+), 0 deletions(-) diff --git a/arch/x86/Kconfig b/arch/x86/Kconfig index b11f082..fc06c25 100644 --- a/arch/x86/Kconfig +++ b/arch/x86/Kconfig @@ -548,6 +548,7 @@ config STA2X11 select SWIOTLB select MFD_STA2X11 select ARCH_REQUIRE_GPIOLIB + select ARM_AMBA default n ---help--- This adds support for boards based on the STA2X11 IO-Hub, @@ -2271,6 +2272,9 @@ config TS5500 endif # X86_32 +config ARM_AMBA +bool + config AMD_NB def_bool y depends on CPU_SUP_AMD && PCI -- 1.7.7.2 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH V5 4/5] drivers/amba: add support for a PCI bridge
[meanwhile I posted V6 with the acked-by of linusw and others, that were missing in V5] rmk: >> I'm happy to take it through my tree if everyone is now happy with this. hpa: > I am okay with that, although I would like to make sure we do a bunch of > x86 randconfigs on it before pushing it to Linus. I did like this: - disable STA2X11 (and thus AMBA) and build - enable STA2X11, answer y to all new questions and build So there's nothing left (you'll have two unrelated warnings, that I'm working on and I'll post a fix tomorrow). Sure, Peter, first time I didn't do that test and missed some of the drivers. Thanks /alessandro -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH RFC 0/8] drivers/fmc: bus support for ANSI-VITA 57.1
This is an RFC for upstreaming the Linux bus abstraction for FMC. The following text is a slightly modified extract from the documentation, which is included in the fmc-bus package. The code I'm submitting is currently maintained outside of the kernel proper. See http://www.ohwr.org/projects/fmc-bus/ . The public repository is at git://ohwr.org/fmc-projects/fmc-bus.git and the current manual is at http://www.ohwr.org/attachments/download/1845/fmc-bus-2013-01-release.pdf The whole patch-set is sent to lkml, Greg K H (for drivers/), Rob Landley and the linux-doc list (both for Documentation/). FMC is a standard developed by the VME consortium called VITA (VMEbus International Trade Association) and ratified by ANSI, the American National Standard Institute. The official documentation is called "ANSI-VITA 57.1". The wikipedia article is http://en.wikipedia.org/wiki/FMC_%E2%80%93_FPGA_Mezzanine_Card FMC (FPGA Mezzanine Card) is what we use for our I/O devices, in the context of White Rabbit and related hardware. White Rabbit is a multi-lab synchronization project; bot software and hardware for WR is hosted at www.ohwr.org . In our I/O environments we need to write drivers for each mezzanine card, and such drivers must work regardless of the carrier being used. To achieve this, we abstract the FMC interface. The FMC card is an almost square PCB, around 70x75 millimeters, that is called mezzanine in code and documentation under drivers/fmc. It usually lives plugged into another PCB for power supply and control; such bigger circuit board is called carrier from now on, and a single carrier may host more than one mezzanine. We have a carrier for PCI-E called SPEC and one for VME called SVEC, (http://www.ohwr.org/projects/spec/wiki and http://www.ohwr.org/projects/svec/wiki) but more are planned. Also, we support stand-alone devices (usually plugged on a SPEC card), controlled through Etherbone, which in turn is developed by GSI.de . This submission does not include drivers for specific cards like the SPEC or SVEC, but has software-only carriers and drivers. Nothing in the submission in specific to CERN: the code is designed to match FMC features, not our own specific needs. In the typical application the mezzanine is mostly analog while the carrier is mostly digital, and hosts an FPGA that must be configured to match the specific mezzanine and the desired application. Thus, you may need to load different FPGA images to drive different instances of the same mezzanine. FMC, as such, is not a bus in the usual meaning of the term, because most carriers have only one connector, and carriers with several connectors have completely separate electrical connections to them. This package, however, implements a bus as a software abstraction. SDB (Self Describing Bus) is a set of data structures that we use for enumerating the internal structure of an FPGA image. We also use it as a filesystem inside the FMC EEPROM, but this submission only uses it to enumerate cores inside and FPGA design. SDB is not mandatory for use of this FMC kernel bus, but if you have SDB this package can make good use of it. SDB itself is developed in the fpga-config-space OHWR project. The link to the repository is `git://ohwr.org/hdl-core-lib/fpga-config-space.git' and what is used in this project lives in the sdbfs subdirectory in there. Alessandro Rubini (8): FMC: create drivers/fmc and toplevel Kconfig question FMC: add needed headers FMC: add core bus driver FMC: add documentation for the core FMC: add a software carrier driver FMC: add a software mezzanine driver FMC: add a driver to write mezzanine EEPROM FMC: add a char-device mezzanine driver Documentation/00-INDEX |2 + Documentation/fmc/00-INDEX | 38 Documentation/fmc/API.txt | 44 + Documentation/fmc/FMC-and-SDB.txt | 89 + Documentation/fmc/carrier.txt | 311 Documentation/fmc/fmc-chardev.txt | 64 +++ Documentation/fmc/fmc-fakedev.txt | 30 +++ Documentation/fmc/fmc-trivial.txt | 17 ++ Documentation/fmc/fmc-write-eeprom.txt | 112 Documentation/fmc/identifiers.txt | 169 + Documentation/fmc/mezzanine.txt| 123 + Documentation/fmc/parameters.txt | 56 ++ MAINTAINERS|9 + drivers/Kconfig|2 + drivers/Makefile |1 + drivers/fmc/Kconfig| 51 ++ drivers/fmc/Makefile | 13 ++ drivers/fmc/fmc-chardev.c | 197 drivers/fmc/fmc-core.c | 255 ++ drivers/fmc/fmc-dump.c | 100 ++ drivers/fmc/fmc-fakedev.c | 308 +++ drivers/fmc/fmc-match.c| 108
[PATCH 1/8] FMC: create drivers/fmc and toplevel Kconfig question
This commit creates the drivers/fmc directory and puts the necessary
hooks for kbuild and kconfig. The code is currently a placeholder
that only registers an empty bus.
Signed-off-by: Alessandro Rubini
Acked-by: Juan David Gonzalez Cobas
Acked-by: Emilio G. Cota
Acked-by: Samuel Iglesias Gonsalvez
---
MAINTAINERS|9 +
drivers/Kconfig|2 ++
drivers/Makefile |1 +
drivers/fmc/Kconfig| 17 +
drivers/fmc/Makefile |4
drivers/fmc/fmc-core.c | 42 ++
6 files changed, 75 insertions(+), 0 deletions(-)
create mode 100644 drivers/fmc/Kconfig
create mode 100644 drivers/fmc/Makefile
create mode 100644 drivers/fmc/fmc-core.c
diff --git a/MAINTAINERS b/MAINTAINERS
index 1279240..dca2907 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -3253,6 +3253,15 @@ T: git
git://git.kernel.org/pub/scm/linux/kernel/git/jikos/floppy.git
S: Odd fixes
F: drivers/block/floppy.c
+FMC SUBSYSTEM
+M: Alessandro Rubini
+W: http://www.ohwr.org/projects/fmc-bus
+S: Supported
+F: drivers/fmc/
+F: include/linux/fmc*.h
+F: include/linux/ipmi-fru.h
+K: fmc_d.*register
+
FPU EMULATOR
M: Bill Metzenthen
W: http://floatingpoint.sourceforge.net/emulator/index.html
diff --git a/drivers/Kconfig b/drivers/Kconfig
index 202fa6d..e0182e0 100644
--- a/drivers/Kconfig
+++ b/drivers/Kconfig
@@ -162,4 +162,6 @@ source "drivers/irqchip/Kconfig"
source "drivers/ipack/Kconfig"
+source "drivers/fmc/Kconfig"
+
endmenu
diff --git a/drivers/Makefile b/drivers/Makefile
index a93fbfc..57363a6 100644
--- a/drivers/Makefile
+++ b/drivers/Makefile
@@ -150,3 +150,4 @@ obj-$(CONFIG_IIO) += iio/
obj-$(CONFIG_VME_BUS) += vme/
obj-$(CONFIG_IPACK_BUS)+= ipack/
obj-$(CONFIG_NTB) += ntb/
+obj-$(CONFIG_FMC) += fmc/
diff --git a/drivers/fmc/Kconfig b/drivers/fmc/Kconfig
new file mode 100644
index 000..e287902
--- /dev/null
+++ b/drivers/fmc/Kconfig
@@ -0,0 +1,17 @@
+#
+# FMC (ANSI-VITA 57.1) bus support
+#
+
+menuconfig FMC
+ tristate "FMC support"
+ help
+
+ FMC (FPGA Mezzanine Carrier) is a mechanical and electrical
+ standard for mezzanine cards that plug into a carrier board.
+ This kernel subsystem supports the matching between carrier
+ and mezzanine based on identifiers stored in the internal I2C
+ EEPROM, as well as having carrier-independent drivers.
+
+ The framework was born outside of the kernel and at this time
+ the off-tree code base is more complete. Code and documentation
+ is at git://ohwr.org/fmc-projects/fmc-bus.git .
diff --git a/drivers/fmc/Makefile b/drivers/fmc/Makefile
new file mode 100644
index 000..a2784d8
--- /dev/null
+++ b/drivers/fmc/Makefile
@@ -0,0 +1,4 @@
+
+obj-$(CONFIG_FMC) += fmc.o
+
+fmc-y = fmc-core.o
diff --git a/drivers/fmc/fmc-core.c b/drivers/fmc/fmc-core.c
new file mode 100644
index 000..8695291
--- /dev/null
+++ b/drivers/fmc/fmc-core.c
@@ -0,0 +1,42 @@
+/* Temporary placeholder so the empty code can build */
+#include
+#include
+#include
+#include
+
+static struct bus_type fmc_bus_type = {
+ .name = "fmc",
+};
+
+/* Every device must have a release method: provide a default */
+static void __fmc_release(struct device *dev) { }
+
+/* This is needed as parent for our devices and dir in sysfs */
+struct device fmc_bus = {
+ .release = __fmc_release,
+ .init_name = "fmc",
+};
+
+static int fmc_init(void)
+{
+ int err;
+
+ err = device_register(&fmc_bus);
+ if (err)
+ return err;
+ err = bus_register(&fmc_bus_type);
+ if (err)
+ device_unregister(&fmc_bus);
+ return err;
+}
+
+static void fmc_exit(void)
+{
+ bus_unregister(&fmc_bus_type);
+ device_unregister(&fmc_bus);
+}
+
+module_init(fmc_init);
+module_exit(fmc_exit);
+
+MODULE_LICENSE("GPL");
--
1.7.7.2
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 2/8] FMC: add needed headers
This set of headers comes from commit 55812ecd (current master of the
project on ohwr.org). They define the basic data structures for FMC
and its SDB support.
Signed-off-by: Alessandro Rubini
Acked-by: Juan David Gonzalez Cobas
Acked-by: Emilio G. Cota
Acked-by: Samuel Iglesias Gonsalvez
---
include/linux/fmc-sdb.h | 36 +++
include/linux/fmc.h | 237 ++
include/linux/ipmi-fru.h | 135 ++
include/linux/sdb.h | 130 +
4 files changed, 538 insertions(+), 0 deletions(-)
create mode 100644 include/linux/fmc-sdb.h
create mode 100644 include/linux/fmc.h
create mode 100644 include/linux/ipmi-fru.h
create mode 100644 include/linux/sdb.h
diff --git a/include/linux/fmc-sdb.h b/include/linux/fmc-sdb.h
new file mode 100644
index 000..1974317
--- /dev/null
+++ b/include/linux/fmc-sdb.h
@@ -0,0 +1,36 @@
+/*
+ * This file is separate from sdb.h, because I want that one to remain
+ * unchanged (as far as possible) from the official sdb distribution
+ *
+ * This file and associated functionality are a playground for me to
+ * understand stuff which will later be implemented in more generic places.
+ */
+#include
+
+/* This is the union of all currently defined types */
+union sdb_record {
+ struct sdb_interconnect ic;
+ struct sdb_device dev;
+ struct sdb_bridge bridge;
+ struct sdb_integration integr;
+ struct sdb_empty empty;
+};
+
+struct fmc_device;
+
+/* Every sdb table is turned into this structure */
+struct sdb_array {
+ int len;
+ int level;
+ unsigned long baseaddr;
+ struct fmc_device *fmc; /* the device that hosts it */
+ struct sdb_array *parent; /* NULL at root */
+ union sdb_record *record; /* copies of the struct */
+ struct sdb_array **subtree; /* only valid for bridge items */
+};
+
+extern int fmc_scan_sdb_tree(struct fmc_device *fmc, unsigned long address);
+extern void fmc_show_sdb_tree(const struct fmc_device *fmc);
+extern signed long fmc_find_sdb_device(struct sdb_array *tree, uint64_t vendor,
+ uint32_t device, unsigned long *sz);
+extern int fmc_free_sdb_tree(struct fmc_device *fmc);
diff --git a/include/linux/fmc.h b/include/linux/fmc.h
new file mode 100644
index 000..4a821e4
--- /dev/null
+++ b/include/linux/fmc.h
@@ -0,0 +1,237 @@
+/*
+ * Copyright (C) 2012 CERN (www.cern.ch)
+ * Author: Alessandro Rubini
+ *
+ * Released according to the GNU GPL, version 2 or any later version.
+ *
+ * This work is part of the White Rabbit project, a research effort led
+ * by CERN, the European Institute for Nuclear Research.
+ */
+#ifndef __LINUX_FMC_H__
+#define __LINUX_FMC_H__
+#include
+#include
+#include
+#include
+#include
+#include
+
+struct fmc_device;
+struct fmc_driver;
+
+/*
+ * This bus abstraction is developed separately from drivers, so we need
+ * to check the version of the data structures we receive.
+ */
+
+#define FMC_MAJOR 3
+#define FMC_MINOR 0
+#define FMC_VERSION((FMC_MAJOR << 16) | FMC_MINOR)
+#define __FMC_MAJOR(x) ((x) >> 16)
+#define __FMC_MINOR(x) ((x) & 0x)
+
+/*
+ * The device identification, as defined by the IPMI FRU (Field Replaceable
+ * Unit) includes four different strings to describe the device. Here we
+ * only match the "Board Manufacturer" and the "Board Product Name",
+ * ignoring the "Board Serial Number" and "Board Part Number". All 4 are
+ * expected to be strings, so they are treated as zero-terminated C strings.
+ * Unspecified string (NULL) means "any", so if both are unspecified this
+ * is a catch-all driver. So null entries are allowed and we use array
+ * and length. This is unlike pci and usb that use null-terminated arrays
+ */
+struct fmc_fru_id {
+ char *manufacturer;
+ char *product_name;
+};
+
+/*
+ * If the FPGA is already programmed (think Etherbone or the second
+ * SVEC slot), we can match on SDB devices in the memory image. This
+ * match uses an array of devices that must all be present, and the
+ * match is based on vendor and device only. Further checks are expected
+ * to happen in the probe function. Zero means "any" and catch-all is allowed.
+ */
+struct fmc_sdb_one_id {
+ uint64_t vendor;
+ uint32_t device;
+};
+struct fmc_sdb_id {
+ struct fmc_sdb_one_id *cores;
+ int cores_nr;
+};
+
+struct fmc_device_id {
+ struct fmc_fru_id *fru_id;
+ int fru_id_nr;
+ struct fmc_sdb_id *sdb_id;
+ int sdb_id_nr;
+};
+
+/* This sizes the module_param_array used by generic module parameters */
+#define FMC_MAX_CARDS 32
+
+/* The driver is a pretty simple thing */
+struct fmc_driver {
+ unsigned long version;
+ struct device_driver driver;
+ int (*probe)(struct fmc_device *);
+ int (*remove)(struct fmc_device *);
[PATCH 4/8] FMC: add documentation for the core
This is selected sections of the current manual for fmc-bus, as developed outside of the kernel before submission. Signed-off-by: Alessandro Rubini Acked-by: Juan David Gonzalez Cobas Acked-by: Emilio G. Cota Acked-by: Samuel Iglesias Gonsalvez --- Documentation/00-INDEX|2 + Documentation/fmc/00-INDEX| 26 +++ Documentation/fmc/API.txt | 44 + Documentation/fmc/FMC-and-SDB.txt | 89 +++ Documentation/fmc/carrier.txt | 311 + Documentation/fmc/identifiers.txt | 169 Documentation/fmc/mezzanine.txt | 123 +++ Documentation/fmc/parameters.txt | 56 +++ 8 files changed, 820 insertions(+), 0 deletions(-) create mode 100644 Documentation/fmc/00-INDEX create mode 100644 Documentation/fmc/API.txt create mode 100644 Documentation/fmc/FMC-and-SDB.txt create mode 100644 Documentation/fmc/carrier.txt create mode 100644 Documentation/fmc/identifiers.txt create mode 100644 Documentation/fmc/mezzanine.txt create mode 100644 Documentation/fmc/parameters.txt diff --git a/Documentation/00-INDEX b/Documentation/00-INDEX index 45b3df9..0c4cc68 100644 --- a/Documentation/00-INDEX +++ b/Documentation/00-INDEX @@ -187,6 +187,8 @@ firmware_class/ - request_firmware() hotplug interface info. flexible-arrays.txt - how to make use of flexible sized arrays in linux +fmc/ + - information about the FMC bus abstraction frv/ - Fujitsu FR-V Linux documentation. futex-requeue-pi.txt diff --git a/Documentation/fmc/00-INDEX b/Documentation/fmc/00-INDEX new file mode 100644 index 000..71304b7 --- /dev/null +++ b/Documentation/fmc/00-INDEX @@ -0,0 +1,26 @@ + +Documentation in this directory comes from sections of the manual we +wrote for the externally-developed fmc-bus package. The complete +manual as of today (2013-02) is available in PDF format at +http://www.ohwr.org/projects/fmc-bus/files + +00-INDEX + - this file. + +FMC-and-SDB.txt + - What are FMC and SDB, basic concepts for this framework + +API.txt + - The functions that are exported by the bus driver + +parameters.txt + - The module parameters + +carrier.txt + - writing a carrier (a device) + +mezzanine.txt + - writing code for your mezzanine (a driver) + +identifiers.txt + - how identification and matching works diff --git a/Documentation/fmc/API.txt b/Documentation/fmc/API.txt new file mode 100644 index 000..2fe75d6 --- /dev/null +++ b/Documentation/fmc/API.txt @@ -0,0 +1,44 @@ +Functions Exported by fmc.ko + + +The FMC core exports the usual 4 functions that are needed for a bus to +work, and a few more: + +int fmc_driver_register(struct fmc_driver *drv); +void fmc_driver_unregister(struct fmc_driver *drv); +int fmc_device_register(struct fmc_device *fmc); +void fmc_device_unregister(struct fmc_device *fmc); + +int fmc_device_register_n(struct fmc_device *fmc, int n); +void fmc_device_unregister_n(struct fmc_device *fmc, int n); + +uint32_t fmc_readl(struct fmc_device *fmc, int offset); +void fmc_writel(struct fmc_device *fmc, uint32_t val, int off); +void *fmc_get_drvdata(struct fmc_device *fmc); +void fmc_set_drvdata(struct fmc_device *fmc, void *data); + +int fmc_reprogram(struct fmc_device *f, struct fmc_driver *d, char *gw, + int sdb_entry); + +The data structure that describe a device is detailed in *note FMC +Device::, the one that describes a driver is detailed in *note FMC +Driver::. + +The functions to register and unregister n devices are meant to be used +by carriers that host more than one mezzanine. The devices must be all +registered at the same time because if the FPGA is reprogrammed, all +devices in the array are affected. Usually, the driver matching the +first device will reprogram the FPGA, so other devices must know they +are already driven by a reprogrammed FPGA. + +If a carrier hosts slots that are driven by different FPGA devices, it +should register as a group only mezzanines that are driven by the same +FPGA, for the reason outlined above. + +Finally, the fmc_reprogram function calls the reprogram method (see +*note The API Offered by Carriers:: and also scans the memory area for +an SDB tree. You can pass -1 as sdb_entry to disable such scan. +Otherwise, the function fails if no tree is found at the specified +entry point. The function is meant to factorize common code, and by +the time you read this it is already used by the spec-sw and fine-delay +modules. diff --git a/Documentation/fmc/FMC-and-SDB.txt b/Documentation/fmc/FMC-and-SDB.txt new file mode 100644 index 000..bf49e0b --- /dev/null +++ b/Documentation/fmc/FMC-and-SDB.txt @@ -0,0 +1,89 @@ + +FMC (FPGA Mezzanine Card) is the standard we use for our I/O devices, +in the context of White Rabbit and related hardware. + +In
[PATCH 5/8] FMC: add a software carrier driver
This fake carrier is designed to understand how a carrier driver
works, and to experiment the behaviour with EEPROM reprogramming (with
a mezzanine driver commited later).
We have real carriers (both on PCI-E and VME), but they are bigger
things and are not part of this submission.
Signed-off-by: Alessandro Rubini
Acked-by: Juan David Gonzalez Cobas
Acked-by: Emilio G. Cota
Acked-by: Samuel Iglesias Gonsalvez
---
Documentation/fmc/00-INDEX|3 +
Documentation/fmc/fmc-fakedev.txt | 30
drivers/fmc/Kconfig | 11 ++
drivers/fmc/Makefile |2 +
drivers/fmc/fmc-fakedev.c | 308 +
5 files changed, 354 insertions(+), 0 deletions(-)
create mode 100644 Documentation/fmc/fmc-fakedev.txt
create mode 100644 drivers/fmc/fmc-fakedev.c
diff --git a/Documentation/fmc/00-INDEX b/Documentation/fmc/00-INDEX
index 71304b7..34df5cf 100644
--- a/Documentation/fmc/00-INDEX
+++ b/Documentation/fmc/00-INDEX
@@ -24,3 +24,6 @@ mezzanine.txt
identifiers.txt
- how identification and matching works
+
+fmc-fakedev.txt
+ - about drivers/fmc/fmc-fakedev.ko
diff --git a/Documentation/fmc/fmc-fakedev.txt
b/Documentation/fmc/fmc-fakedev.txt
new file mode 100644
index 000..4b0bc6c
--- /dev/null
+++ b/Documentation/fmc/fmc-fakedev.txt
@@ -0,0 +1,30 @@
+fmc-fakedev
+===
+
+This package includes a software-only device, called fmc-fakedev.
+Unlike the SPEC driver, which creates an FMC device for each PCI cards
+it manages, this module creates a single instance of its device.
+
+It is meant as the simplest possible example of how a driver should be
+written, and it includes a fake EEPROM image (built using the tools
+described in *note FMC Identification::).
+
+You can also use this device to verify the match algorithms, by asking
+it to test your own EEPROM image. You can provide the image by means of
+the eeprom= module parameter: the new EEPROM image is loaded, as usual,
+by means of the firmware loader. This example shows the defaults and a
+custom EEPROM image:
+
+spusa.root# insmod fmc-fakedev.ko
+[ 158.355436] fake-fmc: Manufacturer: fake-vendor
+[ 158.360106] fake-fmc: Product name: fake-design-for-testing
+spusa.root# rmmod fmc-fakedev
+spusa.root# insmod fmc-fakedev.ko eeprom=fdelay-eeprom.bin
+[ 197.182682] fake-fmc: Manufacturer: CERN
+[ 197.186764] fake-fmc: Product name: FmcDelay1ns4cha
+spusa.root# rmmod fmc-fakedev
+
+After loading the device, you can use the write_ee method do modify its
+own internal fake EEPROM: whenever the image is overwritten starting at
+offset 0, the module will unregister and register again the FMC device.
+This is shown in fmc-write-eeprom.txt
diff --git a/drivers/fmc/Kconfig b/drivers/fmc/Kconfig
index e287902..505e96b 100644
--- a/drivers/fmc/Kconfig
+++ b/drivers/fmc/Kconfig
@@ -15,3 +15,14 @@ menuconfig FMC
The framework was born outside of the kernel and at this time
the off-tree code base is more complete. Code and documentation
is at git://ohwr.org/fmc-projects/fmc-bus.git .
+
+if FMC
+
+config FMC_FAKEDEV
+ tristate "FMC fake device (software testing)"
+ help
+ This is a fake carrier, bringing a default EEPROM content
+ that can be rewritten at run time and usef for matching
+ mezzanines.
+
+endif # FMC
diff --git a/drivers/fmc/Makefile b/drivers/fmc/Makefile
index df98939..9832b79 100644
--- a/drivers/fmc/Makefile
+++ b/drivers/fmc/Makefile
@@ -6,3 +6,5 @@ fmc-y += fmc-match.o
fmc-y += fmc-sdb.o
fmc-y += fru-parse.o
fmc-y += fmc-dump.o
+
+obj-$(CONFIG_FMC_FAKEDEV) += fmc-fakedev.o
diff --git a/drivers/fmc/fmc-fakedev.c b/drivers/fmc/fmc-fakedev.c
new file mode 100644
index 000..17ceddb
--- /dev/null
+++ b/drivers/fmc/fmc-fakedev.c
@@ -0,0 +1,308 @@
+/*
+ * Copyright (C) 2012 CERN (www.cern.ch)
+ * Author: Alessandro Rubini
+ *
+ * Released to the public domain, as example to be reused
+ */
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+static char *ff_eeprom;
+module_param_named(eeprom, ff_eeprom, charp, 0444);
+
+/* Lazily, don't support the "standard" module parameters */
+
+#define FF_EEPROM_SIZE 8192
+
+/*
+ * Eeprom built from these commands:
+
+ ../fru-generator -v fake-vendor -n fake-design-for-testing \
+ -s 01234 -p none > IPMI-FRU
+
+ gensdbfs . ../fake-eeprom.bin
+*/
+static char ff_eeimg[FF_EEPROM_SIZE] = {
+ 0x01, 0x00, 0x00, 0x01, 0x00, 0x0c, 0x00, 0xf2, 0x01, 0x0b, 0x00, 0xb2,
+ 0x86, 0x87, 0xcb, 0x66, 0x61, 0x6b, 0x65, 0x2d, 0x76, 0x65, 0x6e, 0x64,
+ 0x6f, 0x72, 0xd7, 0x66, 0x61, 0x6b, 0x65, 0x2d, 0x64, 0x65, 0x73, 0x69,
+ 0x67, 0x6e, 0x2d, 0x66, 0x6f, 0x72, 0x2d, 0x74, 0x65, 0x73, 0x74, 0x69,
+ 0x6e, 0x67, 0xc5, 0x30, 0x31, 0x32, 0x33, 0x34, 0xc4, 0x6e, 0x6f, 0x6e,
+
[PATCH 6/8] FMC: add a software mezzanine driver
This simple do-nothing mezzanine driver shows how to write a mezzanine
driver, that can also handle interrupts reported by the carrier.
Signed-off-by: Alessandro Rubini
Acked-by: Juan David Gonzalez Cobas
Acked-by: Emilio G. Cota
Acked-by: Samuel Iglesias Gonsalvez
---
Documentation/fmc/00-INDEX|3 +
Documentation/fmc/fmc-trivial.txt | 17 ++
drivers/fmc/Kconfig |7 +++
drivers/fmc/Makefile |1 +
drivers/fmc/fmc-trivial.c | 101 +
5 files changed, 129 insertions(+), 0 deletions(-)
create mode 100644 Documentation/fmc/fmc-trivial.txt
create mode 100644 drivers/fmc/fmc-trivial.c
diff --git a/Documentation/fmc/00-INDEX b/Documentation/fmc/00-INDEX
index 34df5cf..c22d687 100644
--- a/Documentation/fmc/00-INDEX
+++ b/Documentation/fmc/00-INDEX
@@ -27,3 +27,6 @@ identifiers.txt
fmc-fakedev.txt
- about drivers/fmc/fmc-fakedev.ko
+
+fmc-trivial.txt
+ - about drivers/fmc/fmc-trivial.ko
diff --git a/Documentation/fmc/fmc-trivial.txt
b/Documentation/fmc/fmc-trivial.txt
new file mode 100644
index 000..d1910bc
--- /dev/null
+++ b/Documentation/fmc/fmc-trivial.txt
@@ -0,0 +1,17 @@
+fmc-trivial
+===
+
+The simple module fmc-trivial is just a simple client that registers an
+interrupt handler. I used it to verify the basic mechanism of the FMC
+bus and how interrupts worked.
+
+The module implements the generic FMC parameters, so it can program a
+different gateware file in each card. The whole list of parameters it
+accepts are:
+
+`busid='
+`gateware='
+ Generic parameters. See mezzanine.txt
+
+
+This driver is worth reading, in my opinion.
diff --git a/drivers/fmc/Kconfig b/drivers/fmc/Kconfig
index 505e96b..7eacef9 100644
--- a/drivers/fmc/Kconfig
+++ b/drivers/fmc/Kconfig
@@ -25,4 +25,11 @@ config FMC_FAKEDEV
that can be rewritten at run time and usef for matching
mezzanines.
+config FMC_TRIVIAL
+ tristate "FMC trivial mezzanine driver (software testing)"
+ help
+ This is a fake mezzanine driver, to show how FMC works and test it.
+ The driver also handles interrupts (we used it with a real carrier
+ before the mezzanines were produced)
+
endif # FMC
diff --git a/drivers/fmc/Makefile b/drivers/fmc/Makefile
index 9832b79..52624e6 100644
--- a/drivers/fmc/Makefile
+++ b/drivers/fmc/Makefile
@@ -8,3 +8,4 @@ fmc-y += fru-parse.o
fmc-y += fmc-dump.o
obj-$(CONFIG_FMC_FAKEDEV) += fmc-fakedev.o
+obj-$(CONFIG_FMC_TRIVIAL) += fmc-trivial.o
diff --git a/drivers/fmc/fmc-trivial.c b/drivers/fmc/fmc-trivial.c
new file mode 100644
index 000..c60f74c
--- /dev/null
+++ b/drivers/fmc/fmc-trivial.c
@@ -0,0 +1,101 @@
+/*
+ * Copyright (C) 2012 CERN (www.cern.ch)
+ * Author: Alessandro Rubini
+ *
+ * Released to the public domain, as example to be reused
+ */
+
+/* A trivial fmc driver that can load a gateware file and reports interrupts */
+#include
+#include
+#include
+#include
+#include
+
+static struct fmc_driver t_drv; /* initialized later */
+
+irqreturn_t t_handler(int irq, void *dev_id)
+{
+ struct fmc_device *fmc = dev_id;
+
+ fmc->op->irq_ack(fmc);
+ dev_info(fmc->hwdev, "received irq %i\n", irq);
+ return IRQ_HANDLED;
+}
+
+struct fmc_gpio t_gpio[] = {
+ {
+ .gpio = FMC_GPIO_IRQ(0),
+ .mode = GPIOF_DIR_IN,
+ .irqmode = IRQF_TRIGGER_RISING,
+ }, {
+ .gpio = FMC_GPIO_IRQ(1),
+ .mode = GPIOF_DIR_IN,
+ .irqmode = IRQF_TRIGGER_RISING,
+ }
+};
+
+int t_probe(struct fmc_device *fmc)
+{
+ int ret;
+ int index = 0;
+
+ if (fmc->op->validate)
+ index = fmc->op->validate(fmc, &t_drv);
+ if (index < 0)
+ return -EINVAL; /* not our device: invalid */
+
+ ret = fmc->op->irq_request(fmc, t_handler, "fmc-trivial", IRQF_SHARED);
+ if (ret < 0)
+ return ret;
+ /* ignore error code of call below, we really don't care */
+ fmc->op->gpio_config(fmc, t_gpio, ARRAY_SIZE(t_gpio));
+
+ /* Reprogram, if asked to. ESRCH == no filename specified */
+ ret = -ESRCH;
+ if (fmc->op->reprogram)
+ ret = fmc->op->reprogram(fmc, &t_drv, "");
+ if (ret == -ESRCH)
+ ret = 0;
+ if (ret < 0)
+ fmc->op->irq_free(fmc);
+
+ /* FIXME: reprogram LM32 too */
+ return ret;
+}
+
+int t_remove(struct fmc_device *fmc)
+{
+ fmc->op->irq_free(fmc);
+ return 0;
+}
+
+static struct fmc_driver t_drv = {
+ .version = FMC_VERSION,
+ .driver.name = KBUILD_MODNAME,
+ .probe = t_probe,
+ .remove = t_remove,
+ /* no table, as the current match just matches everything */
+};
+
+ /* We accept the generi
[PATCH 8/8] FMC: add a char-device mezzanine driver
This driver exports the memory area associated with the mezzanine card as a misc device, so users can access registers. Signed-off-by: Alessandro Rubini Acked-by: Juan David Gonzalez Cobas Acked-by: Emilio G. Cota Acked-by: Samuel Iglesias Gonsalvez --- Documentation/fmc/00-INDEX|5 +- Documentation/fmc/fmc-chardev.txt | 64 drivers/fmc/Kconfig |8 ++ drivers/fmc/Makefile |1 + drivers/fmc/fmc-chardev.c | 197 + 5 files changed, 274 insertions(+), 1 deletions(-) create mode 100644 Documentation/fmc/fmc-chardev.txt create mode 100644 drivers/fmc/fmc-chardev.c diff --git a/Documentation/fmc/00-INDEX b/Documentation/fmc/00-INDEX index 177c3e4..431c695 100644 --- a/Documentation/fmc/00-INDEX +++ b/Documentation/fmc/00-INDEX @@ -32,4 +32,7 @@ fmc-trivial.txt - about drivers/fmc/fmc-trivial.ko fmc-write-eeprom.txt -- about drivers/fmc/fmc-write-eeprom.ko + - about drivers/fmc/fmc-write-eeprom.ko + +fmc-chardev.txt + - about drivers/fmc/fmc-chardev.ko diff --git a/Documentation/fmc/fmc-chardev.txt b/Documentation/fmc/fmc-chardev.txt new file mode 100644 index 000..d9ccb27 --- /dev/null +++ b/Documentation/fmc/fmc-chardev.txt @@ -0,0 +1,64 @@ +fmc-chardev +=== + +This is a simple generic driver, that allows user access by means of a +character device (actually, one for each mezzanine it takes hold of). + +The char device is created as a misc device. Its name in /dev (as +created by udev) is the same name as the underlying FMC device. Thus, +the name can be a silly fmc- look-alike if the device has no +identifiers nor bus_id, a more specific fmc-0400 if the device has a +bus-specific address but no associated name, or something like +fdelay-0400 if the FMC core can rely on both a mezzanine name and a bus +address. + +Currently the driver only supports read and write: you can lseek to the +desired address and read or write a register. + +The driver assumes all registers are 32-bit in size, and only accepts a +single read or write per system call. However, as a result of Unix read +and write semantics, users can simply fread or fwrite bigger areas in +order to dump or store bigger memory areas. + +There is currently no support for mmap, user-space interrupt management +and DMA buffers. They may be added in later versions, if the need +arises. + +The example below shows raw access to a SPEC card programmed with its +golden FPGA file, that features an SDB structure at offset 256 - i.e. +64 words. The mezzanine's EEPROM in this case is not programmed, so the +default name is fmc-, and there are two cards in the system: + + spusa.root# insmod fmc-chardev.ko + [ 1073.339332] spec :02:00.0: Driver has no ID: matches all + [ 1073.345051] spec :02:00.0: Created misc device "fmc-0200" + [ 1073.350821] spec :04:00.0: Driver has no ID: matches all + [ 1073.356525] spec :04:00.0: Created misc device "fmc-0400" + spusa.root# ls -l /dev/fmc* + crw--- 1 root root 10, 58 Nov 20 19:23 /dev/fmc-0200 + crw--- 1 root root 10, 57 Nov 20 19:23 /dev/fmc-0400 + spusa.root# dd bs=4 skip=64 count=1 if=/dev/fmc-0200 2> /dev/null | od -t x1z + 000 2d 42 44 53 >-BDS< + 004 + +The simple program tools/fmc-mem in this package can access an FMC char +device and read or write a word or a whole area. Actually, the program +is not specific to FMC at all, it just uses lseek, read and write. + +Its first argument is the device name, the second the offset, the third +(if any) the value to write and the optional last argument that must +begin with "+" is the number of bytes to read or write. In case of +repeated reading data is written to stdout; repeated writes read from +stdin and the value argument is ignored. + +The following examples show reading the SDB magic number and the first +SDB record from a SPEC device programmed with its golden image: + + spusa.root# ./fmc-mem /dev/fmc-0200 100 + 5344422d + spusa.root# ./fmc-mem /dev/fmc-0200 100 +40 | od -Ax -t x1z + 00 2d 42 44 53 00 01 02 00 00 00 00 00 00 00 00 00 >-BDS< + 10 00 00 00 00 ff 01 00 00 00 00 00 00 51 06 00 00 >Q...< + 20 c9 42 a5 e6 02 00 00 00 11 05 12 20 2d 34 42 57 >.B. -4BW< + 30 73 6f 72 43 72 61 62 73 49 53 47 2d 00 20 20 20 >sorCrabsISG-. < + 40 diff --git a/drivers/fmc/Kconfig b/drivers/fmc/Kconfig index 2bb1953..c01cf45 100644 --- a/drivers/fmc/Kconfig +++ b/drivers/fmc/Kconfig @@ -40,4 +40,12 @@ config FMC_WRITE_EEPROM its binary and the function carrier->reprogram to actually do it. It is useful when the mezzanines are produced. +config FMC_CHARDEV + tristate "FMC mezzanine driver that registers a char device" + help + This
[PATCH 7/8] FMC: add a driver to write mezzanine EEPROM
This driver allows to reprogram the EEPROM in a mezzanine, to store its own identifiers during manufacturing or to save other useful data. Signed-off-by: Alessandro Rubini Acked-by: Juan David Gonzalez Cobas Acked-by: Emilio G. Cota Acked-by: Samuel Iglesias Gonsalvez --- Documentation/fmc/00-INDEX |3 + Documentation/fmc/fmc-write-eeprom.txt | 112 + drivers/fmc/Kconfig|8 ++ drivers/fmc/Makefile |1 + drivers/fmc/fmc-write-eeprom.c | 170 5 files changed, 294 insertions(+), 0 deletions(-) create mode 100644 Documentation/fmc/fmc-write-eeprom.txt create mode 100644 drivers/fmc/fmc-write-eeprom.c diff --git a/Documentation/fmc/00-INDEX b/Documentation/fmc/00-INDEX index c22d687..177c3e4 100644 --- a/Documentation/fmc/00-INDEX +++ b/Documentation/fmc/00-INDEX @@ -30,3 +30,6 @@ fmc-fakedev.txt fmc-trivial.txt - about drivers/fmc/fmc-trivial.ko + +fmc-write-eeprom.txt +- about drivers/fmc/fmc-write-eeprom.ko diff --git a/Documentation/fmc/fmc-write-eeprom.txt b/Documentation/fmc/fmc-write-eeprom.txt new file mode 100644 index 000..c4033d6 --- /dev/null +++ b/Documentation/fmc/fmc-write-eeprom.txt @@ -0,0 +1,112 @@ +fmc-write-eeprom + + +This module is designed to load a binary file from /lib/firmware and to +write it to the internal EEPROM of the mezzanine card. This driver uses +the `busid' generic parameter. + +Overwriting the EEPROM is not something you should do daily, and it is +expected to only happen during manufacturing. For this reason, the +module makes it unlikely for the random user to change a working EEPROM. + +The module takes the following measures: + + * It accepts a `file=' argument (within /lib/firmware) and if no + such argument is received, it doesn't write anything to EEPROM + (i.e. there is no default file name). + + * If the file name ends with `.bin' it is written verbatim starting + at offset 0. + + * If the file name ends with `.tlv' it is interpreted as + type-length-value (i.e., it allows writev(2)-like operation). + + * If the file name doesn't match any of the patterns above, it is + ignored and no write is performed. + + * Only cards listed with `busid=' are written to. If no busid is + specified, no programming is done (and the probe function of the + driver will fail). + + +Each TLV tuple is formatted in this way: the header is 5 bytes, +followed by data. The first byte is `w' for write, the next two bytes +represent the address, in little-endian byte order, and the next two +represent the data length, in little-endian order. The length does not +include the header (it is the actual number of bytes to be written). + +This is a real example: that writes 5 bytes at position 0x110: + +spusa.root# od -t x1 -Ax /lib/firmware/try.tlv +00 77 10 01 05 00 30 31 32 33 34 +0a +spusa.root# insmod /tmp/fmc-write-eeprom.ko busid=0x0200 file=try.tlv +[19983.391498] spec :03:00.0: write 5 bytes at 0x0110 +[19983.414615] spec :03:00.0: write_eeprom: success + +Please note that you'll most likely want to use SDBFS to build your +EEPROM image, at least if your mezzanines are being used in the White +Rabbit environment. For this reason the TLV format is not expected to +be used much and is not expected to be developed further. + +If you want to try reflashing fake EEPROM devices, you can use the +fmc-fakedev.ko module (see *note fmc-fakedev::). Whenever you change +the image starting at offset 0, it will deregister and register again +after two seconds. Please note, however, that if fmc-write-eeprom is +still loaded, the system will associate it to the new device, which +will be reprogrammed and thus will be unloaded after two seconds. The +following example removes the module after it reflashed fakedev the +first time. + + spusa.root# insmod fmc-fakedev.ko +[ 72.984733] fake-fmc: Manufacturer: fake-vendor +[ 72.989434] fake-fmc: Product name: fake-design-for-testing +spusa.root# insmod fmc-write-eeprom.ko busid=0 file=fdelay-eeprom.bin; \ +rmmod fmc-write-eeprom +[ 130.874098] fake-fmc: Matching a generic driver (no ID) +[ 130.887845] fake-fmc: programming 6155 bytes +[ 130.894567] fake-fmc: write_eeprom: success +[ 132.895794] fake-fmc: Manufacturer: CERN +[ 132.899872] fake-fmc: Product name: FmcDelay1ns4cha + + +Writing to the EEPROM += + +Once you have created a binary file for your EEPROM, you can write it +to the storage medium using the fmc-write-eeprom (See *note +fmc-write-eeprom::, while relying on a carrier driver. The procedure +here shown here uses the SPEC driver +(`http://www.ohwr.org/projects/spec-sw'). + +The example assumes no driver is
[PATCH 3/8] FMC: add core bus driver
This module offers registration services for both carriers
(i.e. devices) and mezzanines (i.e. drivers). The matching for devices
and drivers is performed according to the IPMI standard for FRU
devices (Field Replaceable Units).
The code includes support for parsing an SDB tree if present in the FPGA,
and dumping it for diagnostics. SDB is not mandatory.
Files in this commit correspond to commit 55812ecd in the master branch
of the project hosted on ohwr.org.
Signed-off-by: Alessandro Rubini
Acked-by: Juan David Gonzalez Cobas
Acked-by: Emilio G. Cota
Acked-by: Samuel Iglesias Gonsalvez
---
drivers/fmc/Makefile|4 +
drivers/fmc/fmc-core.c | 219 +++-
drivers/fmc/fmc-dump.c | 100 ++
drivers/fmc/fmc-match.c | 108
drivers/fmc/fmc-sdb.c | 258 +++
drivers/fmc/fru-parse.c | 82 +++
6 files changed, 768 insertions(+), 3 deletions(-)
create mode 100644 drivers/fmc/fmc-dump.c
create mode 100644 drivers/fmc/fmc-match.c
create mode 100644 drivers/fmc/fmc-sdb.c
create mode 100644 drivers/fmc/fru-parse.c
diff --git a/drivers/fmc/Makefile b/drivers/fmc/Makefile
index a2784d8..df98939 100644
--- a/drivers/fmc/Makefile
+++ b/drivers/fmc/Makefile
@@ -2,3 +2,7 @@
obj-$(CONFIG_FMC) += fmc.o
fmc-y = fmc-core.o
+fmc-y += fmc-match.o
+fmc-y += fmc-sdb.o
+fmc-y += fru-parse.o
+fmc-y += fmc-dump.o
diff --git a/drivers/fmc/fmc-core.c b/drivers/fmc/fmc-core.c
index 8695291..316a270 100644
--- a/drivers/fmc/fmc-core.c
+++ b/drivers/fmc/fmc-core.c
@@ -1,14 +1,73 @@
-/* Temporary placeholder so the empty code can build */
+/*
+ * Copyright (C) 2012 CERN (www.cern.ch)
+ * Author: Alessandro Rubini
+ *
+ * Released according to the GNU GPL, version 2 or any later version.
+ *
+ * This work is part of the White Rabbit project, a research effort led
+ * by CERN, the European Institute for Nuclear Research.
+ */
#include
#include
+#include
#include
#include
+#include
+
+static int fmc_check_version(unsigned long version, const char *name)
+{
+ if (__FMC_MAJOR(version) != FMC_MAJOR) {
+ pr_err("%s: \"%s\" has wrong major (has %li, expected %i)\n",
+ __func__, name, __FMC_MAJOR(version), FMC_MAJOR);
+ return -EINVAL;
+ }
+
+ if (__FMC_MINOR(version) != FMC_MINOR)
+ pr_info("%s: \"%s\" has wrong minor (has %li, expected %i)\n",
+ __func__, name, __FMC_MINOR(version), FMC_MINOR);
+ return 0;
+}
+
+static int fmc_uevent(struct device *dev, struct kobj_uevent_env *env)
+{
+ /* struct fmc_device *fdev = to_fmc_device(dev); */
+
+ /* FIXME: The MODALIAS */
+ add_uevent_var(env, "MODALIAS=%s", "fmc");
+ return 0;
+}
+
+static int fmc_probe(struct device *dev)
+{
+ struct fmc_driver *fdrv = to_fmc_driver(dev->driver);
+ struct fmc_device *fdev = to_fmc_device(dev);
+
+ return fdrv->probe(fdev);
+}
+
+static int fmc_remove(struct device *dev)
+{
+ struct fmc_driver *fdrv = to_fmc_driver(dev->driver);
+ struct fmc_device *fdev = to_fmc_device(dev);
+
+ return fdrv->remove(fdev);
+}
+
+static void fmc_shutdown(struct device *dev)
+{
+ /* not implemented but mandatory */
+}
static struct bus_type fmc_bus_type = {
.name = "fmc",
+ .match = fmc_match,
+ .uevent = fmc_uevent,
+ .probe = fmc_probe,
+ .remove = fmc_remove,
+ .shutdown = fmc_shutdown,
};
-/* Every device must have a release method: provide a default */
+/* We really have nothing to release in here */
static void __fmc_release(struct device *dev) { }
/* This is needed as parent for our devices and dir in sysfs */
@@ -17,13 +76,167 @@ struct device fmc_bus = {
.init_name = "fmc",
};
+/*
+ * Functions for client modules follow
+ */
+
+int fmc_driver_register(struct fmc_driver *drv)
+{
+ if (fmc_check_version(drv->version, drv->driver.name))
+ return -EINVAL;
+ drv->driver.bus = &fmc_bus_type;
+ return driver_register(&drv->driver);
+}
+EXPORT_SYMBOL(fmc_driver_register);
+
+void fmc_driver_unregister(struct fmc_driver *drv)
+{
+ driver_unregister(&drv->driver);
+}
+EXPORT_SYMBOL(fmc_driver_unregister);
+
+/*
+ * When a device set is registered, all eeproms must be read
+ * and all FRUs must be parsed
+ */
+int fmc_device_register_n(struct fmc_device *fmcs, int n)
+{
+ struct fmc_device *fmc, **devarray;
+ uint32_t device_id;
+ int i, ret = 0;
+
+ /* Check the version of the first data structure (function prints) */
+ if (fmc_check_version(fmcs->version, fmcs->carrier_name))
+ return -EINVAL;
+
+ devarray = kmalloc(n * sizeof(*devarray), GFP_KERNEL);
+ if (!devarray)
+
[PATCH] x86: fix warning for sta2x11
The .free field of struct dma_map_ops features a prototype that is
different from what lib/swiotlb.c offers. The new "attrs" argument in
dma_ops.free is missing from the generic implementation.
This removes the build warning by providing a function that just calls
swiotlb_free_coherent() without passing "attrs", like others do.
Signed-off-by: Alessandro Rubini
Acked-by: Giancarlo Asnaghi
---
NOTE: The real solution, in my opinion, would be adding "attrs" as
argument to the exported swiotlb_free_coherent() and remove this new
empty function for sta2x11 as well as the identical empty functions
found in other 6 files within arch.
If you ack, I can do that.
arch/x86/pci/sta2x11-fixup.c |9 -
1 files changed, 8 insertions(+), 1 deletions(-)
diff --git a/arch/x86/pci/sta2x11-fixup.c b/arch/x86/pci/sta2x11-fixup.c
index 9d8a509..5c24ccb 100644
--- a/arch/x86/pci/sta2x11-fixup.c
+++ b/arch/x86/pci/sta2x11-fixup.c
@@ -180,10 +180,17 @@ static void *sta2x11_swiotlb_alloc_coherent(struct device
*dev,
return vaddr;
}
+static void sta2x11_swiotlb_free_coherent(struct device *dev, size_t size,
+ void *vaddr, dma_addr_t dma_addr,
+ struct dma_attrs *attrs)
+{
+ swiotlb_free_coherent(dev, size, vaddr, dma_addr);
+}
+
/* We have our own dma_ops: the same as swiotlb but from alloc (above) */
static struct dma_map_ops sta2x11_dma_ops = {
.alloc = sta2x11_swiotlb_alloc_coherent,
- .free = swiotlb_free_coherent,
+ .free = sta2x11_swiotlb_free_coherent,
.map_page = swiotlb_map_page,
.unmap_page = swiotlb_unmap_page,
.map_sg = swiotlb_map_sg_attrs,
--
1.7.7.2
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH] mfd: trivially fix build warning in sta2x11-mfd
This driver cannot be a module, so "remove" is never called. The
mishap is mine, and back then there was no warning due to __devexit().
Signed-off-by: Alessandro Rubini
Acked-by: Giancarlo Asnaghi
---
drivers/mfd/sta2x11-mfd.c | 11 ---
1 files changed, 0 insertions(+), 11 deletions(-)
diff --git a/drivers/mfd/sta2x11-mfd.c b/drivers/mfd/sta2x11-mfd.c
index 9bd3316..d70a3430 100644
--- a/drivers/mfd/sta2x11-mfd.c
+++ b/drivers/mfd/sta2x11-mfd.c
@@ -98,17 +98,6 @@ static int sta2x11_mfd_add(struct pci_dev *pdev, gfp_t flags)
return 0;
}
-static int mfd_remove(struct pci_dev *pdev)
-{
- struct sta2x11_mfd *mfd = sta2x11_mfd_find(pdev);
-
- if (!mfd)
- return -ENODEV;
- list_del(&mfd->list);
- kfree(mfd);
- return 0;
-}
-
/* This function is exported and is not expected to fail */
u32 __sta2x11_mfd_mask(struct pci_dev *pdev, u32 reg, u32 mask, u32 val,
enum sta2x11_mfd_plat_dev index)
--
1.7.7.2
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] debugfs: more tightly restrict default mount mode
> Since the debugfs is mostly only used by root, make the default mount > mode 0700. Most system owners do not need a more permissive value, > but they can choose to weaken the restrictions via their fstab. But if the default is strict, file-completion won't work and most people will run a full root shell instead of sudo to save time. This is a step back in my opinion. Most administrators of their own machine won't go as far as changing fstab (none of my students would, for example). On the other hand admins of serious sites who are really concerned about doing "ls" over debugfs will be able to customize. So I vote against, knowing I'm late. thanks /alessandro -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 3/3] i2c: nomadik: Add Device Tree support to the Nomadik I2C driver
> Alessandro Rubini is actively working on bridging this (and > other amba_device primecells) to PCI, that is the reason why it > was recently converted to an amba_device. Yes, I've been inactive for a while but I'm on it right now. > How is he then supposed to get the proper parameters into the > driver? Note that the PCI ID is no help at all since the parameters > depend on what is connected to the I2C bus, not on what it itself is > connected to. Isn't platform data used in such cases? I'm using platform data currently, but Davide Ciminaghi is actively working to convert the configuration to device-tree: the way we pass platform data to the pci device (and thus amba) is not considered acceptable by Peter Anvin. I'm thus asking Davide if he's happy to remove the platform data configuration path right now (I personally wouldn't be very happy, but I acknowledge it should happen, sooner or later). /alessandro -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 12/16] ARM: nomadik: move platform_data definitions
> Platform data for device drivers should be defined in > include/linux/platform_data/*.h, not in the architecture > and platform specific directories. > > This moves such data out of the nomadik include directories Acked-by: Alessandro Rubini -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v2 00/10] sta2x11-mfd patches
> this is v2 of a patchset already submitted on 2012/09/12 Thanks Davide. For the whole series: Acked-by: Alessandro Rubini /alessandro -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 1/5] debugfs: pass NULL as the last parameter of debugfs_print_regs32()
>> This function is only used (twice) by the author of it, and the >> 'prefix' feature is never used. I introduced it to shrink some internal code that had a lot of repetition in the debugfs files implementation. In that context I use the prefix string. Some of the code had later been submitted, but not yet all of it. Later work by Davide Ciminaghi moved our MFD user to the regmap interface, according to maintainer's suggestion (which however means loosing register names from the debugfs dump). > If the parameter isn't being used, please, just delete it. It is not currently used by upstream callers, but the function itself uses it as documented (Documentation/...). I wouldn't remove the feature and introduce an incompatibility just for this. /alessandro -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
amba pl011: where to submit a fix for x86 builds
Hello. This is cc'd to $(get_maintainer.pl -f drivers/tty/serial/amba-pl011.c) and x86 maintainers too. While working on the pci-to-amba bridge driver (to be resubmitted in the next days) I have to deal with the problem of pl011 not building, after phys_to_page was introduced, by Chanho Min (Cc: here) in commit cb06ff1 ARM: PL011: Add support for Rx DMA buffer polling. because x86 has no phys_to_page. The fix I use is trivially this: - sg_set_page(&sg->sg, phys_to_page(dma_addr), + sg_set_page(&sg->sg, virt_to_page(sg->buf), (virt_to_page is slower, but other sg_get_page() users do the same and other solutions are more convoluted). Shall I submit this to x86 with the pci-to-amba bridge series or to arm/serial and then note the dependency when posting the bridge series? thanks /alessandro -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 1/8] FMC: create drivers/fmc and toplevel Kconfig question
> Nice job :) thanks! > Want me to take this through my char/misc git tree to get to Linus for > 3.11? Would be great. As for the license issue, shall I send the two patches alone or the whole set? thanks /alessandro -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 2/8] FMC: add needed headers
> Any way you can use MODULE_DEVICE_TABLE() for these devices to get > proper module auto-loading for your drivers? It's the next step. We are not doing that in our installations because it is not a trivial addition to running kernels -- we are plugging FMC devices in already-deployed kernel versions, sometimes even 2.6.24. /alessandro -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 3/8] FMC: add core bus driver
>> + * Released according to the GNU GPL, version 2 or any later version. > > I have to ask, do you really mean "or any later version"? Yes, it was intended. I don't think it's an issue for merging, but I understand you've seen so many such undesired copy-paste errors. >> +EXPORT_SYMBOL(fmc_driver_unregister); > > Any specific reason these aren't EXPORT_SYMBOL_GPL()? > > Again, just have to ask. I think we want to allow for proprietary FMC drivers. I personally don't feel this is a core kernel technology. But I'll let David Cobas expand on CERN policies, as I'm only a consultant. thanks /alessandro -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 3/8] FMC: add core bus driver
> Alessandro, care to respin the patches that I didn't apply and resend > them so that I can? Yes, ASAP. But, according to the later message by David, I'll respin with the BSD license for demo code and EXPORT_SYMBOL (no GPL-only clause): https://lkml.org/lkml/2013/6/18/119 "As mentioned, CERN policies are non-restrictive in this sense, hence we consider correct to leave EXPORT_SYMBOLs as they are currently. The BSD licencing for the other, "public domain" examples is also OK." Shortly: since FMC is not a core component of the kernel, the market is better served by allowing use of drivers/fmc also by those companies whose lawyers are bigger than their developers. (disclaimer: wording is mine). Even if CERN itself won't buy cards with proprietary drivers. /alessandro -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH V2 0/2] FMC: resend sample drivers
As suggested by Greg-KH [1] I'm resending the two example submodules (one carrier driver and one mezzanine driver) with a proper licence text for BSD. Among the various wordings, I chose the shortest one, as used by a number of drivers/net/wireless/ files. Thank you David for checking the distribution policies. I rebased to next-20130617 and rebuilt, with no conflicts. In any of the patches of the original series. [1] https://lkml.org/lkml/2013/6/17/772: "Just redo those two patches and send them as 'v2'") Alessandro Rubini (2): FMC: add a software carrier driver FMC: add a software mezzanine driver Documentation/fmc/00-INDEX|6 + Documentation/fmc/fmc-fakedev.txt | 36 Documentation/fmc/fmc-trivial.txt | 17 ++ drivers/fmc/Kconfig | 18 ++ drivers/fmc/Makefile |3 + drivers/fmc/fmc-fakedev.c | 355 + drivers/fmc/fmc-trivial.c | 107 +++ 7 files changed, 542 insertions(+), 0 deletions(-) create mode 100644 Documentation/fmc/fmc-fakedev.txt create mode 100644 Documentation/fmc/fmc-trivial.txt create mode 100644 drivers/fmc/fmc-fakedev.c create mode 100644 drivers/fmc/fmc-trivial.c -- 1.7.7.2 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH V2 1/2] FMC: add a software carrier driver
This fake carrier is designed to help FMC users understand how a carrier driver works, and to experiment the behaviour with EEPROM reprogramming (with a mezzanine driver commited later). This carrier can register up to 4 (fake) mezzanines. We have real carriers (both on PCI-E and VME), but they are bigger things and are not part of this submission. Signed-off-by: Alessandro Rubini Acked-by: Juan David Gonzalez Cobas Acked-by: Emilio G. Cota Acked-by: Samuel Iglesias Gonsalvez --- Documentation/fmc/00-INDEX|3 + Documentation/fmc/fmc-fakedev.txt | 36 drivers/fmc/Kconfig | 11 ++ drivers/fmc/Makefile |2 + drivers/fmc/fmc-fakedev.c | 355 + 5 files changed, 407 insertions(+), 0 deletions(-) create mode 100644 Documentation/fmc/fmc-fakedev.txt create mode 100644 drivers/fmc/fmc-fakedev.c diff --git a/Documentation/fmc/00-INDEX b/Documentation/fmc/00-INDEX index 71304b7..34df5cf 100644 --- a/Documentation/fmc/00-INDEX +++ b/Documentation/fmc/00-INDEX @@ -24,3 +24,6 @@ mezzanine.txt identifiers.txt - how identification and matching works + +fmc-fakedev.txt + - about drivers/fmc/fmc-fakedev.ko diff --git a/Documentation/fmc/fmc-fakedev.txt b/Documentation/fmc/fmc-fakedev.txt new file mode 100644 index 000..e85b74a --- /dev/null +++ b/Documentation/fmc/fmc-fakedev.txt @@ -0,0 +1,36 @@ +fmc-fakedev +=== + +This package includes a software-only device, called fmc-fakedev, which +is able to register up to 4 mezzanines (by default it registers one). +Unlike the SPEC driver, which creates an FMC device for each PCI cards +it manages, this module creates a single instance of its set of +mezzanines. + +It is meant as the simplest possible example of how a driver should be +written, and it includes a fake EEPROM image (built using the tools +described in *note FMC Identification::),, which by default is +replicated for each fake mezzanine. + +You can also use this device to verify the match algorithms, by asking +it to test your own EEPROM image. You can provide the image by means of +the eeprom= module parameter: the new EEPROM image is loaded, as usual, +by means of the firmware loader. This example shows the defaults and a +custom EEPROM image: + + spusa.root# insmod fmc-fakedev.ko + [ 99.971247] fake-fmc-carrier: mezzanine 0 + [ 99.975393] Manufacturer: fake-vendor + [ 99.979624] Product name: fake-design-for-testing + spusa.root# rmmod fmc-fakedev + spusa.root# insmod fmc-fakedev.ko eeprom=fdelay-eeprom.bin + [ 121.447464] fake-fmc-carrier: Mezzanine 0: eeprom "fdelay-eeprom.bin" + [ 121.462725] fake-fmc-carrier: mezzanine 0 + [ 121.466858] Manufacturer: CERN + [ 121.470477] Product name: FmcDelay1ns4cha + spusa.root# rmmod fmc-fakedev + +After loading the device, you can use the write_ee method do modify its +own internal fake EEPROM: whenever the image is overwritten starting at +offset 0, the module will unregister and register again the FMC device. +This is shown in fmc-write-eeprom.txt diff --git a/drivers/fmc/Kconfig b/drivers/fmc/Kconfig index e287902..505e96b 100644 --- a/drivers/fmc/Kconfig +++ b/drivers/fmc/Kconfig @@ -15,3 +15,14 @@ menuconfig FMC The framework was born outside of the kernel and at this time the off-tree code base is more complete. Code and documentation is at git://ohwr.org/fmc-projects/fmc-bus.git . + +if FMC + +config FMC_FAKEDEV + tristate "FMC fake device (software testing)" + help + This is a fake carrier, bringing a default EEPROM content + that can be rewritten at run time and usef for matching + mezzanines. + +endif # FMC diff --git a/drivers/fmc/Makefile b/drivers/fmc/Makefile index df98939..9832b79 100644 --- a/drivers/fmc/Makefile +++ b/drivers/fmc/Makefile @@ -6,3 +6,5 @@ fmc-y += fmc-match.o fmc-y += fmc-sdb.o fmc-y += fru-parse.o fmc-y += fmc-dump.o + +obj-$(CONFIG_FMC_FAKEDEV) += fmc-fakedev.o diff --git a/drivers/fmc/fmc-fakedev.c b/drivers/fmc/fmc-fakedev.c new file mode 100644 index 000..bec94ac --- /dev/null +++ b/drivers/fmc/fmc-fakedev.c @@ -0,0 +1,355 @@ +/* + * Copyright (C) 2012 CERN (www.cern.ch) + * Author: Alessandro Rubini + * + * Permission to use, copy, modify, and/or distribute this software for any + * purpose with or without fee is hereby granted, provided that the above + * copyright notice and this permission notice appear in all copies. + * + * The software is provided "as is"; the copyright holders disclaim + * all warranties and liabilities, to the extent permitted by + * applicable law. + */ +#include +#include +#include +#include +#include +#include +#include +#include +#include + +#define FF_EEPROM_SIZE 8192/* The standard eeprom size */ +#define FF_MAX_MEZZANINES 4 /* Fakes a multi-mezzanine
[PATCH V2 2/2] FMC: add a software mezzanine driver
This simple do-nothing mezzanine driver shows how to write a mezzanine
driver, that can also handle interrupts reported by the carrier.
Signed-off-by: Alessandro Rubini
Acked-by: Juan David Gonzalez Cobas
Acked-by: Emilio G. Cota
Acked-by: Samuel Iglesias Gonsalvez
---
Documentation/fmc/00-INDEX|3 +
Documentation/fmc/fmc-trivial.txt | 17 ++
drivers/fmc/Kconfig |7 +++
drivers/fmc/Makefile |1 +
drivers/fmc/fmc-trivial.c | 107 +
5 files changed, 135 insertions(+), 0 deletions(-)
create mode 100644 Documentation/fmc/fmc-trivial.txt
create mode 100644 drivers/fmc/fmc-trivial.c
diff --git a/Documentation/fmc/00-INDEX b/Documentation/fmc/00-INDEX
index 34df5cf..c22d687 100644
--- a/Documentation/fmc/00-INDEX
+++ b/Documentation/fmc/00-INDEX
@@ -27,3 +27,6 @@ identifiers.txt
fmc-fakedev.txt
- about drivers/fmc/fmc-fakedev.ko
+
+fmc-trivial.txt
+ - about drivers/fmc/fmc-trivial.ko
diff --git a/Documentation/fmc/fmc-trivial.txt
b/Documentation/fmc/fmc-trivial.txt
new file mode 100644
index 000..d1910bc
--- /dev/null
+++ b/Documentation/fmc/fmc-trivial.txt
@@ -0,0 +1,17 @@
+fmc-trivial
+===
+
+The simple module fmc-trivial is just a simple client that registers an
+interrupt handler. I used it to verify the basic mechanism of the FMC
+bus and how interrupts worked.
+
+The module implements the generic FMC parameters, so it can program a
+different gateware file in each card. The whole list of parameters it
+accepts are:
+
+`busid='
+`gateware='
+ Generic parameters. See mezzanine.txt
+
+
+This driver is worth reading, in my opinion.
diff --git a/drivers/fmc/Kconfig b/drivers/fmc/Kconfig
index 505e96b..7eacef9 100644
--- a/drivers/fmc/Kconfig
+++ b/drivers/fmc/Kconfig
@@ -25,4 +25,11 @@ config FMC_FAKEDEV
that can be rewritten at run time and usef for matching
mezzanines.
+config FMC_TRIVIAL
+ tristate "FMC trivial mezzanine driver (software testing)"
+ help
+ This is a fake mezzanine driver, to show how FMC works and test it.
+ The driver also handles interrupts (we used it with a real carrier
+ before the mezzanines were produced)
+
endif # FMC
diff --git a/drivers/fmc/Makefile b/drivers/fmc/Makefile
index 9832b79..52624e6 100644
--- a/drivers/fmc/Makefile
+++ b/drivers/fmc/Makefile
@@ -8,3 +8,4 @@ fmc-y += fru-parse.o
fmc-y += fmc-dump.o
obj-$(CONFIG_FMC_FAKEDEV) += fmc-fakedev.o
+obj-$(CONFIG_FMC_TRIVIAL) += fmc-trivial.o
diff --git a/drivers/fmc/fmc-trivial.c b/drivers/fmc/fmc-trivial.c
new file mode 100644
index 000..6c590f5
--- /dev/null
+++ b/drivers/fmc/fmc-trivial.c
@@ -0,0 +1,107 @@
+/*
+ * Copyright (C) 2012 CERN (www.cern.ch)
+ * Author: Alessandro Rubini
+ *
+ * Permission to use, copy, modify, and/or distribute this software for any
+ * purpose with or without fee is hereby granted, provided that the above
+ * copyright notice and this permission notice appear in all copies.
+ *
+ * The software is provided "as is"; the copyright holders disclaim
+ * all warranties and liabilities, to the extent permitted by
+ * applicable law.
+ */
+
+/* A trivial fmc driver that can load a gateware file and reports interrupts */
+#include
+#include
+#include
+#include
+#include
+
+static struct fmc_driver t_drv; /* initialized later */
+
+static irqreturn_t t_handler(int irq, void *dev_id)
+{
+ struct fmc_device *fmc = dev_id;
+
+ fmc->op->irq_ack(fmc);
+ dev_info(&fmc->dev, "received irq %i\n", irq);
+ return IRQ_HANDLED;
+}
+
+static struct fmc_gpio t_gpio[] = {
+ {
+ .gpio = FMC_GPIO_IRQ(0),
+ .mode = GPIOF_DIR_IN,
+ .irqmode = IRQF_TRIGGER_RISING,
+ }, {
+ .gpio = FMC_GPIO_IRQ(1),
+ .mode = GPIOF_DIR_IN,
+ .irqmode = IRQF_TRIGGER_RISING,
+ }
+};
+
+static int t_probe(struct fmc_device *fmc)
+{
+ int ret;
+ int index = 0;
+
+ if (fmc->op->validate)
+ index = fmc->op->validate(fmc, &t_drv);
+ if (index < 0)
+ return -EINVAL; /* not our device: invalid */
+
+ ret = fmc->op->irq_request(fmc, t_handler, "fmc-trivial", IRQF_SHARED);
+ if (ret < 0)
+ return ret;
+ /* ignore error code of call below, we really don't care */
+ fmc->op->gpio_config(fmc, t_gpio, ARRAY_SIZE(t_gpio));
+
+ /* Reprogram, if asked to. ESRCH == no filename specified */
+ ret = -ESRCH;
+ if (fmc->op->reprogram)
+ ret = fmc->op->reprogram(fmc, &t_drv, "");
+ if (ret == -ESRCH)
+ ret = 0;
+ if (ret < 0)
+ fmc->op->irq_free(fmc);
+
+ /* FIXME: reprogram LM32 too */
+ return ret;
+}
+
+static int t_remo
Re: [PATCH V2 0/2] FMC: resend sample drivers
> Did I only not apply 2 patches? I thought there should be some more > that I'm missing here. Can you resend _everything_ that I need to apply > that I haven't already? Ok. I wondered which magic tools of yours would use "v2" to rebuild the series in the same order. Sneding the whole 6-lot in a few minutes. /alessandro -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH V3 0/6] FMC: resending unapplied patches
Six patches from the series I initially sent on Jun 12. Changes in V3: all 6 yet unapplied by greg are resent, in correct order. Changes in V2: turned a generic "public domain" note for code to be reused into a proper BSD-like license, but I only resent affected patches, in error. Alessandro Rubini (6): FMC: add core bus driver FMC: add documentation for the core FMC: add a software carrier driver FMC: add a software mezzanine driver FMC: add a driver to write mezzanine EEPROM FMC: add a char-device mezzanine driver Documentation/00-INDEX |2 + Documentation/fmc/00-INDEX | 38 Documentation/fmc/API.txt | 47 + Documentation/fmc/FMC-and-SDB.txt | 88 Documentation/fmc/carrier.txt | 311 Documentation/fmc/fmc-chardev.txt | 64 ++ Documentation/fmc/fmc-fakedev.txt | 36 Documentation/fmc/fmc-trivial.txt | 17 ++ Documentation/fmc/fmc-write-eeprom.txt | 125 +++ Documentation/fmc/identifiers.txt | 168 +++ Documentation/fmc/mezzanine.txt| 123 +++ Documentation/fmc/parameters.txt | 56 + drivers/fmc/Kconfig| 34 +++ drivers/fmc/Makefile |9 + drivers/fmc/fmc-chardev.c | 197 ++ drivers/fmc/fmc-core.c | 274 - drivers/fmc/fmc-dump.c | 100 + drivers/fmc/fmc-fakedev.c | 355 drivers/fmc/fmc-match.c| 114 ++ drivers/fmc/fmc-sdb.c | 265 drivers/fmc/fmc-trivial.c | 107 ++ drivers/fmc/fmc-write-eeprom.c | 176 drivers/fmc/fru-parse.c| 82 23 files changed, 2787 insertions(+), 1 deletions(-) create mode 100644 Documentation/fmc/00-INDEX create mode 100644 Documentation/fmc/API.txt create mode 100644 Documentation/fmc/FMC-and-SDB.txt create mode 100644 Documentation/fmc/carrier.txt create mode 100644 Documentation/fmc/fmc-chardev.txt create mode 100644 Documentation/fmc/fmc-fakedev.txt create mode 100644 Documentation/fmc/fmc-trivial.txt create mode 100644 Documentation/fmc/fmc-write-eeprom.txt create mode 100644 Documentation/fmc/identifiers.txt create mode 100644 Documentation/fmc/mezzanine.txt create mode 100644 Documentation/fmc/parameters.txt create mode 100644 drivers/fmc/fmc-chardev.c create mode 100644 drivers/fmc/fmc-dump.c create mode 100644 drivers/fmc/fmc-fakedev.c create mode 100644 drivers/fmc/fmc-match.c create mode 100644 drivers/fmc/fmc-sdb.c create mode 100644 drivers/fmc/fmc-trivial.c create mode 100644 drivers/fmc/fmc-write-eeprom.c create mode 100644 drivers/fmc/fru-parse.c -- 1.7.7.2 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH V3 1/6] FMC: add core bus driver
This module offers registration services for both carriers
(i.e. devices) and mezzanines (i.e. drivers). The matching for devices
and drivers is performed according to the IPMI standard for FRU
devices (Field Replaceable Units).
The code includes support for parsing an SDB tree if present in the FPGA,
and dumping it for diagnostics. SDB is not mandatory.
Files in this commit correspond to commit ab23167f in the master branch
of the project hosted on ohwr.org.
Signed-off-by: Alessandro Rubini
Acked-by: Juan David Gonzalez Cobas
Acked-by: Emilio G. Cota
Acked-by: Samuel Iglesias Gonsalvez
---
drivers/fmc/Makefile|4 +
drivers/fmc/fmc-core.c | 274 ++-
drivers/fmc/fmc-dump.c | 100 +
drivers/fmc/fmc-match.c | 114
drivers/fmc/fmc-sdb.c | 265 +
drivers/fmc/fru-parse.c | 82 ++
6 files changed, 838 insertions(+), 1 deletions(-)
create mode 100644 drivers/fmc/fmc-dump.c
create mode 100644 drivers/fmc/fmc-match.c
create mode 100644 drivers/fmc/fmc-sdb.c
create mode 100644 drivers/fmc/fru-parse.c
diff --git a/drivers/fmc/Makefile b/drivers/fmc/Makefile
index a2784d8..df98939 100644
--- a/drivers/fmc/Makefile
+++ b/drivers/fmc/Makefile
@@ -2,3 +2,7 @@
obj-$(CONFIG_FMC) += fmc.o
fmc-y = fmc-core.o
+fmc-y += fmc-match.o
+fmc-y += fmc-sdb.o
+fmc-y += fru-parse.o
+fmc-y += fmc-dump.o
diff --git a/drivers/fmc/fmc-core.c b/drivers/fmc/fmc-core.c
index fc3547f..f4c8801 100644
--- a/drivers/fmc/fmc-core.c
+++ b/drivers/fmc/fmc-core.c
@@ -1,13 +1,285 @@
-/* Temporary placeholder so the empty code can build */
+/*
+ * Copyright (C) 2012 CERN (www.cern.ch)
+ * Author: Alessandro Rubini
+ *
+ * Released according to the GNU GPL, version 2 or any later version.
+ *
+ * This work is part of the White Rabbit project, a research effort led
+ * by CERN, the European Institute for Nuclear Research.
+ */
#include
#include
+#include
#include
#include
+#include
+
+static int fmc_check_version(unsigned long version, const char *name)
+{
+ if (__FMC_MAJOR(version) != FMC_MAJOR) {
+ pr_err("%s: \"%s\" has wrong major (has %li, expected %i)\n",
+ __func__, name, __FMC_MAJOR(version), FMC_MAJOR);
+ return -EINVAL;
+ }
+
+ if (__FMC_MINOR(version) != FMC_MINOR)
+ pr_info("%s: \"%s\" has wrong minor (has %li, expected %i)\n",
+ __func__, name, __FMC_MINOR(version), FMC_MINOR);
+ return 0;
+}
+
+static int fmc_uevent(struct device *dev, struct kobj_uevent_env *env)
+{
+ /* struct fmc_device *fdev = to_fmc_device(dev); */
+
+ /* FIXME: The MODALIAS */
+ add_uevent_var(env, "MODALIAS=%s", "fmc");
+ return 0;
+}
+
+static int fmc_probe(struct device *dev)
+{
+ struct fmc_driver *fdrv = to_fmc_driver(dev->driver);
+ struct fmc_device *fdev = to_fmc_device(dev);
+
+ return fdrv->probe(fdev);
+}
+
+static int fmc_remove(struct device *dev)
+{
+ struct fmc_driver *fdrv = to_fmc_driver(dev->driver);
+ struct fmc_device *fdev = to_fmc_device(dev);
+
+ return fdrv->remove(fdev);
+}
+
+static void fmc_shutdown(struct device *dev)
+{
+ /* not implemented but mandatory */
+}
static struct bus_type fmc_bus_type = {
.name = "fmc",
+ .match = fmc_match,
+ .uevent = fmc_uevent,
+ .probe = fmc_probe,
+ .remove = fmc_remove,
+ .shutdown = fmc_shutdown,
};
+static void fmc_release(struct device *dev)
+{
+ struct fmc_device *fmc = container_of(dev, struct fmc_device, dev);
+
+ kfree(fmc);
+}
+
+/*
+ * The eeprom is exported in sysfs, through a binary attribute
+ */
+
+static ssize_t fmc_read_eeprom(struct file *file, struct kobject *kobj,
+ struct bin_attribute *bin_attr,
+ char *buf, loff_t off, size_t count)
+{
+ struct device *dev;
+ struct fmc_device *fmc;
+ int eelen;
+
+ dev = container_of(kobj, struct device, kobj);
+ fmc = container_of(dev, struct fmc_device, dev);
+ eelen = fmc->eeprom_len;
+ if (off > eelen)
+ return -ESPIPE;
+ if (off == eelen)
+ return 0; /* EOF */
+ if (off + count > eelen)
+ count = eelen - off;
+ memcpy(buf, fmc->eeprom + off, count);
+ return count;
+}
+
+static struct bin_attribute fmc_eeprom_attr = {
+ .attr = { .name = "eeprom", .mode = S_IRUGO, },
+ .size = 8192, /* more or less standard */
+ .read = fmc_read_eeprom,
+};
+
+/*
+ * Functions for client modules follow
+ */
+
+int fmc_driver_register(struct fmc_driver *drv)
+{
+ if (fmc_check_version(drv->version, drv->driver.name))
+ return -EINVAL;
+ drv-&g
[PATCH V3 3/6] FMC: add a software carrier driver
This fake carrier is designed to help FMC users understand how a carrier driver works, and to experiment the behaviour with EEPROM reprogramming (with a mezzanine driver commited later). This carrier can register up to 4 (fake) mezzanines. We have real carriers (both on PCI-E and VME), but they are bigger things and are not part of this submission. Signed-off-by: Alessandro Rubini Acked-by: Juan David Gonzalez Cobas Acked-by: Emilio G. Cota Acked-by: Samuel Iglesias Gonsalvez --- Documentation/fmc/00-INDEX|3 + Documentation/fmc/fmc-fakedev.txt | 36 drivers/fmc/Kconfig | 11 ++ drivers/fmc/Makefile |2 + drivers/fmc/fmc-fakedev.c | 355 + 5 files changed, 407 insertions(+), 0 deletions(-) create mode 100644 Documentation/fmc/fmc-fakedev.txt create mode 100644 drivers/fmc/fmc-fakedev.c diff --git a/Documentation/fmc/00-INDEX b/Documentation/fmc/00-INDEX index 71304b7..34df5cf 100644 --- a/Documentation/fmc/00-INDEX +++ b/Documentation/fmc/00-INDEX @@ -24,3 +24,6 @@ mezzanine.txt identifiers.txt - how identification and matching works + +fmc-fakedev.txt + - about drivers/fmc/fmc-fakedev.ko diff --git a/Documentation/fmc/fmc-fakedev.txt b/Documentation/fmc/fmc-fakedev.txt new file mode 100644 index 000..e85b74a --- /dev/null +++ b/Documentation/fmc/fmc-fakedev.txt @@ -0,0 +1,36 @@ +fmc-fakedev +=== + +This package includes a software-only device, called fmc-fakedev, which +is able to register up to 4 mezzanines (by default it registers one). +Unlike the SPEC driver, which creates an FMC device for each PCI cards +it manages, this module creates a single instance of its set of +mezzanines. + +It is meant as the simplest possible example of how a driver should be +written, and it includes a fake EEPROM image (built using the tools +described in *note FMC Identification::),, which by default is +replicated for each fake mezzanine. + +You can also use this device to verify the match algorithms, by asking +it to test your own EEPROM image. You can provide the image by means of +the eeprom= module parameter: the new EEPROM image is loaded, as usual, +by means of the firmware loader. This example shows the defaults and a +custom EEPROM image: + + spusa.root# insmod fmc-fakedev.ko + [ 99.971247] fake-fmc-carrier: mezzanine 0 + [ 99.975393] Manufacturer: fake-vendor + [ 99.979624] Product name: fake-design-for-testing + spusa.root# rmmod fmc-fakedev + spusa.root# insmod fmc-fakedev.ko eeprom=fdelay-eeprom.bin + [ 121.447464] fake-fmc-carrier: Mezzanine 0: eeprom "fdelay-eeprom.bin" + [ 121.462725] fake-fmc-carrier: mezzanine 0 + [ 121.466858] Manufacturer: CERN + [ 121.470477] Product name: FmcDelay1ns4cha + spusa.root# rmmod fmc-fakedev + +After loading the device, you can use the write_ee method do modify its +own internal fake EEPROM: whenever the image is overwritten starting at +offset 0, the module will unregister and register again the FMC device. +This is shown in fmc-write-eeprom.txt diff --git a/drivers/fmc/Kconfig b/drivers/fmc/Kconfig index e287902..505e96b 100644 --- a/drivers/fmc/Kconfig +++ b/drivers/fmc/Kconfig @@ -15,3 +15,14 @@ menuconfig FMC The framework was born outside of the kernel and at this time the off-tree code base is more complete. Code and documentation is at git://ohwr.org/fmc-projects/fmc-bus.git . + +if FMC + +config FMC_FAKEDEV + tristate "FMC fake device (software testing)" + help + This is a fake carrier, bringing a default EEPROM content + that can be rewritten at run time and usef for matching + mezzanines. + +endif # FMC diff --git a/drivers/fmc/Makefile b/drivers/fmc/Makefile index df98939..9832b79 100644 --- a/drivers/fmc/Makefile +++ b/drivers/fmc/Makefile @@ -6,3 +6,5 @@ fmc-y += fmc-match.o fmc-y += fmc-sdb.o fmc-y += fru-parse.o fmc-y += fmc-dump.o + +obj-$(CONFIG_FMC_FAKEDEV) += fmc-fakedev.o diff --git a/drivers/fmc/fmc-fakedev.c b/drivers/fmc/fmc-fakedev.c new file mode 100644 index 000..bec94ac --- /dev/null +++ b/drivers/fmc/fmc-fakedev.c @@ -0,0 +1,355 @@ +/* + * Copyright (C) 2012 CERN (www.cern.ch) + * Author: Alessandro Rubini + * + * Permission to use, copy, modify, and/or distribute this software for any + * purpose with or without fee is hereby granted, provided that the above + * copyright notice and this permission notice appear in all copies. + * + * The software is provided "as is"; the copyright holders disclaim + * all warranties and liabilities, to the extent permitted by + * applicable law. + */ +#include +#include +#include +#include +#include +#include +#include +#include +#include + +#define FF_EEPROM_SIZE 8192/* The standard eeprom size */ +#define FF_MAX_MEZZANINES 4 /* Fakes a multi-mezzanine
[PATCH V3 5/6] FMC: add a driver to write mezzanine EEPROM
This driver allows to reprogram the EEPROM in a mezzanine, to store its own identifiers during manufacturing or to save other useful data. Signed-off-by: Alessandro Rubini Acked-by: Juan David Gonzalez Cobas Acked-by: Emilio G. Cota Acked-by: Samuel Iglesias Gonsalvez --- Documentation/fmc/00-INDEX |3 + Documentation/fmc/fmc-write-eeprom.txt | 125 ++ drivers/fmc/Kconfig|8 ++ drivers/fmc/Makefile |1 + drivers/fmc/fmc-write-eeprom.c | 176 5 files changed, 313 insertions(+), 0 deletions(-) create mode 100644 Documentation/fmc/fmc-write-eeprom.txt create mode 100644 drivers/fmc/fmc-write-eeprom.c diff --git a/Documentation/fmc/00-INDEX b/Documentation/fmc/00-INDEX index c22d687..177c3e4 100644 --- a/Documentation/fmc/00-INDEX +++ b/Documentation/fmc/00-INDEX @@ -30,3 +30,6 @@ fmc-fakedev.txt fmc-trivial.txt - about drivers/fmc/fmc-trivial.ko + +fmc-write-eeprom.txt +- about drivers/fmc/fmc-write-eeprom.ko diff --git a/Documentation/fmc/fmc-write-eeprom.txt b/Documentation/fmc/fmc-write-eeprom.txt new file mode 100644 index 000..44a3bc6 --- /dev/null +++ b/Documentation/fmc/fmc-write-eeprom.txt @@ -0,0 +1,125 @@ +fmc-write-eeprom + + +This module is designed to load a binary file from /lib/firmware and to +write it to the internal EEPROM of the mezzanine card. This driver uses +the `busid' generic parameter. + +Overwriting the EEPROM is not something you should do daily, and it is +expected to only happen during manufacturing. For this reason, the +module makes it unlikely for the random user to change a working EEPROM. + +The module takes the following measures: + + * It accepts a `file=' argument (within /lib/firmware) and if no + such argument is received, it doesn't write anything to EEPROM + (i.e. there is no default file name). + + * If the file name ends with `.bin' it is written verbatim starting + at offset 0. + + * If the file name ends with `.tlv' it is interpreted as + type-length-value (i.e., it allows writev(2)-like operation). + + * If the file name doesn't match any of the patterns above, it is + ignored and no write is performed. + + * Only cards listed with `busid=' are written to. If no busid is + specified, no programming is done (and the probe function of the + driver will fail). + + +Each TLV tuple is formatted in this way: the header is 5 bytes, +followed by data. The first byte is `w' for write, the next two bytes +represent the address, in little-endian byte order, and the next two +represent the data length, in little-endian order. The length does not +include the header (it is the actual number of bytes to be written). + +This is a real example: that writes 5 bytes at position 0x110: + +spusa.root# od -t x1 -Ax /lib/firmware/try.tlv +00 77 10 01 05 00 30 31 32 33 34 +0a +spusa.root# insmod /tmp/fmc-write-eeprom.ko busid=0x0200 file=try.tlv +[19983.391498] spec :03:00.0: write 5 bytes at 0x0110 +[19983.414615] spec :03:00.0: write_eeprom: success + +Please note that you'll most likely want to use SDBFS to build your +EEPROM image, at least if your mezzanines are being used in the White +Rabbit environment. For this reason the TLV format is not expected to +be used much and is not expected to be developed further. + +If you want to try reflashing fake EEPROM devices, you can use the +fmc-fakedev.ko module (see *note fmc-fakedev::). Whenever you change +the image starting at offset 0, it will deregister and register again +after two seconds. Please note, however, that if fmc-write-eeprom is +still loaded, the system will associate it to the new device, which +will be reprogrammed and thus will be unloaded after two seconds. The +following example removes the module after it reflashed fakedev the +first time. + + spusa.root# insmod fmc-fakedev.ko +[ 72.984733] fake-fmc: Manufacturer: fake-vendor +[ 72.989434] fake-fmc: Product name: fake-design-for-testing +spusa.root# insmod fmc-write-eeprom.ko busid=0 file=fdelay-eeprom.bin; \ +rmmod fmc-write-eeprom +[ 130.874098] fake-fmc: Matching a generic driver (no ID) +[ 130.887845] fake-fmc: programming 6155 bytes +[ 130.894567] fake-fmc: write_eeprom: success +[ 132.895794] fake-fmc: Manufacturer: CERN +[ 132.899872] fake-fmc: Product name: FmcDelay1ns4cha + + +Writing to the EEPROM += + +Once you have created a binary file for your EEPROM, you can write it +to the storage medium using the fmc-write-eeprom (See *note +fmc-write-eeprom::, while relying on a carrier driver. The procedure +here shown here uses the SPEC driver +(`http://www.ohwr.org/projects/spec-sw'). + +The example assumes no drive
[PATCH V3 2/6] FMC: add documentation for the core
This is selected sections of the current manual for fmc-bus, as developed outside of the kernel before submission. Like the other patches in this set, it corresponds to commit ab23167f of the repository at ohwr.org Signed-off-by: Alessandro Rubini Acked-by: Juan David Gonzalez Cobas Acked-by: Emilio G. Cota Acked-by: Samuel Iglesias Gonsalvez Acked-by: Rob Landley --- Documentation/00-INDEX|2 + Documentation/fmc/00-INDEX| 26 +++ Documentation/fmc/API.txt | 47 ++ Documentation/fmc/FMC-and-SDB.txt | 88 +++ Documentation/fmc/carrier.txt | 311 + Documentation/fmc/identifiers.txt | 168 Documentation/fmc/mezzanine.txt | 123 +++ Documentation/fmc/parameters.txt | 56 +++ 8 files changed, 821 insertions(+), 0 deletions(-) create mode 100644 Documentation/fmc/00-INDEX create mode 100644 Documentation/fmc/API.txt create mode 100644 Documentation/fmc/FMC-and-SDB.txt create mode 100644 Documentation/fmc/carrier.txt create mode 100644 Documentation/fmc/identifiers.txt create mode 100644 Documentation/fmc/mezzanine.txt create mode 100644 Documentation/fmc/parameters.txt diff --git a/Documentation/00-INDEX b/Documentation/00-INDEX index 45b3df9..0c4cc68 100644 --- a/Documentation/00-INDEX +++ b/Documentation/00-INDEX @@ -187,6 +187,8 @@ firmware_class/ - request_firmware() hotplug interface info. flexible-arrays.txt - how to make use of flexible sized arrays in linux +fmc/ + - information about the FMC bus abstraction frv/ - Fujitsu FR-V Linux documentation. futex-requeue-pi.txt diff --git a/Documentation/fmc/00-INDEX b/Documentation/fmc/00-INDEX new file mode 100644 index 000..71304b7 --- /dev/null +++ b/Documentation/fmc/00-INDEX @@ -0,0 +1,26 @@ + +Documentation in this directory comes from sections of the manual we +wrote for the externally-developed fmc-bus package. The complete +manual as of today (2013-02) is available in PDF format at +http://www.ohwr.org/projects/fmc-bus/files + +00-INDEX + - this file. + +FMC-and-SDB.txt + - What are FMC and SDB, basic concepts for this framework + +API.txt + - The functions that are exported by the bus driver + +parameters.txt + - The module parameters + +carrier.txt + - writing a carrier (a device) + +mezzanine.txt + - writing code for your mezzanine (a driver) + +identifiers.txt + - how identification and matching works diff --git a/Documentation/fmc/API.txt b/Documentation/fmc/API.txt new file mode 100644 index 000..06b06b92 --- /dev/null +++ b/Documentation/fmc/API.txt @@ -0,0 +1,47 @@ +Functions Exported by fmc.ko + + +The FMC core exports the usual 4 functions that are needed for a bus to +work, and a few more: + +int fmc_driver_register(struct fmc_driver *drv); +void fmc_driver_unregister(struct fmc_driver *drv); +int fmc_device_register(struct fmc_device *fmc); +void fmc_device_unregister(struct fmc_device *fmc); + +int fmc_device_register_n(struct fmc_device **fmc, int n); +void fmc_device_unregister_n(struct fmc_device **fmc, int n); + +uint32_t fmc_readl(struct fmc_device *fmc, int offset); +void fmc_writel(struct fmc_device *fmc, uint32_t val, int off); +void *fmc_get_drvdata(struct fmc_device *fmc); +void fmc_set_drvdata(struct fmc_device *fmc, void *data); + +int fmc_reprogram(struct fmc_device *f, struct fmc_driver *d, char *gw, + int sdb_entry); + +The data structure that describe a device is detailed in *note FMC +Device::, the one that describes a driver is detailed in *note FMC +Driver::. Please note that structures of type fmc_device must be +allocated by the caller, but must not be released after unregistering. +The fmc-bus itself takes care of releasing the structure when their use +count reaches zero - actually, the device model does that in lieu of us. + +The functions to register and unregister n devices are meant to be used +by carriers that host more than one mezzanine. The devices must all be +registered at the same time because if the FPGA is reprogrammed, all +devices in the array are affected. Usually, the driver matching the +first device will reprogram the FPGA, so other devices must know they +are already driven by a reprogrammed FPGA. + +If a carrier hosts slots that are driven by different FPGA devices, it +should register as a group only mezzanines that are driven by the same +FPGA, for the reason outlined above. + +Finally, the fmc_reprogram function calls the reprogram method (see +*note The API Offered by Carriers:: and also scans the memory area for +an SDB tree. You can pass -1 as sdb_entry to disable such scan. +Otherwise, the function fails if no tree is found at the specified +entry point. The function is meant to factorize common code, and by +the time
[PATCH V3 4/6] FMC: add a software mezzanine driver
This simple do-nothing mezzanine driver shows how to write a mezzanine
driver, that can also handle interrupts reported by the carrier.
Signed-off-by: Alessandro Rubini
Acked-by: Juan David Gonzalez Cobas
Acked-by: Emilio G. Cota
Acked-by: Samuel Iglesias Gonsalvez
---
Documentation/fmc/00-INDEX|3 +
Documentation/fmc/fmc-trivial.txt | 17 ++
drivers/fmc/Kconfig |7 +++
drivers/fmc/Makefile |1 +
drivers/fmc/fmc-trivial.c | 107 +
5 files changed, 135 insertions(+), 0 deletions(-)
create mode 100644 Documentation/fmc/fmc-trivial.txt
create mode 100644 drivers/fmc/fmc-trivial.c
diff --git a/Documentation/fmc/00-INDEX b/Documentation/fmc/00-INDEX
index 34df5cf..c22d687 100644
--- a/Documentation/fmc/00-INDEX
+++ b/Documentation/fmc/00-INDEX
@@ -27,3 +27,6 @@ identifiers.txt
fmc-fakedev.txt
- about drivers/fmc/fmc-fakedev.ko
+
+fmc-trivial.txt
+ - about drivers/fmc/fmc-trivial.ko
diff --git a/Documentation/fmc/fmc-trivial.txt
b/Documentation/fmc/fmc-trivial.txt
new file mode 100644
index 000..d1910bc
--- /dev/null
+++ b/Documentation/fmc/fmc-trivial.txt
@@ -0,0 +1,17 @@
+fmc-trivial
+===
+
+The simple module fmc-trivial is just a simple client that registers an
+interrupt handler. I used it to verify the basic mechanism of the FMC
+bus and how interrupts worked.
+
+The module implements the generic FMC parameters, so it can program a
+different gateware file in each card. The whole list of parameters it
+accepts are:
+
+`busid='
+`gateware='
+ Generic parameters. See mezzanine.txt
+
+
+This driver is worth reading, in my opinion.
diff --git a/drivers/fmc/Kconfig b/drivers/fmc/Kconfig
index 505e96b..7eacef9 100644
--- a/drivers/fmc/Kconfig
+++ b/drivers/fmc/Kconfig
@@ -25,4 +25,11 @@ config FMC_FAKEDEV
that can be rewritten at run time and usef for matching
mezzanines.
+config FMC_TRIVIAL
+ tristate "FMC trivial mezzanine driver (software testing)"
+ help
+ This is a fake mezzanine driver, to show how FMC works and test it.
+ The driver also handles interrupts (we used it with a real carrier
+ before the mezzanines were produced)
+
endif # FMC
diff --git a/drivers/fmc/Makefile b/drivers/fmc/Makefile
index 9832b79..52624e6 100644
--- a/drivers/fmc/Makefile
+++ b/drivers/fmc/Makefile
@@ -8,3 +8,4 @@ fmc-y += fru-parse.o
fmc-y += fmc-dump.o
obj-$(CONFIG_FMC_FAKEDEV) += fmc-fakedev.o
+obj-$(CONFIG_FMC_TRIVIAL) += fmc-trivial.o
diff --git a/drivers/fmc/fmc-trivial.c b/drivers/fmc/fmc-trivial.c
new file mode 100644
index 000..6c590f5
--- /dev/null
+++ b/drivers/fmc/fmc-trivial.c
@@ -0,0 +1,107 @@
+/*
+ * Copyright (C) 2012 CERN (www.cern.ch)
+ * Author: Alessandro Rubini
+ *
+ * Permission to use, copy, modify, and/or distribute this software for any
+ * purpose with or without fee is hereby granted, provided that the above
+ * copyright notice and this permission notice appear in all copies.
+ *
+ * The software is provided "as is"; the copyright holders disclaim
+ * all warranties and liabilities, to the extent permitted by
+ * applicable law.
+ */
+
+/* A trivial fmc driver that can load a gateware file and reports interrupts */
+#include
+#include
+#include
+#include
+#include
+
+static struct fmc_driver t_drv; /* initialized later */
+
+static irqreturn_t t_handler(int irq, void *dev_id)
+{
+ struct fmc_device *fmc = dev_id;
+
+ fmc->op->irq_ack(fmc);
+ dev_info(&fmc->dev, "received irq %i\n", irq);
+ return IRQ_HANDLED;
+}
+
+static struct fmc_gpio t_gpio[] = {
+ {
+ .gpio = FMC_GPIO_IRQ(0),
+ .mode = GPIOF_DIR_IN,
+ .irqmode = IRQF_TRIGGER_RISING,
+ }, {
+ .gpio = FMC_GPIO_IRQ(1),
+ .mode = GPIOF_DIR_IN,
+ .irqmode = IRQF_TRIGGER_RISING,
+ }
+};
+
+static int t_probe(struct fmc_device *fmc)
+{
+ int ret;
+ int index = 0;
+
+ if (fmc->op->validate)
+ index = fmc->op->validate(fmc, &t_drv);
+ if (index < 0)
+ return -EINVAL; /* not our device: invalid */
+
+ ret = fmc->op->irq_request(fmc, t_handler, "fmc-trivial", IRQF_SHARED);
+ if (ret < 0)
+ return ret;
+ /* ignore error code of call below, we really don't care */
+ fmc->op->gpio_config(fmc, t_gpio, ARRAY_SIZE(t_gpio));
+
+ /* Reprogram, if asked to. ESRCH == no filename specified */
+ ret = -ESRCH;
+ if (fmc->op->reprogram)
+ ret = fmc->op->reprogram(fmc, &t_drv, "");
+ if (ret == -ESRCH)
+ ret = 0;
+ if (ret < 0)
+ fmc->op->irq_free(fmc);
+
+ /* FIXME: reprogram LM32 too */
+ return ret;
+}
+
+static int t_remo
[PATCH V3 6/6] FMC: add a char-device mezzanine driver
This driver exports the memory area associated with the mezzanine card as a misc device, so users can access registers. Signed-off-by: Alessandro Rubini Acked-by: Juan David Gonzalez Cobas Acked-by: Emilio G. Cota Acked-by: Samuel Iglesias Gonsalvez --- Documentation/fmc/00-INDEX|5 +- Documentation/fmc/fmc-chardev.txt | 64 drivers/fmc/Kconfig |8 ++ drivers/fmc/Makefile |1 + drivers/fmc/fmc-chardev.c | 197 + 5 files changed, 274 insertions(+), 1 deletions(-) create mode 100644 Documentation/fmc/fmc-chardev.txt create mode 100644 drivers/fmc/fmc-chardev.c diff --git a/Documentation/fmc/00-INDEX b/Documentation/fmc/00-INDEX index 177c3e4..431c695 100644 --- a/Documentation/fmc/00-INDEX +++ b/Documentation/fmc/00-INDEX @@ -32,4 +32,7 @@ fmc-trivial.txt - about drivers/fmc/fmc-trivial.ko fmc-write-eeprom.txt -- about drivers/fmc/fmc-write-eeprom.ko + - about drivers/fmc/fmc-write-eeprom.ko + +fmc-chardev.txt + - about drivers/fmc/fmc-chardev.ko diff --git a/Documentation/fmc/fmc-chardev.txt b/Documentation/fmc/fmc-chardev.txt new file mode 100644 index 000..d9ccb27 --- /dev/null +++ b/Documentation/fmc/fmc-chardev.txt @@ -0,0 +1,64 @@ +fmc-chardev +=== + +This is a simple generic driver, that allows user access by means of a +character device (actually, one for each mezzanine it takes hold of). + +The char device is created as a misc device. Its name in /dev (as +created by udev) is the same name as the underlying FMC device. Thus, +the name can be a silly fmc- look-alike if the device has no +identifiers nor bus_id, a more specific fmc-0400 if the device has a +bus-specific address but no associated name, or something like +fdelay-0400 if the FMC core can rely on both a mezzanine name and a bus +address. + +Currently the driver only supports read and write: you can lseek to the +desired address and read or write a register. + +The driver assumes all registers are 32-bit in size, and only accepts a +single read or write per system call. However, as a result of Unix read +and write semantics, users can simply fread or fwrite bigger areas in +order to dump or store bigger memory areas. + +There is currently no support for mmap, user-space interrupt management +and DMA buffers. They may be added in later versions, if the need +arises. + +The example below shows raw access to a SPEC card programmed with its +golden FPGA file, that features an SDB structure at offset 256 - i.e. +64 words. The mezzanine's EEPROM in this case is not programmed, so the +default name is fmc-, and there are two cards in the system: + + spusa.root# insmod fmc-chardev.ko + [ 1073.339332] spec :02:00.0: Driver has no ID: matches all + [ 1073.345051] spec :02:00.0: Created misc device "fmc-0200" + [ 1073.350821] spec :04:00.0: Driver has no ID: matches all + [ 1073.356525] spec :04:00.0: Created misc device "fmc-0400" + spusa.root# ls -l /dev/fmc* + crw--- 1 root root 10, 58 Nov 20 19:23 /dev/fmc-0200 + crw--- 1 root root 10, 57 Nov 20 19:23 /dev/fmc-0400 + spusa.root# dd bs=4 skip=64 count=1 if=/dev/fmc-0200 2> /dev/null | od -t x1z + 000 2d 42 44 53 >-BDS< + 004 + +The simple program tools/fmc-mem in this package can access an FMC char +device and read or write a word or a whole area. Actually, the program +is not specific to FMC at all, it just uses lseek, read and write. + +Its first argument is the device name, the second the offset, the third +(if any) the value to write and the optional last argument that must +begin with "+" is the number of bytes to read or write. In case of +repeated reading data is written to stdout; repeated writes read from +stdin and the value argument is ignored. + +The following examples show reading the SDB magic number and the first +SDB record from a SPEC device programmed with its golden image: + + spusa.root# ./fmc-mem /dev/fmc-0200 100 + 5344422d + spusa.root# ./fmc-mem /dev/fmc-0200 100 +40 | od -Ax -t x1z + 00 2d 42 44 53 00 01 02 00 00 00 00 00 00 00 00 00 >-BDS< + 10 00 00 00 00 ff 01 00 00 00 00 00 00 51 06 00 00 >Q...< + 20 c9 42 a5 e6 02 00 00 00 11 05 12 20 2d 34 42 57 >.B. -4BW< + 30 73 6f 72 43 72 61 62 73 49 53 47 2d 00 20 20 20 >sorCrabsISG-. < + 40 diff --git a/drivers/fmc/Kconfig b/drivers/fmc/Kconfig index 2bb1953..c01cf45 100644 --- a/drivers/fmc/Kconfig +++ b/drivers/fmc/Kconfig @@ -40,4 +40,12 @@ config FMC_WRITE_EEPROM its binary and the function carrier->reprogram to actually do it. It is useful when the mezzanines are produced. +config FMC_CHARDEV + tristate "FMC mezzanine driver that registers a char device" + help + This
Re: [PATCH 2/8] FMC: add needed headers
> The use of the 'readl' and 'writel' identifiers here causes build errors on > architectures where those are macros. This renames the fields to > read32/write32 > to avoid the problem. Thanks. I'll apply the same to my repo and related drivers. Acked-by: Alessandro Rubini /alessandro -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [patch] FMC: NULL dereference on allocation failure
> If we don't allocate "arr" then the cleanup path will dereference it and > oops. You are right, thanks (acked). How is the procedure here? I don't have my own git tree on kernel.org for pull requests. Can this go through the janitors? (if it makes sense, I can try the procedure to have a tree, but last time I checked it was strictly denied to anyone). thanks /alessandro -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [patch -next] FMC: NULL dereference on allocation failure
>> +arr->record = kzalloc(sizeof(arr->record[0]) * n, GFP_KERNEL); >> +arr->subtree = kzalloc(sizeof(arr->subtree[0]) * n, GFP_KERNEL); > n comes from the hardware no? Yes. Length of hardware description array. > Maybe make these kcalloc too. I'm not a fan of kcalloc. I think it removes readability. I remeber kernel patches to swap the arguments, because people get them wrong. Even Kernighan said it was a design error (in "the practice of programming"). That said, I'm not the leader here. thanks /alessandro -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [patch] FMC: NULL dereference on allocation failure
> Apparently these are going through Greg K-H. I'll resend, with Greg > CC'd so he can pick it up from the mailing list. > > Could you add an entry to the MAINTAINERS file so that Greg will be > CC'd automatically using get_maintainer.pl? Ok. Added to my todo list. > Is there a dedicated list for FMC development? That would go in the > MAINTAINERS file as well. No, there is no list. Or "not yet". The project was born externally (on ohwr.org), mainly within the "white rabbit" research group. If it makes sense, we can have a public list, I'm all for it. thanks /alessandro -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [patch] FMC: fix error handling in probe() function
> The call to kzalloc() wasn't checked. > The dev_info() message dereferenced freed memory on error. > > Signed-off-by: Dan Carpenter Acked-by: Alessandro Rubini Thanks! -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: FMC: BUG: scheduling while atomic on boot
Hello. > I compiled FMC in to test it out, but when booting with it I get: Thank you for your report. I'll take a look tomorrow. I admit I only use it as a module (I'm on it even now, working on an ADC FMC board). Thanks again, I'll have a fix ASAP /alessandro -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 2/8] FMC: add needed headers
This set of headers comes from commit ab23167f (current master of the
project on ohwr.org). They define the basic data structures for FMC
and its SDB support.
Signed-off-by: Alessandro Rubini
Acked-by: Juan David Gonzalez Cobas
Acked-by: Emilio G. Cota
Acked-by: Samuel Iglesias Gonsalvez
---
include/linux/fmc-sdb.h | 36 +++
include/linux/fmc.h | 237 ++
include/linux/ipmi-fru.h | 135 ++
include/linux/sdb.h | 159 +++
4 files changed, 567 insertions(+), 0 deletions(-)
create mode 100644 include/linux/fmc-sdb.h
create mode 100644 include/linux/fmc.h
create mode 100644 include/linux/ipmi-fru.h
create mode 100644 include/linux/sdb.h
diff --git a/include/linux/fmc-sdb.h b/include/linux/fmc-sdb.h
new file mode 100644
index 000..1974317
--- /dev/null
+++ b/include/linux/fmc-sdb.h
@@ -0,0 +1,36 @@
+/*
+ * This file is separate from sdb.h, because I want that one to remain
+ * unchanged (as far as possible) from the official sdb distribution
+ *
+ * This file and associated functionality are a playground for me to
+ * understand stuff which will later be implemented in more generic places.
+ */
+#include
+
+/* This is the union of all currently defined types */
+union sdb_record {
+ struct sdb_interconnect ic;
+ struct sdb_device dev;
+ struct sdb_bridge bridge;
+ struct sdb_integration integr;
+ struct sdb_empty empty;
+};
+
+struct fmc_device;
+
+/* Every sdb table is turned into this structure */
+struct sdb_array {
+ int len;
+ int level;
+ unsigned long baseaddr;
+ struct fmc_device *fmc; /* the device that hosts it */
+ struct sdb_array *parent; /* NULL at root */
+ union sdb_record *record; /* copies of the struct */
+ struct sdb_array **subtree; /* only valid for bridge items */
+};
+
+extern int fmc_scan_sdb_tree(struct fmc_device *fmc, unsigned long address);
+extern void fmc_show_sdb_tree(const struct fmc_device *fmc);
+extern signed long fmc_find_sdb_device(struct sdb_array *tree, uint64_t vendor,
+ uint32_t device, unsigned long *sz);
+extern int fmc_free_sdb_tree(struct fmc_device *fmc);
diff --git a/include/linux/fmc.h b/include/linux/fmc.h
new file mode 100644
index 000..a3c4985
--- /dev/null
+++ b/include/linux/fmc.h
@@ -0,0 +1,237 @@
+/*
+ * Copyright (C) 2012 CERN (www.cern.ch)
+ * Author: Alessandro Rubini
+ *
+ * Released according to the GNU GPL, version 2 or any later version.
+ *
+ * This work is part of the White Rabbit project, a research effort led
+ * by CERN, the European Institute for Nuclear Research.
+ */
+#ifndef __LINUX_FMC_H__
+#define __LINUX_FMC_H__
+#include
+#include
+#include
+#include
+#include
+#include
+
+struct fmc_device;
+struct fmc_driver;
+
+/*
+ * This bus abstraction is developed separately from drivers, so we need
+ * to check the version of the data structures we receive.
+ */
+
+#define FMC_MAJOR 3
+#define FMC_MINOR 0
+#define FMC_VERSION((FMC_MAJOR << 16) | FMC_MINOR)
+#define __FMC_MAJOR(x) ((x) >> 16)
+#define __FMC_MINOR(x) ((x) & 0x)
+
+/*
+ * The device identification, as defined by the IPMI FRU (Field Replaceable
+ * Unit) includes four different strings to describe the device. Here we
+ * only match the "Board Manufacturer" and the "Board Product Name",
+ * ignoring the "Board Serial Number" and "Board Part Number". All 4 are
+ * expected to be strings, so they are treated as zero-terminated C strings.
+ * Unspecified string (NULL) means "any", so if both are unspecified this
+ * is a catch-all driver. So null entries are allowed and we use array
+ * and length. This is unlike pci and usb that use null-terminated arrays
+ */
+struct fmc_fru_id {
+ char *manufacturer;
+ char *product_name;
+};
+
+/*
+ * If the FPGA is already programmed (think Etherbone or the second
+ * SVEC slot), we can match on SDB devices in the memory image. This
+ * match uses an array of devices that must all be present, and the
+ * match is based on vendor and device only. Further checks are expected
+ * to happen in the probe function. Zero means "any" and catch-all is allowed.
+ */
+struct fmc_sdb_one_id {
+ uint64_t vendor;
+ uint32_t device;
+};
+struct fmc_sdb_id {
+ struct fmc_sdb_one_id *cores;
+ int cores_nr;
+};
+
+struct fmc_device_id {
+ struct fmc_fru_id *fru_id;
+ int fru_id_nr;
+ struct fmc_sdb_id *sdb_id;
+ int sdb_id_nr;
+};
+
+/* This sizes the module_param_array used by generic module parameters */
+#define FMC_MAX_CARDS 32
+
+/* The driver is a pretty simple thing */
+struct fmc_driver {
+ unsigned long version;
+ struct device_driver driver;
+ int (*probe)(struct fmc_device *);
+ int (*remove)(struct fmc_device
[PATCH 0/8] Support for FMC carriers and mezzanines
This patch-set includes the Linux bus abstraction for FMC (ANSI/VITA 57). I posted it on Feb 21 2013 as an RFC, and I only got an Acked-by about documentation by Rob Landley; I include that Acked-by in this patch set, even if there are some minor changes in the docs -- typos and new capabilities for the fmc-fakedev carrier module. I fixed the device release bug noted by Greg-KH (yes, I deserved being ridiculed for that). There are no other serious changes, and we are now running this in production as a backport to 2.6.24-rt. The whole patch-set is sent to lkml, Greg K H (for drivers/), Rob Landley and the linux-doc list (both for Documentation/). The code I'm submitting is currently maintained outside of the kernel proper. See http://www.ohwr.org/projects/fmc-bus/ . The public repository is at git://ohwr.org/fmc-projects/fmc-bus.git and the current manual is at http://www.ohwr.org/attachments/download/2124/fmc-bus-2013-05.1-release.pdf The following text is an almost verbatim copy of parts of our documentation, as included in the fmc-bus package. FMC (FPGA Mezzanine Card) is the standard we use for our I/O devices, in the context of White Rabbit and related hardware. In our I/O environments we need to write drivers for each mezzanine card, and such drivers must work independent of the carrier being used. To achieve this, we abstract the FMC interface. We have a carrier for PCI-E called SPEC and one for VME called SVEC, but more are planned. Also, we support stand-alone devices (usually plugged on a SPEC card), controlled through Etherbone, developed by GSI. FMC is a standard developed by the VME consortium called VITA (VMEbus International Trade Association and ratified by ANSI, the American National Standard Institute. The official documentation is called "ANSI-VITA 57.1". The FMC card is an almost square PCB, around 70x75 millimeters, that is called mezzanine in code and documentation under drivers/fmc. It usually lives plugged into into another PCB for power supply and control; such bigger circuit board is called carrier from now on, and a single carrier may host more than one mezzanine. In the typical application the mezzanine is mostly analog while the carrier is mostly digital, and hosts an FPGA that must be programmed to match the specific mezzanine and the desired application. Thus, you may need to load different FPGA images to drive different instances of the same mezzanine. FMC, as such, is not a bus in the usual meaning of the term, because most carriers have only one connector, and carriers with several connectors have completely separate electrical connections to them. This package, however, implements a bus as a software abstraction. SDB (Self Describing Bus) is a set of data structures that we use for enumerating the internal structure of an FPGA image. We also use it as a filesystem inside the FMC EEPROM. SDB is not mandatory for use of this FMC kernel bus, but if you have SDB this package can make good use of it. SDB itself is developed in the fpga-config-space OHWR project. The link to the repository is `git://ohwr.org/hdl-core-lib/fpga-config-space.git' and what is used in this project lives in the sdbfs subdirectory in there. Alessandro Rubini (8): FMC: create drivers/fmc and toplevel Kconfig question FMC: add needed headers FMC: add core bus driver FMC: add documentation for the core FMC: add a software carrier driver FMC: add a software mezzanine driver FMC: add a driver to write mezzanine EEPROM FMC: add a char-device mezzanine driver Documentation/00-INDEX |2 + Documentation/fmc/00-INDEX | 38 Documentation/fmc/API.txt | 47 + Documentation/fmc/FMC-and-SDB.txt | 88 Documentation/fmc/carrier.txt | 311 Documentation/fmc/fmc-chardev.txt | 64 ++ Documentation/fmc/fmc-fakedev.txt | 36 Documentation/fmc/fmc-trivial.txt | 17 ++ Documentation/fmc/fmc-write-eeprom.txt | 125 Documentation/fmc/identifiers.txt | 168 +++ Documentation/fmc/mezzanine.txt| 123 +++ Documentation/fmc/parameters.txt | 56 + MAINTAINERS|9 + drivers/Kconfig|2 + drivers/Makefile |1 + drivers/fmc/Kconfig| 51 + drivers/fmc/Makefile | 13 ++ drivers/fmc/fmc-chardev.c | 197 ++ drivers/fmc/fmc-core.c | 296 +++ drivers/fmc/fmc-dump.c | 100 + drivers/fmc/fmc-fakedev.c | 349 drivers/fmc/fmc-match.c| 114 +++ drivers/fmc/fmc-sdb.c | 265 drivers/fmc/fmc-trivial.c | 101 + drivers/fm
[PATCH 1/8] FMC: create drivers/fmc and toplevel Kconfig question
This commit creates the drivers/fmc directory and puts the necessary
hooks for kbuild and kconfig. The code is currently a placeholder
that only registers an empty bus.
Signed-off-by: Alessandro Rubini
Acked-by: Juan David Gonzalez Cobas
Acked-by: Emilio G. Cota
Acked-by: Samuel Iglesias Gonsalvez
---
MAINTAINERS|9 +
drivers/Kconfig|2 ++
drivers/Makefile |1 +
drivers/fmc/Kconfig| 17 +
drivers/fmc/Makefile |4
drivers/fmc/fmc-core.c | 24
6 files changed, 57 insertions(+), 0 deletions(-)
create mode 100644 drivers/fmc/Kconfig
create mode 100644 drivers/fmc/Makefile
create mode 100644 drivers/fmc/fmc-core.c
diff --git a/MAINTAINERS b/MAINTAINERS
index 8d97b3e..10ebdfc 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -3322,6 +3322,15 @@ T: git
git://git.kernel.org/pub/scm/linux/kernel/git/jikos/floppy.git
S: Odd fixes
F: drivers/block/floppy.c
+FMC SUBSYSTEM
+M: Alessandro Rubini
+W: http://www.ohwr.org/projects/fmc-bus
+S: Supported
+F: drivers/fmc/
+F: include/linux/fmc*.h
+F: include/linux/ipmi-fru.h
+K: fmc_d.*register
+
FPU EMULATOR
M: Bill Metzenthen
W: http://floatingpoint.sourceforge.net/emulator/index.html
diff --git a/drivers/Kconfig b/drivers/Kconfig
index b8ec9cf..aa43b91 100644
--- a/drivers/Kconfig
+++ b/drivers/Kconfig
@@ -164,4 +164,6 @@ source "drivers/ipack/Kconfig"
source "drivers/reset/Kconfig"
+source "drivers/fmc/Kconfig"
+
endmenu
diff --git a/drivers/Makefile b/drivers/Makefile
index bbf3810..ab93de8 100644
--- a/drivers/Makefile
+++ b/drivers/Makefile
@@ -151,3 +151,4 @@ obj-$(CONFIG_IIO) += iio/
obj-$(CONFIG_VME_BUS) += vme/
obj-$(CONFIG_IPACK_BUS)+= ipack/
obj-$(CONFIG_NTB) += ntb/
+obj-$(CONFIG_FMC) += fmc/
diff --git a/drivers/fmc/Kconfig b/drivers/fmc/Kconfig
new file mode 100644
index 000..e287902
--- /dev/null
+++ b/drivers/fmc/Kconfig
@@ -0,0 +1,17 @@
+#
+# FMC (ANSI-VITA 57.1) bus support
+#
+
+menuconfig FMC
+ tristate "FMC support"
+ help
+
+ FMC (FPGA Mezzanine Carrier) is a mechanical and electrical
+ standard for mezzanine cards that plug into a carrier board.
+ This kernel subsystem supports the matching between carrier
+ and mezzanine based on identifiers stored in the internal I2C
+ EEPROM, as well as having carrier-independent drivers.
+
+ The framework was born outside of the kernel and at this time
+ the off-tree code base is more complete. Code and documentation
+ is at git://ohwr.org/fmc-projects/fmc-bus.git .
diff --git a/drivers/fmc/Makefile b/drivers/fmc/Makefile
new file mode 100644
index 000..a2784d8
--- /dev/null
+++ b/drivers/fmc/Makefile
@@ -0,0 +1,4 @@
+
+obj-$(CONFIG_FMC) += fmc.o
+
+fmc-y = fmc-core.o
diff --git a/drivers/fmc/fmc-core.c b/drivers/fmc/fmc-core.c
new file mode 100644
index 000..fc3547f
--- /dev/null
+++ b/drivers/fmc/fmc-core.c
@@ -0,0 +1,24 @@
+/* Temporary placeholder so the empty code can build */
+#include
+#include
+#include
+#include
+
+static struct bus_type fmc_bus_type = {
+ .name = "fmc",
+};
+
+static int fmc_init(void)
+{
+ return bus_register(&fmc_bus_type);
+}
+
+static void fmc_exit(void)
+{
+ bus_unregister(&fmc_bus_type);
+}
+
+module_init(fmc_init);
+module_exit(fmc_exit);
+
+MODULE_LICENSE("GPL");
--
1.7.7.2
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 5/8] FMC: add a software carrier driver
This fake carrier is designed to help FMC users understand how a carrier driver works, and to experiment the behaviour with EEPROM reprogramming (with a mezzanine driver commited later). This carrier can register up to 4 (fake) mezzanines. We have real carriers (both on PCI-E and VME), but they are bigger things and are not part of this submission. Signed-off-by: Alessandro Rubini Acked-by: Juan David Gonzalez Cobas Acked-by: Emilio G. Cota Acked-by: Samuel Iglesias Gonsalvez --- Documentation/fmc/00-INDEX|3 + Documentation/fmc/fmc-fakedev.txt | 36 drivers/fmc/Kconfig | 11 ++ drivers/fmc/Makefile |2 + drivers/fmc/fmc-fakedev.c | 349 + 5 files changed, 401 insertions(+), 0 deletions(-) create mode 100644 Documentation/fmc/fmc-fakedev.txt create mode 100644 drivers/fmc/fmc-fakedev.c diff --git a/Documentation/fmc/00-INDEX b/Documentation/fmc/00-INDEX index 71304b7..34df5cf 100644 --- a/Documentation/fmc/00-INDEX +++ b/Documentation/fmc/00-INDEX @@ -24,3 +24,6 @@ mezzanine.txt identifiers.txt - how identification and matching works + +fmc-fakedev.txt + - about drivers/fmc/fmc-fakedev.ko diff --git a/Documentation/fmc/fmc-fakedev.txt b/Documentation/fmc/fmc-fakedev.txt new file mode 100644 index 000..e85b74a --- /dev/null +++ b/Documentation/fmc/fmc-fakedev.txt @@ -0,0 +1,36 @@ +fmc-fakedev +=== + +This package includes a software-only device, called fmc-fakedev, which +is able to register up to 4 mezzanines (by default it registers one). +Unlike the SPEC driver, which creates an FMC device for each PCI cards +it manages, this module creates a single instance of its set of +mezzanines. + +It is meant as the simplest possible example of how a driver should be +written, and it includes a fake EEPROM image (built using the tools +described in *note FMC Identification::),, which by default is +replicated for each fake mezzanine. + +You can also use this device to verify the match algorithms, by asking +it to test your own EEPROM image. You can provide the image by means of +the eeprom= module parameter: the new EEPROM image is loaded, as usual, +by means of the firmware loader. This example shows the defaults and a +custom EEPROM image: + + spusa.root# insmod fmc-fakedev.ko + [ 99.971247] fake-fmc-carrier: mezzanine 0 + [ 99.975393] Manufacturer: fake-vendor + [ 99.979624] Product name: fake-design-for-testing + spusa.root# rmmod fmc-fakedev + spusa.root# insmod fmc-fakedev.ko eeprom=fdelay-eeprom.bin + [ 121.447464] fake-fmc-carrier: Mezzanine 0: eeprom "fdelay-eeprom.bin" + [ 121.462725] fake-fmc-carrier: mezzanine 0 + [ 121.466858] Manufacturer: CERN + [ 121.470477] Product name: FmcDelay1ns4cha + spusa.root# rmmod fmc-fakedev + +After loading the device, you can use the write_ee method do modify its +own internal fake EEPROM: whenever the image is overwritten starting at +offset 0, the module will unregister and register again the FMC device. +This is shown in fmc-write-eeprom.txt diff --git a/drivers/fmc/Kconfig b/drivers/fmc/Kconfig index e287902..505e96b 100644 --- a/drivers/fmc/Kconfig +++ b/drivers/fmc/Kconfig @@ -15,3 +15,14 @@ menuconfig FMC The framework was born outside of the kernel and at this time the off-tree code base is more complete. Code and documentation is at git://ohwr.org/fmc-projects/fmc-bus.git . + +if FMC + +config FMC_FAKEDEV + tristate "FMC fake device (software testing)" + help + This is a fake carrier, bringing a default EEPROM content + that can be rewritten at run time and usef for matching + mezzanines. + +endif # FMC diff --git a/drivers/fmc/Makefile b/drivers/fmc/Makefile index df98939..9832b79 100644 --- a/drivers/fmc/Makefile +++ b/drivers/fmc/Makefile @@ -6,3 +6,5 @@ fmc-y += fmc-match.o fmc-y += fmc-sdb.o fmc-y += fru-parse.o fmc-y += fmc-dump.o + +obj-$(CONFIG_FMC_FAKEDEV) += fmc-fakedev.o diff --git a/drivers/fmc/fmc-fakedev.c b/drivers/fmc/fmc-fakedev.c new file mode 100644 index 000..a06e0e7 --- /dev/null +++ b/drivers/fmc/fmc-fakedev.c @@ -0,0 +1,349 @@ +/* + * Copyright (C) 2012 CERN (www.cern.ch) + * Author: Alessandro Rubini + * + * Released to the public domain, as example to be reused + */ +#include +#include +#include +#include +#include +#include +#include +#include +#include + +#define FF_EEPROM_SIZE 8192/* The standard eeprom size */ +#define FF_MAX_MEZZANINES 4 /* Fakes a multi-mezzanine carrier */ + +/* The user can pass up to 4 names of eeprom images to load */ +static char *ff_eeprom[FF_MAX_MEZZANINES]; +static int ff_nr_eeprom; +module_param_array_named(eeprom, ff_eeprom, charp, &ff_nr_eeprom, 0444); + +/* The user can ask for a multi-mezzanine carrier, with the default eeprom */ +static int ff_nr_dev
[PATCH 4/8] FMC: add documentation for the core
This is selected sections of the current manual for fmc-bus, as developed outside of the kernel before submission. Like the other patches in this set, it corresponds to commit ab23167f of the repository at ohwr.org Signed-off-by: Alessandro Rubini Acked-by: Juan David Gonzalez Cobas Acked-by: Emilio G. Cota Acked-by: Samuel Iglesias Gonsalvez Acked-by: Rob Landley --- Documentation/00-INDEX|2 + Documentation/fmc/00-INDEX| 26 +++ Documentation/fmc/API.txt | 47 ++ Documentation/fmc/FMC-and-SDB.txt | 88 +++ Documentation/fmc/carrier.txt | 311 + Documentation/fmc/identifiers.txt | 168 Documentation/fmc/mezzanine.txt | 123 +++ Documentation/fmc/parameters.txt | 56 +++ 8 files changed, 821 insertions(+), 0 deletions(-) create mode 100644 Documentation/fmc/00-INDEX create mode 100644 Documentation/fmc/API.txt create mode 100644 Documentation/fmc/FMC-and-SDB.txt create mode 100644 Documentation/fmc/carrier.txt create mode 100644 Documentation/fmc/identifiers.txt create mode 100644 Documentation/fmc/mezzanine.txt create mode 100644 Documentation/fmc/parameters.txt diff --git a/Documentation/00-INDEX b/Documentation/00-INDEX index 45b3df9..0c4cc68 100644 --- a/Documentation/00-INDEX +++ b/Documentation/00-INDEX @@ -187,6 +187,8 @@ firmware_class/ - request_firmware() hotplug interface info. flexible-arrays.txt - how to make use of flexible sized arrays in linux +fmc/ + - information about the FMC bus abstraction frv/ - Fujitsu FR-V Linux documentation. futex-requeue-pi.txt diff --git a/Documentation/fmc/00-INDEX b/Documentation/fmc/00-INDEX new file mode 100644 index 000..71304b7 --- /dev/null +++ b/Documentation/fmc/00-INDEX @@ -0,0 +1,26 @@ + +Documentation in this directory comes from sections of the manual we +wrote for the externally-developed fmc-bus package. The complete +manual as of today (2013-02) is available in PDF format at +http://www.ohwr.org/projects/fmc-bus/files + +00-INDEX + - this file. + +FMC-and-SDB.txt + - What are FMC and SDB, basic concepts for this framework + +API.txt + - The functions that are exported by the bus driver + +parameters.txt + - The module parameters + +carrier.txt + - writing a carrier (a device) + +mezzanine.txt + - writing code for your mezzanine (a driver) + +identifiers.txt + - how identification and matching works diff --git a/Documentation/fmc/API.txt b/Documentation/fmc/API.txt new file mode 100644 index 000..06b06b92 --- /dev/null +++ b/Documentation/fmc/API.txt @@ -0,0 +1,47 @@ +Functions Exported by fmc.ko + + +The FMC core exports the usual 4 functions that are needed for a bus to +work, and a few more: + +int fmc_driver_register(struct fmc_driver *drv); +void fmc_driver_unregister(struct fmc_driver *drv); +int fmc_device_register(struct fmc_device *fmc); +void fmc_device_unregister(struct fmc_device *fmc); + +int fmc_device_register_n(struct fmc_device **fmc, int n); +void fmc_device_unregister_n(struct fmc_device **fmc, int n); + +uint32_t fmc_readl(struct fmc_device *fmc, int offset); +void fmc_writel(struct fmc_device *fmc, uint32_t val, int off); +void *fmc_get_drvdata(struct fmc_device *fmc); +void fmc_set_drvdata(struct fmc_device *fmc, void *data); + +int fmc_reprogram(struct fmc_device *f, struct fmc_driver *d, char *gw, + int sdb_entry); + +The data structure that describe a device is detailed in *note FMC +Device::, the one that describes a driver is detailed in *note FMC +Driver::. Please note that structures of type fmc_device must be +allocated by the caller, but must not be released after unregistering. +The fmc-bus itself takes care of releasing the structure when their use +count reaches zero - actually, the device model does that in lieu of us. + +The functions to register and unregister n devices are meant to be used +by carriers that host more than one mezzanine. The devices must all be +registered at the same time because if the FPGA is reprogrammed, all +devices in the array are affected. Usually, the driver matching the +first device will reprogram the FPGA, so other devices must know they +are already driven by a reprogrammed FPGA. + +If a carrier hosts slots that are driven by different FPGA devices, it +should register as a group only mezzanines that are driven by the same +FPGA, for the reason outlined above. + +Finally, the fmc_reprogram function calls the reprogram method (see +*note The API Offered by Carriers:: and also scans the memory area for +an SDB tree. You can pass -1 as sdb_entry to disable such scan. +Otherwise, the function fails if no tree is found at the specified +entry point. The function is meant to factorize common code, and by +the time
[PATCH 3/8] FMC: add core bus driver
This module offers registration services for both carriers
(i.e. devices) and mezzanines (i.e. drivers). The matching for devices
and drivers is performed according to the IPMI standard for FRU
devices (Field Replaceable Units).
The code includes support for parsing an SDB tree if present in the FPGA,
and dumping it for diagnostics. SDB is not mandatory.
Files in this commit correspond to commit ab23167f in the master branch
of the project hosted on ohwr.org.
Signed-off-by: Alessandro Rubini
Acked-by: Juan David Gonzalez Cobas
Acked-by: Emilio G. Cota
Acked-by: Samuel Iglesias Gonsalvez
---
drivers/fmc/Makefile|4 +
drivers/fmc/fmc-core.c | 274 ++-
drivers/fmc/fmc-dump.c | 100 +
drivers/fmc/fmc-match.c | 114
drivers/fmc/fmc-sdb.c | 265 +
drivers/fmc/fru-parse.c | 82 ++
6 files changed, 838 insertions(+), 1 deletions(-)
create mode 100644 drivers/fmc/fmc-dump.c
create mode 100644 drivers/fmc/fmc-match.c
create mode 100644 drivers/fmc/fmc-sdb.c
create mode 100644 drivers/fmc/fru-parse.c
diff --git a/drivers/fmc/Makefile b/drivers/fmc/Makefile
index a2784d8..df98939 100644
--- a/drivers/fmc/Makefile
+++ b/drivers/fmc/Makefile
@@ -2,3 +2,7 @@
obj-$(CONFIG_FMC) += fmc.o
fmc-y = fmc-core.o
+fmc-y += fmc-match.o
+fmc-y += fmc-sdb.o
+fmc-y += fru-parse.o
+fmc-y += fmc-dump.o
diff --git a/drivers/fmc/fmc-core.c b/drivers/fmc/fmc-core.c
index fc3547f..f4c8801 100644
--- a/drivers/fmc/fmc-core.c
+++ b/drivers/fmc/fmc-core.c
@@ -1,13 +1,285 @@
-/* Temporary placeholder so the empty code can build */
+/*
+ * Copyright (C) 2012 CERN (www.cern.ch)
+ * Author: Alessandro Rubini
+ *
+ * Released according to the GNU GPL, version 2 or any later version.
+ *
+ * This work is part of the White Rabbit project, a research effort led
+ * by CERN, the European Institute for Nuclear Research.
+ */
#include
#include
+#include
#include
#include
+#include
+
+static int fmc_check_version(unsigned long version, const char *name)
+{
+ if (__FMC_MAJOR(version) != FMC_MAJOR) {
+ pr_err("%s: \"%s\" has wrong major (has %li, expected %i)\n",
+ __func__, name, __FMC_MAJOR(version), FMC_MAJOR);
+ return -EINVAL;
+ }
+
+ if (__FMC_MINOR(version) != FMC_MINOR)
+ pr_info("%s: \"%s\" has wrong minor (has %li, expected %i)\n",
+ __func__, name, __FMC_MINOR(version), FMC_MINOR);
+ return 0;
+}
+
+static int fmc_uevent(struct device *dev, struct kobj_uevent_env *env)
+{
+ /* struct fmc_device *fdev = to_fmc_device(dev); */
+
+ /* FIXME: The MODALIAS */
+ add_uevent_var(env, "MODALIAS=%s", "fmc");
+ return 0;
+}
+
+static int fmc_probe(struct device *dev)
+{
+ struct fmc_driver *fdrv = to_fmc_driver(dev->driver);
+ struct fmc_device *fdev = to_fmc_device(dev);
+
+ return fdrv->probe(fdev);
+}
+
+static int fmc_remove(struct device *dev)
+{
+ struct fmc_driver *fdrv = to_fmc_driver(dev->driver);
+ struct fmc_device *fdev = to_fmc_device(dev);
+
+ return fdrv->remove(fdev);
+}
+
+static void fmc_shutdown(struct device *dev)
+{
+ /* not implemented but mandatory */
+}
static struct bus_type fmc_bus_type = {
.name = "fmc",
+ .match = fmc_match,
+ .uevent = fmc_uevent,
+ .probe = fmc_probe,
+ .remove = fmc_remove,
+ .shutdown = fmc_shutdown,
};
+static void fmc_release(struct device *dev)
+{
+ struct fmc_device *fmc = container_of(dev, struct fmc_device, dev);
+
+ kfree(fmc);
+}
+
+/*
+ * The eeprom is exported in sysfs, through a binary attribute
+ */
+
+static ssize_t fmc_read_eeprom(struct file *file, struct kobject *kobj,
+ struct bin_attribute *bin_attr,
+ char *buf, loff_t off, size_t count)
+{
+ struct device *dev;
+ struct fmc_device *fmc;
+ int eelen;
+
+ dev = container_of(kobj, struct device, kobj);
+ fmc = container_of(dev, struct fmc_device, dev);
+ eelen = fmc->eeprom_len;
+ if (off > eelen)
+ return -ESPIPE;
+ if (off == eelen)
+ return 0; /* EOF */
+ if (off + count > eelen)
+ count = eelen - off;
+ memcpy(buf, fmc->eeprom + off, count);
+ return count;
+}
+
+static struct bin_attribute fmc_eeprom_attr = {
+ .attr = { .name = "eeprom", .mode = S_IRUGO, },
+ .size = 8192, /* more or less standard */
+ .read = fmc_read_eeprom,
+};
+
+/*
+ * Functions for client modules follow
+ */
+
+int fmc_driver_register(struct fmc_driver *drv)
+{
+ if (fmc_check_version(drv->version, drv->driver.name))
+ return -EINVAL;
+ drv-&g
[PATCH 6/8] FMC: add a software mezzanine driver
This simple do-nothing mezzanine driver shows how to write a mezzanine
driver, that can also handle interrupts reported by the carrier.
Signed-off-by: Alessandro Rubini
Acked-by: Juan David Gonzalez Cobas
Acked-by: Emilio G. Cota
Acked-by: Samuel Iglesias Gonsalvez
---
Documentation/fmc/00-INDEX|3 +
Documentation/fmc/fmc-trivial.txt | 17 ++
drivers/fmc/Kconfig |7 +++
drivers/fmc/Makefile |1 +
drivers/fmc/fmc-trivial.c | 101 +
5 files changed, 129 insertions(+), 0 deletions(-)
create mode 100644 Documentation/fmc/fmc-trivial.txt
create mode 100644 drivers/fmc/fmc-trivial.c
diff --git a/Documentation/fmc/00-INDEX b/Documentation/fmc/00-INDEX
index 34df5cf..c22d687 100644
--- a/Documentation/fmc/00-INDEX
+++ b/Documentation/fmc/00-INDEX
@@ -27,3 +27,6 @@ identifiers.txt
fmc-fakedev.txt
- about drivers/fmc/fmc-fakedev.ko
+
+fmc-trivial.txt
+ - about drivers/fmc/fmc-trivial.ko
diff --git a/Documentation/fmc/fmc-trivial.txt
b/Documentation/fmc/fmc-trivial.txt
new file mode 100644
index 000..d1910bc
--- /dev/null
+++ b/Documentation/fmc/fmc-trivial.txt
@@ -0,0 +1,17 @@
+fmc-trivial
+===
+
+The simple module fmc-trivial is just a simple client that registers an
+interrupt handler. I used it to verify the basic mechanism of the FMC
+bus and how interrupts worked.
+
+The module implements the generic FMC parameters, so it can program a
+different gateware file in each card. The whole list of parameters it
+accepts are:
+
+`busid='
+`gateware='
+ Generic parameters. See mezzanine.txt
+
+
+This driver is worth reading, in my opinion.
diff --git a/drivers/fmc/Kconfig b/drivers/fmc/Kconfig
index 505e96b..7eacef9 100644
--- a/drivers/fmc/Kconfig
+++ b/drivers/fmc/Kconfig
@@ -25,4 +25,11 @@ config FMC_FAKEDEV
that can be rewritten at run time and usef for matching
mezzanines.
+config FMC_TRIVIAL
+ tristate "FMC trivial mezzanine driver (software testing)"
+ help
+ This is a fake mezzanine driver, to show how FMC works and test it.
+ The driver also handles interrupts (we used it with a real carrier
+ before the mezzanines were produced)
+
endif # FMC
diff --git a/drivers/fmc/Makefile b/drivers/fmc/Makefile
index 9832b79..52624e6 100644
--- a/drivers/fmc/Makefile
+++ b/drivers/fmc/Makefile
@@ -8,3 +8,4 @@ fmc-y += fru-parse.o
fmc-y += fmc-dump.o
obj-$(CONFIG_FMC_FAKEDEV) += fmc-fakedev.o
+obj-$(CONFIG_FMC_TRIVIAL) += fmc-trivial.o
diff --git a/drivers/fmc/fmc-trivial.c b/drivers/fmc/fmc-trivial.c
new file mode 100644
index 000..d91b28c
--- /dev/null
+++ b/drivers/fmc/fmc-trivial.c
@@ -0,0 +1,101 @@
+/*
+ * Copyright (C) 2012 CERN (www.cern.ch)
+ * Author: Alessandro Rubini
+ *
+ * Released to the public domain, as example to be reused
+ */
+
+/* A trivial fmc driver that can load a gateware file and reports interrupts */
+#include
+#include
+#include
+#include
+#include
+
+static struct fmc_driver t_drv; /* initialized later */
+
+static irqreturn_t t_handler(int irq, void *dev_id)
+{
+ struct fmc_device *fmc = dev_id;
+
+ fmc->op->irq_ack(fmc);
+ dev_info(&fmc->dev, "received irq %i\n", irq);
+ return IRQ_HANDLED;
+}
+
+static struct fmc_gpio t_gpio[] = {
+ {
+ .gpio = FMC_GPIO_IRQ(0),
+ .mode = GPIOF_DIR_IN,
+ .irqmode = IRQF_TRIGGER_RISING,
+ }, {
+ .gpio = FMC_GPIO_IRQ(1),
+ .mode = GPIOF_DIR_IN,
+ .irqmode = IRQF_TRIGGER_RISING,
+ }
+};
+
+static int t_probe(struct fmc_device *fmc)
+{
+ int ret;
+ int index = 0;
+
+ if (fmc->op->validate)
+ index = fmc->op->validate(fmc, &t_drv);
+ if (index < 0)
+ return -EINVAL; /* not our device: invalid */
+
+ ret = fmc->op->irq_request(fmc, t_handler, "fmc-trivial", IRQF_SHARED);
+ if (ret < 0)
+ return ret;
+ /* ignore error code of call below, we really don't care */
+ fmc->op->gpio_config(fmc, t_gpio, ARRAY_SIZE(t_gpio));
+
+ /* Reprogram, if asked to. ESRCH == no filename specified */
+ ret = -ESRCH;
+ if (fmc->op->reprogram)
+ ret = fmc->op->reprogram(fmc, &t_drv, "");
+ if (ret == -ESRCH)
+ ret = 0;
+ if (ret < 0)
+ fmc->op->irq_free(fmc);
+
+ /* FIXME: reprogram LM32 too */
+ return ret;
+}
+
+static int t_remove(struct fmc_device *fmc)
+{
+ fmc->op->irq_free(fmc);
+ return 0;
+}
+
+static struct fmc_driver t_drv = {
+ .version = FMC_VERSION,
+ .driver.name = KBUILD_MODNAME,
+ .probe = t_probe,
+ .remove = t_remove,
+ /* no table, as the current match just matches everything */
+};
+
+ /* W
[PATCH 8/8] FMC: add a char-device mezzanine driver
This driver exports the memory area associated with the mezzanine card as a misc device, so users can access registers. Signed-off-by: Alessandro Rubini Acked-by: Juan David Gonzalez Cobas Acked-by: Emilio G. Cota Acked-by: Samuel Iglesias Gonsalvez --- Documentation/fmc/00-INDEX|5 +- Documentation/fmc/fmc-chardev.txt | 64 drivers/fmc/Kconfig |8 ++ drivers/fmc/Makefile |1 + drivers/fmc/fmc-chardev.c | 197 + 5 files changed, 274 insertions(+), 1 deletions(-) create mode 100644 Documentation/fmc/fmc-chardev.txt create mode 100644 drivers/fmc/fmc-chardev.c diff --git a/Documentation/fmc/00-INDEX b/Documentation/fmc/00-INDEX index 177c3e4..431c695 100644 --- a/Documentation/fmc/00-INDEX +++ b/Documentation/fmc/00-INDEX @@ -32,4 +32,7 @@ fmc-trivial.txt - about drivers/fmc/fmc-trivial.ko fmc-write-eeprom.txt -- about drivers/fmc/fmc-write-eeprom.ko + - about drivers/fmc/fmc-write-eeprom.ko + +fmc-chardev.txt + - about drivers/fmc/fmc-chardev.ko diff --git a/Documentation/fmc/fmc-chardev.txt b/Documentation/fmc/fmc-chardev.txt new file mode 100644 index 000..d9ccb27 --- /dev/null +++ b/Documentation/fmc/fmc-chardev.txt @@ -0,0 +1,64 @@ +fmc-chardev +=== + +This is a simple generic driver, that allows user access by means of a +character device (actually, one for each mezzanine it takes hold of). + +The char device is created as a misc device. Its name in /dev (as +created by udev) is the same name as the underlying FMC device. Thus, +the name can be a silly fmc- look-alike if the device has no +identifiers nor bus_id, a more specific fmc-0400 if the device has a +bus-specific address but no associated name, or something like +fdelay-0400 if the FMC core can rely on both a mezzanine name and a bus +address. + +Currently the driver only supports read and write: you can lseek to the +desired address and read or write a register. + +The driver assumes all registers are 32-bit in size, and only accepts a +single read or write per system call. However, as a result of Unix read +and write semantics, users can simply fread or fwrite bigger areas in +order to dump or store bigger memory areas. + +There is currently no support for mmap, user-space interrupt management +and DMA buffers. They may be added in later versions, if the need +arises. + +The example below shows raw access to a SPEC card programmed with its +golden FPGA file, that features an SDB structure at offset 256 - i.e. +64 words. The mezzanine's EEPROM in this case is not programmed, so the +default name is fmc-, and there are two cards in the system: + + spusa.root# insmod fmc-chardev.ko + [ 1073.339332] spec :02:00.0: Driver has no ID: matches all + [ 1073.345051] spec :02:00.0: Created misc device "fmc-0200" + [ 1073.350821] spec :04:00.0: Driver has no ID: matches all + [ 1073.356525] spec :04:00.0: Created misc device "fmc-0400" + spusa.root# ls -l /dev/fmc* + crw--- 1 root root 10, 58 Nov 20 19:23 /dev/fmc-0200 + crw--- 1 root root 10, 57 Nov 20 19:23 /dev/fmc-0400 + spusa.root# dd bs=4 skip=64 count=1 if=/dev/fmc-0200 2> /dev/null | od -t x1z + 000 2d 42 44 53 >-BDS< + 004 + +The simple program tools/fmc-mem in this package can access an FMC char +device and read or write a word or a whole area. Actually, the program +is not specific to FMC at all, it just uses lseek, read and write. + +Its first argument is the device name, the second the offset, the third +(if any) the value to write and the optional last argument that must +begin with "+" is the number of bytes to read or write. In case of +repeated reading data is written to stdout; repeated writes read from +stdin and the value argument is ignored. + +The following examples show reading the SDB magic number and the first +SDB record from a SPEC device programmed with its golden image: + + spusa.root# ./fmc-mem /dev/fmc-0200 100 + 5344422d + spusa.root# ./fmc-mem /dev/fmc-0200 100 +40 | od -Ax -t x1z + 00 2d 42 44 53 00 01 02 00 00 00 00 00 00 00 00 00 >-BDS< + 10 00 00 00 00 ff 01 00 00 00 00 00 00 51 06 00 00 >Q...< + 20 c9 42 a5 e6 02 00 00 00 11 05 12 20 2d 34 42 57 >.B. -4BW< + 30 73 6f 72 43 72 61 62 73 49 53 47 2d 00 20 20 20 >sorCrabsISG-. < + 40 diff --git a/drivers/fmc/Kconfig b/drivers/fmc/Kconfig index 2bb1953..c01cf45 100644 --- a/drivers/fmc/Kconfig +++ b/drivers/fmc/Kconfig @@ -40,4 +40,12 @@ config FMC_WRITE_EEPROM its binary and the function carrier->reprogram to actually do it. It is useful when the mezzanines are produced. +config FMC_CHARDEV + tristate "FMC mezzanine driver that registers a char device" + help + This
[PATCH 7/8] FMC: add a driver to write mezzanine EEPROM
This driver allows to reprogram the EEPROM in a mezzanine, to store its own identifiers during manufacturing or to save other useful data. Signed-off-by: Alessandro Rubini Acked-by: Juan David Gonzalez Cobas Acked-by: Emilio G. Cota Acked-by: Samuel Iglesias Gonsalvez --- Documentation/fmc/00-INDEX |3 + Documentation/fmc/fmc-write-eeprom.txt | 125 ++ drivers/fmc/Kconfig|8 ++ drivers/fmc/Makefile |1 + drivers/fmc/fmc-write-eeprom.c | 176 5 files changed, 313 insertions(+), 0 deletions(-) create mode 100644 Documentation/fmc/fmc-write-eeprom.txt create mode 100644 drivers/fmc/fmc-write-eeprom.c diff --git a/Documentation/fmc/00-INDEX b/Documentation/fmc/00-INDEX index c22d687..177c3e4 100644 --- a/Documentation/fmc/00-INDEX +++ b/Documentation/fmc/00-INDEX @@ -30,3 +30,6 @@ fmc-fakedev.txt fmc-trivial.txt - about drivers/fmc/fmc-trivial.ko + +fmc-write-eeprom.txt +- about drivers/fmc/fmc-write-eeprom.ko diff --git a/Documentation/fmc/fmc-write-eeprom.txt b/Documentation/fmc/fmc-write-eeprom.txt new file mode 100644 index 000..44a3bc6 --- /dev/null +++ b/Documentation/fmc/fmc-write-eeprom.txt @@ -0,0 +1,125 @@ +fmc-write-eeprom + + +This module is designed to load a binary file from /lib/firmware and to +write it to the internal EEPROM of the mezzanine card. This driver uses +the `busid' generic parameter. + +Overwriting the EEPROM is not something you should do daily, and it is +expected to only happen during manufacturing. For this reason, the +module makes it unlikely for the random user to change a working EEPROM. + +The module takes the following measures: + + * It accepts a `file=' argument (within /lib/firmware) and if no + such argument is received, it doesn't write anything to EEPROM + (i.e. there is no default file name). + + * If the file name ends with `.bin' it is written verbatim starting + at offset 0. + + * If the file name ends with `.tlv' it is interpreted as + type-length-value (i.e., it allows writev(2)-like operation). + + * If the file name doesn't match any of the patterns above, it is + ignored and no write is performed. + + * Only cards listed with `busid=' are written to. If no busid is + specified, no programming is done (and the probe function of the + driver will fail). + + +Each TLV tuple is formatted in this way: the header is 5 bytes, +followed by data. The first byte is `w' for write, the next two bytes +represent the address, in little-endian byte order, and the next two +represent the data length, in little-endian order. The length does not +include the header (it is the actual number of bytes to be written). + +This is a real example: that writes 5 bytes at position 0x110: + +spusa.root# od -t x1 -Ax /lib/firmware/try.tlv +00 77 10 01 05 00 30 31 32 33 34 +0a +spusa.root# insmod /tmp/fmc-write-eeprom.ko busid=0x0200 file=try.tlv +[19983.391498] spec :03:00.0: write 5 bytes at 0x0110 +[19983.414615] spec :03:00.0: write_eeprom: success + +Please note that you'll most likely want to use SDBFS to build your +EEPROM image, at least if your mezzanines are being used in the White +Rabbit environment. For this reason the TLV format is not expected to +be used much and is not expected to be developed further. + +If you want to try reflashing fake EEPROM devices, you can use the +fmc-fakedev.ko module (see *note fmc-fakedev::). Whenever you change +the image starting at offset 0, it will deregister and register again +after two seconds. Please note, however, that if fmc-write-eeprom is +still loaded, the system will associate it to the new device, which +will be reprogrammed and thus will be unloaded after two seconds. The +following example removes the module after it reflashed fakedev the +first time. + + spusa.root# insmod fmc-fakedev.ko +[ 72.984733] fake-fmc: Manufacturer: fake-vendor +[ 72.989434] fake-fmc: Product name: fake-design-for-testing +spusa.root# insmod fmc-write-eeprom.ko busid=0 file=fdelay-eeprom.bin; \ +rmmod fmc-write-eeprom +[ 130.874098] fake-fmc: Matching a generic driver (no ID) +[ 130.887845] fake-fmc: programming 6155 bytes +[ 130.894567] fake-fmc: write_eeprom: success +[ 132.895794] fake-fmc: Manufacturer: CERN +[ 132.899872] fake-fmc: Product name: FmcDelay1ns4cha + + +Writing to the EEPROM += + +Once you have created a binary file for your EEPROM, you can write it +to the storage medium using the fmc-write-eeprom (See *note +fmc-write-eeprom::, while relying on a carrier driver. The procedure +here shown here uses the SPEC driver +(`http://www.ohwr.org/projects/spec-sw'). + +The example assumes no drive
Re: [FMC] BUG: scheduling while atomic: swapper/1/0x10000002
Hello. > I got the below dmesg and the first bad commit is > > commit 4debfe409b6e550032bfef9733e9f6f7c5613617 > Author: Alessandro Rubini > Date: Tue Jun 18 23:48:07 2013 +0200 > > FMC: add a char-device mezzanine driver thank you for your report. I already got a problem report with built-in FMC subsystem, but I couldn't reproduce it. Actually, I use drivers/fmc daily (I'm currently finalizing an ADC driver), but I run the whole subsystem as module; it never happens in that case. Thank you for bisecting, I'll take a deeper look as soon as possible (hopefully today). Meanwhile, please disable FMC or build as modules. /alessandro -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH] FMC: fix locking in sample chardev driver
The fmc-chardev module was over-locking, by calling misc register/unregister while holding its spinlock. This reported a "scheduling while atomic" error. Since the misc driver already serializes operations internally, this commit downgrades the fmc-chardev lock to just cover its own list. Reported-by: Sasha Levin Reported-by: Fengguang Wu Signed-off-by: Alessandro Rubini --- drivers/fmc/fmc-chardev.c |9 - 1 files changed, 4 insertions(+), 5 deletions(-) diff --git a/drivers/fmc/fmc-chardev.c b/drivers/fmc/fmc-chardev.c index cc031db..ace6ef2 100644 --- a/drivers/fmc/fmc-chardev.c +++ b/drivers/fmc/fmc-chardev.c @@ -143,18 +143,17 @@ static int fc_probe(struct fmc_device *fmc) fc->misc.fops = &fc_fops; fc->misc.name = kstrdup(dev_name(&fmc->dev), GFP_KERNEL); - spin_lock(&fc_lock); ret = misc_register(&fc->misc); if (ret < 0) - goto err_unlock; + goto out; + spin_lock(&fc_lock); list_add(&fc->list, &fc_devices); spin_unlock(&fc_lock); dev_info(&fc->fmc->dev, "Created misc device \"%s\"\n", fc->misc.name); return 0; -err_unlock: - spin_unlock(&fc_lock); +out: kfree(fc->misc.name); kfree(fc); return ret; @@ -174,10 +173,10 @@ static int fc_remove(struct fmc_device *fmc) spin_lock(&fc_lock); list_del(&fc->list); + spin_unlock(&fc_lock); misc_deregister(&fc->misc); kfree(fc->misc.name); kfree(fc); - spin_unlock(&fc_lock); return 0; } -- 1.7.7.2 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 01/26] x86: fix warning for sta2x11
The .free fied of struct dma_map_ops features a prototype that is
different from what lib/swiotlb.c offers. The new "attrs" argument in
dma_ops.free is missing from the generic implementation.
This removes the build warning by providing a function that just calls
swiotlb_free_coherent() without passing "attrs".
The real solution, in my opinion, would be adding "attrs" as argument
to swiotlb_free_coherent() and remove this new empty function as well
as the identical ones found in other 6 files within arch.
Signed-off-by: Alessandro Rubini
Acked-by: Giancarlo Asnaghi
---
arch/x86/pci/sta2x11-fixup.c |9 -
1 files changed, 8 insertions(+), 1 deletions(-)
diff --git a/arch/x86/pci/sta2x11-fixup.c b/arch/x86/pci/sta2x11-fixup.c
index 9d8a509..5c24ccb 100644
--- a/arch/x86/pci/sta2x11-fixup.c
+++ b/arch/x86/pci/sta2x11-fixup.c
@@ -180,10 +180,17 @@ static void *sta2x11_swiotlb_alloc_coherent(struct device
*dev,
return vaddr;
}
+static void sta2x11_swiotlb_free_coherent(struct device *dev, size_t size,
+ void *vaddr, dma_addr_t dma_addr,
+ struct dma_attrs *attrs)
+{
+ swiotlb_free_coherent(dev, size, vaddr, dma_addr);
+}
+
/* We have our own dma_ops: the same as swiotlb but from alloc (above) */
static struct dma_map_ops sta2x11_dma_ops = {
.alloc = sta2x11_swiotlb_alloc_coherent,
- .free = swiotlb_free_coherent,
+ .free = sta2x11_swiotlb_free_coherent,
.map_page = swiotlb_map_page,
.unmap_page = swiotlb_unmap_page,
.map_sg = swiotlb_map_sg_attrs,
--
1.7.7.2
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 03/26] mmc: Use the new
For portability, use . Signed-off-by: Alessandro Rubini Link: http://lkml.kernel.org/r/1355146956-6009-6-git-send-email-cimina...@gnudd.com Acked-by: Giancarlo Asnaghi Acked-by: David Brown Signed-off-by: H. Peter Anvin --- drivers/mmc/host/mmci.c |2 +- drivers/mmc/host/msm_sdcc.c |2 +- drivers/mmc/host/mvsdio.c |2 +- drivers/mmc/host/pxamci.c |3 +-- 4 files changed, 4 insertions(+), 5 deletions(-) diff --git a/drivers/mmc/host/mmci.c b/drivers/mmc/host/mmci.c index c3785ed..edd987e 100644 --- a/drivers/mmc/host/mmci.c +++ b/drivers/mmc/host/mmci.c @@ -34,11 +34,11 @@ #include #include #include +#include #include #include #include -#include #include "mmci.h" diff --git a/drivers/mmc/host/msm_sdcc.c b/drivers/mmc/host/msm_sdcc.c index b900de4..405f0d8 100644 --- a/drivers/mmc/host/msm_sdcc.c +++ b/drivers/mmc/host/msm_sdcc.c @@ -37,10 +37,10 @@ #include #include #include +#include #include #include -#include #include #include diff --git a/drivers/mmc/host/mvsdio.c b/drivers/mmc/host/mvsdio.c index 4ddd83f..4dec50f 100644 --- a/drivers/mmc/host/mvsdio.c +++ b/drivers/mmc/host/mvsdio.c @@ -23,11 +23,11 @@ #include #include #include +#include #include #include #include -#include #include #include diff --git a/drivers/mmc/host/pxamci.c b/drivers/mmc/host/pxamci.c index 1956a3d..3924f36 100644 --- a/drivers/mmc/host/pxamci.c +++ b/drivers/mmc/host/pxamci.c @@ -33,8 +33,7 @@ #include #include #include - -#include +#include #include #include -- 1.7.7.2 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 04/26] x86: add CONFIG_ARM_AMBA, selected by STA2X11
The sta2x11 I/O Hub is a bridge from PCIe to AMBA. It reuses a number of amba drivers and needs to activate core bus support. Signed-off-by: Alessandro Rubini Acked-by: Giancarlo Asnaghi --- arch/x86/Kconfig |4 1 files changed, 4 insertions(+), 0 deletions(-) diff --git a/arch/x86/Kconfig b/arch/x86/Kconfig index 52432ab..490b001 100644 --- a/arch/x86/Kconfig +++ b/arch/x86/Kconfig @@ -554,6 +554,7 @@ config STA2X11 select SWIOTLB select MFD_STA2X11 select ARCH_REQUIRE_GPIOLIB + select ARM_AMBA default n ---help--- This adds support for boards based on the STA2X11 IO-Hub, @@ -2255,6 +2256,9 @@ config TS5500 endif # X86_32 +config ARM_AMBA +bool + config AMD_NB def_bool y depends on CPU_SUP_AMD && PCI -- 1.7.7.2 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 05/26] drivers/amba: add support for a PCI bridge
This is a PCI driver that registers AMBA devices for the range of
supported devices. It is currently used by STA2X11, which exports
AMBA peripherals under PCIe. The original AMBA drivers work with no
changes or minimal ones.
Signed-off-by: Alessandro Rubini
Acked-by: Giancarlo Asnaghi
Cc: Russell King
---
drivers/Kconfig |2 +
drivers/amba/Kconfig| 10 +
drivers/amba/Makefile |1 +
drivers/amba/pci-amba.c | 93 +++
4 files changed, 106 insertions(+), 0 deletions(-)
create mode 100644 drivers/amba/Kconfig
create mode 100644 drivers/amba/pci-amba.c
diff --git a/drivers/Kconfig b/drivers/Kconfig
index aa43b91..5603bc3 100644
--- a/drivers/Kconfig
+++ b/drivers/Kconfig
@@ -166,4 +166,6 @@ source "drivers/reset/Kconfig"
source "drivers/fmc/Kconfig"
+source "drivers/amba/Kconfig"
+
endmenu
diff --git a/drivers/amba/Kconfig b/drivers/amba/Kconfig
new file mode 100644
index 000..b5b5aca
--- /dev/null
+++ b/drivers/amba/Kconfig
@@ -0,0 +1,10 @@
+
+config PCI_AMBA
+ tristate "PCI-to-AMBA bridge"
+ depends on ARM_AMBA && PCI
+ ---help---
+ This compiles a PCI driver that registers AMBA devices, so
+ the respective AMBA driver can be used unchanged if you have
+ a PCI to amba bridge. This is required for STA2X11 support.
+
+ If uncertain, choose N.
diff --git a/drivers/amba/Makefile b/drivers/amba/Makefile
index 66e81c2..d30e947 100644
--- a/drivers/amba/Makefile
+++ b/drivers/amba/Makefile
@@ -1,2 +1,3 @@
obj-$(CONFIG_ARM_AMBA) += bus.o
+obj-$(CONFIG_PCI_AMBA) += pci-amba.o
obj-$(CONFIG_TEGRA_AHB)+= tegra-ahb.o
diff --git a/drivers/amba/pci-amba.c b/drivers/amba/pci-amba.c
new file mode 100644
index 000..8ce526a
--- /dev/null
+++ b/drivers/amba/pci-amba.c
@@ -0,0 +1,93 @@
+/*
+ * Support for AMBA devices (both APB and AHB) behind a PCI bridge
+ * Copyright 2012 ST Microelectronics (Alessandro Rubini)
+ * GNU GPL version 2.
+ */
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+static int pci_amba_probe(struct pci_dev *pdev,
+ const struct pci_device_id *id)
+{
+ struct amba_device *adev;
+ char *name;
+ int ret;
+
+ pci_enable_msi(pdev);
+ ret = pci_enable_device(pdev);
+ if (ret)
+ return ret;
+
+ /* Create a name: each of them must be different */
+ name = devm_kzalloc(&pdev->dev, strlen(dev_name(&pdev->dev)) + 6,
+ GFP_KERNEL);
+ sprintf(name, "amba-%s", dev_name(&pdev->dev));
+
+ /* Simply build an amba device and register it */
+ adev = amba_device_alloc(name, pdev->resource[0].start, SZ_4K);
+ if (!adev)
+ return -ENOMEM;
+ adev->irq[0] = pdev->irq;
+
+ /* This bridge can host both APB and AHB devices, so set master */
+ pci_set_master(pdev);
+ if (pdev->vendor == PCI_VENDOR_ID_STMICRO) {
+ /* Under sta2x11, DMA is there but limited to 512M */
+ adev->dma_mask = SZ_512M - 1;
+ adev->dev.coherent_dma_mask = SZ_512M - 1;
+ }
+
+ adev->dev.platform_data = pdev->dev.platform_data;
+ pci_set_drvdata(pdev, adev);
+
+ return amba_device_add(adev, &pdev->resource[0]);
+};
+
+static void pci_amba_remove(struct pci_dev *pdev)
+{
+ struct amba_device *adev = pci_get_drvdata(pdev);
+ amba_device_unregister(adev);
+ pci_disable_msi(pdev);
+}
+
+static DEFINE_PCI_DEVICE_TABLE(pci_amba_table) = {
+ {PCI_VDEVICE(STMICRO, PCI_DEVICE_ID_STMICRO_UART_HWFC)},
+ {PCI_VDEVICE(STMICRO, PCI_DEVICE_ID_STMICRO_UART_NO_HWFC)},
+ {PCI_VDEVICE(STMICRO, PCI_DEVICE_ID_STMICRO_SOC_DMA)},
+ {PCI_VDEVICE(STMICRO, PCI_DEVICE_ID_STMICRO_I2C)},
+ {PCI_VDEVICE(STMICRO, PCI_DEVICE_ID_STMICRO_SPI_HS)},
+ {PCI_VDEVICE(STMICRO, PCI_DEVICE_ID_STMICRO_SDIO_EMMC)},
+ {PCI_VDEVICE(STMICRO, PCI_DEVICE_ID_STMICRO_SDIO)},
+ {PCI_VDEVICE(STMICRO, PCI_DEVICE_ID_STMICRO_AUDIO_ROUTER_DMA)},
+ {PCI_VDEVICE(STMICRO, PCI_DEVICE_ID_STMICRO_AUDIO_ROUTER_MSPS)},
+ {0,}
+};
+
+static struct pci_driver pci_amba_driver = {
+ .name = "pci-amba",
+ .id_table = pci_amba_table,
+ .probe = pci_amba_probe,
+ .remove = pci_amba_remove,
+};
+
+static int __init pci_amba_init(void)
+{
+ return pci_register_driver(&pci_amba_driver);
+}
+
+static void __exit pci_amba_exit(void)
+{
+ pci_unregister_driver(&pci_amba_driver);
+}
+
+module_init(pci_amba_init);
+module_exit(pci_amba_exit);
+
+MODULE_LICENSE("GPL");
--
1.7.7.2
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 02/26] DMA: PL330: use prefix in reg names to build under x86
This driver would not compile if ARM_AMBA is selected under x86,
because "CS" and "DS" are already defined there. But AMBA
is used in the x86 world by a PCI-to-AMBA bridge, to be submitted.
The patch just adds the "PL330_" prefix to all registers,
so it can be built by randomconfig after ARM_AMBA appears within x86.
No other technical changes have been performed.
The patch was build-tested only.
Signed-off-by: Alessandro Rubini
Link:
http://lkml.kernel.org/r/1355146956-6009-2-git-send-email-cimina...@gnudd.com
Acked-by: Giancarlo Asnaghi
[Davide Ciminaghi : only registers prefixed]
Signed-off-by: Davide Ciminaghi
Acked-by: Jassi Brar
Signed-off-by: H. Peter Anvin
Conflicts:
drivers/dma/pl330.c
---
drivers/dma/pl330.c | 107 ++-
1 files changed, 54 insertions(+), 53 deletions(-)
diff --git a/drivers/dma/pl330.c b/drivers/dma/pl330.c
index 4ad13eb..da67bee 100644
--- a/drivers/dma/pl330.c
+++ b/drivers/dma/pl330.c
@@ -71,7 +71,7 @@ enum pl330_reqtype {
};
/* Register and Bit field Definitions */
-#define DS 0x0
+#define PL330_DS 0x0
#define DS_ST_STOP 0x0
#define DS_ST_EXEC 0x1
#define DS_ST_CMISS0x2
@@ -85,33 +85,33 @@ enum pl330_reqtype {
#define DS_ST_FLTCMP 0xe
#define DS_ST_FAULT0xf
-#define DPC0x4
-#define INTEN 0x20
-#define ES 0x24
-#define INTSTATUS 0x28
-#define INTCLR 0x2c
-#define FSM0x30
-#define FSC0x34
-#define FTM0x38
+#define PL330_DPC 0x4
+#define PL330_INTEN0x20
+#define PL330_ES 0x24
+#define PL330_INTSTATUS0x28
+#define PL330_INTCLR 0x2c
+#define PL330_FSM 0x30
+#define PL330_FSC 0x34
+#define PL330_FTM 0x38
#define _FTC 0x40
-#define FTC(n) (_FTC + (n)*0x4)
+#define PL330_FTC(n) (_FTC + (n)*0x4)
#define _CS0x100
-#define CS(n) (_CS + (n)*0x8)
+#define PL330_CS(n)(_CS + (n)*0x8)
#define CS_CNS (1 << 21)
#define _CPC 0x104
-#define CPC(n) (_CPC + (n)*0x8)
+#define PL330_CPC(n) (_CPC + (n)*0x8)
#define _SA0x400
-#define SA(n) (_SA + (n)*0x20)
+#define PL330_SA(n)(_SA + (n)*0x20)
#define _DA0x404
-#define DA(n) (_DA + (n)*0x20)
+#define PL330_DA(n)(_DA + (n)*0x20)
#define _CC0x408
-#define CC(n) (_CC + (n)*0x20)
+#define PL330_CC(n)(_CC + (n)*0x20)
#define CC_SRCINC (1 << 0)
#define CC_DSTINC (1 << 14)
@@ -132,24 +132,24 @@ enum pl330_reqtype {
#define CC_SWAP_SHFT 28
#define _LC0 0x40c
-#define LC0(n) (_LC0 + (n)*0x20)
+#define PL330_LC0(n) (_LC0 + (n)*0x20)
#define _LC1 0x410
-#define LC1(n) (_LC1 + (n)*0x20)
+#define PL330_LC1(n) (_LC1 + (n)*0x20)
-#define DBGSTATUS 0xd00
+#define PL330_DBGSTATUS0xd00
#define DBG_BUSY (1 << 0)
-#define DBGCMD 0xd04
-#define DBGINST0 0xd08
-#define DBGINST1 0xd0c
+#define PL330_DBGCMD 0xd04
+#define PL330_DBGINST0 0xd08
+#define PL330_DBGINST1 0xd0c
-#define CR00xe00
-#define CR10xe04
-#define CR20xe08
-#define CR30xe0c
-#define CR40xe10
-#define CRD0xe14
+#define PL330_CR0 0xe00
+#define PL330_CR1 0xe04
+#define PL330_CR2 0xe08
+#define PL330_CR3 0xe0c
+#define PL330_CR4 0xe10
+#define PL330_CRD 0xe14
#define PERIPH_ID 0xfe0
#define PERIPH_REV_SHIFT 20
@@ -1006,7 +1006,7 @@ static bool _until_dmac_idle(struct pl330_thread *thrd)
do {
/* Until Manager is Idle */
- if (!(readl(regs + DBGSTATUS) & DBG_BUSY))
+ if (!(readl(regs + PL330_DBGSTATUS) & DBG_BUSY))
break;
cpu_relax();
@@ -1029,10 +1029,10 @@ static inline void _execute_DBGINSN(struct pl330_thread
*thrd,
val |= (1 << 0);
val |= (thrd->id << 8); /* Channel Number */
}
- writel(val, regs + DBGINST0);
+ writel(val, regs + PL330_DBGINST0);
val = *((u32 *)&insn[2]);
- writel(val, regs + DBGINST1);
+ writel(val, regs + PL330_DBGINST1);
/* If timed ou
[PATCH 00/26] STA2X11 devicetree support for amba/pci
cause PCI assignment may change according to what other cards are present. So this devicetree stuff is killing all the autodetection of PCI, and is very difficult to pass over in the x86 world. On the other hand platform data is denied by x86 maintainers. So the question is: what is the right way (and the right dts structure) to deal with a hotplug bus that instantiates AMBA devices, without killing del self-detection features? Thanks /alessandro Alessandro Rubini (5): x86: fix warning for sta2x11 DMA: PL330: use prefix in reg names to build under x86 mmc: Use the new x86: add CONFIG_ARM_AMBA, selected by STA2X11 drivers/amba: add support for a PCI bridge Davide Ciminaghi (21): x86 STA2X11: select devicetree related config items. OF platform: export of_amba_device_create() OF platform, of_amba_device_create(): add parent resource to parameters. kernel irqdomain: export irq_domain_disassociate() x86 devicetree: add irq domain for msi irqs x86 devicetree: add functions for handling setup/teardown of MSI irqs x86 kernel apic: notify MSI irqdomain(s) on setup/teardown of MSI IRQs drivers/amba/pci-amba.c: use devicetree for amba device creation. gpio: remove sta2x11-gpio x86 STA2X11: remove the sta2x11-mfd driver. x86 STA2X11 platform: add sta2x11_platform_init() x86 STA2X11 platform: add sta2x11_instance_data helpers x86 STA2X11 platform: add a common probe function for platform devices x86 STA2X11 platform: create sta2x11-clock-regs device x86 STA2X11 platform: remove useless pr_info()'s AMBA: pci-amba bridge: improve code readability AMBA: pci-amba bridge: extend number of amba devs per pci device AMBA: pci-amba bridge: export function creating pci-amba device names x86 STA2X11: add dts for Intel's Northville board drivers/clk: sta2x11 common clock framework implementation pinctrl: add support for sta2x11 (via pinctrl-nomadik) .../devicetree/bindings/pinctrl/ste,nomadik.txt|2 +- .../devicetree/bindings/x86/interrupt.txt | 14 + arch/x86/Kconfig | 10 + arch/x86/include/asm/prom.h|9 + arch/x86/include/asm/sta2x11.h | 358 - arch/x86/kernel/apic/io_apic.c |5 + arch/x86/kernel/devicetree.c | 60 ++ arch/x86/pci/sta2x11-fixup.c |9 +- arch/x86/platform/Makefile |1 + arch/x86/platform/sta2x11/Makefile |1 + arch/x86/platform/sta2x11/northville.dts | 941 arch/x86/platform/sta2x11/sta2x11.c| 522 +++ drivers/Kconfig|2 + drivers/amba/Kconfig | 10 + drivers/amba/Makefile |1 + drivers/amba/pci-amba.c| 298 +++ drivers/clk/Makefile |1 + drivers/clk/sta2x11/Makefile |1 + drivers/clk/sta2x11/clk-audio-pll.c| 149 +++ drivers/clk/sta2x11/clk-soc-pll.c | 95 ++ drivers/clk/sta2x11/clk.c | 865 ++ drivers/clk/sta2x11/clk.h | 88 ++ drivers/dma/pl330.c| 107 ++-- drivers/gpio/Kconfig |8 - drivers/gpio/Makefile |1 - drivers/gpio/gpio-sta2x11.c| 440 - drivers/mfd/Kconfig|6 - drivers/mfd/Makefile |1 - drivers/mfd/sta2x11-mfd.c | 680 -- drivers/mmc/host/mmci.c|2 +- drivers/mmc/host/msm_sdcc.c|2 +- drivers/mmc/host/mvsdio.c |2 +- drivers/mmc/host/pxamci.c |3 +- drivers/of/platform.c | 24 +- drivers/pinctrl/Kconfig|6 +- drivers/pinctrl/Makefile |1 + drivers/pinctrl/pinctrl-nomadik-sta2x11.c | 578 drivers/pinctrl/pinctrl-nomadik.c |7 + drivers/pinctrl/pinctrl-nomadik.h | 14 + include/linux/irqdomain.h |3 + include/linux/mfd/sta2x11-mfd.h| 518 --- include/linux/of_platform.h|7 +- include/linux/pci-amba.h | 42 + kernel/irq/irqdomain.c |3 +- 44 files changed, 4167 insertions(+), 1730 deletions(-) create mode 100644 arch/x86/platform/sta2x11/Makefile create mode 100644 arch/x86/platform/sta2x11/northville.dts create mode 100644 arch/x86/platform/sta2x11/sta2x11.c create mode 100644 drivers/amba/Kconfig create
Re: [PATCH 26/26] pinctrl: add support for sta2x11 (via pinctrl-nomadik)
> Maybe you could add a commit message? Ack (Davide is holidays, I grant that for him). > Apart from that it looks like a straight-forward plug-in to the > Nomadik pin controller, so I'd happily apply it, but I guess it > will go in through the x86 tree? It's part of a bigger series, that adds devicetree support first. Yes, it's expected to go through a different path, if the whole series is ok. > Acked-by: Linus Walleij Thanks for this and the gpio acked-by -- yes, I didn't notice it's a nomadik logic block; it's Davide who tried to match the registers. /alessandro -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 00/26] STA2X11 devicetree support for amba/pci
[stripped list of issues from my original message follows] >> Some of the problems he found are: >> >> * Passing a dtb to the kernel: we use a modified kexec at present >> * Passing correct irq numbers to the AMBA drivers >> * Switching to a new gpio driver with devicetree support >> * Writing a suitable dts: at present, a dts only exists for one >>of the STA2X11 based boards (Intel Northville). > OK, so we have a real corner case here... which is a plugin board beyond > which sits a bus normally used by fixed devices. You are definitely > correct that this is something that stresses current means of > description to the breaking point. Basically, it's an ARM chip with a PCI interface. So it offers USB, SATA, Eth, i2c, spi, gpio, can etc to the x86 CPU. > *Note there are some questions below that I would perfectly understand > if you can't talk about publicly, if so, please contact me privately at > my corporate address.* Thanks. I'm not aware of any such issues at this point, though. > However, the plugin board is very different from it being the main > chipset, in no small part because you can boot without it. I think this > is the first time I have ever heard of a chip which can act both as a > system chipset and a plugin card. The main CPU in the Northville is an Atom, which IIUC has its own memory controller -- and definitely a PCIe controller. The Sta2x11 chip is connected to the PCIe bus, as both a slave and a master. It's a busmaster for SATA, USB and something else, and equipped with a PrimeCell PL080 as DMA engine for UART, I2C, SPI, MMC. I'm aware it might be the first time this happens, but I also suspect it will be common pretty soon: the industrial world wants I2C, UART, SPI and GPIO, and bridging overt PCI to an external SoC is the right approach, in my opinion. > The mainboard case is relatively straightforward -- we should use ACPI 5 > (preferred for x86) or device tree to describe it. My understanding > from what you describe so far is that the only existing case is the > Northville which is a mainboard. There are a pair of such mainboards around, but what we developers only have the Northville at this time. And the evaluation board, which is a PCIe card. With the previous platform_data-based approach I could plug two of them and access all devices (2 * 4 UART, 2 * 3 I2C etc). > For the plugin case, my thinking is that we probably do need a driver of > some kind which at least contains the description of the board, as I > assume one is not present in any kind of firmware on the board itself > (*do any such boards or plans for them actually exist at this point?*) The board exists as an evaluation board. But I see nothing against an industrial-grade commercial offering, to give SPI, CAN and all the rest to PC users that need them, as a single do-it-all cheap board. > Ideally that driver should be (primarily?) a data object (an ACPI 5 SSDT > or a DTB file) rather than open coded C. Mostly so. It used to be platform data, to register devices for drivers that already exist. Like we did for Ether and CAN: just add the vendor/device pair and PCI support where missing. > I believe ACPI 5 unlike device tree should be able to specify the > dynamic properties that you are rightfully concerned with. We'll try to get acquainted with that, but my wild guess is that platform data is still simpler. I'm aware of the issues, and I'm not insisting, though. > Sorry if this feels like a wild goose chase to you. Some of this > problem domain is not very well handled by the current code, but we > really have to draw a hard line to make sure it doesn't descend into > unmaintainable chaos. I understand. My impression of devicetree is exactly like that, I must say. What we have here is a very clean PCI enumeration of it all: we only need to specify the mapping of GPIO pins (i.e. card-detect for mmc) and DMA channels, as all the rest works by itself. > We have similar issues with MinnowBoard and are trying to use that as a > platform to figure out how a lot of these things need to be handled. Interesting. I'll take a look. We were looking for a simple PC today and found that very thing as a viable option. Thank you for your feedback. May I ask three more questions (this is the 1st)? Is the patch-set a viable approach for mainline, modulo serious evaluation of the hairy IRQ details and the other bits? Would it make sense to work on devicetree support in x86 bootloaders (especially yours, let's ignore grub)? thank you again /alessandro -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [fmc] BUG: scheduling while atomic: swapper/0/1/0x00000002
> On 08/11/2013 09:52 PM, Fengguang Wu wrote: >> FYI, the bug still exists in the upstream and linux-next kernels. Strange. Greg approved the patch I sent. I see it in next-20130809 but also next-20130801 and other ones with the same hash: 783c2fb FMC: fix locking in sample chardev driver However, it is not in master. It was sent as https://lkml.org/lkml/2013/7/16/196 . Greg, can you please put the patch in the bugfix queue? Thanks /alessandro -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] FMC: Staticize local symbols
> This local symbol is used only in this file. > Fix the following sparse warnings: Thanks! Acked-by: Alessandro Rubini /alessandro -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v4 0/7] enable support for AMBA drivers under x86
> Did this got fixed in some tree in the meantime? Because I still see it on > current Linus + tip/master: > > arch/x86/pci/sta2x11-fixup.c:186:2: warning: initialization from incompatible > pointer type [enabled by default] > arch/x86/pci/sta2x11-fixup.c:186:2: warning: (near initialization for > âsta2x11_dma_ops.freeâ) [enabled by default] Last time I sent the patch was on Feb 22nd: The .free field of struct dma_map_ops features a prototype that is different from what lib/swiotlb.c offers. The new "attrs" argument in dma_ops.free is missing from the generic implementation. This removes the build warning by providing a function that just calls swiotlb_free_coherent() without passing "attrs", like others do. I got no reply. This is the link: http://lkml.org/lkml/2013/2/22/111 It is in patchwork here: https://patchwork.kernel.org/patch/2175551/ /alessandro -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v4 0/7] enable support for AMBA drivers under x86
All-To: mi...@kernel.org,b...@alien8.de,h...@zytor.com,cimina...@gnudd.com,jaswinder.si...@linaro.org,will.dea...@arm.com,li...@arm.linux.org.uk,t...@linutronix.de,mi...@redhat.com,d...@fb.com,vinod.k...@intel.com,grant.lik...@secretlab.ca,linus.wall...@linaro.org,w...@iguana.be,c...@laptop.org,dav...@codeaurora.org,n...@fluxnic.net,ben-li...@fluff.org,viresh.li...@gmail.com,rajeev-dlh.ku...@st.com,linux-kernel@vger.kernel.org,linux-arm-ker...@lists.infradead.org,giancarlo.asna...@st.com Re: [PATCH v4 0/7] enable support for AMBA drivers under x86 > From: Ingo Molnar > To: Borislav Petkov > Cc: Alessandro Rubini , h...@zytor.com, > cimina...@gnudd.com, jaswinder.si...@linaro.org, will.dea...@arm.com, > li...@arm.linux.org.uk, t...@linutronix.de, mi...@redhat.com, > d...@fb.com, vinod.k...@intel.com, grant.lik...@secretlab.ca, > linus.wall...@linaro.org, w...@iguana.be, c...@laptop.org, > dav...@codeaurora.org, n...@fluxnic.net, ben-li...@fluff.org, > viresh.li...@gmail.com, rajeev-dlh.ku...@st.com, > linux-kernel@vger.kernel.org, linux-arm-ker...@lists.infradead.org, > giancarlo.asna...@st.com > Subject: Re: [PATCH v4 0/7] enable support for AMBA drivers under x86 > Date: Mon, 6 May 2013 11:41:54 +0200 > A lot happened meanwhile - patches got acked, applied - so I expected a > resend of the patches that are still pending, with all acks in place in > the patches (not in the cover letter), and against Linus's latest tree. Ok, I'll resend this AMBA/PCI set. But this warning we are discussing about is unrelated and I sent it by itself in february. Anyways, I'll add it to the patch-set I'm going to send most likely tomorrow. thanks /alessndro -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 02/14] MAINTAINERS: remove arch/arm/plat-nomadik/
> In fact, the ARM/Ux500 ARM ARCHITECTURE block has patterns for files > named "nomadik" too. The patterns in this pair of MAINTAINER blocks > really need a review from the respective maintainters. Thanks! Acked-by: Alessandro Rubini -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 13/24] ARM: nomadik: use __iomem pointers for MMIO
> - .options= NAND_COPYBACK | NAND_CACHEPRG | NAND_NO_PADDING \ > - | NAND_NO_READRDY, > + .options= NAND_COPYBACK | NAND_CACHEPRG | NAND_NO_PADDING, This is not clear to me, and it looks unrelated. But I admit I haven't studied what happened to NAND_NO_READRDY lately. If this hunk is desired and not just something else that slipped in, then Acked-by: Alessandro Rubini -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 0/8 RESEND] sta2x11-mfd patches
> Davide Ciminaghi (8): For the whole set: Acked-by: Alessandro Rubini (original committer of the mfd driver) /alessandro -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 0/2] x86, pci: sta2x11-fixup clock related patches
> the following two patches are needed for the sta2x11 common clock > framework (to be submitted shortly) to deal with the possibility > of multiple instances of the connext chip on the same machine. Thanks you very much for your clock work, Davide. For both: Acked-by: Alessandro Rubini /alessandro -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 1/8 v3] DMA: PL330: use prefix in reg names to build under x86
My patch: >> This driver would not compile if ARM_AMBA is selected under x86, >> because "CS" and "DS" are already defined there. But AMBA >> is used in the x86 world by a PCI-to-AMBA bridge, to be submitted. >> >> The patch just adds the "PL330_" prefix to all register and bit fields, >> so it can be built by randomconfig after ARM_AMBA appears within x86. Jassy Brar: > Prefixing only CS and DS should be do the job. > Why do we have to make every symbol noisy with PL330_ ? For internal consistency. I attacked this problem in July. This is what you wrote: I fully agree with your point and IIRC I always add some prefix to definitions in header files. Private defines in a .c file, without redundant prefixes, sounded like safe to me at the time, but perhaps I was wrong. (references: http://lkml.org/lkml/2012/7/1/56) So I made the changes overall. I dislike needless long patches, but picking symbols to work around the conflict of the day while introducing inconsistent naming doesn't look good to me. The other option is making the driver depend on CONFIG_ARM, like other patches in the series. That would be a smaller patch: we have a dozen AMBA peripherals under X86, and the PL330 was not thre. But I got the impression that we don't want to single-out every driver that doesn't compile: an overall more portable system is better. I'm fine either way, but your "perhaps I was wrong" above made me choose the overall-prefixing approach. Thank you all for your patience in this (especially Davide for the upstreaming effort) /alessandro -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v4 0/7] enable support for AMBA drivers under x86
Hello. > Build failure: > > o.i386-allconfig/make.log:make[4]: *** [drivers/gpio/gpio-pl061.o] Error 1 > o.i386-allconfig/make.log:make[3]: *** [drivers/gpio] Error 2 This happens because the pl061 is not in this checkout. I also got a message from the "kbuild test robot", which results from the same kind of problem. I'll check the details later, identifying the missing patches and whether there are remaining warnings. > /home/hpa/kernel/tip.x86-amba/arch/x86/pci/sta2x11-fixup.c:186:2: > warning: initialization from incompatible pointer type [enabled by default] This is a long-standing problem, but with not practical effects. I proposed a pair of different fixes quite some months ago. I'll respin the problem tomorrow. /alessandro -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v2] psmouse: mitigate failing-mouse symptoms
> I think this would be less controversial if the run-time default were > to disable the feature. Yes, that's the common sensible path to new little-tested features. As you say, it may become enabled by default over time. Then, I think it would be good to have a specific sub-structure for this stuff. It would allow this: + psmouse->err_log_base = 0; + psmouse->interval_base = 0; + psmouse->hotio_log_base = 0; + psmouse->err_log_counter = 0; + psmouse->interval_pkts = 0; + psmouse->hotio_log_counter = 0; to be replaced with a memset. I also think it would make it clearer what these are: + unsigned long interval_base; + unsigned long interval_pkts; + unsigned long hotio_log_base; + unsigned long hotio_log_counter; + unsigned long err_log_base; + unsigned long err_log_counter; to the casual reader. This is only a suggestion, though. thanks /alessandro -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] IIO ADC support for AD7923
Thank you Jonathan for replying, I apologize for the delay. >> I wonder if IIO config symbols should have IIO_ in their name, [...] > I have no particular problem with this for new drivers, but > obviously it is an interface change for older ones that may > cause some issues. Yes, that's right. I just raised a problem, though a minor one. thanks /alessandro -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] IIO ADC support for AD7923
>> I wonder if IIO config symbols should have IIO_ in their name, so >> people looking at config files knows what they actually are. >> Actually, all USB drivers have USB in their config name, which is >> useful even if e.g. "PL2303" cannot be but USB. >> >> On the other hand, AD7923 and all the others can well be driven by >> something else than IIO, even if currently this is the only mainstream >> option. > > No, IIO is and should be the only option for these devices. We really don't > want to drivers for the same device in different subsystems of the kernel. We really don't want a non-USB driver for a USB device, but still the name is in the config symbol and is useful. And this is an hardware constraint. And your argument may well have applied to comedi. But they wisely made the right choice and allowed iio to take over and possibly drive the same devices. But sure your code is perfect and no other subsystem will ever be needed. To explain, this is the problem I had: IIO was still in staging, and I had to use the ADC in the at91sam9g20. The platform data there was protected by "IS_ENABLED(CONFIG_AT91_ADC)", which is actually only selectable if IIO is configured in. What should I do if I wanted to drive directly the hardware with a simple custom thing, because, for example, my target board is very small? Currently I run a patched kernel, because otherwise I can't load my custom module and use the already-available platform data. No, it's not only a name change, it's that the description of the hardware should not depend on which subsystems are selected. But yes, you are right. I'm working on another I/O subsystem. We are gong to release zio-1.0 in a few days, because the thing is mature and used in production. I hope to meet you in person at fosdem and be able to talk over a beer or two. regards /alessandro -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] IIO ADC support for AD7923
Thank you Lars for you constructive attitude. See you at fosdem /alessandro -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v3 2/4] videobuf2-dma-streaming: new videobuf2 memory allocator
> The problem is that on the sta2x11 architecture only the first > 512MB are available through the PCI bus, but the allocator can allocate > memory > for DMA above this limit. By using GFP_DMA flags the allocation take place > under the 16MB so it works. Still, you are not running the upstream allocator. IIUC, you added a "gfp_t" field in the platform data or somewhere, so the sta2x11 can request GFP_DMA to be OR'd, while other users remain unaffected. Will you please submit the patch to achieve that? > I cannot do performance test at the moment because I don't have the time, so > I > cannot personally justify the presence of a new allocator. I don't expect you'll see serious performance differences on the PC. I think ARM users will have better benefits, due to the different cache architecture. You told me Jon measured meaningful figures on a Marvel CPU. > I will propose V4 patches soon. thanks /alessandro -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] IIO ADC support for AD7923
> +config AD7923 I wonder if IIO config symbols should have IIO_ in their name, so people looking at config files knows what they actually are. Actually, all USB drivers have USB in their config name, which is useful even if e.g. "PL2303" cannot be but USB. On the other hand, AD7923 and all the others can well be driven by something else than IIO, even if currently this is the only mainstream option. Here comedi made the right choice, and all their symbols are in the CONFIG_COMEDI_ name space. Thanks /alessandro -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[patch] khttpd doesn't detach from the files of its parent
Hi all.
While looking at kHTTPd (linux-2.4.0-test9) I found what looks like a
bug to me.
The daemon doesn't detach itself from the files structure of the
parent process. Therefore, when it is run as a module, the files
opened by "insmod" (or whatever loads it) remain open.
Besides "aesthetical" issues, this can be a problem: if a script loads
a module redirecting stderr to a file, the filesystem won't be
unmountable before the module is removed. (I reproduced that).
The proposed patch is trivial, so I may miss some detail.
A sample session follows, then the patch.
/alessandro
rudo.root# ps aux | grep http
root 1828 0.0 0.0 00 ?SW 12:57 0:00 [khttpd manager]
root 1848 0.0 0.0 00 ?SW 12:58 0:00 [khttpd - 0]
root 1849 0.0 0.0 00 ?SW 12:58 0:00 [khttpd - 1]
rudo.root# ls -l /proc/1828/fd
total 48
lrwx--1 root root 64 Oct 18 13:17 0 -> /dev/ttyp1
lrwx--1 root root 64 Oct 18 13:17 1 -> /dev/ttyp1
lrwx--1 root root 64 Oct 18 13:17 2 -> /dev/ttyp1
rudo.root# ls -l /proc/1848/fd
total 48
lrwx--1 root root 64 Oct 18 13:17 0 -> /dev/ttyp1
lrwx--1 root root 64 Oct 18 13:17 1 -> /dev/ttyp1
lrwx--1 root root 64 Oct 18 13:17 2 -> /dev/ttyp1
then, I tried "insmod khttpd < /dev/ttyS0".
rudo.root# ps aux | grep http
root 2031 0.0 0.0 00 ttypcSW 13:22 0:00 [khttpd manager]
root 2034 0.0 0.0 00 ttypcSW 13:22 0:00 [khttpd - 0]
root 2035 0.0 0.0 00 ttypcSW 13:22 0:00 [khttpd - 1]
rudo.root# ls -l /proc/2034/fd
total 27
lr-x--1 root root 64 Oct 18 13:22 0 -> /dev/ttyS0
lrwx--1 root root 64 Oct 18 13:22 1 -> /dev/ttypc
lrwx--1 root root 64 Oct 18 13:22 2 -> /dev/ttypc
after applying the patch included below, no file remains open
rudo.root# ps aux | grep http
root 2019 0.0 0.0 00 ttypcSW 13:20 0:00 [khttpd manager]
root 2020 0.0 0.0 00 ttypcSW 13:20 0:00 [khttpd - 0]
root 2021 0.0 0.0 00 ttypcSW 13:20 0:00 [khttpd - 1]
rudo.root# ls -l /proc/2020/fd
total 0
rudo.root#
--- ./net/khttpd/main.c.origWed Oct 18 13:01:29 2000
+++ ./net/khttpd/main.c Wed Oct 18 19:13:01 2000
@@ -195,6 +195,7 @@
{
sigset_t tmpsig;
int waitpid_result;
+ int i;
DECLARE_WAIT_QUEUE_HEAD(WQ);
@@ -203,6 +204,10 @@
lock_kernel(); /* This seems to be required for exit_mm */
exit_mm(current);
+ /* init_module has stdin/stdout/stderr open: close them (ARub) */
+ for (i=255; i>=0; i--)
+ if (current->files->fd[i])
+ close(i);
/* Block all signals except SIGKILL and SIGSTOP */
spin_lock_irq(¤t->sigmask_lock);
@@ -383,7 +388,7 @@
StartSysctl();
- (void)kernel_thread(ManagementDaemon,NULL, CLONE_FS | CLONE_FILES |
CLONE_SIGHAND);
+ (void)kernel_thread(ManagementDaemon,NULL, CLONE_FS | CLONE_SIGHAND);
return 0;
}
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/
Re: [patch] khttpd doesn't detach from the files of its parent
> shouldn't this be exit_files() ? Yes, definitely. Arjan already replied (privately) to say the same. Thanks /alessandro - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: [patch] khttpd doesn't detach from the files of its parent
>> Yes, definitely. > > It should, unless you want to open any files in the thread itself. Yes. I realized that just before getting your message (after looking at kernel/exit.c). I should never say "definitely" :) /alessandro - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: [patch] khttpd doesn't detach from the files of its parent
> put_files_struct() is a destructor, so it won't help here. The following > patch may be of use [...] It's "create an empty > files_struct and replace the task->files with it" - thing we can't do via > clone() and may want to (khttpd does). Sorry, what's wrong with just closing the files? It's much easier. Instead of my silly 255-to-0 loop, close_files() can be used (by copying to khttpd or by moving to a header. /alessandro - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: why CURRENT->sector is zero??
Hello. > I downloaded sbull.c (for LDD 2nd Edition) from Please note that sbull is a block device not hosting partitions. > of req->sector in sbull_transfer function). The observations are as follows: > File System req->sector > msdos 0 > vfat 0 > ext2 2 > ext3 2 > iso9000 72 If there is no filesystem in the device, you just get the probe transfers. Not very interesting, indeed. Some filesystems have their magic number in the first sector, and some have it later in the device. > I don't know about other file systems, but I believe the value of > req->sector for msdos/vfat is wrong. Because when I mount a CF card having > FAT file system on my Linux box (using USB mass storage driver), the first > read request contains sector 0x20. Before you state it's wrong you should see some effect. In your case there is no effect at all. If you make a filesystem on the device you'll see it works. So if this concerns you, you should look for an explanation rather than saying it is wrong. > Does someone have any clue, why sbull gets this value as 0 rather then 0x20? I suspect because the device is not partitioned, while the other one is, so every transfer just is done inside the partition (while the low-level access uses absolute sector number of the device). /alessandro - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [patch 0/3] PS3 Storage Drivers for 2.6.23, take 5
Hello. > I didn't hear anything from the misc device maintainer (for the FLASH ROM > Storage Driver). Actually, I am not acting as a maintainer. I'm not active enough nor up to date with all the structure of kernel maintainance. So please don't wait for me. Actually, I tried a pair of times to have my name removed from the MAINTAINERS file over the years without success. Actually, I didn't care a lot because nobody relly used that entry. I think it's time for me to learn how to do it in the proper way. Regards /alessandro - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 12/22] mfd: sta2x11: drop unused MODULE_ tags from non-modular code
> Subject: [PATCH] mfd: sta2x11: drop unused MODULE_ tags from non-modular code Acked-by: Alessandro Rubini > Alessandro, Davide - you can find additional context regarding why we > are making these changes in the [00/22] e-mail that can be found here: > https://lore.kernel.org/lkml/1543811009-15112-1-git-send-email-paul.gortma...@windriver.com/ Thanks a lot for this extra link. Yes, I agree. I set up this as a module because /sys/modules has much more than what is actually a module, and the "module" concept brings it the idea of module parameters, that are available for built-in code too, with the module namespace. But it's actually not used in this case. Thanks /alessandro
Re: [PATCH RFC] err.h: document that PTR_ERR should only be used if IS_ERR returns true
Me: >> > OTOH I admit you can compare any value with -EINVAL, after PTR_ERR. >> > But in general you first detect the error condition and then split >> > among error (or print a message according to the exact value. Al Viro: >> >> if (IS_ERR(p) && PTR_ERR(p) == -ENOENT) >> instead of >> if (p == ERR_PTR(-ENOENT)) >> >> is ugly, obfuscating what's going on for no good reason and I'm going >> to keep killing those every time I run into one... Sure. I was talking about selecting among errors in the error path, after you left the fast path jumping away with IS_ERR(). (in short, I agree). Uwe kleine-koenig > And what do you do if you see a > > p = somefunc(...); > if (PTR_ERR(p) == -ENOENT) > > without first checking for IS_ERR(p)? I see no problem. The original suggestion (only use if IS_ERR), which was mine, refers to doing error management in error cases. Sure if you know the return value is valid or -ENOENT you don't need to verify it is negative before comparing with -2. Both PTR_ERR and ERR_PTR are just a cast to prevent a warning (and tell the reader that you convert from err to ptr or vv), so I think the two are equivalent. Al's version above is maybe cleaner, but we are bikeshedding, IMHO. best /alessandro
Re: [PATCH RFC] err.h: document that PTR_ERR should only be used if IS_ERR returns true
Hello. > during a review I claimed that PTR_ERR should only be used if IS_ERR was > already checked. The rationale isn't obvious though and Thierry > suggested to keep the code as is and not introduce an IS_ERR check. The rationale is the same ch11 you linked to: "any other value is a valid pointer". It isn't usefult to convert to long sth that your are not using as a long. You should not pass it to strerror(-err) for example. OTOH I admit you can compare any value with -EINVAL, after PTR_ERR. But in general you first detect the error condition and then split among error (or print a message according to the exact value. > maybe something like "On an Alpha it is important because > not doing it results in a bus error there." No, nothing that exotic. You said: > Thierry suggested to keep the code as is and not introduce an IS_ERR check. I wonder where. Sure no extra check in the header, that would be extra wasted time in every caller. If it's a specific caller place, it may make sense to avoid the check, I don't know the details. As for the specific patch you propose, I'm unsure it's useful. Maybe we should remember that "this returns the equivalent of "-errno" if IS_ERR() is true", but I'm personally not much for overcommenting: It's a simple cast and there are a zillion users to see how exactly this works if anyone is uncertain. Regards /alessandro
[PATCH 2/2] FMC: show_sdb_tree: dump synthesis/commit ID info
This completes the show_sdb_tree functionality, with the
new informative fields. The output for a verbose module is now
like this (long lines are unavoidable):
SDB: 0651:e6a542c9 WB4-Crossbar-GSI
SDB: ce42:0601 WB-DMA.Control (1000-103f)
SDB: ce42:779c5443 WB-OneWire-Master (1100-11ff)
SDB: ce42:0603 WB-SPEC-CSR (1200-121f)
SDB: ce42:0013 WB-VIC-Int.Control (1300-13ff)
SDB: ce42:d5735ab4 WB-DMA.EIC (1400-140f)
SDB: 0651:eef0b198 WB4-Bridge-GSI (bridge: 2000)
SDB:0651:e6a542c9 WB4-Crossbar-GSI
SDB:ce42:123c5443 WB-I2C-Master (3000-30ff)
SDB:ce42:e503947e WB-SPI.Control (3100-311f)
SDB:ce42:123c5443 WB-I2C-Master (3200-32ff)
SDB:ce42:0608 WB-FMC-ADC-Core (3300-337f)
SDB:ce42:779c5443 WB-OneWire-Master (3400-34ff)
SDB:ce42:26ec6086 WB-FMC-ADC.EIC (3500-350f)
SDB:ce42:0604 WB-Timetag-Core (3600-367f)
SDB: Synthesis repository: git://ohwr.org/fmc-projects/fmc-adc-100m14b4cha.git
SDB: Bitstream 'spec_top_fmc_adcmc-projects/fmc-adc-100m14b4cha.git' \
synthesized 20140116 by mcattin (ISE version 133), commit f0a539dffe6d
Signed-off-by: Tomasz Wlostowski
Acked-by: Alessandro Rubini
Acked-by: Juan David Gonzalez Cobas
---
drivers/fmc/fmc-sdb.c | 34 ++
include/linux/fmc-sdb.h |2 ++
2 files changed, 32 insertions(+), 4 deletions(-)
diff --git a/drivers/fmc/fmc-sdb.c b/drivers/fmc/fmc-sdb.c
index 69f42d7..4603fdb 100644
--- a/drivers/fmc/fmc-sdb.c
+++ b/drivers/fmc/fmc-sdb.c
@@ -150,11 +150,27 @@ int fmc_reprogram(struct fmc_device *fmc, struct
fmc_driver *d, char *gw,
}
EXPORT_SYMBOL(fmc_reprogram);
+static char *__strip_trailing_space(char *buf, char *str, int len)
+{
+ int i = len - 1;
+
+ memcpy(buf, str, len);
+ while(i >= 0 && buf[i] == ' ')
+ buf[i--] = '\0';
+ return buf;
+}
+
+#define __sdb_string(buf, field) ({\
+ BUILD_BUG_ON(sizeof(buf) < sizeof(field)); \
+ __strip_trailing_space(buf, (void *)(field), sizeof(field));\
+ })
+
static void __fmc_show_sdb_tree(const struct fmc_device *fmc,
const struct sdb_array *arr)
{
unsigned long base = arr->baseaddr;
int i, j, n = arr->len, level = arr->level;
+ char buf[64];
for (i = 0; i < n; i++) {
union sdb_record *r;
@@ -190,8 +206,8 @@ static void __fmc_show_sdb_tree(const struct fmc_device
*fmc,
p->name,
__be64_to_cpu(c->addr_first) + base);
if (IS_ERR(arr->subtree[i])) {
- printk(KERN_CONT "(bridge error %li)\n",
- PTR_ERR(arr->subtree[i]));
+ dev_info(&fmc->dev, "SDB: (bridge error %li)\n",
+PTR_ERR(arr->subtree[i]));
break;
}
__fmc_show_sdb_tree(fmc, arr->subtree[i]);
@@ -200,10 +216,20 @@ static void __fmc_show_sdb_tree(const struct fmc_device
*fmc,
printk(KERN_CONT "integration\n");
break;
case sdb_type_repo_url:
- printk(KERN_CONT "repo-url\n");
+ printk(KERN_CONT "Synthesis repository: %s\n",
+ __sdb_string(buf, r->repo_url.repo_url));
break;
case sdb_type_synthesis:
- printk(KERN_CONT "synthesis-info\n");
+ printk(KERN_CONT "Bitstream '%s' ",
+ __sdb_string(buf, r->synthesis.syn_name));
+ printk(KERN_CONT "synthesized %08x by %s ",
+ __be32_to_cpu(r->synthesis.date),
+ __sdb_string(buf, r->synthesis.user_name));
+ printk(KERN_CONT "(%s version %x), ",
+ __sdb_string(buf, r->synthesis.tool_name),
+ __be32_to_cpu(r->synthesis.tool_version));
+ printk(KERN_CONT "commit %pm\n",
+ r->synthesis.commit_id);
break;
case sdb_type_empty:
printk(KERN_CONT "empty\n");
diff --git a/include/linux/fmc-sdb.h b/include/linux/fmc-sdb.h
index 1974317..599bd6b 100644
--- a/include/linux/fmc-sdb.h
+++ b/include/linux/fmc-sd
[PATCH 1/2] FMC: make eeprom attribute writable
This allows easier modification to the eeprom than loading the fmc-write-eeprom module. The carrier driver will refuse writing if the FPGA is not running the golden gateware image, so writing in practice is only available at manufacture/development time. Signed-off-by: Alessandro Rubini Acked-by: Juan David Gonzalez Cobas --- Documentation/fmc/fmc-write-eeprom.txt | 77 ++- drivers/fmc/fmc-core.c | 15 ++- 2 files changed, 39 insertions(+), 53 deletions(-) diff --git a/Documentation/fmc/fmc-write-eeprom.txt b/Documentation/fmc/fmc-write-eeprom.txt index 44a3bc6..e0a9712 100644 --- a/Documentation/fmc/fmc-write-eeprom.txt +++ b/Documentation/fmc/fmc-write-eeprom.txt @@ -9,7 +9,12 @@ Overwriting the EEPROM is not something you should do daily, and it is expected to only happen during manufacturing. For this reason, the module makes it unlikely for the random user to change a working EEPROM. -The module takes the following measures: +However, since the EEPROM may include application-specific information +other than the identification, later versions of this packages added +write-support through sysfs. See *note Accessing the EEPROM::. + +To avoid damaging the EEPROM content, the module takes the following +measures: * It accepts a `file=' argument (within /lib/firmware) and if no such argument is received, it doesn't write anything to EEPROM @@ -70,56 +75,24 @@ first time. [ 132.899872] fake-fmc: Product name: FmcDelay1ns4cha -Writing to the EEPROM +Accessing the EEPROM = -Once you have created a binary file for your EEPROM, you can write it -to the storage medium using the fmc-write-eeprom (See *note -fmc-write-eeprom::, while relying on a carrier driver. The procedure -here shown here uses the SPEC driver -(`http://www.ohwr.org/projects/spec-sw'). - -The example assumes no driver is already loaded (actually, I unloaded -them by hand as everything loads automatically at boot time after you -installed the modules), and shows kernel messages together with -commands. Here the prompt is spusa.root# and two SPEC cards are plugged -in the system. - - spusa.root# insmod fmc.ko - spusa.root# insmod spec.ko - [13972.382818] spec :02:00.0: probe for device 0002: - [13972.392773] spec :02:00.0: got file "fmc/spec-init.bin", 1484404 (0x16a674) bytes - [13972.591388] spec :02:00.0: FPGA programming successful - [13972.883011] spec :02:00.0: EEPROM has no FRU information - [13972.888719] spec :02:00.0: No device_id filled, using index - [13972.894676] spec :02:00.0: No mezzanine_name found - [13972.899863] /home/rubini/wip/spec-sw/kernel/spec-gpio.c - spec_gpio_init - [13972.906578] spec :04:00.0: probe for device 0004: - [13972.916509] spec :04:00.0: got file "fmc/spec-init.bin", 1484404 (0x16a674) bytes - [13973.115096] spec :04:00.0: FPGA programming successful - [13973.401798] spec :04:00.0: EEPROM has no FRU information - [13973.407474] spec :04:00.0: No device_id filled, using index - [13973.413417] spec :04:00.0: No mezzanine_name found - [13973.418600] /home/rubini/wip/spec-sw/kernel/spec-gpio.c - spec_gpio_init - spusa.root# ls /sys/bus/fmc/devices - fmc- fmc-0001 - spusa.root# insmod fmc-write-eeprom.ko busid=0x0200 file=fdelay-eeprom.bin - [14103.966259] spec :02:00.0: Matching an generic driver (no ID) - [14103.975519] spec :02:00.0: programming 6155 bytes - [14126.373762] spec :02:00.0: write_eeprom: success - [14126.378770] spec :04:00.0: Matching an generic driver (no ID) - [14126.384903] spec :04:00.0: fmc_write_eeprom: no filename given: not programming - [14126.392600] fmc_write_eeprom: probe of fmc-0001 failed with error -2 - -Reading back the EEPROM -=== - -In order to read back the binary content of the EEPROM of your -mezzanine device, the bus creates a read-only sysfs file called eeprom -for each mezzanine it knows about: - - spusa.root# cd /sys/bus/fmc/devices; ls -l */eeprom - -r--r--r-- 1 root root 8192 Apr 9 16:53 FmcDelay1ns4cha-f001/eeprom - -r--r--r-- 1 root root 8192 Apr 9 17:19 fake-design-for-testing-f002/eeprom - -r--r--r-- 1 root root 8192 Apr 9 17:19 fake-design-for-testing-f003/eeprom - -r--r--r-- 1 root root 8192 Apr 9 17:19 fmc-f004/eeprom +The bus creates a sysfs binary file called eeprom for each mezzanine it +knows about: + +spusa.root# cd /sys/bus/fmc/devices; ls -l */eeprom +-r--r--r-- 1 root root 8192 Feb 21 12:30 FmcAdc100m14b4cha-0800/eeprom +-r--r--r-- 1 root root 8192 Feb 21 12:30 FmcDelay1ns4cha-0200/eeprom +-r--r--r-- 1 root root 8192 Feb 21 12:30 FmcDio5cha-0400/eeprom + +Everybody can read the files and the superuser can also modify it, but +the operation may on the carri
