[PATCH v3 00/12] J-core J2 cpu and SoC peripherals support

[PATCH v3 00/12] J-core J2 cpu and SoC peripherals support

[Rich Felker]

The following patchset adds support for the J-core J2, an open-source
VHDL reimplementation of the SH-2 ISA, and drivers for the associated
SoC devices (interrupt controller, clocksource, and SPI).

As arch/sh co-maintainer my intent is to include as much as possible
in my pull request for the linux-sh tree. If there are parts outside
of arch/sh that can be included in this, please let me know. I'm not
clear yet on what the right path to upstream is for the clocksource
and irq drivers that are currently only useful/interesting for one
arch, or for the DT binding patches. Even if some drivers are delayed
going upstream, I would really like to get DT bindings acked and
ideally merged, because we want to go ahead with moving the DTB into
J2 boot rom where it belongs, and that should only happen with stable
bindings.

Rich Felker (12):
  of: add vendor prefix for J-Core
  of: add J-Core cpu bindings
  of: add J-Core interrupt controller bindings
  of: add J-Core timer bindings
  of: add J-Core SPI master bindings
  sh: add support for J-Core J2 processor
  sh: add AT_HWCAP flag for J-Core cas.l instruction
  irqchip: add J-Core AIC driver
  clocksource: add J-Core timer/clocksource driver
  spi: add driver for J-Core SPI controller
  sh: add defconfig for J-Core J2
  sh: add device tree source for J2 FPGA on Mimas v2 board

 .../bindings/interrupt-controller/jcore,aic.txt    |  29 +++
 Documentation/devicetree/bindings/jcore/cpus.txt   |  92 +++++++
 .../devicetree/bindings/spi/jcore,spi.txt          |  23 ++
 .../devicetree/bindings/timer/jcore,pit.txt        |  28 ++
 .../devicetree/bindings/vendor-prefixes.txt        |   1 +
 arch/sh/Kconfig                                    |   8 +
 arch/sh/Makefile                                   |   1 +
 arch/sh/boot/dts/j2_mimas_v2.dts                   |  87 +++++++
 arch/sh/configs/j2_defconfig                       |  38 +++
 arch/sh/include/asm/processor.h                    |   2 +-
 arch/sh/include/uapi/asm/cpu-features.h            |   1 +
 arch/sh/kernel/cpu/init.c                          |   2 +-
 arch/sh/kernel/cpu/proc.c                          |   1 +
 arch/sh/kernel/cpu/sh2/entry.S                     |   5 +
 arch/sh/kernel/cpu/sh2/probe.c                     |  36 ++-
 arch/sh/mm/Makefile                                |   3 +-
 arch/sh/mm/cache-j2.c                              |  58 +++++
 arch/sh/mm/cache.c                                 |   6 +-
 drivers/clocksource/Kconfig                        |   8 +
 drivers/clocksource/Makefile                       |   1 +
 drivers/clocksource/jcore-pit.c                    | 282 +++++++++++++++++++++
 drivers/irqchip/Kconfig                            |   6 +
 drivers/irqchip/Makefile                           |   1 +
 drivers/irqchip/irq-jcore-aic.c                    |  95 +++++++
 drivers/spi/Kconfig                                |   4 +
 drivers/spi/Makefile                               |   1 +
 drivers/spi/spi-jcore.c                            | 209 +++++++++++++++
 27 files changed, 1023 insertions(+), 5 deletions(-)
 create mode 100644 Documentation/devicetree/bindings/interrupt-controller/jcore,aic.txt
 create mode 100644 Documentation/devicetree/bindings/jcore/cpus.txt
 create mode 100644 Documentation/devicetree/bindings/spi/jcore,spi.txt
 create mode 100644 Documentation/devicetree/bindings/timer/jcore,pit.txt
 create mode 100755 arch/sh/boot/dts/j2_mimas_v2.dts
 create mode 100644 arch/sh/configs/j2_defconfig
 create mode 100644 arch/sh/mm/cache-j2.c
 create mode 100644 drivers/clocksource/jcore-pit.c
 create mode 100644 drivers/irqchip/irq-jcore-aic.c
 create mode 100644 drivers/spi/spi-jcore.c

-- 
2.8.1

--
To unsubscribe from this list: send the line "unsubscribe linux-spi" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH v3 05/12] of: add J-Core SPI master bindings

[Rich Felker]

Signed-off-by: Rich Felker <dalias@libc.org>
---
 .../devicetree/bindings/spi/jcore,spi.txt          | 23 ++++++++++++++++++++++
 1 file changed, 23 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/spi/jcore,spi.txt

diff --git a/Documentation/devicetree/bindings/spi/jcore,spi.txt b/Documentation/devicetree/bindings/spi/jcore,spi.txt
new file mode 100644
index 0000000..7bff8c0
--- /dev/null
+++ b/Documentation/devicetree/bindings/spi/jcore,spi.txt
@@ -0,0 +1,23 @@
+J-Core SPI master
+
+Required properties:
+
+- compatible: Must be "jcore,spi2".
+
+- reg: Memory region for registers.
+
+- #address-cells: Must be 1.
+
+- #size-cells: Must be 0.
+
+See spi-bus.txt for additional properties not specific to this device.
+
+Example:
+
+spi@40 {
+	compatible = "jcore,spi2";
+	#address-cells = <1>;
+	#size-cells = <0>;
+	reg = < 0x40 0x8 >;
+	spi-max-frequency = <12500000>;
+}
-- 
2.8.1

Re: [PATCH v3 05/12] of: add J-Core SPI master bindings

[Rob Herring]

On Wed, May 25, 2016 at 05:43:03AM +0000, Rich Felker wrote:
> Signed-off-by: Rich Felker <dalias@libc.org>
> ---
>  .../devicetree/bindings/spi/jcore,spi.txt          | 23 ++++++++++++++++++++++
>  1 file changed, 23 insertions(+)
>  create mode 100644 Documentation/devicetree/bindings/spi/jcore,spi.txt

Acked-by: Rob Herring <robh@kernel.org>

[PATCH v3 10/12] spi: add driver for J-Core SPI controller

[Rich Felker]

The J-Core "spi2" device is a PIO-based SPI master controller. It
differs from "bitbang" devices in that that it's clocked in hardware
rather than via soft clock modulation over gpio, and performs
byte-at-a-time transfers between the cpu and SPI controller.

This driver will be extended to support future versions of the J-Core
SPI controller with DMA transfers when they become available.

Signed-off-by: Rich Felker <dalias@libc.org>
---

This version of the SPI patch eliminates USE_MESSAGE_MODE (the open
coding of transfer_one_message logic) and makes severl other minor
changes based on ml discussion of the v2 patch. The chipselect change
has not been made yet, except for rewriting the current logic to be
more clear. If the decision is that it's needed, I can do it easily,
but it needs testing still.

 drivers/spi/Kconfig     |   4 +
 drivers/spi/Makefile    |   1 +
 drivers/spi/spi-jcore.c | 209 ++++++++++++++++++++++++++++++++++++++++++++++++
 3 files changed, 214 insertions(+)
 create mode 100644 drivers/spi/spi-jcore.c

diff --git a/drivers/spi/Kconfig b/drivers/spi/Kconfig
index 9d8c84b..5bd2ccf 100644
--- a/drivers/spi/Kconfig
+++ b/drivers/spi/Kconfig
@@ -285,6 +285,10 @@ config SPI_IMX
 	  This enables using the Freescale i.MX SPI controllers in master
 	  mode.
 
+config SPI_JCORE
+	tristate "J-Core SPI Master"
+	depends on OF
+
 config SPI_LM70_LLP
 	tristate "Parallel port adapter for LM70 eval board (DEVELOPMENT)"
 	depends on PARPORT
diff --git a/drivers/spi/Makefile b/drivers/spi/Makefile
index fbb255c..6a34124 100644
--- a/drivers/spi/Makefile
+++ b/drivers/spi/Makefile
@@ -46,6 +46,7 @@ obj-$(CONFIG_SPI_FSL_SPI)		+= spi-fsl-spi.o
 obj-$(CONFIG_SPI_GPIO)			+= spi-gpio.o
 obj-$(CONFIG_SPI_IMG_SPFI)		+= spi-img-spfi.o
 obj-$(CONFIG_SPI_IMX)			+= spi-imx.o
+obj-$(CONFIG_SPI_JCORE)			+= spi-jcore.o
 obj-$(CONFIG_SPI_LM70_LLP)		+= spi-lm70llp.o
 obj-$(CONFIG_SPI_LP8841_RTC)		+= spi-lp8841-rtc.o
 obj-$(CONFIG_SPI_MESON_SPIFC)		+= spi-meson-spifc.o
diff --git a/drivers/spi/spi-jcore.c b/drivers/spi/spi-jcore.c
new file mode 100644
index 0000000..f239087
--- /dev/null
+++ b/drivers/spi/spi-jcore.c
@@ -0,0 +1,209 @@
+/*
+ * J-Core SPI controller driver
+ *
+ * Copyright (C) 2012-2016 Smart Energy Instruments, Inc.
+ *
+ * Current version by Rich Felker
+ * Based loosely on initial version by Oleksandr G Zhadan
+ *
+ */
+#include <linux/init.h>
+#include <linux/interrupt.h>
+#include <linux/errno.h>
+#include <linux/module.h>
+#include <linux/platform_device.h>
+#include <linux/spi/spi.h>
+#include <linux/io.h>
+#include <linux/of.h>
+#include <linux/delay.h>
+
+#define DRV_NAME "jcore_spi"
+
+#define MAX_SPI_SPEED	12500000	/* 12.5 MHz */
+
+#define CTRL_REG	0x0
+#define DATA_REG	0x4
+
+#define SPI_NOCHIP_CS	0
+#define SPI_FLASH_CS	1
+#define SPI_CONF_CS	2
+#define SPI_SD_CS	2
+#define SPI_CODEC_CS	3
+
+#define JCORE_SPI_CTRL_XMIT		0x02
+#define JCORE_SPI_STAT_BUSY		0x02
+#define JCORE_SPI_CTRL_LOOP		0x08
+#define JCORE_SPI_CTRL_CS_BITS		0x15
+
+#define JCORE_SPI_WAIT_RDY_MAX_LOOP	2000000
+
+struct jcore_spi {
+	struct spi_master *master;
+	void __iomem *base;
+	volatile unsigned int ctrlReg;
+	unsigned int csReg;
+	unsigned int speedReg;
+	unsigned int speed_hz;
+};
+
+static void jcore_spi_wait_till_ready(struct jcore_spi *hw, int timeout)
+{
+	while (timeout--) {
+		hw->ctrlReg = readl(hw->base + CTRL_REG);
+		if (!(hw->ctrlReg & JCORE_SPI_STAT_BUSY))
+			return;
+		cpu_relax();
+	}
+	dev_err(hw->master->dev.parent, "%s: Timeout..\n", __func__);
+}
+
+static void jcore_spi_program(struct jcore_spi *hw)
+{
+	jcore_spi_wait_till_ready(hw, JCORE_SPI_WAIT_RDY_MAX_LOOP);
+	writel(hw->csReg | hw->speedReg, hw->base + CTRL_REG);	
+}
+
+static void jcore_spi_chipsel(struct spi_device *spi, bool value)
+{
+	struct jcore_spi *hw = spi_master_get_devdata(spi->master);
+
+	dev_dbg(hw->master->dev.parent, "%s: CS=%d\n", __func__, value);
+
+	hw->csReg = JCORE_SPI_CTRL_CS_BITS ^ (!value << 2*spi->chip_select);
+
+	jcore_spi_program(hw);
+}
+
+static void jcore_spi_baudrate(struct jcore_spi *hw, int speed)
+{
+	if (speed == hw->speed_hz) return;
+	hw->speed_hz = speed;
+	hw->speedReg = ((MAX_SPI_SPEED / speed) - 1) << 27;
+	jcore_spi_program(hw);
+	dev_dbg(hw->master->dev.parent, "%s: speed=%d pre=0x%x\n",
+		__func__, speed, hw->speedReg);
+}
+
+static int jcore_spi_txrx(struct spi_master *master, struct spi_device *spi,
+			  struct spi_transfer *t)
+{
+	struct jcore_spi *hw = spi_master_get_devdata(master);
+
+	void *ctrl_reg = hw->base + CTRL_REG;
+	void *data_reg = hw->base + DATA_REG;
+	unsigned int timeout;
+	u32 xmit;
+	u32 status;
+
+	/* data buffers */
+	const unsigned char *tx;
+	unsigned char *rx;
+	unsigned int len;
+	unsigned int count;
+
+	jcore_spi_baudrate(hw, t->speed_hz);
+
+	xmit = hw->csReg | hw->speedReg | JCORE_SPI_CTRL_XMIT;
+	tx = t->tx_buf;
+	rx = t->rx_buf;
+	len = t->len;
+
+	for (count = 0; count < len; count++) {
+		timeout = JCORE_SPI_WAIT_RDY_MAX_LOOP;
+		do {
+			status = readl(ctrl_reg);
+		} while ((status & JCORE_SPI_STAT_BUSY) && --timeout);
+		if (!timeout)
+			break;
+
+		writel(tx ? *tx++ : 0, data_reg);
+		writel(xmit, ctrl_reg);
+
+		timeout = JCORE_SPI_WAIT_RDY_MAX_LOOP;
+		do {
+			status = readl(ctrl_reg);
+		} while ((status & JCORE_SPI_STAT_BUSY) && --timeout);
+		if (!timeout)
+			break;
+
+		if (rx)
+			*rx++ = readl(data_reg);
+	}
+
+	spi_finalize_current_transfer(master);
+
+	return count<len ? -EREMOTEIO : 0;
+}
+
+static int jcore_spi_probe(struct platform_device *pdev)
+{
+	struct device_node *node = pdev->dev.of_node;
+	struct jcore_spi *hw;
+	struct spi_master *master;
+	struct resource *res;
+	int err = -ENODEV;
+
+	master = spi_alloc_master(&pdev->dev, sizeof(struct jcore_spi));
+	if (!master)
+		return err;
+
+	/* setup the master state. */
+	master->num_chipselect = 3;
+	master->mode_bits = SPI_MODE_3;
+	master->transfer_one = jcore_spi_txrx;
+	master->set_cs = jcore_spi_chipsel;
+	master->dev.of_node = node;
+
+	hw = spi_master_get_devdata(master);
+	hw->master = master;
+	platform_set_drvdata(pdev, hw);
+
+	/* find and map our resources */
+	res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
+	if (!res)
+		goto exit_busy;
+	if (!devm_request_mem_region
+	    (&pdev->dev, res->start, resource_size(res), pdev->name))
+		goto exit_busy;
+	hw->base =
+	    devm_ioremap_nocache(&pdev->dev, res->start, resource_size(res));
+	if (!hw->base)
+		goto exit_busy;
+
+	jcore_spi_baudrate(hw, 400000);
+
+	pdev->dev.dma_mask = 0;
+	/* register our spi controller */
+	err = devm_spi_register_master(&pdev->dev, master);
+	if (err)
+		goto exit;
+	dev_info(&pdev->dev, "base %p, noirq\n", hw->base);
+
+	return 0;
+
+exit_busy:
+	err = -EBUSY;
+exit:
+	platform_set_drvdata(pdev, NULL);
+	spi_master_put(master);
+	return err;
+}
+
+static const struct of_device_id jcore_spi_of_match[] = {
+	{ .compatible = "jcore,spi2" },
+	{},
+};
+
+static struct platform_driver jcore_spi_driver = {
+	.probe = jcore_spi_probe,
+	.driver = {
+		.name = DRV_NAME,
+		.of_match_table = jcore_spi_of_match,
+	},
+};
+
+module_platform_driver(jcore_spi_driver);
+
+MODULE_DESCRIPTION("J-Core SPI driver");
+MODULE_AUTHOR("Rich Felker <dalias@libc.org>");
+MODULE_ALIAS("platform:" DRV_NAME);
-- 
2.8.1

Re: [PATCH v3 10/12] spi: add driver for J-Core SPI controller

[Mark Brown]

[-- Attachment #1: Type: text/plain, Size: 642 bytes --]

On Wed, May 25, 2016 at 05:43:03AM +0000, Rich Felker wrote:

> changes based on ml discussion of the v2 patch. The chipselect change
> has not been made yet, except for rewriting the current logic to be
> more clear. If the decision is that it's needed, I can do it easily,
> but it needs testing still.

You need to fix that, it's not good to just decide to ignore review
comments.  It is astonishing that you are doing this while expecting to
bypass the normal process for merging things.  I'm not going to look at
this version, please ensure you have addressed all the feedback from the
previous review before any new version you submit.

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 473 bytes --]

Re: [PATCH v3 10/12] spi: add driver for J-Core SPI controller

[Rich Felker]

On Wed, May 25, 2016 at 11:17:08AM +0100, Mark Brown wrote:
> On Wed, May 25, 2016 at 05:43:03AM +0000, Rich Felker wrote:
> 
> > changes based on ml discussion of the v2 patch. The chipselect change
> > has not been made yet, except for rewriting the current logic to be
> > more clear. If the decision is that it's needed, I can do it easily,
> > but it needs testing still.
> 
> You need to fix that, it's not good to just decide to ignore review
> comments.  It is astonishing that you are doing this while expecting to
> bypass the normal process for merging things.  I'm not going to look at
> this version, please ensure you have addressed all the feedback from the
> previous review before any new version you submit.

I've made and tested a change that looks like what you want, with the
hw->csReg's chipselect bits set initially high in the probe function,
and only the requested bit being modified by the chipselect function.
Would you prefer I continue to submit this driver with new versions of
the patch series, or separate it out for further review on its own?

Rich

Re: [PATCH v3 10/12] spi: add driver for J-Core SPI controller

[Mark Brown]

[-- Attachment #1: Type: text/plain, Size: 251 bytes --]

On Thu, May 26, 2016 at 09:16:21PM -0400, Rich Felker wrote:

> Would you prefer I continue to submit this driver with new versions of
> the patch series, or separate it out for further review on its own?

It would be clearer to submit it separately.

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 473 bytes --]

Re: [PATCH v3 00/12] J-core J2 cpu and SoC peripherals support

[Geert Uytterhoeven]

Hi Rich,

On Wed, May 25, 2016 at 7:43 AM, Rich Felker <dalias-8zAoT0mYgF4@public.gmane.org> wrote:
> As arch/sh co-maintainer my intent is to include as much as possible
> in my pull request for the linux-sh tree. If there are parts outside
> of arch/sh that can be included in this, please let me know. I'm not
> clear yet on what the right path to upstream is for the clocksource
> and irq drivers that are currently only useful/interesting for one
> arch, or for the DT binding patches. Even if some drivers are delayed

Drivers outside arch/sh/ should go through the respective maintainer's tree,
unless that maintainer allows you to take it by giving his Acked-by.
The same for DT bindings for such drivers.

> going upstream, I would really like to get DT bindings acked and
> ideally merged, because we want to go ahead with moving the DTB into
> J2 boot rom where it belongs, and that should only happen with stable
> bindings.

Please also add a changelog, so people who reviewed your previous series
before know what to skip and what to focus on.
Please add collected Acked-by and Reviewed-by tags when reposting.

Thanks!

Gr{oetje,eeting}s,

                        Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert-Td1EMuHUCqxL1ZNQvxDV9g@public.gmane.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
                                -- Linus Torvalds
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v3 00/12] J-core J2 cpu and SoC peripherals support

[Mark Brown]

