Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.kernel > #1298989 > unrolled thread

[PATCH v1 0/3] ARM64 LPC: legacy ISA I/O support

Back to article view | Back to linux.kernel

Contents

  [PATCH v1 0/3] ARM64 LPC: legacy ISA I/O support  Rongrong Zou <zourongrong@gmail.com> - 2015-12-29 14:40 +0100
    [PATCH v1 2/3] ARM64 LPC: LPC driver implementation Rongrong Zou <zourongrong@gmail.com> - 2015-12-29 14:40 +0100
      Re: [PATCH v1 2/3] ARM64 LPC: LPC driver implementation Arnd Bergmann <arnd@arndb.de> - 2015-12-29 15:00 +0100
        Re: [PATCH v1 2/3] ARM64 LPC: LPC driver implementation Rongrong Zou <zourongrong@huawei.com> - 2015-12-29 15:10 +0100
          Re: [PATCH v1 2/3] ARM64 LPC: LPC driver implementation Arnd Bergmann <arnd@arndb.de> - 2015-12-29 15:20 +0100
    [PATCH v1 1/3] ARM64 LPC: indirect ISA PORT IO introduced Rongrong Zou <zourongrong@gmail.com> - 2015-12-29 14:40 +0100
      Re: [PATCH v1 1/3] ARM64 LPC: indirect ISA PORT IO introduced Arnd Bergmann <arnd@arndb.de> - 2015-12-29 14:50 +0100
        Re: [PATCH v1 1/3] ARM64 LPC: indirect ISA PORT IO introduced Rongrong Zou <zourongrong@huawei.com> - 2015-12-29 15:30 +0100
          Re: [PATCH v1 1/3] ARM64 LPC: indirect ISA PORT IO introduced Arnd Bergmann <arnd@arndb.de> - 2015-12-29 15:40 +0100
            Re: [PATCH v1 1/3] ARM64 LPC: indirect ISA PORT IO introduced Rongrong Zou <zourongrong@huawei.com> - 2015-12-30 02:40 +0100
              Re: [PATCH v1 1/3] ARM64 LPC: indirect ISA PORT IO introduced Arnd Bergmann <arnd@arndb.de> - 2015-12-30 10:00 +0100
                Re: [PATCH v1 1/3] ARM64 LPC: indirect ISA PORT IO introduced Rongrong Zou <zourongrong@huawei.com> - 2015-12-30 10:40 +0100
                  Re: [PATCH v1 1/3] ARM64 LPC: indirect ISA PORT IO introduced Arnd Bergmann <arnd@arndb.de> - 2015-12-30 10:50 +0100
    [PATCH v1 3/3] ARM64 LPC: update binding doc Rongrong Zou <zourongrong@gmail.com> - 2015-12-29 14:40 +0100
      Re: [PATCH v1 3/3] ARM64 LPC: update binding doc Arnd Bergmann <arnd@arndb.de> - 2015-12-29 15:00 +0100
      Re: [PATCH v1 3/3] ARM64 LPC: update binding doc Arnd Bergmann <arnd@arndb.de> - 2015-12-30 10:10 +0100
        Re: [PATCH v1 3/3] ARM64 LPC: update binding doc Rongrong Zou <zourongrong@huawei.com> - 2015-12-31 15:20 +0100
          Re: [PATCH v1 3/3] ARM64 LPC: update binding doc Arnd Bergmann <arnd@arndb.de> - 2015-12-31 15:50 +0100

#1298989 — [PATCH v1 0/3] ARM64 LPC: legacy ISA I/O support

The Low Pin Count bus, is used on IBM-compatible personal computers 
to connect low-bandwidth devices to the CPU, such as the boot ROM, 
"legacy" I/O devices (integrated into a super I/O chip), and Trusted
Platform Module (TPM)."Legacy" I/O devices usually include serial and 
parallel ports, PS/2 keyboard, PS/2 mouse, and floppy disk controller.

Usually LPC controller is part of PCI host bridge, so the legacy ISA
port locate on LPC bus can be accessed directly. But some SoC have
independent LPC controller, and we can access the legacy port by specifying
LPC address cycle. Thus, LPC driver is introduced.

In addition, indirect legacy ISA port I/O is introduced, then we can
hook LPC driver to gereral inb/outb inerface. So the driver of device
attached to the LPC bus need no modification.

Generally, X86 server platform is managemented by BMC, The host 
communicate with the BMC across IPMI(BT/KCS). BT(KCS) use the
legacy ISA port which is located on LPC bus. 

The BMC is required on Hisilicon Hip06 arm64 SoC board too.  

  ____     lpc     ____
 |host|___________|BMC |
 |____|           |____|

Rongrong Zou (3):
  ARM64 LPC: indirect ISA PORT IO introduced
  ARM64 LPC: LPC driver implementation
  ARM64 LPC: update binding doc

 .../devicetree/bindings/arm64/low-pin-count.txt    |  20 ++
 arch/arm64/Kconfig.platforms                       |   5 +-
 arch/arm64/include/asm/io.h                        |  78 ++++++
 arch/arm64/kernel/Makefile                         |   1 +
 arch/arm64/kernel/lpc.c                            | 294 +++++++++++++++++++++
 arch/arm64/kernel/setup.c                          |   5 +
 6 files changed, 402 insertions(+), 1 deletion(-)
 create mode 100644 Documentation/devicetree/bindings/arm64/low-pin-count.txt
 create mode 100644 arch/arm64/kernel/lpc.c

-- 
1.9.1

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [next] | [standalone]

#1298990 — [PATCH v1 2/3] ARM64 LPC: LPC driver implementation

We only implement io cycles here, we hook the lpc_io_write_byte
and lpc_io_read_byte to inb/outb. So the drivers(ipmi/uart) which access
the legacy ISA I/O port need no modification.

The low pin count specification is at 
http://www.intel.com/design/chipsets/industry/lpc.htm

Signed-off-by: Rongrong Zou <zourongrong@gmail.com>
---
 arch/arm64/kernel/Makefile |   1 +
 arch/arm64/kernel/lpc.c    | 294 +++++++++++++++++++++++++++++++++++++++++++++
 2 files changed, 295 insertions(+)
 create mode 100644 arch/arm64/kernel/lpc.c

diff --git a/arch/arm64/kernel/Makefile b/arch/arm64/kernel/Makefile
index 474691f..4324575 100644
--- a/arch/arm64/kernel/Makefile
+++ b/arch/arm64/kernel/Makefile
@@ -41,6 +41,7 @@ arm64-obj-$(CONFIG_EFI)			+= efi.o efi-entry.stub.o
 arm64-obj-$(CONFIG_PCI)			+= pci.o
 arm64-obj-$(CONFIG_ARMV8_DEPRECATED)	+= armv8_deprecated.o
 arm64-obj-$(CONFIG_ACPI)		+= acpi.o
+arm64-obj-$(CONFIG_ARM64_INDIRECT_PIO)	+= lpc.o
 
 obj-y					+= $(arm64-obj-y) vdso/
 obj-m					+= $(arm64-obj-m)
diff --git a/arch/arm64/kernel/lpc.c b/arch/arm64/kernel/lpc.c
new file mode 100644
index 0000000..174c293
--- /dev/null
+++ b/arch/arm64/kernel/lpc.c
@@ -0,0 +1,294 @@
+#include <linux/errno.h>
+#include <linux/delay.h>
+#include <linux/io.h>
+#include <linux/module.h>
+#include <linux/platform_device.h>
+#include <linux/spinlock.h>
+#include <linux/version.h>
+
+#define LPC_REG_START            (0x00)
+#define LPC_REG_OP_STATUS        (0x04)
+#define LPC_REG_IRQ_ST           (0x08)
+#define LPC_REG_OP_LEN           (0x10)
+#define LPC_REG_CMD              (0x14)
+#define LPC_REG_FWH_ID_MSIZE     (0x18)
+#define LPC_REG_ADDR             (0x20)
+#define LPC_REG_WDATA            (0x24)
+#define LPC_REG_RDATA            (0x28)
+#define LPC_REG_LONG_CNT         (0x30)
+#define LPC_REG_TX_FIFO_ST       (0x50)
+#define LPC_REG_RX_FIFO_ST       (0x54)
+#define LPC_REG_TIME_OUT         (0x58)
+#define LPC_REG_STRQ_CTRL0       (0x80)
+#define LPC_REG_STRQ_CTRL1       (0x84)
+#define LPC_REG_STRQ_INT         (0x90)
+#define LPC_REG_STRQ_INT_MASK    (0x94)
+#define LPC_REG_STRQ_STAT        (0xa0)
+
+#define LPC_CMD_SAMEADDR_SING    (0x00000008)
+#define LPC_CMD_SAMEADDR_INC     (0x00000000)
+#define LPC_CMD_TYPE_IO          (0x00000000)
+#define LPC_CMD_TYPE_MEM         (0x00000002)
+#define LPC_CMD_TYPE_FWH         (0x00000004)
+#define LPC_CMD_WRITE            (0x00000001)
+#define LPC_CMD_READ             (0x00000000)
+
+#define LPC_IRQ_CLEAR            (0x02)
+#define LPC_IRQ_OCCURRED         (0x02)
+#define LPC_STATUS_DILE          (0x01)
+#define LPC_OP_FINISHED          (0x02)
+#define START_WORK (0x01)
+
+#define LPC_FRAME_LEN (0x10)
+
+#define LPC_CURR_STATUS_IDLE     0
+#define LPC_CURR_STATUS_START    1
+#define LPC_CURR_STATUS_TYPE_DIR 2
+#define LPC_CURR_STATUS_ADDR     3
+#define LPC_CURR_STATUS_MSIZE    4
+#define LPC_CURR_STATUS_WDATA    5
+#define LPC_CURR_STATUS_TARHOST  6
+#define LPC_CURR_STATUS_SYNC     7
+#define LPC_CURR_STATUS_RDATA    8
+#define LPC_CURR_STATUS_TARSLAVE 9
+#define LPC_CURR_STATUS_ABORT    10
+
+struct lpc_dev {
+	spinlock_t lock;
+	void __iomem  *regs;
+	struct device *dev;
+};
+
+static struct lpc_dev *lpc_dev;
+
+int lpc_master_write(unsigned int slv_access_mode, unsigned int cycle_type,
+		      unsigned int addr, unsigned char *buf, unsigned int len)
+{
+	unsigned int i;
+	unsigned int lpc_cmd_value;
+	unsigned int lpc_op_state_value;
+	unsigned int retry = 0;
+
+	/* para check */
+	if (!buf || !len)
+		return -EINVAL;
+
+	if (slv_access_mode != LPC_CMD_SAMEADDR_SING &&
+		slv_access_mode != LPC_CMD_SAMEADDR_INC) {
+		return -EINVAL;
+	}
+
+	if ((cycle_type != LPC_CMD_TYPE_IO) &&
+		(cycle_type != LPC_CMD_TYPE_MEM) &&
+		(cycle_type != LPC_CMD_TYPE_FWH)) {
+		return -EINVAL;
+	}
+
+	writel(LPC_IRQ_CLEAR, lpc_dev->regs + LPC_REG_IRQ_ST);
+	retry = 0;
+	while (!(readl(lpc_dev->regs + LPC_REG_OP_STATUS)
+		& LPC_STATUS_DILE)) {
+		udelay(1);
+		retry++;
+		if (retry >= 2)
+			return -ETIME;
+	}
+
+	/* set lpc master write cycle type and slv access mode */
+	lpc_cmd_value = LPC_CMD_WRITE | cycle_type | slv_access_mode;
+	writel(lpc_cmd_value, lpc_dev->regs + LPC_REG_CMD);
+
+	/* set lpc op len */
+	writel(len, lpc_dev->regs + LPC_REG_OP_LEN);
+
+	/* Set write data */
+	for (i = 0; i < len; i++)
+		writel(buf[i], lpc_dev->regs + LPC_REG_WDATA);
+
+	/* set lpc addr config */
+	writel(addr, lpc_dev->regs + LPC_REG_ADDR);
+
+	/* set lpc start work */
+	writel(START_WORK, lpc_dev->regs + LPC_REG_START);
+
+	retry = 0;
+	while (!(readl(lpc_dev->regs + LPC_REG_IRQ_ST) &
+		 LPC_IRQ_OCCURRED)) {
+		udelay(1);
+		retry++;
+		if (retry >= 2)
+			return -ETIME;
+	}
+
+	writel(LPC_IRQ_CLEAR, lpc_dev->regs + LPC_REG_IRQ_ST);
+
+	lpc_op_state_value = readl(lpc_dev->regs + LPC_REG_OP_STATUS);
+	if (lpc_op_state_value & LPC_OP_FINISHED)
+		return 0;
+
+	return -EIO;
+}
+
+void  lpc_io_write_byte(u8 value, unsigned long addr)
+{
+	unsigned long flags;
+
+	if (!lpc_dev)
+		return;
+	spin_lock_irqsave(&lpc_dev->lock, flags);
+	(void)lpc_master_write(LPC_CMD_SAMEADDR_SING, LPC_CMD_TYPE_IO,
+				 addr, &value, 1);
+	spin_unlock_irqrestore(&lpc_dev->lock, flags);
+}
+
+int lpc_master_read(unsigned int slv_access_mode, unsigned int cycle_type,
+		     unsigned int addr, unsigned char *buf, unsigned int len)
+{
+	unsigned int i;
+	unsigned int lpc_cmd_value;
+	unsigned int lpc_op_state_value;
+	unsigned int retry = 0;
+
+	/* para check */
+	if (!buf || !len)
+		return -EINVAL;
+
+	if (slv_access_mode != LPC_CMD_SAMEADDR_SING &&
+	    slv_access_mode != LPC_CMD_SAMEADDR_INC) {
+		return -EINVAL;
+	}
+
+	if (cycle_type != LPC_CMD_TYPE_IO &&
+	    cycle_type != LPC_CMD_TYPE_MEM &&
+	    cycle_type != LPC_CMD_TYPE_FWH) {
+		return -EINVAL;
+	}
+
+	writel(LPC_IRQ_CLEAR, lpc_dev->regs + LPC_REG_IRQ_ST);
+
+	retry = 0;
+	while (!(readl(lpc_dev->regs + LPC_REG_OP_STATUS) &
+	       LPC_STATUS_DILE)) {
+		udelay(1);
+		retry++;
+		if (retry >= 2)
+			return -ETIME;
+	}
+
+	/* set lpc master read cycle type and slv access mode */
+	lpc_cmd_value = LPC_CMD_READ | cycle_type | slv_access_mode;
+	writel(lpc_cmd_value, lpc_dev->regs + LPC_REG_CMD);
+
+	/* set lpc op len */
+	writel(len, lpc_dev->regs + LPC_REG_OP_LEN);
+
+	/* set lpc addr config */
+	writel(addr, lpc_dev->regs + LPC_REG_ADDR);
+
+	/* set lpc start work */
+	writel(START_WORK, lpc_dev->regs + LPC_REG_START);
+
+	while (!(readl(lpc_dev->regs + LPC_REG_IRQ_ST) &
+	       LPC_IRQ_OCCURRED)) {
+		udelay(1);
+		retry++;
+		if (retry >= 2)
+			return -ETIME;
+	}
+
+	writel(LPC_IRQ_CLEAR, lpc_dev->regs + LPC_REG_IRQ_ST);
+
+	lpc_op_state_value = readl(lpc_dev->regs + LPC_REG_OP_STATUS);
+	/* Get read data */
+	if (lpc_op_state_value & LPC_OP_FINISHED) {
+		for (i = 0; i < len; i++)
+			buf[i] = readl(lpc_dev->regs + LPC_REG_RDATA);
+		return 0;
+	}
+	return -EIO;
+}
+
+u8 lpc_io_read_byte(unsigned long addr)
+{
+	unsigned char value;
+	unsigned long flags;
+	int ret;
+
+	if (!lpc_dev)
+		return 0xff;
+
+	spin_lock_irqsave(&lpc_dev->lock, flags);
+	ret = lpc_master_read(LPC_CMD_SAMEADDR_SING,
+		LPC_CMD_TYPE_IO, addr, &value, 1);
+	spin_unlock_irqrestore(&lpc_dev->lock, flags);
+	return ret ? 0xff : value;
+}
+
+static const struct arm64_isa_io lpc_io = {
+	.inb  = lpc_io_read_byte,
+	.outb = lpc_io_write_byte,
+};
+
+static int lpc_probe(struct platform_device *pdev)
+{
+	struct resource *regs = NULL;
+
+	lpc_dev = devm_kzalloc(&pdev->dev,
+		sizeof(struct lpc_dev), GFP_KERNEL);
+	if (!lpc_dev)
+		return -ENOMEM;
+
+	spin_lock_init(&lpc_dev->lock);
+	regs = platform_get_resource(pdev, IORESOURCE_MEM, 0);
+	lpc_dev->regs = devm_ioremap_resource(&pdev->dev, regs);
+	if (IS_ERR(lpc_dev->regs))
+		return PTR_ERR(lpc_dev->regs);
+
+	dev_info(&pdev->dev, "Low pin count driver initialized successfully\n");
+
+	lpc_dev->dev = &pdev->dev;
+	platform_set_drvdata(pdev, lpc_dev);
+	arm64_isa_io = lpc_io;
+
+	return 0;
+}
+
+static int lpc_remove(struct platform_device *pdev)
+{
+	return 0;
+}
+
+static const struct of_device_id lpc_pltfm_match[] = {
+	{
+		.compatible = "low-pin-count",
+	},
+	{},
+};
+
+static struct platform_driver lpc_driver = {
+	.driver = {
+		.name           = "LPC",
+		.owner          = THIS_MODULE,
+		.of_match_table = lpc_pltfm_match,
+	},
+	.probe                = lpc_probe,
+	.remove               = lpc_remove,
+};
+
+static int __init lpc_init_driver(void)
+{
+	return platform_driver_register(&lpc_driver);
+}
+
+static void __exit lpc_init_exit(void)
+{
+	platform_driver_unregister(&lpc_driver);
+}
+
+arch_initcall(lpc_init_driver);
+module_exit(lpc_init_exit);
+
+MODULE_LICENSE("GPL v2");
+MODULE_AUTHOR("Huawei Tech. Co., Ltd.");
+MODULE_DESCRIPTION("LPC driver for linux");
+MODULE_VERSION("v1.0");
-- 
1.9.1

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [prev] | [next] | [standalone]

#1299005 — Re: [PATCH v1 2/3] ARM64 LPC: LPC driver implementation

On Tuesday 29 December 2015 21:33:51 Rongrong Zou wrote:
> We only implement io cycles here, we hook the lpc_io_write_byte
> and lpc_io_read_byte to inb/outb. So the drivers(ipmi/uart) which access
> the legacy ISA I/O port need no modification.
> 
> The low pin count specification is at 
> http://www.intel.com/design/chipsets/industry/lpc.htm
> 
> Signed-off-by: Rongrong Zou <zourongrong@gmail.com>

I'm slightly confused here: I thought this driver was hisilicon specific.
Is the MMIO register layout that is used in this hardware actually standardized
in a way that the driver also works for all other implementations?

> +
> +static struct lpc_dev *lpc_dev;
> +
> +int lpc_master_write(unsigned int slv_access_mode, unsigned int cycle_type,
> +		      unsigned int addr, unsigned char *buf, unsigned int len)
> +{

Please make all function definitions 'static' so we don't accidentally get
other users that bypass the proper interface.

	Arnd
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [prev] | [next] | [standalone]

#1299008 — Re: [PATCH v1 2/3] ARM64 LPC: LPC driver implementation

在 2015/12/29 21:51, Arnd Bergmann 写道:
> On Tuesday 29 December 2015 21:33:51 Rongrong Zou wrote:
>> We only implement io cycles here, we hook the lpc_io_write_byte
>> and lpc_io_read_byte to inb/outb. So the drivers(ipmi/uart) which access
>> the legacy ISA I/O port need no modification.
>>
>> The low pin count specification is at
>> http://www.intel.com/design/chipsets/industry/lpc.htm
>>
>> Signed-off-by: Rongrong Zou <zourongrong@gmail.com>
>
> I'm slightly confused here: I thought this driver was hisilicon specific.
> Is the MMIO register layout that is used in this hardware actually standardized
> in a way that the driver also works for all other implementations?

The register defined is not standardized. other vendors may define their own
registers.

>
>> +
>> +static struct lpc_dev *lpc_dev;
>> +
>> +int lpc_master_write(unsigned int slv_access_mode, unsigned int cycle_type,
>> +		      unsigned int addr, unsigned char *buf, unsigned int len)
>> +{
>
> Please make all function definitions 'static' so we don't accidentally get
> other users that bypass the proper interface.
>
> 	Arnd
> _______________________________________________
> linuxarm mailing list
> linuxarm@huawei.com
> http://rnd-openeuler.huawei.com/mailman/listinfo/linuxarm
>
>

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [prev] | [next] | [standalone]

#1299015 — Re: [PATCH v1 2/3] ARM64 LPC: LPC driver implementation

On Tuesday 29 December 2015 22:03:14 Rongrong Zou wrote:
> 在 2015/12/29 21:51, Arnd Bergmann 写道:
> > On Tuesday 29 December 2015 21:33:51 Rongrong Zou wrote:
> >> We only implement io cycles here, we hook the lpc_io_write_byte
> >> and lpc_io_read_byte to inb/outb. So the drivers(ipmi/uart) which access
> >> the legacy ISA I/O port need no modification.
> >>
> >> The low pin count specification is at
> >> http://www.intel.com/design/chipsets/industry/lpc.htm
> >>
> >> Signed-off-by: Rongrong Zou <zourongrong@gmail.com>
> >
> > I'm slightly confused here: I thought this driver was hisilicon specific.
> > Is the MMIO register layout that is used in this hardware actually standardized
> > in a way that the driver also works for all other implementations?
> 
> The register defined is not standardized. other vendors may define their own
> registers.

Ok, please clarify this in the patch description, the Kconfig help text and
the DT binding then.

	Arnd
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [prev] | [next] | [standalone]

#1298992 — [PATCH v1 1/3] ARM64 LPC: indirect ISA PORT IO introduced

Indirect ISA port I/O accessing introduced, vendors can hook
their own in/out function to general inb/outb. Drivers can access
legacy ISA I/O port by inb/outb as it is done in x86 platform.

Signed-off-by: Rongrong Zou <zourongrong@gmail.com>
---
 arch/arm64/Kconfig.platforms |  5 ++-
 arch/arm64/include/asm/io.h  | 78 ++++++++++++++++++++++++++++++++++++++++++++
 arch/arm64/kernel/setup.c    |  5 +++
 3 files changed, 87 insertions(+), 1 deletion(-)

diff --git a/arch/arm64/Kconfig.platforms b/arch/arm64/Kconfig.platforms
index 4043c35..98ae206 100644
--- a/arch/arm64/Kconfig.platforms
+++ b/arch/arm64/Kconfig.platforms
@@ -127,5 +127,8 @@ config ARCH_ZYNQMP
 	bool "Xilinx ZynqMP Family"
 	help
 	  This enables support for Xilinx ZynqMP Family
-
+config ARM64_INDIRECT_PIO
+	bool "ARM64 Indirect port I/O"
+	help
+	  This enables support for ARM64 indirect port I/O
 endmenu
diff --git a/arch/arm64/include/asm/io.h b/arch/arm64/include/asm/io.h
index 44be1e0..0041f3b 100644
--- a/arch/arm64/include/asm/io.h
+++ b/arch/arm64/include/asm/io.h
@@ -193,6 +193,84 @@ extern void __iomem *ioremap_cache(phys_addr_t phys_addr, size_t size);
  */
 #define xlate_dev_kmem_ptr(p)	p
 
+#ifdef CONFIG_ARM64_INDIRECT_PIO
+#define DEF_PCI_HOOK_pio(x)   x
+#else
+#define DEF_PCI_HOOK_pio(x)   NULL
+#endif
+
+/*
+ * This value is equal to PCIBIOS_MIN_IO
+ */
+#define LEGACY_ISA_PORT_MAX 0x1000
+
+extern struct arm64_isa_io {
+	u8 (*inb)(unsigned long port);
+	u16 (*inw)(unsigned long port);
+	u32 (*inl)(unsigned long port);
+	void (*outb)(u8 value, unsigned long port);
+	void (*outw)(u16 value, unsigned long port);
+	void (*outl)(u32 value, unsigned long port);
+} arm64_isa_io;
+
+#define inb inb
+static inline u8 inb(unsigned long port)
+{
+	if (DEF_PCI_HOOK_pio(arm64_isa_io.inb) &&
+	    port < LEGACY_ISA_PORT_MAX)
+		return arm64_isa_io.inb(port);
+	return readb(PCI_IOBASE + port);
+}
+
+#define inw inw
+static inline u16 inw(unsigned long port)
+{
+	if (DEF_PCI_HOOK_pio(arm64_isa_io.inw) &&
+	    port < LEGACY_ISA_PORT_MAX)
+		return arm64_isa_io.inw(port);
+	return readw(PCI_IOBASE + port);
+}
+
+#define inl inl
+static inline u32 inl(unsigned long port)
+{
+	if (DEF_PCI_HOOK_pio(arm64_isa_io.inl) &&
+	    port < LEGACY_ISA_PORT_MAX)
+		return arm64_isa_io.inl(port);
+	return readl(PCI_IOBASE + port);
+}
+
+#define outb outb
+static inline void outb(u8 val, unsigned long port)
+{
+	if (DEF_PCI_HOOK_pio(arm64_isa_io.outb) &&
+	    port < LEGACY_ISA_PORT_MAX)
+		arm64_isa_io.outb(val, port);
+	else
+		writeb(val, PCI_IOBASE + port);
+}
+
+#define outw outw
+static inline void outw(u16 val, unsigned long port)
+{
+	if (DEF_PCI_HOOK_pio(arm64_isa_io.outw) &&
+	    port < LEGACY_ISA_PORT_MAX)
+		arm64_isa_io.outw(val, port);
+	else
+		writew(val, PCI_IOBASE + port);
+}
+
+#define outl outl
+static inline void outl(u32 val, unsigned long port)
+{
+	if (DEF_PCI_HOOK_pio(arm64_isa_io.outl) &&
+	    port < LEGACY_ISA_PORT_MAX)
+		arm64_isa_io.outl(val, port);
+	else
+		writel(val, PCI_IOBASE + port);
+}
+
+
 #include <asm-generic/io.h>
 
 /*
diff --git a/arch/arm64/kernel/setup.c b/arch/arm64/kernel/setup.c
index 8119479..c689dd7 100644
--- a/arch/arm64/kernel/setup.c
+++ b/arch/arm64/kernel/setup.c
@@ -381,3 +381,8 @@ static int __init topology_init(void)
 	return 0;
 }
 subsys_initcall(topology_init);
+
+#if defined(CONFIG_ARM64_INDIRECT_PIO)
+struct arm64_isa_io arm64_isa_io;
+EXPORT_SYMBOL_GPL(arm64_isa_io);
+#endif
-- 
1.9.1

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [prev] | [next] | [standalone]

#1299000 — Re: [PATCH v1 1/3] ARM64 LPC: indirect ISA PORT IO introduced

On Tuesday 29 December 2015 21:33:50 Rongrong Zou wrote:
> Indirect ISA port I/O accessing introduced, vendors can hook
> their own in/out function to general inb/outb. Drivers can access
> legacy ISA I/O port by inb/outb as it is done in x86 platform.
> 
> Signed-off-by: Rongrong Zou <zourongrong@gmail.com>

Looks correct to me, but I have a few style comments

> ---
>  arch/arm64/Kconfig.platforms |  5 ++-
>  arch/arm64/include/asm/io.h  | 78 ++++++++++++++++++++++++++++++++++++++++++++
>  arch/arm64/kernel/setup.c    |  5 +++
>  3 files changed, 87 insertions(+), 1 deletion(-)
> 
> diff --git a/arch/arm64/Kconfig.platforms b/arch/arm64/Kconfig.platforms
> index 4043c35..98ae206 100644
> --- a/arch/arm64/Kconfig.platforms
> +++ b/arch/arm64/Kconfig.platforms
> @@ -127,5 +127,8 @@ config ARCH_ZYNQMP
>  	bool "Xilinx ZynqMP Family"
>  	help
>  	  This enables support for Xilinx ZynqMP Family
> -
> +config ARM64_INDIRECT_PIO
> +	bool "ARM64 Indirect port I/O"
> +	help
> +	  This enables support for ARM64 indirect port I/O
>  endmenu

The option should probably go into arch/arm64/Kconfig. Possibly you can make
it a silent option that just gets selected whenever a driver is enabled
that might set the callbacks.

> diff --git a/arch/arm64/include/asm/io.h b/arch/arm64/include/asm/io.h
> index 44be1e0..0041f3b 100644
> --- a/arch/arm64/include/asm/io.h
> +++ b/arch/arm64/include/asm/io.h
> @@ -193,6 +193,84 @@ extern void __iomem *ioremap_cache(phys_addr_t phys_addr, size_t size);
>   */
>  #define xlate_dev_kmem_ptr(p)	p
>  
> +#ifdef CONFIG_ARM64_INDIRECT_PIO
> +#define DEF_PCI_HOOK_pio(x)   x
> +#else
> +#define DEF_PCI_HOOK_pio(x)   NULL
> +#endif

Maybe just put the entire definition block inside #ifdef and
fall back to the default inb/outb definitions otherwise.

> +/*
> + * This value is equal to PCIBIOS_MIN_IO
> + */
> +#define LEGACY_ISA_PORT_MAX 0x1000

I would just use PCIBIOS_MIN_IO instead of defining another macro.

> +extern struct arm64_isa_io {
> +	u8 (*inb)(unsigned long port);
> +	u16 (*inw)(unsigned long port);
> +	u32 (*inl)(unsigned long port);
> +	void (*outb)(u8 value, unsigned long port);
> +	void (*outw)(u16 value, unsigned long port);
> +	void (*outl)(u32 value, unsigned long port);
> +} arm64_isa_io;

Maybe make this a single function pointer like

void (*arm64_indirect_pio)(unsigned long port, bool write, int size, void *data);

I'm guessing that this would result in smaller object code at the call sites,
but you'd have to try.

	Arnd

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [prev] | [next] | [standalone]

#1299019 — Re: [PATCH v1 1/3] ARM64 LPC: indirect ISA PORT IO introduced

Hi Arnd,

Thanks for your comment.

在 2015/12/29 21:47, Arnd Bergmann 写道:
> On Tuesday 29 December 2015 21:33:50 Rongrong Zou wrote:
>> Indirect ISA port I/O accessing introduced, vendors can hook
>> their own in/out function to general inb/outb. Drivers can access
>> legacy ISA I/O port by inb/outb as it is done in x86 platform.
>>
>> Signed-off-by: Rongrong Zou <zourongrong@gmail.com>
>
> Looks correct to me, but I have a few style comments
>
>> ---
>>   arch/arm64/Kconfig.platforms |  5 ++-
>>   arch/arm64/include/asm/io.h  | 78 ++++++++++++++++++++++++++++++++++++++++++++
>>   arch/arm64/kernel/setup.c    |  5 +++
>>   3 files changed, 87 insertions(+), 1 deletion(-)
>>
>> diff --git a/arch/arm64/Kconfig.platforms b/arch/arm64/Kconfig.platforms
>> index 4043c35..98ae206 100644
>> --- a/arch/arm64/Kconfig.platforms
>> +++ b/arch/arm64/Kconfig.platforms
>> @@ -127,5 +127,8 @@ config ARCH_ZYNQMP
>>   	bool "Xilinx ZynqMP Family"
>>   	help
>>   	  This enables support for Xilinx ZynqMP Family
>> -
>> +config ARM64_INDIRECT_PIO
>> +	bool "ARM64 Indirect port I/O"
>> +	help
>> +	  This enables support for ARM64 indirect port I/O
>>   endmenu
>
> The option should probably go into arch/arm64/Kconfig. Possibly you can make
> it a silent option that just gets selected whenever a driver is enabled
> that might set the callbacks.

I try to bind it with HISILICON platform.

>
>> diff --git a/arch/arm64/include/asm/io.h b/arch/arm64/include/asm/io.h
>> index 44be1e0..0041f3b 100644
>> --- a/arch/arm64/include/asm/io.h
>> +++ b/arch/arm64/include/asm/io.h
>> @@ -193,6 +193,84 @@ extern void __iomem *ioremap_cache(phys_addr_t phys_addr, size_t size);
>>    */
>>   #define xlate_dev_kmem_ptr(p)	p
>>
>> +#ifdef CONFIG_ARM64_INDIRECT_PIO
>> +#define DEF_PCI_HOOK_pio(x)   x
>> +#else
>> +#define DEF_PCI_HOOK_pio(x)   NULL
>> +#endif
>
> Maybe just put the entire definition block inside #ifdef and
> fall back to the default inb/outb definitions otherwise.
>
>> +/*
>> + * This value is equal to PCIBIOS_MIN_IO
>> + */
>> +#define LEGACY_ISA_PORT_MAX 0x1000
>
> I would just use PCIBIOS_MIN_IO instead of defining another macro.

Because PCIBIOS_MIN_IO is defined in asm/pci.h, and asm/io.h
is included by asm/pci.h. so do you mean i define PCIBIOS_MIN_IO here,
and in asm/pci.h just use include asm/io.h ?

>
>> +extern struct arm64_isa_io {
>> +	u8 (*inb)(unsigned long port);
>> +	u16 (*inw)(unsigned long port);
>> +	u32 (*inl)(unsigned long port);
>> +	void (*outb)(u8 value, unsigned long port);
>> +	void (*outw)(u16 value, unsigned long port);
>> +	void (*outl)(u32 value, unsigned long port);
>> +} arm64_isa_io;
>
> Maybe make this a single function pointer like
>
> void (*arm64_indirect_pio)(unsigned long port, bool write, int size, void *data);
>
> I'm guessing that this would result in smaller object code at the call sites,
> but you'd have to try.

OK, i try it.

>
> 	Arnd
>
> _______________________________________________
> linuxarm mailing list
> linuxarm@huawei.com
> http://rnd-openeuler.huawei.com/mailman/listinfo/linuxarm
>
> .
>

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [prev] | [next] | [standalone]

#1299021 — Re: [PATCH v1 1/3] ARM64 LPC: indirect ISA PORT IO introduced

On Tuesday 29 December 2015 22:26:27 Rongrong Zou wrote:
> 在 2015/12/29 21:47, Arnd Bergmann 写道:
> > On Tuesday 29 December 2015 21:33:50 Rongrong Zou wrote:
> >> Indirect ISA port I/O accessing introduced, vendors can hook
> >> their own in/out function to general inb/outb. Drivers can access
> >> legacy ISA I/O port by inb/outb as it is done in x86 platform.
> >>
> >> Signed-off-by: Rongrong Zou <zourongrong@gmail.com>
> >
> > Looks correct to me, but I have a few style comments
> >
> >> ---
> >>   arch/arm64/Kconfig.platforms |  5 ++-
> >>   arch/arm64/include/asm/io.h  | 78 ++++++++++++++++++++++++++++++++++++++++++++
> >>   arch/arm64/kernel/setup.c    |  5 +++
> >>   3 files changed, 87 insertions(+), 1 deletion(-)
> >>
> >> diff --git a/arch/arm64/Kconfig.platforms b/arch/arm64/Kconfig.platforms
> >> index 4043c35..98ae206 100644
> >> --- a/arch/arm64/Kconfig.platforms
> >> +++ b/arch/arm64/Kconfig.platforms
> >> @@ -127,5 +127,8 @@ config ARCH_ZYNQMP
> >>   	bool "Xilinx ZynqMP Family"
> >>   	help
> >>   	  This enables support for Xilinx ZynqMP Family
> >> -
> >> +config ARM64_INDIRECT_PIO
> >> +	bool "ARM64 Indirect port I/O"
> >> +	help
> >> +	  This enables support for ARM64 indirect port I/O
> >>   endmenu
> >
> > The option should probably go into arch/arm64/Kconfig. Possibly you can make
> > it a silent option that just gets selected whenever a driver is enabled
> > that might set the callbacks.
> 
> I try to bind it with HISILICON platform.

It should be possible to build the actual driver on all platforms, at
least with COMPILE_TEST.

> >> diff --git a/arch/arm64/include/asm/io.h b/arch/arm64/include/asm/io.h
> >> index 44be1e0..0041f3b 100644
> >> --- a/arch/arm64/include/asm/io.h
> >> +++ b/arch/arm64/include/asm/io.h
> >> @@ -193,6 +193,84 @@ extern void __iomem *ioremap_cache(phys_addr_t phys_addr, size_t size);
> >>    */
> >>   #define xlate_dev_kmem_ptr(p)	p
> >>
> >> +#ifdef CONFIG_ARM64_INDIRECT_PIO
> >> +#define DEF_PCI_HOOK_pio(x)   x
> >> +#else
> >> +#define DEF_PCI_HOOK_pio(x)   NULL
> >> +#endif
> >
> > Maybe just put the entire definition block inside #ifdef and
> > fall back to the default inb/outb definitions otherwise.
> >
> >> +/*
> >> + * This value is equal to PCIBIOS_MIN_IO
> >> + */
> >> +#define LEGACY_ISA_PORT_MAX 0x1000
> >
> > I would just use PCIBIOS_MIN_IO instead of defining another macro.
> 
> Because PCIBIOS_MIN_IO is defined in asm/pci.h, and asm/io.h
> is included by asm/pci.h. so do you mean i define PCIBIOS_MIN_IO here,
> and in asm/pci.h just use include asm/io.h ?

Yes, I guess that would work.

	Arnd
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [prev] | [next] | [standalone]

#1299195 — Re: [PATCH v1 1/3] ARM64 LPC: indirect ISA PORT IO introduced

在 2015/12/29 22:35, Arnd Bergmann 写道:
> On Tuesday 29 December 2015 22:26:27 Rongrong Zou wrote:
>> 在 2015/12/29 21:47, Arnd Bergmann 写道:
>>> On Tuesday 29 December 2015 21:33:50 Rongrong Zou wrote:
>>>> Indirect ISA port I/O accessing introduced, vendors can hook
>>>> their own in/out function to general inb/outb. Drivers can access
>>>> legacy ISA I/O port by inb/outb as it is done in x86 platform.
>>>>
>>>> Signed-off-by: Rongrong Zou <zourongrong@gmail.com>
>>>
>>> Looks correct to me, but I have a few style comments
>>>
>>>> ---
>>>>    arch/arm64/Kconfig.platforms |  5 ++-
>>>>    arch/arm64/include/asm/io.h  | 78 ++++++++++++++++++++++++++++++++++++++++++++
>>>>    arch/arm64/kernel/setup.c    |  5 +++
>>>>    3 files changed, 87 insertions(+), 1 deletion(-)
>>>>
>>>> diff --git a/arch/arm64/Kconfig.platforms b/arch/arm64/Kconfig.platforms
>>>> index 4043c35..98ae206 100644
>>>> --- a/arch/arm64/Kconfig.platforms
>>>> +++ b/arch/arm64/Kconfig.platforms
>>>> @@ -127,5 +127,8 @@ config ARCH_ZYNQMP
>>>>    	bool "Xilinx ZynqMP Family"
>>>>    	help
>>>>    	  This enables support for Xilinx ZynqMP Family
>>>> -
>>>> +config ARM64_INDIRECT_PIO
>>>> +	bool "ARM64 Indirect port I/O"
>>>> +	help
>>>> +	  This enables support for ARM64 indirect port I/O
>>>>    endmenu
>>>
>>> The option should probably go into arch/arm64/Kconfig. Possibly you can make
>>> it a silent option that just gets selected whenever a driver is enabled
>>> that might set the callbacks.
>>
>> I try to bind it with HISILICON platform.
>
> It should be possible to build the actual driver on all platforms, at
> least with COMPILE_TEST.

Sorry, I'm a little confused, can you describe it in detail?

>
>>>> diff --git a/arch/arm64/include/asm/io.h b/arch/arm64/include/asm/io.h
>>>> index 44be1e0..0041f3b 100644
>>>> --- a/arch/arm64/include/asm/io.h
>>>> +++ b/arch/arm64/include/asm/io.h
>>>> @@ -193,6 +193,84 @@ extern void __iomem *ioremap_cache(phys_addr_t phys_addr, size_t size);
>>>>     */
>>>>    #define xlate_dev_kmem_ptr(p)	p
>>>>
>>>> +#ifdef CONFIG_ARM64_INDIRECT_PIO
>>>> +#define DEF_PCI_HOOK_pio(x)   x
>>>> +#else
>>>> +#define DEF_PCI_HOOK_pio(x)   NULL
>>>> +#endif
>>>
>>> Maybe just put the entire definition block inside #ifdef and
>>> fall back to the default inb/outb definitions otherwise.
>>>
>>>> +/*
>>>> + * This value is equal to PCIBIOS_MIN_IO
>>>> + */
>>>> +#define LEGACY_ISA_PORT_MAX 0x1000
>>>
>>> I would just use PCIBIOS_MIN_IO instead of defining another macro.
>>
>> Because PCIBIOS_MIN_IO is defined in asm/pci.h, and asm/io.h
>> is included by asm/pci.h. so do you mean i define PCIBIOS_MIN_IO here,
>> and in asm/pci.h just use include asm/io.h ?
>
> Yes, I guess that would work.
>
> 	Arnd
>
> .
>

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [prev] | [next] | [standalone]

#1299269 — Re: [PATCH v1 1/3] ARM64 LPC: indirect ISA PORT IO introduced

On Wednesday 30 December 2015 09:24:04 Rongrong Zou wrote:
> >>>> diff --git a/arch/arm64/Kconfig.platforms b/arch/arm64/Kconfig.platforms
> >>>> index 4043c35..98ae206 100644
> >>>> --- a/arch/arm64/Kconfig.platforms
> >>>> +++ b/arch/arm64/Kconfig.platforms
> >>>> @@ -127,5 +127,8 @@ config ARCH_ZYNQMP
> >>>>            bool "Xilinx ZynqMP Family"
> >>>>            help
> >>>>              This enables support for Xilinx ZynqMP Family
> >>>> -
> >>>> +config ARM64_INDIRECT_PIO
> >>>> +  bool "ARM64 Indirect port I/O"
> >>>> +  help
> >>>> +    This enables support for ARM64 indirect port I/O
> >>>>    endmenu
> >>>
> >>> The option should probably go into arch/arm64/Kconfig. Possibly you can make
> >>> it a silent option that just gets selected whenever a driver is enabled
> >>> that might set the callbacks.
> >>
> >> I try to bind it with HISILICON platform.
> >
> > It should be possible to build the actual driver on all platforms, at
> > least with COMPILE_TEST.
> 
> Sorry, I'm a little confused, can you describe it in detail?
> 
> 

config ARM64_INDIRECT_PIO
	bool
	help
	  Any driver that provides indirect ISA I/O port access should select
	  this symbol

config HISILICON_HI123456_LPC
	bool "Workaround for nonstandard ISA I/O space on Hisilicon Hi123456 SoC"
	depends on ARCH_HISI || COMPILE_TEST
	select ARM64_INDIRECT_PIO
	help
	  ...


	Arnd
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [prev] | [next] | [standalone]

#1299278 — Re: [PATCH v1 1/3] ARM64 LPC: indirect ISA PORT IO introduced

在 2015/12/30 16:59, Arnd Bergmann 写道:
> On Wednesday 30 December 2015 09:24:04 Rongrong Zou wrote:
>>>>>> diff --git a/arch/arm64/Kconfig.platforms b/arch/arm64/Kconfig.platforms
>>>>>> index 4043c35..98ae206 100644
>>>>>> --- a/arch/arm64/Kconfig.platforms
>>>>>> +++ b/arch/arm64/Kconfig.platforms
>>>>>> @@ -127,5 +127,8 @@ config ARCH_ZYNQMP
>>>>>>             bool "Xilinx ZynqMP Family"
>>>>>>             help
>>>>>>               This enables support for Xilinx ZynqMP Family
>>>>>> -
>>>>>> +config ARM64_INDIRECT_PIO
>>>>>> +  bool "ARM64 Indirect port I/O"
>>>>>> +  help
>>>>>> +    This enables support for ARM64 indirect port I/O
>>>>>>     endmenu
>>>>>
>>>>> The option should probably go into arch/arm64/Kconfig. Possibly you can make
>>>>> it a silent option that just gets selected whenever a driver is enabled
>>>>> that might set the callbacks.
>>>>
>>>> I try to bind it with HISILICON platform.
>>>
>>> It should be possible to build the actual driver on all platforms, at
>>> least with COMPILE_TEST.
>>
>> Sorry, I'm a little confused, can you describe it in detail?
>>
>>
>
> config ARM64_INDIRECT_PIO
> 	bool
> 	help
> 	  Any driver that provides indirect ISA I/O port access should select
> 	  this symbol


>
> config HISILICON_HI123456_LPC
> 	bool "Workaround for nonstandard ISA I/O space on Hisilicon Hi123456 SoC"
> 	depends on ARCH_HISI || COMPILE_TEST
> 	select ARM64_INDIRECT_PIO
> 	help
> 	  ...
Can it be a submenu of "Platform selection--->Hisilicon SoC Family"?



>
>
> 	Arnd
>
> .
>

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [prev] | [next] | [standalone]

#1299284 — Re: [PATCH v1 1/3] ARM64 LPC: indirect ISA PORT IO introduced

On Wednesday 30 December 2015 17:28:20 Rongrong Zou wrote:
> >>
> >
> > config ARM64_INDIRECT_PIO
> >       bool
> >       help
> >         Any driver that provides indirect ISA I/O port access should select
> >         this symbol
> 
> 
> >
> > config HISILICON_HI123456_LPC
> >       bool "Workaround for nonstandard ISA I/O space on Hisilicon Hi123456 SoC"
> >       depends on ARCH_HISI || COMPILE_TEST
> >       select ARM64_INDIRECT_PIO
> >       help
> >         ...
> Can it be a submenu of "Platform selection--->Hisilicon SoC Family"?

The first should be in the main Kconfig file for arm64, the second one depends
on where we put the respective code. I'd say both the Kconfig entry and the file
can go into drivers/bus, but arch/arm64/kernel/ is also fine with me.

	Arnd
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [prev] | [next] | [standalone]

#1298996 — [PATCH v1 3/3] ARM64 LPC: update binding doc

Signed-off-by: Rongrong Zou <zourongrong@gmail.com>
---
 .../devicetree/bindings/arm64/low-pin-count.txt      | 20 ++++++++++++++++++++
 1 file changed, 20 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/arm64/low-pin-count.txt

diff --git a/Documentation/devicetree/bindings/arm64/low-pin-count.txt b/Documentation/devicetree/bindings/arm64/low-pin-count.txt
new file mode 100644
index 0000000..215f2c4
--- /dev/null
+++ b/Documentation/devicetree/bindings/arm64/low-pin-count.txt
@@ -0,0 +1,20 @@
+Low Pin Count bus driver
+
+Usually LPC controller is part of PCI host bridge, so the legacy ISA
+port locate on LPC bus can be accessed directly. But some SoC have
+independent LPC controller, and we can access the legacy port by specifying
+LPC address cycle. Thus, LPC driver is introduced.
+
+Required properties:
+- compatible: "low-pin-count"
+- reg: specifies low pin count address range
+
+
+Example:
+
+        lpc_0: lpc@a01b0000 {
+		#address-cells = <1>;
+		#size-cells = <1>;
+                compatible = "low-pin-count";
+                reg = <0x0 0xa01b0000 0x0 0x10000>;
+        };
-- 
1.9.1

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [prev] | [next] | [standalone]

#1299006 — Re: [PATCH v1 3/3] ARM64 LPC: update binding doc

On Tuesday 29 December 2015 21:33:52 Rongrong Zou wrote:
> Signed-off-by: Rongrong Zou <zourongrong@gmail.com>
> ---
>  .../devicetree/bindings/arm64/low-pin-count.txt      | 20 ++++++++++++++++++++
>  1 file changed, 20 insertions(+)
>  create mode 100644 Documentation/devicetree/bindings/arm64/low-pin-count.txt

Please add a patch description above and Cc the devicetree mailing list
when you submit it again.

> diff --git a/Documentation/devicetree/bindings/arm64/low-pin-count.txt b/Documentation/devicetree/bindings/arm64/low-pin-count.txt
> new file mode 100644
> index 0000000..215f2c4
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/arm64/low-pin-count.txt
> @@ -0,0 +1,20 @@
> +Low Pin Count bus driver
> +
> +Usually LPC controller is part of PCI host bridge, so the legacy ISA
> +port locate on LPC bus can be accessed directly. But some SoC have
> +independent LPC controller, and we can access the legacy port by specifying
> +LPC address cycle. Thus, LPC driver is introduced.
> +
> +Required properties:
> +- compatible: "low-pin-count"
> +- reg: specifies low pin count address range
> +

It would be good to add an explanation about the address space for child
devices.

	Arnd
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [prev] | [next] | [standalone]

#1299274 — Re: [PATCH v1 3/3] ARM64 LPC: update binding doc

On Tuesday 29 December 2015 21:33:52 Rongrong Zou wrote:
> Signed-off-by: Rongrong Zou <zourongrong@gmail.com>
> ---
>  .../devicetree/bindings/arm64/low-pin-count.txt      | 20 ++++++++++++++++++++
>  1 file changed, 20 insertions(+)
>  create mode 100644 Documentation/devicetree/bindings/arm64/low-pin-count.txt
> 
> diff --git a/Documentation/devicetree/bindings/arm64/low-pin-count.txt b/Documentation/devicetree/bindings/arm64/low-pin-count.txt
> new file mode 100644
> index 0000000..215f2c4
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/arm64/low-pin-count.txt
> @@ -0,0 +1,20 @@
> +Low Pin Count bus driver
> +
> +Usually LPC controller is part of PCI host bridge, so the legacy ISA
> +port locate on LPC bus can be accessed directly. But some SoC have
> +independent LPC controller, and we can access the legacy port by specifying
> +LPC address cycle. Thus, LPC driver is introduced.
> +
> +Required properties:
> +- compatible: "low-pin-count"
> +- reg: specifies low pin count address range
> +
> +
> +Example:
> +
> +        lpc_0: lpc@a01b0000 {
> +		#address-cells = <1>;
> +		#size-cells = <1>;
> +                compatible = "low-pin-count";
> +                reg = <0x0 0xa01b0000 0x0 0x10000>;
> +        };

One more thought: please try to stick as closely as possible to the existing
ISA binding that is documented at

http://www.firmware.org/1275/bindings/isa/isa0_4d.ps

In particular, this should cover the possibility of describing both memory
and I/O spaces in child devices.

	Arnd
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [prev] | [next] | [standalone]

#1299673 — Re: [PATCH v1 3/3] ARM64 LPC: update binding doc

Sorry for so late reply, it is difficult for me to understand ISA config :( .

在 2015/12/30 17:06, Arnd Bergmann 写道:
> On Tuesday 29 December 2015 21:33:52 Rongrong Zou wrote:
>> Signed-off-by: Rongrong Zou <zourongrong@gmail.com>
>> ---
>>   .../devicetree/bindings/arm64/low-pin-count.txt      | 20 ++++++++++++++++++++
>>   1 file changed, 20 insertions(+)
>>   create mode 100644 Documentation/devicetree/bindings/arm64/low-pin-count.txt
>>
>> diff --git a/Documentation/devicetree/bindings/arm64/low-pin-count.txt b/Documentation/devicetree/bindings/arm64/low-pin-count.txt
>> new file mode 100644
>> index 0000000..215f2c4
>> --- /dev/null
>> +++ b/Documentation/devicetree/bindings/arm64/low-pin-count.txt
>> @@ -0,0 +1,20 @@
>> +Low Pin Count bus driver
>> +
>> +Usually LPC controller is part of PCI host bridge, so the legacy ISA
>> +port locate on LPC bus can be accessed directly. But some SoC have
>> +independent LPC controller, and we can access the legacy port by specifying
>> +LPC address cycle. Thus, LPC driver is introduced.
>> +
>> +Required properties:
>> +- compatible: "low-pin-count"
>> +- reg: specifies low pin count address range
>> +
>> +
>> +Example:
>> +
>> +        lpc_0: lpc@a01b0000 {
>> +		#address-cells = <1>;
>> +		#size-cells = <1>;
>> +                compatible = "low-pin-count";
>> +                reg = <0x0 0xa01b0000 0x0 0x10000>;
>> +        };
>
> One more thought: please try to stick as closely as possible to the existing
> ISA binding that is documented at
>
> http://www.firmware.org/1275/bindings/isa/isa0_4d.ps
 From the specification, I think I should use 2 32bit integer to describe the isa addr in dts.
>
> In particular, this should cover the possibility of describing both memory
> and I/O spaces in child devices.
>

I found below config in powerpc dts "arch/powerpc/boot/dts/mpc8544ds.dts"

isa@1e {
                                 device_type = "isa";
                                 #interrupt-cells = <2>;
                                 #size-cells = <1>;
                                 #address-cells = <2>;
                                 reg = <0xf000 0x0 0x0 0x0 0x0>;
                                 ranges = <0x1 0x0 0x1000000 0x0 0x0
                                           0x1000>;
                                 interrupt-parent = <&i8259>;



                                 rtc@70 {
                                         compatible = "pnpPNP,b00";
                                         reg = <0x1 0x70 0x2>;
                                 };
  the isa space in child-node: reg = <0x1 0x70 0x2>;
  0x1 means IO space, 70 means addr, 0x2 is size.
  but when i config the following in dts, the ipmi_0 node can't be probed,
  I think there may be some problems.

lpc_0: lpc@a01b0000 {
	compatible = "low-pin-count";
	device_type = "isa";
	#address-cells = <2>;
	#size-cells = <1>;
	reg = <0x0 0xa01b0000 0x0 0x10000>;

	ipmi_0:ipmi@000000e4{
		device_type = "ipmi";
		compatible = "ipmi-bt";
		reg = <0x1 0x000000e4 0x4>;
};







> 	Arnd
> _______________________________________________
> linuxarm mailing list
> linuxarm@huawei.com
> http://rnd-openeuler.huawei.com/mailman/listinfo/linuxarm
>
>

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [prev] | [next] | [standalone]

#1299676 — Re: [PATCH v1 3/3] ARM64 LPC: update binding doc

On Thursday 31 December 2015 22:12:19 Rongrong Zou wrote:
> 在 2015/12/30 17:06, Arnd Bergmann 写道:
> > On Tuesday 29 December 2015 21:33:52 Rongrong Zou wrote:
> >> +Example:
> >> +
> >> +        lpc_0: lpc@a01b0000 {
> >> +		#address-cells = <1>;
> >> +		#size-cells = <1>;
> >> +                compatible = "low-pin-count";
> >> +                reg = <0x0 0xa01b0000 0x0 0x10000>;
> >> +        };
> >
> > One more thought: please try to stick as closely as possible to the existing
> > ISA binding that is documented at
> >
> > http://www.firmware.org/1275/bindings/isa/isa0_4d.ps
>  From the specification, I think I should use 2 32bit integer to describe the isa addr in dts.
> >
> > In particular, this should cover the possibility of describing both memory
> > and I/O spaces in child devices.
> >
> 
> I found below config in powerpc dts "arch/powerpc/boot/dts/mpc8544ds.dts"
> 
> isa@1e {
>                                  device_type = "isa";
>                                  #interrupt-cells = <2>;
>                                  #size-cells = <1>;
>                                  #address-cells = <2>;
>                                  reg = <0xf000 0x0 0x0 0x0 0x0>;
>                                  ranges = <0x1 0x0 0x1000000 0x0 0x0
>                                            0x1000>;
>                                  interrupt-parent = <&i8259>;
> 
> 
> 
>                                  rtc@70 {
>                                          compatible = "pnpPNP,b00";
>                                          reg = <0x1 0x70 0x2>;
>                                  };
>   the isa space in child-node: reg = <0x1 0x70 0x2>;
>   0x1 means IO space, 70 means addr, 0x2 is size.
>   but when i config the following in dts, the ipmi_0 node can't be probed,
>   I think there may be some problems.
> 
> lpc_0: lpc@a01b0000 {
> 	compatible = "low-pin-count";
> 	device_type = "isa";
> 	#address-cells = <2>;
> 	#size-cells = <1>;
> 	reg = <0x0 0xa01b0000 0x0 0x10000>;
> 
> 	ipmi_0:ipmi@000000e4{
> 		device_type = "ipmi";
> 		compatible = "ipmi-bt";
> 		reg = <0x1 0x000000e4 0x4>;
> };

The DT sample above looks good in principle. I believe what you are missing
here is code in your driver to scan the child nodes to create the platform
devices. of_bus_isa_translate() should work with your definition here
and create the correct IORESOURCE_IO resources. You don't have any MMIO
resources, so the absence of a ranges property is ok. Maybe all you 
are missing is a call to of_platform_populate() or of_platform_bus_probe()?

	Arnd
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [prev] | [standalone]

Back to top | Article view | linux.kernel

csiph-web