* [PATCHv4 3/3] tty/serial: at91: fix hardware handshake on SAM9x5 (without GPIOs)
From: Richard Genoud @ 2016-09-30 8:58 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20160930085801.21497-1-richard.genoud@gmail.com>
Commit 1cf6e8fc8341 ("tty/serial: at91: fix RTS line management when
hardware handshake is enabled") broke the hardware handshake on SAM9x5
platforms.
On Atmel platforms, the USART can only handle the handware handshake
(ATMEL_US_USMODE_HWHS) if FIFOs or PDC are used.
Thus, ATMEL_US_USMODE_HWHS mode should only be used in this case.
For SAM9x5, there's no FIFOs nor PDC for the USART, so the mode should
be ATMEL_US_USMODE_NORMAL and the RTS pin should be controlled by the
driver.
NB: -stable is not Cced because it doesn't cleanly apply on 4.1+
Tested on SAM9G35-CM with and without DMA
Signed-off-by: Richard Genoud <richard.genoud@gmail.com>
Fixes: 1cf6e8fc8341 ("tty/serial: at91: fix RTS line management when hardware handshake is enabled")
---
drivers/tty/serial/atmel_serial.c | 24 ++++++++++++++----------
1 file changed, 14 insertions(+), 10 deletions(-)
diff --git a/drivers/tty/serial/atmel_serial.c b/drivers/tty/serial/atmel_serial.c
index b01b68ece35c..4d033e6af44a 100644
--- a/drivers/tty/serial/atmel_serial.c
+++ b/drivers/tty/serial/atmel_serial.c
@@ -2131,19 +2131,23 @@ static void atmel_set_termios(struct uart_port *port, struct ktermios *termios,
port->rs485.delay_rts_after_send);
mode |= ATMEL_US_USMODE_RS485;
} else if ((termios->c_cflag & CRTSCTS) &&
- !mctrl_gpio_use_rtscts(atmel_port->gpios)) {
+ !mctrl_gpio_use_rtscts(atmel_port->gpios) &&
+ (atmel_use_pdc_rx(port) || atmel_use_fifo(port))) {
/*
- * RS232 with hardware handshake (RTS/CTS)
- * handled by the controller.
+ * Automatic hardware handshake (RTS/CTS) only work with
+ * FIFOs or PDC.
+ * Meaning that on SAM9x5 the controller can't handle
+ * the hardware handshake (no FIFOs nor PDC on these platforms).
*/
- if (atmel_use_dma_rx(port) && !atmel_use_fifo(port)) {
- dev_info(port->dev, "not enabling hardware flow control because DMA is used");
- termios->c_cflag &= ~CRTSCTS;
- } else {
- mode |= ATMEL_US_USMODE_HWHS;
- }
+ mode |= ATMEL_US_USMODE_HWHS;
} else {
- /* RS232 without hardware handshake or controlled by GPIOs */
+ /*
+ * Other cases are:
+ * - RS232 without hardware handshake
+ * - RS232 with hardware handshake and:
+ * - controller unable to handle CTS/RTS by itself
+ * - or CTS/RTS handled by GPIOs
+ */
mode |= ATMEL_US_USMODE_NORMAL;
}
^ permalink raw reply related
* [PATCH v14 4/4] CMDQ: save more energy in idle
From: Matthias Brugger @ 2016-09-30 9:01 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1475225766.25044.33.camel@mtksdaap41>
On 09/30/2016 10:56 AM, Horng-Shyang Liao wrote:
> On Fri, 2016-09-23 at 17:28 +0800, Horng-Shyang Liao wrote:
>> On Thu, 2016-09-22 at 13:22 +0530, Jassi Brar wrote:
>>> On Mon, Sep 5, 2016 at 7:14 AM, HS Liao <hs.liao@mediatek.com> wrote:
>>>> Use clk_disable_unprepare instead of clk_disable to save more energy
>>>> when CMDQ is idle.
>>>>
>>>> Signed-off-by: HS Liao <hs.liao@mediatek.com>
>>>> ---
>>>> drivers/mailbox/mtk-cmdq.c | 54 +++++++++++++++++++++++++++++++++++++++-------
>>>
>>> The driver is introduced by second patch of the set, so it makes sense
>>> to merge this patch into patch 2/4.
>>
>> Hi Jassi,
>>
>> Could you take a look at previous discussion between Matthias and me?
>> http://lkml.iu.edu/hypermail/linux/kernel/1606.2/05239.html
>> His basic idea is to simplify first working version.
>> Therefore, I move some code to this patch.
>>
Well what I wanted to say is, that right now this driver is quite a big
beast and this makes it difficult to review. So my idea was to just
submit the most basic version of this driver.
Any improvements on the driver should be sent in follow-up patches after
the basic driver got merged. That was my idea.
Regards,
Matthias
^ permalink raw reply
* [PATCH v5 01/14] drivers: iommu: add FWNODE_IOMMU fwnode type
From: Lorenzo Pieralisi @ 2016-09-30 9:07 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <3178073.UTpgCTN6if@vostro.rjw.lan>
On Thu, Sep 29, 2016 at 10:59:40PM +0200, Rafael J. Wysocki wrote:
> On Thursday, September 29, 2016 03:15:20 PM Lorenzo Pieralisi wrote:
> > Hi Rafael,
> >
> > On Fri, Sep 09, 2016 at 03:23:30PM +0100, Lorenzo Pieralisi wrote:
> > > On systems booting with a device tree, every struct device is
> > > associated with a struct device_node, that represents its DT
> > > representation. The device node can be used in generic kernel
> > > contexts (eg IRQ translation, IOMMU streamid mapping), to
> > > retrieve the properties associated with the device and carry
> > > out kernel operation accordingly. Owing to the 1:1 relationship
> > > between the device and its device_node, the device_node can also
> > > be used as a look-up token for the device (eg looking up a device
> > > through its device_node), to retrieve the device in kernel paths
> > > where the device_node is available.
> > >
> > > On systems booting with ACPI, the same abstraction provided by
> > > the device_node is required to provide look-up functionality.
> > >
> > > Therefore, mirroring the approach implemented in the IRQ domain
> > > kernel layer, this patch adds an additional fwnode type FWNODE_IOMMU.
> > >
> > > This patch also implements a glue kernel layer that allows to
> > > allocate/free FWNODE_IOMMU fwnode_handle structures and associate
> > > them with IOMMU devices.
> > >
> > > Signed-off-by: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>
> > > Reviewed-by: Hanjun Guo <hanjun.guo@linaro.org>
> > > Cc: Joerg Roedel <joro@8bytes.org>
> > > Cc: "Rafael J. Wysocki" <rjw@rjwysocki.net>
> > > ---
> > > include/linux/fwnode.h | 1 +
> > > include/linux/iommu.h | 25 +++++++++++++++++++++++++
> > > 2 files changed, 26 insertions(+)
> > >
> > > diff --git a/include/linux/fwnode.h b/include/linux/fwnode.h
> > > index 8516717..6e10050 100644
> > > --- a/include/linux/fwnode.h
> > > +++ b/include/linux/fwnode.h
> > > @@ -19,6 +19,7 @@ enum fwnode_type {
> > > FWNODE_ACPI_DATA,
> > > FWNODE_PDATA,
> > > FWNODE_IRQCHIP,
> > > + FWNODE_IOMMU,
> >
> > This patch provides groundwork for this series and it is key for
> > the rest of it, basically the point here is that we need a fwnode
> > to differentiate platform devices created out of static ACPI tables
> > entries (ie IORT), that represent IOMMU components.
> >
> > The corresponding device is not an ACPI device (I could fabricate one as
> > it is done for other static tables entries eg FADT power button, but I
> > do not necessarily see the reason for doing that given that all we need
> > the fwnode for is a token identifier), so FWNODE_ACPI does not apply
> > here.
> >
> > Please let me know if it is reasonable how I sorted this out (it
> > is basically identical to IRQCHIP, just another enum entry), the
> > remainder of the code depends on this.
>
> I'm not familiar with the use case, so I don't see anything unreasonable
> in it.
The use case is pretty simple: on ARM SMMU devices are platform devices.
When booting with DT they are identified through an of_node and related
FWNODE_OF type. When booting with ACPI, the ARM SMMU platform devices,
to be equivalent to DT booting path, should be created out of static
IORT table entries (that's how we describe SMMUs); we need to create
a fwnode "token" to associate with those platform devices and that's
not a FWNODE_ACPI (that is for an ACPI device firmware object, here we
really do not need one), so this patch.
> If you're asking about whether or not I mind adding more fwnode types in
> principle, then no, I don't. :-)
Yes, that's what I was asking, the only point that bugs me is that for
both FWNODE_IRQCHIP and FWNODE_IOMMU the fwnode is just a "token" (ie a
valid pointer) used for look-up and the type in the fwnode_handle is
mostly there for error checking, I was wondering if we could create a
specific fwnode_type for this specific usage (eg FWNODE_TAG and then add
a type to it as part of its container struct) instead of adding an enum
value per subsystem - it seems there are other fwnode types in the
pipeline :), so I am asking:
lkml.kernel.org/r/3D1468514043-21081-3-git-send-email-minyard at acm.org
If it is ok for you and Joerg I will go ahead with current patch
keeping in mind that the above should not be that complicated to
implement if we deem it reasonable.
Thanks,
Lorenzo
^ permalink raw reply
* [PATCH v14 2/4] CMDQ: Mediatek CMDQ driver
From: CK Hu @ 2016-09-30 9:11 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1475225778.25044.35.camel@mtksdaap41>
Hi, HS:
One comment inline
On Fri, 2016-09-30 at 16:56 +0800, Horng-Shyang Liao wrote:
> Hi CK,
>
> Please see my inline reply.
>
> On Fri, 2016-09-30 at 11:06 +0800, CK Hu wrote:
> > Hi, HS:
> >
> > On Mon, 2016-09-05 at 09:44 +0800, HS Liao wrote:
> > > This patch is first version of Mediatek Command Queue(CMDQ) driver. The
> > > CMDQ is used to help write registers with critical time limitation,
> > > such as updating display configuration during the vblank. It controls
> > > Global Command Engine (GCE) hardware to achieve this requirement.
> > > Currently, CMDQ only supports display related hardwares, but we expect
> > > it can be extended to other hardwares for future requirements.
> > >
> > > Signed-off-by: HS Liao <hs.liao@mediatek.com>
> > > Signed-off-by: CK Hu <ck.hu@mediatek.com>
> > > ---
> >
> > [snip...]
> >
> > > +
> > > +struct cmdq_task {
> > > + struct cmdq *cmdq;
> > > + struct list_head list_entry;
> > > + void *va_base;
> > > + dma_addr_t pa_base;
> > > + size_t cmd_buf_size; /* command occupied size */
> > > + size_t buf_size; /* real buffer size */
> > > + bool finalized;
> > > + struct cmdq_thread *thread;
> >
> > I think thread info could be removed from cmdq_task. Only
> > cmdq_task_handle_error() and cmdq_task_insert_into_thread() use
> > task->thread and caller of both function has the thread info. So you
> > could just pass thread info into these two function and remove thread
> > info in cmdq_task.
>
> This modification will remove 1 pointer but add 2 pointers. Moreover,
> more pointers will need to be delivered between functions for future
> extension. IMHO, it would be better to keep thread pointer inside
> cmdq_task.
>
> > > + struct cmdq_task_cb cb;
> >
> > I think this callback function is equal to mailbox client tx_done
> > callback. It's better to use already-defined interface rather than
> > creating your own.
>
> This is because CMDQ driver allows different callback functions for
> different tasks, but mailbox only allows one callback function per
> channel. But, I think I can add a wrapper for tx_done to call CMDQ
> callback functions. So, I will use tx_done in CMDQ v15.
Up to now, one callback function for one channel is enough for DRM. So
'different callback function for different sent-message' looks like an
advanced function. Maybe you should not include it in first patch.
Regards,
CK
>
> > > +};
> > > +
> >
> > [snip...]
> >
> > > +
> > > +static int cmdq_suspend(struct device *dev)
> > > +{
> > > + struct cmdq *cmdq = dev_get_drvdata(dev);
> > > + struct cmdq_thread *thread;
> > > + int i;
> > > + bool task_running = false;
> > > +
> > > + mutex_lock(&cmdq->task_mutex);
> > > + cmdq->suspended = true;
> > > + mutex_unlock(&cmdq->task_mutex);
> > > +
> > > + for (i = 0; i < ARRAY_SIZE(cmdq->thread); i++) {
> > > + thread = &cmdq->thread[i];
> > > + if (!list_empty(&thread->task_busy_list)) {
> > > + mod_timer(&thread->timeout, jiffies + 1);
> > > + task_running = true;
> > > + }
> > > + }
> > > +
> > > + if (task_running) {
> > > + dev_warn(dev, "exist running task(s) in suspend\n");
> > > + msleep(20);
> >
> > Why sleep here? It looks like a recovery but could 20ms recovery
> > something? I think warning message is enough because you see the warning
> > message, and you fix the bug, so no need to recovery anything.
>
> My purpose is context switch to finish timer's work.
> I will replace it by schedule().
>
> > > + }
> > > +
> > > + clk_unprepare(cmdq->clock);
> > > + return 0;
> > > +}
> > > +
> >
> > Regards,
> > CK
>
> Thanks,
> HS
>
>
^ permalink raw reply
* [PATCH v6 1/3] arm/dts-ls1021: add pcie aer/pme interrupt-name property in the dts
From: Po Liu @ 2016-09-30 9:11 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1473741659-17618-3-git-send-email-po.liu@nxp.com>
NXP arm aer/pme interrupts was not MSI/MSI-X/INTx but using interrupt
line independently. This patch add a "aer" "pme" interrupt-names for
aer/pme interrupts.
With the interrupt-names "aer","pme" code could probe aer/pme interrupt
line for pcie root port, replace the aer/pme interrupt service irqs.
This patch is intend to fixup the Layerscape platforms which aer/pme
interrupt was not MSI/MSI-X/INTx, but using interrupt line independently.
Since the interrupt-names "intr" never been used. Remove it.
Signed-off-by: Po Liu <po.liu@nxp.com>
---
changes for v6:
- add remove "intr" reason;
- add "pme" interrupt;
arch/arm/boot/dts/ls1021a.dtsi | 8 ++++++--
1 file changed, 6 insertions(+), 2 deletions(-)
diff --git a/arch/arm/boot/dts/ls1021a.dtsi b/arch/arm/boot/dts/ls1021a.dtsi
index 368e219..9b3cb3b 100644
--- a/arch/arm/boot/dts/ls1021a.dtsi
+++ b/arch/arm/boot/dts/ls1021a.dtsi
@@ -634,7 +634,9 @@
reg = <0x00 0x03400000 0x0 0x00010000 /* controller registers */
0x40 0x00000000 0x0 0x00002000>; /* configuration space */
reg-names = "regs", "config";
- interrupts = <GIC_SPI 177 IRQ_TYPE_LEVEL_HIGH>; /* controller interrupt */
+ interrupts = <GIC_SPI 181 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 183 IRQ_TYPE_LEVEL_HIGH>; /* aer interrupt */
+ interrupt-names = "pme", "aer";
fsl,pcie-scfg = <&scfg 0>;
#address-cells = <3>;
#size-cells = <2>;
@@ -657,7 +659,9 @@
reg = <0x00 0x03500000 0x0 0x00010000 /* controller registers */
0x48 0x00000000 0x0 0x00002000>; /* configuration space */
reg-names = "regs", "config";
- interrupts = <GIC_SPI 178 IRQ_TYPE_LEVEL_HIGH>;
+ interrupts = <GIC_SPI 182 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 184 IRQ_TYPE_LEVEL_HIGH>; /* aer interrupt */
+ interrupt-names = "pme", "aer";
fsl,pcie-scfg = <&scfg 1>;
#address-cells = <3>;
#size-cells = <2>;
--
2.1.0.27.g96db324
^ permalink raw reply related
* [PATCH v6 2/3] arm64/dts-ls1043-ls2080: add pcie aer/pme interrupt-name property in the dts
From: Po Liu @ 2016-09-30 9:11 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1475226697-7709-1-git-send-email-po.liu@nxp.com>
Some platforms(NXP Layerscape for example) aer/pme interrupts was not
MSI/MSI-X/INTx but using interrupt line independently. This patch
add "aer", "pme" interrupt-names for aer/pme interrupt.
With the interrupt-names "aer", "pme" code could probe aer/pme interrupt
line for pcie root port, replace the aer/pme interrupt service irqs.
This is intend to fixup the Layerscape platforms which aer/pmes interrupts
was not MSI/MSI-X/INTx, but using interrupt line independently.
Since the interrupt-names "intr" never been used. Remove it.
Signed-off-by: Po Liu <po.liu@nxp.com>
---
changes for v6:
- add remove "intr" interrupt reason.
- add "pme" interrupt.
arch/arm64/boot/dts/freescale/fsl-ls1043a.dtsi | 18 +++++++++---------
arch/arm64/boot/dts/freescale/fsl-ls2080a.dtsi | 16 ++++++++--------
2 files changed, 17 insertions(+), 17 deletions(-)
diff --git a/arch/arm64/boot/dts/freescale/fsl-ls1043a.dtsi b/arch/arm64/boot/dts/freescale/fsl-ls1043a.dtsi
index e669fbd..654071d 100644
--- a/arch/arm64/boot/dts/freescale/fsl-ls1043a.dtsi
+++ b/arch/arm64/boot/dts/freescale/fsl-ls1043a.dtsi
@@ -527,9 +527,9 @@
reg = <0x00 0x03400000 0x0 0x00100000 /* controller registers */
0x40 0x00000000 0x0 0x00002000>; /* configuration space */
reg-names = "regs", "config";
- interrupts = <0 118 0x4>, /* controller interrupt */
- <0 117 0x4>; /* PME interrupt */
- interrupt-names = "intr", "pme";
+ interrupts = <0 117 0x4>, /* PME interrupt */
+ <0 118 0x4>; /* aer interrupt */
+ interrupt-names = "pme", "aer";
#address-cells = <3>;
#size-cells = <2>;
device_type = "pci";
@@ -552,9 +552,9 @@
reg = <0x00 0x03500000 0x0 0x00100000 /* controller registers */
0x48 0x00000000 0x0 0x00002000>; /* configuration space */
reg-names = "regs", "config";
- interrupts = <0 128 0x4>,
- <0 127 0x4>;
- interrupt-names = "intr", "pme";
+ interrupts = <0 127 0x4>,
+ <0 128 0x4>;
+ interrupt-names = "pme", "aer";
#address-cells = <3>;
#size-cells = <2>;
device_type = "pci";
@@ -577,9 +577,9 @@
reg = <0x00 0x03600000 0x0 0x00100000 /* controller registers */
0x50 0x00000000 0x0 0x00002000>; /* configuration space */
reg-names = "regs", "config";
- interrupts = <0 162 0x4>,
- <0 161 0x4>;
- interrupt-names = "intr", "pme";
+ interrupts = <0 161 0x4>,
+ <0 162 0x4>;
+ interrupt-names = "pme", "aer";
#address-cells = <3>;
#size-cells = <2>;
device_type = "pci";
diff --git a/arch/arm64/boot/dts/freescale/fsl-ls2080a.dtsi b/arch/arm64/boot/dts/freescale/fsl-ls2080a.dtsi
index 21023a3..58844e8 100644
--- a/arch/arm64/boot/dts/freescale/fsl-ls2080a.dtsi
+++ b/arch/arm64/boot/dts/freescale/fsl-ls2080a.dtsi
@@ -583,8 +583,8 @@
reg = <0x00 0x03400000 0x0 0x00100000 /* controller registers */
0x10 0x00000000 0x0 0x00002000>; /* configuration space */
reg-names = "regs", "config";
- interrupts = <0 108 0x4>; /* Level high type */
- interrupt-names = "intr";
+ interrupts = <0 108 0x4>; /* aer interrupt */
+ interrupt-names = "aer";
#address-cells = <3>;
#size-cells = <2>;
device_type = "pci";
@@ -607,8 +607,8 @@
reg = <0x00 0x03500000 0x0 0x00100000 /* controller registers */
0x12 0x00000000 0x0 0x00002000>; /* configuration space */
reg-names = "regs", "config";
- interrupts = <0 113 0x4>; /* Level high type */
- interrupt-names = "intr";
+ interrupts = <0 113 0x4>; /* aer interrupt */
+ interrupt-names = "aer";
#address-cells = <3>;
#size-cells = <2>;
device_type = "pci";
@@ -631,8 +631,8 @@
reg = <0x00 0x03600000 0x0 0x00100000 /* controller registers */
0x14 0x00000000 0x0 0x00002000>; /* configuration space */
reg-names = "regs", "config";
- interrupts = <0 118 0x4>; /* Level high type */
- interrupt-names = "intr";
+ interrupts = <0 118 0x4>; /* aer interrupt */
+ interrupt-names = "aer";
#address-cells = <3>;
#size-cells = <2>;
device_type = "pci";
@@ -655,8 +655,8 @@
reg = <0x00 0x03700000 0x0 0x00100000 /* controller registers */
0x16 0x00000000 0x0 0x00002000>; /* configuration space */
reg-names = "regs", "config";
- interrupts = <0 123 0x4>; /* Level high type */
- interrupt-names = "intr";
+ interrupts = <0 123 0x4>; /* aer interrupt */
+ interrupt-names = "aer";
#address-cells = <3>;
#size-cells = <2>;
device_type = "pci";
--
2.1.0.27.g96db324
^ permalink raw reply related
* [PATCH v6 3/3] pci:add support aer/pme interrupts with none MSI/MSI-X/INTx mode
From: Po Liu @ 2016-09-30 9:11 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1475226697-7709-1-git-send-email-po.liu@nxp.com>
On some platforms, root port doesn't support MSI/MSI-X/INTx in RC mode.
When chip support the aer/pme interrupts with none MSI/MSI-X/INTx mode,
maybe there is interrupt line for aer pme etc. Search the interrupt
number in the fdt file. Then fixup the dev->irq with it.
Signed-off-by: Po Liu <po.liu@nxp.com>
---
changes for v6:
- modify bindings for "aer""pme";
- changing to the hood method to implement the aer pme interrupt;
- add pme interrupt in the same way;
.../devicetree/bindings/pci/layerscape-pci.txt | 13 +++++--
arch/arm/kernel/bios32.c | 43 ++++++++++++++++++++++
arch/arm64/kernel/pci.c | 43 ++++++++++++++++++++++
drivers/pci/pcie/portdrv_core.c | 31 +++++++++++++++-
include/linux/pci.h | 1 +
5 files changed, 126 insertions(+), 5 deletions(-)
diff --git a/Documentation/devicetree/bindings/pci/layerscape-pci.txt b/Documentation/devicetree/bindings/pci/layerscape-pci.txt
index 41e9f55..51ed49e 100644
--- a/Documentation/devicetree/bindings/pci/layerscape-pci.txt
+++ b/Documentation/devicetree/bindings/pci/layerscape-pci.txt
@@ -18,8 +18,12 @@ Required properties:
- reg: base addresses and lengths of the PCIe controller
- interrupts: A list of interrupt outputs of the controller. Must contain an
entry for each entry in the interrupt-names property.
-- interrupt-names: Must include the following entries:
- "intr": The interrupt that is asserted for controller interrupts
+- interrupt-names: It could include the following entries:
+ "aer": Asserted for aer interrupt when chip support the aer interrupt with
+ none MSI/MSI-X/INTx mode,but there is interrupt line for aer.
+ "pme": Asserted for pme interrupt when chip support the pme interrupt with
+ none MSI/MSI-X/INTx mode,but there is interrupt line for pme.
+ ......
- fsl,pcie-scfg: Must include two entries.
The first entry must be a link to the SCFG device node
The second entry must be '0' or '1' based on physical PCIe controller index.
@@ -35,8 +39,9 @@ Example:
reg = <0x00 0x03400000 0x0 0x00010000 /* controller registers */
0x40 0x00000000 0x0 0x00002000>; /* configuration space */
reg-names = "regs", "config";
- interrupts = <GIC_SPI 177 IRQ_TYPE_LEVEL_HIGH>; /* controller interrupt */
- interrupt-names = "intr";
+ interrupts = <GIC_SPI 176 IRQ_TYPE_LEVEL_HIGH>, /* aer interrupt */
+ <GIC_SPI 177 IRQ_TYPE_LEVEL_HIGH>; /* pme interrupt */
+ interrupt-names = "aer", "pme";
fsl,pcie-scfg = <&scfg 0>;
#address-cells = <3>;
#size-cells = <2>;
diff --git a/arch/arm/kernel/bios32.c b/arch/arm/kernel/bios32.c
index 2f0e077..d2f4869 100644
--- a/arch/arm/kernel/bios32.c
+++ b/arch/arm/kernel/bios32.c
@@ -11,6 +11,8 @@
#include <linux/slab.h>
#include <linux/init.h>
#include <linux/io.h>
+#include <linux/of_irq.h>
+#include <linux/pcieport_if.h>
#include <asm/mach-types.h>
#include <asm/mach/map.h>
@@ -64,6 +66,47 @@ void pcibios_report_status(u_int status_mask, int warn)
}
/*
+ * Check device tree if the service interrupts are there
+ */
+int pcibios_check_service_irqs(struct pci_dev *dev, int *irqs, int mask)
+{
+ int ret, count = 0;
+ struct device_node *np = NULL;
+
+ if (dev->bus->dev.of_node)
+ np = dev->bus->dev.of_node;
+
+ if (np == NULL)
+ return 0;
+
+ if (!IS_ENABLED(CONFIG_OF_IRQ))
+ return 0;
+
+ /* If root port doesn't support MSI/MSI-X/INTx in RC mode,
+ * request irq for aer
+ */
+ if (mask & PCIE_PORT_SERVICE_AER) {
+ ret = of_irq_get_byname(np, "aer");
+ if (ret > 0) {
+ irqs[PCIE_PORT_SERVICE_AER_SHIFT] = ret;
+ count++;
+ }
+ }
+
+ if (mask & PCIE_PORT_SERVICE_PME) {
+ ret = of_irq_get_byname(np, "pme");
+ if (ret > 0) {
+ irqs[PCIE_PORT_SERVICE_PME_SHIFT] = ret;
+ count++;
+ }
+ }
+
+ /* TODO: add more service interrupts if there it is in the device tree*/
+
+ return count;
+}
+
+/*
* We don't use this to fix the device, but initialisation of it.
* It's not the correct use for this, but it works.
* Note that the arbiter/ISA bridge appears to be buggy, specifically in
diff --git a/arch/arm64/kernel/pci.c b/arch/arm64/kernel/pci.c
index acf3872..4a3c61a 100644
--- a/arch/arm64/kernel/pci.c
+++ b/arch/arm64/kernel/pci.c
@@ -17,6 +17,8 @@
#include <linux/mm.h>
#include <linux/of_pci.h>
#include <linux/of_platform.h>
+#include <linux/of_irq.h>
+#include <linux/pcieport_if.h>
#include <linux/pci.h>
#include <linux/pci-acpi.h>
#include <linux/pci-ecam.h>
@@ -55,6 +57,47 @@ int pcibios_alloc_irq(struct pci_dev *dev)
}
/*
+ * Check device tree if the service interrupts are there
+ */
+int pcibios_check_service_irqs(struct pci_dev *dev, int *irqs, int mask)
+{
+ int ret, count = 0;
+ struct device_node *np = NULL;
+
+ if (dev->bus->dev.of_node)
+ np = dev->bus->dev.of_node;
+
+ if (np == NULL)
+ return 0;
+
+ if (!IS_ENABLED(CONFIG_OF_IRQ))
+ return 0;
+
+ /* If root port doesn't support MSI/MSI-X/INTx in RC mode,
+ * request irq for aer
+ */
+ if (mask & PCIE_PORT_SERVICE_AER) {
+ ret = of_irq_get_byname(np, "aer");
+ if (ret > 0) {
+ irqs[PCIE_PORT_SERVICE_AER_SHIFT] = ret;
+ count++;
+ }
+ }
+
+ if (mask & PCIE_PORT_SERVICE_PME) {
+ ret = of_irq_get_byname(np, "pme");
+ if (ret > 0) {
+ irqs[PCIE_PORT_SERVICE_PME_SHIFT] = ret;
+ count++;
+ }
+ }
+
+ /* TODO: add more service interrupts if there it is in the device tree*/
+
+ return count;
+}
+
+/*
* raw_pci_read/write - Platform-specific PCI config space access.
*/
int raw_pci_read(unsigned int domain, unsigned int bus,
diff --git a/drivers/pci/pcie/portdrv_core.c b/drivers/pci/pcie/portdrv_core.c
index e9270b4..34b6dae 100644
--- a/drivers/pci/pcie/portdrv_core.c
+++ b/drivers/pci/pcie/portdrv_core.c
@@ -44,6 +44,19 @@ static void release_pcie_device(struct device *dev)
}
/**
+ * pcibios_check_service_irqs - check irqs in the device tree
+ * @dev: PCI Express port to handle
+ * @irqs: Array of irqs to populate
+ * @mask: Bitmask of port capabilities returned by get_port_device_capability()
+ *
+ * Return value: 0 means no service irqs in the device tree
+ *
+ */
+int __weak pcibios_check_service_irqs(struct pci_dev *dev, int *irqs, int mask)
+{
+ return 0;
+}
+/**
* pcie_port_msix_add_entry - add entry to given array of MSI-X entries
* @entries: Array of MSI-X entries
* @new_entry: Index of the entry to add to the array
@@ -200,6 +213,21 @@ static int pcie_port_enable_msix(struct pci_dev *dev, int *vectors, int mask)
static int init_service_irqs(struct pci_dev *dev, int *irqs, int mask)
{
int i, irq = -1;
+ int ret;
+
+ /* Check if some platforms owns independent irq pins for AER/PME etc.
+ * Some platforms may own independent AER/PME interrupts and set
+ * them in the device tree file.
+ */
+ for (i = 0; i < PCIE_PORT_DEVICE_MAXSERVICES; i++)
+ irqs[i] = -1;
+
+ ret = pcibios_check_service_irqs(dev, irqs, mask);
+ if (ret) {
+ if (dev->irq)
+ irq = dev->irq;
+ goto no_msi;
+ }
/*
* If MSI cannot be used for PCIe PME or hotplug, we have to use
@@ -226,7 +254,8 @@ static int init_service_irqs(struct pci_dev *dev, int *irqs, int mask)
no_msi:
for (i = 0; i < PCIE_PORT_DEVICE_MAXSERVICES; i++)
- irqs[i] = irq;
+ if (irqs[i] == -1)
+ irqs[i] = irq;
irqs[PCIE_PORT_SERVICE_VC_SHIFT] = -1;
if (irq < 0)
diff --git a/include/linux/pci.h b/include/linux/pci.h
index 2599a98..c80f2d0 100644
--- a/include/linux/pci.h
+++ b/include/linux/pci.h
@@ -1793,6 +1793,7 @@ void pcibios_release_device(struct pci_dev *dev);
void pcibios_penalize_isa_irq(int irq, int active);
int pcibios_alloc_irq(struct pci_dev *dev);
void pcibios_free_irq(struct pci_dev *dev);
+int pcibios_check_service_irqs(struct pci_dev *dev, int *irqs, int mask);
#ifdef CONFIG_HIBERNATE_CALLBACKS
extern struct dev_pm_ops pcibios_pm_ops;
--
2.1.0.27.g96db324
^ permalink raw reply related
* [PATCHv4 2/3] tty/serial: at91: fix hardware handshake with GPIOs
From: Uwe Kleine-König @ 2016-09-30 9:12 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20160930085801.21497-3-richard.genoud@gmail.com>
Hello Richard,
On Fri, Sep 30, 2016 at 10:58:00AM +0200, Richard Genoud wrote:
> Commit 1cf6e8fc8341 ("tty/serial: at91: fix RTS line management when
> hardware handshake is enabled") broke the hardware handshake when GPIOs
> were used.
>
> Hardware handshake with GPIOs used to work before this commit because
> the CRTSCTS flag (termios->c_cflag) was set, but not the
> ATMEL_US_USMODE_HWHS flag (controller register) ; so hardware handshake
> enabled, but not handled by the controller.
What does the HWHS flag control? What if only RTS is a gpio and CTS is
not? Or the other way round?
What is the problematic setup? I guess it's RTS and CTS are gpios and
with that setting ATMEL_US_USMODE_HWHS is wrong? What happens if that
happens?
Best regards
Uwe
--
Pengutronix e.K. | Uwe Kleine-K?nig |
Industrial Linux Solutions | http://www.pengutronix.de/ |
^ permalink raw reply
* [PATCH v2] arm64: make rpm failed due to incorrect path to Image.gz
From: Will Deacon @ 2016-09-30 9:14 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20160930070325.GA3834@localhost.localdomain>
On Fri, Sep 30, 2016 at 12:03:26AM -0700, Vadim Lomovtsev wrote:
> [Adding Will Deacon]
> Sorry, should do this at the very beginning. (
>
> On Thu, Sep 29, 2016 at 07:46:07AM -0700, Vadim Lomovtsev wrote:
> > The "make rpm" and "make rpm-pkg" commands for arm64 platform
> > are broken due to rpmbuild couldn't find Image.gz file at
> > default location (which is kernel src root):
> > cp: cannot stat 'Image.gz': No such file or directory
> > error: Bad exit status from /var/tmp/rpm-tmp.ocFBmP (%install)
> >
> > While the correct path to arm64 kernel image file
> > is "arch/arm64/boot/Image.gz".
> >
> > The exact file name (Image.gz) is stored at KBUILD_IMAGE variable
> > and read by rpmbuild with "make image_name" command at
> > install phase after kernel build is complete.
> >
> > Accordingly to Michal's Marek comment the KBUILD_IMAGE
> > variable has to be set to point to actual file.
> >
> > Since the KBUILD_IMAGE variable is used in general cases of
> > build we need to prevent other build types breakage by changing it.
> >
> > The solution is to add to arch/arm64/Makefie extra target "image_name"
> > with dependency "KBUILD_IMAGE:=<proper path to Image.gz file>".
> > Thus it will allow to set proper path to Image.gz file only for
> > the "image_name" build target and this exact value will be picked up
> > while rpm build install phase.
> >
> > Signed-off-by: Vadim Lomovtsev <Vadim.Lomovtsev@caviumnetworks.com>
> > ---
> > arch/arm64/Makefile | 2 ++
> > 1 file changed, 2 insertions(+)
> >
> > diff --git a/arch/arm64/Makefile b/arch/arm64/Makefile
> > index ab51aed..09926d3 100644
> > --- a/arch/arm64/Makefile
> > +++ b/arch/arm64/Makefile
> > @@ -101,6 +101,8 @@ all: $(KBUILD_IMAGE) $(KBUILD_DTBS)
> >
> > boot := arch/arm64/boot
> >
> > +image_name: KBUILD_IMAGE :=$(boot)/$(KBUILD_IMAGE)
> > +
> > Image: vmlinux
> > $(Q)$(MAKE) $(build)=$(boot) $(boot)/$@
It might be worth fixing the other architectures that just set KBUILD_IMAGE
to the filename too. Then you could remove the bodge from
scripts/package/builddeb that tries to support both formats.
Will
^ permalink raw reply
* [PATCH] ARM64: dts: meson-gxbb-odroidc2: Enable USB Nodes
From: Brian Kim @ 2016-09-30 9:17 UTC (permalink / raw)
To: linux-arm-kernel
Enable both gxbb USB controller and add a 5V regulator for the OTG port
VBUS
Signed-off-by: Brian Kim <brian.kim@hardkernel.com>
---
.../arm64/boot/dts/amlogic/meson-gxbb-odroidc2.dts | 29 ++++++++++++++++++++++
1 file changed, 29 insertions(+)
diff --git a/arch/arm64/boot/dts/amlogic/meson-gxbb-odroidc2.dts b/arch/arm64/boot/dts/amlogic/meson-gxbb-odroidc2.dts
index 8d89edc..997c671 100644
--- a/arch/arm64/boot/dts/amlogic/meson-gxbb-odroidc2.dts
+++ b/arch/arm64/boot/dts/amlogic/meson-gxbb-odroidc2.dts
@@ -64,6 +64,18 @@
reg = <0x0 0x0 0x0 0x80000000>;
};
+ usb_pwr: regulator-usb-pwrs {
+ compatible = "regulator-fixed";
+
+ regulator-name = "USB_PWR";
+
+ regulator-min-microvolt = <5000000>;
+ regulator-max-microvolt = <5000000>;
+
+ gpio = <&gpio_ao GPIOAO_5 GPIO_ACTIVE_HIGH>;
+ enable-active-high;
+ };
+
leds {
compatible = "gpio-leds";
blue {
@@ -149,6 +161,23 @@
pinctrl-names = "default";
};
+&usb0_phy {
+ status = "okay";
+ phy-supply = <&usb_pwr>;
+};
+
+&usb1_phy {
+ status = "okay";
+};
+
+&usb0 {
+ status = "okay";
+};
+
+&usb1 {
+ status = "okay";
+};
+
/* SD */
&sd_emmc_b {
status = "okay";
--
2.7.4
^ permalink raw reply related
* [PATCH v4 0/2] arm64/hugetlb: enable gigantic page
From: Yisheng Xie @ 2016-09-30 9:26 UTC (permalink / raw)
To: linux-arm-kernel
changelog
=========
v3->v4:
add changelog in the cover leter to make the change history more clear.
v2->v3:
change the Kconfig file to avoid comile warning when select
ARCH_HAS_GIGANTIC_PAGE with !CONFIG_HUGETLB_PAGE
v1->v2:
introduce the ARCH_HAS_GIGANTIC_PAGE as Michal Hocko <mhocko@suse.com> suggested
Arm64 supports different size of gigantic page which can be seen from:
commit 084bd29810a5 ("ARM64: mm: HugeTLB support.")
commit 66b3923a1a0f ("arm64: hugetlb: add support for PTE contiguous bit")
So I tried to use this function by adding hugepagesz=1G in kernel
parameters, with CONFIG_CMA=y. However, when I
echo xx > \
/sys/kernel/mm/hugepages/hugepages-1048576kB/nr_hugepages
it failed with the following info:
-bash: echo: write error: Invalid argument
This is a v4 patchset which make gigantic page can be
allocated and freed at runtime for arch arm64,
with CONFIG_CMA=y or other related configs is enabled.
You can see the former discussions at:
https://lkml.org/lkml/2016/8/18/310
https://lkml.org/lkml/2016/8/21/410
https://lkml.org/lkml/2016/8/22/319
Yisheng Xie (2):
mm/hugetlb: Introduce ARCH_HAS_GIGANTIC_PAGE
arm64 Kconfig: Select gigantic page
arch/arm64/Kconfig | 1 +
arch/s390/Kconfig | 1 +
arch/x86/Kconfig | 1 +
fs/Kconfig | 3 +++
mm/hugetlb.c | 2 +-
5 files changed, 7 insertions(+), 1 deletion(-)
--
1.7.12.4
^ permalink raw reply
* [PATCH v4 1/2] mm/hugetlb: Introduce ARCH_HAS_GIGANTIC_PAGE
From: Yisheng Xie @ 2016-09-30 9:26 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1475227569-63446-1-git-send-email-xieyisheng1@huawei.com>
Avoid making ifdef get pretty unwieldy if many ARCHs support gigantic page.
No functional change with this patch.
Signed-off-by: Yisheng Xie <xieyisheng1@huawei.com>
Suggested-by: Michal Hocko <mhocko@suse.com>
Acked-by: Michal Hocko <mhocko@suse.com>
Acked-by: Naoya Horiguchi <n-horiguchi@ah.jp.nec.com>
---
arch/s390/Kconfig | 1 +
arch/x86/Kconfig | 1 +
fs/Kconfig | 3 +++
mm/hugetlb.c | 2 +-
4 files changed, 6 insertions(+), 1 deletion(-)
diff --git a/arch/s390/Kconfig b/arch/s390/Kconfig
index c109f07..74a9e45 100644
--- a/arch/s390/Kconfig
+++ b/arch/s390/Kconfig
@@ -71,6 +71,7 @@ config S390
select ARCH_HAS_DEVMEM_IS_ALLOWED
select ARCH_HAS_ELF_RANDOMIZE
select ARCH_HAS_GCOV_PROFILE_ALL
+ select ARCH_HAS_GIGANTIC_PAGE
select ARCH_HAS_KCOV
select ARCH_HAS_SG_CHAIN
select ARCH_HAVE_NMI_SAFE_CMPXCHG
diff --git a/arch/x86/Kconfig b/arch/x86/Kconfig
index 2a1f0ce..aa0b26a 100644
--- a/arch/x86/Kconfig
+++ b/arch/x86/Kconfig
@@ -28,6 +28,7 @@ config X86
select ARCH_HAS_ELF_RANDOMIZE
select ARCH_HAS_FAST_MULTIPLIER
select ARCH_HAS_GCOV_PROFILE_ALL
+ select ARCH_HAS_GIGANTIC_PAGE if X86_64
select ARCH_HAS_KCOV if X86_64
select ARCH_HAS_PMEM_API if X86_64
select ARCH_HAS_MMIO_FLUSH
diff --git a/fs/Kconfig b/fs/Kconfig
index 2bc7ad7..b938205 100644
--- a/fs/Kconfig
+++ b/fs/Kconfig
@@ -199,6 +199,9 @@ config HUGETLBFS
config HUGETLB_PAGE
def_bool HUGETLBFS
+config ARCH_HAS_GIGANTIC_PAGE
+ bool
+
source "fs/configfs/Kconfig"
source "fs/efivarfs/Kconfig"
diff --git a/mm/hugetlb.c b/mm/hugetlb.c
index 87e11d8..8488dcc 100644
--- a/mm/hugetlb.c
+++ b/mm/hugetlb.c
@@ -1022,7 +1022,7 @@ static int hstate_next_node_to_free(struct hstate *h, nodemask_t *nodes_allowed)
((node = hstate_next_node_to_free(hs, mask)) || 1); \
nr_nodes--)
-#if (defined(CONFIG_X86_64) || defined(CONFIG_S390)) && \
+#if defined(CONFIG_ARCH_HAS_GIGANTIC_PAGE) && \
((defined(CONFIG_MEMORY_ISOLATION) && defined(CONFIG_COMPACTION)) || \
defined(CONFIG_CMA))
static void destroy_compound_gigantic_page(struct page *page,
--
1.7.12.4
^ permalink raw reply related
* [PATCH v4 2/2] arm64 Kconfig: Select gigantic page
From: Yisheng Xie @ 2016-09-30 9:26 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1475227569-63446-1-git-send-email-xieyisheng1@huawei.com>
Arm64 supports gigantic page after
commit 084bd29810a5 ("ARM64: mm: HugeTLB support.")
however, it can only be allocated at boottime and can't be freed.
This patch selects ARCH_HAS_GIGANTIC_PAGE to make gigantic pages
can be allocated and freed at runtime for arch arm64.
Acked-by: Michal Hocko <mhocko@suse.com>
Acked-by: Catalin Marinas <catalin.marinas@arm.com>
Signed-off-by: Yisheng Xie <xieyisheng1@huawei.com>
---
arch/arm64/Kconfig | 1 +
1 file changed, 1 insertion(+)
diff --git a/arch/arm64/Kconfig b/arch/arm64/Kconfig
index bc3f00f..92217f6 100644
--- a/arch/arm64/Kconfig
+++ b/arch/arm64/Kconfig
@@ -9,6 +9,7 @@ config ARM64
select ARCH_HAS_ATOMIC64_DEC_IF_POSITIVE
select ARCH_HAS_ELF_RANDOMIZE
select ARCH_HAS_GCOV_PROFILE_ALL
+ select ARCH_HAS_GIGANTIC_PAGE
select ARCH_HAS_KCOV
select ARCH_HAS_SG_CHAIN
select ARCH_HAS_TICK_BROADCAST if GENERIC_CLOCKEVENTS_BROADCAST
--
1.7.12.4
^ permalink raw reply related
* [PATCH 6/6] ARM: da850: adjust memory settings for tilcdc
From: Bartosz Golaszewski @ 2016-09-30 9:31 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20160929190736.vgd3xylzm2nh32l4@gobelin>
2016-09-29 21:07 GMT+02:00 Karl Beldan <karl.beldan@gmail.com>:
> Hi,
>
> On Thu, Sep 29, 2016 at 06:31:55PM +0200, Bartosz Golaszewski wrote:
>> Default memory settings of da850 do not meet the throughput/latency
>> requirements of tilcdc. This results in the image displayed being
>> incorrect and the following warning being displayed by the LCDC
>> drm driver:
>>
>> tilcdc da8xx_lcdc.0: tilcdc_crtc_irq(0x00000020): FIFO underfow
>>
>> Reconfigure the LCDC priority to the highest. This is a workaround
>> for the da850-lcdk board which has the LCD controller enabled in
>> the device tree, but a long-term, system-wide fix is needed for
>> all davinci boards.
>>
>> This patch has been modified for mainline linux. It comes from a
>> downstream TI release for da850[1].
>>
>> Original author: Vishwanathrao Badarkhe, Manish <manishv.b@ti.com>
>>
>> [1] http://arago-project.org/git/projects/linux-davinci.git?p=projects/linux-davinci.git;a=commitdiff;h=b9bd39a34cc02c3ba2fc15539a2f0bc2b68d25da;hp=6f6c795faa6366a4ebc1037a0235edba6018a991
>>
>> Signed-off-by: Bartosz Golaszewski <bgolaszewski@baylibre.com>
>> ---
>
> FWIW, the quirks could be applied conditionnally depending on the lcdc
> node presence in the DT, a bit like:
> https://github.com/kbeldan/linux/commit/cf15572ffef8e8a0d8110b3f6b29bd401d0538be
> https://github.com/kbeldan/linux/commit/07e4fff9958bc1625a96791dce284c163fbe9c43
>
>
> Regards,
> Karl
Hi Karl,
I decided to post the simplest possible way of this to get the lcdc
working upstream. In parallel I'm working on a system-wide way of
applying such quirks not only limited to device tree nodes' presence.
Thanks for the info!
Best regards,
Bartosz Golaszewski
^ permalink raw reply
* [PATCH 2/6] ARM: dts: da850: add a node for the LCD controller
From: Sekhar Nori @ 2016-09-30 9:34 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1475166715-7857-3-git-send-email-bgolaszewski@baylibre.com>
On Thursday 29 September 2016 10:01 PM, Bartosz Golaszewski wrote:
> From: Karl Beldan <kbeldan@baylibre.com>
>
> Add a disabled LCDC node to be reused in device trees including
> da850.dtsi for boards equipped with tilcdc enabled.
>
> Signed-off-by: Karl Beldan <kbeldan@baylibre.com>
> [Bartosz: added the commit description]
> Signed-off-by: Bartosz Golaszewski <bgolaszewski@baylibre.com>
> ---
> arch/arm/boot/dts/da850.dtsi | 8 ++++++++
> 1 file changed, 8 insertions(+)
>
> diff --git a/arch/arm/boot/dts/da850.dtsi b/arch/arm/boot/dts/da850.dtsi
> index f79e1b9..9f39296 100644
> --- a/arch/arm/boot/dts/da850.dtsi
> +++ b/arch/arm/boot/dts/da850.dtsi
> @@ -399,6 +399,14 @@
> <&edma0 0 1>;
> dma-names = "tx", "rx";
> };
> +
> + lcdc: lcdc at 213000 {
node name should be generic per the ePAPR so please use "display".
> + compatible = "ti,am33xx-tilcdc";
Can you please introduce a da850 specific compatible. Something like:
compatible = "ti,da850-tilcdc", "ti,am33xx-tilcdc";
Even if you dont use it in the driver today, please have it in the .dts
I am pretty sure there will be some da850 specific tweak required for
the LCDC at some point. Having a compatible already in place will make
migration easier. You will have to document the compatible though.
This will affect 1/6 too.
Thanks,
Sekhar
^ permalink raw reply
* [RESEND PATCH v3 1/2] ARM: dts: imx6ul: Add DTS for liteSOM module
From: Marcin Niestroj @ 2016-09-30 9:36 UTC (permalink / raw)
To: linux-arm-kernel
This is a SOM (System on Module), so it will be part of another boards.
Hence, this is a "dtsi" file that will be included from another device
tree files.
Hardware specification:
* Freescale i.MX6UL SoC
* up to 512 MB RAM
* eMMC on uSDHC2
Signed-off-by: Marcin Niestroj <m.niestroj@grinn-global.com>
Reviewed-by: Fabio Estevam <fabio.estevam@nxp.com>
---
Changes v2 -> v3:
* Remove cpu0 supplies (arm-supply, soc-supply), as they were already
set in imx6ul.dtsi file (reported by S?bastien Szymanski)
Changes v1 -> v2:
* Use dual license
arch/arm/boot/dts/imx6ul-litesom.dtsi | 82 +++++++++++++++++++++++++++++++++++
1 file changed, 82 insertions(+)
create mode 100644 arch/arm/boot/dts/imx6ul-litesom.dtsi
diff --git a/arch/arm/boot/dts/imx6ul-litesom.dtsi b/arch/arm/boot/dts/imx6ul-litesom.dtsi
new file mode 100644
index 0000000..461292d
--- /dev/null
+++ b/arch/arm/boot/dts/imx6ul-litesom.dtsi
@@ -0,0 +1,82 @@
+/*
+ * Copyright 2016 Grinn
+ *
+ * Author: Marcin Niestroj <m.niestroj@grinn-global.com>
+ *
+ * This file is dual-licensed: you can use it either under the terms
+ * of the GPL or the X11 license, at your option. Note that this dual
+ * licensing only applies to this file, and not this project as a
+ * whole.
+ *
+ * a) This file is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License
+ * version 2 as published by the Free Software Foundation.
+ *
+ * This file is distributed in the hope that it will be useful
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ *
+ * Or, alternatively
+ *
+ * b) Permission is hereby granted, free of charge, to any person
+ * obtaining a copy of this software and associated documentation
+ * files (the "Software"), to deal in the Software without
+ * restriction, including without limitation the rights to use
+ * copy, modify, merge, publish, distribute, sublicense, and/or
+ * sell copies of the Software, and to permit persons to whom the
+ * Software is furnished to do so, subject to the following
+ * conditions:
+ *
+ * The above copyright notice and this permission notice shall be
+ * included in all copies or substantial portions of the Software.
+ *
+ * THE SOFTWARE IS PROVIDED , WITHOUT WARRANTY OF ANY KIND
+ * EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES
+ * OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND
+ * NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT
+ * HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY
+ * WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
+ * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR
+ * OTHER DEALINGS IN THE SOFTWARE.
+ */
+
+#include "imx6ul.dtsi"
+
+/ {
+ model = "Grinn i.MX6UL liteSOM";
+ compatible = "grinn,imx6ul-litesom", "fsl,imx6ul";
+
+ memory {
+ reg = <0x80000000 0x20000000>;
+ };
+};
+
+&iomuxc {
+ pinctrl_usdhc2: usdhc2grp {
+ fsl,pins = <
+ MX6UL_PAD_NAND_RE_B__USDHC2_CLK 0x10069
+ MX6UL_PAD_NAND_WE_B__USDHC2_CMD 0x17059
+ MX6UL_PAD_NAND_DATA00__USDHC2_DATA0 0x17059
+ MX6UL_PAD_NAND_DATA01__USDHC2_DATA1 0x17059
+ MX6UL_PAD_NAND_DATA02__USDHC2_DATA2 0x17059
+ MX6UL_PAD_NAND_DATA03__USDHC2_DATA3 0x17059
+ MX6UL_PAD_NAND_DATA04__USDHC2_DATA4 0x17059
+ MX6UL_PAD_NAND_DATA05__USDHC2_DATA5 0x17059
+ MX6UL_PAD_NAND_DATA06__USDHC2_DATA6 0x17059
+ MX6UL_PAD_NAND_DATA07__USDHC2_DATA7 0x17059
+ MX6UL_PAD_NAND_ALE__USDHC2_RESET_B 0x17059
+ >;
+ };
+};
+
+&usdhc2 {
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_usdhc2>;
+ no-1-8-v;
+ non-removable;
+ keep-power-in-suspend;
+ wakeup-source;
+ bus-width = <8>;
+ status = "okay";
+};
--
2.10.0
^ permalink raw reply related
* [RESEND PATCH v3 2/2] ARM: dts: imx6ul: Add DTS for liteBoard
From: Marcin Niestroj @ 2016-09-30 9:36 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20160930093626.3843-1-m.niestroj@grinn-global.com>
liteBoard is a development board which uses liteSOM as its base.
Hardware specification:
* liteSOM (i.MX6UL, DRAM, eMMC)
* Ethernet PHY (id 0)
* USB host (usb_otg1)
* MicroSD slot (uSDHC1)
Signed-off-by: Marcin Niestroj <m.niestroj@grinn-global.com>
Reviewed-by: Fabio Estevam <fabio.estevam@nxp.com>
---
Changes v2 -> v3: none
Changes v1 -> v2:
* Use dual license
* Fix typo "defaullt" -> "default"
arch/arm/boot/dts/Makefile | 1 +
arch/arm/boot/dts/imx6ul-liteboard.dts | 153 +++++++++++++++++++++++++++++++++
2 files changed, 154 insertions(+)
create mode 100644 arch/arm/boot/dts/imx6ul-liteboard.dts
diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile
index faacd52..b149313 100644
--- a/arch/arm/boot/dts/Makefile
+++ b/arch/arm/boot/dts/Makefile
@@ -407,6 +407,7 @@ dtb-$(CONFIG_SOC_IMX6SX) += \
imx6sx-sdb.dtb
dtb-$(CONFIG_SOC_IMX6UL) += \
imx6ul-14x14-evk.dtb \
+ imx6ul-liteboard.dtb \
imx6ul-pico-hobbit.dtb \
imx6ul-tx6ul-0010.dtb \
imx6ul-tx6ul-0011.dtb \
diff --git a/arch/arm/boot/dts/imx6ul-liteboard.dts b/arch/arm/boot/dts/imx6ul-liteboard.dts
new file mode 100644
index 0000000..f2e04f2
--- /dev/null
+++ b/arch/arm/boot/dts/imx6ul-liteboard.dts
@@ -0,0 +1,153 @@
+/*
+ * Copyright 2016 Grinn
+ *
+ * Author: Marcin Niestroj <m.niestroj@grinn-global.com>
+ *
+ * This file is dual-licensed: you can use it either under the terms
+ * of the GPL or the X11 license, at your option. Note that this dual
+ * licensing only applies to this file, and not this project as a
+ * whole.
+ *
+ * a) This file is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License
+ * version 2 as published by the Free Software Foundation.
+ *
+ * This file is distributed in the hope that it will be useful
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ *
+ * Or, alternatively
+ *
+ * b) Permission is hereby granted, free of charge, to any person
+ * obtaining a copy of this software and associated documentation
+ * files (the "Software"), to deal in the Software without
+ * restriction, including without limitation the rights to use
+ * copy, modify, merge, publish, distribute, sublicense, and/or
+ * sell copies of the Software, and to permit persons to whom the
+ * Software is furnished to do so, subject to the following
+ * conditions:
+ *
+ * The above copyright notice and this permission notice shall be
+ * included in all copies or substantial portions of the Software.
+ *
+ * THE SOFTWARE IS PROVIDED , WITHOUT WARRANTY OF ANY KIND
+ * EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES
+ * OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND
+ * NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT
+ * HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY
+ * WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
+ * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR
+ * OTHER DEALINGS IN THE SOFTWARE.
+ */
+
+/dts-v1/;
+
+#include "imx6ul-litesom.dtsi"
+
+/ {
+ model = "Grinn i.MX6UL liteBoard";
+ compatible = "grinn,imx6ul-liteboard", "grinn,imx6ul-litesom",
+ "fsl,imx6ul";
+
+ chosen {
+ stdout-path = &uart1;
+ };
+
+ regulators {
+ compatible = "simple-bus";
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ reg_usb_otg1_vbus: usb_otg1_regulator {
+ compatible = "regulator-fixed";
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_usb_otg1_vbus>;
+ regulator-name = "usb_otg1_vbus";
+ regulator-min-microvolt = <5000000>;
+ regulator-max-microvolt = <5000000>;
+ gpio = <&gpio2 8 GPIO_ACTIVE_LOW>;
+ };
+ };
+};
+
+&iomuxc {
+ pinctrl_enet1: enet1grp {
+ fsl,pins = <
+ MX6UL_PAD_GPIO1_IO07__ENET1_MDC 0x1b0b0
+ MX6UL_PAD_GPIO1_IO06__ENET1_MDIO 0x1b0b0
+ MX6UL_PAD_ENET1_RX_EN__ENET1_RX_EN 0x1b0b0
+ MX6UL_PAD_ENET1_RX_ER__ENET1_RX_ER 0x1b0b0
+ MX6UL_PAD_ENET1_RX_DATA0__ENET1_RDATA00 0x1b0b0
+ MX6UL_PAD_ENET1_RX_DATA1__ENET1_RDATA01 0x1b0b0
+ MX6UL_PAD_ENET1_TX_EN__ENET1_TX_EN 0x1b0b0
+ MX6UL_PAD_ENET1_TX_DATA0__ENET1_TDATA00 0x1b0b0
+ MX6UL_PAD_ENET1_TX_DATA1__ENET1_TDATA01 0x1b0b0
+ MX6UL_PAD_ENET1_TX_CLK__ENET1_REF_CLK1 0x4001b031
+ >;
+ };
+
+ pinctrl_uart1: uart1grp {
+ fsl,pins = <
+ MX6UL_PAD_UART1_TX_DATA__UART1_DCE_TX 0x1b0b1
+ MX6UL_PAD_UART1_RX_DATA__UART1_DCE_RX 0x1b0b1
+ >;
+ };
+
+ pinctrl_usdhc1: usdhc1grp {
+ fsl,pins = <
+ MX6UL_PAD_UART1_RTS_B__GPIO1_IO19 0x17059
+ MX6UL_PAD_SD1_CMD__USDHC1_CMD 0x17059
+ MX6UL_PAD_SD1_CLK__USDHC1_CLK 0x10071
+ MX6UL_PAD_SD1_DATA0__USDHC1_DATA0 0x17059
+ MX6UL_PAD_SD1_DATA1__USDHC1_DATA1 0x17059
+ MX6UL_PAD_SD1_DATA2__USDHC1_DATA2 0x17059
+ MX6UL_PAD_SD1_DATA3__USDHC1_DATA3 0x17059
+ >;
+ };
+
+ pinctrl_usb_otg1_vbus: usb_otg1_vbus {
+ fsl,pins = <
+ MX6UL_PAD_ENET2_RX_DATA0__GPIO2_IO08 0x79
+ >;
+ };
+};
+
+&fec1 {
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_enet1>;
+ phy-mode = "rmii";
+ phy-handle = <ðphy0>;
+ status = "okay";
+
+ mdio {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ ethphy0: ethernet-phy at 0 {
+ reg = <0>;
+ };
+ };
+};
+
+&uart1 {
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_uart1>;
+ status = "okay";
+};
+
+&usbotg1 {
+ vbus-supply = <®_usb_otg1_vbus>;
+ dr_mode = "host";
+ status = "okay";
+};
+
+&usdhc1 {
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_usdhc1>;
+ cd-gpios = <&gpio1 19 GPIO_ACTIVE_LOW>;
+ no-1-8-v;
+ keep-power-in-suspend;
+ wakeup-source;
+ status = "okay";
+};
--
2.10.0
^ permalink raw reply related
* [PATCH 4/6] ARM: dts: da850-lcdk: add support for 1024x768 resolution
From: Bartosz Golaszewski @ 2016-09-30 9:37 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20160929185805.q2pdihajikgzo4lm@gobelin>
2016-09-29 20:58 GMT+02:00 Karl Beldan <karl.beldan@gmail.com>:
> Hi,
>
> On Thu, Sep 29, 2016 at 06:31:53PM +0200, Bartosz Golaszewski wrote:
>> Add svga timings for 1024x768 resolution to the da850-lcdk
>> device tree.
>>
>
[snip]
>
> Why do you also call 1024x768 svga ?
>
Thanks, should have been xga. will fix in v2.
> I don't think the LCDK can cope with this resolution at this frequency
> (in terms of mem bandwidth), at least that's what I observed back in
> August. If confirmed I think it is worth mentioning in the log at least,
> but then I doubt adding this config would be useful.
>
Thanks for the heads up. How would that manifest itself? This seems to
work fine for me - I'm not getting any warnings on a simple system -
maybe if I added some additional memory load it would complain.
Thanks,
Bartosz
^ permalink raw reply
* [PATCH 6/6] ARM: da850: adjust memory settings for tilcdc
From: Karl Beldan @ 2016-09-30 9:39 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAMpxmJVQwQPa6FK+UGe1f7n5LdWUQyN9g+hO3OHB7PFqWrNY=w@mail.gmail.com>
On Fri, Sep 30, 2016 at 9:31 AM, Bartosz Golaszewski
<bgolaszewski@baylibre.com> wrote:
> 2016-09-29 21:07 GMT+02:00 Karl Beldan <karl.beldan@gmail.com>:
>> Hi,
>>
>> On Thu, Sep 29, 2016 at 06:31:55PM +0200, Bartosz Golaszewski wrote:
>>> Default memory settings of da850 do not meet the throughput/latency
>>> requirements of tilcdc. This results in the image displayed being
>>> incorrect and the following warning being displayed by the LCDC
>>> drm driver:
>>>
>>> tilcdc da8xx_lcdc.0: tilcdc_crtc_irq(0x00000020): FIFO underfow
>>>
>>> Reconfigure the LCDC priority to the highest. This is a workaround
>>> for the da850-lcdk board which has the LCD controller enabled in
>>> the device tree, but a long-term, system-wide fix is needed for
>>> all davinci boards.
>>>
>>> This patch has been modified for mainline linux. It comes from a
>>> downstream TI release for da850[1].
>>>
>>> Original author: Vishwanathrao Badarkhe, Manish <manishv.b@ti.com>
>>>
>>> [1] http://arago-project.org/git/projects/linux-davinci.git?p=projects/linux-davinci.git;a=commitdiff;h=b9bd39a34cc02c3ba2fc15539a2f0bc2b68d25da;hp=6f6c795faa6366a4ebc1037a0235edba6018a991
>>>
>>> Signed-off-by: Bartosz Golaszewski <bgolaszewski@baylibre.com>
>>> ---
>>
>> FWIW, the quirks could be applied conditionnally depending on the lcdc
>> node presence in the DT, a bit like:
>> https://github.com/kbeldan/linux/commit/cf15572ffef8e8a0d8110b3f6b29bd401d0538be
>> https://github.com/kbeldan/linux/commit/07e4fff9958bc1625a96791dce284c163fbe9c43
>>
>>
>> Regards,
>> Karl
>
> Hi Karl,
>
> I decided to post the simplest possible way of this to get the lcdc
> working upstream. In parallel I'm working on a system-wide way of
> applying such quirks not only limited to device tree nodes' presence.
Ok, that'd be a good thing, apparently people have been looking
to do such a thing for the am335x as well.
Regards,
Karl
> Thanks for the info!
>
> Best regards,
> Bartosz Golaszewski
^ permalink raw reply
* [PATCH v4 1/2] mm/hugetlb: Introduce ARCH_HAS_GIGANTIC_PAGE
From: Hillf Danton @ 2016-09-30 9:41 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1475227569-63446-2-git-send-email-xieyisheng1@huawei.com>
On Friday, September 30, 2016 5:26 PM Yisheng Xie
>
> Avoid making ifdef get pretty unwieldy if many ARCHs support gigantic page.
> No functional change with this patch.
>
> Signed-off-by: Yisheng Xie <xieyisheng1@huawei.com>
> Suggested-by: Michal Hocko <mhocko@suse.com>
> Acked-by: Michal Hocko <mhocko@suse.com>
> Acked-by: Naoya Horiguchi <n-horiguchi@ah.jp.nec.com>
> ---
Acked-by: Hillf Danton <hillf.zj@alibaba-inc.com>
^ permalink raw reply
* [PATCH 3/6] ARM: dts: da850-lcdk: enable the LCD controller
From: Bartosz Golaszewski @ 2016-09-30 9:42 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20160929184001.yooxkwulqgioak6a@gobelin>
2016-09-29 20:40 GMT+02:00 Karl Beldan <karl.beldan@gmail.com>:
> Hi,
>
> On Thu, Sep 29, 2016 at 06:31:52PM +0200, Bartosz Golaszewski wrote:
>> From: Karl Beldan <kbeldan@baylibre.com>
>>
>> This adds the pins used by the LCD controller, and uses 'tilcdc,panel'
>> with some default timings for 800x600.
>>
>> Tested on an LCDK connected on the VGA port (the LCDC is connected to
>> this port via a THS8135).
>>
>> Signed-off-by: Karl Beldan <kbeldan@baylibre.com>
>> [Bartosz:
>> - fixed whitespace errors
>> - tweaked the description
>
> The description tweak you mention is the removal of an erratum which is
> in the mentioned commit I put on github @
> (https://github.com/kbeldan/linux/commit/b7720bc983c00a083dece119f68ea9d2f522c6c4)
> it included an erratum wrt FIFO threshold I think is worth keeping:
> {
> There is an erratum (fifo-th) "LCDC: Underflow During Initialization":
> [...]
> "This problem may occur if the LCDC FIFO threshold size (
> LCDDMA_CTRL[TH_FIFO_READY]) is left at its default value after reset.
> Increasing the FIFO threshold size will reduce or eliminate underflows.
> Setting the threshold size to 256 double words or larger is
> recommended."
> }
Isn't this the issue that is fixed by changing the memory priority for lcdc?
>
>> - fixed the incorrect hback-porch value
>
> It can't be a fix, this value depends on the monitor connected.
>
Thanks, I'm new to drm. From reading the datasheet it seemed to me
that this depends on the resolution. FWIW it seems that most LCDs are
able to adjust to this themselves - I tested with two different
displays and the value I introduced worked on both while the previous
one shifted the image to the right. I'll look into that.
>> - other minor tweaks]
>
> I didn't see any other change while diffing.
>
Dropped the refresh rate from the timings node name.
Thanks,
Bartosz
^ permalink raw reply
* [PATCH v4 2/2] arm64 Kconfig: Select gigantic page
From: Hillf Danton @ 2016-09-30 9:43 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1475227569-63446-3-git-send-email-xieyisheng1@huawei.com>
On Friday, September 30, 2016 5:26 PM Yisheng Xie wrote
>
> Arm64 supports gigantic page after
> commit 084bd29810a5 ("ARM64: mm: HugeTLB support.")
> however, it can only be allocated at boottime and can't be freed.
>
> This patch selects ARCH_HAS_GIGANTIC_PAGE to make gigantic pages
> can be allocated and freed at runtime for arch arm64.
>
> Acked-by: Michal Hocko <mhocko@suse.com>
> Acked-by: Catalin Marinas <catalin.marinas@arm.com>
> Signed-off-by: Yisheng Xie <xieyisheng1@huawei.com>
> ---
Acked-by: Hillf Danton <hillf.zj@alibaba-inc.com>
^ permalink raw reply
* [PATCH v14 2/4] CMDQ: Mediatek CMDQ driver
From: Horng-Shyang Liao @ 2016-09-30 9:47 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1475226691.13398.35.camel@mtksdaap41>
On Fri, 2016-09-30 at 17:11 +0800, CK Hu wrote:
> Hi, HS:
>
> One comment inline
>
> On Fri, 2016-09-30 at 16:56 +0800, Horng-Shyang Liao wrote:
> > Hi CK,
> >
> > Please see my inline reply.
> >
> > On Fri, 2016-09-30 at 11:06 +0800, CK Hu wrote:
> > > Hi, HS:
> > >
> > > On Mon, 2016-09-05 at 09:44 +0800, HS Liao wrote:
> > > > This patch is first version of Mediatek Command Queue(CMDQ) driver. The
> > > > CMDQ is used to help write registers with critical time limitation,
> > > > such as updating display configuration during the vblank. It controls
> > > > Global Command Engine (GCE) hardware to achieve this requirement.
> > > > Currently, CMDQ only supports display related hardwares, but we expect
> > > > it can be extended to other hardwares for future requirements.
> > > >
> > > > Signed-off-by: HS Liao <hs.liao@mediatek.com>
> > > > Signed-off-by: CK Hu <ck.hu@mediatek.com>
> > > > ---
> > >
> > > [snip...]
> > >
> > > > +
> > > > +struct cmdq_task {
> > > > + struct cmdq *cmdq;
> > > > + struct list_head list_entry;
> > > > + void *va_base;
> > > > + dma_addr_t pa_base;
> > > > + size_t cmd_buf_size; /* command occupied size */
> > > > + size_t buf_size; /* real buffer size */
> > > > + bool finalized;
> > > > + struct cmdq_thread *thread;
> > >
> > > I think thread info could be removed from cmdq_task. Only
> > > cmdq_task_handle_error() and cmdq_task_insert_into_thread() use
> > > task->thread and caller of both function has the thread info. So you
> > > could just pass thread info into these two function and remove thread
> > > info in cmdq_task.
> >
> > This modification will remove 1 pointer but add 2 pointers. Moreover,
> > more pointers will need to be delivered between functions for future
> > extension. IMHO, it would be better to keep thread pointer inside
> > cmdq_task.
> >
> > > > + struct cmdq_task_cb cb;
> > >
> > > I think this callback function is equal to mailbox client tx_done
> > > callback. It's better to use already-defined interface rather than
> > > creating your own.
> >
> > This is because CMDQ driver allows different callback functions for
> > different tasks, but mailbox only allows one callback function per
> > channel. But, I think I can add a wrapper for tx_done to call CMDQ
> > callback functions. So, I will use tx_done in CMDQ v15.
>
> Up to now, one callback function for one channel is enough for DRM. So
> 'different callback function for different sent-message' looks like an
> advanced function. Maybe you should not include it in first patch.
>
> Regards,
> CK
Hi CK,
OK. I will do it.
Thanks,
HS
[snip...]
^ permalink raw reply
* [PATCH v3 1/9] mtd:fsl-quadspi:use the property fields of SPI-NOR
From: Cyrille Pitchen @ 2016-09-30 10:04 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1471505884-33996-1-git-send-email-B56489@freescale.com>
Hi Yunhui,
Indeed it's a really good thing to update the Freescale QSPI controller driver
so it relies more on the settings chosen in spi-nor.c: it avoids duplicating
the code. spi-nor.c is supposed to select all the instruction codes and memory
settings according to both the (Q)SPI memory and the controller capabilities.
The controller driver should only be responsible for sending the SPI commands
but should neither modify those commands nor be aware of the actual memory
connected to it.
So the idea of this patch is great :)
Best regards,
Cyrille
Le 18/08/2016 ? 09:37, Yunhui Cui a ?crit :
> We can get the read/write/erase opcode from the spi nor framework
> directly. This patch uses the information stored in the SPI-NOR to
> remove the hardcode in the fsl_qspi_init_lut().
>
> Signed-off-by: Yunhui Cui <B56489@freescale.com>
> Signed-off-by: Yunhui Cui <yunhui.cui@nxp.com>
Reviewed-by: Cyrille Pitchen <cyrille.pitchen@atmel.com>
> ---
> drivers/mtd/spi-nor/fsl-quadspi.c | 40 ++++++++++++---------------------------
> 1 file changed, 12 insertions(+), 28 deletions(-)
>
> diff --git a/drivers/mtd/spi-nor/fsl-quadspi.c b/drivers/mtd/spi-nor/fsl-quadspi.c
> index 5c82e4e..5ad6402 100644
> --- a/drivers/mtd/spi-nor/fsl-quadspi.c
> +++ b/drivers/mtd/spi-nor/fsl-quadspi.c
> @@ -373,9 +373,13 @@ static void fsl_qspi_init_lut(struct fsl_qspi *q)
> void __iomem *base = q->iobase;
> int rxfifo = q->devtype_data->rxfifo;
> u32 lut_base;
> - u8 cmd, addrlen, dummy;
> int i;
>
> + struct spi_nor *nor = &q->nor[0];
> + u8 addrlen = (nor->addr_width == 3) ? ADDR24BIT : ADDR32BIT;
> + u8 read_op = nor->read_opcode;
> + u8 read_dm = nor->read_dummy;
> +
> fsl_qspi_unlock_lut(q);
>
> /* Clear all the LUT table */
> @@ -385,20 +389,10 @@ static void fsl_qspi_init_lut(struct fsl_qspi *q)
> /* Quad Read */
> lut_base = SEQID_QUAD_READ * 4;
>
> - if (q->nor_size <= SZ_16M) {
> - cmd = SPINOR_OP_READ_1_1_4;
> - addrlen = ADDR24BIT;
> - dummy = 8;
> - } else {
> - /* use the 4-byte address */
> - cmd = SPINOR_OP_READ_1_1_4;
> - addrlen = ADDR32BIT;
> - dummy = 8;
> - }
> -
> - qspi_writel(q, LUT0(CMD, PAD1, cmd) | LUT1(ADDR, PAD1, addrlen),
> + qspi_writel(q, LUT0(CMD, PAD1, read_op) | LUT1(ADDR, PAD1, addrlen),
> base + QUADSPI_LUT(lut_base));
> - qspi_writel(q, LUT0(DUMMY, PAD1, dummy) | LUT1(FSL_READ, PAD4, rxfifo),
> + qspi_writel(q, LUT0(DUMMY, PAD1, read_dm) |
> + LUT1(FSL_READ, PAD4, rxfifo),
> base + QUADSPI_LUT(lut_base + 1));
>
> /* Write enable */
> @@ -409,16 +403,8 @@ static void fsl_qspi_init_lut(struct fsl_qspi *q)
> /* Page Program */
> lut_base = SEQID_PP * 4;
>
> - if (q->nor_size <= SZ_16M) {
> - cmd = SPINOR_OP_PP;
> - addrlen = ADDR24BIT;
> - } else {
> - /* use the 4-byte address */
> - cmd = SPINOR_OP_PP;
> - addrlen = ADDR32BIT;
> - }
> -
> - qspi_writel(q, LUT0(CMD, PAD1, cmd) | LUT1(ADDR, PAD1, addrlen),
> + qspi_writel(q, LUT0(CMD, PAD1, nor->program_opcode) |
> + LUT1(ADDR, PAD1, addrlen),
> base + QUADSPI_LUT(lut_base));
> qspi_writel(q, LUT0(FSL_WRITE, PAD1, 0),
> base + QUADSPI_LUT(lut_base + 1));
> @@ -432,10 +418,8 @@ static void fsl_qspi_init_lut(struct fsl_qspi *q)
> /* Erase a sector */
> lut_base = SEQID_SE * 4;
>
> - cmd = q->nor[0].erase_opcode;
> - addrlen = q->nor_size <= SZ_16M ? ADDR24BIT : ADDR32BIT;
> -
> - qspi_writel(q, LUT0(CMD, PAD1, cmd) | LUT1(ADDR, PAD1, addrlen),
> + qspi_writel(q, LUT0(CMD, PAD1, nor->erase_opcode) |
> + LUT1(ADDR, PAD1, addrlen),
> base + QUADSPI_LUT(lut_base));
>
> /* Erase the whole chip */
>
^ permalink raw reply
* [PATCH] arm64: add support for SHA256 using NEON instructions
From: Andy Polyakov @ 2016-09-30 10:44 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1475189503-9175-1-git-send-email-ard.biesheuvel@linaro.org>
> This is a port of the ARMv7 implementation in arch/arm/crypto. For a Cortex-A57
> (r2p1), the performance numbers are listed below. In summary, 40% - 50% speedup
> where it counts, i.e., block sizes over 256 bytes with few updates.
Cool! Great! Just in case for reference. You compare generic, new NEON
and hardware-assisted implementations. I assume that first one refers to
C compiler-generated code. But there is another option, i.e. non-NEON
assembly. Now to the "for reference" part. The reason for why NEON is
not utilized in OpenSSL is because it's deemed that it doesn't provide
"extraordinary" improvement over non-NEON assembly code, especially on
less sophisticated processors such as Cortex-A53. Note that I'm not
saying that NEON SHA256 subroutine is not faster, it is, only that it's
not "extraordinarily" faster in most relevant cases(*). In other words
it's reckoned that non-NEON assembly provides adequate *all-round*
performance, taking into consideration that it does it without being
dependent on optional NEON. Non-NEON assembly should also be interesting
in kernel context, because there are situations when you can't call NEON
procedure, be it suggested one or hardware-assisted, which itself relies
on NEON. And of course another nice quality about SHA2 module in OpenSSL
is that it emits both SHA256 and SHA512 codes ;-) On related note it
should be noted that NEON-izing SHA512 on ARM64 makes lesser sense, it's
bound to provide lesser improvement than SHA256 [if any at all in some
cases]. This is because in SHA256 you engage 4 lanes of NEON registers,
while in SHA512 case you have only 2.
(*) Well, this is also question of priorities. My rationale is that
there is a lot of Cortex-A53 and A57 phones out there that don't have
crypto-extensions, I refer to Qualcomm SoCs, where NEON gives less than
10% improvement [over non-NEON assembly]. Yes, it gives more on X-Gene,
but X-Gene is not wide-spread, and the rest (including upcoming X-Gene)
have crypto-extensions, so alternative code path doesn't matter.
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox