* Constantly map and unmap of streaming DMA buffers with IOMMU backend might cause serious performance problem
From: Song Bao Hua @ 2020-05-15 8:19 UTC (permalink / raw)
To: linux@armlinux.org.uk, hch@lst.de, m.szyprowski@samsung.com,
robin.murphy@arm.com, dagum@barrel.engr.sgi.com, ralf@oss.sgi.com,
grundler@cup.hp.com, Jay.Estabrook@compaq.com,
sailer@ife.ee.ethz.ch, andrea@suse.de, jens.axboe@oracle.com,
davidm@hpl.hp.com
Cc: iommu@lists.linux-foundation.org, Linuxarm,
linux-arm-kernel@lists.infradead.org
Hi Russell & All,
In many DMA streaming map/unmap use cases, lower-layer device drivers completely have no idea how and when single/sg buffers are allocated and freed by upper-layer filesystem, network protocol, mm management system etc. So the only thing device drivers can do is constantly mapping the buffer before DMA begins and unmapping the buffer when DMA is done.
This will dramatically increase the latency of dma_map_single/sg and dma_unmap_single/sg when these APIs are bound with the IOMMU backend. As for each map, iommu driver needs to allocate iova and do the map in iommu. And for each unmap, it needs to free iova and unmap the buffer in iommu hardware. When devices performing DMA are super-fast, for example, on 100GbE networks, the DMA streaming map/unmap latency might become a critical system bottleneck.
In comparison to DMA streaming APIs, DMA consistent APIs using IOMMU backend may show much better performance as the map is done when the buffer is allocated and unmap is done when the buffer is freed. DMA can be done multiple times before the buffers are freed by dma_free_coherent(). There is no such map and unmap overhead for each separate DMA transfer as streaming APIs. The typical work flow is like
dma_alloc_coherent->
doing DMA ->
doing DMA ->
doing DMA ->
.... /* DMA many times */
dma_free_coherent
However, the typical work flow for streaming DMA is like
dma_map_sg -> doing DMA -> dma_unmap_sg ->
dma_map_sg -> doing DMA -> dma_unmap_sg ->
dma_map_sg -> doing DMA -> dma_unmap_sg ->
.... /* map, DMA transfer, unmap many times */
Even though upper-layer software might use the same buffers multiple times, for each single DMA transmission, map and unmap still need to be done by lower-level drivers as lower-layer drivers don't know this fact.
A possible routine to improve the performance of stream APIs is like:
dma_map_sg ->
dma_sync_sg_for_device -> doing DMA ->
dma_sync_sg_for_device -> doing DMA ->
dma_sync_sg_for_device -> doing DMA ->
... -> /* sync between DMA and CPU many times */
dma_unmap_sg
For every single DMA, software only needs to do sync operations which are much lighter that map and unmap. But this case is often not applicable to device drivers as the buffers usually come from the upper-layer filesystem, network protocol, mm management system etc. Device drivers have to work with the assumption that the buffer will be freed immediately after DMA is done. However, for those device drivers which are able to allocate and free the DMA stream buffers by themselves, they will get benefits of reusing the same buffers for doing DMA multiple times without map/unmap overhead.
I collected some latency data for iommu_dma_map_sg and iommu_dma_unmap_sg. In the test case, zswap is calling acomp APIs to compress/decompress pages, and comp/decomp is done by lower-level hardware ZIP driver.
root@ubuntu:/usr/share/bcc/tools# ./funclatency iommu_dma_map_sg
Tracing 1 functions for "iommu_dma_map_sg"... Hit Ctrl-C to end.
^C
nsecs : count distribution
0 -> 1 : 0 | |
2 -> 3 : 0 | |
4 -> 7 : 0 | |
8 -> 15 : 0 | |
16 -> 31 : 0 | |
32 -> 63 : 0 | |
64 -> 127 : 0 | |
128 -> 255 : 0 | |
256 -> 511 : 0 | |
512 -> 1023 : 0 | |
1024 -> 2047 : 2274570 |*********************** |
2048 -> 4095 : 3896310 |****************************************|
4096 -> 8191 : 74499 | |
8192 -> 16383 : 4475 | |
16384 -> 32767 : 1519 | |
32768 -> 65535 : 480 | |
65536 -> 131071 : 286 | |
131072 -> 262143 : 18 | |
262144 -> 524287 : 2 | |
root@ubuntu:/usr/share/bcc/tools# ./funclatency iommu_dma_unmap_sg
Tracing 1 functions for "iommu_dma_unmap_sg"... Hit Ctrl-C to end.
^C
nsecs : count distribution
0 -> 1 : 0 | |
2 -> 3 : 0 | |
4 -> 7 : 0 | |
8 -> 15 : 0 | |
16 -> 31 : 0 | |
32 -> 63 : 0 | |
64 -> 127 : 0 | |
128 -> 255 : 0 | |
256 -> 511 : 0 | |
512 -> 1023 : 0 | |
1024 -> 2047 : 0 | |
2048 -> 4095 : 56083 | |
4096 -> 8191 : 5232036 |****************************************|
8192 -> 16383 : 7723 | |
16384 -> 32767 : 1277 | |
32768 -> 65535 : 32 | |
65536 -> 131071 : 12 | |
131072 -> 262143 : 41 | |
In contrast, if we set iommu passthrough, the latency will be much better:
root@ubuntu:/usr/share/bcc/tools# ./funclatency dma_direct_map_sg
Tracing 1 functions for "dma_direct_map_sg"... Hit Ctrl-C to end.
^C
nsecs : count distribution
0 -> 1 : 0 | |
2 -> 3 : 0 | |
4 -> 7 : 0 | |
8 -> 15 : 0 | |
16 -> 31 : 0 | |
32 -> 63 : 0 | |
64 -> 127 : 0 | |
128 -> 255 : 0 | |
256 -> 511 : 0 | |
512 -> 1023 : 10798 | |
1024 -> 2047 : 1435035 |****************************************|
2048 -> 4095 : 13879 | |
4096 -> 8191 : 485 | |
8192 -> 16383 : 791 | |
16384 -> 32767 : 418 | |
32768 -> 65535 : 55 | |
65536 -> 131071 : 67 | |
131072 -> 262143 : 8 | |
root@ubuntu:/usr/share/bcc/tools# ./funclatency dma_direct_unmap_sg
Tracing 1 functions for "dma_direct_unmap_sg"... Hit Ctrl-C to end.
^C
nsecs : count distribution
0 -> 1 : 0 | |
2 -> 3 : 0 | |
4 -> 7 : 0 | |
8 -> 15 : 0 | |
16 -> 31 : 0 | |
32 -> 63 : 0 | |
64 -> 127 : 0 | |
128 -> 255 : 0 | |
256 -> 511 : 0 | |
512 -> 1023 : 216 | |
1024 -> 2047 : 250849 |****************************************|
2048 -> 4095 : 54341 |******** |
4096 -> 8191 : 80 | |
8192 -> 16383 : 191 | |
16384 -> 32767 : 65 | |
In summary, the comparison is as below:
(1)map
iommu passthrough mainly 1-2us
iommu non-passthrough mainly 2-4us
(2)unmap
iommu passthrough mainly 1-2us
iommu non-passthrough mainly 4-8us
The below is the long function trace for each dma_map/unmap_sg while iommu is enabled:
507.520069 | 53) | iommu_dma_map_sg() {
507.520070 | 53) 0.670 us | iommu_get_dma_domain();
507.520071 | 53) 0.610 us | iommu_dma_deferred_attach();
507.520072 | 53) | iommu_dma_alloc_iova.isra.26() {
507.520073 | 53) | alloc_iova_fast() {
507.520074 | 53) | _raw_spin_lock_irqsave() {
507.520074 | 53) 0.570 us | preempt_count_add();
507.520076 | 53) 2.060 us | }
507.520077 | 53) | _raw_spin_unlock_irqrestore() {
507.520077 | 53) 0.790 us | preempt_count_sub();
507.520079 | 53) 2.090 us | }
507.520079 | 53) 6.260 us | }
507.520080 | 53) 7.470 us | }
507.520081 | 53) | iommu_map_sg_atomic() {
507.520081 | 53) | __iommu_map_sg() {
507.520082 | 53) | __iommu_map() {
507.520082 | 53) 0.630 us | iommu_pgsize.isra.14();
507.520084 | 53) | arm_smmu_map() {
507.520084 | 53) | arm_lpae_map() {
507.520085 | 53) | __arm_lpae_map() {
507.520086 | 53) | __arm_lpae_map() {
507.520086 | 53) | __arm_lpae_map() {
507.520087 | 53) 0.930 us | __arm_lpae_map();
507.520089 | 53) 2.170 us | }
507.520089 | 53) 3.490 us | }
507.520090 | 53) 4.730 us | }
507.520090 | 53) 5.980 us | }
507.520091 | 53) 7.250 us | }
507.520092 | 53) 0.650 us | iommu_pgsize.isra.14();
507.520093 | 53) | arm_smmu_map() {
507.520093 | 53) | arm_lpae_map() {
507.520094 | 53) | __arm_lpae_map() {
507.520095 | 53) | __arm_lpae_map() {
507.520096 | 53) | __arm_lpae_map() {
507.520096 | 53) 0.630 us | __arm_lpae_map();
507.520098 | 53) 1.860 us | }
507.520098 | 53) 3.210 us | }
507.520099 | 53) 4.610 us | }
507.520099 | 53) 5.860 us | }
507.520100 | 53) 7.110 us | }
507.520101 | 53) + 18.740 us | }
507.520101 | 53) + 20.080 us | }
507.520102 | 53) + 21.320 us | }
507.520102 | 53) + 33.200 us | }
783.039976 | 48) | iommu_dma_unmap_sg() {
783.039977 | 48) | __iommu_dma_unmap() {
783.039978 | 48) 0.720 us | iommu_get_dma_domain();
783.039979 | 48) | iommu_unmap_fast() {
783.039980 | 48) | __iommu_unmap() {
783.039981 | 48) 0.740 us | iommu_pgsize.isra.14();
783.039982 | 48) | arm_smmu_unmap() {
783.039983 | 48) | arm_lpae_unmap() {
783.039984 | 48) | __arm_lpae_unmap() {
783.039985 | 48) | __arm_lpae_unmap() {
783.039985 | 48) | __arm_lpae_unmap() {
783.039986 | 48) | __arm_lpae_unmap() {
783.039988 | 48) 0.730 us | arm_smmu_tlb_inv_page_nosync();
783.039989 | 48) 3.010 us | }
783.039990 | 48) 4.490 us | }
783.039991 | 48) 5.950 us | }
783.039991 | 48) 7.460 us | }
783.039992 | 48) 8.920 us | }
783.039993 | 48) + 10.380 us | }
783.039993 | 48) + 13.350 us | }
783.039994 | 48) + 14.820 us | }
783.039995 | 48) | arm_smmu_iotlb_sync() {
783.039996 | 48) | arm_smmu_tlb_inv_range() {
783.039996 | 48) | arm_smmu_cmdq_batch_add() {
783.039997 | 48) 0.760 us | arm_smmu_cmdq_build_cmd();
783.039999 | 48) 2.220 us | }
783.039999 | 48) | arm_smmu_cmdq_issue_cmdlist() {
783.040000 | 48) 0.530 us | arm_smmu_cmdq_build_cmd();
783.040001 | 48) 0.530 us | __arm_smmu_cmdq_poll_set_valid_map.isra.40();
783.040002 | 48) 0.540 us | __arm_smmu_cmdq_poll_set_valid_map.isra.40();
783.040004 | 48) | ktime_get() {
783.040004 | 48) 0.540 us | arch_counter_read();
783.040005 | 48) 1.570 us | }
783.040006 | 48) 6.880 us | }
783.040007 | 48) 0.830 us | arm_smmu_atc_inv_domain.constprop.48();
783.040008 | 48) + 12.910 us | }
783.040009 | 48) + 14.370 us | }
783.040010 | 48) | iommu_dma_free_iova() {
783.040011 | 48) | free_iova_fast() {
783.040011 | 48) | _raw_spin_lock_irqsave() {
783.040012 | 48) 0.600 us | preempt_count_add();
783.040013 | 48) 2.000 us | }
783.040014 | 48) | _raw_spin_unlock_irqrestore() {
783.040015 | 48) 0.820 us | preempt_count_sub();
783.040016 | 48) 2.220 us | }
783.040018 | 48) 6.200 us | }
783.040019 | 48) 8.880 us | }
783.040020 | 48) + 42.540 us | }
783.040020 | 48) + 44.030 us | }
I am thinking several possible ways on decreasing or removing the latency of DMA map/unmap for every single DMA transfer. Meanwhile, "non-strict" as an existing option with possible safety issues, I won't discuss it in this mail.
1. provide bounce coherent buffers for streaming buffers.
As the coherent buffers keep the status of mapping, we can remove the overhead of map and unmap for each single DMA operations. However, this solution requires memory copy between stream buffers and bounce buffers. Thus it will work only if copy is faster than map/unmap. Meanwhile, it will consume much more memory bandwidth.
2.make upper-layer kernel components aware of the pain of iommu map/unmap
upper-layer fs, mm, networks can somehow let the lower-layer drivers know the end of the life cycle of sg buffers. In zswap case, I have seen zswap always use the same 2 pages as the destination buffers to save compressed page, but the compressor driver still has to constantly map and unmap those same two pages for every single compression since zswap and zip drivers are working in two completely different software layers.
I am thinking some way as below, upper-layer kernel code can call:
sg_init_table(&sg...);
sg_mark_reusable(&sg....);
.... /* use the buffer many times */
....
sg_mark_stop_reuse(&sg);
After that, if low level drivers see "reusable" flag, it will realize the buffer can be used multiple times and will not do map/unmap every time. it means upper-layer components will further use the buffers and the same buffers will probably be given to lower-layer drivers for new DMA transfer later. When upper-layer code sets " stop_reuse", lower-layer driver will unmap the sg buffers, possibly by providing a unmap-callback to upper-layer components. For zswap case, I have seen the same buffers are always re-used and zip driver maps and unmaps it again and again. Shortly after the buffer is unmapped, it will be mapped in the next transmission, almost without any time gap between unmap and map. In case zswap can set the "reusable" flag, zip driver will save a lot of time.
Meanwhile, for the safety of buffers, lower-layer drivers need to make certain the buffers have already been unmapped in iommu before those buffers go back to buddy for other users.
I don't think letting upper-layer components aware of the overhead of map and unmap is elegant. But it might be something which deserves to be done for performance reason. Upper-layer software which is friendly to lower-layer driver might call sg_mark_reusable(&sg....). But it is not enforced, if upper-layer components don't call the API, the current lower-level driver won't be affected.
Please kindly give your comments on this proposal and provide your suggestions on any possible way to improve the performance of DMA stream APIs with iommu backend. I am glad to send a draft patch for "reusable" buffers if you think it is not bad.
Best Regards
Barry
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH v6] iommu/arm-smmu-qcom: Request direct mapping for modem device
From: Sibi Sankar @ 2020-05-15 8:18 UTC (permalink / raw)
To: will, robin.murphy, joro
Cc: linux-kernel-owner, linux-arm-msm, swboyd, dianders, evgreen,
linux-kernel, iommu, mka, bjorn.andersson, linux-arm-kernel
In-Reply-To: <20200511175532.25874-1-sibis@codeaurora.org>
Hey Will,
On 2020-05-11 23:25, Sibi Sankar wrote:
> The modem remote processor has two access paths to DDR. One path is
> directly connected to DDR and another path goes through an SMMU. The
> SMMU path is configured to be a direct mapping because it's used by
> various peripherals in the modem subsystem. Typically this direct
> mapping is configured statically at EL2 by QHEE (Qualcomm's Hypervisor
> Execution Environment) before the kernel is entered.
>
> In certain firmware configuration, especially when the kernel is
> already
> in full control of the SMMU, defer programming the modem SIDs to the
> kernel. Let's add compatibles here so that we can have the kernel
> program the SIDs for the modem in these cases.
>
> Signed-off-by: Sibi Sankar <sibis@codeaurora.org>
> ---
Now that the patch is reworded can
you please pick it up since its the
only pending path from the series.
>
> V6
> * Rebased on Will's for-joerg/arm-smmu/updates
> * Reword commit message and add more details [Stephen]
>
> drivers/iommu/arm-smmu-qcom.c | 2 ++
> 1 file changed, 2 insertions(+)
>
> diff --git a/drivers/iommu/arm-smmu-qcom.c
> b/drivers/iommu/arm-smmu-qcom.c
> index 5bedf21587a56..cf01d0215a397 100644
> --- a/drivers/iommu/arm-smmu-qcom.c
> +++ b/drivers/iommu/arm-smmu-qcom.c
> @@ -17,7 +17,9 @@ static const struct of_device_id
> qcom_smmu_client_of_match[] = {
> { .compatible = "qcom,mdp4" },
> { .compatible = "qcom,mdss" },
> { .compatible = "qcom,sc7180-mdss" },
> + { .compatible = "qcom,sc7180-mss-pil" },
> { .compatible = "qcom,sdm845-mdss" },
> + { .compatible = "qcom,sdm845-mss-pil" },
> { }
> };
--
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project.
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH v4 5/5] drm/sun4i: mixer: Call of_dma_configure if there's an IOMMU
From: Paul Kocialkowski @ 2020-05-15 8:15 UTC (permalink / raw)
To: Maxime Ripard
Cc: Mark Rutland, devicetree, Joerg Roedel, iommu, Maxime Ripard,
Chen-Yu Tsai, Rob Herring, Frank Rowand, linux-arm-kernel
In-Reply-To: <9a4daf438dd3f2fe07afb23688bfb793a0613d7d.1589378833.git-series.maxime@cerno.tech>
[-- Attachment #1.1: Type: text/plain, Size: 2069 bytes --]
Hi,
On Wed 13 May 20, 16:07, Maxime Ripard wrote:
> The main DRM device is actually a virtual device so it doesn't have the
> iommus property, which is instead on the DMA masters, in this case the
> mixers.
>
> Add a call to of_dma_configure with the mixers DT node but on the DRM
> virtual device to configure it in the same way than the mixers.
Although I'm not very familiar with the DMA API, this looks legit to me and
matches what's already done in sun4i_backend for the interconnect. So:
Reviewed-by: Paul Kocialkowski <paul.kocialkowski@bootlin.com>
Cheers,
Paul
> Signed-off-by: Maxime Ripard <maxime@cerno.tech>
> ---
> drivers/gpu/drm/sun4i/sun8i_mixer.c | 13 +++++++++++++
> 1 file changed, 13 insertions(+)
>
> diff --git a/drivers/gpu/drm/sun4i/sun8i_mixer.c b/drivers/gpu/drm/sun4i/sun8i_mixer.c
> index 56cc037fd312..cc4fb916318f 100644
> --- a/drivers/gpu/drm/sun4i/sun8i_mixer.c
> +++ b/drivers/gpu/drm/sun4i/sun8i_mixer.c
> @@ -363,6 +363,19 @@ static int sun8i_mixer_bind(struct device *dev, struct device *master,
> mixer->engine.ops = &sun8i_engine_ops;
> mixer->engine.node = dev->of_node;
>
> + if (of_find_property(dev->of_node, "iommus", NULL)) {
> + /*
> + * This assume we have the same DMA constraints for
> + * all our the mixers in our pipeline. This sounds
> + * bad, but it has always been the case for us, and
> + * DRM doesn't do per-device allocation either, so we
> + * would need to fix DRM first...
> + */
> + ret = of_dma_configure(drm->dev, dev->of_node, true);
> + if (ret)
> + return ret;
> + }
> +
> /*
> * While this function can fail, we shouldn't do anything
> * if this happens. Some early DE2 DT entries don't provide
> --
> git-series 0.9.1
>
> _______________________________________________
> linux-arm-kernel mailing list
> linux-arm-kernel@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
--
Paul Kocialkowski, Bootlin
Embedded Linux and kernel engineering
https://bootlin.com
[-- Attachment #1.2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
[-- Attachment #2: Type: text/plain, Size: 176 bytes --]
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* [PATCH] iommu/mediatek-v1: Add def_domain_type
From: Yong Wu @ 2020-05-15 8:08 UTC (permalink / raw)
To: Joerg Roedel
Cc: youlin.pei, anan.sun, srv_heupstream, Will Deacon, linux-kernel,
iommu, linux-mediatek, yong.wu, Matthias Brugger, Robin Murphy,
linux-arm-kernel
The MediaTek V1 IOMMU is arm32 whose default domain type is
IOMMU_DOMAIN_UNMANAGED. Add this to satisfy the bus_iommu_probe to
enter "probe_finalize".
The iommu framework will create a iommu domain for each a device.
But all the devices share a iommu domain here, thus we skip all the
other domains in the "attach_device" except the domain we create
internally with arm_iommu_create_mapping.
Also a minor change: in the attach_device, "data" always is not null.
Remove "if (!data) return".
Signed-off-by: Yong Wu <yong.wu@mediatek.com>
---
a. rebase on linux-next.
b. After this patch and fixed the mutex issue(locally I only move
mutex_unlock(&group->mutex) before __iommu_group_dma_attach(group)),
the mtk_iommu_v1.c could work normally.
---
drivers/iommu/mtk_iommu_v1.c | 16 +++++++++++-----
1 file changed, 11 insertions(+), 5 deletions(-)
diff --git a/drivers/iommu/mtk_iommu_v1.c b/drivers/iommu/mtk_iommu_v1.c
index 7bdd74c..f353b07 100644
--- a/drivers/iommu/mtk_iommu_v1.c
+++ b/drivers/iommu/mtk_iommu_v1.c
@@ -265,10 +265,13 @@ static int mtk_iommu_attach_device(struct iommu_domain *domain,
{
struct mtk_iommu_data *data = dev_iommu_priv_get(dev);
struct mtk_iommu_domain *dom = to_mtk_domain(domain);
+ struct dma_iommu_mapping *mtk_mapping;
int ret;
- if (!data)
- return -ENODEV;
+ /* Only allow the domain created internally. */
+ mtk_mapping = data->dev->archdata.iommu;
+ if (mtk_mapping->domain != domain)
+ return 0;
if (!data->m4u_dom) {
data->m4u_dom = dom;
@@ -288,9 +291,6 @@ static void mtk_iommu_detach_device(struct iommu_domain *domain,
{
struct mtk_iommu_data *data = dev_iommu_priv_get(dev);
- if (!data)
- return;
-
mtk_iommu_config(data, dev, false);
}
@@ -416,6 +416,11 @@ static int mtk_iommu_create_mapping(struct device *dev,
return 0;
}
+static int mtk_iommu_def_domain_type(struct device *dev)
+{
+ return IOMMU_DOMAIN_UNMANAGED;
+}
+
static struct iommu_device *mtk_iommu_probe_device(struct device *dev)
{
struct iommu_fwspec *fwspec = dev_iommu_fwspec_get(dev);
@@ -525,6 +530,7 @@ static int mtk_iommu_hw_init(const struct mtk_iommu_data *data)
.probe_device = mtk_iommu_probe_device,
.probe_finalize = mtk_iommu_probe_finalize,
.release_device = mtk_iommu_release_device,
+ .def_domain_type = mtk_iommu_def_domain_type,
.device_group = generic_device_group,
.pgsize_bitmap = ~0UL << MT2701_IOMMU_PAGE_SHIFT,
};
--
1.9.1
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* Re: [PATCH v2 3/6] thermal: add support for the MCU controlled FAN on Khadas boards
From: Neil Armstrong @ 2020-05-15 8:05 UTC (permalink / raw)
To: Amit Kucheria
Cc: Linux PM list, Daniel Lezcano, LKML, Srini Kandagatla,
linux-amlogic, Zhang Rui, lakml
In-Reply-To: <CAHLCerPiC3QS5u5CGX20q_5aUk4sN5knF4043_=WjtbhDDGuUg@mail.gmail.com>
On 15/05/2020 08:41, Amit Kucheria wrote:
> On Tue, May 12, 2020 at 6:56 PM Neil Armstrong <narmstrong@baylibre.com> wrote:
>>
>> The new Khadas VIM2 and VIM3 boards controls the cooling fan via the
>> on-board microcontroller.
>>
>> This implements the FAN control as thermal devices and as cell of the Khadas
>> MCU MFD driver.
>>
>> Signed-off-by: Neil Armstrong <narmstrong@baylibre.com>
>> ---
>> drivers/thermal/Kconfig | 10 ++
>> drivers/thermal/Makefile | 1 +
>> drivers/thermal/khadas_mcu_fan.c | 174 +++++++++++++++++++++++++++++++
>> 3 files changed, 185 insertions(+)
>> create mode 100644 drivers/thermal/khadas_mcu_fan.c
>>
>> diff --git a/drivers/thermal/Kconfig b/drivers/thermal/Kconfig
>> index 91af271e9bb0..72b3960cc5ac 100644
>> --- a/drivers/thermal/Kconfig
>> +++ b/drivers/thermal/Kconfig
>> @@ -490,4 +490,14 @@ config SPRD_THERMAL
>> help
>> Support for the Spreadtrum thermal sensor driver in the Linux thermal
>> framework.
>> +
>> +config KHADAS_MCU_FAN_THERMAL
>> + tristate "Khadas MCU controller FAN cooling support"
>> + depends on OF || COMPILE_TEST
>
> Could you add a depends on the some board/SoC Kconfig option here so
> this doesn't show up for non-Amlogic/non-Khadas boards?
Sure,
Thanks.
Neil
>
> Looks OK otherwise.
>
>> + select MFD_CORE
>> + select REGMAP
>> + help
>> + If you say yes here you get support for the FAN controlled
>> + by the Microcontroller found on the Khadas VIM boards.
>> +
>> endif
>> diff --git a/drivers/thermal/Makefile b/drivers/thermal/Makefile
>> index 8c8ed7b79915..460428c2122c 100644
>> --- a/drivers/thermal/Makefile
>> +++ b/drivers/thermal/Makefile
>> @@ -60,3 +60,4 @@ obj-$(CONFIG_ZX2967_THERMAL) += zx2967_thermal.o
>> obj-$(CONFIG_UNIPHIER_THERMAL) += uniphier_thermal.o
>> obj-$(CONFIG_AMLOGIC_THERMAL) += amlogic_thermal.o
>> obj-$(CONFIG_SPRD_THERMAL) += sprd_thermal.o
>> +obj-$(CONFIG_KHADAS_MCU_FAN_THERMAL) += khadas_mcu_fan.o
>> diff --git a/drivers/thermal/khadas_mcu_fan.c b/drivers/thermal/khadas_mcu_fan.c
>> new file mode 100644
>> index 000000000000..044d4aba8be2
>> --- /dev/null
>> +++ b/drivers/thermal/khadas_mcu_fan.c
>> @@ -0,0 +1,174 @@
>> +// SPDX-License-Identifier: GPL-2.0-or-later
>> +/*
>> + * Khadas MCU Controlled FAN driver
>> + *
>> + * Copyright (C) 2020 BayLibre SAS
>> + * Author(s): Neil Armstrong <narmstrong@baylibre.com>
>> + */
>> +
>> +#include <linux/module.h>
>> +#include <linux/of.h>
>> +#include <linux/platform_device.h>
>> +#include <linux/mfd/khadas-mcu.h>
>> +#include <linux/regmap.h>
>> +#include <linux/sysfs.h>
>> +#include <linux/thermal.h>
>> +
>> +#define MAX_LEVEL 3
>> +
>> +struct khadas_mcu_fan_ctx {
>> + struct khadas_mcu *mcu;
>> + unsigned int level;
>> + struct thermal_cooling_device *cdev;
>> +};
>> +
>> +static int khadas_mcu_fan_set_level(struct khadas_mcu_fan_ctx *ctx,
>> + unsigned int level)
>> +{
>> + int ret;
>> +
>> + ret = regmap_write(ctx->mcu->map, KHADAS_MCU_CMD_FAN_STATUS_CTRL_REG,
>> + level);
>> + if (ret)
>> + return ret;
>> +
>> + ctx->level = level;
>> +
>> + return 0;
>> +}
>> +
>> +static int khadas_mcu_fan_get_max_state(struct thermal_cooling_device *cdev,
>> + unsigned long *state)
>> +{
>> + struct khadas_mcu_fan_ctx *ctx = cdev->devdata;
>> +
>> + if (!ctx)
>> + return -EINVAL;
>> +
>> + *state = MAX_LEVEL;
>> +
>> + return 0;
>> +}
>> +
>> +static int khadas_mcu_fan_get_cur_state(struct thermal_cooling_device *cdev,
>> + unsigned long *state)
>> +{
>> + struct khadas_mcu_fan_ctx *ctx = cdev->devdata;
>> +
>> + if (!ctx)
>> + return -EINVAL;
>> +
>> + *state = ctx->level;
>> +
>> + return 0;
>> +}
>> +
>> +static int
>> +khadas_mcu_fan_set_cur_state(struct thermal_cooling_device *cdev,
>> + unsigned long state)
>> +{
>> + struct khadas_mcu_fan_ctx *ctx = cdev->devdata;
>> +
>> + if (!ctx || (state > MAX_LEVEL))
>> + return -EINVAL;
>> +
>> + if (state == ctx->level)
>> + return 0;
>> +
>> + return khadas_mcu_fan_set_level(ctx, state);
>> +}
>> +
>> +static const struct thermal_cooling_device_ops khadas_mcu_fan_cooling_ops = {
>> + .get_max_state = khadas_mcu_fan_get_max_state,
>> + .get_cur_state = khadas_mcu_fan_get_cur_state,
>> + .set_cur_state = khadas_mcu_fan_set_cur_state,
>> +};
>> +
>> +static int khadas_mcu_fan_probe(struct platform_device *pdev)
>> +{
>> + struct khadas_mcu *mcu = dev_get_drvdata(pdev->dev.parent);
>> + struct thermal_cooling_device *cdev;
>> + struct device *dev = &pdev->dev;
>> + struct khadas_mcu_fan_ctx *ctx;
>> + int ret;
>> +
>> + ctx = devm_kzalloc(dev, sizeof(*ctx), GFP_KERNEL);
>> + if (!ctx)
>> + return -ENOMEM;
>> + ctx->mcu = mcu;
>> + platform_set_drvdata(pdev, ctx);
>> +
>> + cdev = devm_thermal_of_cooling_device_register(dev->parent,
>> + dev->parent->of_node, "khadas-mcu-fan", ctx,
>> + &khadas_mcu_fan_cooling_ops);
>> + if (IS_ERR(cdev)) {
>> + ret = PTR_ERR(cdev);
>> + dev_err(dev,
>> + "Failed to register khadas-mcu-fan as cooling device: %d\n",
>> + ret);
>> + return ret;
>> + }
>> + ctx->cdev = cdev;
>> + thermal_cdev_update(cdev);
>> +
>> + return 0;
>> +}
>> +
>> +static int khadas_mcu_fan_disable(struct device *dev)
>> +{
>> + struct khadas_mcu_fan_ctx *ctx = dev_get_drvdata(dev);
>> + unsigned int level_save = ctx->level;
>> + int ret;
>> +
>> + ret = khadas_mcu_fan_set_level(ctx, 0);
>> + if (ret)
>> + return ret;
>> +
>> + ctx->level = level_save;
>> +
>> + return 0;
>> +}
>> +
>> +static void khadas_mcu_fan_shutdown(struct platform_device *pdev)
>> +{
>> + khadas_mcu_fan_disable(&pdev->dev);
>> +}
>> +
>> +#ifdef CONFIG_PM_SLEEP
>> +static int khadas_mcu_fan_suspend(struct device *dev)
>> +{
>> + return khadas_mcu_fan_disable(dev);
>> +}
>> +
>> +static int khadas_mcu_fan_resume(struct device *dev)
>> +{
>> + struct khadas_mcu_fan_ctx *ctx = dev_get_drvdata(dev);
>> +
>> + return khadas_mcu_fan_set_level(ctx, ctx->level);
>> +}
>> +#endif
>> +
>> +static SIMPLE_DEV_PM_OPS(khadas_mcu_fan_pm, khadas_mcu_fan_suspend,
>> + khadas_mcu_fan_resume);
>> +
>> +static const struct platform_device_id khadas_mcu_fan_id_table[] = {
>> + { .name = "khadas-mcu-fan-ctrl", },
>> + {},
>> +};
>> +MODULE_DEVICE_TABLE(platform, khadas_mcu_fan_id_table);
>> +
>> +static struct platform_driver khadas_mcu_fan_driver = {
>> + .probe = khadas_mcu_fan_probe,
>> + .shutdown = khadas_mcu_fan_shutdown,
>> + .driver = {
>> + .name = "khadas-mcu-fan-ctrl",
>> + .pm = &khadas_mcu_fan_pm,
>> + },
>> + .id_table = khadas_mcu_fan_id_table,
>> +};
>> +
>> +module_platform_driver(khadas_mcu_fan_driver);
>> +
>> +MODULE_AUTHOR("Neil Armstrong <narmstrong@baylibre.com>");
>> +MODULE_DESCRIPTION("Khadas MCU FAN driver");
>> +MODULE_LICENSE("GPL");
>> --
>> 2.22.0
>>
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH 00/13] usb: dwc3: meson: add OTG support for GXL/GXM
From: Neil Armstrong @ 2020-05-15 8:03 UTC (permalink / raw)
To: Felipe Balbi, kishon, khilman, martin.blumenstingl
Cc: linux-amlogic, linux-usb, linux-kernel, linux-arm-kernel
In-Reply-To: <87wo5e3c53.fsf@kernel.org>
[-- Attachment #1.1.1: Type: text/plain, Size: 2654 bytes --]
On 14/05/2020 14:59, Felipe Balbi wrote:
> Neil Armstrong <narmstrong@baylibre.com> writes:
>
>> Hi,
>>
>> On 14/05/2020 12:23, Felipe Balbi wrote:
>>> Felipe Balbi <balbi@kernel.org> writes:
>>>
>>>> Neil Armstrong <narmstrong@baylibre.com> writes:
>>>>
>>>>> The USB support was initialy done with a set of PHYs and dwc3-of-simple
>>>>> because the architecture of the USB complex was not understood correctly
>>>>> at the time (and proper documentation was missing...).
>>>>>
>>>>> But with the G12A family, the USB complex was correctly understood and
>>>>> implemented correctly.
>>>>> But seems the G12A architecture was derived for the GXL USB architecture,
>>>>> with minor differences and looks we can share most of the USB DWC3 glue
>>>>> driver.
>>>>>
>>>>> This patchset refactors and adds callbacks to handle the architecture
>>>>> difference while keeping the main code shared.
>>>>>
>>>>> The main difference is that on GXL/GXM the USB2 PHY control registers
>>>>> are mixed with the PHY registers (we already handle correctly), and
>>>>> the GLUE registers are allmost (99%) the same as G12A.
>>>>>
>>>>> But, the GXL/GXM HW is buggy, here are the quirks :
>>>>> - for the DWC2 controller to reset correctly, the GLUE mux must be switched
>>>>> to peripheral when the DWC2 controlle probes. For now it's handled by simply
>>>>> switching to device when probing the subnodes, but it may be not enough
>>>>> - when manually switching from Host to Device when the USB port is not
>>>>> populated (should not happen with proper Micro-USB/USB-C OTG switch), it
>>>>> makes the DWC3 to crash. The only way to avoid that is to use the Host
>>>>> Disconnect bit to disconnect the DWC3 controller from the port, but we can't
>>>>> recover the Host functionnality unless resetting the DWC3 controller.
>>>>> This bit is set when only manual switch is done, and a warning is printed
>>>>> on manual switching.
>>>>>
>>>>> The patches 1-8 should be applied first, then either waiting the next release
>>>>> or if the usb maintainer can provide us a stable tag, we can use it to merge
>>>>> the DT and bindings.
>>>>
>>>> it's unclear to me if this series is ready to be merged. Can someone
>>>> confirm? If it is, can you resend with all reviewed by tags in place?
>>>
>>> Are we getting a v2 for this?
>>>
>>
>> Yes, even a v3 with reviews on all patches:
>> http://lkml.kernel.org/r/20200416121910.12723-1-narmstrong@baylibre.com
>
> In that case, can you check that I have applied everything correctly in
> testing/next?
>
> cheers
>
Looks fine,
Thanks,
Neil
[-- Attachment #1.2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
[-- Attachment #2: Type: text/plain, Size: 176 bytes --]
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH v7 01/12] dt-bindings: add img, pvrsgx.yaml for Imagination GPUs
From: H. Nikolaus Schaller @ 2020-05-15 7:59 UTC (permalink / raw)
To: Rob Herring
Cc: Mark Rutland, David Airlie, James Hogan, Jonathan Bakker,
dri-devel, linux-mips, Paul Cercueil, linux-omap, Paul Burton,
Krzysztof Kozlowski, Tony Lindgren, Chen-Yu Tsai, Kukjin Kim,
devicetree, Benoît Cousson, Maxime Ripard, linux-samsung-soc,
letux-kernel, linux-arm-kernel, Thomas Bogendoerfer,
Philipp Rossak, openpvrsgx-devgroup, linux-kernel, Ralf Baechle,
Daniel Vetter, kernel
In-Reply-To: <20200505155311.GA18025@bogus>
> Am 05.05.2020 um 17:53 schrieb Rob Herring <robh@kernel.org>:
>
> On Fri, Apr 24, 2020 at 10:34:04PM +0200, H. Nikolaus Schaller wrote:
>> The Imagination PVR/SGX GPU is part of several SoC from
>> multiple vendors, e.g. TI OMAP, Ingenic JZ4780, Intel Poulsbo,
>> Allwinner A83 and others.
>>
>> With this binding, we describe how the SGX processor is
>> interfaced to the SoC (registers and interrupt).
>>
>> The interface also consists of clocks, reset, power but
>> information from data sheets is vague and some SoC integrators
>> (TI) deciced to use a PRCM wrapper (ti,sysc) which does
>> all clock, reset and power-management through registers
>> outside of the sgx register block.
>>
>> Therefore all these properties are optional.
>>
>> Tested by make dt_binding_check
>>
>> Signed-off-by: H. Nikolaus Schaller <hns@goldelico.com>
>> ---
>> .../devicetree/bindings/gpu/img,pvrsgx.yaml | 150 ++++++++++++++++++
>> 1 file changed, 150 insertions(+)
>> + oneOf:
>> + - description: SGX530-121 based SoC
>> + items:
>> + - enum:
>> + - ti,omap3-sgx530-121 # BeagleBoard A/B/C, OpenPandora 600MHz and similar
>
> Should be indented 2 more here and elsewhere where you have a list
> under a list.
added for patch v8 series.
BR and thanks,
Nikolaus
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH v7 01/12] dt-bindings: add img, pvrsgx.yaml for Imagination GPUs
From: H. Nikolaus Schaller @ 2020-05-15 7:58 UTC (permalink / raw)
To: Tony Lindgren
Cc: Mark Rutland, David Airlie, James Hogan, Jonathan Bakker,
dri-devel, linux-mips, Paul Cercueil, letux-kernel, Paul Burton,
Krzysztof Kozlowski, linux-samsung-soc, Chen-Yu Tsai, Kukjin Kim,
devicetree, Benoît Cousson, Maxime Ripard, Rob Herring,
linux-omap, linux-arm-kernel, Thomas Bogendoerfer, Philipp Rossak,
openpvrsgx-devgroup, linux-kernel, Ralf Baechle, Daniel Vetter,
kernel
In-Reply-To: <20200503150143.GG37466@atomide.com>
Hi Tony,
> Am 03.05.2020 um 17:01 schrieb Tony Lindgren <tony@atomide.com>:
>
> * Paul Cercueil <paul@crapouillou.net> [200503 14:19]:
>> You have a new SoC with a SGX, and you only need to enable one clock to get
>> it to work. So you create a devicetree node which receives only one clock.
>>
>> Turns out, that the bootloader was enabling the other 3 clocks, and since
>> the last release, it doesn't anymore. You're left with having to support a
>> broken devicetree.
>>
>> That's the kind of problem that can be easily avoided by enforcing the
>> number of clocks that have to be provided.
>
> The number of clocks depends on how it's wired for the SoC.
>
> On omaps, there's are no controls for additinoal SGX clocks. Sure some
> of the clocks may be routed to multple places internally by the wrapper
> module. But we have no control over that.
>
> If we wanted to specify just the "fck" clock on omaps, then we can
> do it with something like this:
>
> allOf:
> - if:
> properites:
> compatible:
> enum:
> - "ti,omap4-sgx544-112"
> - "ti,omap5-sgx544-116"
> - "ti,dra7-sgx544-116"
> then:
> properties:
> clocks:
> minItems: 1
> maxItems: 1
>
> clock-names:
> const: fck
>
> required:
> - clocks
> - clock-names
will add to v8 of this series as a separate patch on top of the
general one. This should make it easier to have a focussed discussion
and revert/bisect if something goes wrong.
BR and thanks,
Nikolaus
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* RE: [PATCH v3 0/7] firmware: smccc: Add basic SMCCC v1.2 + ARCH_SOC_ID support
From: Etienne Carriere @ 2020-05-15 7:50 UTC (permalink / raw)
To: sudeep.holla
Cc: mark.rutland, lorenzo.pieralisi, arnd, catalin.marinas,
linux-kernel, steven.price, harb, will, linux-arm-kernel
In-Reply-To: <20200506164411.3284-1-sudeep.holla@arm.com>
> From: Sudeep Holla <sudeep.holla@arm.com>
>
> Hi,
>
> This patch series adds support for SMCCCv1.2 ARCH_SOC_ID.
> This doesn't add other changes added in SMCCC v1.2 yet. They will
> follow these soon along with its first user SPCI/PSA-FF.
>
> This is tested using upstream TF-A + the patch[2] fixing the original
> implementation there.
>
>
> v1[0]->v2[1]:
> - Incorporated comments from Steven Price in patch 5/5
> - Fixed build for CONFIG_PSCI_FW=n on some arm32 platforms
> - Added Steven Price's review tags
>
> v2[1]->v3:
> - Incorporated additional comments from Steven Price in patch 5/5
> and added his review tags
> - Refactored SMCCC code from PSCI and moved it under
> drivers/firmware/smccc/smccc.c
> - Also moved soc_id.c under drivers/firmware/smccc
>
> Regards,
> Sudeep
Hello Sudeep,
In case it helps. I have successfully tested the 7 patches series
on some platforms, playing a bit with few configurations.
Qemu emulator for arm64/cortex-a57 with TF-A (v2.x) as secure firmware.
Qemu emulator for arm/cortex-a15. OP-TEE (v3.x) as secure firmware.
A stm32mp15 device (arm/cortex-a7), tested both TF-A (v2.x) and
OP-TEE (3.7.0, 3.9.0-rc) as runtime secure firmware.
Helper functions arm_smccc_1_1_get_conduit()/arm_smccc_1_1_invoke()
works as expected AFAICT. No regression seen with older secure
firmwares.
For the patches 1 to 6, as I poorly tested [v3,7/7] soc ids,
based on tag next-20200505 [1]:
Tested-by: Etienne Carriere <etienne.carriere@st.com>
Reviewed-by: Etienne Carriere <etienne.carriere@st.com>
For [v3,7/7] firmware: smccc: Add ARCH_SOC_ID support
Acked-by: Etienne Carriere <etienne.carriere@st.com>
[1] 7def1ef0f72c ("Add linux-next specific files for 20200505")
Regards,
Etienne
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH v2 0/6] phy: meson8b-usb2: small fixes and improvements
From: Vinod Koul @ 2020-05-15 7:49 UTC (permalink / raw)
To: Martin Blumenstingl
Cc: devicetree, narmstrong, hexdump0815, linux-kernel, kishon,
robh+dt, linux-amlogic, linux-arm-kernel
In-Reply-To: <20200512222424.549351-1-martin.blumenstingl@googlemail.com>
On 13-05-20, 00:24, Martin Blumenstingl wrote:
> This is a batch of fixes and improvements for the phy-meson8b-usb2
> driver:
> - convert the existing dt-bindings to json-schema and add a fallback
> compatible string which is already in existing .dtsi files
> - differentiate between Meson8 and Meson8m2 using a new compatible
> string for the latter
> - simplify the code by using a MMIO regmap
> - set / unset the IDDQ and ACA enable bits depending on the operating
> mode (and for the latter also the compatible string)
>
> I suggest that all of these are applied to -next because we will need a
> separate .dts patch (which I already have prepared) to use the new
> Meson8m2 compatible string in meson8m2.dtsi. Otherwise we will be
> changing behavior in patch #4, because meson8m2.dtsi currently inherits
> the Meson8 compatible string.
> The number of actual Meson8 users is very small (I only know one case),
> so keeping Meson8m2 working is more important to me (because I know
> several users with boards that have a Meson8m2 SoC).
Applied all, thanks
--
~Vinod
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH v1 1/9] dmaengine: Actions: get rid of bit fields from dma descriptor
From: Amit Tomer @ 2020-05-15 7:46 UTC (permalink / raw)
To: Vinod Koul
Cc: Andre Przywara, linux-actions, cristian.ciocaltea,
Manivannan Sadhasivam, dmaengine, dan.j.williams,
Andreas Färber, linux-arm-kernel
In-Reply-To: <20200515065827.GL333670@vkoul-mobl>
Hi
> > > So i see patch 1/9 and 2/9 in my inbox... where are the rest ? No cover
> > > to detail out what the rest contains, who should merge them etc etc!
>
> and what is the answer for this..?
I do have a cover letter for this series , But CCed only to Actions
Semi SoC maintainers
and mailing list.
Also, As I said going forward I would Cc every stake holder at least
for cover letter.
Thanks
-Amit
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* [GIT PULL] Hisilicon driver updates for v5.8
From: Wei Xu @ 2020-05-15 7:26 UTC (permalink / raw)
To: soc, arm@kernel.org, linux-arm-kernel@lists.infradead.org
Cc: song.bao.hua, Salil Mehta, Tangkunshan, Arnd Bergmann, John Garry,
Linuxarm, Shameerali Kolothum Thodi, huangdaode, xuwei (O),
Jonathan Cameron, Olof Johansson, Liguozhu (Kenneth), Zhangyi ac,
Shiju Jose
Hi ARM-SoC team,
Please consider to pull the following changes.
Thanks!
Best Regards,
Wei
---
The following changes since commit 8f3d9f354286745c751374f5f1fcafee6b3f3136:
Linux 5.7-rc1 (2020-04-12 12:35:55 -0700)
are available in the Git repository at:
git://github.com/hisilicon/linux-hisi.git tags/hisi-drivers-for-5.8
for you to fetch changes up to 4acaa93ef64377417677d777a596e22da68c5e0d:
logic_pio: Use _inX() and _outX() (2020-05-07 14:54:26 +0800)
----------------------------------------------------------------
ARM64: hisi: SoC driver updates for 5.8
- Generate consistent behaviour for logic_pio by defining and using
generic _inX() and _outX() in asm-generic/io.h which have per-arch
overrideable barriers.
----------------------------------------------------------------
John Garry (3):
io: Provide _inX() and _outX()
logic_pio: Improve macro argument name
logic_pio: Use _inX() and _outX()
include/asm-generic/io.h | 64 +++++++++++++++++++++++++++++++++---------------
lib/logic_pio.c | 22 ++++++++---------
2 files changed, 55 insertions(+), 31 deletions(-)
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH] arm64: defconfig: enable CONFIG_PCIE_RCAR_HOST
From: Geert Uytterhoeven @ 2020-05-15 7:22 UTC (permalink / raw)
To: Lad Prabhakar
Cc: Catalin Marinas, Linux Kernel Mailing List, Linux-Renesas,
Prabhakar Lad, Will Deacon, Linux ARM
In-Reply-To: <1589494238-2933-1-git-send-email-prabhakar.mahadev-lad.rj@bp.renesas.com>
Hi Prabhakar,
On Fri, May 15, 2020 at 12:10 AM Lad Prabhakar
<prabhakar.mahadev-lad.rj@bp.renesas.com> wrote:
> config option PCIE_RCAR internally selects PCIE_RCAR_HOST which builds the
> same driver. So this patch renames CONFIG_PCIE_RCAR to
> CONFIG_PCIE_RCAR_HOST so that PCIE_RCAR can be safely dropped from Kconfig
> file.
>
> Signed-off-by: Lad Prabhakar <prabhakar.mahadev-lad.rj@bp.renesas.com>
> Reviewed-by: Yoshihiro Shimoda <yoshihiro.shimoda.uh@renesas.com>
Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be>
I wrote before:
"I can take patch 2/11 through renesas-devel.
Probably it's best if I submit it to arm-soc as a fix for v5.8, after
the driver part has been merged into v5.8-rc1."
so this will have to wait for v5.8-rc1.
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* [GIT PULL] arm64: dts: hisilicon dts updates for v5.8
From: Wei Xu @ 2020-05-15 7:21 UTC (permalink / raw)
To: soc, arm@kernel.org, linux-arm-kernel@lists.infradead.org
Cc: Salil Mehta, Loic Poulain, Tangkunshan, Arnd Bergmann, John Garry,
Linuxarm, Shameerali Kolothum Thodi, huangdaode, xuwei (O),
Jonathan Cameron, Olof Johansson, Shiju Jose, Liguozhu (Kenneth),
Zhangyi ac, Mike Leach
Hi ARM-SoC team,
Please consider to pull the following changes.
Thanks!
Best Regards,
Wei
---
The following changes since commit 8f3d9f354286745c751374f5f1fcafee6b3f3136:
Linux 5.7-rc1 (2020-04-12 12:35:55 -0700)
are available in the Git repository at:
git://github.com/hisilicon/linux-hisi.git tags/hisi-arm64-dt-for-5.8
for you to fetch changes up to fd955a7eac362d87f9dcb5c2f2c3e4355726c6fc:
arm64: dts: hi6220: Add CTI options (2020-05-07 14:44:56 +0800)
----------------------------------------------------------------
ARM64: DT: Hisilicon SoCs DT updates for 5.8
- Add pinconf for spi2 and spi3 nodes and increase the drive
strength to achieve the max speed for the Hikey960 board
- Add CTI nodes for the Hikey620 board
----------------------------------------------------------------
Loic Poulain (1):
arm64: dts: hikey960: pinctrl: Fix spi2/spi3 pinconf
Mike Leach (1):
arm64: dts: hi6220: Add CTI options
arch/arm64/boot/dts/hisilicon/hi3660.dtsi | 4 +-
.../arm64/boot/dts/hisilicon/hi6220-coresight.dtsi | 130 +++++++++++++++++++--
.../arm64/boot/dts/hisilicon/hikey960-pinctrl.dtsi | 6 +-
3 files changed, 127 insertions(+), 13 deletions(-)
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH v7 01/12] dt-bindings: add img, pvrsgx.yaml for Imagination GPUs
From: H. Nikolaus Schaller @ 2020-05-15 7:18 UTC (permalink / raw)
To: Paul Cercueil, Paul Burton
Cc: Mark Rutland, David Airlie, James Hogan, Jonathan Bakker,
open list:DRM PANEL DRIVERS, linux-mips, linux-samsung-soc,
Discussions about the Letux Kernel, Krzysztof Kozlowski,
Tony Lindgren, Chen-Yu Tsai, Kukjin Kim,
open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS,
Benoît Cousson, Maxime Ripard, Rob Herring, linux-omap,
arm-soc, Thomas Bogendoerfer, Philipp Rossak,
OpenPVRSGX Linux Driver Group, Linux Kernel Mailing List,
Ralf Baechle, Daniel Vetter, kernel
In-Reply-To: <08B861A8-D4C2-48A6-9B05-B8CA43312834@goldelico.com>
Hi Paul & Paul,
> Am 03.05.2020 um 18:41 schrieb H. Nikolaus Schaller <hns@goldelico.com>:
>
> Hi Paul and Paul,
>
>> Am 03.05.2020 um 16:18 schrieb Paul Cercueil <paul@crapouillou.net>:
>>
>>
>>
>> Le dim. 3 mai 2020 à 15:31, H. Nikolaus Schaller <hns@goldelico.com> a écrit :
>>> Hi Paul,
>>>> Am 03.05.2020 um 14:52 schrieb Paul Cercueil <paul@crapouillou.net>:
>>>>>> It's possible to forbid the presence of the 'clocks' property on some implementations, and require it on others.
>>>>> To be precise we have to specify the exact number of clocks (between 0 and 4) for every architecture.
>>>>> This also contradicts my dream to get rid of the architecture specific components in the long run. My dream (because I can't tell how it can be done) is that we can one day develop something which just needs compatible = img,530 or imp,540 or img,544. Then we can't make the number clocks depend on the implementation any more.
>>>> As we said before, the number of clocks is a property of the GPU and *not* its integration into the SoC.
>>> Well, it is a not very well documented property of the GPU. We have no data sheet of the standalone GPU. Only several SoC data sheets which give some indications.
>>
>> Maybe we can nicely ask them?
>
> There is some (old) answer here:
>
> https://github.com/MIPS/CI20_linux/blob/ci20-v3.18/arch/mips/boot/dts/jz4780.dtsi#L63
>
>> I expect Paul Burton to have some contacts at ImgTec. Asking for a doc would be too much, but maybe they can help a bit with the DT bindings.
>
> Good idea! It is definitively worth to try. Therefore I have moved him from CC: to To:
Do we already have an idea if we can get into contact and get help from ImgTec for this topic or if we have to live with what we have?
BR and thanks,
Nikolaus
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* [GIT PULL] arm64: defconfig: hisilicon config updates for v5.8
From: Wei Xu @ 2020-05-15 7:17 UTC (permalink / raw)
To: soc, arm@kernel.org, linux-arm-kernel@lists.infradead.org
Cc: Salil Mehta, Tangkunshan, Arnd Bergmann, John Garry, Linuxarm,
Shameerali Kolothum Thodi, Wangzhou (B), huangdaode, xuwei (O),
Jonathan Cameron, Olof Johansson, Liguozhu (Kenneth), Zhangyi ac,
Shiju Jose
Hi ARM-SoC team,
Please consider to pull the following changes.
Thanks!
Best Regards,
Wei
---
The following changes since commit 8f3d9f354286745c751374f5f1fcafee6b3f3136:
Linux 5.7-rc1 (2020-04-12 12:35:55 -0700)
are available in the Git repository at:
git://github.com/hisilicon/linux-hisi.git tags/hisi-arm64-defconfig-for-5.8
for you to fetch changes up to 528443e32a3d53000d30bb8be04a382b04e57470:
arm64: defconfig: Enable UACCE/PCI PASID/SEC2/HPRE configs (2020-05-15 09:29:47 +0800)
----------------------------------------------------------------
ARM64: hisilicon: defconfig updates for 5.8
- Enable PCI PASID as built-in module and UACCE/SEC2/HPRE as
loadable modules to support UACCE use case for the D06CS board
----------------------------------------------------------------
Zhou Wang (1):
arm64: defconfig: Enable UACCE/PCI PASID/SEC2/HPRE configs
arch/arm64/configs/defconfig | 4 ++++
1 file changed, 4 insertions(+)
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH] arm64: defconfig: Enable UACCE/PCI PASID/SEC2/HPRE configs
From: Wei Xu @ 2020-05-15 7:13 UTC (permalink / raw)
To: Zhou Wang, xuwei5, Catalin Marinas, Will Deacon
Cc: linuxarm, linux-arm-kernel
In-Reply-To: <1588989918-53184-1-git-send-email-wangzhou1@hisilicon.com>
Hi Zhou,
On 2020/5/9 10:05, Zhou Wang wrote:
> Enable configs for UACCE, PCI PASID, HiSilicon SEC2 and HPRE drivers.
>
> Signed-off-by: Zhou Wang <wangzhou1@hisilicon.com>
> ---
> arch/arm64/configs/defconfig | 4 ++++
> 1 file changed, 4 insertions(+)
>
> diff --git a/arch/arm64/configs/defconfig b/arch/arm64/configs/defconfig
> index 24e534d..b6edf59 100644
> --- a/arch/arm64/configs/defconfig
> +++ b/arch/arm64/configs/defconfig
> @@ -188,6 +188,7 @@ CONFIG_NET_9P_VIRTIO=y
> CONFIG_PCI=y
> CONFIG_PCIEPORTBUS=y
> CONFIG_PCI_IOV=y
> +CONFIG_PCI_PASID=y
> CONFIG_HOTPLUG_PCI=y
> CONFIG_HOTPLUG_PCI_ACPI=y
> CONFIG_PCI_AARDVARK=y
> @@ -241,6 +242,7 @@ CONFIG_BLK_DEV_NVME=m
> CONFIG_SRAM=y
> CONFIG_EEPROM_AT24=m
> CONFIG_EEPROM_AT25=m
> +CONFIG_UACCE=m
> # CONFIG_SCSI_PROC_FS is not set
> CONFIG_BLK_DEV_SD=y
> CONFIG_SCSI_SAS_ATA=y
> @@ -968,6 +970,8 @@ CONFIG_CRYPTO_DEV_FSL_CAAM=m
> CONFIG_CRYPTO_DEV_FSL_DPAA2_CAAM=m
> CONFIG_CRYPTO_DEV_QCOM_RNG=m
> CONFIG_CRYPTO_DEV_CCREE=m
> +CONFIG_CRYPTO_DEV_HISI_SEC2=m
> +CONFIG_CRYPTO_DEV_HISI_HPRE=m
> CONFIG_CRYPTO_DEV_HISI_ZIP=m
> CONFIG_CMA_SIZE_MBYTES=32
> CONFIG_PRINTK_TIME=y
>
Thanks!
Applied to the hisilicon arm64 defconfig tree by swapping the order
between CONFIG_CRYPTO_DEV_HISI_HPRE and CONFIG_CRYPTO_DEV_HISI_ZIP
according the menuconfig.
Best Regards,
Wei
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* RE: [PATCH v2 7/8] iio: core: simplify alloc alignment code
From: Sa, Nuno @ 2020-05-15 7:12 UTC (permalink / raw)
To: Ardelean, Alexandru, linux-iio@vger.kernel.org,
linux-arm-kernel@lists.infradead.org,
linux-stm32@st-md-mailman.stormreply.com,
linux-kernel@vger.kernel.org
Cc: alexandre.belloni@bootlin.com, alexandre.torgue@st.com,
ludovic.desroches@microchip.com, ak@it-klinger.de,
mcoquelin.stm32@gmail.com, eugen.hristev@microchip.com,
Ardelean, Alexandru, jic23@kernel.org
In-Reply-To: <20200514131710.84201-8-alexandru.ardelean@analog.com>
Hey Alex,
Just a small question...
> From: linux-iio-owner@vger.kernel.org <linux-iio-owner@vger.kernel.org>
> On Behalf Of Alexandru Ardelean
> Sent: Donnerstag, 14. Mai 2020 15:17
> To: linux-iio@vger.kernel.org; linux-arm-kernel@lists.infradead.org; linux-
> stm32@st-md-mailman.stormreply.com; linux-kernel@vger.kernel.org
> Cc: ludovic.desroches@microchip.com; eugen.hristev@microchip.com;
> jic23@kernel.org; nicolas.ferre@microchip.com;
> alexandre.belloni@bootlin.com; alexandre.torgue@st.com;
> mcoquelin.stm32@gmail.com; ak@it-klinger.de; Ardelean, Alexandru
> <alexandru.Ardelean@analog.com>
> Subject: [PATCH v2 7/8] iio: core: simplify alloc alignment code
>
> There was a recent discussion about this code:
> https://urldefense.com/v3/__https://lore.kernel.org/linux-
> iio/20200322165317.0b1f0674@archlinux/__;!!A3Ni8CS0y2Y!pgdUSayJCfxMiE
> w8Fpv0LkEZurCSkX0sEcLnXeDSCLmhpu1xont6-vBQj3ZbCw$
>
> This looks like a good time to rework this, since any issues about it
> should pop-up under testing, because the iio_dev is having a bit of an
> overhaul and stuff being moved to iio_dev_priv.
>
> Signed-off-by: Alexandru Ardelean <alexandru.ardelean@analog.com>
> ---
> drivers/iio/industrialio-core.c | 10 +++-------
> 1 file changed, 3 insertions(+), 7 deletions(-)
>
> diff --git a/drivers/iio/industrialio-core.c b/drivers/iio/industrialio-core.c
> index a1b29e0f8fd6..7671d36efae7 100644
> --- a/drivers/iio/industrialio-core.c
> +++ b/drivers/iio/industrialio-core.c
> @@ -1514,13 +1514,9 @@ struct iio_dev *iio_device_alloc(int sizeof_priv)
> struct iio_dev *dev;
> size_t alloc_size;
>
> - alloc_size = sizeof(struct iio_dev_opaque);
> - if (sizeof_priv) {
> - alloc_size = ALIGN(alloc_size, IIO_ALIGN);
> - alloc_size += sizeof_priv;
> - }
> - /* ensure 32-byte alignment of whole construct ? */
> - alloc_size += IIO_ALIGN - 1;
> + alloc_size = ALIGN(sizeof(struct iio_dev_opaque), IIO_ALIGN);
> + if (sizeof_priv)
> + alloc_size += ALIGN(sizeof_priv, IIO_ALIGN);
Do we actually need to do the `ALIGN` again? It seems to me that `alloc_size += sizeof_priv`
would be enough or am I missing something obvious?
- Nuno Sá
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH v3 10/15] net: ethernet: mtk-eth-mac: new driver
From: Bartosz Golaszewski @ 2020-05-15 7:11 UTC (permalink / raw)
To: Arnd Bergmann
Cc: Edwin Peer, DTML, Bartosz Golaszewski, Stephane Le Provost,
Jonathan Corbet, Networking, Sean Wang,
linux-kernel@vger.kernel.org, Pedro Tsai, Mark Lee, Fabien Parent,
Rob Herring, moderated list:ARM/Mediatek SoC..., Andrew Perepech,
John Crispin, Matthias Brugger, Jakub Kicinski, David S . Miller,
Linux ARM, Heiner Kallweit
In-Reply-To: <CAK8P3a3=xgbvqrSpCK5h96eRH32AA7xnoK2ossvT0-cLFLzmXA@mail.gmail.com>
czw., 14 maj 2020 o 18:19 Arnd Bergmann <arnd@arndb.de> napisał(a):
>
> On Thu, May 14, 2020 at 10:00 AM Bartosz Golaszewski <brgl@bgdev.pl> wrote:
> >
> > From: Bartosz Golaszewski <bgolaszewski@baylibre.com>
> >
> > This adds the driver for the MediaTek Ethernet MAC used on the MT8* SoC
> > family. For now we only support full-duplex.
> >
> > Signed-off-by: Bartosz Golaszewski <bgolaszewski@baylibre.com>
>
> Looks very nice overall. Just a few things I noticed, and some ideas
> that may or may not make sense:
>
> > +/* This is defined to 0 on arm64 in arch/arm64/include/asm/processor.h but
> > + * this IP doesn't work without this alignment being equal to 2.
> > + */
> > +#ifdef NET_IP_ALIGN
> > +#undef NET_IP_ALIGN
> > +#endif
> > +#define NET_IP_ALIGN 2
>
> Maybe you should just define your own macro instead of replacing
> the normal one then?
>
I did in an earlier version and was told to use NET_IP_ALIGN but then
found out its value on arm64 doesn't work for me so I did the thing
that won't make anybody happy - redefine the existing constant. :)
> > +static void mtk_mac_lock(struct mtk_mac_priv *priv)
> > +{
> > + spin_lock_irqsave(&priv->lock, priv->lock_flags);
> > +}
> > +
> > +static void mtk_mac_unlock(struct mtk_mac_priv *priv)
> > +{
> > + spin_unlock_irqrestore(&priv->lock, priv->lock_flags);
> > +}
>
> This looks wrong: you should not have shared 'flags' passed into
> spin_lock_irqsave(), and I don't even see a need to use the
> irqsave variant of the lock in the first place.
>
> Maybe start by open-coding the lock and remove the wrappers
> above.
>
> Then see if you can use a cheaper spin_lock_bh() or plain spin_lock()
> instead of irqsave.
>
This is from an earlier version where I did a lot more in hard irq
context. Now that almost all of the processing happens in soft-irq
context I guess you're right - I can go with a regular spin_lock().
> Finally, see if this can be done in a lockless way by relying on
> appropriate barriers and separating the writers into separate
> cache lines. From a brief look at the driver I think it can be done
> without too much trouble.
>
Unfortunately I do need some locking. Accessing RX and TX descriptors
at the same time seems to upset the controller. I experimented a lot
with barriers but it turned out that I got a lot of weird bugs at high
throughput.
> > +static unsigned int mtk_mac_intr_read_and_clear(struct mtk_mac_priv *priv)
> > +{
> > + unsigned int val;
> > +
> > + regmap_read(priv->regs, MTK_MAC_REG_INT_STS, &val);
> > + regmap_write(priv->regs, MTK_MAC_REG_INT_STS, val);
> > +
> > + return val;
> > +}
>
> Do you actually need to read the register? That is usually a relatively
> expensive operation, so if possible try to use clear the bits when
> you don't care which bits were set.
>
I do care, I'm afraid. The returned value is being used in the napi
poll callback to see which ring to process.
> > +/* All processing for TX and RX happens in the napi poll callback. */
> > +static irqreturn_t mtk_mac_handle_irq(int irq, void *data)
> > +{
> > + struct mtk_mac_priv *priv;
> > + struct net_device *ndev;
> > +
> > + ndev = data;
> > + priv = netdev_priv(ndev);
> > +
> > + if (netif_running(ndev)) {
> > + mtk_mac_intr_mask_all(priv);
> > + napi_schedule(&priv->napi);
> > + }
> > +
> > + return IRQ_HANDLED;
>
>
> > +static int mtk_mac_netdev_start_xmit(struct sk_buff *skb,
> > + struct net_device *ndev)
> > +{
> > + struct mtk_mac_priv *priv = netdev_priv(ndev);
> > + struct mtk_mac_ring *ring = &priv->tx_ring;
> > + struct device *dev = mtk_mac_get_dev(priv);
> > + struct mtk_mac_ring_desc_data desc_data;
> > +
> > + desc_data.dma_addr = mtk_mac_dma_map_tx(priv, skb);
> > + if (dma_mapping_error(dev, desc_data.dma_addr))
> > + goto err_drop_packet;
> > +
> > + desc_data.skb = skb;
> > + desc_data.len = skb->len;
> > +
> > + mtk_mac_lock(priv);
> > + mtk_mac_ring_push_head_tx(ring, &desc_data);
> > +
> > + if (mtk_mac_ring_full(ring))
> > + netif_stop_queue(ndev);
> > + mtk_mac_unlock(priv);
> > +
> > + mtk_mac_dma_resume_tx(priv);
> > +
> > + return NETDEV_TX_OK;
> > +
> > +err_drop_packet:
> > + dev_kfree_skb(skb);
> > + ndev->stats.tx_dropped++;
> > + return NETDEV_TX_BUSY;
> > +}
>
> I would always add BQL flow control in new drivers, using
> netdev_sent_queue here...
>
Ok, will do.
> > +static int mtk_mac_tx_complete_one(struct mtk_mac_priv *priv)
> > +{
> > + struct mtk_mac_ring *ring = &priv->tx_ring;
> > + struct mtk_mac_ring_desc_data desc_data;
> > + int ret;
> > +
> > + ret = mtk_mac_ring_pop_tail(ring, &desc_data);
> > + if (ret)
> > + return ret;
> > +
> > + mtk_mac_dma_unmap_tx(priv, &desc_data);
> > + dev_kfree_skb_irq(desc_data.skb);
> > +
> > + return 0;
> > +}
>
> ... and netdev_completed_queue() here.
>
Same here.
> > +static void mtk_mac_tx_complete_all(struct mtk_mac_priv *priv)
> > +{
> > + struct mtk_mac_ring *ring = &priv->tx_ring;
> > + struct net_device *ndev = priv->ndev;
> > + int ret;
> > +
> > + for (;;) {
> > + mtk_mac_lock(priv);
> > +
> > + if (!mtk_mac_ring_descs_available(ring)) {
> > + mtk_mac_unlock(priv);
> > + break;
> > + }
> > +
> > + ret = mtk_mac_tx_complete_one(priv);
> > + if (ret) {
> > + mtk_mac_unlock(priv);
> > + break;
> > + }
> > +
> > + if (netif_queue_stopped(ndev))
> > + netif_wake_queue(ndev);
> > +
> > + mtk_mac_unlock(priv);
> > + }
> > +}
>
> It looks like most of the stuff inside of the loop can be pulled out
> and only done once here.
>
I did that in one of the previous submissions but it was pointed out
to me that a parallel TX path may fill up the queue before I wake it.
> > +static int mtk_mac_poll(struct napi_struct *napi, int budget)
> > +{
> > + struct mtk_mac_priv *priv;
> > + unsigned int status;
> > + int received = 0;
> > +
> > + priv = container_of(napi, struct mtk_mac_priv, napi);
> > +
> > + status = mtk_mac_intr_read_and_clear(priv);
> > +
> > + /* Clean up TX */
> > + if (status & MTK_MAC_BIT_INT_STS_TNTC)
> > + mtk_mac_tx_complete_all(priv);
> > +
> > + /* Receive up to $budget packets */
> > + if (status & MTK_MAC_BIT_INT_STS_FNRC)
> > + received = mtk_mac_process_rx(priv, budget);
> > +
> > + /* One of the counter reached 0x8000000 - update stats and reset all
> > + * counters.
> > + */
> > + if (status & MTK_MAC_REG_INT_STS_MIB_CNT_TH) {
> > + mtk_mac_update_stats(priv);
> > + mtk_mac_reset_counters(priv);
> > + }
> > +
> > + if (received < budget)
> > + napi_complete_done(napi, received);
> > +
> > + mtk_mac_intr_unmask_all(priv);
> > +
> > + return received;
> > +}
>
> I think you want to leave (at least some of) the interrupts masked
> if your budget is exhausted, to avoid generating unnecessary
> irqs.
>
The networking stack shouldn't queue any new TX packets if the queue
is stopped - is this really worth complicating the code? Looks like
premature optimization IMO.
> It may also be faster to not mask/unmask at all but just
> clear the interrupts that you have finished processing
>
Bart
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH v7 0/2] Amlogic 32-bit Meson SoC SDHC MMC controller driver
From: Ulf Hansson @ 2020-05-15 7:09 UTC (permalink / raw)
To: Martin Blumenstingl
Cc: DTML, Jianxin Pan, Anand Moon, linux-mmc@vger.kernel.org,
Linux Kernel Mailing List, yinxin_1989, Rob Herring,
open list:ARM/Amlogic Meson..., Jerome Brunet, Linux ARM, lnykww
In-Reply-To: <20200512204147.504087-1-martin.blumenstingl@googlemail.com>
On Tue, 12 May 2020 at 22:42, Martin Blumenstingl
<martin.blumenstingl@googlemail.com> wrote:
>
> Hello,
>
> this is the patchset for a driver for the Amlogic "SDHC" MMC controller
> found on Meson6, Meson8, Meson8b and Meson8m2 SoCs.
>
> The public S805 (Meson8b) datasheet has some documentation starting on
> page 74: [0]
>
> It's performance is still not as good as the driver from Amlogic's 3.10
> kernel, but it does not corrupt data anymore (as RFC v1 did).
>
> Special thanks to the people who supported me off-list - you are
> amazing and deserve to be mentioned here:
> - Xin Yin who helped me fix two more write corruption problems. I am
> hoping that he will reply with Reviewed-by, Tested-by and Bug-fixed-by
> - Jianxin Pan for sharing some of the internal workings of this MMC
> controller with me
> - Wei Wang for spotting the initial write corruption problem and helping
> test this driver on his board. I have his permission to add his
> Tested-by (off-list, he's Cc'ed so if there's any problem he can speak
> up)
>
>
> Changes since v6 at [6]:
> - both patches: dropped the clock #include from the dt-bindings as well
> as #clock-cells = <1> and the self-referencing clock inputs. Instead
> the driver will not be registering a clock provider anymore. The
> clock references are obtained using "clk_hw.clk" (thus not going
> through the dt-bindings anymore) as suggested in [7] until a better
> solution is implemented. A TODO comment is also in place so it's
> easier to find this temporary workaround when the new helper exists.
> - dropped Rob's Reviewed-by because I modified the dt-bindings. schema
> validation still passes on my build machine.
> - patch #2: dropped MMC_CAP_ERASE due to the following patch which is
> queued in mmc's -next: "mmc: host: Drop redundant MMC_CAP_ERASE"
> - patch #2: fill all clk_{mux,divider,gate,hw} values in
> meson_mx_sdhc_register_clkc instead of using loops and two separate
> structs to make the code easier to read. Thanks to Jerome for the
> suggestion.
> - I decided to keep all the Tested-by's because testing was smooth
> for me and none of the clock calculation formulas has changed (only
> the API how to obtain the clocks).
>
> Changes since v5 at [5] (thanks to Ulf and Jerome for the feedback):
> - changed copyright year to 2020
> - move register #defines to a separate header file
> - drop unused include linux/clk-provider.h from meson-mx-sdhc.c
> - used #defines for regmap_read_poll_timeout timeout/sleep values
> - set MMC_CAP_WAIT_WHILE_BUSY
> - move the clock controller code to mmc/host/meson-mx-sdhc-clkc.c and
> don't register a separate platform_device for it. This also means
> that the driver switched from clk_regmap to the standard
> clk_{divider,gate,mux}_ops
> - dropped ".index = -1" for clk_parent_data with .fw_name
> - use CLK_SET_RATE_PARENT on all leaf clocks and drop
> CLK_SET_RATE_GATE
> - switch from parent_data.name to parent_hws
> - use fallthrough; instead of fallthrough comment
> - added Anand's Tested-by - thank you!
> - I decided to keep all Tested-by and Reviewed-by because they were
> only for the MMC controller part and I have barely touched that with
> this update.
> - Ulf asked if the timeout can be shortened. I believe it can but I
> have no documentation for it. Thus I need a test-case to see if my
> assumptions are correct - thus I have not addressed this in v6 yet
>
> Changes since v4 at [4]:
> - move the four clkin clock inputs to the start of the clock-names list
> as suggested by Rob, affects patch #1
> - fixed #include statement in dt-bindings example in patch #1
>
> Changes since v3 at [3]:
> - split the clock bits into a separate clock controller driver because
> of two reasons: 1) it keeps the MMC controller driver mostly clean of
> the clock bits 2) the pure clock controller can use
> devm_clk_hw_register() (instead of devm_clk_register(), which is
> deprecated) and the MMC controller can act as a pure clock consumer.
> This also affects the dt-bindings which is why I dropped Rob's
> Reviewed-by. Thanks to Ulf for the suggestions
>
> Changes since v2 at [2]:
> - rebased on top of v5.5-rc1
> - added Rob's and Xin Yin's Reviewed-by and Tested-by (thank you!)
> - (note: Kevin had v2 of this series in -next for a few days so the
> build test robots could play with it. I haven't received any negative
> feedback in that time)
>
> Changes since RFC v1 at [1]:
> - don't set MESON_SDHC_MISC_MANUAL_STOP to fix one of three write
> corruption problems. the out-of-tree 3.10 "reference" driver doesn't
> set it either
> - check against data->flags instead of cmd->flags when testing for
> MMC_DATA_WRITE as spotted by Xin Yin (many thanks!). This fixes
> another write corruption problem
> - clear the FIFOs after successfully transferring data as suggested by
> Xin Yin (many thanks!). This is what the 3.10 driver did and fixes yet
> another write corruption problem
> - integrate the clock suggestions from Jianxin Pan so the driver is now
> able to set up the clocks correctly for all known cases. documentation
> is also added to the patch description. Thank you Jianxin for the
> help!
> - set the correct max_busy_timeout as suggested by Jianxin Pan (thanks!)
> - convert the dt-bindings to .yaml (which is why I didn't add Rob's
> Reviewed-by)
> - switch to struct clk_parent_data as part of newer common clock
> framework APIs to simplify the clock setup
> - dropped CMD23 support because it seems to hurt read and write
> performance by 10-20% in my tests. it's not clear why, but for now we
> can live without this.
> - use devm_platform_ioremap_resource instead of open-coding it
>
>
> [0] https://dn.odroid.com/S805/Datasheet/S805_Datasheet%20V0.8%2020150126.pdf
> [1] https://patchwork.kernel.org/cover/11035505/
> [2] http://lists.infradead.org/pipermail/linux-amlogic/2019-November/014576.html
> [3] https://patchwork.kernel.org/cover/11283179/
> [4] https://patchwork.kernel.org/cover/11329017/
> [5] https://patchwork.kernel.org/cover/11463341/
> [6] https://patchwork.kernel.org/cover/11515603/
> [7] https://lore.kernel.org/linux-clk/158870581453.26370.15255632521260524214@swboyd.mtv.corp.google.com/
>
>
> Martin Blumenstingl (2):
> dt-bindings: mmc: Document the Amlogic Meson SDHC MMC host controller
> mmc: host: meson-mx-sdhc: new driver for the Amlogic Meson SDHC host
>
> .../bindings/mmc/amlogic,meson-mx-sdhc.yaml | 68 ++
> drivers/mmc/host/Kconfig | 14 +
> drivers/mmc/host/Makefile | 1 +
> drivers/mmc/host/meson-mx-sdhc-clkc.c | 158 +++
> drivers/mmc/host/meson-mx-sdhc.c | 907 ++++++++++++++++++
> drivers/mmc/host/meson-mx-sdhc.h | 141 +++
> 6 files changed, 1289 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/mmc/amlogic,meson-mx-sdhc.yaml
> create mode 100644 drivers/mmc/host/meson-mx-sdhc-clkc.c
> create mode 100644 drivers/mmc/host/meson-mx-sdhc.c
> create mode 100644 drivers/mmc/host/meson-mx-sdhc.h
>
Applied for next, thanks!
Kind regards
Uffe
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH] mmc: sdhci: use FIELD_GET/PREP for current capabilities bit masks
From: Ulf Hansson @ 2020-05-15 7:09 UTC (permalink / raw)
To: Masahiro Yamada
Cc: Shawn Guo, Sascha Hauer, linux-mmc@vger.kernel.org, Adrian Hunter,
Linux Kernel Mailing List, NXP Linux Team,
Pengutronix Kernel Team, Fabio Estevam, Linux ARM
In-Reply-To: <20200511062828.1791484-1-yamada.masahiro@socionext.com>
On Mon, 11 May 2020 at 08:29, Masahiro Yamada
<yamada.masahiro@socionext.com> wrote:
>
> Use FIELD_GET and FIELD_PREP to get access to the register fields. Delete
> the shift macros and use GENMASK() for the touched macros.
>
> Note that, this has the side-effect of changing the constants to 64-bit on
> 64-bit platforms.
>
> Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
Applied for next, thanks!
Kind regards
Uffe
> ---
>
> drivers/mmc/host/sdhci-esdhc-imx.c | 6 +++---
> drivers/mmc/host/sdhci.c | 27 ++++++++++++---------------
> drivers/mmc/host/sdhci.h | 11 ++++-------
> 3 files changed, 19 insertions(+), 25 deletions(-)
>
> diff --git a/drivers/mmc/host/sdhci-esdhc-imx.c b/drivers/mmc/host/sdhci-esdhc-imx.c
> index 38cd83118082..9896e03fce71 100644
> --- a/drivers/mmc/host/sdhci-esdhc-imx.c
> +++ b/drivers/mmc/host/sdhci-esdhc-imx.c
> @@ -419,9 +419,9 @@ static u32 esdhc_readl_le(struct sdhci_host *host, int reg)
>
> if (unlikely(reg == SDHCI_MAX_CURRENT) && esdhc_is_usdhc(imx_data)) {
> val = 0;
> - val |= 0xFF << SDHCI_MAX_CURRENT_330_SHIFT;
> - val |= 0xFF << SDHCI_MAX_CURRENT_300_SHIFT;
> - val |= 0xFF << SDHCI_MAX_CURRENT_180_SHIFT;
> + val |= FIELD_PREP(SDHCI_MAX_CURRENT_330_MASK, 0xFF);
> + val |= FIELD_PREP(SDHCI_MAX_CURRENT_300_MASK, 0xFF);
> + val |= FIELD_PREP(SDHCI_MAX_CURRENT_180_MASK, 0xFF);
> }
>
> if (unlikely(reg == SDHCI_INT_STATUS)) {
> diff --git a/drivers/mmc/host/sdhci.c b/drivers/mmc/host/sdhci.c
> index 344a7e0e33fe..7818e650f974 100644
> --- a/drivers/mmc/host/sdhci.c
> +++ b/drivers/mmc/host/sdhci.c
> @@ -4355,35 +4355,32 @@ int sdhci_setup_host(struct sdhci_host *host)
>
> curr = min_t(u32, curr, SDHCI_MAX_CURRENT_LIMIT);
> max_current_caps =
> - (curr << SDHCI_MAX_CURRENT_330_SHIFT) |
> - (curr << SDHCI_MAX_CURRENT_300_SHIFT) |
> - (curr << SDHCI_MAX_CURRENT_180_SHIFT);
> + FIELD_PREP(SDHCI_MAX_CURRENT_330_MASK, curr) |
> + FIELD_PREP(SDHCI_MAX_CURRENT_300_MASK, curr) |
> + FIELD_PREP(SDHCI_MAX_CURRENT_180_MASK, curr);
> }
> }
>
> if (host->caps & SDHCI_CAN_VDD_330) {
> ocr_avail |= MMC_VDD_32_33 | MMC_VDD_33_34;
>
> - mmc->max_current_330 = ((max_current_caps &
> - SDHCI_MAX_CURRENT_330_MASK) >>
> - SDHCI_MAX_CURRENT_330_SHIFT) *
> - SDHCI_MAX_CURRENT_MULTIPLIER;
> + mmc->max_current_330 = FIELD_GET(SDHCI_MAX_CURRENT_330_MASK,
> + max_current_caps) *
> + SDHCI_MAX_CURRENT_MULTIPLIER;
> }
> if (host->caps & SDHCI_CAN_VDD_300) {
> ocr_avail |= MMC_VDD_29_30 | MMC_VDD_30_31;
>
> - mmc->max_current_300 = ((max_current_caps &
> - SDHCI_MAX_CURRENT_300_MASK) >>
> - SDHCI_MAX_CURRENT_300_SHIFT) *
> - SDHCI_MAX_CURRENT_MULTIPLIER;
> + mmc->max_current_300 = FIELD_GET(SDHCI_MAX_CURRENT_300_MASK,
> + max_current_caps) *
> + SDHCI_MAX_CURRENT_MULTIPLIER;
> }
> if (host->caps & SDHCI_CAN_VDD_180) {
> ocr_avail |= MMC_VDD_165_195;
>
> - mmc->max_current_180 = ((max_current_caps &
> - SDHCI_MAX_CURRENT_180_MASK) >>
> - SDHCI_MAX_CURRENT_180_SHIFT) *
> - SDHCI_MAX_CURRENT_MULTIPLIER;
> + mmc->max_current_180 = FIELD_GET(SDHCI_MAX_CURRENT_180_MASK,
> + max_current_caps) *
> + SDHCI_MAX_CURRENT_MULTIPLIER;
> }
>
> /* If OCR set by host, use it instead. */
> diff --git a/drivers/mmc/host/sdhci.h b/drivers/mmc/host/sdhci.h
> index d7f1441b0fc3..2ff98891bf25 100644
> --- a/drivers/mmc/host/sdhci.h
> +++ b/drivers/mmc/host/sdhci.h
> @@ -233,13 +233,10 @@
> #define SDHCI_SUPPORT_HS400 0x80000000 /* Non-standard */
>
> #define SDHCI_MAX_CURRENT 0x48
> -#define SDHCI_MAX_CURRENT_LIMIT 0xFF
> -#define SDHCI_MAX_CURRENT_330_MASK 0x0000FF
> -#define SDHCI_MAX_CURRENT_330_SHIFT 0
> -#define SDHCI_MAX_CURRENT_300_MASK 0x00FF00
> -#define SDHCI_MAX_CURRENT_300_SHIFT 8
> -#define SDHCI_MAX_CURRENT_180_MASK 0xFF0000
> -#define SDHCI_MAX_CURRENT_180_SHIFT 16
> +#define SDHCI_MAX_CURRENT_LIMIT GENMASK(7, 0)
> +#define SDHCI_MAX_CURRENT_330_MASK GENMASK(7, 0)
> +#define SDHCI_MAX_CURRENT_300_MASK GENMASK(15, 8)
> +#define SDHCI_MAX_CURRENT_180_MASK GENMASK(23, 16)
> #define SDHCI_MAX_CURRENT_MULTIPLIER 4
>
> /* 4C-4F reserved for more max current */
> --
> 2.25.1
>
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH] mmc: uniphier-sd: call devm_request_irq() after tmio_mmc_host_probe()
From: Ulf Hansson @ 2020-05-15 7:09 UTC (permalink / raw)
To: Masahiro Yamada
Cc: Wolfram Sang, linux-mmc@vger.kernel.org,
Linux Kernel Mailing List, Linux ARM
In-Reply-To: <20200511062158.1790924-1-yamada.masahiro@socionext.com>
On Mon, 11 May 2020 at 08:22, Masahiro Yamada
<yamada.masahiro@socionext.com> wrote:
>
> Currently, tmio_mmc_irq() handler is registered before the host is
> fully initialized by tmio_mmc_host_probe(). I did not previously notice
> this problem.
>
> The boot ROM of a new Socionext SoC unmasks interrupts (CTL_IRQ_MASK)
> somehow. The handler is invoked before tmio_mmc_host_probe(), then
> emits noisy call trace.
>
> Move devm_request_irq() below tmio_mmc_host_probe().
>
> Fixes: 3fd784f745dd ("mmc: uniphier-sd: add UniPhier SD/eMMC controller driver")
> Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
Applied for next, and by adding a stable tag, thanks!
Kind regards
Uffe
> ---
>
> drivers/mmc/host/uniphier-sd.c | 12 +++++++-----
> 1 file changed, 7 insertions(+), 5 deletions(-)
>
> diff --git a/drivers/mmc/host/uniphier-sd.c b/drivers/mmc/host/uniphier-sd.c
> index a1683c49cb90..f82baf99fd69 100644
> --- a/drivers/mmc/host/uniphier-sd.c
> +++ b/drivers/mmc/host/uniphier-sd.c
> @@ -610,11 +610,6 @@ static int uniphier_sd_probe(struct platform_device *pdev)
> }
> }
>
> - ret = devm_request_irq(dev, irq, tmio_mmc_irq, IRQF_SHARED,
> - dev_name(dev), host);
> - if (ret)
> - goto free_host;
> -
> if (priv->caps & UNIPHIER_SD_CAP_EXTENDED_IP)
> host->dma_ops = &uniphier_sd_internal_dma_ops;
> else
> @@ -642,8 +637,15 @@ static int uniphier_sd_probe(struct platform_device *pdev)
> if (ret)
> goto free_host;
>
> + ret = devm_request_irq(dev, irq, tmio_mmc_irq, IRQF_SHARED,
> + dev_name(dev), host);
> + if (ret)
> + goto remove_host;
> +
> return 0;
>
> +remove_host:
> + tmio_mmc_host_remove(host);
> free_host:
> tmio_mmc_host_free(host);
>
> --
> 2.25.1
>
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH v2 0/3] io.h, logic_pio: Allow barriers for inX() and outX() be overridden
From: Wei Xu @ 2020-05-15 7:07 UTC (permalink / raw)
To: John Garry, xuwei5, arnd
Cc: linux-arch, okaya, linux-kernel, jiaxun.yang, linuxarm, olof,
bhelgaas, linux-arm-kernel
In-Reply-To: <1585325174-195915-1-git-send-email-john.garry@huawei.com>
Hi John,
On 2020/3/28 0:06, John Garry wrote:
> Since commits a7851aa54c0c ("io: change outX() to have their own IO
> barrier overrides") and 87fe2d543f81 ("io: change inX() to have their own
> IO barrier overrides"), the outX() and inX() functions have memory
> barriers which can be overridden per-arch.
>
> However, under CONFIG_INDIRECT_PIO, logic_pio defines its own version of
> inX() and outX(), which still use readb et al. For these, the barrier
> after a raw read is weaker than it otherwise would be.
>
> This series generates consistent behaviour for logic_pio, by defining
> generic _inX() and _outX() in asm-generic/io.h, and using those in
> logic_pio. Generic _inX() and _outX() have per-arch overrideable
> barriers.
>
> The topic was discussed there originally:
> https://lore.kernel.org/lkml/2e80d7bc-32a0-cc40-00a9-8a383a1966c2@huawei.com/
>
> A small tidy-up patch is included.
>
> I hope that series can go through the arm-soc tree, as with other recent
> logic_pio changes.
>
> Hi Arnd,
>
> I added your tag, but please let me know if you have any issue with the
> updated change in patch #1.
>
> cheers
>
> - Differences to v1
> - fix x86 clang build by adding extra build swicth for _{in,out}X
> - added Arnd's RB tag
>
> John Garry (3):
> io: Provide _inX() and _outX()
> logic_pio: Improve macro argument name
> logic_pio: Use _inX() and _outX()
>
> include/asm-generic/io.h | 64 +++++++++++++++++++++++++++++++++---------------
> lib/logic_pio.c | 22 ++++++++---------
> 2 files changed, 55 insertions(+), 31 deletions(-)
>
Thanks!
Series applied to the hisilicon SoC tree.
Best Regards,
Wei
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH] dt-bindings: hisilicon: Add CTI bindings for hi-6220
From: Wei Xu @ 2020-05-15 7:06 UTC (permalink / raw)
To: Mike Leach, devicetree, linux-arm-kernel, coresight
Cc: mathieu.poirier, suzuki.poulose
In-Reply-To: <20200415201259.15831-1-mike.leach@linaro.org>
Hi Mike,
On 2020/4/16 4:12, Mike Leach wrote:
> Adds in CTI device tree information for the Hikey620 board.
>
> Tested on Linux 5.7-rc1.
>
> Signed-off-by: Mike Leach <mike.leach@linaro.org>
> Reviewed-by: Mathieu Poirier <mathieu.poirier@linaro.org>
> Tested-by: Leo Yan <leo.yan@linaro.org>
Thanks!
Applied to the hisilicon arm64 dt tree.
Best Regards,
Wei
> ---
> .../boot/dts/hisilicon/hi6220-coresight.dtsi | 130 ++++++++++++++++--
> 1 file changed, 122 insertions(+), 8 deletions(-)
>
> diff --git a/arch/arm64/boot/dts/hisilicon/hi6220-coresight.dtsi b/arch/arm64/boot/dts/hisilicon/hi6220-coresight.dtsi
> index 651771a73ed6..27f067e87601 100644
> --- a/arch/arm64/boot/dts/hisilicon/hi6220-coresight.dtsi
> +++ b/arch/arm64/boot/dts/hisilicon/hi6220-coresight.dtsi
> @@ -213,7 +213,7 @@
> };
> };
>
> - etm@f659c000 {
> + etm0: etm@f659c000 {
> compatible = "arm,coresight-etm4x", "arm,primecell";
> reg = <0 0xf659c000 0 0x1000>;
>
> @@ -232,7 +232,7 @@
> };
> };
>
> - etm@f659d000 {
> + etm1: etm@f659d000 {
> compatible = "arm,coresight-etm4x", "arm,primecell";
> reg = <0 0xf659d000 0 0x1000>;
>
> @@ -251,7 +251,7 @@
> };
> };
>
> - etm@f659e000 {
> + etm2: etm@f659e000 {
> compatible = "arm,coresight-etm4x", "arm,primecell";
> reg = <0 0xf659e000 0 0x1000>;
>
> @@ -270,7 +270,7 @@
> };
> };
>
> - etm@f659f000 {
> + etm3: etm@f659f000 {
> compatible = "arm,coresight-etm4x", "arm,primecell";
> reg = <0 0xf659f000 0 0x1000>;
>
> @@ -289,7 +289,7 @@
> };
> };
>
> - etm@f65dc000 {
> + etm4: etm@f65dc000 {
> compatible = "arm,coresight-etm4x", "arm,primecell";
> reg = <0 0xf65dc000 0 0x1000>;
>
> @@ -308,7 +308,7 @@
> };
> };
>
> - etm@f65dd000 {
> + etm5: etm@f65dd000 {
> compatible = "arm,coresight-etm4x", "arm,primecell";
> reg = <0 0xf65dd000 0 0x1000>;
>
> @@ -327,7 +327,7 @@
> };
> };
>
> - etm@f65de000 {
> + etm6: etm@f65de000 {
> compatible = "arm,coresight-etm4x", "arm,primecell";
> reg = <0 0xf65de000 0 0x1000>;
>
> @@ -346,7 +346,7 @@
> };
> };
>
> - etm@f65df000 {
> + etm7: etm@f65df000 {
> compatible = "arm,coresight-etm4x", "arm,primecell";
> reg = <0 0xf65df000 0 0x1000>;
>
> @@ -364,5 +364,119 @@
> };
> };
> };
> +
> + /* System CTIs */
> + /* CTI 0 - TMC and TPIU connections */
> + cti@f6403000 {
> + compatible = "arm,coresight-cti", "arm,primecell";
> + reg = <0 0xf6403000 0 0x1000>;
> +
> + clocks = <&acpu_sctrl HI6220_ACPU_SFT_AT_S>;
> + clock-names = "apb_pclk";
> + };
> +
> + /* CTI - CPU-0 */
> + cti@f6598000 {
> + compatible = "arm,coresight-cti-v8-arch", "arm,coresight-cti",
> + "arm,primecell";
> + reg = <0 0xf6598000 0 0x1000>;
> +
> + clocks = <&acpu_sctrl HI6220_ACPU_SFT_AT_S>;
> + clock-names = "apb_pclk";
> +
> + cpu = <&cpu0>;
> + arm,cs-dev-assoc = <&etm0>;
> + };
> +
> + /* CTI - CPU-1 */
> + cti@f6599000 {
> + compatible = "arm,coresight-cti-v8-arch", "arm,coresight-cti",
> + "arm,primecell";
> + reg = <0 0xf6599000 0 0x1000>;
> +
> + clocks = <&acpu_sctrl HI6220_ACPU_SFT_AT_S>;
> + clock-names = "apb_pclk";
> +
> + cpu = <&cpu1>;
> + arm,cs-dev-assoc = <&etm1>;
> + };
> +
> + /* CTI - CPU-2 */
> + cti@f659a000 {
> + compatible = "arm,coresight-cti-v8-arch", "arm,coresight-cti",
> + "arm,primecell";
> + reg = <0 0xf659a000 0 0x1000>;
> +
> + clocks = <&acpu_sctrl HI6220_ACPU_SFT_AT_S>;
> + clock-names = "apb_pclk";
> +
> + cpu = <&cpu2>;
> + arm,cs-dev-assoc = <&etm2>;
> + };
> +
> + /* CTI - CPU-3 */
> + cti@f659b000 {
> + compatible = "arm,coresight-cti-v8-arch", "arm,coresight-cti",
> + "arm,primecell";
> + reg = <0 0xf659b000 0 0x1000>;
> +
> + clocks = <&acpu_sctrl HI6220_ACPU_SFT_AT_S>;
> + clock-names = "apb_pclk";
> +
> + cpu = <&cpu3>;
> + arm,cs-dev-assoc = <&etm3>;
> + };
> +
> + /* CTI - CPU-4 */
> + cti@f65d8000 {
> + compatible = "arm,coresight-cti-v8-arch", "arm,coresight-cti",
> + "arm,primecell";
> + reg = <0 0xf65d8000 0 0x1000>;
> +
> + clocks = <&acpu_sctrl HI6220_ACPU_SFT_AT_S>;
> + clock-names = "apb_pclk";
> +
> + cpu = <&cpu4>;
> + arm,cs-dev-assoc = <&etm4>;
> + };
> +
> + /* CTI - CPU-5 */
> + cti@f65d9000 {
> + compatible = "arm,coresight-cti-v8-arch", "arm,coresight-cti",
> + "arm,primecell";
> + reg = <0 0xf65d9000 0 0x1000>;
> +
> + clocks = <&acpu_sctrl HI6220_ACPU_SFT_AT_S>;
> + clock-names = "apb_pclk";
> +
> + cpu = <&cpu5>;
> + arm,cs-dev-assoc = <&etm5>;
> + };
> +
> + /* CTI - CPU-6 */
> + cti@f65da000 {
> + compatible = "arm,coresight-cti-v8-arch", "arm,coresight-cti",
> + "arm,primecell";
> + reg = <0 0xf65da000 0 0x1000>;
> +
> + clocks = <&acpu_sctrl HI6220_ACPU_SFT_AT_S>;
> + clock-names = "apb_pclk";
> +
> + cpu = <&cpu6>;
> + arm,cs-dev-assoc = <&etm6>;
> + };
> +
> + /* CTI - CPU-7 */
> + cti@f65db000 {
> + compatible = "arm,coresight-cti-v8-arch", "arm,coresight-cti",
> + "arm,primecell";
> + reg = <0 0xf65db000 0 0x1000>;
> +
> + clocks = <&acpu_sctrl HI6220_ACPU_SFT_AT_S>;
> + clock-names = "apb_pclk";
> +
> + cpu = <&cpu7>;
> + arm,cs-dev-assoc = <&etm7>;
> + };
> };
> };
>
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH] arm64: dts: hikey960: pinctrl: Fix spi2/spi3 pinconf
From: Wei Xu @ 2020-05-15 7:05 UTC (permalink / raw)
To: Loic Poulain, robh+dt; +Cc: linux-arm-kernel
In-Reply-To: <1585044472-16706-1-git-send-email-loic.poulain@linaro.org>
Hi Loic,
On 2020/3/24 18:07, Loic Poulain wrote:
> Only the pinmux was selected, not the pinconf, leading to spi issues.
> Increase drive strength so that max speed (25Mhz) can be achieved.
>
> Signed-off-by: Loic Poulain <loic.poulain@linaro.org>
Thanks!
Applied to the hisilicon arm64 dt tree.
Best Regards,
Wei
> ---
> arch/arm64/boot/dts/hisilicon/hi3660.dtsi | 4 ++--
> arch/arm64/boot/dts/hisilicon/hikey960-pinctrl.dtsi | 6 +++---
> 2 files changed, 5 insertions(+), 5 deletions(-)
>
> diff --git a/arch/arm64/boot/dts/hisilicon/hi3660.dtsi b/arch/arm64/boot/dts/hisilicon/hi3660.dtsi
> index 253cc34..c39b7898 100644
> --- a/arch/arm64/boot/dts/hisilicon/hi3660.dtsi
> +++ b/arch/arm64/boot/dts/hisilicon/hi3660.dtsi
> @@ -974,7 +974,7 @@
> clocks = <&crg_ctrl HI3660_CLK_GATE_SPI2>;
> clock-names = "apb_pclk";
> pinctrl-names = "default";
> - pinctrl-0 = <&spi2_pmx_func>;
> + pinctrl-0 = <&spi2_pmx_func &spi2_cfg_func>;
> num-cs = <1>;
> cs-gpios = <&gpio27 2 0>;
> status = "disabled";
> @@ -989,7 +989,7 @@
> clocks = <&crg_ctrl HI3660_CLK_GATE_SPI3>;
> clock-names = "apb_pclk";
> pinctrl-names = "default";
> - pinctrl-0 = <&spi3_pmx_func>;
> + pinctrl-0 = <&spi3_pmx_func &spi3_cfg_func>;
> num-cs = <1>;
> cs-gpios = <&gpio18 5 0>;
> status = "disabled";
> diff --git a/arch/arm64/boot/dts/hisilicon/hikey960-pinctrl.dtsi b/arch/arm64/boot/dts/hisilicon/hikey960-pinctrl.dtsi
> index d11efc8..920a311 100644
> --- a/arch/arm64/boot/dts/hisilicon/hikey960-pinctrl.dtsi
> +++ b/arch/arm64/boot/dts/hisilicon/hikey960-pinctrl.dtsi
> @@ -717,7 +717,7 @@
> spi3_cfg_func: spi3_cfg_func {
> pinctrl-single,pins = <
> 0x008 0x0 /* SPI3_CLK */
> - 0x0 /* SPI3_DI */
> + 0x00c 0x0 /* SPI3_DI */
> 0x010 0x0 /* SPI3_DO */
> 0x014 0x0 /* SPI3_CS0_N */
> >;
> @@ -734,7 +734,7 @@
> PULL_UP
> >;
> pinctrl-single,drive-strength = <
> - DRIVE7_02MA DRIVE6_MASK
> + DRIVE7_06MA DRIVE6_MASK
> >;
> };
> };
> @@ -1031,7 +1031,7 @@
> PULL_UP
> >;
> pinctrl-single,drive-strength = <
> - DRIVE7_02MA DRIVE6_MASK
> + DRIVE7_06MA DRIVE6_MASK
> >;
> };
>
>
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ 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