* [PATCH v5 2/5] arm64: dts: exynos: make tm2 and tm2e independent from each other
From: Javier Martinez Canillas @ 2017-01-06 14:02 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20170106134929.mj7wqalp7lpkfm6b@kozik-lap>
Hello Krzysztof,
On 01/06/2017 10:49 AM, Krzysztof Kozlowski wrote:
> On Fri, Jan 06, 2017 at 10:43:47PM +0900, Andi Shyti wrote:
>> Currently tm2e dts includes tm2 but there are some differences
>> between the two boards and tm2 has some properties that tm2e
>> doesn't have.
>>
>> That's why it's important to keep the two dts files independent
>> and put all the commonalities in a tm2-common.dtsi file.
>>
>> At the current status the only two differences between the two
>> dts files (besides the board name) are ldo31 and ldo38.
>>
>> Signed-off-by: Andi Shyti <andi.shyti@samsung.com>
>> Reviewed-by: Javier Martinez Canillas <javier@osg.samsung.com>
>> ---
[snip]
> Beside that it is starting to look good. I didn't find anything else but
> maybe Javier's eagle eye will catch something.
>
I didn't find anything else, the patch looks good to me now.
>
> Best regards,
> Krzysztof
>
Best regards,
--
Javier Martinez Canillas
Open Source Group
Samsung Research America
^ permalink raw reply
* [PATCH v5 5/5] arm64: dts: exynos: Add tm2 touchkey node
From: Krzysztof Kozlowski @ 2017-01-06 14:03 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20170106134350.32428-6-andi.shyti@samsung.com>
On Fri, Jan 06, 2017 at 10:43:50PM +0900, Andi Shyti wrote:
> From: Jaechul Lee <jcsing.lee@samsung.com>
>
> Add DT node support for TM2 touchkey device.
>
> Signed-off-by: Beomho Seo <beomho.seo@samsung.com>
> Signed-off-by: Jaechul Lee <jcsing.lee@samsung.com>
> Signed-off-by: Andi Shyti <andi.shyti@samsung.com>
> Reviewed-by: Javier Martinez Canillas <javier@osg.samsung.com>
> ---
> arch/arm64/boot/dts/exynos/exynos5433-tm2.dts | 13 +++++++++++++
> 1 file changed, 13 insertions(+)
>
Looks good, but I will wait with this one till the bindings and driver
got accepted.
Best regards,
Krzysztof
^ permalink raw reply
* [PATCH] ARM, ARM64: dts: drop "arm,amba-bus" in favor of "simple-bus" part 3
From: Krzysztof Kozlowski @ 2017-01-06 14:13 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1482853886-7932-1-git-send-email-yamada.masahiro@socionext.com>
On Wed, Dec 28, 2016 at 12:51:26AM +0900, Masahiro Yamada wrote:
> Tree-wide replacement was done by commit 2ef7d5f342c1 ("ARM, ARM64:
> dts: drop "arm,amba-bus" in favor of "simple-bus"), then the 2nd
> round by commit 15b7cc78f095 ("arm64: dts: drop "arm,amba-bus" in
> favor of "simple-bus" part 2").
>
> Here, some new users have appeared for Linux v4.10-rc1. Eliminate
> them now.
>
> Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
> ---
>
> Hi Arnd, Olof,
>
> Can you pick this up for v4.10 fixes?
>
> If we carry arm,amba-bus until the release, we will need to
> take more time to deprecate it.
What is the status of this?
Masahiro, if you would split this, I could take Exynos part through my
tree. Anyway I am fine with taking this directly into arm-soc. I do not
expect conflicts around these lines, so:
For Exynos:
Acked-by: Krzysztof Kozlowski <krzk@kernel.org>
Best regards,
Krzysztof
^ permalink raw reply
* [PATCH 3/4] ARM: dts: sunxi: add usb_otg and usbphy node for V3s SoC
From: Maxime Ripard @ 2017-01-06 14:19 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20170103152534.20118-4-icenowy@aosc.xyz>
On Tue, Jan 03, 2017 at 11:25:33PM +0800, Icenowy Zheng wrote:
> V3s SoC features a USB PHY controller and a MUSB OTG controller.
>
> Add device nodes for them.
>
> Signed-off-by: Icenowy Zheng <icenowy@aosc.xyz>
This can be merged in your other DTSI patch.
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/20170106/c1123176/attachment.sig>
^ permalink raw reply
* [PATCHv2 net-next 05/16] net: mvpp2: introduce PPv2.2 HW descriptors and adapt accessors
From: Russell King - ARM Linux @ 2017-01-06 14:29 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1482943592-12556-6-git-send-email-thomas.petazzoni@free-electrons.com>
On Wed, Dec 28, 2016 at 05:46:21PM +0100, Thomas Petazzoni wrote:
> This commit adds the definition of the PPv2.2 HW descriptors, adjusts
> the mvpp2_tx_desc and mvpp2_rx_desc structures accordingly, and adapts
> the accessors to work on both PPv2.1 and PPv2.2.
>
> Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
...
> + /* On PPv2.2, the situation is more complicated,
> + * because there is only 40 bits to store the virtual
> + * address, which is not sufficient. So on 64 bits
> + * systems, we use phys_to_virt() to get the virtual
> + * address from the physical address, which is fine
> + * because the kernel linear mapping includes the
> + * entire 40 bits physical address space. On 32 bits
> + * systems however, we can't use phys_to_virt(), but
> + * since virtual addresses are 32 bits only, there is
> + * enough space in the RX descriptor for the full
> + * virtual address.
> + */
> +#ifdef CONFIG_ARCH_DMA_ADDR_T_64BIT
> + dma_addr_t dma_addr =
> + rx_desc->pp22.buf_phys_addr_key_hash & DMA_BIT_MASK(40);
> + phys_addr_t phys_addr =
> + dma_to_phys(port->dev->dev.parent, dma_addr);
> +
> + return (unsigned long)phys_to_virt(phys_addr);
> +#else
> + return rx_desc->pp22.buf_cookie_misc & DMA_BIT_MASK(40);
> +#endif
I'm not sure that's the best way of selecting the difference. It seems
that the issue here is the size of the virtual address, so why not test
the size of a virtual address pointer?
if (8 * sizeof(rx_desc) > 40) {
/* do phys addr dance */
} else {
return rx_desc->pp22.buf_cookie_misc & DMA_BIT_MASK(40);
}
It also means that we get compile coverage over both sides of the
conditional.
--
RMK's Patch system: http://www.armlinux.org.uk/developer/patches/
FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up
according to speedtest.net.
^ permalink raw reply
* [PATCH v3 0/5] drm/dp: Implement CRC debugfs API
From: Tomeu Vizoso @ 2017-01-06 14:30 UTC (permalink / raw)
To: linux-arm-kernel
Hi,
this series builds up on the API for exposing captured CRCs through
debugfs.
It adds new DP helpers for starting and stopping CRC capture and gets
the Rockchip driver to use it.
Also had to add a connector backpointer to the drm_dp_aux struct so we could
wait for the right vblank and store the CRCs afterwards, I will be glad
to hear about better alternatives.
With these patches, tests in IGT such as kms_pipe_crc_basic and
kms_plane do pass on RK3288.
Thanks,
Tomeu
Tomeu Vizoso (5):
drm/dp: add connector backpointer to drm_dp_aux
drm/bridge: analogix_dp: set connector to drm_dp_aux
drm/dp: add helpers for capture of frame CRCs
drm/bridge: analogix_dp: add helpers for capture of frame CRCs
drm/rockchip: Implement CRC debugfs API
drivers/gpu/drm/bridge/analogix/analogix_dp_core.c | 34 ++++--
drivers/gpu/drm/drm_dp_helper.c | 118 +++++++++++++++++++++
drivers/gpu/drm/rockchip/rockchip_drm_vop.c | 48 +++++++++
include/drm/bridge/analogix_dp.h | 3 +
include/drm/drm_dp_helper.h | 9 ++
5 files changed, 204 insertions(+), 8 deletions(-)
--
2.9.3
^ permalink raw reply
* [PATCH v3 5/5] drm/rockchip: Implement CRC debugfs API
From: Tomeu Vizoso @ 2017-01-06 14:30 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20170106143029.11553-1-tomeu.vizoso@collabora.com>
Implement the .set_crc_source() callback and call the DP helpers
accordingly to start and stop CRC capture.
This is only done if this CRTC is currently using the eDP connector.
v3: Remove superfluous check on rockchip_crtc_state->output_type
Signed-off-by: Tomeu Vizoso <tomeu.vizoso@collabora.com>
---
drivers/gpu/drm/rockchip/rockchip_drm_vop.c | 48 +++++++++++++++++++++++++++++
1 file changed, 48 insertions(+)
diff --git a/drivers/gpu/drm/rockchip/rockchip_drm_vop.c b/drivers/gpu/drm/rockchip/rockchip_drm_vop.c
index fb5f001f51c3..5e19bef6d5b4 100644
--- a/drivers/gpu/drm/rockchip/rockchip_drm_vop.c
+++ b/drivers/gpu/drm/rockchip/rockchip_drm_vop.c
@@ -19,6 +19,7 @@
#include <drm/drm_crtc_helper.h>
#include <drm/drm_flip_work.h>
#include <drm/drm_plane_helper.h>
+#include <drm/bridge/analogix_dp.h>
#include <linux/kernel.h>
#include <linux/module.h>
@@ -1105,6 +1106,52 @@ static void vop_crtc_destroy_state(struct drm_crtc *crtc,
kfree(s);
}
+static struct drm_connector *vop_get_edp_connector(struct vop *vop)
+{
+ struct drm_crtc *crtc = &vop->crtc;
+ struct drm_connector *connector;
+
+ mutex_lock(&crtc->dev->mode_config.mutex);
+ drm_for_each_connector(connector, crtc->dev)
+ if (connector->connector_type == DRM_MODE_CONNECTOR_eDP) {
+ mutex_unlock(&crtc->dev->mode_config.mutex);
+ return connector;
+ }
+ mutex_unlock(&crtc->dev->mode_config.mutex);
+
+ return NULL;
+}
+
+static int vop_crtc_set_crc_source(struct drm_crtc *crtc,
+ const char *source_name, size_t *values_cnt)
+{
+ struct vop *vop = to_vop(crtc);
+ struct rockchip_crtc_state *s = to_rockchip_crtc_state(crtc->state);
+ struct drm_connector *connector;
+ int ret;
+
+ connector = vop_get_edp_connector(vop);
+ if (!connector)
+ return -EINVAL;
+
+ *values_cnt = 3;
+
+ if (source_name &&
+ strcmp(source_name, "auto") == 0) {
+
+ if (s->output_type != DRM_MODE_CONNECTOR_eDP)
+ return -EINVAL;
+
+ ret = analogix_dp_start_crc(connector);
+ } else if (!source_name)
+
+ ret = analogix_dp_stop_crc(connector);
+ else
+ ret = -EINVAL;
+
+ return ret;
+}
+
static const struct drm_crtc_funcs vop_crtc_funcs = {
.set_config = drm_atomic_helper_set_config,
.page_flip = drm_atomic_helper_page_flip,
@@ -1112,6 +1159,7 @@ static const struct drm_crtc_funcs vop_crtc_funcs = {
.reset = vop_crtc_reset,
.atomic_duplicate_state = vop_crtc_duplicate_state,
.atomic_destroy_state = vop_crtc_destroy_state,
+ .set_crc_source = vop_crtc_set_crc_source,
};
static void vop_fb_unref_worker(struct drm_flip_work *work, void *val)
--
2.9.3
^ permalink raw reply related
* [PATCHv2 net-next 06/16] net: mvpp2: adjust the allocation/free of BM pools for PPv2.2
From: Russell King - ARM Linux @ 2017-01-06 14:32 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1482943592-12556-7-git-send-email-thomas.petazzoni@free-electrons.com>
On Wed, Dec 28, 2016 at 05:46:22PM +0100, Thomas Petazzoni wrote:
> +#ifdef CONFIG_ARCH_DMA_ADDR_T_64BIT
> + if (priv->hw_version == MVPP22) {
Maybe
if (sizeof(dma_addr_t) > sizeof(u32) && priv->hw_version == MVPP22) {
to get better compile coverage?
> + u32 val;
> + u32 paddr_highbits;
> +
> + val = mvpp2_read(priv, MVPP2_BM_ADDR_HIGH_ALLOC);
> + paddr_highbits = (val & MVPP2_BM_ADDR_HIGH_PHYS_MASK);
> +
> + *paddr |= (dma_addr_t)paddr_highbits << 32;
> + *vaddr = (unsigned long)phys_to_virt(dma_to_phys(dev, *paddr));
> + }
> +#endif
> +}
> +
> /* Free all buffers from the pool */
> static void mvpp2_bm_bufs_free(struct device *dev, struct mvpp2 *priv,
> struct mvpp2_bm_pool *bm_pool)
> @@ -3616,10 +3671,8 @@ static void mvpp2_bm_bufs_free(struct device *dev, struct mvpp2 *priv,
> dma_addr_t buf_phys_addr;
> unsigned long vaddr;
>
> - /* Get buffer virtual address (indirect access) */
> - buf_phys_addr = mvpp2_read(priv,
> - MVPP2_BM_PHY_ALLOC_REG(bm_pool->id));
> - vaddr = mvpp2_read(priv, MVPP2_BM_VIRT_ALLOC_REG);
> + mvpp2_bm_bufs_get_addrs(dev, priv, bm_pool,
> + &buf_phys_addr, &vaddr);
>
> dma_unmap_single(dev, buf_phys_addr,
> bm_pool->buf_size, DMA_FROM_DEVICE);
> @@ -3651,7 +3704,7 @@ static int mvpp2_bm_pool_destroy(struct platform_device *pdev,
> val |= MVPP2_BM_STOP_MASK;
> mvpp2_write(priv, MVPP2_BM_POOL_CTRL_REG(bm_pool->id), val);
>
> - dma_free_coherent(&pdev->dev, sizeof(u32) * bm_pool->size,
> + dma_free_coherent(&pdev->dev, bm_pool->size_bytes,
> bm_pool->virt_addr,
> bm_pool->phys_addr);
> return 0;
> @@ -3787,8 +3840,19 @@ static inline void mvpp2_bm_pool_put(struct mvpp2_port *port, int pool,
> dma_addr_t buf_phys_addr,
> unsigned long buf_virt_addr)
> {
> - mvpp2_write(port->priv, MVPP2_BM_VIRT_RLS_REG, buf_virt_addr);
> - mvpp2_write(port->priv, MVPP2_BM_PHY_RLS_REG(pool), buf_phys_addr);
> +#if defined(CONFIG_ARCH_DMA_ADDR_T_64BIT)
> + u32 val;
> +
> + val = upper_32_bits(buf_phys_addr) & MVPP22_BM_ADDR_HIGH_PHYS_RLS_MASK;
> + val |= (upper_32_bits(buf_virt_addr) &
> + MVPP22_BM_ADDR_HIGH_VIRT_RLS_MASK)
> + << MVPP22_BM_ADDR_HIGH_VIRT_RLS_SHIFT;
> + mvpp2_write(port->priv, MVPP22_BM_ADDR_HIGH_RLS_REG, val);
> +#endif
Similar compile-time conditional?
--
RMK's Patch system: http://www.armlinux.org.uk/developer/patches/
FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up
according to speedtest.net.
^ permalink raw reply
* [PATCH 16/18] arm64: ptrace: handle ptrace_request differently for aarch32 and ilp32
From: Catalin Marinas @ 2017-01-06 14:36 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20170105204003.GA7437@yury-N73SV>
On Fri, Jan 06, 2017 at 02:10:03AM +0530, Yury Norov wrote:
> On Wed, Dec 07, 2016 at 09:40:13PM +0100, Arnd Bergmann wrote:
> > On Wednesday, December 7, 2016 4:59:13 PM CET Catalin Marinas wrote:
> > > On Tue, Dec 06, 2016 at 11:55:08AM +0530, Yury Norov wrote:
> > > > On Mon, Dec 05, 2016 at 04:34:23PM +0000, Catalin Marinas wrote:
> > > > > On Fri, Oct 21, 2016 at 11:33:15PM +0300, Yury Norov wrote:
> > > > > > New aarch32 ptrace syscall handler is introduced to avoid run-time
> > > > > > detection of the task type.
> > > > >
> > > > > What's wrong with the run-time detection? If it's just to avoid a
> > > > > negligible overhead, I would rather keep the code simpler by avoiding
> > > > > duplicating the generic compat_sys_ptrace().
> > > >
> > > > Nothing wrong. This is how Arnd asked me to do. You already asked this
> > > > question: http://lkml.iu.edu/hypermail/linux/kernel/1604.3/00930.html
> > >
> > > Hmm, I completely forgot about this ;). There is still an advantage to
> > > doing run-time checking if we avoid touching core code (less acks to
> > > gather and less code duplication).
> > >
> > > Let's see what Arnd says but the initial patch looked simpler.
> >
> > I don't currently have either version of the patch in my inbox
> > (the archive is on a different machine), but in general I'd still
> > think it's best to avoid the runtime check for aarch64-ilp32
> > altogether. I'd have to look at the overall kernel source to
> > see if it's worth avoiding one or two instances though, or
> > if there are an overwhelming number of other checks that we
> > can't avoid at all.
> >
> > Regarding ptrace, I notice that arch/tile doesn't even use
> > the compat entry point for its ilp32 user space on 64-bit
> > kernels, it just calls the regular 64-bit one. Would that
> > help here?
>
> ILP32 tasks has unique context that is not like aarch64 or aarch32,
> so we have to have unique ptrace handler. I prepared the patch for
> ptrace with runtime ABI detection, as Catalin said, see there:
> https://github.com/norov/linux/commit/1f66dc22a4450b192e83458f2c3cc0e79f53e670
>
> If it's OK, I'd like to update submission.
This looks better to me (and even better if you no longer need to touch
the generic ptrace code).
--
Catalin
^ permalink raw reply
* [PATCH] arm64: do not set dma masks that device connection can't handle
From: Nikita Yushchenko @ 2017-01-06 14:38 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <9a03c05d-ad4c-0547-d1fe-01edb8b082d6@cogentembedded.com>
It is possible that device is capable of 64-bit DMA addresses, and
device driver tries to set wide DMA mask, but bridge or bus used to
connect device to the system can't handle wide addresses.
With swiotlb, memory above 4G still can be used by drivers for streaming
DMA, but *dev->mask and dev->dma_coherent_mask must still keep values
that hardware handles physically.
This patch enforces that. Based on original version by
Arnd Bergmann <arnd@arndb.de>, extended with coherent mask hadnling.
Signed-off-by: Nikita Yushchenko <nikita.yoush@cogentembedded.com>
CC: Arnd Bergmann <arnd@arndb.de>
---
arch/arm64/Kconfig | 3 +++
arch/arm64/include/asm/device.h | 1 +
arch/arm64/mm/dma-mapping.c | 40 ++++++++++++++++++++++++++++++++++++++++
3 files changed, 44 insertions(+)
diff --git a/arch/arm64/Kconfig b/arch/arm64/Kconfig
index 1117421..afb2c08 100644
--- a/arch/arm64/Kconfig
+++ b/arch/arm64/Kconfig
@@ -216,6 +216,9 @@ config NEED_DMA_MAP_STATE
config NEED_SG_DMA_LENGTH
def_bool y
+config ARCH_HAS_DMA_SET_COHERENT_MASK
+ def_bool y
+
config SMP
def_bool y
diff --git a/arch/arm64/include/asm/device.h b/arch/arm64/include/asm/device.h
index 243ef25..a57e7bb 100644
--- a/arch/arm64/include/asm/device.h
+++ b/arch/arm64/include/asm/device.h
@@ -22,6 +22,7 @@ struct dev_archdata {
void *iommu; /* private IOMMU data */
#endif
bool dma_coherent;
+ u64 parent_dma_mask;
};
struct pdev_archdata {
diff --git a/arch/arm64/mm/dma-mapping.c b/arch/arm64/mm/dma-mapping.c
index 290a84f..be3632e 100644
--- a/arch/arm64/mm/dma-mapping.c
+++ b/arch/arm64/mm/dma-mapping.c
@@ -352,6 +352,31 @@ static int __swiotlb_dma_supported(struct device *hwdev, u64 mask)
return 1;
}
+static int __swiotlb_set_dma_mask(struct device *dev, u64 mask)
+{
+ /* device is not DMA capable */
+ if (!dev->dma_mask)
+ return -EIO;
+
+ /* mask is below swiotlb bounce buffer, so fail */
+ if (!swiotlb_dma_supported(dev, mask))
+ return -EIO;
+
+ /*
+ * because of the swiotlb, we can return success for
+ * larger masks, but need to ensure that bounce buffers
+ * are used above parent_dma_mask, so set that as
+ * the effective mask.
+ */
+ if (mask > dev->archdata.parent_dma_mask)
+ mask = dev->archdata.parent_dma_mask;
+
+
+ *dev->dma_mask = mask;
+
+ return 0;
+}
+
static struct dma_map_ops swiotlb_dma_ops = {
.alloc = __dma_alloc,
.free = __dma_free,
@@ -367,8 +392,23 @@ static struct dma_map_ops swiotlb_dma_ops = {
.sync_sg_for_device = __swiotlb_sync_sg_for_device,
.dma_supported = __swiotlb_dma_supported,
.mapping_error = swiotlb_dma_mapping_error,
+ .set_dma_mask = __swiotlb_set_dma_mask,
};
+int dma_set_coherent_mask(struct device *dev, u64 mask)
+{
+ if (!dma_supported(dev, mask))
+ return -EIO;
+
+ if (get_dma_ops(dev) == &swiotlb_dma_ops &&
+ mask > dev->archdata.parent_dma_mask)
+ mask = dev->archdata.parent_dma_mask;
+
+ dev->coherent_dma_mask = mask;
+ return 0;
+}
+EXPORT_SYMBOL(dma_set_coherent_mask);
+
static int __init atomic_pool_init(void)
{
pgprot_t prot = __pgprot(PROT_NORMAL_NC);
--
2.1.4
^ permalink raw reply related
* [PATCHv2 net-next 05/16] net: mvpp2: introduce PPv2.2 HW descriptors and adapt accessors
From: Robin Murphy @ 2017-01-06 14:44 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20170106142901.GC14217@n2100.armlinux.org.uk>
On 06/01/17 14:29, Russell King - ARM Linux wrote:
> On Wed, Dec 28, 2016 at 05:46:21PM +0100, Thomas Petazzoni wrote:
>> This commit adds the definition of the PPv2.2 HW descriptors, adjusts
>> the mvpp2_tx_desc and mvpp2_rx_desc structures accordingly, and adapts
>> the accessors to work on both PPv2.1 and PPv2.2.
>>
>> Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
> ...
>> + /* On PPv2.2, the situation is more complicated,
>> + * because there is only 40 bits to store the virtual
>> + * address, which is not sufficient. So on 64 bits
>> + * systems, we use phys_to_virt() to get the virtual
>> + * address from the physical address, which is fine
>> + * because the kernel linear mapping includes the
>> + * entire 40 bits physical address space. On 32 bits
>> + * systems however, we can't use phys_to_virt(), but
>> + * since virtual addresses are 32 bits only, there is
>> + * enough space in the RX descriptor for the full
>> + * virtual address.
>> + */
>> +#ifdef CONFIG_ARCH_DMA_ADDR_T_64BIT
>> + dma_addr_t dma_addr =
>> + rx_desc->pp22.buf_phys_addr_key_hash & DMA_BIT_MASK(40);
>> + phys_addr_t phys_addr =
>> + dma_to_phys(port->dev->dev.parent, dma_addr);
Ugh, this looks bogus. dma_to_phys(), in the arm64 case at least, is
essentially a SWIOTLB internal helper function which has to be
implemented in architecture code because reasons. Calling it from a
driver is almost certainly wrong (it doesn't even exist on most
architectures). Besides, if this is really a genuine dma_addr_t obtained
from a DMA API call, you cannot infer it to be related to a CPU physical
address, or convertible to one at all.
>> +
>> + return (unsigned long)phys_to_virt(phys_addr);
>> +#else
>> + return rx_desc->pp22.buf_cookie_misc & DMA_BIT_MASK(40);
>> +#endif
>
> I'm not sure that's the best way of selecting the difference.
Given that CONFIG_ARCH_DMA_ADDR_T_64BIT could be enabled on 32-bit LPAE
systems, indeed it definitely isn't.
Robin.
> It seems
> that the issue here is the size of the virtual address, so why not test
> the size of a virtual address pointer?
>
> if (8 * sizeof(rx_desc) > 40) {
> /* do phys addr dance */
> } else {
> return rx_desc->pp22.buf_cookie_misc & DMA_BIT_MASK(40);
> }
>
> It also means that we get compile coverage over both sides of the
> conditional.
>
^ permalink raw reply
* [PATCH] arm64: do not set dma masks that device connection can't handle
From: Nikita Yushchenko @ 2017-01-06 14:45 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <9a03c05d-ad4c-0547-d1fe-01edb8b082d6@cogentembedded.com>
It is possible that device is capable of 64-bit DMA addresses, and
device driver tries to set wide DMA mask, but bridge or bus used to
connect device to the system can't handle wide addresses.
With swiotlb, memory above 4G still can be used by drivers for streaming
DMA, but *dev->mask and dev->dma_coherent_mask must still keep values
that hardware handles physically.
This patch enforces that. Based on original version by
Arnd Bergmann <arnd@arndb.de>, extended with coherent mask hadnling.
Signed-off-by: Nikita Yushchenko <nikita.yoush@cogentembedded.com>
CC: Arnd Bergmann <arnd@arndb.de>
---
... now with initially missed change in arch_setup_dma_ops() ...
arch/arm64/Kconfig | 3 +++
arch/arm64/include/asm/device.h | 1 +
arch/arm64/mm/dma-mapping.c | 52 +++++++++++++++++++++++++++++++++++++++++
3 files changed, 56 insertions(+)
diff --git a/arch/arm64/Kconfig b/arch/arm64/Kconfig
index 1117421..afb2c08 100644
--- a/arch/arm64/Kconfig
+++ b/arch/arm64/Kconfig
@@ -216,6 +216,9 @@ config NEED_DMA_MAP_STATE
config NEED_SG_DMA_LENGTH
def_bool y
+config ARCH_HAS_DMA_SET_COHERENT_MASK
+ def_bool y
+
config SMP
def_bool y
diff --git a/arch/arm64/include/asm/device.h b/arch/arm64/include/asm/device.h
index 243ef25..a57e7bb 100644
--- a/arch/arm64/include/asm/device.h
+++ b/arch/arm64/include/asm/device.h
@@ -22,6 +22,7 @@ struct dev_archdata {
void *iommu; /* private IOMMU data */
#endif
bool dma_coherent;
+ u64 parent_dma_mask;
};
struct pdev_archdata {
diff --git a/arch/arm64/mm/dma-mapping.c b/arch/arm64/mm/dma-mapping.c
index 290a84f..09c7900 100644
--- a/arch/arm64/mm/dma-mapping.c
+++ b/arch/arm64/mm/dma-mapping.c
@@ -352,6 +352,31 @@ static int __swiotlb_dma_supported(struct device *hwdev, u64 mask)
return 1;
}
+static int __swiotlb_set_dma_mask(struct device *dev, u64 mask)
+{
+ /* device is not DMA capable */
+ if (!dev->dma_mask)
+ return -EIO;
+
+ /* mask is below swiotlb bounce buffer, so fail */
+ if (!swiotlb_dma_supported(dev, mask))
+ return -EIO;
+
+ /*
+ * because of the swiotlb, we can return success for
+ * larger masks, but need to ensure that bounce buffers
+ * are used above parent_dma_mask, so set that as
+ * the effective mask.
+ */
+ if (mask > dev->archdata.parent_dma_mask)
+ mask = dev->archdata.parent_dma_mask;
+
+
+ *dev->dma_mask = mask;
+
+ return 0;
+}
+
static struct dma_map_ops swiotlb_dma_ops = {
.alloc = __dma_alloc,
.free = __dma_free,
@@ -367,8 +392,23 @@ static struct dma_map_ops swiotlb_dma_ops = {
.sync_sg_for_device = __swiotlb_sync_sg_for_device,
.dma_supported = __swiotlb_dma_supported,
.mapping_error = swiotlb_dma_mapping_error,
+ .set_dma_mask = __swiotlb_set_dma_mask,
};
+int dma_set_coherent_mask(struct device *dev, u64 mask)
+{
+ if (!dma_supported(dev, mask))
+ return -EIO;
+
+ if (get_dma_ops(dev) == &swiotlb_dma_ops &&
+ mask > dev->archdata.parent_dma_mask)
+ mask = dev->archdata.parent_dma_mask;
+
+ dev->coherent_dma_mask = mask;
+ return 0;
+}
+EXPORT_SYMBOL(dma_set_coherent_mask);
+
static int __init atomic_pool_init(void)
{
pgprot_t prot = __pgprot(PROT_NORMAL_NC);
@@ -957,6 +997,18 @@ void arch_setup_dma_ops(struct device *dev, u64 dma_base, u64 size,
if (!dev->archdata.dma_ops)
dev->archdata.dma_ops = &swiotlb_dma_ops;
+ /*
+ * we don't yet support buses that have a non-zero mapping.
+ * Let's hope we won't need it
+ */
+ WARN_ON(dma_base != 0);
+
+ /*
+ * Whatever the parent bus can set. A device must not set
+ * a DMA mask larger than this.
+ */
+ dev->archdata.parent_dma_mask = size;
+
dev->archdata.dma_coherent = coherent;
__iommu_setup_dma_ops(dev, dma_base, size, iommu);
}
--
2.1.4
^ permalink raw reply related
* [PATCHv2 net-next 10/16] net: mvpp2: handle register mapping and access for PPv2.2
From: Russell King - ARM Linux @ 2017-01-06 14:46 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1482943592-12556-11-git-send-email-thomas.petazzoni@free-electrons.com>
On Wed, Dec 28, 2016 at 05:46:26PM +0100, Thomas Petazzoni wrote:
> This commit adjusts the mvpp2 driver register mapping and access logic
> to support PPv2.2, to handle a number of differences.
>
> Due to how the registers are laid out in memory, the Device Tree binding
> for the "reg" property is different:
>
> - On PPv2.1, we had a first area for the common registers, and then one
> area per port.
>
> - On PPv2.2, we have a first area for the common registers, and a
> second area for all the per-ports registers.
>
> In addition, on PPv2.2, the area for the common registers is split into
> so-called "address spaces" of 64 KB each. They allow to access the same
> registers, but from different CPUs. Hence the introduction of cpu_base[]
> in 'struct mvpp2', and the modification of the mvpp2_write() and
> mvpp2_read() register accessors. For PPv2.1, the compatibility is
> preserved by using an "address space" size of 0.
I'm not entirely sure this is the best solution - every register access
will be wrapped with a preempt_disable() and preempt_enable(). At
every site, when preempt is enabled, we will end up with code to:
- get the thread info
- increment the preempt count
- access the register
- decrement the preempt count
- test resulting preempt count and branch to __preempt_schedule()
If tracing is enabled, it gets much worse, because the increment and
decrement happen out of line, and are even more expensive.
If a function is going to make several register accesses, it's going
to be much more efficient to do:
void __iomem *base = priv->cpu_base[get_cpu()];
...
put_cpu();
which means we don't end up with multiple instances of the preempt code
consecutive accesses.
I think this is an example where having driver-private accessors for
readl()/writel() is far from a good idea.
--
RMK's Patch system: http://www.armlinux.org.uk/developer/patches/
FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up
according to speedtest.net.
^ permalink raw reply
* [RFC3 nowrap: PATCH v7 00/18] ILP32 for ARM64
From: Catalin Marinas @ 2017-01-06 14:47 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161218070823.GA1153@yury-N73SV>
On Sun, Dec 18, 2016 at 12:38:23PM +0530, Yury Norov wrote:
> On Fri, Oct 21, 2016 at 11:32:59PM +0300, Yury Norov wrote:
> > This series enables aarch64 with ilp32 mode, and as supporting work,
> > introduces ARCH_32BIT_OFF_T configuration option that is enabled for
> > existing 32-bit architectures but disabled for new arches (so 64-bit
> > off_t is is used by new userspace).
> >
> > This version is based on kernel v4.9-rc1. It works with glibc-2.24,
> > and tested with LTP.
>
> Hi Arnd, Catalin
>
> For last few days I'm trying to rebase this series on current master,
> and I see significant conflicts and regressions. In fact, every time
> I rebase on next rc1, I feel like I play a roulette.
>
> This is not a significant problem now because it's almost for sure
> that this series will not get into 4.10, for reasons not related to
> kernel code. And I have time to deal with regressions. But in general,
> I'd like to try my patches on top of other candidates for next merge
> window. I cannot read all emails in LKML, but I can easily detect
> problems and join to the discussion at early stage if I see any problem.
>
> This is probably a noob question, and there are well-known branches,
> like Andrew Morton's one. But at this stage it's very important to
> have this series prepared for merge, and I'd prefer to ask about it.
I'm not entirely sure what the question is. For development, you could
base your series on a final release, e.g. 4.9. For reviews and
especially if you are targeting a certain merging window, it's useful to
rebase your patches on a fairly recent -rc, e.g. 4.10-rc3. I would
entirely skip any non-tagged kernel states (like middle of the merging
window) or out of tree branches. There may be a case to rebase on some
other developer's branch but only if there is a dependency that can't be
avoided and usually with prior agreement from both the respective
developer (as not to rebase the branch) and the involved maintainers.
--
Catalin
^ permalink raw reply
* [PATCH 10/18] arm64: ilp32: introduce binfmt_ilp32.c
From: Catalin Marinas @ 2017-01-06 14:48 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161221185640.GA16562@yury-N73SV>
On Thu, Dec 22, 2016 at 12:26:40AM +0530, Yury Norov wrote:
> On Mon, Dec 05, 2016 at 03:38:01PM +0000, Catalin Marinas wrote:
> > On Fri, Oct 21, 2016 at 11:33:09PM +0300, Yury Norov wrote:
> > > binfmt_ilp32.c is needed to handle ILP32 binaries
> > >
> > > Signed-off-by: Yury Norov <ynorov@caviumnetworks.com>
> > > Signed-off-by: Bamvor Zhang Jian <bamvor.zhangjian@linaro.org>
> > > ---
> > > arch/arm64/include/asm/elf.h | 6 +++
> > > arch/arm64/kernel/Makefile | 1 +
> > > arch/arm64/kernel/binfmt_ilp32.c | 97 ++++++++++++++++++++++++++++++++++++++++
> > > 3 files changed, 104 insertions(+)
> > > create mode 100644 arch/arm64/kernel/binfmt_ilp32.c
> > >
> > > diff --git a/arch/arm64/include/asm/elf.h b/arch/arm64/include/asm/elf.h
> > > index f259fe8..be29dde 100644
> > > --- a/arch/arm64/include/asm/elf.h
> > > +++ b/arch/arm64/include/asm/elf.h
> > > @@ -175,10 +175,16 @@ extern int arch_setup_additional_pages(struct linux_binprm *bprm,
> > >
> > > #define COMPAT_ELF_ET_DYN_BASE (2 * TASK_SIZE_32 / 3)
> > >
> > > +#ifndef USE_AARCH64_GREG
> > > /* AArch32 registers. */
> > > #define COMPAT_ELF_NGREG 18
> > > typedef unsigned int compat_elf_greg_t;
> > > typedef compat_elf_greg_t compat_elf_gregset_t[COMPAT_ELF_NGREG];
> > > +#else /* AArch64 registers for AARCH64/ILP32 */
> > > +#define COMPAT_ELF_NGREG ELF_NGREG
> > > +#define compat_elf_greg_t elf_greg_t
> > > +#define compat_elf_gregset_t elf_gregset_t
> > > +#endif
> >
> > I think you only need compat_elf_gregset_t definition here and leave the
> > other two undefined.
>
> I checked everything here again, and found that almost all compat defines
> may be moved to corresponding binfmt files. If everything is OK, I'll
> incorporate next patch to the series
It seems fine at a quick look but I'll have to see the final patch.
--
Catalin
^ permalink raw reply
* [PATCH v6 3/4] arm64: arch_timer: Work around Erratum Hisilicon-161601
From: Marc Zyngier @ 2017-01-06 14:49 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1483594317-10732-4-git-send-email-dingtianhong@huawei.com>
On 05/01/17 05:31, Ding Tianhong wrote:
> Erratum Hisilicon-161601 says that the ARM generic timer counter "has the
> potential to contain an erroneous value when the timer value changes".
> Accesses to TVAL (both read and write) are also affected due to the implicit counter
> read. Accesses to CVAL are not affected.
>
> The workaround is to reread the system count registers until the value of the second
> read is larger than the first one by less than 32, the system counter can be guaranteed
> not to return wrong value twice by back-to-back read and the error value is always larger
> than the correct one by 32. Writes to TVAL are replaced with an equivalent write to CVAL.
>
> The workaround is enabled if the hisilicon,erratum-161601 property is found in
> the timer node in the device tree. This can be overridden with the
> clocksource.arm_arch_timer.hisilicon-161601 boot parameter, which allows KVM
> users to enable the workaround until a mechanism is implemented to
> automatically communicate this information.
>
> Fix some description for fsl erratum a008585.
>
> v2: Significant rework based on feedback, including seperate the fsl erratum a008585
> to another patch, update the erratum name and remove unwanted code.
>
> v3: Significant rework based on feedback, including fix some alignment problem, make the
> #define __hisi_161601_read_reg to be private to the .c file instead of being globally
> visible, add more accurate annotation and modify a bit of logical format to enable
> arch_timer_read_ool_enabled, remove the kernel commandline parameter
> clocksource.arm_arch_timer.hisilicon-161601.
>
> v5: Theoretically the erratum should not occur more than twice in succession when reading
> the system counter, but it is possible that some interrupts may lead to more than twice
> read errors, triggering the warning, so setting the number of retries to 50 which is far
> beyond the number of iterations the loop has been observed to take.
>
> v6: Mark the hisi_161601_read_xxx_el0 with notrace, if CONFIG_FUNCTION_GRAPH_TRACER selected,
> hisi_161601_read_xxx_el0 will be related to ftrace_graph_caller which will calling sched_clock
> to read system counter again, it will cause the system stall into an endless loop.
Please move the changelog to the cover letter, as I don't need
any of this to end-up in the commit log.
>
> Signed-off-by: Ding Tianhong <dingtianhong@huawei.com>
> ---
> Documentation/arm64/silicon-errata.txt | 1 +
> arch/arm64/include/asm/arch_timer.h | 2 +-
> drivers/clocksource/Kconfig | 9 +++++
> drivers/clocksource/arm_arch_timer.c | 70 +++++++++++++++++++++++++++++++---
> 4 files changed, 76 insertions(+), 6 deletions(-)
>
> diff --git a/Documentation/arm64/silicon-errata.txt b/Documentation/arm64/silicon-errata.txt
> index 405da11..1c1a95f 100644
> --- a/Documentation/arm64/silicon-errata.txt
> +++ b/Documentation/arm64/silicon-errata.txt
> @@ -63,3 +63,4 @@ stable kernels.
> | Cavium | ThunderX SMMUv2 | #27704 | N/A |
> | | | | |
> | Freescale/NXP | LS2080A/LS1043A | A-008585 | FSL_ERRATUM_A008585 |
> +| Hisilicon | Hip0{5,6,7} | #161601 | HISILICON_ERRATUM_161601|
> diff --git a/arch/arm64/include/asm/arch_timer.h b/arch/arm64/include/asm/arch_timer.h
> index f882c7c..ebf4cde 100644
> --- a/arch/arm64/include/asm/arch_timer.h
> +++ b/arch/arm64/include/asm/arch_timer.h
> @@ -29,7 +29,7 @@
>
> #include <clocksource/arm_arch_timer.h>
>
> -#if IS_ENABLED(CONFIG_FSL_ERRATUM_A008585)
> +#if IS_ENABLED(CONFIG_FSL_ERRATUM_A008585) || IS_ENABLED(CONFIG_HISILICON_ERRATUM_161601)
> extern struct static_key_false arch_timer_read_ool_enabled;
> #define needs_unstable_timer_counter_workaround() \
> static_branch_unlikely(&arch_timer_read_ool_enabled)
> diff --git a/drivers/clocksource/Kconfig b/drivers/clocksource/Kconfig
> index 4866f7a..162d820 100644
> --- a/drivers/clocksource/Kconfig
> +++ b/drivers/clocksource/Kconfig
> @@ -335,6 +335,15 @@ config FSL_ERRATUM_A008585
> value"). The workaround will only be active if the
> fsl,erratum-a008585 property is found in the timer node.
>
> +config HISILICON_ERRATUM_161601
> + bool "Workaround for Hisilicon Erratum 161601"
> + default y
> + depends on ARM_ARCH_TIMER && ARM64
> + help
> + This option enables a workaround for Hisilicon Erratum
> + 161601. The workaround will be active if the hisilicon,erratum-161601
> + property is found in the timer node.
> +
> config ARM_GLOBAL_TIMER
> bool "Support for the ARM global timer" if COMPILE_TEST
> select CLKSRC_OF if OF
> diff --git a/drivers/clocksource/arm_arch_timer.c b/drivers/clocksource/arm_arch_timer.c
> index f9097b6..078d38f 100644
> --- a/drivers/clocksource/arm_arch_timer.c
> +++ b/drivers/clocksource/arm_arch_timer.c
> @@ -95,15 +95,18 @@ static int __init early_evtstrm_cfg(char *buf)
> * Architected system timer support.
> */
>
> -#ifdef CONFIG_FSL_ERRATUM_A008585
> +#if CONFIG_FSL_ERRATUM_A008585 || IS_ENABLED(CONFIG_HISILICON_ERRATUM_161601)
This line looks horrible. it should probably be IS_ENABLED(CONFIG_FSL).
But more importantly, given that at least two independent SoC
manufacturers have managed to screw their timers in a similar way,
I'd expect that list to grow.
So please introduce a new config symbol (for example something like
CONFIG_ARM_ARCH_TIMER_OOL_WORKAROUND) which gets selected by individual
workarounds, and use that everywhere where you have both symbols.
> struct arch_timer_erratum_workaround *timer_unstable_counter_workaround = NULL;
> EXPORT_SYMBOL_GPL(timer_unstable_counter_workaround);
>
> #define FSL_A008585 0x0001
> +#define HISILICON_161601 0x0002
>
> DEFINE_STATIC_KEY_FALSE(arch_timer_read_ool_enabled);
> EXPORT_SYMBOL_GPL(arch_timer_read_ool_enabled);
> +#endif
>
> +#ifdef CONFIG_FSL_ERRATUM_A008585
> /*
> * The number of retries is an arbitrary value well beyond the highest number
> * of iterations the loop has been observed to take.
> @@ -145,6 +148,54 @@ static u64 notrace fsl_a008585_read_cntvct_el0(void)
> };
> #endif /* CONFIG_FSL_ERRATUM_A008585 */
>
> +#ifdef CONFIG_HISILICON_ERRATUM_161601
> +/*
> + * Verify whether the value of the second read is larger than the first by
> + * less than 32 is the only way to confirm the value is correct, so clear the
> + * lower 5 bits to check whether the difference is greater than 32 or not.
> + * Theoretically the erratum should not occur more than twice in succession
> + * when reading the system counter, but it is possible that some interrupts
> + * may lead to more than twice read errors, triggering the warning, so setting
> + * the number of retries far beyond the number of iterations the loop has been
> + * observed to take.
> + */
> +#define __hisi_161601_read_reg(reg) ({ \
> + u64 _old, _new; \
> + int _retries = 50; \
> + \
> + do { \
> + _old = read_sysreg(reg); \
> + _new = read_sysreg(reg); \
> + _retries--; \
> + } while (unlikely((_new - _old) >> 5) && _retries); \
> + \
> + WARN_ON_ONCE(!_retries); \
> + _new; \
> +})
> +
> +static u32 notrace hisi_161601_read_cntp_tval_el0(void)
> +{
> + return __hisi_161601_read_reg(cntp_tval_el0);
> +}
> +
> +static u32 notrace hisi_161601_read_cntv_tval_el0(void)
> +{
> + return __hisi_161601_read_reg(cntv_tval_el0);
> +}
> +
> +static u64 notrace hisi_161601_read_cntvct_el0(void)
> +{
> + return __hisi_161601_read_reg(cntvct_el0);
> +}
> +
> +static struct arch_timer_erratum_workaround arch_timer_hisi_161601 = {
> + .erratum = HISILICON_161601,
> + .read_cntp_tval_el0 = hisi_161601_read_cntp_tval_el0,
> + .read_cntv_tval_el0 = hisi_161601_read_cntv_tval_el0,
> + .read_cntvct_el0 = hisi_161601_read_cntvct_el0,
> +};
> +#endif /* CONFIG_HISILICON_ERRATUM_161601 */
> +
> static __always_inline
> void arch_timer_reg_write(int access, enum arch_timer_reg reg, u32 val,
> struct clock_event_device *clk)
> @@ -294,7 +345,7 @@ static __always_inline void set_next_event(const int access, unsigned long evt,
> arch_timer_reg_write(access, ARCH_TIMER_REG_CTRL, ctrl, clk);
> }
>
> -#ifdef CONFIG_FSL_ERRATUM_A008585
> +#if IS_ENABLED(CONFIG_FSL_ERRATUM_A008585) || IS_ENABLED(CONFIG_HISILICON_ERRATUM_161601)
> static __always_inline void erratum_set_next_event_generic(const int access,
> unsigned long evt, struct clock_event_device *clk)
> {
> @@ -358,7 +409,7 @@ static int arch_timer_set_next_event_phys_mem(unsigned long evt,
>
> static void erratum_workaround_set_sne(struct clock_event_device *clk)
> {
> -#ifdef CONFIG_FSL_ERRATUM_A008585
> +#if IS_ENABLED(CONFIG_FSL_ERRATUM_A008585) || IS_ENABLED(CONFIG_HISILICON_ERRATUM_161601)
> if (!static_branch_unlikely(&arch_timer_read_ool_enabled))
> return;
>
> @@ -618,7 +669,7 @@ static void __init arch_counter_register(unsigned type)
>
> clocksource_counter.archdata.vdso_direct = true;
>
> -#ifdef CONFIG_FSL_ERRATUM_A008585
> +#if IS_ENABLED(CONFIG_FSL_ERRATUM_A008585) || IS_ENABLED(CONFIG_HISILICON_ERRATUM_161601)
> /*
> * Don't use the vdso fastpath if errata require using
> * the out-of-line counter accessor.
> @@ -909,10 +960,19 @@ static int __init arch_timer_of_init(struct device_node *np)
> #ifdef CONFIG_FSL_ERRATUM_A008585
> if (!timer_unstable_counter_workaround && of_property_read_bool(np, "fsl,erratum-a008585"))
> timer_unstable_counter_workaround = &arch_timer_fsl_a008585;
> +#endif
> +
> +#ifdef CONFIG_HISILICON_ERRATUM_161601
> + if (!timer_unstable_counter_workaround && of_property_read_bool(np, "hisilicon,erratum-161601"))
> + timer_unstable_counter_workaround = &arch_timer_hisi_161601;
> +#endif
>
> +#if IS_ENABLED(CONFIG_FSL_ERRATUM_A008585) || IS_ENABLED(CONFIG_HISILICON_ERRATUM_161601)
> if (timer_unstable_counter_workaround) {
> static_branch_enable(&arch_timer_read_ool_enabled);
> - pr_info("Enabling workaround for FSL erratum A-008585\n");
> + pr_info("Enabling workaround for %s\n",
> + timer_unstable_counter_workaround->erratum == FSL_A008585 ?
> + "FSL ERRATUM A-008585" : "HISILICON ERRATUM 161601");
> }
> #endif
This looks extremely messy, and maybe it is time you properly refactor
the whole thing so that we can scale. I came up with the following
approach, which seems more manageable:
diff --git a/arch/arm64/include/asm/arch_timer.h b/arch/arm64/include/asm/arch_timer.h
index ebf4cde..1f89d94 100644
--- a/arch/arm64/include/asm/arch_timer.h
+++ b/arch/arm64/include/asm/arch_timer.h
@@ -37,15 +37,14 @@ extern struct static_key_false arch_timer_read_ool_enabled;
#define needs_unstable_timer_counter_workaround() false
#endif
-
struct arch_timer_erratum_workaround {
- int erratum; /* Indicate the Erratum ID */
+ const char *id;
u32 (*read_cntp_tval_el0)(void);
u32 (*read_cntv_tval_el0)(void);
u64 (*read_cntvct_el0)(void);
};
-extern struct arch_timer_erratum_workaround *timer_unstable_counter_workaround;
+extern const struct arch_timer_erratum_workaround *timer_unstable_counter_workaround;
#define arch_timer_reg_read_stable(reg) \
({ \
diff --git a/drivers/clocksource/arm_arch_timer.c b/drivers/clocksource/arm_arch_timer.c
index c069f1a..0dd80e6 100644
--- a/drivers/clocksource/arm_arch_timer.c
+++ b/drivers/clocksource/arm_arch_timer.c
@@ -96,12 +96,9 @@ early_param("clocksource.arm_arch_timer.evtstrm", early_evtstrm_cfg);
*/
#if CONFIG_FSL_ERRATUM_A008585 || IS_ENABLED(CONFIG_HISILICON_ERRATUM_161601)
-struct arch_timer_erratum_workaround *timer_unstable_counter_workaround = NULL;
+const struct arch_timer_erratum_workaround *timer_unstable_counter_workaround;
EXPORT_SYMBOL_GPL(timer_unstable_counter_workaround);
-#define FSL_A008585 0x0001
-#define HISILICON_161601 0x0002
-
DEFINE_STATIC_KEY_FALSE(arch_timer_read_ool_enabled);
EXPORT_SYMBOL_GPL(arch_timer_read_ool_enabled);
#endif
@@ -139,13 +136,6 @@ static u64 notrace fsl_a008585_read_cntvct_el0(void)
{
return __fsl_a008585_read_reg(cntvct_el0);
}
-
-static struct arch_timer_erratum_workaround arch_timer_fsl_a008585 = {
- .erratum = FSL_A008585,
- .read_cntp_tval_el0 = fsl_a008585_read_cntp_tval_el0,
- .read_cntv_tval_el0 = fsl_a008585_read_cntv_tval_el0,
- .read_cntvct_el0 = fsl_a008585_read_cntvct_el0,
-};
#endif /* CONFIG_FSL_ERRATUM_A008585 */
#ifdef CONFIG_HISILICON_ERRATUM_161601
@@ -187,13 +177,6 @@ static u64 notrace hisi_161601_read_cntvct_el0(void)
{
return __hisi_161601_read_reg(cntvct_el0);
}
-
-static struct arch_timer_erratum_workaround arch_timer_hisi_161601 = {
- .erratum = HISILICON_161601,
- .read_cntp_tval_el0 = hisi_161601_read_cntp_tval_el0,
- .read_cntv_tval_el0 = hisi_161601_read_cntv_tval_el0,
- .read_cntvct_el0 = hisi_161601_read_cntvct_el0,
-};
#endif /* CONFIG_HISILICON_ERRATUM_161601 */
static __always_inline
@@ -346,6 +329,25 @@ static __always_inline void set_next_event(const int access, unsigned long evt,
}
#if IS_ENABLED(CONFIG_FSL_ERRATUM_A008585) || IS_ENABLED(CONFIG_HISILICON_ERRATUM_161601)
+static const struct arch_timer_erratum_workaround ool_workarounds[] = {
+#ifdef CONFIG_FSL_ERRATUM_A008585
+ {
+ .id = "fsl,erratum-a008585",
+ .read_cntp_tval_el0 = fsl_a008585_read_cntp_tval_el0,
+ .read_cntv_tval_el0 = fsl_a008585_read_cntv_tval_el0,
+ .read_cntvct_el0 = fsl_a008585_read_cntvct_el0,
+ },
+#endif
+#ifdef CONFIG_HISILICON_ERRATUM_161601
+ {
+ .id = "hisilicon,erratum-161601",
+ .read_cntp_tval_el0 = hisi_161601_read_cntp_tval_el0,
+ .read_cntv_tval_el0 = hisi_161601_read_cntv_tval_el0,
+ .read_cntvct_el0 = hisi_161601_read_cntvct_el0,
+ },
+#endif
+};
+
static __always_inline void erratum_set_next_event_generic(const int access,
unsigned long evt, struct clock_event_device *clk)
{
@@ -957,22 +959,15 @@ static int __init arch_timer_of_init(struct device_node *np)
arch_timer_c3stop = !of_property_read_bool(np, "always-on");
-#ifdef CONFIG_FSL_ERRATUM_A008585
- if (!timer_unstable_counter_workaround && of_property_read_bool(np, "fsl,erratum-a008585"))
- timer_unstable_counter_workaround = &arch_timer_fsl_a008585;
-#endif
-
-#ifdef CONFIG_HISILICON_ERRATUM_161601
- if (!timer_unstable_counter_workaround && of_property_read_bool(np, "hisilicon,erratum-161601"))
- timer_unstable_counter_workaround = &arch_timer_hisi_161601;
-#endif
-
#if IS_ENABLED(CONFIG_FSL_ERRATUM_A008585) || IS_ENABLED(CONFIG_HISILICON_ERRATUM_161601)
- if (timer_unstable_counter_workaround) {
- static_branch_enable(&arch_timer_read_ool_enabled);
- pr_info("Enabling workaround for %s\n",
- timer_unstable_counter_workaround->erratum == FSL_A008585 ?
- "FSL ERRATUM A-008585" : "HISILICON ERRATUM 161601");
+ for (i = 0; i < ARRAY_SIZE(ool_workarounds); i++) {
+ if (of_property_read_bool(np, ool_workarounds[i].id)) {
+ timer_unstable_counter_workaround = &ool_workarounds[i];
+ static_branch_enable(&arch_timer_read_ool_enabled);
+ pr_info("Enabling workaround %s\n",
+ timer_unstable_counter_workaround->id);
+ break;
+ }
}
#endif
Thoughts?
M.
--
Jazz is not dead. It just smells funny...
^ permalink raw reply related
* [PATCH net-next v4 0/4] Fix OdroidC2 Gigabit Tx link issue
From: Russell King - ARM Linux @ 2017-01-06 15:05 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1483710621.28003.74.camel@baylibre.com>
(quick reply...)
On Fri, Jan 06, 2017 at 02:50:21PM +0100, Jerome Brunet wrote:
> So I'm not sure I understand, are you against EEE integration in phylib
> entirely, or specifically against the test I added in set_eee to filter
> out broken modes ?
I'm happy to see EEE integrated into phylib, but I think the current
implementation is very buggy and needs a rewrite.
> > BTW, one of the problems (not caused by your patch) is that changing
> > the EEE advertisment does not (on all PHY drivers) cause the link to
> > be renegotiated - there's no call to phy_start_aneg() when the advert
> > changes, and even if there was, there's no guarantee that
> > phy_start_aneg() will even set the AN restart bit in the control
> > register.
> >
> > However, given that you're hooking into the set_eee function, I'm not
> > sure why you placed your EEE advertisment thing into config_aneg() -
> > isn't it more an initialisation thing (so should be in
> > config_init()?)
>
> What I change is what the PHY advertise, so it seems logical to do it
> where "genphy_config_advert" was called. Just taking the existing code
> as an example
You need to adjust the adverisment in two places:
1. On initialisation, when you need to change the default value.
2. Whenever the user requests a different EEE advertisment.
You don't need to do it each time config_aneg() is called - nothing's
going to change the EEE advertisment in that path. Hence, to check
it each and every time seems like a waste of CPU cycles.
However, there's another path that needs to be considered, which the
current EEE code fails to do, and that is the resume path. Nothing
at present saves and restores the EEE settings, they are completely
lost if the PHY is powered down. This is just another symptom of the
current poor quality EEE implementation in phylib, and another reason
why I say above that the EEE code is in need of a rewrite... which is
something I will be looking at.
If the EEE settings are properly saved and restored over suspend/
resume, then the previously programmed EEE advertisment would also
be restored.
--
RMK's Patch system: http://www.armlinux.org.uk/developer/patches/
FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up
according to speedtest.net.
^ permalink raw reply
* [RFC PATCH 1/7] arm64: Use physical counter for in-kernel reads
From: Marc Zyngier @ 2017-01-06 15:16 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20170106105301.GB27758@cbox>
On 06/01/17 10:53, Christoffer Dall wrote:
> On Fri, Jan 06, 2017 at 10:38:49AM +0000, Marc Zyngier wrote:
>> On 06/01/17 10:00, Christoffer Dall wrote:
>>> Hi Marc,
>>>
>>> On Thu, Jan 05, 2017 at 06:11:14PM +0000, Marc Zyngier wrote:
>>>> [adding the arm64 maintainers, plus Mark as arch timer maintainer]
>>>
>>> Right, sorry, I should have done that already.
>>>
>>>>
>>>> On 10/12/16 20:47, Christoffer Dall wrote:
>>>>> Using the physical counter allows KVM to retain the offset between the
>>>>> virtual and physical counter as long as it is actively running a VCPU.
>>>>>
>>>>> As soon as a VCPU is released, another thread is scheduled or we start
>>>>> running userspace applications, we reset the offset to 0, so that VDSO
>>>>> operations can still read the virtual counter and get the same view of
>>>>> time as the kernel.
>>>>>
>>>>> This opens up potential improvements for KVM performance.
>>>>>
>>>>> VHE kernels or kernels using the virtual timer are unaffected by this.
>>>>>
>>>>> Signed-off-by: Christoffer Dall <christoffer.dall@linaro.org>
>>>>> ---
>>>>> arch/arm64/include/asm/arch_timer.h | 6 ++++--
>>>>> drivers/clocksource/arm_arch_timer.c | 2 +-
>>>>> 2 files changed, 5 insertions(+), 3 deletions(-)
>>>>>
>>>>> diff --git a/arch/arm64/include/asm/arch_timer.h b/arch/arm64/include/asm/arch_timer.h
>>>>> index eaa5bbe..cec2549 100644
>>>>> --- a/arch/arm64/include/asm/arch_timer.h
>>>>> +++ b/arch/arm64/include/asm/arch_timer.h
>>>>> @@ -139,11 +139,13 @@ static inline void arch_timer_set_cntkctl(u32 cntkctl)
>>>>>
>>>>> static inline u64 arch_counter_get_cntpct(void)
>>>>> {
>>>>> + u64 cval;
>>>>> /*
>>>>> * AArch64 kernel and user space mandate the use of CNTVCT.
>>>>> */
>>>>> - BUG();
>>>>> - return 0;
>>>>> + isb();
>>>>> + asm volatile("mrs %0, cntpct_el0" : "=r" (cval));
>>>>> + return cval;
>>>>> }
>>>>>
>>>>> static inline u64 arch_counter_get_cntvct(void)
>>>>> diff --git a/drivers/clocksource/arm_arch_timer.c b/drivers/clocksource/arm_arch_timer.c
>>>>> index 73c487d..a5b0789 100644
>>>>> --- a/drivers/clocksource/arm_arch_timer.c
>>>>> +++ b/drivers/clocksource/arm_arch_timer.c
>>>>> @@ -597,7 +597,7 @@ static void __init arch_counter_register(unsigned type)
>>>>>
>>>>> /* Register the CP15 based counter if we have one */
>>>>> if (type & ARCH_CP15_TIMER) {
>>>>> - if (IS_ENABLED(CONFIG_ARM64) || arch_timer_uses_ppi == VIRT_PPI)
>>>>> + if (arch_timer_uses_ppi == VIRT_PPI || is_kernel_in_hyp_mode())
>>>>
>>>> Why do we have this is_kernel_in_hyp_mode clause? I can't think of any
>>>> reason for a VHE kernel to use the virtual counter at all...
>>>>
>>>
>>> Good question. I think I just didn't want to change behavior from the
>>> existing functionality mre than necessary.
>>>
>>> Note that on a VHE kernel this will be the EL2 virtual counter, not the
>>> EL1 virtual counter, due to the register redirection. Are the virtual
>>> and physical EL2 counters always equivalent on a VHE system?
>>
>> Yes, they are. CNTVOFF_EL2 is ignored in that case, and you get an extra
>> interrupt for the new EL2 virtual timer as well.
>>
>
> ok, in that case I suppose I can just check for arch_timer_uses_ppi ==
> VIRT_PPI and be done with it.
I wonder what we should do for get_cycles(), which is hardwired to the
virtual counter at the moment. If we decide to use the physical counter
on systems identified as hosts, we may have to revise this as well (I
feel the need for an alternative... ;-).
Thanks,
M.
--
Jazz is not dead. It just smells funny...
^ permalink raw reply
* [PATCH v11 0/8] power: add power sequence library
From: Krzysztof Kozlowski @ 2017-01-06 15:18 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1483596119-27508-1-git-send-email-peter.chen@nxp.com>
On Thu, Jan 05, 2017 at 02:01:51PM +0800, Peter Chen wrote:
> Hi all,
>
> This is a follow-up for my last power sequence framework patch set [1].
> According to Rob Herring and Ulf Hansson's comments[2]. The kinds of
> power sequence instances will be added at postcore_initcall, the match
> criteria is compatible string first, if the compatible string is not
> matched between dts and library, it will try to use generic power sequence.
>
> The host driver just needs to call of_pwrseq_on/of_pwrseq_off
> if only one power sequence instance is needed, for more power sequences
> are used, using of_pwrseq_on_list/of_pwrseq_off_list instead (eg, USB hub driver).
>
> In future, if there are special power sequence requirements, the special
> power sequence library can be created.
>
> This patch set is tested on i.mx6 sabresx evk using a dts change, I use
> two hot-plug devices to simulate this use case, the related binding
> change is updated at patch [1/6], The udoo board changes were tested
> using my last power sequence patch set.[3]
>
> Except for hard-wired MMC and USB devices, I find the USB ULPI PHY also
> need to power on itself before it can be found by ULPI bus.
>
> [1] http://www.spinics.net/lists/linux-usb/msg142755.html
> [2] http://www.spinics.net/lists/linux-usb/msg143106.html
> [3] http://www.spinics.net/lists/linux-usb/msg142815.html
>
Unfortunately I was unable to utilize this library to solve Odroid U3
usb3503/lan9730 power sequence (as a continuation of my old series [0][1]).
The main problem is that power sequence instance (pwrseq_generic.c) is
not a device. I don't get why it is not a device. It would be rather
intuitive to me to make it a device. Also it would make life easier
because you could use all device-like consumer APIs (of getting clocks,
GPIOs etc). Since it is not a device, it is not possible to use
regulator consumer API.
I need a regulator because I need to toggle the power.
Other encountered issue is that power sequence happens early, before the
unused regulators are turned off by the system. However maybe this is
the necessity from other point of view.
My case is annoyingly over-complicated so I am slowly getting sertain
that it is not generic. Anyway it looks like this:
EHCI controller
|
|--HSIC0--lan9730 (reset is done only through regulator)
|--HSIC1--usb3504 (it has a reset GPIO... but it is toggled by
usb3504 driver)
Overall, I want to reset the lan9730. This can be done only through
power - buck8. buck8 state is an logical OR of register set by I2C and
GPIO. Thus to turn it off, it is not sufficient just to set register to
0x0 because the GPIO is keeping it on. The best way is to switch the
buck8 to gpio-enable-control thus only GPIO will be toggling it... still
through the regulator consumer API (because it is an GPIO for the
regulator, not for the reset!).
However these two seems coupled. On invalid reset sequence, both chips
die. The usb3504 has its own existing reset sequence and my findings
show that it should happen after lan9730 reset sequence. Otherwise all
devices might be lost...
[0] http://www.spinics.net/lists/linux-mmc/msg37386.html
[1] https://github.com/krzk/linux/commits/for-next/odroid-u3-usb3503-lan-boot-fixes-v4
Best regards,
Krzysztof
> Changes for v11:
> - Fix warning: (USB) selects POWER_SEQUENCE which has unmet direct dependencies (OF)
> - Delete redundant copyright statement.
> - Change pr_warn to pr_debug at wrseq_find_available_instance
> - Refine kerneldoc
> - %s/ENONET/ENOENT
> - Allocate pwrseq list node before than carry out power sequence on
> - Add mutex_lock/mutex_lock for pwrseq node browse at pwrseq_find_available_instance
> - Add pwrseq_suspend/resume for API both single instance and list
> - Add .pwrseq_suspend/resume for pwrseq_generic.c
> - Add pwrseq_suspend_list and pwrseq_resume_list for USB hub suspend
> and resume routine
>
> Changes for v10:
> - Improve the kernel-doc for power sequence core, including exported APIs and
> main structure. [Patch 2/8]
> - Change Kconfig, and let the user choose power sequence. [Patch 2/8]
> - Delete EXPORT_SYMBOL and change related APIs as local, these APIs do not
> be intended to export currently. [Patch 2/8]
> - Selete POWER_SEQUENCE at USB core's Kconfig. [Patch 4/8]
>
> Changes for v9:
> - Add Vaibhav Hiremath's reviewed-by [Patch 4/8]
> - Rebase to v4.9-rc1
>
> Changes for v8:
> - Allocate one extra pwrseq instance if pwrseq_get has succeed, it can avoid
> preallocate instances problem which the number of instance is decided at
> compile time, thanks for Heiko Stuebner's suggestion [Patch 2/8]
> - Delete pwrseq_compatible_sample.c which is the demo purpose to show compatible
> match method. [Patch 2/8]
> - Add Maciej S. Szmigiero's tested-by. [Patch 7/8]
>
> Changes for v7:
> - Create kinds of power sequence instance at postcore_initcall, and match
> the instance with node using compatible string, the beneit of this is
> the host driver doesn't need to consider which pwrseq instance needs
> to be used, and pwrseq core will match it, however, it eats some memories
> if less power sequence instances are used. [Patch 2/8]
> - Add pwrseq_compatible_sample.c to test match pwrseq using device_id. [Patch 2/8]
> - Fix the comments Vaibhav Hiremath adds for error path for clock and do not
> use device_node for parameters at pwrseq_on. [Patch 2/8]
> - Simplify the caller to use power sequence, follows Alan's commnets [Patch 4/8]
> - Tested three pwrseq instances together using both specific compatible string and
> generic libraries.
>
> Changes for v6:
> - Add Matthias Kaehlcke's Reviewed-by and Tested-by. (patch [2/6])
> - Change chipidea core of_node assignment for coming user. (patch [5/6])
> - Applies Joshua Clayton's three dts changes for two boards,
> the USB device's reg has only #address-cells, but without #size-cells.
>
> Changes for v5:
> - Delete pwrseq_register/pwrseq_unregister, which is useless currently
> - Fix the linker error when the pwrseq user is compiled as module
>
> Changes for v4:
> - Create the patch on next-20160722
> - Fix the of_node is not NULL after chipidea driver is unbinded [Patch 5/6]
> - Using more friendly wait method for reset gpio [Patch 2/6]
> - Support multiple input clocks [Patch 2/6]
> - Add Rob Herring's ack for DT changes
> - Add Joshua Clayton's Tested-by
>
> Changes for v3:
> - Delete "power-sequence" property at binding-doc, and change related code
> at both library and user code.
> - Change binding-doc example node name with Rob's comments
> - of_get_named_gpio_flags only gets the gpio, but without setting gpio flags,
> add additional code request gpio with proper gpio flags
> - Add Philipp Zabel's Ack and MAINTAINER's entry
>
> Changes for v2:
> - Delete "pwrseq" prefix and clock-names for properties at dt binding
> - Should use structure not but its pointer for kzalloc
> - Since chipidea core has no of_node, let core's of_node equals glue
> layer's at core's probe
>
> Joshua Clayton (2):
> ARM: dts: imx6qdl: Enable usb node children with <reg>
> ARM: dts: imx6q-evi: Fix onboard hub reset line
>
> Peter Chen (6):
> binding-doc: power: pwrseq-generic: add binding doc for generic power
> sequence library
> power: add power sequence library
> binding-doc: usb: usb-device: add optional properties for power
> sequence
> usb: core: add power sequence handling for USB devices
> usb: chipidea: let chipidea core device of_node equal's glue layer
> device of_node
> ARM: dts: imx6qdl-udoo.dtsi: fix onboard USB HUB property
>
> .../bindings/power/pwrseq/pwrseq-generic.txt | 48 +++
> .../devicetree/bindings/usb/usb-device.txt | 10 +-
> MAINTAINERS | 9 +
> arch/arm/boot/dts/imx6q-evi.dts | 25 +-
> arch/arm/boot/dts/imx6qdl-udoo.dtsi | 26 +-
> arch/arm/boot/dts/imx6qdl.dtsi | 6 +
> drivers/power/Kconfig | 1 +
> drivers/power/Makefile | 1 +
> drivers/power/pwrseq/Kconfig | 20 ++
> drivers/power/pwrseq/Makefile | 2 +
> drivers/power/pwrseq/core.c | 335 +++++++++++++++++++++
> drivers/power/pwrseq/pwrseq_generic.c | 224 ++++++++++++++
> drivers/usb/Kconfig | 1 +
> drivers/usb/chipidea/core.c | 27 +-
> drivers/usb/core/hub.c | 48 ++-
> drivers/usb/core/hub.h | 1 +
> include/linux/power/pwrseq.h | 81 +++++
> 17 files changed, 823 insertions(+), 42 deletions(-)
> create mode 100644 Documentation/devicetree/bindings/power/pwrseq/pwrseq-generic.txt
> create mode 100644 drivers/power/pwrseq/Kconfig
> create mode 100644 drivers/power/pwrseq/Makefile
> create mode 100644 drivers/power/pwrseq/core.c
> create mode 100644 drivers/power/pwrseq/pwrseq_generic.c
> create mode 100644 include/linux/power/pwrseq.h
>
> --
> 2.7.4
>
^ permalink raw reply
* [PATCH] arm64: dts: juno: Fix CoreSight support for Juno r1/r2 variants
From: Sudeep Holla @ 2017-01-06 15:27 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1483637646-39229-1-git-send-email-mike.leach@linaro.org>
+Suzuki
Hi Mike,
Thanks for fixing the R1/2 CS support. Suzuki was also looking at fixing it.
On 05/01/17 17:34, Mike Leach wrote:
> The CoreSight support added for Juno is valid for only Juno r0.
> The Juno r1 and r2 variants have additional components and alternative
> connection routes between trace source and sinks.
>
> The CoreSight infrastructure external to the Cortex-Axx clusters, has
> been split into separate .dtsi include files for r0 and r1/r2 to correctly
> represent these variations.
>
> Adds missing DT entry for the CoreSight STM component in the infrastructure
> .dtsi files.
>
STM support can be a separate patch as it's a new feature added.
> Signed-off-by: Mike Leach <mike.leach@linaro.org>
> ---
> arch/arm64/boot/dts/arm/juno-base.dtsi | 135 ---------------
> arch/arm64/boot/dts/arm/juno-cs-r0.dtsi | 166 +++++++++++++++++++
> arch/arm64/boot/dts/arm/juno-cs-r1r2.dtsi | 266 ++++++++++++++++++++++++++++++
> arch/arm64/boot/dts/arm/juno-r1.dts | 1 +
> arch/arm64/boot/dts/arm/juno-r2.dts | 1 +
> arch/arm64/boot/dts/arm/juno.dts | 1 +
> 6 files changed, 435 insertions(+), 135 deletions(-)
> create mode 100644 arch/arm64/boot/dts/arm/juno-cs-r0.dtsi
> create mode 100644 arch/arm64/boot/dts/arm/juno-cs-r1r2.dtsi
>
> diff --git a/arch/arm64/boot/dts/arm/juno-base.dtsi b/arch/arm64/boot/dts/arm/juno-base.dtsi
> index 7d83224..7c89000 100644
> --- a/arch/arm64/boot/dts/arm/juno-base.dtsi
> +++ b/arch/arm64/boot/dts/arm/juno-base.dtsi
[...]
> +
> + stm at 20100000 {
> + compatible = "arm,coresight-stm", "arm,primecell";
> + reg = <0 0x20100000 0 0x1000>,
> + <0 0x28000000 0 0x180000>;
> + reg-names = "stm-base", "stm-stimulus-base";
> +
> + clocks = <&soc_smc50mhz>;
> + clock-names = "apb_pclk";
> + power-domains = <&scpi_devpd 0>;
> + port {
> + stm_out_port: endpoint {
> + remote-endpoint = <&main_funnel_in_port2>;
> + };
> + };
> + };
As mentioned above move this to a different patch.
--
Regards,
Sudeep
^ permalink raw reply
* [PATCH v2 2/5] arm64: Work around Falkor erratum 1003
From: Christopher Covington @ 2017-01-06 15:39 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1dfdc578-e0f8-1320-d223-c9c55e70ca93@codeaurora.org>
On 12/29/2016 06:02 PM, Timur Tabi wrote:
> On 12/29/2016 04:43 PM, Christopher Covington wrote:
>> -| Implementor | Component | Erratum ID | Kconfig |
>> -+----------------+-----------------+-----------------+-------------------------+
>> -| ARM | Cortex-A53 | #826319 | ARM64_ERRATUM_826319 |
>> -| ARM | Cortex-A53 | #827319 | ARM64_ERRATUM_827319 |
>> -| ARM | Cortex-A53 | #824069 | ARM64_ERRATUM_824069 |
>> -| ARM | Cortex-A53 | #819472 | ARM64_ERRATUM_819472 |
>> -| ARM | Cortex-A53 | #845719 | ARM64_ERRATUM_845719 |
>> -| ARM | Cortex-A53 | #843419 | ARM64_ERRATUM_843419 |
>> -| ARM | Cortex-A57 | #832075 | ARM64_ERRATUM_832075 |
>> -| ARM | Cortex-A57 | #852523 | N/A |
>> -| ARM | Cortex-A57 | #834220 | ARM64_ERRATUM_834220 |
>> -| ARM | Cortex-A72 | #853709 | N/A |
>> -| ARM | MMU-500 | #841119,#826419 | N/A |
>> -| | | | |
>> -| Cavium | ThunderX ITS | #22375, #24313 | CAVIUM_ERRATUM_22375 |
>> -| Cavium | ThunderX ITS | #23144 | CAVIUM_ERRATUM_23144 |
>> -| Cavium | ThunderX GICv3 | #23154 | CAVIUM_ERRATUM_23154 |
>> -| Cavium | ThunderX Core | #27456 | CAVIUM_ERRATUM_27456 |
>> -| Cavium | ThunderX SMMUv2 | #27704 | N/A |
>> -| | | | |
>> -| Freescale/NXP | LS2080A/LS1043A | A-008585 | FSL_ERRATUM_A008585 |
>> +| Implementor | Component | Erratum ID | Kconfig |
>> ++---------------+-----------------+-----------------+--------------------------+
>> +| ARM | Cortex-A53 | #826319 | ARM64_ERRATUM_826319 |
>> +| ARM | Cortex-A53 | #827319 | ARM64_ERRATUM_827319 |
>> +| ARM | Cortex-A53 | #824069 | ARM64_ERRATUM_824069 |
>> +| ARM | Cortex-A53 | #819472 | ARM64_ERRATUM_819472 |
>> +| ARM | Cortex-A53 | #845719 | ARM64_ERRATUM_845719 |
>> +| ARM | Cortex-A53 | #843419 | ARM64_ERRATUM_843419 |
>> +| ARM | Cortex-A57 | #832075 | ARM64_ERRATUM_832075 |
>> +| ARM | Cortex-A57 | #852523 | N/A |
>> +| ARM | Cortex-A57 | #834220 | ARM64_ERRATUM_834220 |
>> +| ARM | Cortex-A72 | #853709 | N/A |
>> +| ARM | MMU-500 | #841119,#826419 | N/A |
>> +| | | | |
>> +| Cavium | ThunderX ITS | #22375, #24313 | CAVIUM_ERRATUM_22375 |
>> +| Cavium | ThunderX ITS | #23144 | CAVIUM_ERRATUM_23144 |
>> +| Cavium | ThunderX GICv3 | #23154 | CAVIUM_ERRATUM_23154 |
>> +| Cavium | ThunderX Core | #27456 | CAVIUM_ERRATUM_27456 |
>> +| Cavium | ThunderX SMMUv2 | #27704 | N/A |
>> +| | | | |
>> +| Freescale/NXP | LS2080A/LS1043A | A-008585 | FSL_ERRATUM_A008585 |
>> +| Qualcomm | Falkor v1 | E1003 | QCOM_FALKOR_ERRATUM_1003 |
>
> Looks like you've made an unrelated whitespace change that affected the entire table,
> not just the line you're adding.
I'm making space for "QCOM_FALKOR_ERRATUM_1003".
Cov
--
Qualcomm Datacenter Technologies, Inc. as an affiliate of Qualcomm
Technologies, Inc. Qualcomm Technologies, Inc. is a member of the Code
Aurora Forum, a Linux Foundation Collaborative Project.
^ permalink raw reply
* [PATCH v2 2/5] arm64: Work around Falkor erratum 1003
From: Christopher Covington @ 2017-01-06 15:44 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <ac275374-2aa6-43ec-25c9-6a3fec4ceedc@codeaurora.org>
On 12/29/2016 06:08 PM, Timur Tabi wrote:
> On 12/29/2016 04:43 PM, Christopher Covington wrote:
>> +config QCOM_FALKOR_E1003_RESERVED_ASID
>> + int
>> + default 1
>> + depends on QCOM_FALKOR_ERRATUM_1003
>
> Also, since this can't be changed via the menu, why bother putting it in?
I put it in in response to review comments asking for the magic number to
be clarified by a #define or variable. I could not find a suitably shared
header between the files in question, so I used the Kconfig machinery to
generate the #define.
Cov
--
Qualcomm Datacenter Technologies, Inc. as an affiliate of Qualcomm
Technologies, Inc. Qualcomm Technologies, Inc. is a member of the Code
Aurora Forum, a Linux Foundation Collaborative Project.
^ permalink raw reply
* [PATCH v2 2/5] arm64: Work around Falkor erratum 1003
From: Timur Tabi @ 2017-01-06 15:49 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <54ceb523-47ea-f137-293f-0da0166bb14b@codeaurora.org>
Christopher Covington wrote:
>> > Also, since this can't be changed via the menu, why bother putting it in?
> I put it in in response to review comments asking for the magic number to
> be clarified by a #define or variable. I could not find a suitably shared
> header between the files in question, so I used the Kconfig machinery to
> generate the #define.
I don't think that's the right approach. Kconfigs are not an
alternative to header files. Is the ASID configurable? If you just put
some text after the "int" then it because a menu option that the user
can select and change.
--
Sent by an employee of the Qualcomm Innovation Center, Inc.
The Qualcomm Innovation Center, Inc. is a member of the
Code Aurora Forum, hosted by The Linux Foundation.
^ permalink raw reply
* [PATCH v2 2/5] arm64: Work around Falkor erratum 1003
From: Christopher Covington @ 2017-01-06 15:49 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20170103155502.GA14183@leverpostej>
On 01/03/2017 10:55 AM, Mark Rutland wrote:
> Hi,
>
> On Thu, Dec 29, 2016 at 05:43:32PM -0500, Christopher Covington wrote:
>> +config QCOM_FALKOR_E1003_RESERVED_ASID
>> + int
>> + default 1
>> + depends on QCOM_FALKOR_ERRATUM_1003
>> +
>
> I don't think this needs to be configurable, so let's drop this into a
> header, e.g. drop:
>
> #define FALKOR_RESERVED_ASID 1
>
> ... in <asm/mmu_context.h>, protecting the rest with an ifndef
> __ASSEMBLY__ guard.
Will do, thanks for the concrete suggestion.
> [...]
>
>> +#ifdef CONFIG_QCOM_FALKOR_ERRATUM_1003
>> +alternative_if ARM64_WORKAROUND_QCOM_FALKOR_E1003
>> + mrs x2, ttbr0_el1 // get cuurent TTBR0_EL1
>> + mov x3, #CONFIG_QCOM_FALKOR_ERRATUM_1003 // reserved ASID
>
> Wrong macro? That's not the ASID.
Oops, thanks for spotting.
Cov
--
Qualcomm Datacenter Technologies, Inc. as an affiliate of Qualcomm
Technologies, Inc. Qualcomm Technologies, Inc. is a member of the Code
Aurora Forum, a Linux Foundation Collaborative Project.
^ permalink raw reply
* [PATCH v2 2/5] arm64: Work around Falkor erratum 1003
From: Timur Tabi @ 2017-01-06 15:51 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <fd82e2bf-5259-2fda-c931-1996387d779f@codeaurora.org>
Christopher Covington wrote:
>> > Looks like you've made an unrelated whitespace change that affected the entire table,
>> > not just the line you're adding.
> I'm making space for "QCOM_FALKOR_ERRATUM_1003".
Ok, but you're also shrinking the other columns. I think a better
solution is to make the macro shorter. QCOM_ERRATUM_FLK1003?
--
Sent by an employee of the Qualcomm Innovation Center, Inc.
The Qualcomm Innovation Center, Inc. is a member of the
Code Aurora Forum, hosted by The Linux Foundation.
^ 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