* [PATCH v5 net-next 2/7] net: mvneta: Do not allocate buffer in rxq init with HWBM
From: Gregory CLEMENT @ 2016-11-30 21:42 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <cover.0270f6d2413a709521fe2c8c17fbebea6f2e78d1.1480542157.git-series.gregory.clement@free-electrons.com>
For HWBM all buffers are allocated in mvneta_bm_construct() and in runtime
they are put into descriptors by hardware. There is no need to fill them
at this point.
Suggested-by: Marcin Wojtas <mw@semihalf.com>
Signed-off-by: Gregory CLEMENT <gregory.clement@free-electrons.com>
---
drivers/net/ethernet/marvell/mvneta.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/net/ethernet/marvell/mvneta.c b/drivers/net/ethernet/marvell/mvneta.c
index 1b84f746d748..f5319c50f8d9 100644
--- a/drivers/net/ethernet/marvell/mvneta.c
+++ b/drivers/net/ethernet/marvell/mvneta.c
@@ -2784,14 +2784,14 @@ static int mvneta_rxq_init(struct mvneta_port *pp,
mvneta_rxq_buf_size_set(pp, rxq,
MVNETA_RX_BUF_SIZE(pp->pkt_size));
mvneta_rxq_bm_disable(pp, rxq);
+ mvneta_rxq_fill(pp, rxq, rxq->size);
} else {
mvneta_rxq_bm_enable(pp, rxq);
mvneta_rxq_long_pool_set(pp, rxq);
mvneta_rxq_short_pool_set(pp, rxq);
+ mvneta_rxq_non_occup_desc_add(pp, rxq, rxq->size);
}
- mvneta_rxq_fill(pp, rxq, rxq->size);
-
return 0;
}
--
git-series 0.8.10
^ permalink raw reply related
* [PATCH] USB: OHCI: ohci-s3c2410: remove useless functions
From: csmanjuvijay at gmail.com @ 2016-11-30 21:42 UTC (permalink / raw)
To: linux-arm-kernel
From: Manjunath Goudar <csmanjuvijay@gmail.com>
The ohci_hcd_s3c2410_drv_probe and ohci_hcd_s3c2410_drv_remove
functions are removed as these are useless functions except calling
usb_hcd_s3c2410_probe and usb_hcd_s3c2410_remove functions.
The usb_hcd_s3c2410_probe function renamed to ohci_hcd_s3c2410_drv_probe
and usb_hcd_s3c2410_remove function renamed to ohci_hcd_s3c2410_drv_remove
for proper naming.
This also removes warnings and errors of checkpatch.pl script.
Signed-off-by: Manjunath Goudar <csmanjuvijay@gmail.com>
Cc: Kukjin Kim <kgene@kernel.org>
Cc: Krzysztof Kozlowski <krzk@kernel.org>
Cc: Javier Martinez Canillas <javier@osg.samsung.com>
Cc: Alan Stern <stern@rowland.harvard.edu>
Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Cc: linux-arm-kernel at lists.infradead.org
Cc: linux-samsung-soc at vger.kernel.org
Cc: linux-usb at vger.kernel.org
Cc: linux-kernel at vger.kernel.org
---
drivers/usb/host/ohci-s3c2410.c | 57 +++++++++++++++++------------------------
1 file changed, 24 insertions(+), 33 deletions(-)
diff --git a/drivers/usb/host/ohci-s3c2410.c b/drivers/usb/host/ohci-s3c2410.c
index d8e03a8..27b75b3 100644
--- a/drivers/usb/host/ohci-s3c2410.c
+++ b/drivers/usb/host/ohci-s3c2410.c
@@ -17,7 +17,7 @@
* Thanks to basprog at mail.ru for updates to newer kernels
*
* This file is licenced under the GPL.
-*/
+ */
#include <linux/clk.h>
#include <linux/io.h>
@@ -43,6 +43,8 @@ static const char hcd_name[] = "ohci-s3c2410";
static struct clk *clk;
static struct clk *usb_clk;
+static struct hc_driver __read_mostly ohci_s3c2410_hc_driver;
+
/* forward definitions */
static void s3c2410_hcd_oc(struct s3c2410_hcd_info *info, int port_oc);
@@ -96,7 +98,7 @@ static void s3c2410_stop_hc(struct platform_device *dev)
*
* update the status data from the hub with anything that
* has been detected by our system
-*/
+ */
static int
ohci_s3c2410_hub_status_data(struct usb_hcd *hcd, char *buf)
@@ -135,7 +137,7 @@ ohci_s3c2410_hub_status_data(struct usb_hcd *hcd, char *buf)
*
* configure the power on a port, by calling the platform device
* routine registered with the platform device
-*/
+ */
static void s3c2410_usb_set_power(struct s3c2410_hcd_info *info,
int port, int to)
@@ -154,7 +156,7 @@ static void s3c2410_usb_set_power(struct s3c2410_hcd_info *info,
* look at control requests to the hub, and see if we need
* to take any action or over-ride the results from the
* request.
-*/
+ */
static int ohci_s3c2410_hub_control(
struct usb_hcd *hcd,
@@ -174,7 +176,8 @@ static int ohci_s3c2410_hub_control(
hcd, typeReq, wValue, wIndex, buf, wLength);
/* if we are only an humble host without any special capabilities
- * process the request straight away and exit */
+ * process the request straight away and exit
+ */
if (info == NULL) {
ret = ohci_hub_control(hcd, typeReq, wValue,
@@ -285,7 +288,7 @@ static int ohci_s3c2410_hub_control(
/* s3c2410_hcd_oc
*
* handle an over-current report
-*/
+ */
static void s3c2410_hcd_oc(struct s3c2410_hcd_info *info, int port_oc)
{
@@ -309,7 +312,8 @@ static void s3c2410_hcd_oc(struct s3c2410_hcd_info *info, int port_oc)
port->oc_changed = 1;
/* ok, once over-current is detected,
- the port needs to be powered down */
+ * the port needs to be powered down
+ */
s3c2410_usb_set_power(info, portno+1, 0);
}
}
@@ -321,26 +325,29 @@ static void s3c2410_hcd_oc(struct s3c2410_hcd_info *info, int port_oc)
/* may be called with controller, bus, and devices active */
/*
- * usb_hcd_s3c2410_remove - shutdown processing for HCD
+ * ohci_hcd_s3c2410_remove - shutdown processing for HCD
* @dev: USB Host Controller being removed
* Context: !in_interrupt()
*
- * Reverses the effect of usb_hcd_3c2410_probe(), first invoking
+ * Reverses the effect of ohci_hcd_3c2410_probe(), first invoking
* the HCD's stop() method. It is always called from a thread
* context, normally "rmmod", "apmd", or something similar.
*
-*/
+ */
-static void
-usb_hcd_s3c2410_remove(struct usb_hcd *hcd, struct platform_device *dev)
+static int
+ohci_hcd_s3c2410_remove(struct platform_device *dev)
{
+ struct usb_hcd *hcd = platform_get_drvdata(dev);
+
usb_remove_hcd(hcd);
s3c2410_stop_hc(dev);
usb_put_hcd(hcd);
+ return 0;
}
/**
- * usb_hcd_s3c2410_probe - initialize S3C2410-based HCDs
+ * ohci_hcd_s3c2410_probe - initialize S3C2410-based HCDs
* Context: !in_interrupt()
*
* Allocates basic resources for this USB host controller, and
@@ -348,8 +355,7 @@ usb_hcd_s3c2410_remove(struct usb_hcd *hcd, struct platform_device *dev)
* through the hotplug entry's driver_data.
*
*/
-static int usb_hcd_s3c2410_probe(const struct hc_driver *driver,
- struct platform_device *dev)
+static int ohci_hcd_s3c2410_probe(struct platform_device *dev)
{
struct usb_hcd *hcd = NULL;
struct s3c2410_hcd_info *info = dev_get_platdata(&dev->dev);
@@ -358,7 +364,7 @@ static int usb_hcd_s3c2410_probe(const struct hc_driver *driver,
s3c2410_usb_set_power(info, 1, 1);
s3c2410_usb_set_power(info, 2, 1);
- hcd = usb_create_hcd(driver, &dev->dev, "s3c24xx");
+ hcd = usb_create_hcd(&ohci_s3c2410_hc_driver, &dev->dev, "s3c24xx");
if (hcd == NULL)
return -ENOMEM;
@@ -404,21 +410,6 @@ static int usb_hcd_s3c2410_probe(const struct hc_driver *driver,
/*-------------------------------------------------------------------------*/
-static struct hc_driver __read_mostly ohci_s3c2410_hc_driver;
-
-static int ohci_hcd_s3c2410_drv_probe(struct platform_device *pdev)
-{
- return usb_hcd_s3c2410_probe(&ohci_s3c2410_hc_driver, pdev);
-}
-
-static int ohci_hcd_s3c2410_drv_remove(struct platform_device *pdev)
-{
- struct usb_hcd *hcd = platform_get_drvdata(pdev);
-
- usb_hcd_s3c2410_remove(hcd, pdev);
- return 0;
-}
-
#ifdef CONFIG_PM
static int ohci_hcd_s3c2410_drv_suspend(struct device *dev)
{
@@ -465,8 +456,8 @@ static const struct of_device_id ohci_hcd_s3c2410_dt_ids[] = {
MODULE_DEVICE_TABLE(of, ohci_hcd_s3c2410_dt_ids);
static struct platform_driver ohci_hcd_s3c2410_driver = {
- .probe = ohci_hcd_s3c2410_drv_probe,
- .remove = ohci_hcd_s3c2410_drv_remove,
+ .probe = ohci_hcd_s3c2410_probe,
+ .remove = ohci_hcd_s3c2410_remove,
.shutdown = usb_hcd_platform_shutdown,
.driver = {
.name = "s3c2410-ohci",
--
2.7.4
^ permalink raw reply related
* [PATCH v5 net-next 1/7] net: mvneta: Optimize rx path for small frame
From: Gregory CLEMENT @ 2016-11-30 21:42 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <cover.0270f6d2413a709521fe2c8c17fbebea6f2e78d1.1480542157.git-series.gregory.clement@free-electrons.com>
For small frame reuse the phys_addr variable instead of accessing the
uncacheable value in the rx descriptor.
Signed-off-by: Gregory CLEMENT <gregory.clement@free-electrons.com>
---
drivers/net/ethernet/marvell/mvneta.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/net/ethernet/marvell/mvneta.c b/drivers/net/ethernet/marvell/mvneta.c
index 87274d4ab102..1b84f746d748 100644
--- a/drivers/net/ethernet/marvell/mvneta.c
+++ b/drivers/net/ethernet/marvell/mvneta.c
@@ -1918,7 +1918,7 @@ static int mvneta_rx_swbm(struct mvneta_port *pp, int rx_todo,
goto err_drop_frame;
dma_sync_single_range_for_cpu(dev->dev.parent,
- rx_desc->buf_phys_addr,
+ phys_addr,
MVNETA_MH_SIZE + NET_SKB_PAD,
rx_bytes,
DMA_FROM_DEVICE);
--
git-series 0.8.10
^ permalink raw reply related
* [PATCH v5 net-next 0/7] Support Armada 37xx SoC (ARMv8 64-bits) in mvneta driver
From: Gregory CLEMENT @ 2016-11-30 21:42 UTC (permalink / raw)
To: linux-arm-kernel
Hi,
The Armada 37xx is a new ARMv8 SoC from Marvell using same network
controller as the older Armada 370/38x/XP SoCs. This series adapts the
driver in order to be able to use it on this new SoC. The main changes
are:
- 64-bits support: the first patches allow using the driver on a 64-bit
architecture.
- MBUS support: the mbus configuration is different on Armada 37xx
from the older SoCs.
- per cpu interrupt: Armada 37xx do not support per cpu interrupt for
the NETA IP, the non-per-CPU behavior was added back.
The first patch is an optimization in the rx path in swbm mode.
The second patch remove unnecessary allocation for HWBM.
The first item is solved by patches 4 and 5.
The 2 last items are solved by patch 6.
In patch 7 the dt support is added.
Beside Armada 37xx, this series have been again tested on Armada XP
and Armada 38x (with Hardware Buffer Management and with Software
Buffer Management).
This is the 5th version of the series:
- 1st version:
http://lists.infradead.org/pipermail/linux-arm-kernel/2016-November/469588.html
- 2nd version:
http://lists.infradead.org/pipermail/linux-arm-kernel/2016-November/470476.html
- 3rd version:
http://lists.infradead.org/pipermail/linux-arm-kernel/2016-November/470901.html
- 4th version:
http://lists.infradead.org/pipermail/linux-arm-kernel/2016-November/471039.html
Changelog:
v4 -> v5:
- remove unnecessary cast in patch 3
v3 -> v4:
- Adding new patch: "net: mvneta: do not allocate buffer in rxq init
with HWBM"
- Simplify the HWBM case in patch 3 as suggested by Marcin
v2 -> v3:
- Adding patch 1 "Optimize rx path for small frame"
- Fix the kbuild error by moving the "phys_addr += pp->rx_offset_correction;"
line from patch 2 to patch 3 where rx_offset_correction is introduced.
- Move the memory allocation of the buf_virt_addr of the rxq to be
called by the probe function in order to avoid a memory leak.
Thanks,
Gregory
Gregory CLEMENT (5):
net: mvneta: Optimize rx path for small frame
net: mvneta: Do not allocate buffer in rxq init with HWBM
net: mvneta: Use cacheable memory to store the rx buffer virtual address
net: mvneta: Only disable mvneta_bm for 64-bits
ARM64: dts: marvell: Add network support for Armada 3700
Marcin Wojtas (2):
net: mvneta: Convert to be 64 bits compatible
net: mvneta: Add network support for Armada 3700 SoC
Documentation/devicetree/bindings/net/marvell-armada-370-neta.txt | 7 +-
arch/arm64/boot/dts/marvell/armada-3720-db.dts | 23 +++++-
arch/arm64/boot/dts/marvell/armada-37xx.dtsi | 23 +++++-
drivers/net/ethernet/marvell/Kconfig | 10 +-
drivers/net/ethernet/marvell/mvneta.c | 344 +++++++++++++++++++++++++++++++++++++++++++++++++++---------------------
5 files changed, 305 insertions(+), 102 deletions(-)
base-commit: 436accebb53021ef7c63535f60bda410aa87c136
--
git-series 0.8.10
^ permalink raw reply
* [PATCH] dt-bindings: document how to setup rockchip timers as clocksource
From: Alexander Kochetkov @ 2016-11-30 21:40 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161130213006.p6totahjga7546s6@rob-hp-laptop>
> 1 ???. 2016 ?., ? 0:30, Rob Herring <robh@kernel.org> ???????(?):
>
> 1st and 2nd are ambiguous. Plus this is an OS implementation detail that
> doesn't belong in the binding.
>
>> +If you want to bind specific timer as clockevent (i.e. one from alive subsystem)
>> +and specific timer as clocksource, you can number the timers in "aliases" node.
>
> No.
>
> Use and/or describe what are the features of a timer to make the
> decision. There has to be some reason you care which one. One has an
> interrupt and the other doesn't. One is always on. Etc.
Thank you, Rob.
Eventually I abandoned this decision.
I left only one patch, which you confirmed recently.
And sorry for making noise with duplicate patches.
Alexander.
^ permalink raw reply
* [GIT PULL 2/3] ARM: dts: exynos: DT for v4.10, second round
From: Arnd Bergmann @ 2016-11-30 21:39 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1479967709-6619-3-git-send-email-krzk@kernel.org>
On Thursday, November 24, 2016 8:08:28 AM CET Krzysztof Kozlowski wrote:
> ----------------------------------------------------------------
> Samsung DeviceTree second update for v4.10:
> 1. Cleanups in MSHC nodes.
> 2. Enable ADC on Odroid boards.
> 3. Fix interrupt flags on recently added DMA sound nodes in Exynos5410.
Pulled into next/dt, thanks!
Arnd
^ permalink raw reply
* [PATCH 2/2] dt-bindings: Add DT bindings info for FlexRM mailbox driver
From: Rob Herring @ 2016-11-30 21:38 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1480048551-3285-3-git-send-email-anup.patel@broadcom.com>
On Fri, Nov 25, 2016 at 10:05:51AM +0530, Anup Patel wrote:
> This patch adds device tree bindings document for the FlexRM
> mailbox driver.
Bindings document h/w, not drivers.
>
> Reviewed-by: Ray Jui <ray.jui@broadcom.com>
> Reviewed-by: Scott Branden <scott.branden@broadcom.com>
> Signed-off-by: Anup Patel <anup.patel@broadcom.com>
> ---
> .../bindings/mailbox/brcm,flexrm-mbox.txt | 60 ++++++++++++++++++++++
> 1 file changed, 60 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/mailbox/brcm,flexrm-mbox.txt
>
> diff --git a/Documentation/devicetree/bindings/mailbox/brcm,flexrm-mbox.txt b/Documentation/devicetree/bindings/mailbox/brcm,flexrm-mbox.txt
> new file mode 100644
> index 0000000..7969b1c
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/mailbox/brcm,flexrm-mbox.txt
> @@ -0,0 +1,60 @@
> +Broadcom FlexRM Mailbox Driver
h/w
> +===============================
> +The Broadcom FlexRM ring manager provides a set of rings which can be
> +used to submit work to offload engines. An SoC may have multiple FlexRM
> +hardware blocks. There is one device tree entry per block. The FlexRM
> +mailbox drivers creates a mailbox instance using FlexRM rings where
> +each mailbox channel is a separate FlexRM ring.
> +
> +Required properties:
> +--------------------
> +- compatible: Should be "brcm,flexrm-mbox"
Sounds generic. Add SoC specific compatible strings please.
> +- reg: Specifies base physical address and size of the FlexRM
> + ring registers
> +- msi-parent: Phandles (and potential Device IDs) to MSI controllers
> + The FlexRM engine will send MSIs (instead of wired
> + interrupts) to CPU. There is one MSI for each FlexRM ring.
One ring is one h/w block, right? How many instances is not really
relevant.
> + Refer devicetree/bindings/interrupt-controller/msi.txt
> +- #mbox-cells: Specifies the number of cells needed to encode a mailbox
> + channel. This should be 3.
> +
> + The 1st cell is the mailbox channel number.
> +
> + The 2nd cell contains MSI completion threshold. This is the
> + number of completion messages for which FlexRM will inject
> + one MSI interrupt to CPU.
> +
> + The 3nd cell contains MSI timer value representing time for
> + which FlexRM will wait to accumulate N completion messages
> + where N is the value specified by 2nd cell above. If FlexRM
> + does not get required number of completion messages in time
> + specified by this cell then it will inject one MSI interrupt
> + to CPU provided atleast one completion message is available.
> +
> +Optional properties:
> +--------------------
> +- dma-coherent: Present if DMA operations made by the FlexRM engine (such
> + as DMA descriptor access, access to buffers pointed by DMA
> + descriptors and read/write pointer updates to DDR) are
> + cache coherent with the CPU.
> +
> +Example:
> +--------
> +crypto_mbox: mbox at 67000000 {
> + compatible = "brcm,flexrm-mbox";
> + reg = <0x67000000 0x200000>;
> + msi-parent = <&gic_its 0x7f00>;
> + #mbox-cells = <3>;
> +};
> +
> +crypto_client {
Is this a h/w block or purely a driver on top of the mailbox? The latter
doesn't belong in DT.
> + ...
> + mboxes = <&crypto_mbox 0 0x1 0xffff>,
> + <&crypto_mbox 1 0x1 0xffff>,
> + <&crypto_mbox 16 0x1 0xffff>,
> + <&crypto_mbox 17 0x1 0xffff>,
> + <&crypto_mbox 30 0x1 0xffff>,
> + <&crypto_mbox 31 0x1 0xffff>;
> + };
> + ...
> +};
> --
> 2.7.4
>
^ permalink raw reply
* [PATCH] dt-bindings: document how to setup rockchip timers as clocksource
From: Rob Herring @ 2016-11-30 21:30 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1480025536-6837-1-git-send-email-al.kochet@gmail.com>
On Fri, Nov 25, 2016 at 01:12:16AM +0300, Alexander Kochetkov wrote:
> The patch describes how to setup rockchip timers in device tree
> so they can be used as clocksource.
>
> I'm going to implement this feature.
>
> Signed-off-by: Alexander Kochetkov <al.kochet@gmail.com>
> ---
> .../bindings/timer/rockchip,rk-timer.txt | 35 +++++++++++++++++++-
> 1 file changed, 34 insertions(+), 1 deletion(-)
>
> diff --git a/Documentation/devicetree/bindings/timer/rockchip,rk-timer.txt b/Documentation/devicetree/bindings/timer/rockchip,rk-timer.txt
> index 7bc9691..15f8fed 100644
> --- a/Documentation/devicetree/bindings/timer/rockchip,rk-timer.txt
> +++ b/Documentation/devicetree/bindings/timer/rockchip,rk-timer.txt
> @@ -16,7 +16,18 @@ Required properties:
> - clock-names : must include the following entries:
> "timer", "pclk"
>
> -Example:
> +Note:
> +If device tree contain only one timer, than the timer will be intialized
> +as clockevent provider. If device tree contain two timers, than first timer
> +will be initialized as clockevent provider and second one as clocksource.
1st and 2nd are ambiguous. Plus this is an OS implementation detail that
doesn't belong in the binding.
> +If you want to bind specific timer as clockevent (i.e. one from alive subsystem)
> +and specific timer as clocksource, you can number the timers in "aliases" node.
No.
Use and/or describe what are the features of a timer to make the
decision. There has to be some reason you care which one. One has an
interrupt and the other doesn't. One is always on. Etc.
Rob
^ permalink raw reply
* [PATCH v4 net-next 3/7] net: mvneta: Use cacheable memory to store the rx buffer virtual address
From: Gregory CLEMENT @ 2016-11-30 21:27 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161130.135725.407314756675613303.davem@davemloft.net>
Hi David,
On mer., nov. 30 2016, David Miller <davem@davemloft.net> wrote:
> From: Gregory CLEMENT <gregory.clement@free-electrons.com>
> Date: Tue, 29 Nov 2016 15:55:21 +0100
>
>> + /* Virtual address of the RX buffer */
>> + void **buf_virt_addr;
>> +
>> /* Virtual address of the RX DMA descriptors array */
>> struct mvneta_rx_desc *descs;
>>
> ...
>> + data = (unsigned char *)rxq->buf_virt_addr[index];
>
> This cast is unnecessary, please remove it.
OK I am doing it now.
Thanks,
Gregory
--
Gregory Clement, Free Electrons
Kernel, drivers, real-time and embedded Linux
development, consulting, training and support.
http://free-electrons.com
^ permalink raw reply
* [GIT PULL 2/6] Broadcom devicetree changes for 4.10
From: Arnd Bergmann @ 2016-11-30 21:27 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161122054824.16974-2-f.fainelli@gmail.com>
On Monday, November 21, 2016 9:48:20 PM CET Florian Fainelli wrote:
> 34 files changed, 1440 insertions(+), 29 deletions(-)
One follow-up: as this was a relatively big branch, it would have
been nice to get parts of it a little earlier. I see that the
raspberry-pi changes make up about half of it and came fairly
late, but the rest apparently was ready much earlier.
If you have the choice between waiting a little longer to
send all the changes at once, and sending off a good chunk
a little earlier, better send multiple sets of pull requests.
Arnd
^ permalink raw reply
* [PATCH] dt-bindings: clarify compatible field usage for rockchip timers
From: Rob Herring @ 2016-11-30 21:25 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1480025455-6797-1-git-send-email-al.kochet@gmail.com>
On Fri, Nov 25, 2016 at 01:10:55AM +0300, Alexander Kochetkov wrote:
> rk3036 dtsi file already use compatible field as
> "rockchip,rk3036-timer", "rockchip,rk3288-timer".
>
> The patch clearly shows how that filed should be used on other chips.
>
> Signed-off-by: Alexander Kochetkov <al.kochet@gmail.com>
> ---
> .../bindings/timer/rockchip,rk-timer.txt | 12 +++++++++---
> 1 file changed, 9 insertions(+), 3 deletions(-)
Acked-by: Rob Herring <robh@kernel.org>
^ permalink raw reply
* [GIT PULL 6/6] Broadcom defconfig-arm64 changes for 4.10
From: Arnd Bergmann @ 2016-11-30 21:23 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161122054824.16974-6-f.fainelli@gmail.com>
On Monday, November 21, 2016 9:48:24 PM CET Florian Fainelli wrote:
> This pull request contains Broadcom ARM64-based SoCs defconfig changes for 4.10,
> please pull the following changes:
>
> - Eric updates the ARMv8 defconfig to contain everything that is needed to run
> a 64-bit kernel on the Raspberry Pi 3
>
> - Scott enables the standard AT25 EEPROM driver as module for the ARM64 defconfig
>
> - Martin enables the Raspberry Pi Thermal driver in the ARM64 defconfig
>
Pulled into next/arm64, thanks!
Arnd
^ permalink raw reply
* [GIT PULL 5/6] Broadcom defconfig changes for 4.10
From: Arnd Bergmann @ 2016-11-30 21:22 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161122054824.16974-5-f.fainelli@gmail.com>
On Monday, November 21, 2016 9:48:23 PM CET Florian Fainelli wrote:
> This pull request contains Broadcom ARM-based defconfig changes for 4.10, please
> pull the following:
>
> - Florian updates the multi_v7_defconfig with the relevant basic drivers needed
> for the Broadcom BCM5301x (Northstar) SoCs to reboot, have PCIe, and Ethernet
>
> - Martin enables the Raspberry Pi thermal driver in bcm2835_defconfig
>
Pulled into next/defconfig, thanks!
Arnd
^ permalink raw reply
* [PATCH v2 3/7] PWM: add pwm-stm32 DT bindings
From: Rob Herring @ 2016-11-30 21:20 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1480000463-9625-4-git-send-email-benjamin.gaignard@st.com>
On Thu, Nov 24, 2016 at 04:14:19PM +0100, Benjamin Gaignard wrote:
> Define bindings for pwm-stm32
>
> version 2:
> - use parameters instead of compatible of handle the hardware configuration
>
> Signed-off-by: Benjamin Gaignard <benjamin.gaignard@st.com>
> ---
> .../devicetree/bindings/pwm/pwm-stm32.txt | 37 ++++++++++++++++++++++
> 1 file changed, 37 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/pwm/pwm-stm32.txt
>
> diff --git a/Documentation/devicetree/bindings/pwm/pwm-stm32.txt b/Documentation/devicetree/bindings/pwm/pwm-stm32.txt
> new file mode 100644
> index 0000000..36263f0
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/pwm/pwm-stm32.txt
> @@ -0,0 +1,37 @@
> +STMicroelectronics PWM driver bindings for STM32
> +
> +Must be a sub-node of STM32 general purpose timer driver
> +
> +Required parameters:
> +- compatible: Must be "st,stm32-pwm"
> +- pinctrl-names: Set to "default".
> +- pinctrl-0: List of phandles pointing to pin configuration nodes
> + for PWM module.
> + For Pinctrl properties, please refer to [1].
> +
> +Optional parameters:
> +- st,breakinput: Set if the hardware have break input capabilities
> +- st,breakinput-polarity: Set break input polarity. Default is 0
> + The value define the active polarity:
> + - 0 (active LOW)
> + - 1 (active HIGH)
> +- st,pwm-num-chan: Number of available PWM channels. Default is 0.
> +- st,32bits-counter: Set if the hardware have a 32 bits counter
> +- st,complementary: Set if the hardware have complementary output channels
What does complementary mean here?
> +
> +[1] Documentation/devicetree/bindings/pinctrl/pinctrl-bindings.txt
> +
> +Example:
> + gptimer1: gptimer1 at 40010000 {
timer at ...
> + compatible = "st,stm32-gptimer";
> + reg = <0x40010000 0x400>;
> + clocks = <&rcc 0 160>;
> + clock-names = "clk_int";
> +
> + pwm1 at 0 {
pwm {
Is there more than one?
> + compatible = "st,stm32-pwm";
> + st,pwm-num-chan = <4>;
> + st,breakinput;
> + st,complementary;
> + };
> + };
> --
> 1.9.1
>
^ permalink raw reply
* [GIT PULL 4/6] Broadcom maintainers-arm64 changes for 4.10
From: Arnd Bergmann @ 2016-11-30 21:20 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161122054824.16974-4-f.fainelli@gmail.com>
On Monday, November 21, 2016 9:48:22 PM CET Florian Fainelli wrote:
> This pull request contains MAINTAINERS file updates for Broadcom ARM64 entries,
> please pull:
>
> - Jayachandran updates his email address for the Broadcom Vulcan entry
>
Pulled into next/arm64, thanks!
Arnd
^ permalink raw reply
* [GIT PULL 10/10] arm64: tegra: Default configuration updates for v4.10-rc1
From: Arnd Bergmann @ 2016-11-30 21:12 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161130163929.GA20246@ulmo.ba.sec>
On Wednesday, November 30, 2016 5:39:29 PM CET Thierry Reding wrote:
> On Wed, Nov 30, 2016 at 05:10:43PM +0100, Arnd Bergmann wrote:
> > On Friday, November 18, 2016 5:17:19 PM CET Thierry Reding wrote:
> > > arm64: tegra: Default configuration updates for v4.10-rc1
> > >
> > > Enable Tegra186 support.
> > >
> >
> > This was already in next/arm64 (but I didn't see a notification),
> > and with the arm64-dt branch now merged as well, we should have
> > everything you sent.
>
> I had also sent a couple of individual patches that seemed to not have
> it made into v4.9 and v4.8 for some reason (they were part of the pull
> requests, as far as I can tell). Do you think you could pull those in
> as well?
Most likely yes, but I have trouble finding them right now. Can you
just resend them?
Arnd
^ permalink raw reply
* [PATCH v2] soc: ti: qmss: fix the case when !SMP
From: Arnd Bergmann @ 2016-11-30 21:11 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <92af0586-7deb-9e94-a0e7-377337ebfb9e@oracle.com>
On Wednesday, November 30, 2016 9:13:44 AM CET Santosh Shilimkar wrote:
>
> Can you apply this to your non critical fixes queue ?
>
> On 11/30/2016 9:09 AM, Grygorii Strashko wrote:
> > + Santosh Shilimkar <santosh.shilimkar@oracle.com>
> >
> > On 11/30/2016 10:53 AM, Grygorii Strashko wrote:
> >> The irq_set_affinity_hint() will always fail when !SMP and
> >> Networking will fail on Keystone 2 devices in this case.
> >> Hence, fix by ignoring IRQ affinity settings when !SMP.
> >>
> >> Cc: Arnd Bergmann <arnd@arndb.de>
> >> Signed-off-by: Grygorii Strashko <grygorii.strashko@ti.com>
> >> ---
> Acked-by: Santosh Shilimkar <ssantosh@kernel.org>
>
>
Applied, thanks!
Arnd
^ permalink raw reply
* [GIT PULL] ARM: keystone: add TI SCI protocol support for v4.10
From: Arnd Bergmann @ 2016-11-30 21:09 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <6f67f67f-7489-6d62-c2c2-9bba440cfabc@ti.com>
On Wednesday, November 30, 2016 7:59:26 PM CET Tero Kristo wrote:
>
> Thanks Arnd, that looks good to me.
>
> I'll figure out how to add branch description next time when I am going
> to be sending a pull-request directly to you guys.
>
>
You should get a prompt when you sign the tag.
Actually my preference would be for you to forward this to Santosh:
There are a lot of little details to know about the submission
process to for arm-soc, and it's easier for us if fewer people
have to be aware of them.
Arnd
^ permalink raw reply
* [PATCH v2 4/9] clk: stm32f4: Add lcd-tft clock
From: Rob Herring @ 2016-11-30 20:53 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1479998749-20358-5-git-send-email-gabriel.fernandez@st.com>
On Thu, Nov 24, 2016 at 03:45:44PM +0100, gabriel.fernandez at st.com wrote:
> From: Gabriel Fernandez <gabriel.fernandez@st.com>
>
> This patch introduces lcd-tft clock for stm32f4 soc.
>
> Signed-off-by: Gabriel Fernandez <gabriel.fernandez@st.com>
> ---
> .../devicetree/bindings/clock/st,stm32-rcc.txt | 1 +
> drivers/clk/clk-stm32f4.c | 118 +++++++++++++++++++++
> include/dt-bindings/clock/stm32f4-clock.h | 3 +-
> 3 files changed, 121 insertions(+), 1 deletion(-)
> diff --git a/include/dt-bindings/clock/stm32f4-clock.h b/include/dt-bindings/clock/stm32f4-clock.h
> index 56b8e10..1be4a3a 100644
> --- a/include/dt-bindings/clock/stm32f4-clock.h
> +++ b/include/dt-bindings/clock/stm32f4-clock.h
> @@ -27,7 +27,8 @@
> #define CLK_RTC 5
> #define PLL_VCO_I2S 6
> #define PLL_VCO_SAI 7
> +#define CLK_LCD 8
>
> -#define END_PRIMARY_CLK 8
> +#define END_PRIMARY_CLK 9
Do you really need this? Having this change could cause compatibility
problems between dtb and kernel versions.
Please restructure the patch series and put all of the binding changes
including this header into a single patch. Incrementally add s/w
features, not h/w.
Rob
^ permalink raw reply
* [linux-sunxi] Re: [RFC PATCH] ARM: dts: sun8i: add simplefb node for H3
From: Maxime Ripard @ 2016-11-30 20:52 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <185067972.ij8nq5Ea6J@jernej-laptop>
On Wed, Nov 30, 2016 at 09:41:26PM +0100, Jernej ?krabec wrote:
> > > > > The only
> > > > > code left from you is for DE2. HDMI stuff is basically copied from
> > > > > Rockhip
> > > > > driver (including EDID reading), TCON code is now reverted to the same
> > > > > as
> > > > > it is in sunxi_display.c. I think it is worth to take a look at EDID
> > > > > code
> > > > > and compare it.
> > > >
> > > > So is the TCON of DE 2.0 identical to the original TCON?
> > > >
> > > > If so, we should reuse sun4i-tcon ...
> > >
> > > Well, TCON is splitted in two parts (two base addresses), one for HDMI and
> > > one for TV. However, register offsets are same as before, so I guess
> > > driver reusage make sense. I think that there are few additional
> > > registers, but they can be ignored for simplefb.
> >
> > The TCON1 of the H3 is not usable (no ckock). Analog TV has its own
> > clock and I/O area.
> >
>
> True, H3 user manual can be misleading sometimes. But this doesn't change the
> fact that TCON0 has same register offsets with same meaning.
Then yes, we should definitely share the drivers too. So, in the end,
the only thing that is actually new is the display-engine?
Maxime
--
Maxime Ripard, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 801 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20161130/dbe6e562/attachment.sig>
^ permalink raw reply
* [PATCH v2 2/9] clk: stm32f4: Add PLL_I2S & PLL_SAI for STM32F429/469 boards
From: Rob Herring @ 2016-11-30 20:48 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1479998749-20358-3-git-send-email-gabriel.fernandez@st.com>
On Thu, Nov 24, 2016 at 03:45:42PM +0100, gabriel.fernandez at st.com wrote:
> From: Gabriel Fernandez <gabriel.fernandez@st.com>
>
> This patch introduces PLL_I2S and PLL_SAI.
> Vco clock of these PLLs can be modify by DT (only n multiplicator,
> m divider is still fixed by the boot-loader).
> Each PLL has 3 dividers. PLL should be off when we modify the rate.
>
> Signed-off-by: Gabriel Fernandez <gabriel.fernandez@st.com>
> ---
> .../devicetree/bindings/clock/st,stm32-rcc.txt | 2 +
> drivers/clk/clk-stm32f4.c | 342 ++++++++++++++++++++-
> include/dt-bindings/clock/stm32f4-clock.h | 4 +-
> 3 files changed, 332 insertions(+), 16 deletions(-)
Acked-by: Rob Herring <robh@kernel.org>
^ permalink raw reply
* [PATCH v2 1/9] clk: stm32f4: Update DT bindings documentation
From: Rob Herring @ 2016-11-30 20:47 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1479998749-20358-2-git-send-email-gabriel.fernandez@st.com>
On Thu, Nov 24, 2016 at 03:45:41PM +0100, gabriel.fernandez at st.com wrote:
> From: Gabriel Fernandez <gabriel.fernandez@st.com>
>
> Creation of dt include file for specific stm32f4 clocks.
> These specific clocks are not derived from system clock (SYSCLOCK)
> We should use index 1 to use these clocks in DT.
> e.g. <&rcc 1 CLK_LSI>
>
> Signed-off-by: Gabriel Fernandez <gabriel.fernandez@st.com>
> ---
> .../devicetree/bindings/clock/st,stm32-rcc.txt | 8 ++++++
> drivers/clk/clk-stm32f4.c | 9 +++++--
> include/dt-bindings/clock/stm32f4-clock.h | 31 ++++++++++++++++++++++
> 3 files changed, 46 insertions(+), 2 deletions(-)
> create mode 100644 include/dt-bindings/clock/stm32f4-clock.h
Acked-by: Rob Herring <robh@kernel.org>
^ permalink raw reply
* [PATCH v28 9/9] Documentation: dt: chosen properties for arm64 kdump
From: Rob Herring @ 2016-11-30 20:44 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161124171413.GE7452@e104818-lin.cambridge.arm.com>
On Thu, Nov 24, 2016 at 05:14:13PM +0000, Catalin Marinas wrote:
> On Thu, Nov 24, 2016 at 06:59:44PM +0900, AKASHI Takahiro wrote:
> > From: James Morse <james.morse@arm.com>
> >
> > Add documentation for
> > linux,crashkernel-base and crashkernel-size,
> > linux,usable-memory-range
> > linux,elfcorehdr
> > used by arm64 kdump to decribe the kdump reserved area, and
> > the elfcorehdr's location within it.
> >
> > Signed-off-by: James Morse <james.morse@arm.com>
> > [takahiro.akashi at linaro.org: added "linux,crashkernel-base" and "-size" ]
> > Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org>
> > Cc: devicetree at vger.kernel.org
> > Cc: Rob Herring <robh+dt@kernel.org>
> > Cc: Mark Rutland <mark.rutland@arm.com>
>
> Rob, Mark, are you ok with this patch?
I'm leaving this one to Mark.
Rob
^ permalink raw reply
* [linux-sunxi] Re: [RFC PATCH] ARM: dts: sun8i: add simplefb node for H3
From: Jernej Škrabec @ 2016-11-30 20:41 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161130203724.a390595df0199ed19069f91d@free.fr>
Dne sreda, 30. november 2016 ob 20:37:24 CET je Jean-Francois Moine
napisal(a):
> On Wed, 30 Nov 2016 20:14:11 +0100
>
> Jernej ?krabec <jernej.skrabec@gmail.com> wrote:
> > Dne ?etrtek, 01. december 2016 ob 03:03:14 CET je Icenowy Zheng
napisal(a):
> > > 2016?12?1? 02:49? Jernej Skrabec <jernej.skrabec@gmail.com>???
> > >
> > > > Hi Jean-Fran?ois,
> > > >
> > > > Dne sreda, 30. november 2016 10.35.08 UTC+1 je oseba Jean-Fran?ois
> > > > Moine
> >
> > napisala:
> > > >> On Tue, 29 Nov 2016 22:59:32 +0100
> > > >>
> > > >> Maxime Ripard <maxime...@free-electrons.com> wrote:
> > > >> > > > I'm still not sure which pipeline should I use.
> > > >> > > >
> > > >> > > > And, it seems that HDMI Slow Clock is not needed?
> > > >> > > >
> > > >> > > > (seems that it's only for EDID, but simplefb won't use EDID)
> > > >> > >
> > > >> > > So, I don't see how this may work.
> > > >> > > How can the u-boot know the resolutions of the HDMI display
> > > >> > > device?
> > > >> > >
> > > >> > > In other words: I have a new H3 board with the last u-boot and
> > > >> > > kernel.
> > > >> > > I plug my (rather old or brand new) HDMI display device.
> > > >> > > After powering on the system, I hope to get something on the
> > > >> > > screen.
> > > >> > > How?
> > > >> >
> > > >> > If it works like the driver for the first display engine in U-Boot,
> > > >> > it
> > > >> > will use the preferred mode reported by the EDID, and will fallback
> > > >> > to
> > > >> > 1024x768 if it cannot access it.
> > > >>
> > > >> Icenowy wrote: "simplefb won't use EDID"
> > > >>
> > > >> Then, if it is like in the kernel, the 1024x768 mode is VGA. It does
> > > >> not work with HDMI (different timings).
> > > >
> > > > U-Boot driver now accept any timings recommended by EDID. So far it
> > > > was tested with at least following resolutions:
> > > > - 1920x1080 @ 60 Hz
> > > > - 1280x1024 @ 60 Hz
> > > > - 1280x800 @ 60 Hz (slight clock difference)
> > > > - 800x480 (not sure about frame rate)
> > > > - 3840x2160 @ 30 Hz (4K)
> > >
> > > I tested on 1024x600 (If my memory is right, it's @ 60Hz)
> > >
> > > > and nobody complained so far. I'm pretty sure 1024x768 would work.
>
> Check the timings offered by the DRM core.
I'm not really familiar with DRM code, but my Linux laptop happily works with
1024x768 @ 75 Hz and other non CEA resolutions through HDMI, so I guess it
should be possible here too. Isn't function drm_add_edid_modes() designed
exactly for that?
Anyway, this is off topic for simplefb. Simplefb driver will just take over
framebuffer set up by U-Boot with some additional info like width, height,
pitch... It doesn't have to deal with HW directly.
>
> > > >> > Maybe it would be worth exchanging on the EDID code that has been
> > > >> > done
> > > >> > for the u-boot driver too, so that it can be fixed in your driver.
> > > >>
> > > >> The u-boot got my code, and, up to now, I could not fix the random or
> > > >> permanent failures of EDID reading in some boards.
> > > >
> > > > I only have one OPi2, but as I said, EDID always worked for me.
>
> Happy guy!
>
> > > > The only
> > > > code left from you is for DE2. HDMI stuff is basically copied from
> > > > Rockhip
> > > > driver (including EDID reading), TCON code is now reverted to the same
> > > > as
> > > > it is in sunxi_display.c. I think it is worth to take a look at EDID
> > > > code
> > > > and compare it.
> > >
> > > So is the TCON of DE 2.0 identical to the original TCON?
> > >
> > > If so, we should reuse sun4i-tcon ...
> >
> > Well, TCON is splitted in two parts (two base addresses), one for HDMI and
> > one for TV. However, register offsets are same as before, so I guess
> > driver reusage make sense. I think that there are few additional
> > registers, but they can be ignored for simplefb.
>
> The TCON1 of the H3 is not usable (no ckock). Analog TV has its own
> clock and I/O area.
>
True, H3 user manual can be misleading sometimes. But this doesn't change the
fact that TCON0 has same register offsets with same meaning.
> --
> Ken ar c'henta? | ** Breizh ha Linux atav! **
> Jef | http://moinejf.free.fr/
^ permalink raw reply
* [PATCH 3/3] arm64: dts: r8a7796: Add CAN FD support
From: Rob Herring @ 2016-11-30 20:37 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1479903288-2009-1-git-send-email-chris.paterson2@renesas.com>
On Wed, Nov 23, 2016 at 12:14:48PM +0000, Chris Paterson wrote:
> Adds CAN FD controller node for r8a7796.
>
> Based on a patch for r8a7795 by Ramesh Shanmugasundaram.
>
> Signed-off-by: Chris Paterson <chris.paterson2@renesas.com>
> ---
> .../devicetree/bindings/net/can/rcar_canfd.txt | 12 ++++++-----
> arch/arm64/boot/dts/renesas/r8a7796.dtsi | 24 ++++++++++++++++++++++
> 2 files changed, 31 insertions(+), 5 deletions(-)
Acked-by: Rob Herring <robh@kernel.org>
^ 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