* [PATCH] dma: Add Xilinx AXI Video Direct Memory Access Engine driver support
From: Arnd Bergmann @ 2014-01-20 11:39 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CA+mB=1L0ZSC8f6eMEuO7MEk6nG5SDahE7AH2F_uUr1TgTCD=cw@mail.gmail.com>
On Monday 20 January 2014, Srikanth Thokala wrote:
> On Fri, Jan 17, 2014 at 9:43 PM, Arnd Bergmann <arnd@arndb.de> wrote:
> > On Thursday 16 January 2014, Srikanth Thokala wrote:
> > I also assume that some of the properties should just go away:
> >
> > * xlnx,device-id should be the argument in the handle from the slave device
>
> We can have multiple instances of this VDMA IP configured in the FPGA and we
> need a unique identifier for each VDMA device that is present in the FPGA.
> This device-id dt parameter forms the filter mask for the slave devices. As an
> example, this can be used to get a channel of specific VDMA device (assuming
> multiple instances) using the API dma_request_channel(). Please note this
> is an example of a slave device that doesnt have dt node.
That is not a valid scenario: You should not try to support legacy
slave devices (without DT) connected to a dma-engine that is initialized
using DT. If you still in the progress of converting drivers to DT, you
can use auxdata to attach additional information that can be used for
those slave devices, but the code should be kept out of the mainline
kernel, and I don't want to see it manifest in the bindings.
> > * data width should be a property of the slave driver that is configured
> > through dma_slave_config(), unless you can have dma engines that only
> > support certain a width.
>
> Yes, this VDMA engine soft IP support only certain widths, which is
> configurable during IP synthesis.
But what is this property used for in that case? Surely you can't
connect a slave device to a dmaengine if the bus width doesn't match.
You probably have a point here, but I don't understand it yet.
Arnd
^ permalink raw reply
* commit 40d4511 "can: Disable flexcan driver build for big endian CPU on ARM" breaks Flexcan on ARM
From: Marc Kleine-Budde @ 2014-01-20 11:37 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20140120123257.573205a9@ipc1.ka-ro>
On 01/20/2014 12:32 PM, Lothar Wa?mann wrote:
> Hi,
>
> The commit 40d451181a7fa57e32bca4632ae7b22f80861a73
> |Author: Guenter Roeck <linux@roeck-us.net>
> |Date: Mon Jan 6 05:21:03 2014 -0800
> |
> | can: Disable flexcan driver build for big endian CPU on ARM
> |
> | Building arm:allmodconfig fails with
> |
> | flexcan.c: In function 'flexcan_read':
> | flexcan.c:243:2: error: implicit declaration of function 'in_be32'
> | flexcan.c: In function 'flexcan_write':
> | flexcan.c:248:2: error: implicit declaration of function 'out_be32'
> |
> | in_be32 and out_be32 do not (or no longer) exist for ARM targets.
> | Disable the build for ARM on big endian CPUs.
> |
> | Signed-off-by: Guenter Roeck <linux@roeck-us.net>
> | Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
> |
> |diff --git a/drivers/net/can/Kconfig b/drivers/net/can/Kconfig
> |index 9e7d95d..d447b88 100644
> |--- a/drivers/net/can/Kconfig
> |+++ b/drivers/net/can/Kconfig
> |@@ -104,7 +104,7 @@ config CAN_JANZ_ICAN3
> |
> | config CAN_FLEXCAN
> | tristate "Support for Freescale FLEXCAN based chips"
> |- depends on ARM || PPC
> |+ depends on (ARM && CPU_LITTLE_ENDIAN) || PPC
> | ---help---
> | Say Y here if you want to support for Freescale FlexCAN.
>>
> completely disables the flexcan driver for all ARM platforms, since the
> symbol CPU_LITTLE_ENDIAN does not exist on ARM!
Arnd Bergmann posted a better patch, which I'll include in a pull
request once the net tree is open again.
Marc
--
Pengutronix e.K. | Marc Kleine-Budde |
Industrial Linux Solutions | Phone: +49-231-2826-924 |
Vertretung West/Dortmund | Fax: +49-5121-206917-5555 |
Amtsgericht Hildesheim, HRA 2686 | http://www.pengutronix.de |
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 242 bytes
Desc: OpenPGP digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20140120/b60177fc/attachment-0001.sig>
^ permalink raw reply
* [PATCH v2] dma: imx-sdma: clarify firmare not found warning
From: Lothar Waßmann @ 2014-01-20 11:36 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20140120122840.36520f37@ipc1.ka-ro>
Hi,
Lothar Wa?mann wrote:
> Hi,
>
erroneously pressed the 'Send' button...
> Sascha Hauer wrote:
> > When a firmware cannot be found for the SDMA engine then we can
> > continue with the inernal ROM firmware.
> >
> > The meaning of this message is frequently asked for, so make clear
> > that the driver still works with the internal ROM firmware and reduce
> > the loglevel from err to info.
> >
In case user space firmware loading support (CONFIG_FW_LOADER) is
enabled, this message may still be inadequate, since the firmware may
very well be loaded lateron.
Lothar Wa?mann
--
___________________________________________________________
Ka-Ro electronics GmbH | Pascalstra?e 22 | D - 52076 Aachen
Phone: +49 2408 1402-0 | Fax: +49 2408 1402-10
Gesch?ftsf?hrer: Matthias Kaussen
Handelsregistereintrag: Amtsgericht Aachen, HRB 4996
www.karo-electronics.de | info at karo-electronics.de
___________________________________________________________
^ permalink raw reply
* commit 40d4511 "can: Disable flexcan driver build for big endian CPU on ARM" breaks Flexcan on ARM
From: Lothar Waßmann @ 2014-01-20 11:32 UTC (permalink / raw)
To: linux-arm-kernel
Hi,
The commit 40d451181a7fa57e32bca4632ae7b22f80861a73
|Author: Guenter Roeck <linux@roeck-us.net>
|Date: Mon Jan 6 05:21:03 2014 -0800
|
| can: Disable flexcan driver build for big endian CPU on ARM
|
| Building arm:allmodconfig fails with
|
| flexcan.c: In function 'flexcan_read':
| flexcan.c:243:2: error: implicit declaration of function 'in_be32'
| flexcan.c: In function 'flexcan_write':
| flexcan.c:248:2: error: implicit declaration of function 'out_be32'
|
| in_be32 and out_be32 do not (or no longer) exist for ARM targets.
| Disable the build for ARM on big endian CPUs.
|
| Signed-off-by: Guenter Roeck <linux@roeck-us.net>
| Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
|
|diff --git a/drivers/net/can/Kconfig b/drivers/net/can/Kconfig
|index 9e7d95d..d447b88 100644
|--- a/drivers/net/can/Kconfig
|+++ b/drivers/net/can/Kconfig
|@@ -104,7 +104,7 @@ config CAN_JANZ_ICAN3
|
| config CAN_FLEXCAN
| tristate "Support for Freescale FLEXCAN based chips"
|- depends on ARM || PPC
|+ depends on (ARM && CPU_LITTLE_ENDIAN) || PPC
| ---help---
| Say Y here if you want to support for Freescale FlexCAN.
>
completely disables the flexcan driver for all ARM platforms, since the
symbol CPU_LITTLE_ENDIAN does not exist on ARM!
Lothar Wa?mann
^ permalink raw reply
* [PATCH v3] xen: swiotlb: handle sizeof(dma_addr_t) != sizeof(phys_addr_t)
From: Ian Campbell @ 2014-01-20 11:30 UTC (permalink / raw)
To: linux-arm-kernel
The use of phys_to_machine and machine_to_phys in the phys<=>bus conversions
causes us to lose the top bits of the DMA address if the size of a DMA address is not the same as the size of the phyiscal address.
This can happen in practice on ARM where foreign pages can be above 4GB even
though the local kernel does not have LPAE page tables enabled (which is
totally reasonable if the guest does not itself have >4GB of RAM). In this
case the kernel still maps the foreign pages at a phys addr below 4G (as it
must) but the resulting DMA address (returned by the grant map operation) is
much higher.
This is analogous to a hardware device which has its view of RAM mapped up
high for some reason.
This patch makes I/O to foreign pages (specifically blkif) work on 32-bit ARM
systems with more than 4GB of RAM.
Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
Acked-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Cc: Russell King <linux@arm.linux.org.uk>
Cc: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Cc: linux-arm-kernel at lists.infradead.org
---
v3: Added Stefano's ack, added accidentally forgotten Ccs to Russell and l-a-k.
v2: Add comment on avoiding PFN_PHYS, and remove accidental truncation due to
it in xen_bus_to_phys.
---
arch/arm/Kconfig | 1 +
drivers/xen/swiotlb-xen.c | 22 ++++++++++++++++++++--
2 files changed, 21 insertions(+), 2 deletions(-)
diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
index c1f1a7e..24307dc 100644
--- a/arch/arm/Kconfig
+++ b/arch/arm/Kconfig
@@ -1885,6 +1885,7 @@ config XEN
depends on !GENERIC_ATOMIC64
select ARM_PSCI
select SWIOTLB_XEN
+ select ARCH_DMA_ADDR_T_64BIT
help
Say Y if you want to run Linux in a Virtual Machine on Xen on ARM.
diff --git a/drivers/xen/swiotlb-xen.c b/drivers/xen/swiotlb-xen.c
index 1eac073..ebd8f21 100644
--- a/drivers/xen/swiotlb-xen.c
+++ b/drivers/xen/swiotlb-xen.c
@@ -75,14 +75,32 @@ static unsigned long xen_io_tlb_nslabs;
static u64 start_dma_addr;
+/*
+ * Both of these functions should avoid PFN_PHYS because phys_addr_t
+ * can be 32bit when dma_addr_t is 64bit leading to a loss in
+ * information if the shift is done before casting to 64bit.
+ */
static inline dma_addr_t xen_phys_to_bus(phys_addr_t paddr)
{
- return phys_to_machine(XPADDR(paddr)).maddr;
+ unsigned long mfn = pfn_to_mfn(PFN_DOWN(paddr));
+ dma_addr_t dma = (dma_addr_t)mfn << PAGE_SHIFT;
+
+ dma |= paddr & ~PAGE_MASK;
+
+ return dma;
}
static inline phys_addr_t xen_bus_to_phys(dma_addr_t baddr)
{
- return machine_to_phys(XMADDR(baddr)).paddr;
+ unsigned long pfn = mfn_to_pfn(PFN_DOWN(baddr));
+ dma_addr_t dma = (dma_addr_t)pfn << PAGE_SHIFT;
+ phys_addr_t paddr = dma;
+
+ BUG_ON(paddr != dma); /* truncation has occurred, should never happen */
+
+ paddr |= baddr & ~PAGE_MASK;
+
+ return paddr;
}
static inline dma_addr_t xen_virt_to_bus(void *address)
--
1.7.10.4
^ permalink raw reply related
* [PATCH v2] dma: imx-sdma: clarify firmare not found warning
From: Lothar Waßmann @ 2014-01-20 11:28 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1390212438-6855-1-git-send-email-s.hauer@pengutronix.de>
Hi,
Sascha Hauer wrote:
> When a firmware cannot be found for the SDMA engine then we can
> continue with the inernal ROM firmware.
>
> The meaning of this message is frequently asked for, so make clear
> that the driver still works with the internal ROM firmware and reduce
> the loglevel from err to info.
>
In case user space firmware loading
> Signed-off-by: Sascha Hauer <s.hauer@pengutronix.de>
> Cc: Vinod Koul <vinod.koul@intel.com>
> Cc: linux-arm-kernel at lists.infradead.org
> Cc: Shawn Guo <shawn.guo@linaro.org>
> ---
>
> changes since v1:
> - instead of removing the message make it more clear
>
> drivers/dma/imx-sdma.c | 5 ++++-
> 1 file changed, 4 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/dma/imx-sdma.c b/drivers/dma/imx-sdma.c
> index c75679d..d79eaad 100644
> --- a/drivers/dma/imx-sdma.c
> +++ b/drivers/dma/imx-sdma.c
> @@ -1259,7 +1259,10 @@ static void sdma_load_firmware(const struct firmware *fw, void *context)
> unsigned short *ram_code;
>
> if (!fw) {
> - dev_err(sdma->dev, "firmware not found\n");
> + dev_info(sdma->dev, "external firmware not found, using ROM firmware\n");
> + /*
> + * In this case we just use the ROM firmware.
> + */
> return;
> }
>
--
___________________________________________________________
Ka-Ro electronics GmbH | Pascalstra?e 22 | D - 52076 Aachen
Phone: +49 2408 1402-0 | Fax: +49 2408 1402-10
Gesch?ftsf?hrer: Matthias Kaussen
Handelsregistereintrag: Amtsgericht Aachen, HRB 4996
www.karo-electronics.de | info at karo-electronics.de
___________________________________________________________
^ permalink raw reply
* [PATCH] dma: fix vchan_cookie_complete() debug print
From: Russell King - ARM Linux @ 2014-01-20 11:28 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20140120095917.GZ26823@intel.com>
On Mon, Jan 20, 2014 at 03:29:17PM +0530, Vinod Koul wrote:
> On Fri, Dec 06, 2013 at 04:42:09PM +0100, Jonas Jensen wrote:
> > vd->tx.cookie is set zero on dma_cookie_complete(),
> > save to local before printing it.
> >
> > Signed-off-by: Jonas Jensen <jonas.jensen@gmail.com>
> > ---
> >
> > Notes:
> > dev_vdbg() could also be moved to happen earlier, what do you prefer?
> This would be preferred IMHO. Also pls cc dmaengine at vger on this
I prefer this version - it means that the verbose debug printk doesn't
impact the completion timing when printk is expensive (eg, because its
outputting via a serial port.)
--
FTTC broadband for 0.8mile line: 5.8Mbps down 500kbps up. Estimation
in database were 13.1 to 19Mbit for a good line, about 7.5+ for a bad.
Estimate before purchase was "up to 13.2Mbit".
^ permalink raw reply
* [PATCH 13/15] fbdev: sh-mobile-lcdcfb: Enable driver compilation with COMPILE_TEST
From: Tomi Valkeinen @ 2014-01-20 11:21 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <22423852.GiH1NBjiii@avalon>
On 2014-01-19 23:01, Laurent Pinchart wrote:
> Hi Tomi,
> The lcdc driver can be compiled without meram support. This is handled by
> conditional compilation in include/video/sh_mobile_meram.h that defines the
> meram functions as stubs when meram support isn't selected.
>
> The problem comes from the combination of FB_SH_MOBILE_MERAM=m and
> FB_SH_MOBILE_LCDC=y. The former makes the meram function non-stubs, while the
> later makes the LCDC driver fail to link, as meram support is then compiled as
> a module.
>
> How do you usually handle this ?
I guess the easiest option is to make FB_SH_MOBILE_MERAM a bool, instead
of tristate.
Tomi
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 901 bytes
Desc: OpenPGP digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20140120/6d5866fc/attachment.sig>
^ permalink raw reply
* [PATCH v5 0/4] Fix i2c bus hang on A0 version of the Armada XP SoCs
From: Gregory CLEMENT @ 2014-01-20 11:20 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <52D4F966.6060200@free-electrons.com>
On 14/01/2014 09:46, Gregory CLEMENT wrote:
> On 14/01/2014 03:14, Jason Cooper wrote:
>> Gregory,
>>
>> On Wed, Jan 08, 2014 at 04:06:25PM +0100, Gregory CLEMENT wrote:
>>> Hi,
>>>
>>> Here come the 5th version of the series fixing the i2c bus hang on A0
>>> version of the Armada XP SoCs. It occurred on the early release of the
>>> OpenBlocks AX3-4 boards. Indeed the first variants of Armada XP SoCs
>>> (A0 stepping) have issues related to the i2c controller which prevent
>>> to use the offload mechanism and lead to a kernel hang during boot.
>>>
>>> The main change are the use of marvell,mv78230-a0-i2c and that the
>>> function mvebu_get_soc_id() is now local to mach-mvebu.
>>>
>>> The first patch add a mean to detect the SoCs version at run-time and
>>> the second one use this feature in the driver.
>>>
>>> The 3 first patches should be applied on 3.13-rc and on stable kernel
>>> 3.12 as it fixes a regression introduce by the commit 930ab3d403ae
>>> "i2c: mv64xxx: Add I2C Transaction Generator support".
>>
>> Ok, I've pulled this in by cherrypicking the commits. I needed to add
>> the 'Fixes: ...' and 'Cc: stable ...' language, so the commit ids were
>> going to change anyhow. I also added the note to the binding as we
>> discussed. I've also based this against v3.13-rc1 as there doesn't
>> appear to be any need to drag in everything up to -rc6.
>>
>> I've pushed this to mvebu/fixes. Please take a look. If it all looks
>> good I'll send the pull request off tomorrow.
> Hi Jason,
>
> Everything looks perfect!
>
> Thanks for having improved it,
>
> Gregory
>
Hi Jason,
Eventually we didn't finish with it!
Ezequiel found an issue when we try to access pci_base if it have
not been properly mapped, in this case the kernel hang. Indeed the check
of the return of of_iomap was wrong.
The fix would be something like:
-o<---o<---o<---o<---o<---o<---o<---o<---o<---o<---o<--
--- a/arch/arm/mach-mvebu/mvebu-soc-id.c
+++ b/arch/arm/mach-mvebu/mvebu-soc-id.c
@@ -88,7 +88,7 @@ static int __init mvebu_soc_id_init(void)
}
pci_base = of_iomap(child, 0);
- if (IS_ERR(pci_base)) {
+ if (pci_base == NULL) {
pr_err("cannot map registers\n");
ret = -ENOMEM;
goto res_ioremap;
-o<---o<---o<---o<---o<---o<---o<---o<---o<---o<---o<--
How do you want we handle it?
Do you want a proper patch to amend?
A new series?
Something else?
Thanks,
Gregory
>>
>> thx,
>>
>> Jason.
>>
>> _______________________________________________
>> linux-arm-kernel mailing list
>> linux-arm-kernel at lists.infradead.org
>> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
>>
>
>
--
Gregory Clement, Free Electrons
Kernel, drivers, real-time and embedded Linux
development, consulting, training and support.
http://free-electrons.com
^ permalink raw reply
* [PATCH v3 7/7] net: moxa: use eth_mac_addr()
From: Jonas Jensen @ 2014-01-20 11:13 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1390216399-27028-1-git-send-email-jonas.jensen@gmail.com>
Replace boilerplate in moxart_set_mac_address() with eth_mac_addr().
Signed-off-by: Jonas Jensen <jonas.jensen@gmail.com>
---
Notes:
Applies to next-20140120
drivers/net/ethernet/moxa/moxart_ether.c | 7 +------
1 file changed, 1 insertion(+), 6 deletions(-)
diff --git a/drivers/net/ethernet/moxa/moxart_ether.c b/drivers/net/ethernet/moxa/moxart_ether.c
index 0f25f4dc..8378be9 100644
--- a/drivers/net/ethernet/moxa/moxart_ether.c
+++ b/drivers/net/ethernet/moxa/moxart_ether.c
@@ -56,12 +56,7 @@ static void moxart_update_mac_address(struct net_device *ndev)
static int moxart_set_mac_address(struct net_device *ndev, void *addr)
{
- struct sockaddr *address = addr;
-
- if (!is_valid_ether_addr(address->sa_data))
- return -EADDRNOTAVAIL;
-
- memcpy(ndev->dev_addr, address->sa_data, ndev->addr_len);
+ eth_mac_addr(ndev, addr);
moxart_update_mac_address(ndev);
return 0;
--
1.8.2.1
^ permalink raw reply related
* [PATCH v3 6/7] net: moxa: generate random address
From: Jonas Jensen @ 2014-01-20 11:13 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1390216399-27028-1-git-send-email-jonas.jensen@gmail.com>
The address register is zero:ed on boot, fill it with a randomly generated
address on probe.
Signed-off-by: Jonas Jensen <jonas.jensen@gmail.com>
---
Notes:
Applies to next-20140120
drivers/net/ethernet/moxa/moxart_ether.c | 6 ++++++
1 file changed, 6 insertions(+)
diff --git a/drivers/net/ethernet/moxa/moxart_ether.c b/drivers/net/ethernet/moxa/moxart_ether.c
index 6df372f..0f25f4dc 100644
--- a/drivers/net/ethernet/moxa/moxart_ether.c
+++ b/drivers/net/ethernet/moxa/moxart_ether.c
@@ -740,6 +740,12 @@ static int moxart_mac_probe(struct platform_device *pdev)
goto init_fail;
}
+ if (!is_valid_ether_addr(ndev->dev_addr)) {
+ eth_hw_addr_random(ndev);
+ netdev_info(ndev, "generated random MAC address %pM\n",
+ ndev->dev_addr);
+ }
+
netdev_dbg(ndev, "%s: IRQ=%d address=%pM\n",
__func__, ndev->irq, ndev->dev_addr);
--
1.8.2.1
^ permalink raw reply related
* [PATCH v3 5/7] net: moxa: add IFF_LIVE_ADDR_CHANGE flag
From: Jonas Jensen @ 2014-01-20 11:13 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1390216399-27028-1-git-send-email-jonas.jensen@gmail.com>
.ndo_set_mac_address hook callback already supports IFF_LIVE_ADDR_CHANGE
so add it to our flags.
Signed-off-by: Jonas Jensen <jonas.jensen@gmail.com>
---
Notes:
Applies to next-20140120
drivers/net/ethernet/moxa/moxart_ether.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/net/ethernet/moxa/moxart_ether.c b/drivers/net/ethernet/moxa/moxart_ether.c
index ca892bb..6df372f 100644
--- a/drivers/net/ethernet/moxa/moxart_ether.c
+++ b/drivers/net/ethernet/moxa/moxart_ether.c
@@ -728,7 +728,7 @@ static int moxart_mac_probe(struct platform_device *pdev)
ether_setup(ndev);
ndev->netdev_ops = &moxart_netdev_ops;
netif_napi_add(ndev, &priv->napi, moxart_rx_poll, RX_DESC_NUM);
- ndev->priv_flags |= IFF_UNICAST_FLT;
+ ndev->priv_flags |= IFF_UNICAST_FLT | IFF_LIVE_ADDR_CHANGE;
ndev->irq = irq;
SET_NETDEV_DEV(ndev, &pdev->dev);
--
1.8.2.1
^ permalink raw reply related
* [PATCH v3 4/7] net: moxa: add ethtool support
From: Jonas Jensen @ 2014-01-20 11:13 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1390216399-27028-1-git-send-email-jonas.jensen@gmail.com>
Add and assign ethtool_ops callback functions.
Signed-off-by: Jonas Jensen <jonas.jensen@gmail.com>
---
Notes:
Applies to next-20140120
drivers/net/ethernet/moxa/moxart_ether.c | 121 +++++++++++++++++++++++++++++++
1 file changed, 121 insertions(+)
diff --git a/drivers/net/ethernet/moxa/moxart_ether.c b/drivers/net/ethernet/moxa/moxart_ether.c
index c19bff2..ca892bb 100644
--- a/drivers/net/ethernet/moxa/moxart_ether.c
+++ b/drivers/net/ethernet/moxa/moxart_ether.c
@@ -31,6 +31,10 @@
#include "moxart_ether.h"
+#define DRV_NAME "moxart-ethernet"
+#define DRV_VERSION "0.2"
+#define MOXART_NUM_STATS ARRAY_SIZE(ethtool_stats_keys)
+
static inline void moxart_emac_write(struct net_device *ndev,
unsigned int reg, unsigned long value)
{
@@ -63,6 +67,122 @@ static int moxart_set_mac_address(struct net_device *ndev, void *addr)
return 0;
}
+static struct {
+ const char str[ETH_GSTRING_LEN];
+} ethtool_stats_keys[] = {
+ { "tx_ok_mcol_2to15" },
+ { "tx_ok_1col" },
+ { "rx_frame_pause" },
+ { "frame_align_err" },
+ { "err_col_late_16" },
+ { "err_col_16" },
+ { "rx_runt" },
+ { "late_col" },
+ { "crc_err" },
+ { "rx_ftl" },
+ { "rx_fifo_full" },
+ { "rx_col" },
+ { "rx_bcast" },
+ { "rx_mcast" },
+ { "rx_ok" },
+ { "tx_ok" },
+};
+
+static void moxart_get_drvinfo(struct net_device *ndev,
+ struct ethtool_drvinfo *info)
+{
+ strlcpy(info->driver, DRV_NAME, sizeof(info->driver));
+ strlcpy(info->version, DRV_VERSION, sizeof(info->version));
+ strlcpy(info->bus_info, dev_name(&ndev->dev), sizeof(info->bus_info));
+}
+
+static int moxart_get_settings(struct net_device *ndev, struct ethtool_cmd *cmd)
+{
+ struct moxart_mac_priv_t *priv = netdev_priv(ndev);
+
+ return phy_ethtool_gset(priv->phy_dev, cmd);
+}
+
+static int moxart_set_settings(struct net_device *ndev, struct ethtool_cmd *cmd)
+{
+ struct moxart_mac_priv_t *priv = netdev_priv(ndev);
+
+ return phy_ethtool_sset(priv->phy_dev, cmd);
+}
+
+static int moxart_nway_reset(struct net_device *ndev)
+{
+ struct moxart_mac_priv_t *priv = netdev_priv(ndev);
+
+ return genphy_restart_aneg(priv->phy_dev);
+}
+
+static void moxart_get_ethtool_stats(struct net_device *ndev,
+ struct ethtool_stats *estats,
+ u64 *tmp_stats)
+{
+ struct moxart_mac_priv_t *priv = netdev_priv(ndev);
+ u32 s;
+ int i = 0;
+
+ s = readl(priv->base + REG_TX_COL_COUNTER);
+ tmp_stats[i++] = s & 0xffff0000;
+ tmp_stats[i++] = s & 0x0000ffff;
+ s = readl(priv->base + REG_RPF_AEP_COUNTER);
+ tmp_stats[i++] = s & 0xffff0000;
+ tmp_stats[i++] = s & 0x0000ffff;
+ s = readl(priv->base + REG_XM_PG_COUNTER);
+ tmp_stats[i++] = s & 0xffff0000;
+ tmp_stats[i++] = s & 0x0000ffff;
+ s = readl(priv->base + REG_RUNT_TLC_COUNTER);
+ tmp_stats[i++] = s & 0xffff0000;
+ tmp_stats[i++] = s & 0x0000ffff;
+ s = readl(priv->base + REG_CRC_FTL_COUNTER);
+ tmp_stats[i++] = s & 0xffff0000;
+ tmp_stats[i++] = s & 0x0000ffff;
+ s = readl(priv->base + REG_RLC_RCC_COUNTER);
+ tmp_stats[i++] = s & 0xffff0000;
+ tmp_stats[i++] = s & 0x0000ffff;
+ tmp_stats[i++] = readl(priv->base + REG_BROC_COUNTER);
+ tmp_stats[i++] = readl(priv->base + REG_MULCA_COUNTER);
+ tmp_stats[i++] = readl(priv->base + REG_XP_COUNTER);
+ tmp_stats[i++] = readl(priv->base + REG_RP_COUNTER);
+}
+
+static int moxart_get_sset_count(struct net_device *netdev,
+ int string_set)
+{
+ switch (string_set) {
+ case ETH_SS_STATS:
+ return MOXART_NUM_STATS;
+ default:
+ return -EINVAL;
+ }
+}
+
+static void moxart_get_strings(struct net_device *dev, u32 stringset, u8 *data)
+{
+ switch (stringset) {
+ case ETH_SS_STATS:
+ memcpy(data, ðtool_stats_keys, sizeof(ethtool_stats_keys));
+ break;
+ default:
+ WARN_ON(1);
+ break;
+ }
+}
+
+static const struct ethtool_ops moxart_ethtool_ops = {
+ .set_settings = moxart_set_settings,
+ .get_settings = moxart_get_settings,
+ .get_drvinfo = moxart_get_drvinfo,
+ .nway_reset = moxart_nway_reset,
+ .get_link = ethtool_op_get_link,
+ .get_ethtool_stats = moxart_get_ethtool_stats,
+ .get_sset_count = moxart_get_sset_count,
+ .get_strings = moxart_get_strings,
+};
+
static int moxart_do_ioctl(struct net_device *ndev, struct ifreq *ir, int cmd)
{
struct moxart_mac_priv_t *priv = netdev_priv(ndev);
@@ -612,6 +732,7 @@ static int moxart_mac_probe(struct platform_device *pdev)
ndev->irq = irq;
SET_NETDEV_DEV(ndev, &pdev->dev);
+ SET_ETHTOOL_OPS(ndev, &moxart_ethtool_ops);
ret = register_netdev(ndev);
if (ret) {
--
1.8.2.1
^ permalink raw reply related
* [PATCH v3 3/7] net: moxa: connect to PHY
From: Jonas Jensen @ 2014-01-20 11:13 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1390216399-27028-1-git-send-email-jonas.jensen@gmail.com>
The kernel now has a MDIO bus driver and a phy_driver (RTL8201CP),
connect to this PHY using OF.
Signed-off-by: Jonas Jensen <jonas.jensen@gmail.com>
---
Notes:
Applies to next-20140120
.../devicetree/bindings/net/moxa,moxart-mac.txt | 47 ++++++++++-
drivers/net/ethernet/moxa/moxart_ether.c | 92 +++++++++++++++++++++-
drivers/net/ethernet/moxa/moxart_ether.h | 2 +
3 files changed, 138 insertions(+), 3 deletions(-)
diff --git a/Documentation/devicetree/bindings/net/moxa,moxart-mac.txt b/Documentation/devicetree/bindings/net/moxa,moxart-mac.txt
index 583418b..94c1f3b 100644
--- a/Documentation/devicetree/bindings/net/moxa,moxart-mac.txt
+++ b/Documentation/devicetree/bindings/net/moxa,moxart-mac.txt
@@ -1,21 +1,64 @@
MOXA ART Ethernet Controller
+Integrated MDIO bus node:
+
+- compatible: "moxa,moxart-mdio"
+- Inherits from MDIO bus node binding[1]
+
+[1] Documentation/devicetree/bindings/net/phy.txt
+
+
+Ethernet node:
+
Required properties:
- compatible : Must be "moxa,moxart-mac"
- reg : Should contain register location and length
- interrupts : Should contain the mac interrupt number
+Optional Properties:
+
+- phy-handle : the phandle to a PHY node
+
+
Example:
+ mdio0: mdio at 90900090 {
+ compatible = "moxa,moxart-mdio";
+ reg = <0x90900090 0x8>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ ethphy0: ethernet-phy at 1 {
+ device_type = "ethernet-phy";
+ compatible = "moxa,moxart-rtl8201cp", "ethernet-phy-ieee802.3-c22";
+ reg = <1>;
+ };
+ };
+
+ mdio1: mdio at 92000090 {
+ compatible = "moxa,moxart-mdio";
+ reg = <0x92000090 0x8>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ ethphy1: ethernet-phy at 1 {
+ device_type = "ethernet-phy";
+ compatible = "moxa,moxart-rtl8201cp", "ethernet-phy-ieee802.3-c22";
+ reg = <1>;
+ };
+ };
+
mac0: mac at 90900000 {
compatible = "moxa,moxart-mac";
- reg = <0x90900000 0x100>;
+ reg = <0x90900000 0x90>;
interrupts = <25 0>;
+ phy-handle = <ðphy0>;
};
mac1: mac at 92000000 {
compatible = "moxa,moxart-mac";
- reg = <0x92000000 0x100>;
+ reg = <0x92000000 0x90>;
interrupts = <27 0>;
+ phy-handle = <ðphy1>;
};
diff --git a/drivers/net/ethernet/moxa/moxart_ether.c b/drivers/net/ethernet/moxa/moxart_ether.c
index 17c9f0e..c19bff2 100644
--- a/drivers/net/ethernet/moxa/moxart_ether.c
+++ b/drivers/net/ethernet/moxa/moxart_ether.c
@@ -25,6 +25,9 @@
#include <linux/of_irq.h>
#include <linux/crc32.h>
#include <linux/crc32c.h>
+#include <linux/phy.h>
+#include <linux/of_mdio.h>
+#include <linux/of_net.h>
#include "moxart_ether.h"
@@ -60,6 +63,16 @@ static int moxart_set_mac_address(struct net_device *ndev, void *addr)
return 0;
}
+static int moxart_do_ioctl(struct net_device *ndev, struct ifreq *ir, int cmd)
+{
+ struct moxart_mac_priv_t *priv = netdev_priv(ndev);
+
+ if (!netif_running(ndev))
+ return -EINVAL;
+
+ return phy_mii_ioctl(priv->phy_dev, ir, cmd);
+}
+
static void moxart_mac_free_memory(struct net_device *ndev)
{
struct moxart_mac_priv_t *priv = netdev_priv(ndev);
@@ -109,6 +122,19 @@ static void moxart_mac_enable(struct net_device *ndev)
writel(priv->reg_maccr, priv->base + REG_MAC_CTRL);
}
+static void moxart_mac_update_duplex(struct net_device *ndev)
+{
+ struct moxart_mac_priv_t *priv = netdev_priv(ndev);
+
+ priv->reg_maccr &= ~(FULLDUP | ENRX_IN_HALFTX);
+ if (priv->duplex)
+ priv->reg_maccr |= FULLDUP;
+ else
+ priv->reg_maccr |= ENRX_IN_HALFTX;
+
+ writel(priv->reg_maccr, priv->base + REG_MAC_CTRL);
+}
+
static void moxart_mac_setup_desc_ring(struct net_device *ndev)
{
struct moxart_mac_priv_t *priv = netdev_priv(ndev);
@@ -168,6 +194,9 @@ static int moxart_mac_open(struct net_device *ndev)
moxart_update_mac_address(ndev);
moxart_mac_setup_desc_ring(ndev);
moxart_mac_enable(ndev);
+
+ phy_start(priv->phy_dev);
+
netif_start_queue(ndev);
netdev_dbg(ndev, "%s: IMR=0x%x, MACCR=0x%x\n",
@@ -183,6 +212,8 @@ static int moxart_mac_stop(struct net_device *ndev)
napi_disable(&priv->napi);
+ phy_stop(priv->phy_dev);
+
netif_stop_queue(ndev);
/* disable all interrupts */
@@ -435,12 +466,49 @@ static struct net_device_ops moxart_netdev_ops = {
.ndo_set_mac_address = moxart_set_mac_address,
.ndo_validate_addr = eth_validate_addr,
.ndo_change_mtu = eth_change_mtu,
+ .ndo_do_ioctl = moxart_do_ioctl,
};
+static void moxart_adjust_link(struct net_device *ndev)
+{
+ struct moxart_mac_priv_t *priv = netdev_priv(ndev);
+ unsigned long flags;
+ int status_change = 0;
+
+ if (priv->phy_dev->link) {
+ if (priv->speed != priv->phy_dev->speed) {
+ priv->speed = priv->phy_dev->speed;
+ status_change = 1;
+ }
+
+ if (priv->duplex != priv->phy_dev->duplex) {
+ spin_lock_irqsave(&priv->txlock, flags);
+
+ priv->duplex = priv->phy_dev->duplex;
+ moxart_mac_update_duplex(ndev);
+
+ spin_unlock_irqrestore(&priv->txlock, flags);
+ status_change = 1;
+ }
+ }
+
+ if (priv->link != priv->phy_dev->link) {
+ if (!priv->phy_dev->link) {
+ priv->speed = 0;
+ priv->duplex = -1;
+ }
+ priv->link = priv->phy_dev->link;
+ status_change = 1;
+ }
+
+ if (status_change)
+ phy_print_status(priv->phy_dev);
+}
+
static int moxart_mac_probe(struct platform_device *pdev)
{
struct device *p_dev = &pdev->dev;
- struct device_node *node = p_dev->of_node;
+ struct device_node *node = p_dev->of_node, *phy_node;
struct net_device *ndev;
struct moxart_mac_priv_t *priv;
struct resource *res;
@@ -461,6 +529,28 @@ static int moxart_mac_probe(struct platform_device *pdev)
priv = netdev_priv(ndev);
priv->ndev = ndev;
+ priv->link = 0;
+ priv->speed = 0;
+ priv->duplex = -1;
+
+ phy_node = of_parse_phandle(node, "phy-handle", 0);
+ if (!phy_node) {
+ dev_err(p_dev, "of_parse_phandle failed\n");
+ ret = -ENODEV;
+ goto init_fail;
+ }
+
+ if (phy_node) {
+ priv->phy_dev = of_phy_connect(priv->ndev, phy_node,
+ &moxart_adjust_link,
+ 0, of_get_phy_mode(node));
+ if (!priv->phy_dev) {
+ dev_err(p_dev, "of_phy_connect failed\n");
+ ret = -ENODEV;
+ goto init_fail;
+ }
+ }
+
res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
ndev->base_addr = res->start;
priv->base = devm_ioremap_resource(p_dev, res);
diff --git a/drivers/net/ethernet/moxa/moxart_ether.h b/drivers/net/ethernet/moxa/moxart_ether.h
index 2be9280..b8877bf 100644
--- a/drivers/net/ethernet/moxa/moxart_ether.h
+++ b/drivers/net/ethernet/moxa/moxart_ether.h
@@ -297,6 +297,8 @@ struct moxart_mac_priv_t {
unsigned int reg_imr;
struct napi_struct napi;
struct net_device *ndev;
+ struct phy_device *phy_dev;
+ int speed, duplex, link;
dma_addr_t rx_base;
dma_addr_t rx_mapping[RX_DESC_NUM];
--
1.8.2.1
^ permalink raw reply related
* [PATCH v3 2/7] net: moxa: fix build_skb() memory corruption
From: Jonas Jensen @ 2014-01-20 11:13 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1390216399-27028-1-git-send-email-jonas.jensen@gmail.com>
DMA buffer memory must be synchronized and copied before passing skb to
napi_gro_receive(). The use of build_skb() can lead to memory corruption,
replace it with netdev_alloc_skb_ip_align() and memcpy().
Addresses https://bugzilla.kernel.org/show_bug.cgi?id=69041
Signed-off-by: Jonas Jensen <jonas.jensen@gmail.com>
---
Notes:
This fixes the following error on wget download (or ncftp),
usually after only a few seconds:
"read error: Bad address"
On receiving this error, wget exits. The download is not resumed (busybox default).
Applies to next-20140120
drivers/net/ethernet/moxa/moxart_ether.c | 13 ++++++++++---
1 file changed, 10 insertions(+), 3 deletions(-)
diff --git a/drivers/net/ethernet/moxa/moxart_ether.c b/drivers/net/ethernet/moxa/moxart_ether.c
index aa45607..17c9f0e 100644
--- a/drivers/net/ethernet/moxa/moxart_ether.c
+++ b/drivers/net/ethernet/moxa/moxart_ether.c
@@ -226,14 +226,21 @@ static int moxart_rx_poll(struct napi_struct *napi, int budget)
if (len > RX_BUF_SIZE)
len = RX_BUF_SIZE;
- skb = build_skb(priv->rx_buf[rx_head], priv->rx_buf_size);
+ dma_sync_single_for_cpu(&ndev->dev,
+ priv->rx_mapping[rx_head],
+ priv->rx_buf_size, DMA_FROM_DEVICE);
+ skb = netdev_alloc_skb_ip_align(ndev, len);
if (unlikely(!skb)) {
- net_dbg_ratelimited("build_skb failed\n");
+ net_dbg_ratelimited("netdev_alloc_skb_ip_align failed\n");
priv->stats.rx_dropped++;
priv->stats.rx_errors++;
}
-
+ memcpy(skb->data, priv->rx_buf[rx_head], len);
skb_put(skb, len);
+ dma_sync_single_for_device(&ndev->dev,
+ priv->rx_mapping[rx_head],
+ priv->rx_buf_size, DMA_FROM_DEVICE);
+
skb->protocol = eth_type_trans(skb, ndev);
napi_gro_receive(&priv->napi, skb);
rx++;
--
1.8.2.1
^ permalink raw reply related
* [PATCH v3 1/7] net: moxa: clear TX descriptor length bits between sends
From: Jonas Jensen @ 2014-01-20 11:13 UTC (permalink / raw)
To: linux-arm-kernel
Add TX_DESC1_BUF_SIZE_MASK to bits that are cleared, before the TX buffer
length is set. Failing to do so can cause the controller to drop dead
i.e. all TX interrupts stop, resulting in complete communication failure.
Addresses https://bugzilla.kernel.org/show_bug.cgi?id=69031
Signed-off-by: Jonas Jensen <jonas.jensen@gmail.com>
---
Notes:
Applies to next-20140120
drivers/net/ethernet/moxa/moxart_ether.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/net/ethernet/moxa/moxart_ether.c b/drivers/net/ethernet/moxa/moxart_ether.c
index 5020fd4..aa45607 100644
--- a/drivers/net/ethernet/moxa/moxart_ether.c
+++ b/drivers/net/ethernet/moxa/moxart_ether.c
@@ -348,7 +348,8 @@ static int moxart_mac_start_xmit(struct sk_buff *skb, struct net_device *ndev)
txdes1 = readl(desc + TX_REG_OFFSET_DESC1);
txdes1 |= TX_DESC1_LTS | TX_DESC1_FTS;
- txdes1 &= ~(TX_DESC1_FIFO_COMPLETE | TX_DESC1_INTR_COMPLETE);
+ txdes1 &= ~(TX_DESC1_FIFO_COMPLETE | TX_DESC1_INTR_COMPLETE |
+ TX_DESC1_BUF_SIZE_MASK);
txdes1 |= (len & TX_DESC1_BUF_SIZE_MASK);
writel(txdes1, desc + TX_REG_OFFSET_DESC1);
writel(TX_DESC0_DMA_OWN, desc + TX_REG_OFFSET_DESC0);
--
1.8.2.1
^ permalink raw reply related
* [PATCHv10 2/2] dma: Add Freescale eDMA engine driver support
From: Jingchang Lu @ 2014-01-20 11:05 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20140120093541.GX26823@intel.com>
> -----Original Message-----
> From: Vinod Koul [mailto:vinod.koul at intel.com]
> Sent: Monday, January 20, 2014 5:36 PM
> To: Lu Jingchang-B35083
> Cc: dan.j.williams at intel.com; arnd at arndb.de; shawn.guo at linaro.org;
> pawel.moll at arm.com; mark.rutland at arm.com; swarren at wwwdotorg.org; linux-
> kernel at vger.kernel.org; linux-arm-kernel at lists.infradead.org;
> devicetree at vger.kernel.org; Wang Huan-B18965
> Subject: Re: [PATCHv10 2/2] dma: Add Freescale eDMA engine driver support
>
> On Mon, Jan 20, 2014 at 09:06:43AM +0000, Jingchang Lu wrote:
> >
> >
> > > -----Original Message-----
> > > From: Vinod Koul [mailto:vinod.koul at intel.com]
> > > Sent: Monday, January 20, 2014 3:40 PM
> > > To: Lu Jingchang-B35083
> > > Cc: dan.j.williams at intel.com; arnd at arndb.de; shawn.guo at linaro.org;
> > > pawel.moll at arm.com; mark.rutland at arm.com; swarren at wwwdotorg.org;
> linux-
> > > kernel at vger.kernel.org; linux-arm-kernel at lists.infradead.org;
> > > devicetree at vger.kernel.org; Wang Huan-B18965
> > > Subject: Re: [PATCHv10 2/2] dma: Add Freescale eDMA engine driver
> support
> > >
> > > On Fri, Jan 17, 2014 at 02:04:44PM +0800, Jingchang Lu wrote:
> > > > Add Freescale enhanced direct memory(eDMA) controller support.
> > > > This module can be found on Vybrid and LS-1 SoCs.
> > > >
> > > > Signed-off-by: Alison Wang <b18965@freescale.com>
> > > > Signed-off-by: Jingchang Lu <b35083@freescale.com>
> > > > Acked-by: Arnd Bergmann <arnd@arndb.de>
> > > > ---
> > >
> > > > +static int fsl_edma_control(struct dma_chan *chan, enum
> dma_ctrl_cmd
> > > cmd,
> > > > + unsigned long arg)
> > > > +{
> > > > + struct fsl_edma_chan *fsl_chan = to_fsl_edma_chan(chan);
> > > > + struct dma_slave_config *cfg = (void *)arg;
> > > > + unsigned long flags;
> > > > + LIST_HEAD(head);
> > > > +
> > > > + switch (cmd) {
> > > > + case DMA_TERMINATE_ALL:
> > > > + spin_lock_irqsave(&fsl_chan->vchan.lock, flags);
> > > > + fsl_edma_disable_request(fsl_chan);
> > > > + fsl_chan->edesc = NULL;
> > > > + vchan_get_all_descriptors(&fsl_chan->vchan, &head);
> > > > + spin_unlock_irqrestore(&fsl_chan->vchan.lock, flags);
> > > > + vchan_dma_desc_free_list(&fsl_chan->vchan, &head);
> > > > + return 0;
> > > well what happens to the current ongoing transactions, i don't see
> those
> > > getting
> > > terminated?
> > The fsl_edma_disable_request(fsl_chan) would end the channel's ongoing
> transaction, then
> > the eDMA would not response to device dma request, and the
> vchan_dma_desc_free_list()
> > will release all associate memory. Thanks.
> Can you explain a bit more how terminate will happen, given taht you are
> using
> same thing for pause?
It works just like an interrupt controller on irq enable and disable. It has a register called
set/clear enable request register(SERQ/CERQ) to enable or disable the DMA request for a given
channel. It won't transfer data any more with the enable request register cleared. So for the
pause and terminate the pause is the same. And there is no other way to stop the channels.
Thanks.
> > > > +static struct dma_async_tx_descriptor *fsl_edma_prep_dma_cyclic(
> > > > + struct dma_chan *chan, dma_addr_t dma_addr, size_t
> buf_len,
> > > > + size_t period_len, enum dma_transfer_direction
> direction,
> > > > + unsigned long flags, void *context)
> > > > +{
> > > you may want to implement the capablities api subsequently for audio
> > > usage.
> > Do you mean the device_slave_caps function? If it is, I will add it.
> Yes, that can be incrementally added..
I have send the v11 patch out with a basic device_slave_caps definition. I notice
that there is some new update of the dma capabilities, so if possible and others ok,
could you please merge this patch first and leave me improving the driver in subsequent
patches. Thanks.
Best Regards,
Jingchang
^ permalink raw reply
* [PATCH] ARM: imx: correct usecount of IPG, ARM and MMDC clk on i.mx6sl
From: Anson Huang @ 2014-01-20 10:44 UTC (permalink / raw)
To: linux-arm-kernel
IPG, ARM and MMDC's clock should be enabled during kernel boot up,
so we need to maintain their use count, otherwise, they may be
disabled unexpectedly if their children's clock are turned off,
which is not allowed.
Signed-off-by: Anson Huang <b20788@freescale.com>
---
arch/arm/mach-imx/clk-imx6sl.c | 15 +++++++++++++++
1 file changed, 15 insertions(+)
diff --git a/arch/arm/mach-imx/clk-imx6sl.c b/arch/arm/mach-imx/clk-imx6sl.c
index 78f3bd6..8d720f9 100644
--- a/arch/arm/mach-imx/clk-imx6sl.c
+++ b/arch/arm/mach-imx/clk-imx6sl.c
@@ -291,6 +291,21 @@ static void __init imx6sl_clocks_init(struct device_node *ccm_node)
pr_warn("%s: failed to set AHB clock rate %d!\n",
__func__, ret);
+ /* Correct usecount of IPG clk */
+ ret = clk_prepare_enable(clks[IMX6SL_CLK_IPG]);
+ if (ret)
+ pr_warn("%s: failed to enable IPG clock %d\n", __func__, ret);
+
+ /* Correct usecount of ARM clk */
+ ret = clk_prepare_enable(clks[IMX6SL_CLK_ARM]);
+ if (ret)
+ pr_warn("%s: failed to enable ARM clock %d\n", __func__, ret);
+
+ /* Correct usecount of MMDC clk */
+ ret = clk_prepare_enable(clks[IMX6SL_CLK_MMDC_ROOT]);
+ if (ret)
+ pr_warn("%s: failed to enable MMDC clock %d\n", __func__, ret);
+
if (IS_ENABLED(CONFIG_USB_MXS_PHY)) {
clk_prepare_enable(clks[IMX6SL_CLK_USBPHY1_GATE]);
clk_prepare_enable(clks[IMX6SL_CLK_USBPHY2_GATE]);
--
1.7.9.5
^ permalink raw reply related
* [PATCH v4] dmaengine: sirf: enable generic dt binding for dma channels
From: Barry Song @ 2014-01-20 10:30 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20140120074857.GJ26823@intel.com>
2014/1/20 Vinod Koul <vinod.koul@intel.com>:
> On Wed, Jan 08, 2014 at 10:12:49PM +0800, Barry Song wrote:
>> From: Barry Song <Baohua.Song@csr.com>
>>
>> move to support of_dma_request_slave_channel() and dma_request_slave_channel.
>> we add a xlate() to let dma clients be able to find right dma_chan by generic
>> "dmas" properties in dts.
>>
>> Cc: Mark Rutland <mark.rutland@arm.com>
>> Cc: Lars-Peter Clausen <lars@metafoo.de>
>> Signed-off-by: Barry Song <Baohua.Song@csr.com>
> Look okay, need an ACk from DT maintainers before I can apply...
sorry. i just realized Mark has followed this thread and given
comments from the beginning.
Hi Mark,
will you ack this?
>
> --
> ~Vinod
>> ---
>> -v4: clear dt-binding document according to Mark's feedback
>>
-barry
^ permalink raw reply
* [PATCH] dmaengine: sirf: Add device_slave_caps interface
From: Barry Song @ 2014-01-20 10:24 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20140120075054.GK26823@intel.com>
2014/1/20 Vinod Koul <vinod.koul@intel.com>:
> On Mon, Jan 20, 2014 at 01:17:57PM +0530, Vinod Koul wrote:
>> On Mon, Dec 23, 2013 at 08:19:21PM +0800, Barry Song wrote:
>> > From: Rongjun Ying <rongjun.ying@csr.com>
>> >
>> > this patch adds device_slave_caps() callback as SiRF SoC sound drivers
>> > depend on it.
>>
>> Applied, thanks
>
> Btw you should send incremental patch for granurity reporting after the merge
> window. Those changes are getting merged thru ASoC tree.
yes. Rongjun is now handling the audio stuff with ASoC guys.
>
> --
> ~Vinod
-barry
^ permalink raw reply
* [PATCH v6 0/3] AArch64: KGDB support
From: Will Deacon @ 2014-01-20 10:23 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CALicx6tQu2O8o4pr-N8Xc=D-Y9kOMsFNsn6BLVDqRo0Pbay00Q@mail.gmail.com>
On Sat, Jan 18, 2014 at 08:02:21AM +0000, Vijay Kilari wrote:
> Hi Catalin,
>
> On Thu, Jan 16, 2014 at 7:15 PM, Catalin Marinas
> <catalin.marinas@arm.com> wrote:
> > On Thu, Dec 19, 2013 at 11:50:48AM +0000, vijay.kilari at gmail.com wrote:
> >> Vijaya Kumar K (3):
> >> AArch64: KGDB: Add Basic KGDB support
> >> AArch64: KGDB: Add step debugging support
> >> KGDB: make kgdb_breakpoint() as noinline
> >
> > I gave them a try and now I have some doubts about your testing
> > methodology:
> >
> > 1. There is no HAVE_ARCH_KGDB anywhere in these patches, so
> > the code here isn't compiled.
> >
> OK, I will send a patch
>
> > 2. There are several compiler warnings that need to be addressed.
> >
> > 3. I enabled CONFIG_KGDB_TESTS and CONFIG_KGDB_TESTS_ON_BOOT and that's
> > what really scared me.
> >
>
> Are you refering to these warning?. I don't see any warning in the
> patched files. I will fix these.
[...]
Well, the warnings are one thing but the 100 miles of backtrace output that
appear on every boot (and I think end in an oops) are probably more
important to fix. Please enable CONFIG_KGDB_TESTS and
CONFIG_KGDB_TESTS_ON_BOOT and take a look.
Will
^ permalink raw reply
* [PATCH v4] dmaengine: sirf: enable generic dt binding for dma channels
From: Barry Song @ 2014-01-20 10:20 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20140120084738.GO26823@intel.com>
2014/1/20 Vinod Koul <vinod.koul@intel.com>:
> On Mon, Jan 20, 2014 at 05:35:07PM +0800, Barry Song wrote:
>> 2014/1/20 Vinod Koul <vinod.koul@intel.com>:
>> > On Wed, Jan 08, 2014 at 10:12:49PM +0800, Barry Song wrote:
>> >> From: Barry Song <Baohua.Song@csr.com>
>> >>
>> >> move to support of_dma_request_slave_channel() and dma_request_slave_channel.
>> >> we add a xlate() to let dma clients be able to find right dma_chan by generic
>> >> "dmas" properties in dts.
>> >>
>> >> Cc: Mark Rutland <mark.rutland@arm.com>
>> >> Cc: Lars-Peter Clausen <lars@metafoo.de>
>> >> Signed-off-by: Barry Song <Baohua.Song@csr.com>
>> > Look okay, need an ACk from DT maintainers before I can apply...
>>
>> Vinod, will i send v5 with your ack to
>> devicetree-discuss at lists.ozlabs.org, and CC Grant & Rob?
> Which tree are you tragetting this, if dmaengine then my ack make no sense :)
>
>>
>> Hi Rob, will you Ack this one if you have noticed this thread?
> I dont think Robs email is avlid anymore, I think he moved to Linaro, if I am
> not mistaken.
>
> ~Vinod
ok. i will resend the patch with dts guys.
>> > ~Vinod
>> >> ---
>> >> -v4: clear dt-binding document according to Mark's feedback
>>
>> -barry
-barry
^ permalink raw reply
* [PATCHv10 2/2] dma: Add Freescale eDMA engine driver support
From: Vinod Koul @ 2014-01-20 10:20 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <f173c2531461478899818365e06df437@BL2PR03MB467.namprd03.prod.outlook.com>
On Mon, Jan 20, 2014 at 11:05:03AM +0000, Jingchang Lu wrote:
> > > > > + struct fsl_edma_chan *fsl_chan = to_fsl_edma_chan(chan);
> > > > > + struct dma_slave_config *cfg = (void *)arg;
> > > > > + unsigned long flags;
> > > > > + LIST_HEAD(head);
> > > > > +
> > > > > + switch (cmd) {
> > > > > + case DMA_TERMINATE_ALL:
> > > > > + spin_lock_irqsave(&fsl_chan->vchan.lock, flags);
> > > > > + fsl_edma_disable_request(fsl_chan);
> > > > > + fsl_chan->edesc = NULL;
> > > > > + vchan_get_all_descriptors(&fsl_chan->vchan, &head);
> > > > > + spin_unlock_irqrestore(&fsl_chan->vchan.lock, flags);
> > > > > + vchan_dma_desc_free_list(&fsl_chan->vchan, &head);
> > > > > + return 0;
> > > > well what happens to the current ongoing transactions, i don't see
> > those
> > > > getting
> > > > terminated?
> > > The fsl_edma_disable_request(fsl_chan) would end the channel's ongoing
> > transaction, then
> > > the eDMA would not response to device dma request, and the
> > vchan_dma_desc_free_list()
> > > will release all associate memory. Thanks.
> > Can you explain a bit more how terminate will happen, given taht you are
> > using
> > same thing for pause?
> It works just like an interrupt controller on irq enable and disable. It has a register called
> set/clear enable request register(SERQ/CERQ) to enable or disable the DMA request for a given
> channel. It won't transfer data any more with the enable request register cleared. So for the
> pause and terminate the pause is the same. And there is no other way to stop the channels.
well then it is not pause! If you jave no way to stop the channel, you cant
claim to support pause and resume!
Also, for terminate this will be problematic. Assuming you are doing transfers
and terminate is invoked. Then you will disable irq. The transfers may get stuck
and periphral clock may go away after transfer so current transaction never gets
completed, how do we recovery from this?
Alstly, have you looked at edma driver already existing, any similarties in teh
controller with that?
> > > > > +static struct dma_async_tx_descriptor *fsl_edma_prep_dma_cyclic(
> > > > > + struct dma_chan *chan, dma_addr_t dma_addr, size_t
> > buf_len,
> > > > > + size_t period_len, enum dma_transfer_direction
> > direction,
> > > > > + unsigned long flags, void *context)
> > > > > +{
> > > > you may want to implement the capablities api subsequently for audio
> > > > usage.
> > > Do you mean the device_slave_caps function? If it is, I will add it.
> > Yes, that can be incrementally added..
> I have send the v11 patch out with a basic device_slave_caps definition. I notice
> that there is some new update of the dma capabilities, so if possible and others ok,
> could you please merge this patch first and leave me improving the driver in subsequent
> patches. Thanks.
Sure, as I said this can be incremental but atm am worried about pause and
terminate behaviour.
--
~Vinod
^ permalink raw reply
* Deadlock in do_page_fault() on ARM (old kernel)
From: Michal Hocko @ 2014-01-20 10:15 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <52D73220.3030108@signal11.us>
On Wed 15-01-14 20:13:04, Alan Ott wrote:
[...]
> 2. __copy_to_user_memcpy() takes a read lock (down_read()) on
This looks like a bug. copy_to_user_* shouldn't take mmap_sem at all
Check the might_fault annotation used in generic code. Arm version of
copy_to_user* doesn't seem to use the annotation and I do not see a good
reason for that.
> mm->mmap_sem. While that lock is held, __copy_to_user_memcpy() can
> generate a page fault, causing do_page_fault() to get called, which
> will also try to get a read lock (down_read()) on mm->mmap_sem.
> Multiple read locks can be taken on an rw_semaphore, but deadlock
> will occur if another thread tries to get a write lock
> (down_write()) in between. For example:
> Task 1: Task 2:
> down_read(sem)
> down_write(sem) <-- Goes to sleep
> down_read(sem) <-- Goes to sleep
>
> There is a thread from 2005[3] which seems to discuss the same
> concept of recursive rw_semaphores, but for futexes.
>
> Other comments:
> 1. My analysis of this probably wrong. Otherwise it seems many
> others would have the same problem, and they don't seem to. I'm
> hoping this email will help to correct my understanding.
> 2. I looked through the git logs for recent (since 2.6.37 time
> frame) and nothing else jumped out at me as being an obvious fix for
> this situation.
>
> Thanks for any insight you can give,
>
> Alan.
>
> [1] http://www.signal11.us/~alan/show-all-tasks-deadlock.txt
>
> [2] Some websites/bugtrackers mention this commit with a similar
> issue, but I'm not entirely sure how it's related:
> http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=8878a539ff19a43cf3729e7562cd528f490246ae
>
> This one seems obviously related, but has no effect on my system:
> http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=435a7ef52db7d86e67a009b36cac1457f8972391
>
> [3] http://thread.gmane.org/gmane.linux.kernel/280900
> --
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo at vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
--
Michal Hocko
SUSE Labs
^ permalink raw reply
* [PATCH v2] dma: imx-sdma: clarify firmare not found warning
From: Sascha Hauer @ 2014-01-20 10:07 UTC (permalink / raw)
To: linux-arm-kernel
When a firmware cannot be found for the SDMA engine then we can
continue with the inernal ROM firmware.
The meaning of this message is frequently asked for, so make clear
that the driver still works with the internal ROM firmware and reduce
the loglevel from err to info.
Signed-off-by: Sascha Hauer <s.hauer@pengutronix.de>
Cc: Vinod Koul <vinod.koul@intel.com>
Cc: linux-arm-kernel at lists.infradead.org
Cc: Shawn Guo <shawn.guo@linaro.org>
---
changes since v1:
- instead of removing the message make it more clear
drivers/dma/imx-sdma.c | 5 ++++-
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/drivers/dma/imx-sdma.c b/drivers/dma/imx-sdma.c
index c75679d..d79eaad 100644
--- a/drivers/dma/imx-sdma.c
+++ b/drivers/dma/imx-sdma.c
@@ -1259,7 +1259,10 @@ static void sdma_load_firmware(const struct firmware *fw, void *context)
unsigned short *ram_code;
if (!fw) {
- dev_err(sdma->dev, "firmware not found\n");
+ dev_info(sdma->dev, "external firmware not found, using ROM firmware\n");
+ /*
+ * In this case we just use the ROM firmware.
+ */
return;
}
--
1.8.5.2
^ permalink raw reply related
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