[-- Attachment #1: Type: text/plain, Size: 1292 bytes --]

On Wed, May 25, 2016 at 05:43:02AM +0000, Rich Felker wrote:

> As arch/sh co-maintainer my intent is to include as much as possible
> in my pull request for the linux-sh tree. If there are parts outside
> of arch/sh that can be included in this, please let me know. I'm not

Do *not* include the SPI driver, you shouldn't be including any drivers
unless it's been explicitly discussed with the subsystem maintainers.

Quite aside from the fact that like Geert says drivers are expected to
go through the subsystem trees to repeat what I said last time it wasn't
posted until after the merge window and we're now a few days before the
end of the merge window and a new version is being posted.  The
turnaround times you are demanding on review are unreasonable - people
get busy, have holidays and so on - and you really need to pay attention
to what people are telling you about the process or you're just going to
annoy people.

> arch, or for the DT binding patches. Even if some drivers are delayed
> going upstream, I would really like to get DT bindings acked and
> ideally merged, because we want to go ahead with moving the DTB into
> J2 boot rom where it belongs, and that should only happen with stable

If you want people to review DT bindings you're going to need to submit
them.

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 473 bytes --]

Re: [PATCH v3 00/12] J-core J2 cpu and SoC peripherals support

[Rich Felker]

On Wed, May 25, 2016 at 10:54:44AM +0100, Mark Brown wrote:
> On Wed, May 25, 2016 at 05:43:02AM +0000, Rich Felker wrote:
> 
> > As arch/sh co-maintainer my intent is to include as much as possible
> > in my pull request for the linux-sh tree. If there are parts outside
> > of arch/sh that can be included in this, please let me know. I'm not
> 
> Do *not* include the SPI driver, you shouldn't be including any drivers
> unless it's been explicitly discussed with the subsystem maintainers.

See the "please let me know". I thought this was plenty clear that I
was asking for permission for including things outside of arch/sh, and
that short of getting an ack, the default permission is no. You also
snipped the part of my message that mentioned the specific subsystems
I was asking about (which were non-SPI because you already made quite
a point about not taking the SPI driver):

> > clear yet on what the right path to upstream is for the clocksource
> > and irq drivers that are currently only useful/interesting for one
> > arch, or for the DT binding patches. Even if some drivers are delayed
> > [...]

> Quite aside from the fact that like Geert says drivers are expected to
> go through the subsystem trees to repeat what I said last time it wasn't
> posted until after the merge window and we're now a few days before the
> end of the merge window and a new version is being posted.  The
> turnaround times you are demanding on review are unreasonable - people
> get busy, have holidays and so on - and you really need to pay attention
> to what people are telling you about the process or you're just going to
> annoy people.

If you can't review and ack the code on short notice, that's fine;
just say so. There's no need to be overerly hostile about it. I've
gotten arch/sh patches during the merge window before and I try to be
polite with the contributor and ask if there's something seriously
broken that would be improved by my making an effort to check it at
the last minute, or it if can happily wait until next time.

Being that the driver in question here is for a new platform that was
not previously supported upstream and has zero chance of breaking
anything else, and that its inclusion would be a big plus for users of
the platform, I don't see any reason for you making such a big deal
out of it unless enforcing policy for its own sake makes you feel
good, but I have better things to do than argue about it.

> > arch, or for the DT binding patches. Even if some drivers are delayed
> > going upstream, I would really like to get DT bindings acked and
> > ideally merged, because we want to go ahead with moving the DTB into
> > J2 boot rom where it belongs, and that should only happen with stable
> 
> If you want people to review DT bindings you're going to need to submit
> them.

I have, twice now, and I Cc'd the the linux-spi list too on v3 for the
spi binding. Rob Herring acked it.

Rich

Re: [PATCH v3 00/12] J-core J2 cpu and SoC peripherals support

[Mark Brown]

[-- Attachment #1: Type: text/plain, Size: 6430 bytes --]

On Wed, May 25, 2016 at 06:24:41PM -0400, Rich Felker wrote:
> On Wed, May 25, 2016 at 10:54:44AM +0100, Mark Brown wrote:
> > On Wed, May 25, 2016 at 05:43:02AM +0000, Rich Felker wrote:

> > > As arch/sh co-maintainer my intent is to include as much as possible
> > > in my pull request for the linux-sh tree. If there are parts outside
> > > of arch/sh that can be included in this, please let me know. I'm not

> > Do *not* include the SPI driver, you shouldn't be including any drivers
> > unless it's been explicitly discussed with the subsystem maintainers.

> See the "please let me know". I thought this was plenty clear that I
> was asking for permission for including things outside of arch/sh, and
> that short of getting an ack, the default permission is no. You also
> snipped the part of my message that mentioned the specific subsystems
> I was asking about (which were non-SPI because you already made quite
> a point about not taking the SPI driver):

Given that you started off with "my intent is to include as much as
possible" and the general apparent lack of clarity about the process
it's really not sufficiently obvious to me based on your message that
this is clear to you.  The presentation of your message especially in
the context of the prior discussion suggests that it is expected for
things to go in at this point which haven't even been in -next yet and
that this is all perfectly normal, it is really not clear enough to me
reading it that you are looking for acks but instead sounds like you
might possibly intend to try to send anything that doesn't get
explicitly nacked.

It would really have helped to have some explicit mention of the fact
that you understand that what you are asking for is unusual and some
discussion of why you think it should still go in.  The best and
clearest thing to do would have been to post the series you were
considering sending as one series and everything else separately.  This
is one of the reasons why it was recommended to you that you should
split things up, it helps make things clear - the normal thing would be
that a series like this would be what you were planning to send.
Failing that another thing that'd have helped would be an explicit
mention of the bits you knew weren't going to be included in any pull
request.

> > end of the merge window and a new version is being posted.  The
> > turnaround times you are demanding on review are unreasonable - people
> > get busy, have holidays and so on - and you really need to pay attention
> > to what people are telling you about the process or you're just going to
> > annoy people.

> If you can't review and ack the code on short notice, that's fine;
> just say so. There's no need to be overerly hostile about it. I've

Since you were still talking about sending pull requests for this code
during this mergen window after the previous thread I want to be as sure
as I can be that you do understand the process and remove any hint of
ambiguity.

Note that you should not expect that people are going to send you an
explicit message about when they intend to review things and usually a
week is considered the lowest bound for chasing on things that aren't
urgent.

> gotten arch/sh patches during the merge window before and I try to be
> polite with the contributor and ask if there's something seriously
> broken that would be improved by my making an effort to check it at
> the last minute, or it if can happily wait until next time.

You're not a new contributor posting some patches here, you are talking
about sending pull requests as the architecture maintainer.  That's
rather different.  

If you were just sending patches that would be fine and not at all
disruptive, that is a perfectly normal part of the workflow, but that's
not what's happening here.  I'm actually one of the people who's more
gung ho about applying things - I do tend to apply patches right up to
the wire and will carry on reviewing and applying new code through the
merge window (I looked at your first version after all) but only fixes
will get queued up for Linus, anything else that sits on topic branches
until after the merge window.

> Being that the driver in question here is for a new platform that was
> not previously supported upstream and has zero chance of breaking
> anything else, and that its inclusion would be a big plus for users of

Even if people aren't going to run the code it's buildable on other
architectures (as it should be so we can compile test things, do static
analysis and so on) and breaking the build or even introducing new
warnings during the merge window isn't helpful.  People build and test
things like all*config as a matter of routine and if those get broken
then that takes people's time can mask other issues.

> the platform, I don't see any reason for you making such a big deal
> out of it unless enforcing policy for its own sake makes you feel
> good, but I have better things to do than argue about it.

Like I say it's the bit where you're talking about sending pull requests
that's really flagging up here.

Most people's changes are important for them and only affect some
specific subset of platforms or systems which often aren't widely used
outside a given company but we still expect their changes to be in -next
before the merge window.  It's a lot easier for everyone to just follow
that rule, we have time based releases and things like -next available
so it is really not the end of the world to wait for one release, doing
this is fairer, minimises the risk of disruption for everyone and it
saves effort with evaluating the different bits of special pleading or
trying to rush to get reviews done quickly.

> > If you want people to review DT bindings you're going to need to submit
> > them.

> I have, twice now, and I Cc'd the the linux-spi list too on v3 for the
> spi binding. Rob Herring acked it.

To repeat what was said last time the code and binding need to be
reviewed together - they will generally be merged together.  This means
that you need to copy subsystem maintainers on bindings for their
subsystem along with the code, as a rule you should send the binding to
at least everyone you send the code to.  Sending things to the lists
alone is not enough to ensure they will be seen with the code using
them.

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 473 bytes --]