* [PATCH] drm/rockchip: vop: fix irq disabled after vop driver probed
From: Tomasz Figa @ 2018-05-25 2:57 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <25470133.K8n9sLBzRS@diego>
Hi Heiko, Sandy,
On Fri, May 25, 2018 at 7:07 AM Heiko St?bner <heiko@sntech.de> wrote:
> From: Sandy Huang <hjc@rock-chips.com>
> The vop irq is shared between vop and iommu and irq probing in the
> iommu driver moved to the probe function recently. This can in some
> cases lead to a stall if the irq is triggered while the vop driver
> still has it disabled.
> But there is no real need to disable the irq, as the vop can simply
> also track its enabled state and ignore irqs in that case.
> So remove the enable/disable handling and add appropriate condition
> to the irq handler.
> Signed-off-by: Sandy Huang <hjc@rock-chips.com>
> [added an actual commit message]
> Signed-off-by: Heiko Stuebner <heiko@sntech.de>
> ---
> Hi Ezequiel,
> this patch came from a discussion I had with Rockchip people over the
> iommu changes and resulting issues back in april, but somehow was
> forgotten and not posted to the lists. Correcting that now.
> So removing the enable/disable voodoo on the shared interrupt is
> the preferred way.
> drivers/gpu/drm/rockchip/rockchip_drm_vop.c | 13 ++++++-------
> 1 file changed, 7 insertions(+), 7 deletions(-)
> diff --git a/drivers/gpu/drm/rockchip/rockchip_drm_vop.c
b/drivers/gpu/drm/rockchip/rockchip_drm_vop.c
> index 510cdf0..61493d4 100644
> --- a/drivers/gpu/drm/rockchip/rockchip_drm_vop.c
> +++ b/drivers/gpu/drm/rockchip/rockchip_drm_vop.c
> @@ -549,8 +549,6 @@ static int vop_enable(struct drm_crtc *crtc)
> spin_unlock(&vop->reg_lock);
> - enable_irq(vop->irq);
> -
While this one should be okay (+/- my comment for vop_isr()), because the
hardware is already powered on and clocked at this point...
> drm_crtc_vblank_on(crtc);
> return 0;
> @@ -596,8 +594,6 @@ static void vop_crtc_atomic_disable(struct drm_crtc
*crtc,
> vop_dsp_hold_valid_irq_disable(vop);
> - disable_irq(vop->irq);
> -
> vop->is_enabled = false;
...this one is more tricky. There might be an interrupt handler still
running at this point. disable_irq() waits for any running handler to
complete before disabling, so we might want to call synchronize_irq() after
setting is_enabled to false.
> /*
> @@ -1168,6 +1164,13 @@ static irqreturn_t vop_isr(int irq, void *data)
> int ret = IRQ_NONE;
> /*
> + * since the irq is shared with iommu, iommu irq is enabled
before vop
> + * enable, so before vop enable we do nothing.
> + */
> + if (!vop->is_enabled)
> + return IRQ_NONE;
This doesn't seem to be properly synchronized. We don't even call it under
a spinlock, so no barriers are issued. Perhaps we should make this atomic_t?
Best regards,
Tomasz
^ permalink raw reply
* [PATCH v2 13/40] vfio: Add support for Shared Virtual Addressing
From: Xu Zaibo @ 2018-05-25 2:39 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <205c1729-8026-3efe-c363-d37d7150d622@arm.com>
Hi,
On 2018/5/24 23:04, Jean-Philippe Brucker wrote:
> On 24/05/18 13:35, Xu Zaibo wrote:
>>> Right, sva_init() must be called once for any device that intends to use
>>> bind(). For the second process though, group->sva_enabled will be true
>>> so we won't call sva_init() again, only bind().
>> Well, while I create mediated devices based on one parent device to support multiple
>> processes(a new process will create a new 'vfio_group' for the corresponding mediated device,
>> and 'sva_enabled' cannot work any more), in fact, *sva_init and *sva_shutdown are basically
>> working on parent device, so, as a result, I just only need sva initiation and shutdown on the
>> parent device only once. So I change the two as following:
>>
>> @@ -551,8 +565,18 @@ int iommu_sva_device_init(struct device *dev, unsigned long features,
>> if (features & ~IOMMU_SVA_FEAT_IOPF)
>> return -EINVAL;
>>
>> + /* If already exists, do nothing */
>> + mutex_lock(&dev->iommu_param->lock);
>> + if (dev->iommu_param->sva_param) {
>> + mutex_unlock(&dev->iommu_param->lock);
>> + return 0;
>> + }
>> + mutex_unlock(&dev->iommu_param->lock);
>>
>> if (features & IOMMU_SVA_FEAT_IOPF) {
>> ret = iommu_register_device_fault_handler(dev, iommu_queue_iopf,
>>
>>
>> @@ -621,6 +646,14 @@ int iommu_sva_device_shutdown(struct device *dev)
>> if (!domain)
>> return -ENODEV;
>>
>> + /* If any other process is working on the device, shut down does nothing. */
>> + mutex_lock(&dev->iommu_param->lock);
>> + if (!list_empty(&dev->iommu_param->sva_param->mm_list)) {
>> + mutex_unlock(&dev->iommu_param->lock);
>> + return 0;
>> + }
>> + mutex_unlock(&dev->iommu_param->lock);
> I don't think iommu-sva.c is the best place for this, it's probably
> better to implement an intermediate layer (the mediating driver), that
> calls iommu_sva_device_init() and iommu_sva_device_shutdown() once. Then
> vfio-pci would still call these functions itself, but for mdev the
> mediating driver keeps a refcount of groups, and calls device_shutdown()
> only when freeing the last mdev.
>
> A device driver (non mdev in this example) expects to be able to free
> all its resources after sva_device_shutdown() returns. Imagine the
> mm_list isn't empty (mm_exit() is running late), and instead of waiting
> in unbind_dev_all() below, we return 0 immediately. Then the calling
> driver frees its resources, and the mm_exit callback along with private
> data passed to bind() disappear. If a mm_exit() is still running in
> parallel, then it will try to access freed data and corrupt memory. So
> in this function if mm_list isn't empty, the only thing we can do is wait.
>
I still don't understand why we should 'unbind_dev_all', is it possible
to do a 'unbind_dev_pasid'?
Then we can do other things instead of waiting that user may not like. :)
Thanks
Zaibo
>
>> +
>> __iommu_sva_unbind_dev_all(dev);
>>
>> mutex_lock(&dev->iommu_param->lock);
>>
>> I add the above two checkings in both *sva_init and *sva_shutdown, it is working now,
>> but i don't know if it will cause any new problems. What's more, i doubt if it is
>> reasonable to check this to avoid repeating operation in VFIO, maybe it is better to check
>> in IOMMU. :)
>
>
>
> .
>
^ permalink raw reply
* Nokia N900: refcount_t underflow, use after free
From: Suman Anna @ 2018-05-25 2:37 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180524110533.GA20599@amd>
On 05/24/2018 06:05 AM, Pavel Machek wrote:
> Hi!
>
>>>>
>>>> OK, see if the following fixes the issue for you, only build tested.
>>>
>>> Word-wrapped, so I applied by hand. And yes, the oops at boot is
>>> gone. Thanks!
>>
>> Sorry about that, have to check my mail settings. Anyway will post the
>> patch again, glad that it fixed your issue.
>
> Any news here? AFAICT the bug creeped into v4.17-rcX in the
> meantime...
>
The patch has been on linux-next for sometime now.
regards
Suman
> Pavel
>
>> regards
>> Suman
>>
>>>
>>> (Camera still does not work in -next... kills system. Oh well. Lets
>>> debug that some other day.)
>>>
>>>> 8< ---------------------
>>>> >From bac9a48fb646dc51f2030d676a0dbe3298c3b134 Mon Sep 17 00:00:00 2001
>>>> From: Suman Anna <s-anna@ti.com>
>>>> Date: Fri, 9 Mar 2018 16:39:59 -0600
>>>> Subject: [PATCH] media: omap3isp: fix unbalanced dma_iommu_mapping
>>>>
>>>> The OMAP3 ISP driver manages its MMU mappings through the IOMMU-aware
>>>> ARM DMA backend. The current code creates a dma_iommu_mapping and
>>>> attaches this to the ISP device, but never detaches the mapping in
>>>> either the probe failure paths or the driver remove path resulting
>>>> in an unbalanced mapping refcount and a memory leak. Fix this properly.
>>>>
>>>> Reported-by: Pavel Machek <pavel@ucw.cz>
>>>> Signed-off-by: Suman Anna <s-anna@ti.com>
>>>
>>> Tested-by: Pavel Machek <pavel@ucw.cz>
>>> Pavel
>>>
>
^ permalink raw reply
* [PATCH] arm64: dts: sprd: fix typo in 'remote-endpoint'
From: Chunyan Zhang @ 2018-05-25 2:36 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAL_JsqKrsTpgnLfxhcxeucpoh9NkyGwwZq82QUBgJZrdjGYQzg@mail.gmail.com>
Hi Arnd, Olof
Could you please take this patch through arm-soc git?
Thanks,
Chunyan
On 24 May 2018 at 04:30, Rob Herring <robh@kernel.org> wrote:
> On Tue, May 8, 2018 at 8:58 PM, Chunyan Zhang <zhang.lyra@gmail.com> wrote:
>> Hi Rob,
>>
>> On 8 May 2018 at 23:09, Rob Herring <robh@kernel.org> wrote:
>>> dtc now warns on incomplete OF graph endpoint connections:
>>>
>>> arch/arm64/boot/dts/sprd/sp9860g-1h10.dtb: Warning (graph_endpoint): /soc/stm at 10006000/port/endpoint: graph connection to node '/soc/funnel at 10001000/ports/port at 2/endpoint' is not bidirectional
>>>
>>> The cause is a typo in 'remote-endpoint'.
>>
>> Thanks for fixing this and,
>>
>> Acked-by: Chunyan Zhang <zhang.lyra@gmail.com>
>
> Is someone going to apply this? Still seeing warnings in linux-next.
>
> Rob
^ permalink raw reply
* [PATCH v3 8/8] drm/mediatek: add third ddp path
From: stu.hsieh at mediatek.com @ 2018-05-25 2:34 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1527215665-11937-1-git-send-email-stu.hsieh@mediatek.com>
From: Stu Hsieh <stu.hsieh@mediatek.com>
This patch create third crtc by third ddp path
Signed-off-by: Stu Hsieh <stu.hsieh@mediatek.com>
---
drivers/gpu/drm/mediatek/mtk_drm_drv.c | 5 +++++
1 file changed, 5 insertions(+)
diff --git a/drivers/gpu/drm/mediatek/mtk_drm_drv.c b/drivers/gpu/drm/mediatek/mtk_drm_drv.c
index b32c4cc8d051..3a866e1d6af4 100644
--- a/drivers/gpu/drm/mediatek/mtk_drm_drv.c
+++ b/drivers/gpu/drm/mediatek/mtk_drm_drv.c
@@ -267,6 +267,11 @@ static int mtk_drm_kms_init(struct drm_device *drm)
if (ret < 0)
goto err_component_unbind;
+ ret = mtk_drm_crtc_create(drm, private->data->third_path,
+ private->data->third_len);
+ if (ret < 0)
+ goto err_component_unbind;
+
/* Use OVL device for all DMA memory allocations */
np = private->comp_node[private->data->main_path[0]] ?:
private->comp_node[private->data->ext_path[0]];
--
2.12.5
^ permalink raw reply related
* [PATCH v3 7/8] drm/mediatek: Add support for mediatek SOC MT2712
From: stu.hsieh at mediatek.com @ 2018-05-25 2:34 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1527215665-11937-1-git-send-email-stu.hsieh@mediatek.com>
From: Stu Hsieh <stu.hsieh@mediatek.com>
This patch add support for the Mediatek MT2712 DISP subsystem.
There are two OVL engine and three disp output in MT2712.
Signed-off-by: Stu Hsieh <stu.hsieh@mediatek.com>
---
drivers/gpu/drm/mediatek/mtk_drm_ddp.c | 46 +++++++++++++++++++++++++++--
drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.c | 8 +++--
drivers/gpu/drm/mediatek/mtk_drm_drv.c | 42 ++++++++++++++++++++++++--
drivers/gpu/drm/mediatek/mtk_drm_drv.h | 7 +++--
4 files changed, 94 insertions(+), 9 deletions(-)
diff --git a/drivers/gpu/drm/mediatek/mtk_drm_ddp.c b/drivers/gpu/drm/mediatek/mtk_drm_ddp.c
index 0f568dd853d8..676726249ae0 100644
--- a/drivers/gpu/drm/mediatek/mtk_drm_ddp.c
+++ b/drivers/gpu/drm/mediatek/mtk_drm_ddp.c
@@ -61,6 +61,24 @@
#define MT8173_MUTEX_MOD_DISP_PWM1 24
#define MT8173_MUTEX_MOD_DISP_OD 25
+#define MT2712_MUTEX_MOD_DISP_OVL0 11
+#define MT2712_MUTEX_MOD_DISP_OVL1 12
+#define MT2712_MUTEX_MOD_DISP_RDMA0 13
+#define MT2712_MUTEX_MOD_DISP_RDMA1 14
+#define MT2712_MUTEX_MOD_DISP_RDMA2 15
+#define MT2712_MUTEX_MOD_DISP_WDMA0 16
+#define MT2712_MUTEX_MOD_DISP_WDMA1 17
+#define MT2712_MUTEX_MOD_DISP_COLOR0 18
+#define MT2712_MUTEX_MOD_DISP_COLOR1 19
+#define MT2712_MUTEX_MOD_DISP_AAL0 20
+#define MT2712_MUTEX_MOD_DISP_UFOE 22
+#define MT2712_MUTEX_MOD_DISP_PWM0 23
+#define MT2712_MUTEX_MOD_DISP_PWM1 24
+#define MT2712_MUTEX_MOD_DISP_PWM2 10
+#define MT2712_MUTEX_MOD_DISP_OD0 25
+#define MT2712_MUTEX_MOD2_DISP_AAL1 33
+#define MT2712_MUTEX_MOD2_DISP_OD1 34
+
#define MT2701_MUTEX_MOD_DISP_OVL 3
#define MT2701_MUTEX_MOD_DISP_WDMA 6
#define MT2701_MUTEX_MOD_DISP_COLOR 7
@@ -75,6 +93,7 @@
#define OVL0_MOUT_EN_COLOR0 0x1
#define OD_MOUT_EN_RDMA0 0x1
+#define OD1_MOUT_EN_RDMA1 BIT(16)
#define UFOE_MOUT_EN_DSI0 0x1
#define COLOR0_SEL_IN_OVL0 0x1
#define OVL1_MOUT_EN_COLOR1 0x1
@@ -109,12 +128,32 @@ static const unsigned int mt2701_mutex_mod[DDP_COMPONENT_ID_MAX] = {
[DDP_COMPONENT_WDMA0] = MT2701_MUTEX_MOD_DISP_WDMA,
};
+static const unsigned int mt2712_mutex_mod[DDP_COMPONENT_ID_MAX] = {
+ [DDP_COMPONENT_AAL0] = MT2712_MUTEX_MOD_DISP_AAL0,
+ [DDP_COMPONENT_AAL1] = MT2712_MUTEX_MOD2_DISP_AAL1,
+ [DDP_COMPONENT_COLOR0] = MT2712_MUTEX_MOD_DISP_COLOR0,
+ [DDP_COMPONENT_COLOR1] = MT2712_MUTEX_MOD_DISP_COLOR1,
+ [DDP_COMPONENT_OD0] = MT2712_MUTEX_MOD_DISP_OD0,
+ [DDP_COMPONENT_OD1] = MT2712_MUTEX_MOD2_DISP_OD1,
+ [DDP_COMPONENT_OVL0] = MT2712_MUTEX_MOD_DISP_OVL0,
+ [DDP_COMPONENT_OVL1] = MT2712_MUTEX_MOD_DISP_OVL1,
+ [DDP_COMPONENT_PWM0] = MT2712_MUTEX_MOD_DISP_PWM0,
+ [DDP_COMPONENT_PWM1] = MT2712_MUTEX_MOD_DISP_PWM1,
+ [DDP_COMPONENT_PWM2] = MT2712_MUTEX_MOD_DISP_PWM2,
+ [DDP_COMPONENT_RDMA0] = MT2712_MUTEX_MOD_DISP_RDMA0,
+ [DDP_COMPONENT_RDMA1] = MT2712_MUTEX_MOD_DISP_RDMA1,
+ [DDP_COMPONENT_RDMA2] = MT2712_MUTEX_MOD_DISP_RDMA2,
+ [DDP_COMPONENT_UFOE] = MT2712_MUTEX_MOD_DISP_UFOE,
+ [DDP_COMPONENT_WDMA0] = MT2712_MUTEX_MOD_DISP_WDMA0,
+ [DDP_COMPONENT_WDMA1] = MT2712_MUTEX_MOD_DISP_WDMA1,
+};
+
static const unsigned int mt8173_mutex_mod[DDP_COMPONENT_ID_MAX] = {
- [DDP_COMPONENT_AAL] = MT8173_MUTEX_MOD_DISP_AAL,
+ [DDP_COMPONENT_AAL0] = MT8173_MUTEX_MOD_DISP_AAL,
[DDP_COMPONENT_COLOR0] = MT8173_MUTEX_MOD_DISP_COLOR0,
[DDP_COMPONENT_COLOR1] = MT8173_MUTEX_MOD_DISP_COLOR1,
[DDP_COMPONENT_GAMMA] = MT8173_MUTEX_MOD_DISP_GAMMA,
- [DDP_COMPONENT_OD] = MT8173_MUTEX_MOD_DISP_OD,
+ [DDP_COMPONENT_OD0] = MT8173_MUTEX_MOD_DISP_OD,
[DDP_COMPONENT_OVL0] = MT8173_MUTEX_MOD_DISP_OVL0,
[DDP_COMPONENT_OVL1] = MT8173_MUTEX_MOD_DISP_OVL1,
[DDP_COMPONENT_PWM0] = MT8173_MUTEX_MOD_DISP_PWM0,
@@ -139,7 +178,7 @@ static unsigned int mtk_ddp_mout_en(enum mtk_ddp_comp_id cur,
} else if (cur == DDP_COMPONENT_OVL0 && next == DDP_COMPONENT_RDMA0) {
*addr = DISP_REG_CONFIG_DISP_OVL_MOUT_EN;
value = OVL_MOUT_EN_RDMA;
- } else if (cur == DDP_COMPONENT_OD && next == DDP_COMPONENT_RDMA0) {
+ } else if (cur == DDP_COMPONENT_OD0 && next == DDP_COMPONENT_RDMA0) {
*addr = DISP_REG_CONFIG_DISP_OD_MOUT_EN;
value = OD_MOUT_EN_RDMA0;
} else if (cur == DDP_COMPONENT_UFOE && next == DDP_COMPONENT_DSI0) {
@@ -429,6 +468,7 @@ static int mtk_ddp_remove(struct platform_device *pdev)
static const struct of_device_id ddp_driver_dt_match[] = {
{ .compatible = "mediatek,mt2701-disp-mutex", .data = mt2701_mutex_mod},
+ { .compatible = "mediatek,mt2712-disp-mutex", .data = mt2712_mutex_mod},
{ .compatible = "mediatek,mt8173-disp-mutex", .data = mt8173_mutex_mod},
{},
};
diff --git a/drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.c b/drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.c
index 4672317e3ad1..86e8c9e5df41 100644
--- a/drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.c
+++ b/drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.c
@@ -218,7 +218,8 @@ struct mtk_ddp_comp_match {
};
static const struct mtk_ddp_comp_match mtk_ddp_matches[DDP_COMPONENT_ID_MAX] = {
- [DDP_COMPONENT_AAL] = { MTK_DISP_AAL, 0, &ddp_aal },
+ [DDP_COMPONENT_AAL0] = { MTK_DISP_AAL, 0, &ddp_aal },
+ [DDP_COMPONENT_AAL1] = { MTK_DISP_AAL, 1, &ddp_aal },
[DDP_COMPONENT_BLS] = { MTK_DISP_BLS, 0, NULL },
[DDP_COMPONENT_COLOR0] = { MTK_DISP_COLOR, 0, NULL },
[DDP_COMPONENT_COLOR1] = { MTK_DISP_COLOR, 1, NULL },
@@ -226,10 +227,13 @@ static const struct mtk_ddp_comp_match mtk_ddp_matches[DDP_COMPONENT_ID_MAX] = {
[DDP_COMPONENT_DSI0] = { MTK_DSI, 0, NULL },
[DDP_COMPONENT_DSI1] = { MTK_DSI, 1, NULL },
[DDP_COMPONENT_GAMMA] = { MTK_DISP_GAMMA, 0, &ddp_gamma },
- [DDP_COMPONENT_OD] = { MTK_DISP_OD, 0, &ddp_od },
+ [DDP_COMPONENT_OD0] = { MTK_DISP_OD, 0, &ddp_od },
+ [DDP_COMPONENT_OD1] = { MTK_DISP_OD, 1, &ddp_od },
[DDP_COMPONENT_OVL0] = { MTK_DISP_OVL, 0, NULL },
[DDP_COMPONENT_OVL1] = { MTK_DISP_OVL, 1, NULL },
[DDP_COMPONENT_PWM0] = { MTK_DISP_PWM, 0, NULL },
+ [DDP_COMPONENT_PWM1] = { MTK_DISP_PWM, 1, NULL },
+ [DDP_COMPONENT_PWM2] = { MTK_DISP_PWM, 2, NULL },
[DDP_COMPONENT_RDMA0] = { MTK_DISP_RDMA, 0, NULL },
[DDP_COMPONENT_RDMA1] = { MTK_DISP_RDMA, 1, NULL },
[DDP_COMPONENT_RDMA2] = { MTK_DISP_RDMA, 2, NULL },
diff --git a/drivers/gpu/drm/mediatek/mtk_drm_drv.c b/drivers/gpu/drm/mediatek/mtk_drm_drv.c
index a2ca90fc403c..b32c4cc8d051 100644
--- a/drivers/gpu/drm/mediatek/mtk_drm_drv.c
+++ b/drivers/gpu/drm/mediatek/mtk_drm_drv.c
@@ -146,11 +146,37 @@ static const enum mtk_ddp_comp_id mt2701_mtk_ddp_ext[] = {
DDP_COMPONENT_DPI0,
};
+static const enum mtk_ddp_comp_id mt2712_mtk_ddp_main[] = {
+ DDP_COMPONENT_OVL0,
+ DDP_COMPONENT_COLOR0,
+ DDP_COMPONENT_AAL0,
+ DDP_COMPONENT_OD0,
+ DDP_COMPONENT_RDMA0,
+ DDP_COMPONENT_DPI0,
+ DDP_COMPONENT_PWM0,
+};
+
+static const enum mtk_ddp_comp_id mt2712_mtk_ddp_ext[] = {
+ DDP_COMPONENT_OVL1,
+ DDP_COMPONENT_COLOR1,
+ DDP_COMPONENT_AAL1,
+ DDP_COMPONENT_OD1,
+ DDP_COMPONENT_RDMA1,
+ DDP_COMPONENT_DPI1,
+ DDP_COMPONENT_PWM1,
+};
+
+static const enum mtk_ddp_comp_id mt2712_mtk_ddp_third[] = {
+ DDP_COMPONENT_RDMA2,
+ DDP_COMPONENT_DSI2,
+ DDP_COMPONENT_PWM2,
+};
+
static const enum mtk_ddp_comp_id mt8173_mtk_ddp_main[] = {
DDP_COMPONENT_OVL0,
DDP_COMPONENT_COLOR0,
- DDP_COMPONENT_AAL,
- DDP_COMPONENT_OD,
+ DDP_COMPONENT_AAL0,
+ DDP_COMPONENT_OD0,
DDP_COMPONENT_RDMA0,
DDP_COMPONENT_UFOE,
DDP_COMPONENT_DSI0,
@@ -173,6 +199,15 @@ static const struct mtk_mmsys_driver_data mt2701_mmsys_driver_data = {
.shadow_register = true,
};
+static const struct mtk_mmsys_driver_data mt2712_mmsys_driver_data = {
+ .main_path = mt2712_mtk_ddp_main,
+ .main_len = ARRAY_SIZE(mt2712_mtk_ddp_main),
+ .ext_path = mt2712_mtk_ddp_ext,
+ .ext_len = ARRAY_SIZE(mt2712_mtk_ddp_ext),
+ .third_path = mt2712_mtk_ddp_third,
+ .third_len = ARRAY_SIZE(mt2712_mtk_ddp_third),
+};
+
static const struct mtk_mmsys_driver_data mt8173_mmsys_driver_data = {
.main_path = mt8173_mtk_ddp_main,
.main_len = ARRAY_SIZE(mt8173_mtk_ddp_main),
@@ -374,6 +409,7 @@ static const struct of_device_id mtk_ddp_comp_dt_ids[] = {
{ .compatible = "mediatek,mt8173-dsi", .data = (void *)MTK_DSI },
{ .compatible = "mediatek,mt8173-dpi", .data = (void *)MTK_DPI },
{ .compatible = "mediatek,mt2701-disp-mutex", .data = (void *)MTK_DISP_MUTEX },
+ { .compatible = "mediatek,mt2712-disp-mutex", .data = (void *)MTK_DISP_MUTEX },
{ .compatible = "mediatek,mt8173-disp-mutex", .data = (void *)MTK_DISP_MUTEX },
{ .compatible = "mediatek,mt2701-disp-pwm", .data = (void *)MTK_DISP_BLS },
{ .compatible = "mediatek,mt8173-disp-pwm", .data = (void *)MTK_DISP_PWM },
@@ -552,6 +588,8 @@ static SIMPLE_DEV_PM_OPS(mtk_drm_pm_ops, mtk_drm_sys_suspend,
static const struct of_device_id mtk_drm_of_ids[] = {
{ .compatible = "mediatek,mt2701-mmsys",
.data = &mt2701_mmsys_driver_data},
+ { .compatible = "mediatek,mt2712-mmsys",
+ .data = &mt2712_mmsys_driver_data},
{ .compatible = "mediatek,mt8173-mmsys",
.data = &mt8173_mmsys_driver_data},
{ }
diff --git a/drivers/gpu/drm/mediatek/mtk_drm_drv.h b/drivers/gpu/drm/mediatek/mtk_drm_drv.h
index c3378c452c0a..e821342bc2d3 100644
--- a/drivers/gpu/drm/mediatek/mtk_drm_drv.h
+++ b/drivers/gpu/drm/mediatek/mtk_drm_drv.h
@@ -17,8 +17,8 @@
#include <linux/io.h>
#include "mtk_drm_ddp_comp.h"
-#define MAX_CRTC 2
-#define MAX_CONNECTOR 2
+#define MAX_CRTC 3
+#define MAX_CONNECTOR 3
struct device;
struct device_node;
@@ -33,6 +33,9 @@ struct mtk_mmsys_driver_data {
unsigned int main_len;
const enum mtk_ddp_comp_id *ext_path;
unsigned int ext_len;
+ enum mtk_ddp_comp_id *third_path;
+ unsigned int third_len;
+
bool shadow_register;
};
--
2.12.5
^ permalink raw reply related
* [PATCH v3 6/8] drm/mediatek: add ddp component PWM2
From: stu.hsieh at mediatek.com @ 2018-05-25 2:34 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1527215665-11937-1-git-send-email-stu.hsieh@mediatek.com>
From: Stu Hsieh <stu.hsieh@mediatek.com>
This patch add component PWM2
Signed-off-by: Stu Hsieh <stu.hsieh@mediatek.com>
---
drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.h | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.h b/drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.h
index 9b19fc4423f1..e00c2e798abd 100644
--- a/drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.h
+++ b/drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.h
@@ -56,6 +56,7 @@ enum mtk_ddp_comp_id {
DDP_COMPONENT_OVL1,
DDP_COMPONENT_PWM0,
DDP_COMPONENT_PWM1,
+ DDP_COMPONENT_PWM2,
DDP_COMPONENT_RDMA0,
DDP_COMPONENT_RDMA1,
DDP_COMPONENT_RDMA2,
--
2.12.5
^ permalink raw reply related
* [PATCH v3 5/8] drm/mediatek: add ddp component OD1
From: stu.hsieh at mediatek.com @ 2018-05-25 2:34 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1527215665-11937-1-git-send-email-stu.hsieh@mediatek.com>
From: Stu Hsieh <stu.hsieh@mediatek.com>
This patch add the component OD1 and
rename the OD to OD1
Signed-off-by: Stu Hsieh <stu.hsieh@mediatek.com>
---
drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.h | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.h b/drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.h
index eee3c0cc2632..9b19fc4423f1 100644
--- a/drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.h
+++ b/drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.h
@@ -50,7 +50,8 @@ enum mtk_ddp_comp_id {
DDP_COMPONENT_DSI0,
DDP_COMPONENT_DSI1,
DDP_COMPONENT_GAMMA,
- DDP_COMPONENT_OD,
+ DDP_COMPONENT_OD0,
+ DDP_COMPONENT_OD1,
DDP_COMPONENT_OVL0,
DDP_COMPONENT_OVL1,
DDP_COMPONENT_PWM0,
--
2.12.5
^ permalink raw reply related
* [PATCH v3 4/8] drm/mediatek: add ddp component AAL1
From: stu.hsieh at mediatek.com @ 2018-05-25 2:34 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1527215665-11937-1-git-send-email-stu.hsieh@mediatek.com>
From: Stu Hsieh <stu.hsieh@mediatek.com>
This patch add component AAL1 and
rename AAL to AAL0
Signed-off-by: Stu Hsieh <stu.hsieh@mediatek.com>
---
drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.h | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.h b/drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.h
index 0828cf8bf85c..eee3c0cc2632 100644
--- a/drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.h
+++ b/drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.h
@@ -41,7 +41,8 @@ enum mtk_ddp_comp_type {
};
enum mtk_ddp_comp_id {
- DDP_COMPONENT_AAL,
+ DDP_COMPONENT_AAL0,
+ DDP_COMPONENT_AAL1,
DDP_COMPONENT_BLS,
DDP_COMPONENT_COLOR0,
DDP_COMPONENT_COLOR1,
--
2.12.5
^ permalink raw reply related
* [PATCH v3 3/8] drm/mediatek: add connection from OD1 to RDMA1
From: stu.hsieh at mediatek.com @ 2018-05-25 2:34 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1527215665-11937-1-git-send-email-stu.hsieh@mediatek.com>
From: Stu Hsieh <stu.hsieh@mediatek.com>
This patch add the connection from OD1 to RDMA1 for ext path.
Signed-off-by: Stu Hsieh <stu.hsieh@mediatek.com>
---
drivers/gpu/drm/mediatek/mtk_drm_ddp.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/drivers/gpu/drm/mediatek/mtk_drm_ddp.c b/drivers/gpu/drm/mediatek/mtk_drm_ddp.c
index 47ffa240bd25..0f568dd853d8 100644
--- a/drivers/gpu/drm/mediatek/mtk_drm_ddp.c
+++ b/drivers/gpu/drm/mediatek/mtk_drm_ddp.c
@@ -151,6 +151,9 @@ static unsigned int mtk_ddp_mout_en(enum mtk_ddp_comp_id cur,
} else if (cur == DDP_COMPONENT_GAMMA && next == DDP_COMPONENT_RDMA1) {
*addr = DISP_REG_CONFIG_DISP_GAMMA_MOUT_EN;
value = GAMMA_MOUT_EN_RDMA1;
+ } else if (cur == DDP_COMPONENT_OD1 && next == DDP_COMPONENT_RDMA1) {
+ *addr = DISP_REG_CONFIG_DISP_OD_MOUT_EN;
+ value = OD1_MOUT_EN_RDMA1;
} else if (cur == DDP_COMPONENT_RDMA1 && next == DDP_COMPONENT_DPI0) {
*addr = DISP_REG_CONFIG_DISP_RDMA1_MOUT_EN;
value = RDMA1_MOUT_DPI0;
--
2.12.5
^ permalink raw reply related
* [PATCH v3 2/8] drm/mediatek: support maximum 64 mutex mod
From: stu.hsieh at mediatek.com @ 2018-05-25 2:34 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1527215665-11937-1-git-send-email-stu.hsieh@mediatek.com>
From: Stu Hsieh <stu.hsieh@mediatek.com>
This patch support that if modules more than 32,
add index more than 31 when using DISP_REG_MUTEX_MOD2 bit
Signed-off-by: Stu Hsieh <stu.hsieh@mediatek.com>
---
drivers/gpu/drm/mediatek/mtk_drm_ddp.c | 75 +++++++++++++++++++++-------------
1 file changed, 47 insertions(+), 28 deletions(-)
diff --git a/drivers/gpu/drm/mediatek/mtk_drm_ddp.c b/drivers/gpu/drm/mediatek/mtk_drm_ddp.c
index 8130f3dab661..47ffa240bd25 100644
--- a/drivers/gpu/drm/mediatek/mtk_drm_ddp.c
+++ b/drivers/gpu/drm/mediatek/mtk_drm_ddp.c
@@ -41,31 +41,32 @@
#define DISP_REG_MUTEX_RST(n) (0x28 + 0x20 * (n))
#define DISP_REG_MUTEX_MOD(n) (0x2c + 0x20 * (n))
#define DISP_REG_MUTEX_SOF(n) (0x30 + 0x20 * (n))
+#define DISP_REG_MUTEX_MOD2(n) (0x34 + 0x20 * (n))
#define INT_MUTEX BIT(1)
-#define MT8173_MUTEX_MOD_DISP_OVL0 BIT(11)
-#define MT8173_MUTEX_MOD_DISP_OVL1 BIT(12)
-#define MT8173_MUTEX_MOD_DISP_RDMA0 BIT(13)
-#define MT8173_MUTEX_MOD_DISP_RDMA1 BIT(14)
-#define MT8173_MUTEX_MOD_DISP_RDMA2 BIT(15)
-#define MT8173_MUTEX_MOD_DISP_WDMA0 BIT(16)
-#define MT8173_MUTEX_MOD_DISP_WDMA1 BIT(17)
-#define MT8173_MUTEX_MOD_DISP_COLOR0 BIT(18)
-#define MT8173_MUTEX_MOD_DISP_COLOR1 BIT(19)
-#define MT8173_MUTEX_MOD_DISP_AAL BIT(20)
-#define MT8173_MUTEX_MOD_DISP_GAMMA BIT(21)
-#define MT8173_MUTEX_MOD_DISP_UFOE BIT(22)
-#define MT8173_MUTEX_MOD_DISP_PWM0 BIT(23)
-#define MT8173_MUTEX_MOD_DISP_PWM1 BIT(24)
-#define MT8173_MUTEX_MOD_DISP_OD BIT(25)
-
-#define MT2701_MUTEX_MOD_DISP_OVL BIT(3)
-#define MT2701_MUTEX_MOD_DISP_WDMA BIT(6)
-#define MT2701_MUTEX_MOD_DISP_COLOR BIT(7)
-#define MT2701_MUTEX_MOD_DISP_BLS BIT(9)
-#define MT2701_MUTEX_MOD_DISP_RDMA0 BIT(10)
-#define MT2701_MUTEX_MOD_DISP_RDMA1 BIT(12)
+#define MT8173_MUTEX_MOD_DISP_OVL0 11
+#define MT8173_MUTEX_MOD_DISP_OVL1 12
+#define MT8173_MUTEX_MOD_DISP_RDMA0 13
+#define MT8173_MUTEX_MOD_DISP_RDMA1 14
+#define MT8173_MUTEX_MOD_DISP_RDMA2 15
+#define MT8173_MUTEX_MOD_DISP_WDMA0 16
+#define MT8173_MUTEX_MOD_DISP_WDMA1 17
+#define MT8173_MUTEX_MOD_DISP_COLOR0 18
+#define MT8173_MUTEX_MOD_DISP_COLOR1 19
+#define MT8173_MUTEX_MOD_DISP_AAL 20
+#define MT8173_MUTEX_MOD_DISP_GAMMA 21
+#define MT8173_MUTEX_MOD_DISP_UFOE 22
+#define MT8173_MUTEX_MOD_DISP_PWM0 23
+#define MT8173_MUTEX_MOD_DISP_PWM1 24
+#define MT8173_MUTEX_MOD_DISP_OD 25
+
+#define MT2701_MUTEX_MOD_DISP_OVL 3
+#define MT2701_MUTEX_MOD_DISP_WDMA 6
+#define MT2701_MUTEX_MOD_DISP_COLOR 7
+#define MT2701_MUTEX_MOD_DISP_BLS 9
+#define MT2701_MUTEX_MOD_DISP_RDMA0 10
+#define MT2701_MUTEX_MOD_DISP_RDMA1 12
#define MUTEX_SOF_SINGLE_MODE 0
#define MUTEX_SOF_DSI0 1
@@ -278,6 +279,7 @@ void mtk_disp_mutex_add_comp(struct mtk_disp_mutex *mutex,
struct mtk_ddp *ddp = container_of(mutex, struct mtk_ddp,
mutex[mutex->id]);
unsigned int reg;
+ unsigned int offset;
WARN_ON(&ddp->mutex[mutex->id] != mutex);
@@ -292,9 +294,17 @@ void mtk_disp_mutex_add_comp(struct mtk_disp_mutex *mutex,
reg = MUTEX_SOF_DPI0;
break;
default:
- reg = readl_relaxed(ddp->regs + DISP_REG_MUTEX_MOD(mutex->id));
- reg |= ddp->mutex_mod[id];
- writel_relaxed(reg, ddp->regs + DISP_REG_MUTEX_MOD(mutex->id));
+ if (ddp->mutex_mod[id] < 32) {
+ offset = DISP_REG_MUTEX_MOD(mutex->id);
+ reg = readl_relaxed(ddp->regs + offset);
+ reg |= 1 << ddp->mutex_mod[id];
+ writel_relaxed(reg, ddp->regs + offset);
+ } else {
+ offset = DISP_REG_MUTEX_MOD2(mutex->id);
+ reg = readl_relaxed(ddp->regs + offset);
+ reg |= 1 << (ddp->mutex_mod[id] - 32);
+ writel_relaxed(reg, ddp->regs + offset);
+ }
return;
}
@@ -307,6 +317,7 @@ void mtk_disp_mutex_remove_comp(struct mtk_disp_mutex *mutex,
struct mtk_ddp *ddp = container_of(mutex, struct mtk_ddp,
mutex[mutex->id]);
unsigned int reg;
+ unsigned int offset;
WARN_ON(&ddp->mutex[mutex->id] != mutex);
@@ -318,9 +329,17 @@ void mtk_disp_mutex_remove_comp(struct mtk_disp_mutex *mutex,
ddp->regs + DISP_REG_MUTEX_SOF(mutex->id));
break;
default:
- reg = readl_relaxed(ddp->regs + DISP_REG_MUTEX_MOD(mutex->id));
- reg &= ~(ddp->mutex_mod[id]);
- writel_relaxed(reg, ddp->regs + DISP_REG_MUTEX_MOD(mutex->id));
+ if (ddp->mutex_mod[id] < 32) {
+ offset = DISP_REG_MUTEX_MOD(mutex->id);
+ reg = readl_relaxed(ddp->regs + offset);
+ reg &= ~(1 << ddp->mutex_mod[id]);
+ writel_relaxed(reg, ddp->regs + offset);
+ } else {
+ offset = DISP_REG_MUTEX_MOD2(mutex->id);
+ reg = readl_relaxed(ddp->regs + offset);
+ reg &= ~(1 << (ddp->mutex_mod[id] - 32));
+ writel_relaxed(reg, ddp->regs + offset);
+ }
break;
}
}
--
2.12.5
^ permalink raw reply related
* [PATCH v3 1/8] drm/mediatek: update dt-bindings for mt2712
From: stu.hsieh at mediatek.com @ 2018-05-25 2:34 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1527215665-11937-1-git-send-email-stu.hsieh@mediatek.com>
From: Stu Hsieh <stu.hsieh@mediatek.com>
Update device tree binding documentation for the display subsystem for
Mediatek MT2712 SoCs.
Signed-off-by: Stu Hsieh <stu.hsieh@mediatek.com>
---
Documentation/devicetree/bindings/display/mediatek/mediatek,disp.txt | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/Documentation/devicetree/bindings/display/mediatek/mediatek,disp.txt b/Documentation/devicetree/bindings/display/mediatek/mediatek,disp.txt
index 383183a89164..8469de510001 100644
--- a/Documentation/devicetree/bindings/display/mediatek/mediatek,disp.txt
+++ b/Documentation/devicetree/bindings/display/mediatek/mediatek,disp.txt
@@ -40,7 +40,7 @@ Required properties (all function blocks):
"mediatek,<chip>-dpi" - DPI controller, see mediatek,dpi.txt
"mediatek,<chip>-disp-mutex" - display mutex
"mediatek,<chip>-disp-od" - overdrive
- the supported chips are mt2701 and mt8173.
+ the supported chips are mt2701, mt2712 and mt8173.
- reg: Physical base address and length of the function block register space
- interrupts: The interrupt signal from the function block (required, except for
merge and split function blocks).
--
2.12.5
^ permalink raw reply related
* [PATCH v3 0/8] Add support for mediatek SOC MT2712
From: stu.hsieh at mediatek.com @ 2018-05-25 2:34 UTC (permalink / raw)
To: linux-arm-kernel
From: Stu Hsieh <stu.hsieh@mediatek.com>
This patch add support for the Mediatek MT2712 DISP subsystem.
MT2712 is base on MT8173, there are some difference as following:
MT2712 support three disp output(two ovl and one rdma)
Change in v3:
- Added patch for ddp component AAL1
- Added patch for ddp component OD1
- Added patch for ddp component PWM2
- Added patch to create third ddp path
- Rebase patch "support maximum 64 mutex mod" before
"Add support for mediatek SOC MT2712"
- Rebase patch "add connection from OD1 to RDMA1" before
"Add support for mediatek SOC MT2712"
- Remove two definition about RDMA0 and RDMA2
- Change the definition about mutex module from
bitwise to index
Changes in v2:
- update dt-bindings for mt2712
- Added patch to connection from OD1 to RDMA1
- Added patch to support maximum 64 mutex mod
- rewrite mutex mod condition for reducing one byte
- Change the component name AAL/OD to AAL0/OD0 for naming consistency
- Move the compatible infomation about dpi to other patch which modify
the dpi driver for mt2712
Stu Hsieh (8):
drm/mediatek: update dt-bindings for mt2712
drm/mediatek: support maximum 64 mutex mod
drm/mediatek: add connection from OD1 to RDMA1
drm/mediatek: add ddp component AAL1
drm/mediatek: add ddp component OD1
drm/mediatek: add ddp component PWM2
drm/mediatek: Add support for mediatek SOC MT2712
drm/mediatek: add third ddp path
.../bindings/display/mediatek/mediatek,disp.txt | 2 +-
drivers/gpu/drm/mediatek/mtk_drm_ddp.c | 124 +++++++++++++++------
drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.c | 8 +-
drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.h | 7 +-
drivers/gpu/drm/mediatek/mtk_drm_drv.c | 47 +++++++-
drivers/gpu/drm/mediatek/mtk_drm_drv.h | 7 +-
6 files changed, 155 insertions(+), 40 deletions(-)
--
2.12.5
^ permalink raw reply
* [PATCH 5/5] MAINTAINERS: imx: add NXP linux team upstream maillist as reviewer
From: A.s. Dong @ 2018-05-25 2:14 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1524855977-15719-6-git-send-email-aisheng.dong@nxp.com>
Hi Shawn,
> -----Original Message-----
> From: A.s. Dong
> Sent: Saturday, April 28, 2018 3:06 AM
> To: linux-arm-kernel at lists.infradead.org
> Cc: dongas86 at gmail.com; kernel at pengutronix.de; shawnguo at kernel.org;
> Fabio Estevam <fabio.estevam@nxp.com>; robh+dt at kernel.org;
> catalin.marinas at arm.com; will.deacon at arm.com; dl-linux-imx <linux-
> imx at nxp.com>; A.s. Dong <aisheng.dong@nxp.com>
> Subject: [PATCH 5/5] MAINTAINERS: imx: add NXP linux team upstream
> maillist as reviewer
>
> Add NXP linux team upstream maillist as reviewer
>
> Cc: Shawn Guo <shawnguo@kernel.org>
> Cc: Sascha Hauer <kernel@pengutronix.de>
> Cc: Fabio Estevam <fabio.estevam@nxp.com>
> Signed-off-by: Dong Aisheng <aisheng.dong@nxp.com>
Would you pick this one first?
Regards
Dong Aisheng
> ---
> MAINTAINERS | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/MAINTAINERS b/MAINTAINERS
> index 0a1410d..1defbc8 100644
> --- a/MAINTAINERS
> +++ b/MAINTAINERS
> @@ -1403,6 +1403,7 @@ ARM/FREESCALE IMX / MXC ARM ARCHITECTURE
> M: Shawn Guo <shawnguo@kernel.org>
> M: Sascha Hauer <kernel@pengutronix.de>
> R: Fabio Estevam <fabio.estevam@nxp.com>
> +R: NXP Linux Team <linux-imx@nxp.com>
> L: linux-arm-kernel at lists.infradead.org (moderated for non-
> subscribers)
> S: Maintained
> T: git git://git.kernel.org/pub/scm/linux/kernel/git/shawnguo/linux.git
> --
> 2.7.4
^ permalink raw reply
* [RFC][PATCH] ARM: shmobile: Rework the PMIC IRQ line quirk
From: Marek Vasut @ 2018-05-25 0:30 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAMuHMdXep2sdVK71i1FBkJTd+3aYj0LzCKsqp8vBKrewkaX1FA@mail.gmail.com>
On 02/26/2018 11:39 AM, Geert Uytterhoeven wrote:
> Hi Marek,
Hi,
> On Mon, Feb 26, 2018 at 11:17 AM, Marek Vasut <marek.vasut@gmail.com> wrote:
>> Rather than hard-coding the quirk topology, which stopped scaling,
>> parse the information from DT. The code looks for all compatible
>> PMICs -- da9036 and da9210 -- and checks if their IRQ line is tied
>> to the same pin. If so, the code sends a matching sequence to the
>> PMIC to deassert the IRQ.
>>
>> Signed-off-by: Marek Vasut <marek.vasut+renesas@gmail.com>
>
> Thanks for your patch!
>
> At first sight, the probing part looks good to me. I'll have a closer look,
> and will give it a try later.
>
> A few early comment below.
>
>> --- a/arch/arm/mach-shmobile/regulator-quirk-rcar-gen2.c
>> +++ b/arch/arm/mach-shmobile/regulator-quirk-rcar-gen2.c
>
>> @@ -88,17 +103,21 @@ static int regulator_quirk_notify(struct notifier_block *nb,
>> client = to_i2c_client(dev);
>> dev_dbg(dev, "Detected %s\n", client->name);
>>
>> - if ((client->addr == 0x58 && !strcmp(client->name, "da9063")) ||
>> - (client->addr == 0x68 && !strcmp(client->name, "da9210")) ||
>> - (client->addr == 0x70 && !strcmp(client->name, "da9210"))) {
>> - int ret, len;
>> + list_for_each_entry(pos, &quirk_list, list) {
>> + if (pos->i2c_msg.addr != client->addr)
>> + continue;
>>
>> - /* There are two DA9210 on Stout, one on the other boards. */
>> - len = of_machine_is_compatible("renesas,stout") ? 3 : 2;
>> + if (!of_device_is_compatible(dev->of_node, pos->id->compatible))
>> + continue;
>>
>> - dev_info(&client->dev, "clearing da9063/da9210 interrupts\n");
>> - ret = i2c_transfer(client->adapter, da9xxx_msgs, len);
>> - if (ret != ARRAY_SIZE(da9xxx_msgs))
>> + if (!pos->shared)
>> + continue;
>> +
>> + dev_info(&client->dev, "clearing %s at 0x%02x interrupts\n",
>> + pos->id->compatible, pos->i2c_msg.addr);
>> +
>> + ret = i2c_transfer(client->adapter, &pos->i2c_msg, 1);
>> + if (ret != 1)
>> dev_err(&client->dev, "i2c error %d\n", ret);
>> }
>
> The loop above sents a clear message to a single device only, right?
> That won't work, as that will clear the interrupt for that single device only.
> All other devices may still have their interrupts asserted.
> Next step in probing will be binding the da9210 or da9063 driver, which will
> enable the shared irq, and boom!
>
> Upon detecting the first affected device, you really have to send clear
> messages to all devices in the list for which shared == true.
This is even worse, the single-device part can be easily fixed. But what
if the devices are on different i2c bus ? Do we care about that case or
do we assume they are on the same bus (they are in the configurations we
know of).
>> @@ -122,7 +146,14 @@ static struct notifier_block regulator_quirk_nb = {
>>
>> static int __init rcar_gen2_regulator_quirk(void)
>> {
>> - u32 mon;
>> + struct device_node *np;
>> + const struct of_device_id *id;
>> + struct regulator_quirk *quirk;
>> + struct regulator_quirk *pos;
>> + struct of_phandle_args *argsa, *argsb;
>> + u32 mon, addr, i;
>> + bool match;
>> + int ret;
>>
>> if (!of_machine_is_compatible("renesas,koelsch") &&
>> !of_machine_is_compatible("renesas,lager") &&
>
>> @@ -130,6 +161,51 @@ static int __init rcar_gen2_regulator_quirk(void)
>> !of_machine_is_compatible("renesas,gose"))
>> return -ENODEV;
>
> We might drop the checks above, to handle other platforms based on the
> Renesas reference designs.
Are you sure that's a good idea ?
>>
>> + for_each_matching_node_and_match(np, rcar_gen2_quirk_match, &id) {
>> + if(!np || !of_device_is_available(np))
>> + break;
>> +
>> + quirk = kzalloc(sizeof(*quirk), GFP_KERNEL);
>> +
>> + argsa = &quirk->irq_args;
>> + memcpy(&quirk->i2c_msg, id->data, sizeof(quirk->i2c_msg));
>> +
>> + ret = of_property_read_u32(np, "reg", &addr);
>> + if (ret)
>> + return ret;
>> +
>> + quirk->id = id;
>> + quirk->i2c_msg.addr = addr;
>> + quirk->shared = false;
>> +
>> + ret = of_irq_parse_one(np, 0, &quirk->irq_args);
>> + if (ret)
>> + return ret;
>> +
>> + list_for_each_entry(pos, &quirk_list, list) {
>> + argsa = &quirk->irq_args;
>> + argsb = &pos->irq_args;
>> +
>> + if (argsa->args_count != argsb->args_count)
>> + continue;
>> +
>> + match = true;
>> + for (i = 0; i < argsa->args_count; i++) {
>> + if (argsa->args[i] != argsb->args[i]) {
>> + match = false;
>> + break;
>> + }
>> + }
>> +
>> + if (match) {
>
> The loop and check above can be replaced by
>
> if (!memcmp(argsa->args, argsb->args, argsa->args_count *
> sizeof(argsa->args[0]))
Fixed
--
Best regards,
Marek Vasut
^ permalink raw reply
* [PATCH 6/6] coresight: allow to build as modules
From: Kim Phillips @ 2018-05-24 23:49 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180522213906.GC25658@xps15>
On Tue, 22 May 2018 15:39:06 -0600
Mathieu Poirier <mathieu.poirier@linaro.org> wrote:
> On Thu, May 17, 2018 at 08:20:24PM -0500, Kim Phillips wrote:
> > Allow to build coresight as modules. This greatly enhances developer
> > efficiency by allowing the development to take place exclusively on the
> > target, and without needing to reboot in between changes.
> >
> > - Kconfig bools become tristates, to allow =m
> >
> > - use -objs to denote merge object directives in Makefile, adds a
> > coresight-core nomenclature for the base module.
> >
> > - Export core functions so as to be able to be used by
> > non-core modules.
> >
> > - add a coresight_exit() that unregisters the coresight bus, add
> > remove fns for most others.
> >
> > - fix up modules with ID tables for autoloading on boot
> >
> > Cc: Mathieu Poirier <mathieu.poirier@linaro.org>
> > Cc: Alexander Shishkin <alexander.shishkin@linux.intel.com>
> > Cc: Randy Dunlap <rdunlap@infradead.org>
> > Signed-off-by: Kim Phillips <kim.phillips@arm.com>
> > ---
> > drivers/hwtracing/coresight/Kconfig | 48 +++++++++++++++----
> > drivers/hwtracing/coresight/Makefile | 28 +++++++----
> > .../hwtracing/coresight/coresight-cpu-debug.c | 2 +
> > .../coresight/coresight-dynamic-replicator.c | 26 ++++++++--
> > drivers/hwtracing/coresight/coresight-etb10.c | 27 +++++++++--
> > .../hwtracing/coresight/coresight-etm-perf.c | 9 +++-
> > .../coresight/coresight-etm3x-sysfs.c | 1 +
> > drivers/hwtracing/coresight/coresight-etm3x.c | 32 +++++++++++--
> > .../coresight/coresight-etm4x-sysfs.c | 1 +
> > drivers/hwtracing/coresight/coresight-etm4x.c | 33 +++++++++++--
> > .../hwtracing/coresight/coresight-funnel.c | 26 ++++++++--
> > drivers/hwtracing/coresight/coresight-priv.h | 1 -
> > .../coresight/coresight-replicator.c | 28 +++++++++--
> > drivers/hwtracing/coresight/coresight-stm.c | 23 ++++++++-
> > drivers/hwtracing/coresight/coresight-tmc.c | 18 ++++++-
> > drivers/hwtracing/coresight/coresight-tpiu.c | 26 ++++++++--
> > drivers/hwtracing/coresight/coresight.c | 14 ++++++
> > 17 files changed, 299 insertions(+), 44 deletions(-)
>
> For the next revision please split the work based on files.
If I read that literally, one file-by-one would break build
bisectability. Do you mean split by source files depending on the
logical modules they belong to, e.g., etm3x, etm4x, etb10, etc.? If
so, I think it would look like the coresight-core would be first,
followed by the rest, but I also think there are cross-dependencies.
Hmm, OK, I'll have a look, but there's also one more thing: I think
the Makefile obj '-core' nomenclature was to change the name of the
module to not be the same as the core source file, so what do you think
about renaming the core source file instead of the module name? e.g.:
Instead of this:
obj-$(CONFIG_CORESIGHT) += coresight-core.o
coresight-core-objs := coresight.o \
of_coresight.o
we have this:
obj-$(CONFIG_CORESIGHT) += coresight.o
coresight-objs := coresight-core.o \
of_coresight.o
and e.g., instead of this:
obj-$(CONFIG_CORESIGHT_SOURCE_ETM3X) += coresight-etm3x-core.o
coresight-etm3x-core-objs := coresight-etm3x.o \
coresight-etm-cp14.o \
coresight-etm3x-sysfs.o
we have this:
obj-$(CONFIG_CORESIGHT_SOURCE_ETM3X) += coresight-etm3x.o
coresight-etm3x-objs := coresight-etm3x-core.o \
coresight-etm-cp14.o \
coresight-etm3x-sysfs.o
?
> > +static int __exit tmc_remove(struct amba_device *adev)
> > +{
> > + struct tmc_drvdata *drvdata = dev_get_drvdata(&adev->dev);
> > +
> > + /* free ETB/ETF or ETR memory */
> > + tmc_read_unprepare(drvdata);
> > +
> > + misc_deregister(&drvdata->miscdev);
> > + coresight_unregister(drvdata->csdev);
> > +
> > + return 0;
> > +}
> > +
>
> Right now I can remove the module for a TMC link or sink when part of an active
> session, something I pointed out during an earlier revision.
Right, I missed that :(
So would the first thing tmc_remove does is this:
if (drvdata->reading)
return -EBUSY;
work, or would we need to introduce a new sentinel?
> I also think we need to deal with driver removal cases when the TMC buffer
> (ETR or ETF) is being read from sysFS.
OK, I thought the:
struct file_operations tmc_fops = {
.owner = THIS_MODULE,
would prevent module unload whilst sysfs access was being performed,
but I'll double check.
Thanks,
Kim
^ permalink raw reply
* [PATCH v2 1/8] driver core: make deferring probe after init optional
From: Rob Herring @ 2018-05-24 23:47 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180524222855.GD14924@minitux>
On Thu, May 24, 2018 at 5:28 PM, Bjorn Andersson
<bjorn.andersson@linaro.org> wrote:
> On Thu 24 May 10:50 PDT 2018, Rob Herring wrote:
>
>> Deferred probe will currently wait forever on dependent devices to probe,
>> but sometimes a driver will never exist. It's also not always critical for
>> a driver to exist. Platforms can rely on default configuration from the
>> bootloader or reset defaults for things such as pinctrl and power domains.
>> This is often the case with initial platform support until various drivers
>> get enabled. There's at least 2 scenarios where deferred probe can render
>> a platform broken. Both involve using a DT which has more devices and
>> dependencies than the kernel supports. The 1st case is a driver may be
>> disabled in the kernel config. The 2nd case is the kernel version may
>> simply not have the dependent driver. This can happen if using a newer DT
>> (provided by firmware perhaps) with a stable kernel version.
>>
>> Subsystems or drivers may opt-in to this behavior by calling
>> driver_deferred_probe_check_init_done() instead of just returning
>> -EPROBE_DEFER. They may use additional information from DT or kernel's
>> config to decide whether to continue to defer probe or not.
>>
>
> For builtin drivers this still looks reasonable.
>
> But I would like to have an additional clarification here stating that
> drivers that might be targeted by this query must not be compiled as
> modules.
>
> And I would prefer to see an ack from e.g. Arnd that arm-soc is okay
> that we drop "tristate" on drivers affected by this; e.g. if we put this
> in the pinctrl core then all pinctrl drivers should be "bool" and so
> should any i2c, ssbi and spmi buses and drivers be.
For pinctrl, you are not affected now unless you change your DT. I
made pinctrl opt-in since as you said it could lead to some
intermittent problems. If iommu or power domains are required, then it
should fail pretty hard.
However, good luck getting your serial console to work if it has a
pinctrl dependency and that's a module. It won't work because the
console has to be up before userspace. Of course, you can just rely on
earlycon, but that just proves that pinctrl is not required (at least
for 1 serial pin). :)
Rob
>
> Regards,
> Bjorn
>
>> Cc: Alexander Graf <agraf@suse.de>
>> Signed-off-by: Rob Herring <robh@kernel.org>
>> ---
>> drivers/base/dd.c | 17 +++++++++++++++++
>> include/linux/device.h | 2 ++
>> 2 files changed, 19 insertions(+)
>>
>> diff --git a/drivers/base/dd.c b/drivers/base/dd.c
>> index c9f54089429b..d6034718da6f 100644
>> --- a/drivers/base/dd.c
>> +++ b/drivers/base/dd.c
>> @@ -226,6 +226,16 @@ void device_unblock_probing(void)
>> driver_deferred_probe_trigger();
>> }
>>
>> +int driver_deferred_probe_check_init_done(struct device *dev, bool optional)
>> +{
>> + if (optional && initcalls_done) {
>> + dev_WARN(dev, "ignoring dependency for device, assuming no driver");
>> + return -ENODEV;
>> + }
>> +
>> + return -EPROBE_DEFER;
>> +}
>> +
>> /**
>> * deferred_probe_initcall() - Enable probing of deferred devices
>> *
>> @@ -240,6 +250,13 @@ static int deferred_probe_initcall(void)
>> /* Sort as many dependencies as possible before exiting initcalls */
>> flush_work(&deferred_probe_work);
>> initcalls_done = true;
>> +
>> + /*
>> + * Trigger deferred probe again, this time we won't defer anything
>> + * that is optional
>> + */
>> + driver_deferred_probe_trigger();
>> + flush_work(&deferred_probe_work);
>> return 0;
>> }
>> late_initcall(deferred_probe_initcall);
>> diff --git a/include/linux/device.h b/include/linux/device.h
>> index 477956990f5e..f3dafd44c285 100644
>> --- a/include/linux/device.h
>> +++ b/include/linux/device.h
>> @@ -334,6 +334,8 @@ struct device *driver_find_device(struct device_driver *drv,
>> struct device *start, void *data,
>> int (*match)(struct device *dev, void *data));
>>
>> +int driver_deferred_probe_check_init_done(struct device *dev, bool optional);
>> +
>> /**
>> * struct subsys_interface - interfaces to device functions
>> * @name: name of the device function
>> --
>> 2.17.0
>>
^ permalink raw reply
* [PATCH 03/14] ARM: bugs: hook processor bug checking into SMP and suspend paths
From: Florian Fainelli @ 2018-05-24 23:30 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <E1fKjEx-00063Y-N5@rmk-PC.armlinux.org.uk>
On 05/21/2018 04:44 AM, Russell King wrote:
> Check for CPU bugs when secondary processors are being brought online,
> and also when CPUs are resuming from a low power mode. This gives an
> opportunity to check that processor specific bug workarounds are
> correctly enabled for all paths that a CPU re-enters the kernel.
>
> Signed-off-by: Russell King <rmk+kernel@armlinux.org.uk>
> Reviewed-by: Florian Fainelli <f.fainelli@gmail.com>
Something I missed, is that this correctly warns about e.g: missing the
IBE bit for secondary cores, but it seems to be missing it for the boot CPU:
[ 0.001053] CPU: Testing write buffer coherency: ok
[ 0.001086] CPU: Spectre v2: using ICIALLU workaround
[ 0.001304] CPU0: update cpu_capacity 1024
[ 0.001316] CPU0: thread -1, cpu 0, socket 0, mpidr 80000000
[ 0.001693] Setting up static identity map for 0x200000 - 0x200060
[ 0.001769] Hierarchical SRCU implementation.
[ 0.003951] brcmstb: biuctrl: MCP: Write pairing already disabled
[ 0.004224] smp: Bringing up secondary CPUs ...
[ 0.004874] CPU1: update cpu_capacity 1024
[ 0.004877] CPU1: thread -1, cpu 1, socket 0, mpidr 80000001
[ 0.004881] CPU1: Spectre v2: firmware did not set auxiliary control
register IBE bit, system vulnerable
[ 0.005604] CPU2: update cpu_capacity 1024
[ 0.005607] CPU2: thread -1, cpu 2, socket 0, mpidr 80000002
[ 0.005610] CPU2: Spectre v2: firmware did not set auxiliary control
register IBE bit, system vulnerable
[ 0.006295] CPU3: update cpu_capacity 1024
[ 0.006299] CPU3: thread -1, cpu 3, socket 0, mpidr 80000003
[ 0.006302] CPU3: Spectre v2: firmware did not set auxiliary control
register IBE bit, system vulnerable
[ 0.006377] smp: Brought up 1 node, 4 CPUs
[ 0.006389] SMP: Total of 4 processors activated (216.00 BogoMIPS).
[ 0.006398] CPU: All CPU(s) started in SVC mode.
Which could be confusing if you intentionally restricted a SMP system to
UP with maxcpus=1 or smp=off:
[ 0.001043] CPU: Testing write buffer coherency: ok
[ 0.001077] CPU: Spectre v2: using ICIALLU workaround
[ 0.001291] CPU0: update cpu_capacity 1024
[ 0.001302] CPU0: thread -1, cpu 0, socket 0, mpidr 80000000
[ 0.001516] Setting up static identity map for 0x200000 - 0x200060
[ 0.001593] Hierarchical SRCU implementation.
[ 0.003829] brcmstb: biuctrl: MCP: Write pairing already disabled
[ 0.004097] smp: Bringing up secondary CPUs ...
[ 0.004108] smp: Brought up 1 node, 1 CPU
[ 0.004117] SMP: Total of 1 processors activated (54.00 BogoMIPS).
[ 0.004126] CPU: All CPU(s) started in SVC mode.
> ---
> arch/arm/include/asm/bugs.h | 2 ++
> arch/arm/kernel/bugs.c | 5 +++++
> arch/arm/kernel/smp.c | 4 ++++
> arch/arm/kernel/suspend.c | 2 ++
> 4 files changed, 13 insertions(+)
>
> diff --git a/arch/arm/include/asm/bugs.h b/arch/arm/include/asm/bugs.h
> index ed122d294f3f..73a99c72a930 100644
> --- a/arch/arm/include/asm/bugs.h
> +++ b/arch/arm/include/asm/bugs.h
> @@ -14,8 +14,10 @@ extern void check_writebuffer_bugs(void);
>
> #ifdef CONFIG_MMU
> extern void check_bugs(void);
> +extern void check_other_bugs(void);
> #else
> #define check_bugs() do { } while (0)
> +#define check_other_bugs() do { } while (0)
> #endif
>
> #endif
> diff --git a/arch/arm/kernel/bugs.c b/arch/arm/kernel/bugs.c
> index 88024028bb70..16e7ba2a9cc4 100644
> --- a/arch/arm/kernel/bugs.c
> +++ b/arch/arm/kernel/bugs.c
> @@ -3,7 +3,12 @@
> #include <asm/bugs.h>
> #include <asm/proc-fns.h>
>
> +void check_other_bugs(void)
> +{
> +}
> +
> void __init check_bugs(void)
> {
> check_writebuffer_bugs();
> + check_other_bugs();
> }
> diff --git a/arch/arm/kernel/smp.c b/arch/arm/kernel/smp.c
> index 2da087926ebe..5ad0b67b9e33 100644
> --- a/arch/arm/kernel/smp.c
> +++ b/arch/arm/kernel/smp.c
> @@ -31,6 +31,7 @@
> #include <linux/irq_work.h>
>
> #include <linux/atomic.h>
> +#include <asm/bugs.h>
> #include <asm/smp.h>
> #include <asm/cacheflush.h>
> #include <asm/cpu.h>
> @@ -405,6 +406,9 @@ asmlinkage void secondary_start_kernel(void)
> * before we continue - which happens after __cpu_up returns.
> */
> set_cpu_online(cpu, true);
> +
> + check_other_bugs();
> +
> complete(&cpu_running);
>
> local_irq_enable();
> diff --git a/arch/arm/kernel/suspend.c b/arch/arm/kernel/suspend.c
> index a40ebb7c0896..d08099269e35 100644
> --- a/arch/arm/kernel/suspend.c
> +++ b/arch/arm/kernel/suspend.c
> @@ -3,6 +3,7 @@
> #include <linux/slab.h>
> #include <linux/mm_types.h>
>
> +#include <asm/bugs.h>
> #include <asm/cacheflush.h>
> #include <asm/idmap.h>
> #include <asm/pgalloc.h>
> @@ -36,6 +37,7 @@ int cpu_suspend(unsigned long arg, int (*fn)(unsigned long))
> cpu_switch_mm(mm->pgd, mm);
> local_flush_bp_all();
> local_flush_tlb_all();
> + check_other_bugs();
> }
>
> return ret;
>
--
Florian
^ permalink raw reply
* [PATCH 1/6] coresight: remove CORESIGHT_LINKS_AND_SINKS dependencies and selections
From: Kim Phillips @ 2018-05-24 23:30 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CANLsYkw-KcEM43pqWgGU1XYOfSTD4cmspNcPM-u+n9x6Xtazbg@mail.gmail.com>
On Thu, 24 May 2018 09:32:48 -0600
Mathieu Poirier <mathieu.poirier@linaro.org> wrote:
> On 23 May 2018 at 13:51, Kim Phillips <kim.phillips@arm.com> wrote:
> > On Tue, 22 May 2018 11:31:40 -0600
> > Mathieu Poirier <mathieu.poirier@linaro.org> wrote:
> >
> >> On Thu, May 17, 2018 at 08:20:19PM -0500, Kim Phillips wrote:
> >> > A coresight topology doesn't need to include links, i.e., a source can
> >> > be directly connected to a sink. As such, selecting and/or depending on
> >> > LINKS_AND_SINKS is no longer needed.
> >>
> >> I'm good with this patch but now the help text for CORESIGHT_LINKS_AND_SINKS no
> >> longer match what the config does. I see two ways to fix this:
> >
> > This patch doesn't change what the config does, it just changes what
> > other config options depend on it.
> >
> >> 1) Rework the help text.
> >
> > I don't see how, given the above. Here's the text:
> >
> > config CORESIGHT_LINKS_AND_SINKS
> > bool "CoreSight Link and Sink drivers"
> > help
> > This enables support for CoreSight link and sink drivers that are
> > responsible for transporting and collecting the trace data
> > respectively. Link and sinks are dynamically aggregated with a trace
> > entity at run time to form a complete trace path.
> >
> > What part of that becomes invalid with this patch?
>
> Looking at the new Kconfig, what sink component depend on
> CORESIGHT_LINKS_AND_SINKS?
How does that affect the description text? The description text
doesn't insinuate any implicit dependencies or non-.
> config CORESIGHT_LINKS
Please, not another gratuitous config name change, I've already
experienced usage regressions from the CORESIGHT_QCOM_REPLICATOR =>
CORESIGHT_DYNAMIC_REPLICATOR change:
https://patchwork.kernel.org/patch/10206023/
> bool "CoreSight Link drivers"
> help
> This enables support for CoreSight link drivers that are responsible
> for transporting trace data from source to sink. Links are
> dynamically
> aggregated with other traces entities at run time to form a
> complete trace
> path.
Oh, I see, so your point is that LINKS_AND_SINKS doesn't technically
build any sink drivers? That's completely orthogonal to removing a
dependency chain: that just tells me the name was a poor choice in the
first place maybe? I don't see where the Makefile may have built a
sink, but it may be before the move to drivers/hwtracing/coresight, or
some other reorganization.
> >> 2) Rework CORESIGHT_LINKS_AND_SINKS to be CORESIGHT_FUNNEL and move
> >> coresight-replicator.o under CORESIGHT_DYNAMIC_REPLICATOR in the Makefile. I
> >> really liked your idea of making the replicator driver intelligent enough to
> >> deal with both DT and platform declaration, which merges two driver into one.
> >>
> >> I'm obviously favouring the second option but recognise it doesn't have to be
> >> part of this patchet. So for this set please rework the help text for
> >> CORESIGHT_LINKS_AND_SINKS. Once we've dealt with this topic we can refactor the
> >> replicator driver.
> >
> > I'd really like to just focus on getting CoreSight to load as modules,
> > something for which this patch isn't technically required...
>
> The only thing I'm asking is that the config description and help text
> reflect what the Makefile does.
argh, wellll, it's a completely different change, and we're now
completely off the modularization topic, and I'm uncomfortable doing
reorgs on things I don't understand, renaming CONFIG_s, esp. when
others such as the REPLICATOR, since as far as I know, that's also a
link??
Kim
^ permalink raw reply
* [PATCH v2 00/14] ARM Spectre variant 2 fixes
From: Florian Fainelli @ 2018-05-24 23:18 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180521114238.GN17671@n2100.armlinux.org.uk>
On 05/21/2018 04:42 AM, Russell King - ARM Linux wrote:
> This is the second posting - the original cover note is below. Comments
> from previous series addresesd:
> - Drop R7 and R8 changes.
> - Remove "PSCI" from the hypervisor version of the workaround.
>
> arch/arm/include/asm/bugs.h | 6 +-
> arch/arm/include/asm/cp15.h | 3 +
> arch/arm/include/asm/cputype.h | 5 ++
> arch/arm/include/asm/kvm_asm.h | 2 -
> arch/arm/include/asm/kvm_host.h | 14 +++-
> arch/arm/include/asm/kvm_mmu.h | 23 +++++-
> arch/arm/include/asm/proc-fns.h | 4 +
> arch/arm/include/asm/system_misc.h | 8 ++
> arch/arm/kernel/Makefile | 1 +
> arch/arm/kernel/bugs.c | 18 +++++
> arch/arm/kernel/smp.c | 4 +
> arch/arm/kernel/suspend.c | 2 +
> arch/arm/kvm/hyp/hyp-entry.S | 108 +++++++++++++++++++++++++-
> arch/arm/mm/Kconfig | 23 ++++++
> arch/arm/mm/Makefile | 2 +-
> arch/arm/mm/fault.c | 3 +
> arch/arm/mm/proc-macros.S | 3 +-
> arch/arm/mm/proc-v7-2level.S | 6 --
> arch/arm/mm/proc-v7-bugs.c | 130 +++++++++++++++++++++++++++++++
> arch/arm/mm/proc-v7.S | 154 +++++++++++++++++++++++++++++--------
> 20 files changed, 469 insertions(+), 50 deletions(-)
> create mode 100644 arch/arm/kernel/bugs.c
> create mode 100644 arch/arm/mm/proc-v7-bugs.c
Since there appears to be more work needed in the PSCI/KVM changes
(patches 9 through 14), how about we go with the "bare-metal" parts:
patches 1-8 first and try to get those included ASAP?
The rationale being that a lot of affected people have Linux running on
ARMv7-A Cortex-A, typically A9, A15, Brahma-B15, and are in need of
those patches but do not necessarily require KVM fixes right now, and
even less so PSCI infrastructure to mitigate ARMv8-A running in AArch32.
In terms of backporting to -stable, and because the spectre variant 1
patches have not been submitted yet, it is not like we can lump
everything in one go anyway, so we are not making the lives of the
-stable maintainers any worse than it currently is?
Yay or nay?
>
> On Wed, May 16, 2018 at 11:59:49AM +0100, Russell King - ARM Linux wrote:
>> This series addresses the Spectre variant 2 issues on ARM Cortex and
>> Broadcom Brahma B15 CPUs. Due to the complexity of the bug, it is not
>> possible to verify that this series fixes any of the bugs, since it
>> has not been able to reproduce these exact scenarios using test
>> programs.
>>
>> I believe that this covers the entire extent of the Spectre variant 2
>> issues, with the exception of Cortex A53 and Cortex A72 processors as
>> these require a substantially more complex solution (except where the
>> workaround is implemented in PSCI firmware.)
>>
>> Spectre variant 1 is not covered by this series.
>>
>> The patch series is based partly on Marc Zyngier's work from February -
>> two of the KVM patches are from Marc's work.
>>
>> The main differences are:
>> - Inclusion of more processors as per current ARM Ltd security update
>> documentation.
>> - Extension of "bugs" infrastructure to detect Cortex A8 and Cortex A15
>> CPUs missing out on the IBE bit being set on (re-)entry to the kernel
>> through all paths.
>> - Handle all suspect userspace-touching-kernelspace aborts irrespective
>> of mapping type.
>>
>> The first patch will trivially conflict with the Broadcom Brahma
>> updates already in arm-soc - it has been necessary to independently
>> add the ID definitions for the B15 CPU.
>>
>> Having worked through this series, I'm of the opinion that the
>> define_processor_functions macro in proc-v7 are probably more hassle
>> than they're worth - here, we don't need the global equivalent symbols,
>> because we never refer to them from the kernel code for any V7
>> processor (MULTI_CPU is always defined.)
>>
>> This series is currently in my "spectre" branch (along with some
>> Spectre variant 1 patches.)
>>
>> Please carefully review.
>>
>> arch/arm/include/asm/bugs.h | 6 +-
>> arch/arm/include/asm/cp15.h | 3 +
>> arch/arm/include/asm/cputype.h | 5 ++
>> arch/arm/include/asm/kvm_asm.h | 2 -
>> arch/arm/include/asm/kvm_host.h | 14 +++-
>> arch/arm/include/asm/kvm_mmu.h | 23 +++++-
>> arch/arm/include/asm/proc-fns.h | 4 +
>> arch/arm/include/asm/system_misc.h | 8 ++
>> arch/arm/kernel/Makefile | 1 +
>> arch/arm/kernel/bugs.c | 18 +++++
>> arch/arm/kernel/smp.c | 4 +
>> arch/arm/kernel/suspend.c | 2 +
>> arch/arm/kvm/hyp/hyp-entry.S | 108 ++++++++++++++++++++++++-
>> arch/arm/mm/Kconfig | 23 ++++++
>> arch/arm/mm/Makefile | 2 +-
>> arch/arm/mm/fault.c | 3 +
>> arch/arm/mm/proc-macros.S | 3 +-
>> arch/arm/mm/proc-v7-2level.S | 6 --
>> arch/arm/mm/proc-v7-bugs.c | 130 ++++++++++++++++++++++++++++++
>> arch/arm/mm/proc-v7.S | 158 +++++++++++++++++++++++++++++--------
>> 20 files changed, 471 insertions(+), 52 deletions(-)
>>
>> --
>> RMK's Patch system: http://www.armlinux.org.uk/developer/patches/
>> FTTC broadband for 0.8mile line in suburbia: sync at 8.8Mbps down 630kbps up
>> According to speedtest.net: 8.21Mbps down 510kbps up
>>
>> _______________________________________________
>> linux-arm-kernel mailing list
>> linux-arm-kernel at lists.infradead.org
>> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
>
--
Florian
^ permalink raw reply
* [PATCH v2 1/3] input: touchscreen: edt-ft5x06: don't make device a wakeup source by default
From: Dmitry Torokhov @ 2018-05-24 23:17 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAL_JsqJQt6vFqH-KzNvjW+FZXCgzNAwXj_nSYow2Uz2Vcmi_Cg@mail.gmail.com>
On Wed, May 23, 2018 at 09:45:05AM -0500, Rob Herring wrote:
> On Wed, May 23, 2018 at 3:27 AM, Daniel Mack <daniel@zonque.org> wrote:
> > On Tuesday, May 22, 2018 07:54 PM, Rob Herring wrote:
> >>
> >> On Thu, May 17, 2018 at 11:05:50AM +0200, Daniel Mack wrote:
> >>>
> >>> Allow configuring the device as wakeup source through device properties,
> >>> as
> >>> not all platforms want to wake up on touch screen activity.
> >>>
> >>> The I2C core automatically reads the "wakeup-source" DT property to
> >>> configure a device's wakeup capability, and board supports files can set
> >>> I2C_CLIENT_WAKE in the flags.
> >>
> >>
> >> This will break wake-up on working systems. Looks like mostly i.MX, but
> >> there's one AM437x board. If that board doesn't care, then it is up to
> >> Shawn.
> >
> >
> > I added the property to the dts files, but as Dmitry pointed out, I missed
> > some. Sorry for that.
>
> Just adding the property to dts files doesn't fix the compatibility
> problem. If a user uses an existing dtb (before this change) with a
> new kernel (after this change), then wakeup will stop working.
Is this a practical problem though? Do we know of any products with
this touch panel that use DTS not distributed with the kernel?
--
Dmitry
^ permalink raw reply
* [PATCH 6/9] asm-generic/bitops/atomic.h: Rewrite using atomic_fetch_*
From: Peter Zijlstra @ 2018-05-24 22:32 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180524220610.GA7607@andrea>
On Fri, May 25, 2018 at 12:06:10AM +0200, Andrea Parri wrote:
> Hi Mark,
>
> > As an aside, If I complete the autogeneration stuff, it'll be possible
> > to generate those. I split out the necessary barriers in [1], but I
> > still have a lot of other preparatory cleanup to do.
>
> I do grasp the rationale behind that naming:
>
> __atomic_mb_{before,after}_{acquire,release,fence}()
>
> and yet I remain puzzled by it:
>
> For example, can you imagine (using):
>
> __atomic_mb_before_acquire() ?
>
> (as your __atomic_mb_after_acquire() is whispering me "acquire-fences"...)
Yes, I really do think he means acquire-fence. It is however something I
have vague memories of not being liked much because it is the memop
itself that carries the ordering.
That said, this is only an implementation detail and not a public
interface, so maybe we can get away with it.
^ permalink raw reply
* [PATCH] arm64: dts: qcom: msm8996: Use UFS_GDSC for UFS
From: Bjorn Andersson @ 2018-05-24 22:31 UTC (permalink / raw)
To: linux-arm-kernel
The UFS host controller occationally (20%) fails to enable
gcc_ufs_axi_clk because the UFS GDSC is not enabled. In most cases it's
enabled through the UFS phy driver, but to make sure it's enabled let's
enable it directly from the UFS host controller directly as well.
Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org>
---
arch/arm64/boot/dts/qcom/msm8996.dtsi | 2 ++
1 file changed, 2 insertions(+)
diff --git a/arch/arm64/boot/dts/qcom/msm8996.dtsi b/arch/arm64/boot/dts/qcom/msm8996.dtsi
index 380e14591686..03c7904bda14 100644
--- a/arch/arm64/boot/dts/qcom/msm8996.dtsi
+++ b/arch/arm64/boot/dts/qcom/msm8996.dtsi
@@ -674,6 +674,8 @@
vccq-max-microamp = <450000>;
vccq2-max-microamp = <450000>;
+ power-domains = <&gcc UFS_GDSC>;
+
clock-names =
"core_clk_src",
"core_clk",
--
2.17.0
^ permalink raw reply related
* [PATCH v2 1/8] driver core: make deferring probe after init optional
From: Bjorn Andersson @ 2018-05-24 22:28 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180524175024.19874-2-robh@kernel.org>
On Thu 24 May 10:50 PDT 2018, Rob Herring wrote:
> Deferred probe will currently wait forever on dependent devices to probe,
> but sometimes a driver will never exist. It's also not always critical for
> a driver to exist. Platforms can rely on default configuration from the
> bootloader or reset defaults for things such as pinctrl and power domains.
> This is often the case with initial platform support until various drivers
> get enabled. There's at least 2 scenarios where deferred probe can render
> a platform broken. Both involve using a DT which has more devices and
> dependencies than the kernel supports. The 1st case is a driver may be
> disabled in the kernel config. The 2nd case is the kernel version may
> simply not have the dependent driver. This can happen if using a newer DT
> (provided by firmware perhaps) with a stable kernel version.
>
> Subsystems or drivers may opt-in to this behavior by calling
> driver_deferred_probe_check_init_done() instead of just returning
> -EPROBE_DEFER. They may use additional information from DT or kernel's
> config to decide whether to continue to defer probe or not.
>
For builtin drivers this still looks reasonable.
But I would like to have an additional clarification here stating that
drivers that might be targeted by this query must not be compiled as
modules.
And I would prefer to see an ack from e.g. Arnd that arm-soc is okay
that we drop "tristate" on drivers affected by this; e.g. if we put this
in the pinctrl core then all pinctrl drivers should be "bool" and so
should any i2c, ssbi and spmi buses and drivers be.
Regards,
Bjorn
> Cc: Alexander Graf <agraf@suse.de>
> Signed-off-by: Rob Herring <robh@kernel.org>
> ---
> drivers/base/dd.c | 17 +++++++++++++++++
> include/linux/device.h | 2 ++
> 2 files changed, 19 insertions(+)
>
> diff --git a/drivers/base/dd.c b/drivers/base/dd.c
> index c9f54089429b..d6034718da6f 100644
> --- a/drivers/base/dd.c
> +++ b/drivers/base/dd.c
> @@ -226,6 +226,16 @@ void device_unblock_probing(void)
> driver_deferred_probe_trigger();
> }
>
> +int driver_deferred_probe_check_init_done(struct device *dev, bool optional)
> +{
> + if (optional && initcalls_done) {
> + dev_WARN(dev, "ignoring dependency for device, assuming no driver");
> + return -ENODEV;
> + }
> +
> + return -EPROBE_DEFER;
> +}
> +
> /**
> * deferred_probe_initcall() - Enable probing of deferred devices
> *
> @@ -240,6 +250,13 @@ static int deferred_probe_initcall(void)
> /* Sort as many dependencies as possible before exiting initcalls */
> flush_work(&deferred_probe_work);
> initcalls_done = true;
> +
> + /*
> + * Trigger deferred probe again, this time we won't defer anything
> + * that is optional
> + */
> + driver_deferred_probe_trigger();
> + flush_work(&deferred_probe_work);
> return 0;
> }
> late_initcall(deferred_probe_initcall);
> diff --git a/include/linux/device.h b/include/linux/device.h
> index 477956990f5e..f3dafd44c285 100644
> --- a/include/linux/device.h
> +++ b/include/linux/device.h
> @@ -334,6 +334,8 @@ struct device *driver_find_device(struct device_driver *drv,
> struct device *start, void *data,
> int (*match)(struct device *dev, void *data));
>
> +int driver_deferred_probe_check_init_done(struct device *dev, bool optional);
> +
> /**
> * struct subsys_interface - interfaces to device functions
> * @name: name of the device function
> --
> 2.17.0
>
^ permalink raw reply
* [PATCH] drm/rockchip: vop: fix irq disabled after vop driver probed
From: Heiko Stübner @ 2018-05-24 22:06 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <b8eb41e576c4007d40223699eb951db32916b86a.camel@collabora.com>
From: Sandy Huang <hjc@rock-chips.com>
The vop irq is shared between vop and iommu and irq probing in the
iommu driver moved to the probe function recently. This can in some
cases lead to a stall if the irq is triggered while the vop driver
still has it disabled.
But there is no real need to disable the irq, as the vop can simply
also track its enabled state and ignore irqs in that case.
So remove the enable/disable handling and add appropriate condition
to the irq handler.
Signed-off-by: Sandy Huang <hjc@rock-chips.com>
[added an actual commit message]
Signed-off-by: Heiko Stuebner <heiko@sntech.de>
---
Hi Ezequiel,
this patch came from a discussion I had with Rockchip people over the
iommu changes and resulting issues back in april, but somehow was
forgotten and not posted to the lists. Correcting that now.
So removing the enable/disable voodoo on the shared interrupt is
the preferred way.
drivers/gpu/drm/rockchip/rockchip_drm_vop.c | 13 ++++++-------
1 file changed, 7 insertions(+), 7 deletions(-)
diff --git a/drivers/gpu/drm/rockchip/rockchip_drm_vop.c b/drivers/gpu/drm/rockchip/rockchip_drm_vop.c
index 510cdf0..61493d4 100644
--- a/drivers/gpu/drm/rockchip/rockchip_drm_vop.c
+++ b/drivers/gpu/drm/rockchip/rockchip_drm_vop.c
@@ -549,8 +549,6 @@ static int vop_enable(struct drm_crtc *crtc)
spin_unlock(&vop->reg_lock);
- enable_irq(vop->irq);
-
drm_crtc_vblank_on(crtc);
return 0;
@@ -596,8 +594,6 @@ static void vop_crtc_atomic_disable(struct drm_crtc *crtc,
vop_dsp_hold_valid_irq_disable(vop);
- disable_irq(vop->irq);
-
vop->is_enabled = false;
/*
@@ -1168,6 +1164,13 @@ static irqreturn_t vop_isr(int irq, void *data)
int ret = IRQ_NONE;
/*
+ * since the irq is shared with iommu, iommu irq is enabled before vop
+ * enable, so before vop enable we do nothing.
+ */
+ if (!vop->is_enabled)
+ return IRQ_NONE;
+
+ /*
* interrupt register has interrupt status, enable and clear bits, we
* must hold irq_lock to avoid a race with enable/disable_vblank().
*/
@@ -1586,9 +1588,6 @@ static int vop_bind(struct device *dev, struct device *master, void *data)
if (ret)
goto err_disable_pm_runtime;
- /* IRQ is initially disabled; it gets enabled in power_on */
- disable_irq(vop->irq);
-
return 0;
err_disable_pm_runtime:
--
2.7.4
^ permalink raw reply related
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox