* [PATCH v7 0/4] arm64: arch_timer: Add workaround for hisilicon-161601 erratum
From: Ding Tianhong @ 2017-01-12 4:23 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1483772858-10380-1-git-send-email-dingtianhong@huawei.com>
Hi Marc:
How about this v7, if any suggestions very grateful.
Thanks.
Ding
On 2017/1/7 15:07, Ding Tianhong wrote:
> Erratum Hisilicon-161601 says that the ARM generic timer counter "has the
> potential to contain an erroneous value when the timer value changes".
> Accesses to TVAL (both read and write) are also affected due to the implicit counter
> read. Accesses to CVAL are not affected.
>
> The workaround is to reread the system count registers until the value of the second
> read is larger than the first one by less than 32, the system counter can be guaranteed
> not to return wrong value twice by back-to-back read and the error value is always larger
> than the correct one by 32. Writes to TVAL are replaced with an equivalent write to CVAL.
>
> v2: Introducing a new generic erratum handling mechanism for fsl,a008585 and hisilicon,161601.
> Significant rework based on feedback, including seperate the fsl erratum a008585
> to another patch, update the erratum name and remove unwanted code.
>
> v3: Introducing the erratum_workaround_set_sne generic function for fsl erratum a008585
> and make the #define __fsl_a008585_read_reg to be private to the .c file instead of
> being globally visible. After discussion with Marc and Will, a consensus decision was
> made to remove the commandline parameter for enabling fsl,erratum-a008585 erratum,
> and make some generic name more specific, export timer_unstable_counter_workaround
> for module access.
>
> Significant rework based on feedback, including fix some alignment problem, make the
> #define __hisi_161601_read_reg to be private to the .c file instead of being globally
> visible, add more accurate annotation and modify a bit of logical format to enable
> arch_timer_read_ool_enabled, remove the kernel commandline parameter
> clocksource.arm_arch_timer.hisilicon-161601.
>
> Introduce a generic aquick framework for erratum in ACPI mode.
>
> v4: rename the quirk handler parameter to make it more generic, and
> avoid break loop when handling the quirk becasue it need to
> support multi quirks handler.
>
> update some data structures for acpi mode.
>
> v5: Adapt the new kernel-parameters.txt for latest kernel version.
> Set the retries of reread system counter to 50, because it is possible
> that some interrupts may lead to more than twice read errors and break the loop,
> it will trigger the warning, so we set the number of retries far beyond the number of
> iterations the loop has been observed to take.
>
> v6: The last 2 patches in the previous version about the ACPI mode will conflict witch Fuwei's
> GTDT patches, so remove the ACPI part and only support the DT base code for this patch set.
>
> We have trigger a bug when select the CONFIG_FUNCTION_GRAPH_TRACER and enable function_graph
> to /sys/kernel/debug/tracing/current_tracer, the system will stall into an endless loop, it looks
> like that the ftrace_graph_caller will be related to xxx.read_cntvct_el0 and read the system counter
> again, so mark the xxx.read_cntvct_el0 with notrace to fix the problem.
>
> v7: Introduce a new general config symbol named CONFIG_ARM_ARCH_TIMER_OOL_WORKAROUND to enable the workaround
> for any chips which has similar arch timer erratum just like "fsl,erratum_a008585" and "hisilicon,erratum_161601",
> modify the struct arch_timer_erratum_workaround to be compatible different chip erratum more easily, and
> reconstruction some code base on the new config symbol and struct, thanks to Marc's suggestion.
>
> Ding Tianhong (4):
> arm64: arch_timer: Add device tree binding for hisilicon-161601
> erratum
> arm64: arch_timer: Introduce a generic erratum handing mechanism for
> fsl-a008585
> arm64: arch_timer: Work around Erratum Hisilicon-161601
> arm64: arch timer: Add timer erratum property for Hip05-d02 and
> Hip06-d03
>
> Documentation/admin-guide/kernel-parameters.txt | 9 --
> Documentation/arm64/silicon-errata.txt | 1 +
> .../devicetree/bindings/arm/arch_timer.txt | 8 ++
> arch/arm64/boot/dts/hisilicon/hip05.dtsi | 1 +
> arch/arm64/boot/dts/hisilicon/hip06.dtsi | 1 +
> arch/arm64/include/asm/arch_timer.h | 38 ++----
> drivers/clocksource/Kconfig | 18 +++
> drivers/clocksource/arm_arch_timer.c | 150 +++++++++++++++------
> 8 files changed, 152 insertions(+), 74 deletions(-)
>
^ permalink raw reply
* [PATCH v5] arm64: dts: mt8173: add mmsel clocks for 4K support
From: Daniel Kurtz @ 2017-01-12 4:50 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1470279438-60372-1-git-send-email-bibby.hsieh@mediatek.com>
Hi Matthias,
(Trying again to send plain text email)...
On Thu, Aug 4, 2016 at 10:57 AM, Bibby Hsieh <bibby.hsieh@mediatek.com> wrote:
> To support HDMI 4K resolution, mmsys need clcok
> mm_sel to be 400MHz.
>
> The board .dts file should override the clock rate
> property with the higher VENCPLL frequency the board
> supports HDMI 4K resolution.
>
> Signed-off-by: Bibby Hsieh <bibby.hsieh@mediatek.com>
Reviewed-by: Daniel Kurtz <djkurtz@chromium.org>
It looks like this patch was lost. It is actually a prerequisite for
MTK 4k HDMI support, which already landed in v4.9.
See the email thread entitled:
[PATCH v5 0/3] MT8173 HDMI 4K support <https://lkml.org/lkml/2016/9/28/893>
Or these three:
0d2200794f0a drm/mediatek: modify the factor to make the pll_rate set
in the 1G-2G range
968253bd7caa drm/mediatek: enhance the HDMI driving current
d542b7c473f0 drm/mediatek: do mtk_hdmi_send_infoframe after HDMI clock enable
-Dan
> ---
> arch/arm64/boot/dts/mediatek/mt8173.dtsi | 2 ++
> 1 file changed, 2 insertions(+)
>
> diff --git a/arch/arm64/boot/dts/mediatek/mt8173.dtsi b/arch/arm64/boot/dts/mediatek/mt8173.dtsi
> index 78529e4..c3f32f3 100644
> --- a/arch/arm64/boot/dts/mediatek/mt8173.dtsi
> +++ b/arch/arm64/boot/dts/mediatek/mt8173.dtsi
> @@ -690,6 +690,8 @@
> compatible = "mediatek,mt8173-mmsys", "syscon";
> reg = <0 0x14000000 0 0x1000>;
> power-domains = <&scpsys MT8173_POWER_DOMAIN_MM>;
> + assigned-clocks = <&topckgen CLK_TOP_MM_SEL>;
> + assigned-clock-rates = <400000000>;
> #clock-cells = <1>;
> };
>
> --
> 1.7.9.5
>
^ permalink raw reply
* [PATCH v3 04/10] Documentation: perf: hisi: Documentation for HiP05/06/07 PMU event counting.
From: Anurup M @ 2017-01-12 5:47 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20170110175500.GD24036@leverpostej>
On Tuesday 10 January 2017 11:25 PM, Mark Rutland wrote:
> On Mon, Jan 02, 2017 at 01:49:37AM -0500, Anurup M wrote:
>> +The Hisilicon SoC HiP05/06/07 chips consist of various independent system
>> +device PMU's such as L3 cache(L3C) and Miscellaneous Nodes(MN).
>> +These PMU devices are independent and have hardware logic to gather
>> +statistics and performance information.
>> +
>> +HiP0x chips are encapsulated by multiple CPU and IO die's. The CPU die is
>> +called as Super CPU cluster (SCCL) which includes 16 cpu-cores. Every SCCL
>> +is further grouped as CPU clusters (CCL) which includes 4 cpu-cores each.
>> +Each SCCL has 1 L3 cache and 1 MN units.
> Are there systems with multiple SCCLs? Or is there only one SCCL per
> system?
The HiP0x are encapsulated by multiple SCCL (CPU die) and SICL (IO die).
The HiP06 and HiP07 have two SCCLs.
>> +The L3 cache is shared by all CPU cores in a CPU die. The L3C has four banks
>> +(or instances). Each bank or instance of L3C has Eight 32-bit counter
>> +registers and also event control registers. The HiP05/06 chip L3 cache has
>> +22 statistics events. The HiP07 chip has 66 statistics events. These events
>> +are very useful for debugging.
> Is an L3C associated with a subset of physical memory (as with the ARM
> CCN's L3C), or is it associated with a set of CPUs (e.g. only those in
> a single SCCL) covering all physical memory (as with each CPU's L1 &
> L2)?
Yes the L3C is associated with the set of CPUs in a single SCCL covering
all physical memory.
The L3 cache in all the SCCLs share the complete physical memory.
Thanks,
Anurup
> Thanks,
> Mark.
^ permalink raw reply
* [PATCH 1/2] dma-mapping: let arch know origin of dma range passed to arch_setup_dma_ops()
From: Nikita Yushchenko @ 2017-01-12 5:52 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <30025121.yS4lyZEDrk@wuerfel>
>> diff --git a/drivers/staging/fsl-mc/bus/fsl-mc-bus.c b/drivers/staging/fsl-mc/bus/fsl-mc-bus.c
>> index 5ac373c..480b644 100644
>> --- a/drivers/staging/fsl-mc/bus/fsl-mc-bus.c
>> +++ b/drivers/staging/fsl-mc/bus/fsl-mc-bus.c
>> @@ -540,7 +540,7 @@ int fsl_mc_device_add(struct dprc_obj_desc *obj_desc,
>>
>> /* Objects are coherent, unless 'no shareability' flag set. */
>> if (!(obj_desc->flags & DPRC_OBJ_FLAG_NO_MEM_SHAREABILITY))
>> - arch_setup_dma_ops(&mc_dev->dev, 0, 0, NULL, true);
>> + arch_setup_dma_ops(&mc_dev->dev, 0, 0, false, NULL, true);
>>
>> /*
>> * The device-specific probe callback will get invoked by device_add()
>
> Why are these actually calling arch_setup_dma_ops() here in the first
> place? Are these all devices that are DMA masters without an OF node?
I don't know, but that's a different topic. This patch just adds
argument and sets it to false everywhere but in the location when range
should be definitely enforced.
>> @@ -126,6 +127,8 @@ void of_dma_configure(struct device *dev, struct device_node *np)
>> return;
>> }
>> dev_dbg(dev, "dma_pfn_offset(%#08lx)\n", offset);
>> +
>> + enforce_range = true;
>> }
>>
>> dev->dma_pfn_offset = offset;
>
> Hmm, I think when the dma-ranges are missing, we should either enforce
> a 32-bit mask, or disallow DMA completely. It's probably too late for
> the latter, I wish we had done this earlier in order to force everyone
> on ARM64 to have a valid dma-ranges property for any DMA master.
This can be done over time.
However the very idea of this version of patch is - keep working pieces
as-is, thus for now setting enforce_range to false in case of no defined
dma-ranges is intentional.
What I should re-check is - does rcar dtsi set dma-ranges, and add it if
it does not.
Nikita
^ permalink raw reply
* [PATCH 2/2] arm64: avoid increasing DMA masks above what hardware supports
From: Nikita Yushchenko @ 2017-01-12 5:53 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <2489599.dXme8sRkvp@wuerfel>
>> @@ -959,6 +990,15 @@ void arch_setup_dma_ops(struct device *dev, u64 dma_base, u64 size,
>> if (!dev->archdata.dma_ops)
>> dev->archdata.dma_ops = &swiotlb_dma_ops;
>>
>> + /*
>> + * Whatever the parent bus can set. A device must not set
>> + * a DMA mask larger than this.
>> + */
>> + if (enforce_range)
>> + dev->archdata.parent_dma_mask = size - 1;
>> + else
>> + dev->archdata.parent_dma_mask = DMA_BIT_MASK(64);
>> +
>> dev->archdata.dma_coherent = coherent;
>> __iommu_setup_dma_ops(dev, dma_base, size, iommu);
>>
>
> Could we just pass the mask instead of the size here?
We don't want to change API now.
Nikita
^ permalink raw reply
* [PATCH v3 02/10] dt-bindings: hisi: Add Hisilicon HiP05/06/07 Djtag dts bindings
From: Anurup M @ 2017-01-12 5:57 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20170110174515.GC24036@leverpostej>
On Tuesday 10 January 2017 11:15 PM, Mark Rutland wrote:
> On Thu, Jan 05, 2017 at 10:28:54AM +0530, Anurup M wrote:
>>
>> On Wednesday 04 January 2017 04:26 AM, Rob Herring wrote:
>>> On Mon, Jan 02, 2017 at 01:49:03AM -0500, Anurup M wrote:
>>>> From: Tan Xiaojun <tanxiaojun@huawei.com>
>>>>
>>>> Add Hisilicon HiP05/06/07 Djtag dts bindings for CPU and IO Die
>>>>
>>>> Signed-off-by: Tan Xiaojun <tanxiaojun@huawei.com>
>>>> Signed-off-by: Anurup M <anurup.m@huawei.com>
>>>> ---
>>>> .../devicetree/bindings/arm/hisilicon/djtag.txt | 41 ++++++++++++++++++++++
>>>> 1 file changed, 41 insertions(+)
>>>> create mode 100644 Documentation/devicetree/bindings/arm/hisilicon/djtag.txt
>>>>
>>>> diff --git a/Documentation/devicetree/bindings/arm/hisilicon/djtag.txt b/Documentation/devicetree/bindings/arm/hisilicon/djtag.txt
>>>> new file mode 100644
>>>> index 0000000..bbe8b45
>>>> --- /dev/null
>>>> +++ b/Documentation/devicetree/bindings/arm/hisilicon/djtag.txt
>>>> @@ -0,0 +1,41 @@
>>>> +The Hisilicon Djtag is an independent component which connects with some other
>>>> +components in the SoC by Debug Bus. The djtag is available in CPU and IO dies
>>>> +in the chip. The djtag controls access to connecting modules of CPU and IO
>>>> +dies.
>>>> +The various connecting components in CPU die (like L3 cache, L3 cache PMU etc.)
>>>> +are accessed by djtag during real time debugging. In IO die there are connecting
>>>> +components like RSA. These components appear as devices attached to djtag bus.
>>>> +
>>>> +Hisilicon HiP05/06/07 djtag for CPU and IO die
>>>> +Required properties:
>>>> + - compatible : The value should be as follows
>>>> + (a) "hisilicon,hip05-djtag-v1" for CPU and IO die which use v1 hw in
>>>> + HiP05 chipset.
>>> You don't need to distinguish the CPU and IO blocks?
>> The CPU and IO djtag nodes will have different base address(in reg
>> property).
>> There is no difference in handling of CPU and IO dies in the djtag driver.
>> So there is currently no need to distinguish them.
> It may still make sense to distinuguish them, even if the current djtag
> driver can handle them the same. Presumably clients of the djtag driver
> will poke CPU and IO djtag units differently.
Ok. I shall add "-cpu-/-io-" in the compatible field to distinguish.
e.g. "hisilicon,hip05-cpu-djtag-v1".
Thanks,
Anurup
> Thanks,
> Mark.
^ permalink raw reply
* [PATCH v3 00/10] perf: arm64: Support for Hisilicon SoC Hardware event counters
From: Anurup M @ 2017-01-12 6:27 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20170110174311.GB24036@leverpostej>
On Tuesday 10 January 2017 11:13 PM, Mark Rutland wrote:
> Hi,
>
> On Mon, Jan 02, 2017 at 01:47:52AM -0500, Anurup M wrote:
>> ToDo:
>> 1) The counter overflow handling is currently unsupported in this
>> patch series.
> From a quick scan of the patches, I see mention of an interrupt in a
> comment the driver, but there's noething in the DT binding.
>
> Is there an overflow interrupt at all?
>
> Or do you need to implement polling to avoid overflow?
>
> This is a prerequisite for merging the driver.
The HiP0x chips support counter overflow interrupt for L3C and MN.
The HiP05/06 interrupts in CPU die use Hisilicon mbigen-v1, but the
mbigen-v1
driver is not available in mainline. So the L3C and MN PMU in HiP05/06
cannot
support counter overflow in driver.
As the support for HiP05/06 are not the prime focus now. I shall remove
them
from the patch series and shall plan to include them later.
For HiP07, as it use mbigen-v2, which is in mainline, I shall include
the overflow
handling support in the next revision (V4 series).
Thanks,
Anurup
> Thanks,
> Mark.
^ permalink raw reply
* [PATCH 1/2] dma-mapping: let arch know origin of dma range passed to arch_setup_dma_ops()
From: Nikita Yushchenko @ 2017-01-12 6:33 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <764334db-3400-58c6-cc4b-3f7ce66daa27@cogentembedded.com>
12.01.2017 08:52, Nikita Yushchenko wrote:
>>> diff --git a/drivers/staging/fsl-mc/bus/fsl-mc-bus.c b/drivers/staging/fsl-mc/bus/fsl-mc-bus.c
>>> index 5ac373c..480b644 100644
>>> --- a/drivers/staging/fsl-mc/bus/fsl-mc-bus.c
>>> +++ b/drivers/staging/fsl-mc/bus/fsl-mc-bus.c
>>> @@ -540,7 +540,7 @@ int fsl_mc_device_add(struct dprc_obj_desc *obj_desc,
>>>
>>> /* Objects are coherent, unless 'no shareability' flag set. */
>>> if (!(obj_desc->flags & DPRC_OBJ_FLAG_NO_MEM_SHAREABILITY))
>>> - arch_setup_dma_ops(&mc_dev->dev, 0, 0, NULL, true);
>>> + arch_setup_dma_ops(&mc_dev->dev, 0, 0, false, NULL, true);
>>>
>>> /*
>>> * The device-specific probe callback will get invoked by device_add()
>>
>> Why are these actually calling arch_setup_dma_ops() here in the first
>> place? Are these all devices that are DMA masters without an OF node?
>
> I don't know, but that's a different topic. This patch just adds
> argument and sets it to false everywhere but in the location when range
> should be definitely enforced.
>
>>> @@ -126,6 +127,8 @@ void of_dma_configure(struct device *dev, struct device_node *np)
>>> return;
>>> }
>>> dev_dbg(dev, "dma_pfn_offset(%#08lx)\n", offset);
>>> +
>>> + enforce_range = true;
>>> }
>>>
>>> dev->dma_pfn_offset = offset;
>>
>> Hmm, I think when the dma-ranges are missing, we should either enforce
>> a 32-bit mask, or disallow DMA completely. It's probably too late for
>> the latter, I wish we had done this earlier in order to force everyone
>> on ARM64 to have a valid dma-ranges property for any DMA master.
>
> This can be done over time.
>
> However the very idea of this version of patch is - keep working pieces
> as-is, thus for now setting enforce_range to false in case of no defined
> dma-ranges is intentional.
What we can do is - check bus width (as it is defined in DT) and set
enforce_range to true if bus is 32-bit
> What I should re-check is - does rcar dtsi set dma-ranges, and add it if
> it does not.
It does not, will have to add.
In DT bus is defined as 64-bit. But looks like physically it is 32-bit.
Maybe DT needs fixing.
^ permalink raw reply
* [PATCH] arm64: dts: exynos: Replace small letter of base address/offset on Exynos5433
From: Krzysztof Kozlowski @ 2017-01-12 6:34 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAGTfZH0H_kA9cRPG4Vqh3iLZncfXqfKDFiSYEXV1zp+9yFP25Q@mail.gmail.com>
On Wed, Jan 11, 2017 at 11:22 PM, Chanwoo Choi <cwchoi00@gmail.com> wrote:
> 2017-01-12 1:26 GMT+09:00 Krzysztof Kozlowski <krzk@kernel.org>:
>> On Wed, Jan 11, 2017 at 09:55:48AM +0900, Chanwoo Choi wrote:
>>> This patch replaces the small letter of base address, offset and hex value
>>> with the capital letter to keep the consistency on Exynos5433.
>>>
>>> Signed-off-by: Chanwoo Choi <cw00.choi@samsung.com>
>>> ---
>>> arch/arm64/boot/dts/exynos/exynos5433.dtsi | 14 +++++++-------
>>> 1 file changed, 7 insertions(+), 7 deletions(-)
>>>
>>> diff --git a/arch/arm64/boot/dts/exynos/exynos5433.dtsi b/arch/arm64/boot/dts/exynos/exynos5433.dtsi
>>> index abaf6b4d599d..d7ed1a68b6fd 100644
>>> --- a/arch/arm64/boot/dts/exynos/exynos5433.dtsi
>>> +++ b/arch/arm64/boot/dts/exynos/exynos5433.dtsi
>>> @@ -231,7 +231,7 @@
>>> compatible = "arm,psci";
>>> method = "smc";
>>> cpu_off = <0x84000002>;
>>> - cpu_on = <0xC4000003>;
>>> + cpu_on = <0xc4000003>;
>>
>> There is no point of such "improvements". This is just unnecessary
>> churn.
>>
>> Sometimes such things are accepted as part of some bigger work (vide
>> recent Andrzej's sysmmu for HDMI/TV). But on its own? No sense at all.
>
> Do you mean that this patch is not reasonable? or
> The modification of cpu_on property is only not reasonable?
>
> It is simple for the consistency to use the hex value in dts file.
The patch is not reasonable (as sent alone).
Best regards,
Krzysztof
^ permalink raw reply
* [PATCH 1/1] iommu/arm-smmu: Fix for ThunderX erratum #27704
From: Tomasz Nowicki @ 2017-01-12 6:41 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <2c048126-a4d6-16af-987a-3174401a3960@arm.com>
On 11.01.2017 13:19, Robin Murphy wrote:
> On 11/01/17 11:51, Tomasz Nowicki wrote:
>> The goal of erratum #27704 workaround was to make sure that ASIDs and VMIDs
>> are unique across all SMMU instances on affected Cavium systems.
>>
>> Currently, the workaround code partitions ASIDs and VMIDs by increasing
>> global cavium_smmu_context_count which in turn becomes the base ASID and VMID
>> value for the given SMMU instance upon the context bank initialization.
>>
>> For systems with multiple SMMU instances this approach implies the risk
>> of crossing 8-bit ASID, like for CN88xx capable of 4 SMMUv2, 128 context bank each:
>> SMMU_0 (0-127 ASID RANGE)
>> SMMU_1 (127-255 ASID RANGE)
>> SMMU_2 (256-383 ASID RANGE) <--- crossing 8-bit ASID
>> SMMU_3 (384-511 ASID RANGE) <--- crossing 8-bit ASID
>
> I could swear that at some point in the original discussion it was said
> that the TLBs were only shared between pairs of SMMUs, so in fact 0/1
> and 2/3 are independent of each other
Indeed TLBs are only shared between pairs of SMMUs but the workaround
makes sure ASIDs are unique across all SMMU instances so we do not have
to bother about SMMUs probe order.
- out of interest, have you
> managed to hit an actual problem in practice or is this patch just by
> inspection?
Except SMMU0/1 devices all other devices under other SMMUs will fail on
guest power off/on. Since we try to invalidate tlb with 16bit ASID but
we actually have 8 bit zero padded 16 bit entry.
>
> Of course, depending on the SMMUs to probe in the right order isn't
> particularly robust, so it's still probably a worthwhile change.
>
>> Since we use 8-bit ASID now we effectively misconfigure ASID[15:8] bits for
>> SMMU_CBn_TTBRm register. Also, we still use non-zero ASID[15:8] bits
>> upon context invalidation. This patch adds 16-bit ASID support for stage-1
>> AArch64 contexts for Cavium SMMUv2 model so that we use ASIDs consistently.
>>
>> Signed-off-by: Tomasz Nowicki <tn@semihalf.com>
>> ---
>> drivers/iommu/arm-smmu.c | 4 ++++
>> 1 file changed, 4 insertions(+)
>>
>> diff --git a/drivers/iommu/arm-smmu.c b/drivers/iommu/arm-smmu.c
>> index a60cded..ae8f059 100644
>> --- a/drivers/iommu/arm-smmu.c
>> +++ b/drivers/iommu/arm-smmu.c
>> @@ -260,6 +260,7 @@ enum arm_smmu_s2cr_privcfg {
>>
>> #define TTBCR2_SEP_SHIFT 15
>> #define TTBCR2_SEP_UPSTREAM (0x7 << TTBCR2_SEP_SHIFT)
>> +#define TTBCR2_AS (1 << 4)
>>
>> #define TTBRn_ASID_SHIFT 48
>>
>> @@ -778,6 +779,9 @@ static void arm_smmu_init_context_bank(struct arm_smmu_domain *smmu_domain,
>> reg = pgtbl_cfg->arm_lpae_s1_cfg.tcr;
>> reg2 = pgtbl_cfg->arm_lpae_s1_cfg.tcr >> 32;
>> reg2 |= TTBCR2_SEP_UPSTREAM;
>> + if (smmu->model == CAVIUM_SMMUV2 &&
>
> I'd be inclined to say "smmu->version == ARM_SMMU_V2" there, rather than
> make it Cavium-specific - we enable 16-bit VMID unconditionally where
> supported, so I don't see any reason not to handle 16-bit ASIDs in the
> same manner.
I agree, I will enable 16-bit ASID for ARM_SMMU_V2.
>
>> + cfg->fmt == ARM_SMMU_CTX_FMT_AARCH64)
>> + reg2 |= TTBCR2_AS;
>> }
>> if (smmu->version > ARM_SMMU_V1)
>> writel_relaxed(reg2, cb_base + ARM_SMMU_CB_TTBCR2);
>>
>
> Either way:
>
> Reviewed-by: Robin Murphy <robin.murphy@arm.com>
Thanks Robin!
Tomasz
^ permalink raw reply
* [PATCH v2 3/3] phy: rockchip-inno-usb2: Set EXTCON_USB when EXTCON_CHG_USB_SDP was set
From: Baolin Wang @ 2017-01-12 6:43 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAMz4kuJP9Q7Ly4uRBjCFU32YzbVbnsGyk+wHc+M=g8W=uDBsEQ@mail.gmail.com>
On 3 January 2017 at 13:54, Baolin Wang <baolin.wang@linaro.org> wrote:
> Hi Kison and Heiko,
>
> On 21 December 2016 at 16:12, Baolin Wang <baolin.wang@linaro.org> wrote:
>> According to the documentation, we should set the EXTCON_USB when
>> one SDP charger connector was reported.
>>
>> Signed-off-by: Baolin Wang <baolin.wang@linaro.org>
>> Reviewed-by: Chanwoo Choi <cw00.choi@samsung.com>
>
> Could you apply this patch if there are no other comments? Thanks.
Ping?
--
Baolin.wang
Best Regards
^ permalink raw reply
* [PATCH] ARM: defconfig: include QCOM_EBI2 in multi_v7
From: Linus Walleij @ 2017-01-12 7:04 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <cee567ef-adc3-eb3f-81bb-e8a678b35fa8@codeaurora.org>
On Thu, Jan 12, 2017 at 2:01 AM, Stephen Boyd <sboyd@codeaurora.org> wrote:
> On 01/11/2017 07:22 AM, Linus Walleij wrote:
>> On Tue, Jan 10, 2017 at 7:02 PM, Olof Johansson <olof@lixom.net> wrote:
>>> On Tue, Jan 10, 2017 at 2:09 AM, Linus Walleij <linus.walleij@linaro.org> wrote:
>>>> This adds the Qualcomm External Bus Interface 2 to the multi_v7
>>>> defconfig: it is hard for users to realize that this is a
>>>> required driver for getting things like ethernet, and a necessary
>>>> prerequisite to get the external bus discoverable on the
>>>> MSM8660/APQ8060 machines.
>>> Is it the kind of option that should really be selected through
>>> Kconfig instead for those platforms?
>>
>> Stephen Boyd question.
>>
>> AFAIK the ambition is to go with the platform to have zero
>> stuff in mach-qcom/* and thus it all becomes a defconfig
>> thing.
>
> It could be made a 'default ARCH_QCOM' type of thing. Then the config
> doesn't need an update unless you want to turn it off.
OK I will do that.
Olof: let's scrap this patch.
Yours,
Linus Walleij
^ permalink raw reply
* [PATCH] bus: qcom_ebi2: default y if ARCH_QCOM
From: Linus Walleij @ 2017-01-12 7:08 UTC (permalink / raw)
To: linux-arm-kernel
Since we want this external bus to be available on multi_v7 builds,
set to default ARCH_QCOM so we get it selected whenever QCOM is
enabled.
Suggested-by: Stephen Boyd <sboyd@codeaurora.org>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
---
Andy: I guess you could queue this to ARM SoC, they seem so manage
drivers/bus from there.
---
drivers/bus/Kconfig | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/bus/Kconfig b/drivers/bus/Kconfig
index b9e8cfc93c7e..0a52da439abf 100644
--- a/drivers/bus/Kconfig
+++ b/drivers/bus/Kconfig
@@ -112,6 +112,7 @@ config QCOM_EBI2
bool "Qualcomm External Bus Interface 2 (EBI2)"
depends on HAS_IOMEM
depends on ARCH_QCOM || COMPILE_TEST
+ default ARCH_QCOM
help
Say y here to enable support for the Qualcomm External Bus
Interface 2, which can be used to connect things like NAND Flash,
--
2.9.3
^ permalink raw reply related
* [PATCH v2 5/5] ARM: dts: Add LEGO MINDSTORMS EV3 dts
From: Sekhar Nori @ 2017-01-12 7:39 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1dd57ac3-554f-7d66-97b0-b76c3ddc7854@lechnology.com>
On Wednesday 11 January 2017 09:55 PM, David Lechner wrote:
>>> +&spi0 {
>>> + status = "okay";
>>> + pinctrl-names = "default";
>>> + pinctrl-0 = <&spi0_pins>, <&spi0_cs0_pin>, <&spi0_cs3_pin>;
>>> +
>>> + flash at 0 {
>>> + compatible = "n25q128a13", "jedec,spi-nor";
>>> + reg = <0>;
>>> + spi-max-frequency = <50000000>;
>>> + ti,spi-wdelay = <8>;
>>> +
>>> + /* Partitions are based on the official firmware from LEGO */
>>> + partitions {
>>> + #address-cells = <1>;
>>> + #size-cells = <1>;
>>> + partition at 0 {
>>> + label = "U-Boot";
>>> + reg = <0 0x40000>;
>>> + };
>>> +
>>> + partition at 40000 {
>>> + label = "U-Boot Env";
>>> + reg = <0x40000 0x10000>;
>>> + };
>>> +
>>> + partition at 50000 {
>>> + label = "Kernel";
>>> + reg = <0x50000 0x200000>;
>>> + };
>>> +
>>> + partition at 250000 {
>>> + label = "Filesystem";
>>> + reg = <0x250000 0xa50000>;
>>> + };
>>> +
>>> + partition at cb0000 {
>>> + label = "Storage";
>>> + reg = <0xcb0000 0x2f0000>;
>>> + };
>>> + };
>>> + };
>>> +
>>> + adc at 3 {
>>> + compatible = "ti-ads7957";
>>
>> So looks like this works because of_register_spi_device() sets up
>> modalias of spi device from compatible string. I am fine with it, just
>> highlighting it here to make sure this is acceptable practice. I did not
>> really find any precedence for using SPI device name as compatible
>> property in existing DTS files.
>
> Indeed. It looks like this sort of "trivial" device binding is just used
> for i2c devices. I will submit some patches to add proper device tree
> bindings and change this to "ti,ads7957".
Alright, if you are going to do that, then I suggest you respin this
patch with the adc node dropped for now. That way we can ensure basic
board support in v4.11. If dependencies pan out, the adc can go in too
as a separate patch.
Thanks,
Sekhar
^ permalink raw reply
* [PATCH v8 00/18] KVM PCIe/MSI passthrough on ARM/ARM64 and IOVA reserved regions
From: Auger Eric @ 2017-01-12 7:40 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <AM5PR0401MB254547FE747461B3332721FC9A790@AM5PR0401MB2545.eurprd04.prod.outlook.com>
Hi Bharat,
On 12/01/2017 04:59, Bharat Bhushan wrote:
>
>
>> -----Original Message-----
>> From: Eric Auger [mailto:eric.auger at redhat.com]
>> Sent: Wednesday, January 11, 2017 3:12 PM
>> To: eric.auger at redhat.com; eric.auger.pro at gmail.com;
>> christoffer.dall at linaro.org; marc.zyngier at arm.com;
>> robin.murphy at arm.com; alex.williamson at redhat.com;
>> will.deacon at arm.com; joro at 8bytes.org; tglx at linutronix.de;
>> jason at lakedaemon.net; linux-arm-kernel at lists.infradead.org
>> Cc: kvm at vger.kernel.org; drjones at redhat.com; linux-
>> kernel at vger.kernel.org; pranav.sawargaonkar at gmail.com;
>> iommu at lists.linux-foundation.org; punit.agrawal at arm.com; Diana Madalina
>> Craciun <diana.craciun@nxp.com>; gpkulkarni at gmail.com;
>> shankerd at codeaurora.org; Bharat Bhushan <bharat.bhushan@nxp.com>;
>> geethasowjanya.akula at gmail.com
>> Subject: [PATCH v8 00/18] KVM PCIe/MSI passthrough on ARM/ARM64 and
>> IOVA reserved regions
>>
>> Following LPC discussions, we now report reserved regions through the
>> iommu-group sysfs reserved_regions attribute file.
>>
>> Reserved regions are populated through the IOMMU get_resv_region
>> callback (former get_dm_regions), now implemented by amd-iommu, intel-
>> iommu and arm-smmu:
>> - the intel-iommu reports the [0xfee00000 - 0xfeefffff] MSI window
>> as a reserved region and RMRR regions as direct-mapped regions.
>> - the amd-iommu reports device direct mapped regions, the MSI region
>> and HT regions.
>> - the arm-smmu reports the MSI window (arbitrarily located at
>> 0x8000000 and 1MB large).
>>
>> Unsafe interrupt assignment is tested by enumerating all MSI irq domains
>> and checking MSI remapping is supported in the above hierarchy.
>> This check is done in case we detect the iommu translates MSI (an
>> IOMMU_RESV_MSI window exists). Otherwise the IRQ remapping capability
>> is checked at IOMMU level. Obviously this is a defensive IRQ safety
>> assessment: Assuming there are several MSI controllers in the system and at
>> least one does not implement IRQ remapping, the assignment will be
>> considered as unsafe (even if this controller is not acessible from the
>> assigned devices).
>>
>> The series first patch stems from Robin's branch:
>> http://linux-arm.org/git?p=linux-
>> rm.git;a=shortlog;h=refs/heads/iommu/misc
>>
>> Best Regards
>>
>> Eric
>>
>> Git: complete series available at
>> https://github.com/eauger/linux/tree/v4.10-rc3-reserved-v8
>
> This series is tested on NXP platform, if you want you can add my tested by
> Tested-by: Bharat Bhushan <bharat.bhushan@nxp.com>
Thank you for this!
Best Regards
Eric
>
> Thanks
> -Bharat
>
>>
>> istory:
>>
>> PATCHv7 -> PATCHv8
>> - take into account Marc's comments and apply his R-b
>> - remove iommu_group_remove_file call in iommu_group_release
>> - add Will's A-b
>> - removed [PATCH v7 01/19] iommu/dma: Implement PCI allocation
>> optimisation and updated iommu/dma: Allow MSI-only cookies
>> as per Robin's indications
>>
>> PATCHv6 -> PATCHv7:
>> - iommu/dma: Implement PCI allocation optimisation was added to apply
>> iommu/dma: Allow MSI-only cookies
>> - report Intel RMRR as direct-mapped regions
>> - report the type in the iommu group sysfs reserved_regions file
>> - do not merge regions of different types when building the list
>> of reserved regions
>> - intgeration Robin's "iommu/dma: Allow MSI-only cookies" last
>> version
>> - update Documentation/ABI/testing/sysfs-kernel-iommu_groups
>> - rename IOMMU_RESV_NOMAP into IOMMU_RESV_RESERVED
>>
>> PATCHv5 -> PATCHv6
>> - Introduce IRQ_DOMAIN_FLAG_MSI as suggested by Marc
>> - irq_domain_is_msi, irq_domain_is_msi_remap,
>> irq_domain_hierarchical_is_msi_remap,
>> - set IRQ_DOMAIN_FLAG_MSI in msi_create_irq_domain
>> - fix compil issue on i386
>> - rework test at VFIO level
>>
>> RFCv4 -> PATCHv5
>> - fix IRQ security assessment by looking at irq domain parents
>> - check DOMAIN_BUS_FSL_MC_MSI irq domains
>> - AMD MSI and HT regions are exposed in iommu group sysfs
>>
>> RFCv3 -> RFCv4:
>> - arm-smmu driver does not register PCI host bridge windows as
>> reserved regions anymore
>> - Implement reserved region get/put callbacks also in arm-smmuv3
>> - take the iommu_group lock on iommu_get_group_resv_regions
>> - add a type field in iommu_resv_region instead of using prot
>> - init the region list_head in iommu_alloc_resv_region, also
>> add type parameter
>> - iommu_insert_resv_region manage overlaps and sort reserved
>> windows
>> - address IRQ safety assessment by enumerating all the MSI irq
>> domains and checking the MSI_REMAP flag
>> - update Documentation/ABI/testing/sysfs-kernel-iommu_groups
>>
>> RFC v2 -> v3:
>> - switch to an iommu-group sysfs API
>> - use new dummy allocator provided by Robin
>> - dummy allocator initialized by vfio-iommu-type1 after enumerating
>> the reserved regions
>> - at the moment ARM MSI base address/size is left unchanged compared
>> to v2
>> - we currently report reserved regions and not usable IOVA regions as
>> requested by Alex
>>
>> RFC v1 -> v2:
>> - fix intel_add_reserved_regions
>> - add mutex lock/unlock in vfio_iommu_type1
>>
>>
>> Eric Auger (17):
>> iommu: Rename iommu_dm_regions into iommu_resv_regions
>> iommu: Add a new type field in iommu_resv_region
>> iommu: iommu_alloc_resv_region
>> iommu: Only map direct mapped regions
>> iommu: iommu_get_group_resv_regions
>> iommu: Implement reserved_regions iommu-group sysfs file
>> iommu/vt-d: Implement reserved region get/put callbacks
>> iommu/amd: Declare MSI and HT regions as reserved IOVA regions
>> iommu/arm-smmu: Implement reserved region get/put callbacks
>> iommu/arm-smmu-v3: Implement reserved region get/put callbacks
>> irqdomain: Add irq domain MSI and MSI_REMAP flags
>> genirq/msi: Set IRQ_DOMAIN_FLAG_MSI on MSI domain creation
>> irqdomain: irq_domain_check_msi_remap
>> irqchip/gicv3-its: Sets IRQ_DOMAIN_FLAG_MSI_REMAP
>> vfio/type1: Allow transparent MSI IOVA allocation
>> vfio/type1: Check MSI remapping at irq domain level
>> iommu/arm-smmu: Do not advertise IOMMU_CAP_INTR_REMAP anymore
>>
>> Robin Murphy (1):
>> iommu/dma: Allow MSI-only cookies
>>
>> .../ABI/testing/sysfs-kernel-iommu_groups | 12 ++
>> drivers/iommu/amd_iommu.c | 54 ++++---
>> drivers/iommu/arm-smmu-v3.c | 30 +++-
>> drivers/iommu/arm-smmu.c | 30 +++-
>> drivers/iommu/dma-iommu.c | 119 +++++++++++---
>> drivers/iommu/intel-iommu.c | 92 ++++++++---
>> drivers/iommu/iommu.c | 177 +++++++++++++++++++--
>> drivers/irqchip/irq-gic-v3-its.c | 1 +
>> drivers/vfio/vfio_iommu_type1.c | 37 ++++-
>> include/linux/dma-iommu.h | 6 +
>> include/linux/iommu.h | 46 ++++--
>> include/linux/irqdomain.h | 36 +++++
>> kernel/irq/irqdomain.c | 36 +++++
>> kernel/irq/msi.c | 4 +-
>> 14 files changed, 587 insertions(+), 93 deletions(-)
>>
>> --
>> 1.9.1
>
^ permalink raw reply
* [PATCH v2 3/3] phy: rockchip-inno-usb2: Set EXTCON_USB when EXTCON_CHG_USB_SDP was set
From: Kishon Vijay Abraham I @ 2017-01-12 8:18 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAMz4ku+X8v2HH5L_fS60naNTqR1ZFKYeWuXuHqjg0UsHQq1dsQ@mail.gmail.com>
Hi,
On Thursday 12 January 2017 12:13 PM, Baolin Wang wrote:
> On 3 January 2017 at 13:54, Baolin Wang <baolin.wang@linaro.org> wrote:
>> Hi Kison and Heiko,
>>
>> On 21 December 2016 at 16:12, Baolin Wang <baolin.wang@linaro.org> wrote:
>>> According to the documentation, we should set the EXTCON_USB when
>>> one SDP charger connector was reported.
>>>
>>> Signed-off-by: Baolin Wang <baolin.wang@linaro.org>
>>> Reviewed-by: Chanwoo Choi <cw00.choi@samsung.com>
>>
>> Could you apply this patch if there are no other comments? Thanks.
Does it fix something? Or else it can go in the next merge window.
Thanks
Kishon
^ permalink raw reply
* [PATCH 0/4] ARM: dts: mt7623: Add initial Geek Force support
From: John Crispin @ 2017-01-12 8:23 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <3fecb422-8185-7ee0-c203-2bfdc4fd1393@phrozen.org>
Hi Andreas,
had a look last night why the ethernet dtsi was not added and it
obviously was not added as we were waiting for the clk-mt2701 to be
merged. the ethernet dtsi will have phandles pointing at the clk nodes
which did not exist at the time. same is true for the PWM code.
i sat down last night and worked out what pending patches i still have
for mt7623 and out of the ~80 required to get v4.4 working i only need
around 10 for v4.10-rc1.
i started to rebase these patches last night and will have time to test
them tomorrow or early next week. as the pwrap node alone is around 200
lines of devicetree we need to figure out a way to add this to the dts
files without duplicating it. i'll try to post a series early next week
that we can then discuss and rebase your geekboard patches on.
John
^ permalink raw reply
* [PATCH 0/4] video: ARM CLCD: add support of an optional GPIO to enable panel
From: Linus Walleij @ 2017-01-12 8:27 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <330598fa-d331-3695-b0a2-3590059e2be4@mleia.com>
On Thu, Jan 12, 2017 at 1:05 AM, Vladimir Zapolskiy <vz@mleia.com> wrote:
> On 01/11/2017 05:16 PM, Linus Walleij wrote:
>> On Tue, Jan 10, 2017 at 2:47 PM, Vladimir Murzin
>> <vladimir.murzin@arm.com> wrote:
>>
>>> In another thread Benjamin pointed at patch [1] in drm/kms part for noMMU.
>>>
>>> [1] https://cgit.freedesktop.org/drm/drm-misc/commit/?id=62a0d98a188cc4ebd8ea54b37d274ec20465e464
>>
>> Problem solved?
>>
>> Vladimir: I do not require in any way that you create a CLCD driver for DRM,
>> I just think it would be very very nice...
>>
>
> I have no other option, this series is unreviewed and thus unlikely it will
> be applied, still a panel PCB on my board needs power management support.
Hm I can ACK it I guess, but mergeing it into an unmaintained subsystem
is another issue, just not very optimal. If you get it working on your system
I can look into migrating all the old users to DRM as well.
Yours,
Linus Walleij
^ permalink raw reply
* [PATCH v2 3/3] phy: rockchip-inno-usb2: Set EXTCON_USB when EXTCON_CHG_USB_SDP was set
From: Baolin Wang @ 2017-01-12 8:37 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <58773BC8.2050808@ti.com>
Hi,
On 12 January 2017 at 16:18, Kishon Vijay Abraham I <kishon@ti.com> wrote:
> Hi,
>
> On Thursday 12 January 2017 12:13 PM, Baolin Wang wrote:
>> On 3 January 2017 at 13:54, Baolin Wang <baolin.wang@linaro.org> wrote:
>>> Hi Kison and Heiko,
>>>
>>> On 21 December 2016 at 16:12, Baolin Wang <baolin.wang@linaro.org> wrote:
>>>> According to the documentation, we should set the EXTCON_USB when
>>>> one SDP charger connector was reported.
>>>>
>>>> Signed-off-by: Baolin Wang <baolin.wang@linaro.org>
>>>> Reviewed-by: Chanwoo Choi <cw00.choi@samsung.com>
>>>
>>> Could you apply this patch if there are no other comments? Thanks.
>
> Does it fix something? Or else it can go in the next merge window.
Just fix the correct usage of EXTCON_CHG_USB_SDP connector. It's okay
for me that it can go in the next merge window. Thanks.
--
Baolin.wang
Best Regards
^ permalink raw reply
* [PATCH v5 0/4] drm/dp: Implement CRC debugfs API
From: Tomeu Vizoso @ 2017-01-12 8:58 UTC (permalink / raw)
To: linux-arm-kernel
Hi,
this series builds up on the API for exposing captured CRCs through
debugfs.
It adds new DP helpers for starting and stopping CRC capture and gets
the Rockchip driver to use it.
Also had to add a connector backpointer to the drm_dp_aux struct so we could
wait for the right vblank and store the CRCs afterwards, I will be glad
to hear about better alternatives.
With these patches, tests in IGT such as kms_pipe_crc_basic and
kms_plane do pass on RK3288.
In this v5, "drm/dp: add helpers for capture of frame CRCs" has gone
back to the more explicit way of just retrying once.
Also, I have left the connector back pointer in the AUX structure, as on
IRC nor danvet nor me could find a good reason to change it.
Thanks,
Tomeu
Tomeu Vizoso (4):
drm/bridge: analogix_dp: set connector to drm_dp_aux
drm/dp: add helpers for capture of frame CRCs
drm/bridge: analogix_dp: add helpers for capture of frame CRCs
drm/rockchip: Implement CRC debugfs API
drivers/gpu/drm/bridge/analogix/analogix_dp_core.c | 34 ++++--
drivers/gpu/drm/drm_dp_helper.c | 124 +++++++++++++++++++++
drivers/gpu/drm/rockchip/rockchip_drm_vop.c | 42 +++++++
include/drm/bridge/analogix_dp.h | 3 +
include/drm/drm_dp_helper.h | 7 ++
5 files changed, 202 insertions(+), 8 deletions(-)
--
2.9.3
^ permalink raw reply
* [PATCH v5 4/4] drm/rockchip: Implement CRC debugfs API
From: Tomeu Vizoso @ 2017-01-12 8:58 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20170112085844.19878-1-tomeu.vizoso@collabora.com>
Implement the .set_crc_source() callback and call the DP helpers
accordingly to start and stop CRC capture.
This is only done if this CRTC is currently using the eDP connector.
v3: Remove superfluous check on rockchip_crtc_state->output_type
Signed-off-by: Tomeu Vizoso <tomeu.vizoso@collabora.com>
---
drivers/gpu/drm/rockchip/rockchip_drm_vop.c | 42 +++++++++++++++++++++++++++++
1 file changed, 42 insertions(+)
diff --git a/drivers/gpu/drm/rockchip/rockchip_drm_vop.c b/drivers/gpu/drm/rockchip/rockchip_drm_vop.c
index fb5f001f51c3..6e5eb1aa182a 100644
--- a/drivers/gpu/drm/rockchip/rockchip_drm_vop.c
+++ b/drivers/gpu/drm/rockchip/rockchip_drm_vop.c
@@ -19,6 +19,7 @@
#include <drm/drm_crtc_helper.h>
#include <drm/drm_flip_work.h>
#include <drm/drm_plane_helper.h>
+#include <drm/bridge/analogix_dp.h>
#include <linux/kernel.h>
#include <linux/module.h>
@@ -1105,6 +1106,46 @@ static void vop_crtc_destroy_state(struct drm_crtc *crtc,
kfree(s);
}
+static struct drm_connector *vop_get_edp_connector(struct vop *vop)
+{
+ struct drm_crtc *crtc = &vop->crtc;
+ struct drm_connector *connector;
+
+ mutex_lock(&crtc->dev->mode_config.mutex);
+ drm_for_each_connector(connector, crtc->dev)
+ if (connector->connector_type == DRM_MODE_CONNECTOR_eDP) {
+ mutex_unlock(&crtc->dev->mode_config.mutex);
+ return connector;
+ }
+ mutex_unlock(&crtc->dev->mode_config.mutex);
+
+ return NULL;
+}
+
+static int vop_crtc_set_crc_source(struct drm_crtc *crtc,
+ const char *source_name, size_t *values_cnt)
+{
+ struct vop *vop = to_vop(crtc);
+ struct rockchip_crtc_state *s = to_rockchip_crtc_state(crtc->state);
+ struct drm_connector *connector;
+ int ret;
+
+ connector = vop_get_edp_connector(vop);
+ if (!connector)
+ return -EINVAL;
+
+ *values_cnt = 3;
+
+ if (source_name && strcmp(source_name, "auto") == 0)
+ ret = analogix_dp_start_crc(connector);
+ else if (!source_name)
+ ret = analogix_dp_stop_crc(connector);
+ else
+ ret = -EINVAL;
+
+ return ret;
+}
+
static const struct drm_crtc_funcs vop_crtc_funcs = {
.set_config = drm_atomic_helper_set_config,
.page_flip = drm_atomic_helper_page_flip,
@@ -1112,6 +1153,7 @@ static const struct drm_crtc_funcs vop_crtc_funcs = {
.reset = vop_crtc_reset,
.atomic_duplicate_state = vop_crtc_duplicate_state,
.atomic_destroy_state = vop_crtc_destroy_state,
+ .set_crc_source = vop_crtc_set_crc_source,
};
static void vop_fb_unref_worker(struct drm_flip_work *work, void *val)
--
2.9.3
^ permalink raw reply related
* [PATCH v7 0/4] arm64: arch_timer: Add workaround for hisilicon-161601 erratum
From: Marc Zyngier @ 2017-01-12 9:11 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <6c33e4e9-6472-4738-aea2-55dcaab3a94f@huawei.com>
On 12/01/17 04:23, Ding Tianhong wrote:
> Hi Marc:
>
> How about this v7, if any suggestions very grateful.
It's been less than 5 days since you posted this. I'll get to it once I
finish reviewing all the other patches that are sitting in the queue
right before yours.
Thanks,
M.
--
Jazz is not dead. It just smells funny...
^ permalink raw reply
* [PATCHv3 3/5] pinctrl: mvebu: pinctrl driver for 98DX3236 SoC
From: Chris Packham @ 2017-01-12 9:13 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <95cb4240-e77b-5eaa-1920-4d9e26028038@gmail.com>
On 12/01/17 09:56, Sebastian Hesselbarth wrote:
> On 01/11/2017 03:44 PM, Linus Walleij wrote:
>> On Fri, Jan 6, 2017 at 5:15 AM, Chris Packham
>> <chris.packham@alliedtelesis.co.nz> wrote:
>>
>>> From: Kalyan Kinthada <kalyan.kinthada@alliedtelesis.co.nz>
>>>
>>> This pinctrl driver supports the 98DX3236, 98DX3336 and 98DX4251 SoCs
>>> from Marvell.
>>>
>>> Signed-off-by: Kalyan Kinthada <kalyan.kinthada@alliedtelesis.co.nz>
>>> Signed-off-by: Chris Packham <chris.packham@alliedtelesis.co.nz>
>>
>> I am waiting for an ACK or comment from the maintainers on
>> this patch. Sebastian?
>
> Sorry for the ignorance.
>
> I don't have the patch to reply to inline, but:
>
> - In the driver MPP_MODE2, spi0 there is a typo "csk" instead of "sck".
> - MPP_MODE5 binding "dev","bootcs" and driver "dev","bootcs0" differ.
> - MPP_MODE6 binding "gpio" and driver "gpo" differ.
> - MPP_MODE17 binding "dev","clk" and driver "dev","clkout" differ.
> - MPP_MODE19 binding mentiones "dev","rb" but driver does not.
> - MPP_MODE20 binding "gpio" and driver "gpo" differ.
> - MPP_MODE20 binding "dev","we" and driver "dev","we0" differ.
> - MPP_MODE21 through MPP_MODE30 binding "gpio" and driver "gpo" differ.
> - remove spaces before "0, 0" in mv98dx3236_mpp_gpio_ranges.
>
> Most of it is cosmetic stuff, so if you fix it feel free to add my
>
> Acked-by: Sebastian Hesselbarth <sebastian.hesselbarth@gmail.com>
Hi Sebastian,
Hopefully I can get a v4 out with the above fixed soon.
One point on "gpio" vs "gpo" this one isn't a typo. Some of these pins
can be driven as outputs but can't be used as inputs. From a pinctrl
driver point of view there is no difference but I did want to convey
that from a system design point of view if you really need something to
be an input you shouldn't use one of these pins. This is also noted in
the datasheets so it doesn't necessarily need repeating. If you still
want me to use "gpio" in the code and binding I'm happy to do so.
^ permalink raw reply
* [PATCH v2 00/11] add support for VBUS max current and min voltage limits AXP20X and AXP22X PMICs
From: Maxime Ripard @ 2017-01-12 9:28 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161209110419.28981-1-quentin.schulz@free-electrons.com>
On Fri, Dec 09, 2016 at 12:04:08PM +0100, Quentin Schulz wrote:
> The X-Powers AXP209 and AXP20X PMICs are able to set a limit for the
> VBUS power supply for both max current and min voltage supplied. This
> series of patch adds the possibility to set these limits from sysfs.
>
> Also, the AXP223 PMIC shares most of its behaviour with the AXP221 but
> the former can set the VBUS power supply max current to 100mA, unlike
> the latter. The AXP223 VBUS power supply driver used to probe on the
> AXP221 compatible. This series of patch introduces a new compatible for
> the AXP223 to be able to set the current max limit to 100mA.
>
> With that new compatible, boards having the AXP223 see their DT updated
> to use the VBUS power supply driver with the correct compatible.
>
> This series of patch also migrates from of_device_is_compatible function
> to the data field of of_device_id to identify the compatible used to
> probe. This improves the code readability.
>
> Mostly cosmetic changes in v2 and adding volatile and writeable regs to
> AXP20X and AXP22X MFD cells for the VBUS power supply driver.
Applied all the DT patches. I also fixed all the prefixes. Please make
sure to look at what prefixes are used by a given subsystem next time.
Thanks!
Maxime
--
Maxime Ripard, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 801 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20170112/8fc64b9f/attachment.sig>
^ permalink raw reply
* kvm: deadlock in kvm_vgic_map_resources
From: Marc Zyngier @ 2017-01-12 9:32 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CACT4Y+YRg=H0F-_QTtPf0--o85sQCb__j=V25tPchx9ycYtyKg@mail.gmail.com>
Hi Dmitry,
On 11/01/17 19:01, Dmitry Vyukov wrote:
> Hello,
>
> While running syzkaller fuzzer I've got the following deadlock.
> On commit 9c763584b7c8911106bb77af7e648bef09af9d80.
>
>
> =============================================
> [ INFO: possible recursive locking detected ]
> 4.9.0-rc6-xc2-00056-g08372dd4b91d-dirty #50 Not tainted
> ---------------------------------------------
> syz-executor/20805 is trying to acquire lock:
> (
> &kvm->lock
> ){+.+.+.}
> , at:
> [< inline >] kvm_vgic_dist_destroy
> arch/arm64/kvm/../../../virt/kvm/arm/vgic/vgic-init.c:271
> [<ffff2000080ea4bc>] kvm_vgic_destroy+0x34/0x250
> arch/arm64/kvm/../../../virt/kvm/arm/vgic/vgic-init.c:294
> but task is already holding lock:
> (&kvm->lock){+.+.+.}, at:
> [<ffff2000080ea7e4>] kvm_vgic_map_resources+0x2c/0x108
> arch/arm64/kvm/../../../virt/kvm/arm/vgic/vgic-init.c:343
> other info that might help us debug this:
> Possible unsafe locking scenario:
> CPU0
> ----
> lock(&kvm->lock);
> lock(&kvm->lock);
> *** DEADLOCK ***
> May be due to missing lock nesting notation
> 2 locks held by syz-executor/20805:
> #0:(&vcpu->mutex){+.+.+.}, at:
> [<ffff2000080bcc30>] vcpu_load+0x28/0x1d0
> arch/arm64/kvm/../../../virt/kvm/kvm_main.c:143
> #1:(&kvm->lock){+.+.+.}, at:
> [<ffff2000080ea7e4>] kvm_vgic_map_resources+0x2c/0x108
> arch/arm64/kvm/../../../virt/kvm/arm/vgic/vgic-init.c:343
> stack backtrace:
> CPU: 2 PID: 20805 Comm: syz-executor Not tainted
> 4.9.0-rc6-xc2-00056-g08372dd4b91d-dirty #50
> Hardware name: Hardkernel ODROID-C2 (DT)
> Call trace:
> [<ffff200008090560>] dump_backtrace+0x0/0x3c8 arch/arm64/kernel/traps.c:69
> [<ffff200008090948>] show_stack+0x20/0x30 arch/arm64/kernel/traps.c:219
> [< inline >] __dump_stack lib/dump_stack.c:15
> [<ffff200008895840>] dump_stack+0x100/0x150 lib/dump_stack.c:51
> [< inline >] print_deadlock_bug kernel/locking/lockdep.c:1728
> [< inline >] check_deadlock kernel/locking/lockdep.c:1772
> [< inline >] validate_chain kernel/locking/lockdep.c:2250
> [<ffff2000081c8718>] __lock_acquire+0x1938/0x3440 kernel/locking/lockdep.c:3335
> [<ffff2000081caa84>] lock_acquire+0xdc/0x1d8 kernel/locking/lockdep.c:3746
> [< inline >] __mutex_lock_common kernel/locking/mutex.c:521
> [<ffff200009700004>] mutex_lock_nested+0xdc/0x7b8 kernel/locking/mutex.c:621
> [< inline >] kvm_vgic_dist_destroy
> arch/arm64/kvm/../../../virt/kvm/arm/vgic/vgic-init.c:271
> [<ffff2000080ea4bc>] kvm_vgic_destroy+0x34/0x250
> arch/arm64/kvm/../../../virt/kvm/arm/vgic/vgic-init.c:294
> [<ffff2000080ec290>] vgic_v2_map_resources+0x218/0x430
> arch/arm64/kvm/../../../virt/kvm/arm/vgic/vgic-v2.c:295
> [<ffff2000080ea884>] kvm_vgic_map_resources+0xcc/0x108
> arch/arm64/kvm/../../../virt/kvm/arm/vgic/vgic-init.c:348
> [< inline >] kvm_vcpu_first_run_init
> arch/arm64/kvm/../../../arch/arm/kvm/arm.c:505
> [<ffff2000080d2768>] kvm_arch_vcpu_ioctl_run+0xab8/0xce0
> arch/arm64/kvm/../../../arch/arm/kvm/arm.c:591
> [<ffff2000080c1fec>] kvm_vcpu_ioctl+0x434/0xc08
> arch/arm64/kvm/../../../virt/kvm/kvm_main.c:2557
> [< inline >] vfs_ioctl fs/ioctl.c:43
> [<ffff200008450c38>] do_vfs_ioctl+0x128/0xfc0 fs/ioctl.c:679
> [< inline >] SYSC_ioctl fs/ioctl.c:694
> [<ffff200008451b78>] SyS_ioctl+0xa8/0xb8 fs/ioctl.c:685
> [<ffff200008083ef0>] el0_svc_naked+0x24/0x28 arch/arm64/kernel/entry.S:755
Nice catch, and many thanks for reporting this.
The bug is fairly obvious. Christoffer, what do you think? I don't think
we need to hold the kvm->lock all the way, but I'd like another pair of
eyes (the coffee machine is out of order again, and tea doesn't cut it).
Thanks,
M.
>From 93f80b20fb9351a49ee8b74eed3fc59c84651371 Mon Sep 17 00:00:00 2001
From: Marc Zyngier <marc.zyngier@arm.com>
Date: Thu, 12 Jan 2017 09:21:56 +0000
Subject: [PATCH] KVM: arm/arm64: vgic: Fix deadlock on error handling
Dmitry Vyukov reported that the syzkaller fuzzer triggered a
deadlock in the vgic setup code when an error was detected, as
the cleanup code tries to take a lock that is already held by
the setup code.
The fix is pretty obvious: move the cleaup call after having
dropped the lock, since not much can happen at that point.
Cc: stable at vger.kernel.org
Signed-off-by: Marc Zyngier <marc.zyngier@arm.com>
---
virt/kvm/arm/vgic/vgic-init.c | 4 ++++
virt/kvm/arm/vgic/vgic-v2.c | 2 --
virt/kvm/arm/vgic/vgic-v3.c | 2 --
3 files changed, 4 insertions(+), 4 deletions(-)
diff --git a/virt/kvm/arm/vgic/vgic-init.c b/virt/kvm/arm/vgic/vgic-init.c
index 5114391..0e0c295 100644
--- a/virt/kvm/arm/vgic/vgic-init.c
+++ b/virt/kvm/arm/vgic/vgic-init.c
@@ -350,6 +350,10 @@ int kvm_vgic_map_resources(struct kvm *kvm)
ret = vgic_v3_map_resources(kvm);
out:
mutex_unlock(&kvm->lock);
+
+ if (ret)
+ kvm_vgic_destroy(kvm);
+
return ret;
}
diff --git a/virt/kvm/arm/vgic/vgic-v2.c b/virt/kvm/arm/vgic/vgic-v2.c
index 9bab867..834137e 100644
--- a/virt/kvm/arm/vgic/vgic-v2.c
+++ b/virt/kvm/arm/vgic/vgic-v2.c
@@ -293,8 +293,6 @@ int vgic_v2_map_resources(struct kvm *kvm)
dist->ready = true;
out:
- if (ret)
- kvm_vgic_destroy(kvm);
return ret;
}
diff --git a/virt/kvm/arm/vgic/vgic-v3.c b/virt/kvm/arm/vgic/vgic-v3.c
index 7df1b90..a4c7fff 100644
--- a/virt/kvm/arm/vgic/vgic-v3.c
+++ b/virt/kvm/arm/vgic/vgic-v3.c
@@ -308,8 +308,6 @@ int vgic_v3_map_resources(struct kvm *kvm)
dist->ready = true;
out:
- if (ret)
- kvm_vgic_destroy(kvm);
return ret;
}
--
2.1.4
--
Jazz is not dead. It just smells funny...
^ 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