* [PATCHv2] arm64: dts: stratix10: Add QSPI support for Stratix10
From: thor.thayer at linux.intel.com @ 2018-05-11 16:10 UTC (permalink / raw)
To: linux-arm-kernel
From: Thor Thayer <thor.thayer@linux.intel.com>
Add qspi_clock
The qspi_clk frequency is updated by U-Boot before starting Linux.
Add QSPI interface node.
Add QSPI flash memory child node.
Setup the QSPI memory in 2 partitions.
Signed-off-by: Thor Thayer <thor.thayer@linux.intel.com>
---
v2 s/_/-/ in qspi-clk
rename flash node.
use partition child node notation
---
arch/arm64/boot/dts/altera/socfpga_stratix10.dtsi | 22 ++++++++++++++
.../boot/dts/altera/socfpga_stratix10_socdk.dts | 35 ++++++++++++++++++++++
2 files changed, 57 insertions(+)
diff --git a/arch/arm64/boot/dts/altera/socfpga_stratix10.dtsi b/arch/arm64/boot/dts/altera/socfpga_stratix10.dtsi
index e6b059378dc0..bac01b0b7907 100644
--- a/arch/arm64/boot/dts/altera/socfpga_stratix10.dtsi
+++ b/arch/arm64/boot/dts/altera/socfpga_stratix10.dtsi
@@ -119,6 +119,12 @@
#clock-cells = <0>;
compatible = "fixed-clock";
};
+
+ qspi_clk: qspi-clk {
+ #clock-cells = <0>;
+ compatible = "fixed-clock";
+ clock-frequency = <200000000>;
+ };
};
gmac0: ethernet at ff800000 {
@@ -466,5 +472,21 @@
interrupts = <16 4>, <48 4>;
};
};
+
+ qspi: spi at ff8d2000 {
+ compatible = "cdns,qspi-nor";
+ #address-cells = <1>;
+ #size-cells = <0>;
+ reg = <0xff8d2000 0x100>,
+ <0xff900000 0x100000>;
+ interrupts = <0 3 4>;
+ cdns,fifo-depth = <128>;
+ cdns,fifo-width = <4>;
+ cdns,trigger-address = <0x00000000>;
+ clocks = <&qspi_clk>;
+ bus-num = <1>;
+
+ status = "disabled";
+ };
};
};
diff --git a/arch/arm64/boot/dts/altera/socfpga_stratix10_socdk.dts b/arch/arm64/boot/dts/altera/socfpga_stratix10_socdk.dts
index f9b1ef12db48..96542150654b 100644
--- a/arch/arm64/boot/dts/altera/socfpga_stratix10_socdk.dts
+++ b/arch/arm64/boot/dts/altera/socfpga_stratix10_socdk.dts
@@ -147,3 +147,38 @@
reg = <0x68>;
};
};
+
+&qspi {
+ flash at 0 {
+ #address-cells = <1>;
+ #size-cells = <1>;
+ compatible = "n25q00aa";
+ reg = <0>;
+ spi-max-frequency = <50000000>;
+
+ m25p,fast-read;
+ cdns,page-size = <256>;
+ cdns,block-size = <16>;
+ cdns,read-delay = <1>;
+ cdns,tshsl-ns = <50>;
+ cdns,tsd2d-ns = <50>;
+ cdns,tchsh-ns = <4>;
+ cdns,tslch-ns = <4>;
+
+ partitions {
+ compatible = "fixed-partitions";
+ #address-cells = <1>;
+ #size-cells = <1>;
+
+ qspi_boot: partition at 0 {
+ label = "Boot and fpga data";
+ reg = <0x0 0x4000000>;
+ };
+
+ qspi_rootfs: partition at 4000000 {
+ label = "Root Filesystem - JFFS2";
+ reg = <0x4000000 0x4000000>;
+ };
+ };
+ };
+};
--
2.7.4
^ permalink raw reply related
* [PATCH v2 3/4] Documentation: bindings: add phy_config for Rockchip USB Type-C PHY
From: Enric Balletbo Serra @ 2018-05-11 16:09 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180511144305.GP33053@art_vandelay>
Hi Lin,
2018-05-11 16:43 GMT+02:00 Sean Paul <seanpaul@chromium.org>:
> On Wed, May 09, 2018 at 06:22:43PM +0800, Lin Huang wrote:
>> If want to do training outside DP Firmware, need phy voltage swing
>> and pre_emphasis value.
>>
>> Signed-off-by: Lin Huang <hl@rock-chips.com>
>
> Adding Rob Herring so he has a hope of seeing this.
>
And adding the devicetree ML, otherwise Rob will probably ignore the patch.
>> ---
>> Changes in v2:
>> - rebase
>>
>> Documentation/devicetree/bindings/phy/phy-rockchip-typec.txt | 4 +++-
>> 1 file changed, 3 insertions(+), 1 deletion(-)
>>
>> diff --git a/Documentation/devicetree/bindings/phy/phy-rockchip-typec.txt b/Documentation/devicetree/bindings/phy/phy-rockchip-typec.txt
>> index 960da7f..eda26dd 100644
>> --- a/Documentation/devicetree/bindings/phy/phy-rockchip-typec.txt
>> +++ b/Documentation/devicetree/bindings/phy/phy-rockchip-typec.txt
>> @@ -17,7 +17,9 @@ Required properties:
>>
>> Optional properties:
>> - extcon : extcon specifier for the Power Delivery
>> -
>> + - rockchip,phy_config : That's phy voltage swing and pre_emphasis
>> + setting, if want to do dp training outside
>> + dp firmware, need to add these value.
>
> What are the units?
>
Also, I think that will be good add an example or include the property
in the current examples to see how works. It's not clear from the
property description. I suppose it is an array of pairs <swing
pre-emphasis>?
nit:
-rockchip,phy_config: A list of voltage swing (unit) and pre-emphasis
(unit) pairs. Use this property to enable software link training
instead of hardware link training.
Best regards,
Enric
> Sean
>
>> Required nodes : a sub-node is required for each port the phy provides.
>> The sub-node name is used to identify dp or usb3 port,
>> and shall be the following entries:
>> --
>> 2.7.4
>>
>
> --
> Sean Paul, Software Engineer, Google / Chromium OS
^ permalink raw reply
* [PATCH] [stable 4.9] arm64: Add work around for Arm Cortex-A55 Erratum 1024718
From: Suzuki K Poulose @ 2018-05-11 16:06 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180511154721.GC17038@kroah.com>
On 11/05/18 16:47, Greg KH wrote:
> On Fri, May 11, 2018 at 02:51:15PM +0100, Suzuki K Poulose wrote:
>> commit ece1397cbc89c51914fae1aec729539cfd8bd62b upstream
>>
>> Some variants of the Arm Cortex-55 cores (r0p0, r0p1, r1p0) suffer
>> from an erratum 1024718, which causes incorrect updates when DBM/AP
>> bits in a page table entry is modified without a break-before-make
>> sequence. The work around is to disable the hardware DBM feature
>> on the affected cores. The hardware Access Flag management features
>> is not affected.
>>
>> The hardware DBM feature is a non-conflicting capability, i.e, the
>> kernel could handle cores using the feature and those without having
>> the features running at the same time. So this work around is detected
>> at early boot time, rather than delaying it until the CPUs are brought
>> up into the kernel with MMU turned on. This also avoids other complexities
>> with late CPUs turning online, with or without the hardware DBM features.
>>
>> Cc: stable at vger.kernel.org # v4.9
>> Cc: Catalin Marinas <catalin.marinas@arm.com>
>> Cc: Mark Rutland <mark.rutland@arm.com>
>> Cc: Will Deacon <will.deacon@arm.com>
>> Signed-off-by: Suzuki K Poulose <suzuki.poulose@arm.com>
>> ---
>> Note: The upstream commit is on top of a reworked capability
>> infrastructure for arm64 heterogeneous systems, which allows
>> delaying the CPU model checks. This backport is based on the
>> original version of the patch [0], which checks the affected
>> CPU models during the early boot.
>>
>> [0] https://lkml.kernel.org/r/20180116102323.3470-1-suzuki.poulose at arm.com
>
> Now applied, thanks.
Greg,
I have the backport for v4.4 ready. But it needs to cherry-pick a commit
(commit 30b5ba5cf33 : arm64: introduce mov_q macro to move a constant into a 64-bit register)
which adds the assembly helper and that seems to result in a conflict with
an obvious resolution. What do you prefer in this case ?
1) Go ahead with the cherry-pick
Or
2) Fold the pre-req patch (which is about 30 lines of changes) in the back port
Cheers
Suzuki
^ permalink raw reply
* [PATCH v2 05/27] dts: bindings: Document device tree binding for CATU
From: Rob Herring @ 2018-05-11 16:05 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <8725a726-0733-b0bc-fcf8-4e22399c0e22@arm.com>
On Tue, May 8, 2018 at 10:40 AM, Suzuki K Poulose
<Suzuki.Poulose@arm.com> wrote:
>
>
> Rob, Mathieu,
>
>
> On 03/05/18 18:42, Mathieu Poirier wrote:
>>
>> On 1 May 2018 at 07:10, Rob Herring <robh@kernel.org> wrote:
>>>
>>> On Tue, May 01, 2018 at 10:10:35AM +0100, Suzuki K Poulose wrote:
>>>>
>>>> Document CATU device-tree bindings. CATU augments the TMC-ETR
>>>> by providing an improved Scatter Gather mechanism for streaming
>>>> trace data to non-contiguous system RAM pages.
>>>>
>>>> Cc: devicetree at vger.kernel.org
>>>> Cc: frowand.list at gmail.com
>>>> Cc: Rob Herring <robh@kernel.org>
>>>> Cc: Mark Rutland <mark.rutland@arm.com>
>>>> Cc: Mathieu Poirier <mathieu.poirier@arm.com>
>>>> Signed-off-by: Suzuki K Poulose <suzuki.poulose@arm.com>
>>>> ---
>>>> .../devicetree/bindings/arm/coresight.txt | 52
>>>> ++++++++++++++++++++++
>>>> 1 file changed, 52 insertions(+)
>>>>
>>>> diff --git a/Documentation/devicetree/bindings/arm/coresight.txt
>>>> b/Documentation/devicetree/bindings/arm/coresight.txt
>>>> index 15ac8e8..cdd84d0 100644
>>>> --- a/Documentation/devicetree/bindings/arm/coresight.txt
>>>> +++ b/Documentation/devicetree/bindings/arm/coresight.txt
>>>> @@ -39,6 +39,8 @@ its hardware characteristcs.
>>>>
>>>> - System Trace Macrocell:
>>>> "arm,coresight-stm", "arm,primecell"; [1]
>>>> + - Coresight Address Translation Unit (CATU)
>>>> + "arm, coresight-catu", "arm,primecell";
>>>
>>>
>>> spurious space ^
>
>
> Thanks for spotting, will fix it.
>
>>>
>>>>
>>>> * reg: physical base address and length of the register
>>>> set(s) of the component.
>>>> @@ -86,6 +88,9 @@ its hardware characteristcs.
>>>> * arm,buffer-size: size of contiguous buffer space for TMC ETR
>>>> (embedded trace router)
>>>>
>>>> +* Optional property for CATU :
>>>> + * interrupts : Exactly one SPI may be listed for reporting the
>>>> address
>>>> + error
>>>
>>>
>>> Somewhere you need to define the ports for the CATU.
>
>
> The ports are defined common to all the coresight components. Would you
> like it to be added just for the CATU ?
Yeah, that's probably how we got into this problem with the port
numbering in the first place.
>>>> Example:
>>>>
>>>> @@ -118,6 +123,35 @@ Example:
>>>> };
>>>> };
>>>>
>>>> + etr at 20070000 {
>>>> + compatible = "arm,coresight-tmc", "arm,primecell";
>>>> + reg = <0 0x20070000 0 0x1000>;
>>>> +
>>>> + /* input port */
>>>> + port at 0 {
>>>> + reg = <0>;
>>>> + etr_in_port: endpoint {
>>>> + slave-mode;
>>>> + remote-endpoint =
>>>> <&replicator2_out_port0>;
>>>> + };
>>>> + };
>>>> +
>>>> + /* CATU link represented by output port */
>>>> + port at 1 {
>>>> + reg = <0>;
>>>
>>>
>>> While common in the Coresight bindings, having unit-address and reg not
>>> match is an error. Mathieu and I discussed this a bit as dtc now warns
>>> on these.
>>>
>>> Either reg should be 1 here, or 'ports' needs to be split into input and
>>> output ports. My preference would be the former, but Mathieu objected to
>>> this not reflecting the the h/w numbering.
>>
>>
>> Suzuki, as we discuss this is related to your work on revamping CS
>> bindings for ACPI. Until that gets done and to move forward with this
>> set I suggest you abide to Rob's request.
>
>
> Ok, I can change it to <1>, as we don't expect any other output port for an
> ETR.
Better let Mathieu confirm he's okay with the first option because he
wasn't okay with changing the port reg when we discussed. But maybe
that was just on existing things like TPIU.
Rob
^ permalink raw reply
* [PATCH 2/2] arm64: Clear the stack
From: Alexander Popov @ 2018-05-11 15:50 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <4badae50-be9b-2c6d-854b-57ab48664800@linux.com>
Hello everyone,
On 06.05.2018 11:22, Alexander Popov wrote:
> On 04.05.2018 14:09, Mark Rutland wrote:
>>>>> + stack_left = sp & (THREAD_SIZE - 1);
>>>>> + BUG_ON(stack_left < 256 || size >= stack_left - 256);
>>>>
>>>> Is this arbitrary, or is there something special about 256?
>>>>
>>>> Even if this is arbitrary, can we give it some mnemonic?
>>>
>>> It's just a reasonable number. We can introduce a macro for it.
>>
>> I'm just not sure I see the point in the offset, given things like
>> VMAP_STACK exist. BUG_ON() handling will likely require *more* than 256
>> bytes of stack, so it seems superfluous, as we'd be relying on stack
>> overflow detection at that point.
>>
>> I can see that we should take the CONFIG_SCHED_STACK_END_CHECK offset
>> into account, though.
>
> Mark, thank you for such an important remark!
>
> In Kconfig STACKLEAK implies but doesn't depend on VMAP_STACK. In fact x86_32
> doesn't have VMAP_STACK at all but can have STACKLEAK.
>
> [Adding Andy Lutomirski]
>
> I've made some additional experiments: I exhaust the thread stack to have only
> (MIN_STACK_LEFT - 1) bytes left and then force alloca. If VMAP_STACK is
> disabled, BUG_ON() handling causes stack depth overflow, which is detected by
> SCHED_STACK_END_CHECK. If VMAP_STACK is enabled, the kernel hangs on BUG_ON()
> handling! Enabling CONFIG_PROVE_LOCKING gives the needed report from VMAP_STACK:
[...]
> I can't say why VMAP_STACK report hangs during BUG_ON() handling on defconfig.
> Andy, can you give a clue?
>
> I see that MIN_STACK_LEFT = 2048 is enough for BUG_ON() handling on both x86_64
> and x86_32. So I'm going to:
> - set MIN_STACK_LEFT to 2048;
> - improve the lkdtm test to cover this case.
>
> Mark, Kees, Laura, does it sound good?
Could you have a look at the following changes in check_alloca() before I send
the next version?
If VMAP_STACK is enabled and alloca causes stack depth overflow, I write to
guard page below the thread stack to cause double fault and VMAP_STACK report.
If VMAP_STACK is disabled, I use MIN_STACK_LEFT = 2048, which seems to be enough
for BUG_ON() handling both on x86_32 and x86_64. Unfortunately, I can't
guarantee that it is always enough.
#ifdef CONFIG_GCC_PLUGIN_STACKLEAK
-#define MIN_STACK_LEFT 256
+#define MIN_STACK_LEFT 2048
void __used check_alloca(unsigned long size)
{
unsigned long sp = (unsigned long)&sp;
struct stack_info stack_info = {0};
unsigned long visit_mask = 0;
unsigned long stack_left;
BUG_ON(get_stack_info(&sp, current, &stack_info, &visit_mask));
stack_left = sp - (unsigned long)stack_info.begin;
+
+#ifdef CONFIG_VMAP_STACK
+ /*
+ * If alloca oversteps the thread stack boundary, we touch the guard
+ * page provided by VMAP_STACK to trigger handle_stack_overflow().
+ */
+ if (size >= stack_left)
+ *(stack_info.begin - 1) = 42;
+#else
BUG_ON(stack_left < MIN_STACK_LEFT ||
size >= stack_left - MIN_STACK_LEFT);
+#endif
}
EXPORT_SYMBOL(check_alloca);
#endif
Looking forward to your feedback.
Best regards,
Alexander
^ permalink raw reply
* [PATCH] [stable 4.9] arm64: Add work around for Arm Cortex-A55 Erratum 1024718
From: Greg KH @ 2018-05-11 15:47 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1526046675-23790-1-git-send-email-suzuki.poulose@arm.com>
On Fri, May 11, 2018 at 02:51:15PM +0100, Suzuki K Poulose wrote:
> commit ece1397cbc89c51914fae1aec729539cfd8bd62b upstream
>
> Some variants of the Arm Cortex-55 cores (r0p0, r0p1, r1p0) suffer
> from an erratum 1024718, which causes incorrect updates when DBM/AP
> bits in a page table entry is modified without a break-before-make
> sequence. The work around is to disable the hardware DBM feature
> on the affected cores. The hardware Access Flag management features
> is not affected.
>
> The hardware DBM feature is a non-conflicting capability, i.e, the
> kernel could handle cores using the feature and those without having
> the features running at the same time. So this work around is detected
> at early boot time, rather than delaying it until the CPUs are brought
> up into the kernel with MMU turned on. This also avoids other complexities
> with late CPUs turning online, with or without the hardware DBM features.
>
> Cc: stable at vger.kernel.org # v4.9
> Cc: Catalin Marinas <catalin.marinas@arm.com>
> Cc: Mark Rutland <mark.rutland@arm.com>
> Cc: Will Deacon <will.deacon@arm.com>
> Signed-off-by: Suzuki K Poulose <suzuki.poulose@arm.com>
> ---
> Note: The upstream commit is on top of a reworked capability
> infrastructure for arm64 heterogeneous systems, which allows
> delaying the CPU model checks. This backport is based on the
> original version of the patch [0], which checks the affected
> CPU models during the early boot.
>
> [0] https://lkml.kernel.org/r/20180116102323.3470-1-suzuki.poulose at arm.com
Now applied, thanks.
greg k-h
^ permalink raw reply
* Re: [PATCH v10 00/27] ARM: davinci: convert to common clock framework
From: Sekhar Nori @ 2018-05-11 15:26 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180509172606.29387-1-david@lechnology.com>
Hi David,
On Wednesday 09 May 2018 10:55 PM, David Lechner wrote:
> This series converts mach-davinci to use the common clock framework.
>
> The series works like this, the first 3 patches fix some issues with the clock
> drivers that have already been accepted into the mainline kernel.
I have not yet looked at the patches, but I got a bunch of W=1 warnings
and some sparse warnings when building your branch. Please take a look
at these. Unfortunately the output is mixed between sparse and compiler.
The "expression using sizeof(void)" can be ignored as its a known issue
with sparse, I believe.
Thanks,
Sekhar
drivers/clk/davinci/pll-da830.c:39:5: warning: symbol 'da830_pll_init' was not declared. Should it be static?
drivers/clk/davinci/pll.c:142:16: warning: expression using sizeof(void)
drivers/clk/davinci/pll.c:142:16: warning: expression using sizeof(void)
drivers/clk/davinci/pll-da850.c:87:5: warning: symbol 'da850_pll0_init' was not declared. Should it be static?
drivers/clk/davinci/pll-da830.c:39:5: warning: no previous prototype for ?da830_pll_init? [-Wmissing-prototypes]
int da830_pll_init(struct device *dev, void __iomem *base, struct regmap *cfgchip)
^~~~~~~~~~~~~~
drivers/clk/davinci/pll-da850.c:87:5: warning: no previous prototype for ?da850_pll0_init? [-Wmissing-prototypes]
int da850_pll0_init(struct device *dev, void __iomem *base, struct regmap *cfgchip)
^~~~~~~~~~~~~~~
drivers/clk/davinci/pll-dm355.c:30:5: warning: symbol 'dm355_pll1_init' was not declared. Should it be static?
drivers/clk/davinci/pll-dm365.c:59:5: warning: symbol 'dm365_pll1_init' was not declared. Should it be static?
drivers/clk/davinci/pll-dm365.c:122:5: warning: symbol 'dm365_pll2_init' was not declared. Should it be static?
drivers/clk/davinci/da8xx-cfgchip.c:581: warning: Function parameter or member 'dev' not described in 'da8xx_cfgchip_register_usb1_clk48'
drivers/clk/davinci/pll-dm646x.c:32:5: warning: symbol 'dm646x_pll1_init' was not declared. Should it be static?
drivers/clk/davinci/pll-dm644x.c:30:5: warning: symbol 'dm644x_pll1_init' was not declared. Should it be static?
drivers/clk/davinci/pll-dm365.c:59:5: warning: no previous prototype for ?dm365_pll1_init? [-Wmissing-prototypes]
int dm365_pll1_init(struct device *dev, void __iomem *base, struct regmap *cfgchip)
^~~~~~~~~~~~~~~
drivers/clk/davinci/pll-dm365.c:122:5: warning: no previous prototype for ?dm365_pll2_init? [-Wmissing-prototypes]
int dm365_pll2_init(struct device *dev, void __iomem *base, struct regmap *cfgchip)
^~~~~~~~~~~~~~~
drivers/clk/davinci/pll-dm355.c:30:5: warning: no previous prototype for ?dm355_pll1_init? [-Wmissing-prototypes]
int dm355_pll1_init(struct device *dev, void __iomem *base, struct regmap *cfgchip)
^~~~~~~~~~~~~~~
drivers/clk/davinci/psc.c:310:5: warning: symbol 'davinci_clk_reset_assert' was not declared. Should it be static?
drivers/clk/davinci/psc.c:316:5: warning: symbol 'davinci_clk_reset_deassert' was not declared. Should it be static?
drivers/clk/davinci/psc-dm644x.c:66:5: warning: symbol 'dm644x_psc_init' was not declared. Should it be static?
drivers/clk/davinci/psc-dm355.c:71:5: warning: symbol 'dm355_psc_init' was not declared. Should it be static?
drivers/clk/davinci/pll-dm646x.c:32:5: warning: no previous prototype for ?dm646x_pll1_init? [-Wmissing-prototypes]
int dm646x_pll1_init(struct device *dev, void __iomem *base, struct regmap *cfgchip)
^~~~~~~~~~~~~~~~
drivers/clk/davinci/psc-dm365.c:76:5: warning: symbol 'dm365_psc_init' was not declared. Should it be static?
drivers/clk/davinci/psc-dm646x.c:61:5: warning: symbol 'dm646x_psc_init' was not declared. Should it be static?
drivers/clk/davinci/pll-dm644x.c:30:5: warning: no previous prototype for ?dm644x_pll1_init? [-Wmissing-prototypes]
int dm644x_pll1_init(struct device *dev, void __iomem *base, struct regmap *cfgchip)
^~~~~~~~~~~~~~~~
drivers/clk/davinci/psc-dm355.c:71:5: warning: no previous prototype for ?dm355_psc_init? [-Wmissing-prototypes]
int dm355_psc_init(struct device *dev, void __iomem *base)
^~~~~~~~~~~~~~
In file included from drivers/clk/davinci/psc-dm355.c:15:0:
drivers/clk/davinci/psc-dm355.c:26:14: warning: ?mcbsp0_clkdev? defined but not used [-Wunused-const-variable=]
LPSC_CLKDEV1(mcbsp0_clkdev, NULL, "davinci-mcbsp.0");
^
drivers/clk/davinci/psc.h:31:46: note: in definition of macro ?LPSC_CLKDEV1?
static const struct davinci_lpsc_clkdev_info n[] __initconst = { \
^
drivers/clk/davinci/psc-dm355.c:21:14: warning: ?mcbsp1_clkdev? defined but not used [-Wunused-const-variable=]
LPSC_CLKDEV1(mcbsp1_clkdev, NULL, "davinci-mcbsp.1");
^
drivers/clk/davinci/psc.h:31:46: note: in definition of macro ?LPSC_CLKDEV1?
static const struct davinci_lpsc_clkdev_info n[] __initconst = { \
^
drivers/clk/davinci/psc-dm365.c:76:5: warning: no previous prototype for ?dm365_psc_init? [-Wmissing-prototypes]
int dm365_psc_init(struct device *dev, void __iomem *base)
^~~~~~~~~~~~~~
drivers/clk/davinci/psc-dm646x.c:61:5: warning: no previous prototype for ?dm646x_psc_init? [-Wmissing-prototypes]
int dm646x_psc_init(struct device *dev, void __iomem *base)
^~~~~~~~~~~~~~~
drivers/clk/davinci/psc-dm644x.c:66:5: warning: no previous prototype for ?dm644x_psc_init? [-Wmissing-prototypes]
int dm644x_psc_init(struct device *dev, void __iomem *base)
^~~~~~~~~~~~~~~
drivers/clk/davinci/pll.c:496: warning: Function parameter or member 'dev' not described in 'davinci_pll_auxclk_register'
drivers/clk/davinci/psc.c:310:5: warning: no previous prototype for ?davinci_clk_reset_assert? [-Wmissing-prototypes]
int davinci_clk_reset_assert(struct clk *clk)
^~~~~~~~~~~~~~~~~~~~~~~~
drivers/clk/davinci/psc.c:316:5: warning: no previous prototype for ?davinci_clk_reset_deassert? [-Wmissing-prototypes]
int davinci_clk_reset_deassert(struct clk *clk)
^~~~~~~~~~~~~~~~~~~~~~~~~~
drivers/clk/davinci/pll.c:509: warning: Function parameter or member 'dev' not described in 'davinci_pll_sysclkbp_clk_register'
drivers/clk/davinci/pll.c:524: warning: Function parameter or member 'dev' not described in 'davinci_pll_obsclk_register'
drivers/clk/davinci/pll.c:605: warning: Function parameter or member 'dev' not described in 'davinci_pll_sysclk_register'
^ permalink raw reply
* [PATCH 3/3] ARM: davinci: board-dm646x-evm: set VPIF capture card name
From: Sekhar Nori @ 2018-05-11 15:21 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180511152136.29515-1-nsekhar@ti.com>
VPIF capture driver expects card name to be set since it
uses it without checking for NULL. The commit which
introduced VPIF display and capture support added card
name only for display, not for capture.
Set it in platform data to probe driver successfully.
While at it, also fix the display card name to something more
appropriate.
Fixes: 85609c1ccda6 ("DaVinci: DM646x - platform changes for vpif capture and display drivers")
Signed-off-by: Sekhar Nori <nsekhar@ti.com>
---
arch/arm/mach-davinci/board-dm646x-evm.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/arch/arm/mach-davinci/board-dm646x-evm.c b/arch/arm/mach-davinci/board-dm646x-evm.c
index bf6f85048d17..867ab2fa6cfd 100644
--- a/arch/arm/mach-davinci/board-dm646x-evm.c
+++ b/arch/arm/mach-davinci/board-dm646x-evm.c
@@ -538,7 +538,7 @@ static struct vpif_display_config dm646x_vpif_display_config = {
.outputs = dm6467_ch0_outputs,
.output_count = ARRAY_SIZE(dm6467_ch0_outputs),
},
- .card_name = "DM646x EVM",
+ .card_name = "DM646x EVM Video Display",
};
/**
@@ -697,6 +697,7 @@ static struct vpif_capture_config dm646x_vpif_capture_cfg = {
.fid_pol = 0,
},
},
+ .card_name = "DM646x EVM Video Capture",
};
static void __init evm_init_video(void)
--
2.16.2
^ permalink raw reply related
* [PATCH 2/3] ARM: davinci: board-dm646x-evm: pass correct I2C adapter id for VPIF
From: Sekhar Nori @ 2018-05-11 15:21 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180511152136.29515-1-nsekhar@ti.com>
commit a16cb91ad9c4 ("[media] media: vpif: use a configurable
i2c_adapter_id for vpif display") removed hardcoded I2C adaptor
setting in VPIF driver, but missed updating platform data passed
from DM646x board.
Fix it.
Fixes: a16cb91ad9c4 ("[media] media: vpif: use a configurable i2c_adapter_id for vpif display")
Signed-off-by: Sekhar Nori <nsekhar@ti.com>
---
arch/arm/mach-davinci/board-dm646x-evm.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/arch/arm/mach-davinci/board-dm646x-evm.c b/arch/arm/mach-davinci/board-dm646x-evm.c
index 37c9e0ee4dcc..bf6f85048d17 100644
--- a/arch/arm/mach-davinci/board-dm646x-evm.c
+++ b/arch/arm/mach-davinci/board-dm646x-evm.c
@@ -533,6 +533,7 @@ static struct vpif_display_config dm646x_vpif_display_config = {
.set_clock = set_vpif_clock,
.subdevinfo = dm646x_vpif_subdev,
.subdev_count = ARRAY_SIZE(dm646x_vpif_subdev),
+ .i2c_adapter_id = 1,
.chan_config[0] = {
.outputs = dm6467_ch0_outputs,
.output_count = ARRAY_SIZE(dm6467_ch0_outputs),
@@ -675,6 +676,7 @@ static struct vpif_capture_config dm646x_vpif_capture_cfg = {
.setup_input_channel_mode = setup_vpif_input_channel_mode,
.subdev_info = vpif_capture_sdev_info,
.subdev_count = ARRAY_SIZE(vpif_capture_sdev_info),
+ .i2c_adapter_id = 1,
.chan_config[0] = {
.inputs = dm6467_ch0_inputs,
.input_count = ARRAY_SIZE(dm6467_ch0_inputs),
--
2.16.2
^ permalink raw reply related
* [PATCH 1/3] ARM: davinci: dm646x: fix timer interrupt generation
From: Sekhar Nori @ 2018-05-11 15:21 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180511152136.29515-1-nsekhar@ti.com>
commit b38434145b34 ("ARM: davinci: irqs: Correct McASP1 TX
interrupt definition for DM646x") inadvertently removed
setting for priority for timer0_12 (bottom half of timer0).
This timer is used as clockevent.
When INTPRIn register setting for an interrupt is left at 0,
it is mapped to FIQ by the AINTC causing the timer interrupt to
not get generated.
Fix it by including an entry for timer0_12 in interrupt
priority map array. While at it, move the clockevent comment to
the right place.
Fixes: b38434145b34 ("ARM: davinci: irqs: Correct McASP1 TX interrupt definition for DM646x")
Signed-off-by: Sekhar Nori <nsekhar@ti.com>
---
arch/arm/mach-davinci/dm646x.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/arch/arm/mach-davinci/dm646x.c b/arch/arm/mach-davinci/dm646x.c
index 54a4299030de..6bd2ed069d0d 100644
--- a/arch/arm/mach-davinci/dm646x.c
+++ b/arch/arm/mach-davinci/dm646x.c
@@ -178,7 +178,8 @@ static u8 dm646x_default_priorities[DAVINCI_N_AINTC_IRQ] = {
[IRQ_DM646X_MCASP0TXINT] = 7,
[IRQ_DM646X_MCASP0RXINT] = 7,
[IRQ_DM646X_RESERVED_3] = 7,
- [IRQ_DM646X_MCASP1TXINT] = 7, /* clockevent */
+ [IRQ_DM646X_MCASP1TXINT] = 7,
+ [IRQ_TINT0_TINT12] = 7, /* clockevent */
[IRQ_TINT0_TINT34] = 7, /* clocksource */
[IRQ_TINT1_TINT12] = 7, /* DSP timer */
[IRQ_TINT1_TINT34] = 7, /* system tick */
--
2.16.2
^ permalink raw reply related
* [PATCH 0/3] ARM: davinci: some dm646x related fixes
From: Sekhar Nori @ 2018-05-11 15:21 UTC (permalink / raw)
To: linux-arm-kernel
Hi,
Here are some DM646x related fixes for issues I found
while testing the platform.
Sekhar Nori (3):
ARM: davinci: dm646x: fix timer interrupt generation
ARM: davinci: board-dm646x-evm: pass correct I2C adapter id for VPIF
ARM: davinci: board-dm646x-evm: set VPIF capture card name
arch/arm/mach-davinci/board-dm646x-evm.c | 5 ++++-
arch/arm/mach-davinci/dm646x.c | 3 ++-
2 files changed, 6 insertions(+), 2 deletions(-)
--
2.16.2
^ permalink raw reply
* [PATCH 1/2] arm64: arch_timer: Workaround for Allwinner A64 timer instability
From: Samuel Holland @ 2018-05-11 15:08 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <058bea48-a19b-d2c2-d5c4-8de7a424ef8a@arm.com>
On 05/11/18 03:48, Marc Zyngier wrote:
> [+Mark, who co-maintains the arch timer code with me]
>
> Hi Samuel,
>
> On 11/05/18 03:27, Samuel Holland wrote:
>> The Allwinner A64 SoC is known [1] to have an unstable architectural
>> timer, which manifests itself most obviously in the time jumping forward
>> a multiple of 95 years [2][3]. This coincides with 2^56 cycles at a
>> timer frequency of 24 MHz, implying that the time went slightly backward
>> (and this was interpreted by the kernel as it jumping forward and
>> wrapping around past the epoch).
>>
>> Further investigation revealed instability in the low bits of CNTVCT at
>> the point a high bit rolls over. This leads to power-of-two cycle
>> forward and backward jumps. (Testing shows that forward jumps are about
>> twice as likely as backward jumps.)
>>
>> Without trapping reads to CNTVCT, a userspace program is able to read it
>> in a loop faster than it changes. A test program running on all 4 CPU
>> cores that reported jumps larger than 100 ms was run for 13.6 hours and
>> reported the following:
>>
>> Count | Event
>> -------+---------------------------
>> 9940 | jumped backward 699ms
>> 268 | jumped backward 1398ms
>> 1 | jumped backward 2097ms
>> 16020 | jumped forward 175ms
>> 6443 | jumped forward 699ms
>> 2976 | jumped forward 1398ms
>> 9 | jumped forward 356516ms
>> 9 | jumped forward 357215ms
>> 4 | jumped forward 714430ms
>> 1 | jumped forward 3578440ms
>>
>> This works out to a jump larger than 100 ms about every 5.5 seconds on
>> each CPU core.
>>
>> The largest jump (almost an hour!) was the following sequence of reads:
>> 0x0000007fffffffff ? 0x00000093feffffff ? 0x0000008000000000
>>
>> Note that the middle bits don't necessarily all read as all zeroes or
>> all ones during the anomalous behavior; however the low 11 bits checked
>> by the function in this patch have never been observed with any other
>> value.
>>
>> Also note that smaller jumps are much more common, with the smallest
>> backward jumps of 2048 cycles observed over 400 times per second on each
>> core. (Of course, this is partially due to lower bits rolling over more
>> frequently.) Any one of these could have caused the 95 year time skip.
>>
>> Similar anomalies were observed while reading CNTPCT (after patching the
>> kernel to allow reads from userspace). However, the jumps are much less
>> frequent, and only small jumps were observed. The same program as before
>> (except now reading CNTPCT) observed after 72 hours:
>>
>> Count | Event
>> -------+---------------------------
>> 17 | jumped backward 699ms
>> 52 | jumped forward 175ms
>> 2831 | jumped forward 699ms
>> 5 | jumped forward 1398ms
>>
>> ========================================================================
>>
>> Because the CPU can read the CNTPCT/CNTVCT registers faster than they
>> change, performing two reads of the register and comparing the high bits
>> (like other workarounds) is not a workable solution. And because the
>> timer can jump both forward and backward, no pair of reads can
>> distinguish a good value from a bad one. The only way to guarantee a
>> good value from consecutive reads would be to read _three_ times, and
>> take the middle value iff the three values are 1) individually unique
>> and 2) increasing. This takes at minimum 3 cycles (125 ns), or more if
>> an anomaly is detected.
>>
>> However, since there is a distinct pattern to the bad values, we can
>> optimize the common case (2046/2048 of the time) to a single read by
>> simply ignoring values that match the pattern. This still takes no more
>> than 3 cycles in the worst case, and requires much less code.
>
> Thanks for the thorough description of the problem. A couple of questions:
>
> - Have the 000/7ff values of the bottom bits only been experimentally
> found? Or do you have more concrete evidence of this is what happens in
> the HW?
Only experimentally found. Here's a sample of the larger jumps:
CPU 3: 0x000000a5ebffffff ? 0x000000a5edffffff (retry = 0x000000a5ec000000)
CPU 1: 0x000000a5ebffffff ? 0x000000a5edffffff (retry = 0x000000a5ec000000)
CPU 1: 0x000000a5ecffffff > 0x000000a5ec000000 (retry = 0x000000a5ed000000)
CPU 0: 0x000000a5eeffffff > 0x000000a5ee000000 (retry = 0x000000a5ef000000)
CPU 2: 0x000000a5f0bfffff ? 0x000000a5f0ffffff (retry = 0x000000a5f0c00000)
CPU 0: 0x000000a5f0ffffff > 0x000000a5f0000000 (retry = 0x000000a5f1000000)
CPU 2: 0x000000a5f3ffffff > 0x000000a5f2000000 (retry = 0x000000a5f4000000)
CPU 0: 0x000000a5f6ffffff > 0x000000a5f6000000 (retry = 0x000000a5f7000000)
CPU 1: 0x000000a5fbbfffff ? 0x000000a5fbffffff (retry = 0x000000a5fbc00000)
CPU 0: 0x000000a5fdffffff ? 0x000000a5feffffff (retry = 0x000000a5fe000000)
CPU 2: 0x000000a5ffffffff ? 0x000000a7fe000000 (retry = 0x000000a600000000)
CPU 3: 0x000000a5ffffffff ? 0x000000a7fe000000 (retry = 0x000000a600000000)
CPU 1: 0x000000a603bfffff ? 0x000000a603ffffff (retry = 0x000000a603c00000)
CPU 1: 0x000000a607bfffff ? 0x000000a607ffffff (retry = 0x000000a607c00000)
CPU 3: 0x000000a60cbfffff ? 0x000000a60cffffff (retry = 0x000000a60cc00000)
CPU 2: 0x000000a60cbfffff ? 0x000000a60cffffff (retry = 0x000000a60cc00000)
CPU 2: 0x000000a60dffffff ? 0x000000a60effffff (retry = 0x000000a60e000000)
CPU 0: 0x000000a60e3fffff ? 0x000000a60e7fffff (retry = 0x000000a60e400000)
CPU 1: 0x000000a60effffff > 0x000000a60e000000 (retry = 0x000000a60f000000)
(Note that for the large jump, 0x000000a5ffffffff ? 0x000000a7fe000000, not
all of the low bits are zeroes during the transition.)
And of the tiny jumps backward:
CPU 3: 0x000000d2f010bfff > 0x000000d2f010b800 (retry = 0x000000d2f010b801)
CPU 3: 0x000000d2f0110fff > 0x000000d2f0110800 (retry = 0x000000d2f0110801)
CPU 3: 0x000000d2f0112fff > 0x000000d2f0112800 (retry = 0x000000d2f0112801)
CPU 3: 0x000000d2f0119fff > 0x000000d2f0119800 (retry = 0x000000d2f0119801)
CPU 3: 0x000000d2f011f7ff > 0x000000d2f011f000 (retry = 0x000000d2f011f800)
CPU 3: 0x000000d2f01257ff > 0x000000d2f0125000 (retry = 0x000000d2f0125800)
CPU 3: 0x000000d2f012b7ff > 0x000000d2f012b000 (retry = 0x000000d2f012b800)
CPU 3: 0x000000d2f01317ff > 0x000000d2f0131000 (retry = 0x000000d2f0131800)
CPU 2: 0x000000d2f00c17ff > 0x000000d2f00c1000 (retry = 0x000000d2f00c1800)
CPU 2: 0x000000d2f0136fff > 0x000000d2f0136800 (retry = 0x000000d2f0136801)
CPU 2: 0x000000d2f01377ff > 0x000000d2f0137000 (retry = 0x000000d2f0137800)
CPU 2: 0x000000d2f013afff > 0x000000d2f013a800 (retry = 0x000000d2f013a801)
CPU 2: 0x000000d2f01417ff > 0x000000d2f0141000 (retry = 0x000000d2f0141800)
CPU 2: 0x000000d2f0142fff > 0x000000d2f0142800 (retry = 0x000000d2f0142801)
CPU 2: 0x000000d2f01497ff > 0x000000d2f0149000 (retry = 0x000000d2f0149800)
CPU 2: 0x000000d2f014b7ff > 0x000000d2f014b000 (retry = 0x000000d2f014b800)
CPU 2: 0x000000d2f0150fff > 0x000000d2f0150800 (retry = 0x000000d2f0150801)
CPU 2: 0x000000d2f01577ff > 0x000000d2f0157000 (retry = 0x000000d2f0157800)
CPU 2: 0x000000d2f015d7ff > 0x000000d2f015d000 (retry = 0x000000d2f015d800)
CPU 2: 0x000000d2f015f7ff > 0x000000d2f015f000 (retry = 0x000000d2f015f800)
CPU 2: 0x000000d2f01617ff > 0x000000d2f0161000 (retry = 0x000000d2f0161800)
CPU 2: 0x000000d2f0166fff > 0x000000d2f0166800 (retry = 0x000000d2f0166801)
CPU 2: 0x000000d2f0168fff > 0x000000d2f0168800 (retry = 0x000000d2f0168801)
CPU 2: 0x000000d2f016b7ff > 0x000000d2f016b000 (retry = 0x000000d2f016b800)
I have close to 100 hours of data, and the "bottom 11 bits" value came from
the observations that:
1) Jumps by 2048 cycles were the smallest jumps seen
2) Even when the anomalous values were not all ones/all zeroes, the bottom
11 bits _were_ all ones/all zeroes
I'd be happy to run more tests if there's something else you think I should
look for.
> - Do you have an official erratum number from the silicon vendor, so
> that Documentation/arm64/silicon-errata.txt can be kept up to date?
No, unfortunately the only information we have from the vendor is in the
form of BSP kernel code drops. There _is_ a workaround present in their
official sources [1], but it looks to be for a different issue (one that I
haven't experienced).
[1]
https://github.com/Allwinner-Homlet/H6-BSP4.9-linux/blob/e634a960316d/drivers/clocksource/arm_arch_timer.c#L272-L327
>>
>> [1]: https://github.com/armbian/build/commit/a08cd6fe7ae9
>> [2]: https://forum.armbian.com/topic/3458-a64-datetime-clock-issue/
>> [3]: https://irclog.whitequark.org/linux-sunxi/2018-01-26
>>
>> Signed-off-by: Samuel Holland <samuel@sholland.org>
>> ---
>> drivers/clocksource/Kconfig | 11 ++++++++++
>> drivers/clocksource/arm_arch_timer.c | 39 ++++++++++++++++++++++++++++++++++++
>> 2 files changed, 50 insertions(+)
>>
>> diff --git a/drivers/clocksource/Kconfig b/drivers/clocksource/Kconfig
>> index 8e8a09755d10..7a5d434dd30b 100644
>> --- a/drivers/clocksource/Kconfig
>> +++ b/drivers/clocksource/Kconfig
>> @@ -364,6 +364,17 @@ config ARM64_ERRATUM_858921
>> The workaround will be dynamically enabled when an affected
>> core is detected.
>>
>> +config SUN50I_A64_UNSTABLE_TIMER
>> + bool "Workaround for Allwinner A64 timer instability"
>> + default y
>> + depends on ARM_ARCH_TIMER && ARM64 && ARCH_SUNXI
>> + select ARM_ARCH_TIMER_OOL_WORKAROUND
>> + help
>> + This option enables a workaround for instability in the timer on
>> + the Allwinner A64 SoC. The workaround will only be active if the
>> + allwinner,sun50i-a64-unstable-timer property is found in the
>> + timer node.
>> +
>> config ARM_GLOBAL_TIMER
>> bool "Support for the ARM global timer" if COMPILE_TEST
>> select TIMER_OF if OF
>> diff --git a/drivers/clocksource/arm_arch_timer.c b/drivers/clocksource/arm_arch_timer.c
>> index 57cb2f00fc07..66ce13578c52 100644
>> --- a/drivers/clocksource/arm_arch_timer.c
>> +++ b/drivers/clocksource/arm_arch_timer.c
>> @@ -319,6 +319,36 @@ static u64 notrace arm64_858921_read_cntvct_el0(void)
>> }
>> #endif
>>
>> +#ifdef CONFIG_SUN50I_A64_UNSTABLE_TIMER
>> +/*
>> + * The low bits of each register can transiently read as all ones or all zeroes
>> + * when bit 11 or greater rolls over. Since the value can jump both backward
>> + * (7ff -> 000 -> 800) and forward (7ff -> fff -> 800), it is simplest to just
>> + * ignore register values with all ones or zeros in the low bits.
>> + */
>> +static u64 notrace sun50i_a64_read_cntpct_el0(void)
>> +{
>> + u64 val;
>> +
>> + do {
>> + val = read_sysreg(cntpct_el0);
>> + } while (((val + 1) & GENMASK(10, 0)) <= 1);
>
> Other workarounds of the same kind have a bounded loop. Have you done
> any investigation on how many loops you need at most to sort the timer?
> Depending on how many loops you need, it might be worth sticking a WFE
> here to just wait for something to happen instead of busy looping.
The worst case delay inside the loop is two timer cycles at 24 MHz (83.3 ns).
So the number of iterations depends on the CPU speed. For example:
0x???4ffe -> read once and return
0x???4fff -> read and loop (((val + 1) & GENMASK(10, 0)) == 0)
0x???5000 -> read and loop (((val + 1) & GENMASK(10, 0)) == 1)
0x???5001 -> read once and return
Now of course this function could be preempted, in which case it most likely
does even fewer reads. (The probability of "read 0x???4fff", "preempt", "read
0x???5fff" is pretty low.)
I do not think it is possible to know if an 000/7ff value is valid without
reading three unique values from the timer. So the latency entirely depends
on the timer frequency, not the CPU speed.
>> +
>> + return val;
>> +}
>> +
>> +static u64 notrace sun50i_a64_read_cntvct_el0(void)
>> +{
>> + u64 val;
>> +
>> + do {
>> + val = read_sysreg(cntvct_el0);
>> + } while (((val + 1) & GENMASK(10, 0)) <= 1);
>> +
>> + return val;
>> +}
>> +#endif
>> +
>> #ifdef CONFIG_ARM_ARCH_TIMER_OOL_WORKAROUND
>> DEFINE_PER_CPU(const struct arch_timer_erratum_workaround *, timer_unstable_counter_workaround);
>> EXPORT_SYMBOL_GPL(timer_unstable_counter_workaround);
>> @@ -408,6 +438,15 @@ static const struct arch_timer_erratum_workaround ool_workarounds[] = {
>> .read_cntvct_el0 = arm64_858921_read_cntvct_el0,
>> },
>> #endif
>> +#ifdef CONFIG_SUN50I_A64_UNSTABLE_TIMER
>> + {
>> + .match_type = ate_match_dt,
>> + .id = "allwinner,sun50i-a64-unstable-timer",
>> + .desc = "Allwinner A64 timer instability",
>> + .read_cntpct_el0 = sun50i_a64_read_cntpct_el0,
>> + .read_cntvct_el0 = sun50i_a64_read_cntvct_el0,
>> + },
>> +#endif
>> };
>>
>> typedef bool (*ate_match_fn_t)(const struct arch_timer_erratum_workaround *,
>>
>
> Thanks,
>
> M.
>
^ permalink raw reply
* [PATCH v2 03/12] arm: dts: mt7623: fix invalid memory node being generated
From: Matthias Brugger @ 2018-05-11 15:03 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <d887b72e1839c7e476179e384cfc712216096f20.1523434758.git.sean.wang@mediatek.com>
On 04/11/2018 10:53 AM, sean.wang at mediatek.com wrote:
> From: Sean Wang <sean.wang@mediatek.com>
>
> Below two wrong nodes in existing DTS files would cause a fail boot since
> in fact the address 0 is not the correct place the memory device locates
> at.
>
> memory {
> device_type = "memory";
> reg = <0x0 0x0 0x0 0x0>;
> };
>
> memory at 80000000 {
> reg = <0x0 0x80000000 0x0 0x40000000>;
> };
>
> In order to avoid having a memory node starting at address 0, we can't
> include file skeleton64.dtsi and instead need to explicitly manually
> define a few of properties the DTS relies on such as #address-cells
> and #size-cells in root node and device_type in the node memory at 80000000.
>
> Cc: stable at vger.kernel.org
> Fixes: 31ac0d69a1d4 ("ARM: dts: mediatek: add MT7623 basic support")
> Signed-off-by: Sean Wang <sean.wang@mediatek.com>
> Cc: Rob Herring <robh+dt@kernel.org>
> ---
> arch/arm/boot/dts/mt7623.dtsi | 3 ++-
> arch/arm/boot/dts/mt7623n-bananapi-bpi-r2.dts | 1 +
> arch/arm/boot/dts/mt7623n-rfb.dtsi | 1 +
> 3 files changed, 4 insertions(+), 1 deletion(-)
>
merged. We would need this at least for mt2701 as well, correct?
Would you mind to provide a patch.
Regards,
Matthias
> diff --git a/arch/arm/boot/dts/mt7623.dtsi b/arch/arm/boot/dts/mt7623.dtsi
> index fec4715..406a9f3 100644
> --- a/arch/arm/boot/dts/mt7623.dtsi
> +++ b/arch/arm/boot/dts/mt7623.dtsi
> @@ -15,11 +15,12 @@
> #include <dt-bindings/phy/phy.h>
> #include <dt-bindings/reset/mt2701-resets.h>
> #include <dt-bindings/thermal/thermal.h>
> -#include "skeleton64.dtsi"
>
> / {
> compatible = "mediatek,mt7623";
> interrupt-parent = <&sysirq>;
> + #address-cells = <2>;
> + #size-cells = <2>;
>
> cpu_opp_table: opp-table {
> compatible = "operating-points-v2";
> diff --git a/arch/arm/boot/dts/mt7623n-bananapi-bpi-r2.dts b/arch/arm/boot/dts/mt7623n-bananapi-bpi-r2.dts
> index bbf56f8..5938e4c 100644
> --- a/arch/arm/boot/dts/mt7623n-bananapi-bpi-r2.dts
> +++ b/arch/arm/boot/dts/mt7623n-bananapi-bpi-r2.dts
> @@ -109,6 +109,7 @@
> };
>
> memory at 80000000 {
> + device_type = "memory";
> reg = <0 0x80000000 0 0x40000000>;
> };
> };
> diff --git a/arch/arm/boot/dts/mt7623n-rfb.dtsi b/arch/arm/boot/dts/mt7623n-rfb.dtsi
> index a199ae7..343e8ef 100644
> --- a/arch/arm/boot/dts/mt7623n-rfb.dtsi
> +++ b/arch/arm/boot/dts/mt7623n-rfb.dtsi
> @@ -40,6 +40,7 @@
> };
>
> memory at 80000000 {
> + device_type = "memory";
> reg = <0 0x80000000 0 0x40000000>;
> };
>
>
^ permalink raw reply
* [PATCH v2 4/4] drm/rockchip: support dp training outside dp firmware
From: Sean Paul @ 2018-05-11 15:01 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1525861364-26323-4-git-send-email-hl@rock-chips.com>
On Wed, May 09, 2018 at 06:22:44PM +0800, Lin Huang wrote:
> DP firmware uses fixed phy config values to do training, but some
> boards need to adjust these values to fit for their unique hardware
> design. So if the phy is using custom config values, do software
> link training instead of relying on firmware, if software training
> fail, keep firmware training as a fallback if sw training fails.
>
> Signed-off-by: Chris Zhong <zyw@rock-chips.com>
> Signed-off-by: Lin Huang <hl@rock-chips.com>
FTR, I've previously reviewed this patch at
https://chromium-review.googlesource.com/c/chromiumos/third_party/kernel/+/985573
> ---
> Changes in v2:
> - update patch following Enric suggest
>
> drivers/gpu/drm/rockchip/Makefile | 3 +-
> drivers/gpu/drm/rockchip/cdn-dp-core.c | 24 +-
> drivers/gpu/drm/rockchip/cdn-dp-core.h | 2 +
> drivers/gpu/drm/rockchip/cdn-dp-link-training.c | 391 ++++++++++++++++++++++++
> drivers/gpu/drm/rockchip/cdn-dp-reg.c | 34 ++-
> drivers/gpu/drm/rockchip/cdn-dp-reg.h | 38 ++-
> 6 files changed, 479 insertions(+), 13 deletions(-)
> create mode 100644 drivers/gpu/drm/rockchip/cdn-dp-link-training.c
>
/snip
> diff --git a/drivers/gpu/drm/rockchip/cdn-dp-core.h b/drivers/gpu/drm/rockchip/cdn-dp-core.h
> index 46159b2..c6050ab 100644
> --- a/drivers/gpu/drm/rockchip/cdn-dp-core.h
> +++ b/drivers/gpu/drm/rockchip/cdn-dp-core.h
> @@ -84,6 +84,7 @@ struct cdn_dp_device {
> bool connected;
> bool active;
> bool suspended;
> + bool sw_training_success;
Can you change this to use_fw_training instead? So it will be false if sw
training succeeds, and true if sw training fails and needs to fallback to fw.
>
> const struct firmware *fw; /* cdn dp firmware */
> unsigned int fw_version; /* cdn fw version */
> @@ -106,6 +107,7 @@ struct cdn_dp_device {
> u8 ports;
> u8 lanes;
> int active_port;
> + u8 train_set[4];
>
> u8 dpcd[DP_RECEIVER_CAP_SIZE];
> bool sink_has_audio;
/snip
> diff --git a/drivers/gpu/drm/rockchip/cdn-dp-reg.c b/drivers/gpu/drm/rockchip/cdn-dp-reg.c
> index afdfda0..bd0aed5 100644
> --- a/drivers/gpu/drm/rockchip/cdn-dp-reg.c
> +++ b/drivers/gpu/drm/rockchip/cdn-dp-reg.c
> @@ -17,7 +17,9 @@
> #include <linux/delay.h>
> #include <linux/io.h>
> #include <linux/iopoll.h>
> +#include <linux/phy/phy.h>
> #include <linux/reset.h>
> +#include <soc/rockchip/rockchip_phy_typec.h>
>
> #include "cdn-dp-core.h"
> #include "cdn-dp-reg.h"
> @@ -189,7 +191,7 @@ static int cdn_dp_mailbox_send(struct cdn_dp_device *dp, u8 module_id,
> return 0;
> }
>
> -static int cdn_dp_reg_write(struct cdn_dp_device *dp, u16 addr, u32 val)
> +int cdn_dp_reg_write(struct cdn_dp_device *dp, u16 addr, u32 val)
> {
> u8 msg[6];
>
> @@ -606,7 +608,35 @@ static int cdn_dp_get_training_status(struct cdn_dp_device *dp)
> int cdn_dp_train_link(struct cdn_dp_device *dp)
> {
> int ret;
> + struct cdn_dp_port *port = dp->port[dp->active_port];
> + struct rockchip_typec_phy *tcphy = phy_get_drvdata(port->phy);
>
> + /*
> + * DP firmware uses fixed phy config values to do training, but some
> + * boards need to adjust these values to fit for their unique hardware
> + * design. So if the phy is using custom config values, do software
> + * link training instead of relying on firmware, if software training
> + * fail, keep firmware training as a fallback if sw training fails.
> + */
> + if (tcphy->need_software_training) {
As discussed in the downstream review, I'd rather default to sw training and
fallback to fw training if we must.
> + ret = cdn_dp_software_train_link(dp);
> + if (ret) {
> + DRM_DEV_ERROR(dp->dev,
> + "Failed to do software training %d\n", ret);
> + goto do_fw_training;
> + }
> + ret = cdn_dp_reg_write(dp, SOURCE_HDTX_CAR, 0xf);
> + if (ret) {
> + DRM_DEV_ERROR(dp->dev,
> + "Failed to write SOURCE_HDTX_CAR register %d\n", ret);
> + goto do_fw_training;
> + }
> + dp->sw_training_success = true;
> + return 0;
> + }
> +
> +do_fw_training:
> + dp->sw_training_success = false;
Can you please add a DRM_DEBUG_KMS log message here?
> ret = cdn_dp_training_start(dp);
> if (ret) {
> DRM_DEV_ERROR(dp->dev, "Failed to start training %d\n", ret);
> @@ -621,7 +651,7 @@ int cdn_dp_train_link(struct cdn_dp_device *dp)
>
> DRM_DEV_DEBUG_KMS(dp->dev, "rate:0x%x, lanes:%d\n", dp->link.rate,
> dp->link.num_lanes);
> - return ret;
> + return 0;
> }
>
> int cdn_dp_set_video_status(struct cdn_dp_device *dp, int active)
> diff --git a/drivers/gpu/drm/rockchip/cdn-dp-reg.h b/drivers/gpu/drm/rockchip/cdn-dp-reg.h
> index 6580b11..3420771 100644
> --- a/drivers/gpu/drm/rockchip/cdn-dp-reg.h
> +++ b/drivers/gpu/drm/rockchip/cdn-dp-reg.h
> @@ -137,7 +137,7 @@
> #define HPD_EVENT_MASK 0x211c
> #define HPD_EVENT_DET 0x2120
>
> -/* dpyx framer addr */
> +/* dptx framer addr */
> #define DP_FRAMER_GLOBAL_CONFIG 0x2200
> #define DP_SW_RESET 0x2204
> #define DP_FRAMER_TU 0x2208
> @@ -431,6 +431,40 @@
> /* Reference cycles when using lane clock as reference */
> #define LANE_REF_CYC 0x8000
>
> +/* register CM_VID_CTRL */
> +#define LANE_VID_REF_CYC(x) (((x) & (BIT(24) - 1)) << 0)
> +#define NMVID_MEAS_TOLERANCE(x) (((x) & 0xf) << 24)
> +
> +/* register DP_TX_PHY_CONFIG_REG */
> +#define DP_TX_PHY_TRAINING_ENABLE(x) ((x) & 1)
> +#define DP_TX_PHY_TRAINING_TYPE_PRBS7 (0 << 1)
> +#define DP_TX_PHY_TRAINING_TYPE_TPS1 (1 << 1)
> +#define DP_TX_PHY_TRAINING_TYPE_TPS2 (2 << 1)
> +#define DP_TX_PHY_TRAINING_TYPE_TPS3 (3 << 1)
> +#define DP_TX_PHY_TRAINING_TYPE_TPS4 (4 << 1)
> +#define DP_TX_PHY_TRAINING_TYPE_PLTPAT (5 << 1)
> +#define DP_TX_PHY_TRAINING_TYPE_D10_2 (6 << 1)
> +#define DP_TX_PHY_TRAINING_TYPE_HBR2CPAT (8 << 1)
> +#define DP_TX_PHY_TRAINING_PATTERN(x) ((x) << 1)
> +#define DP_TX_PHY_SCRAMBLER_BYPASS(x) (((x) & 1) << 5)
> +#define DP_TX_PHY_ENCODER_BYPASS(x) (((x) & 1) << 6)
> +#define DP_TX_PHY_SKEW_BYPASS(x) (((x) & 1) << 7)
> +#define DP_TX_PHY_DISPARITY_RST(x) (((x) & 1) << 8)
> +#define DP_TX_PHY_LANE0_SKEW(x) (((x) & 7) << 9)
> +#define DP_TX_PHY_LANE1_SKEW(x) (((x) & 7) << 12)
> +#define DP_TX_PHY_LANE2_SKEW(x) (((x) & 7) << 15)
> +#define DP_TX_PHY_LANE3_SKEW(x) (((x) & 7) << 18)
> +#define DP_TX_PHY_10BIT_ENABLE(x) (((x) & 1) << 21)
> +
> +/* register DP_FRAMER_GLOBAL_CONFIG */
> +#define NUM_LANES(x) ((x) & 3)
> +#define SST_MODE (0 << 2)
> +#define RG_EN (0 << 4)
> +#define GLOBAL_EN BIT(3)
> +#define NO_VIDEO BIT(5)
> +#define ENC_RST_DIS BIT(6)
> +#define WR_VHSYNC_FALL BIT(7)
> +
> enum voltage_swing_level {
> VOLTAGE_LEVEL_0,
> VOLTAGE_LEVEL_1,
> @@ -476,6 +510,7 @@ int cdn_dp_set_host_cap(struct cdn_dp_device *dp, u8 lanes, bool flip);
> int cdn_dp_event_config(struct cdn_dp_device *dp);
> u32 cdn_dp_get_event(struct cdn_dp_device *dp);
> int cdn_dp_get_hpd_status(struct cdn_dp_device *dp);
> +int cdn_dp_reg_write(struct cdn_dp_device *dp, u16 addr, u32 val);
> ssize_t cdn_dp_dpcd_write(struct cdn_dp_device *dp, u32 addr,
> u8 *data, u16 len);
> ssize_t cdn_dp_dpcd_read(struct cdn_dp_device *dp, u32 addr,
> @@ -489,4 +524,5 @@ int cdn_dp_config_video(struct cdn_dp_device *dp);
> int cdn_dp_audio_stop(struct cdn_dp_device *dp, struct audio_info *audio);
> int cdn_dp_audio_mute(struct cdn_dp_device *dp, bool enable);
> int cdn_dp_audio_config(struct cdn_dp_device *dp, struct audio_info *audio);
> +int cdn_dp_software_train_link(struct cdn_dp_device *dp);
> #endif /* _CDN_DP_REG_H */
> --
> 2.7.4
>
--
Sean Paul, Software Engineer, Google / Chromium OS
^ permalink raw reply
* [PATCH v2] arm64: allwinner: a64: Add Amarula A64 Relic initial support
From: Maxime Ripard @ 2018-05-11 14:57 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAMty3ZCM7Sxsp4MwDRYq9NSfWJfj6XKK6JN9DKyk91MNrLvPAg@mail.gmail.com>
On Fri, May 11, 2018 at 11:37:04AM +0530, Jagan Teki wrote:
> On Fri, May 11, 2018 at 11:20 AM, Chen-Yu Tsai <wens@csie.org> wrote:
> > On Thu, May 10, 2018 at 10:43 PM, Jagan Teki <jagan@amarulasolutions.com> wrote:
> >> Amarula A64 Relic is Allwinner A64 based IoT device, which support
> >> - Allwinner A64 Cortex-A53
> >> - Mali-400MP2 GPU
> >> - AXP803 PMIC
> >> - 1GB DDR3 RAM
> >> - 8GB eMMC
> >> - AP6330 Wifi/BLE
> >> - MIPI-DSI
> >> - CSI: OV5640 sensor
> >> - USB OTG
> >> - 12V DC power supply
> >>
> >> Signed-off-by: Jagan Teki <jagan@amarulasolutions.com>
> >> ---
> >> Changes for v2:
> >> - Rename dts name to sun50i-a64-relic.dts which is simple to use
> >
> > This is subjective. For other users this hardly qualifies to
> > identify the board. Please keep the vendor / brand name in
> > the file name.
>
> Which I thought initially, but adding vendor makes long string which
> become lengthy for next boards to add it in future. So we make
> notation with <SOC_name>_<board_name> like sun50i-a64-teres-i.dts
> does.
In the case of Teres-I, this is an easily identifiable board, for
which a simple google search can give you very easily what board it is
and where you can get it. Yours fail for both, so I agree with Chen-Yu
here.
Maxime
--
Maxime Ripard, Bootlin (formerly Free Electrons)
Embedded Linux and Kernel engineering
https://bootlin.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20180511/19c6f9d6/attachment.sig>
^ permalink raw reply
* [PATCH v2 3/4] Documentation: bindings: add phy_config for Rockchip USB Type-C PHY
From: Sean Paul @ 2018-05-11 14:43 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1525861364-26323-3-git-send-email-hl@rock-chips.com>
On Wed, May 09, 2018 at 06:22:43PM +0800, Lin Huang wrote:
> If want to do training outside DP Firmware, need phy voltage swing
> and pre_emphasis value.
>
> Signed-off-by: Lin Huang <hl@rock-chips.com>
Adding Rob Herring so he has a hope of seeing this.
> ---
> Changes in v2:
> - rebase
>
> Documentation/devicetree/bindings/phy/phy-rockchip-typec.txt | 4 +++-
> 1 file changed, 3 insertions(+), 1 deletion(-)
>
> diff --git a/Documentation/devicetree/bindings/phy/phy-rockchip-typec.txt b/Documentation/devicetree/bindings/phy/phy-rockchip-typec.txt
> index 960da7f..eda26dd 100644
> --- a/Documentation/devicetree/bindings/phy/phy-rockchip-typec.txt
> +++ b/Documentation/devicetree/bindings/phy/phy-rockchip-typec.txt
> @@ -17,7 +17,9 @@ Required properties:
>
> Optional properties:
> - extcon : extcon specifier for the Power Delivery
> -
> + - rockchip,phy_config : That's phy voltage swing and pre_emphasis
> + setting, if want to do dp training outside
> + dp firmware, need to add these value.
What are the units?
Sean
> Required nodes : a sub-node is required for each port the phy provides.
> The sub-node name is used to identify dp or usb3 port,
> and shall be the following entries:
> --
> 2.7.4
>
--
Sean Paul, Software Engineer, Google / Chromium OS
^ permalink raw reply
* [GIT PULL] arm64: hisi: SoC driver updates for v4.18
From: Wei Xu @ 2018-05-11 14:42 UTC (permalink / raw)
To: linux-arm-kernel
Hi Arnd, Hi Olof,
Please help to pull the following changes.
Sorry for the inconvenience, because it depends on this patch [1]
which was merged in the rc3, I rebased the pull on rc3.
Thanks!
[1] HISI LPC: Add Kconfig MFD_CORE dependency
https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git/commit/drivers/bus?h=v4.17-rc3&id=4b313ca7b661ab8782f3dcb4a8996632a470b4da
Best Regards,
Wei
---
The following changes since commit 6da6c0db5316275015e8cc2959f12a17584aeb64:
Linux v4.17-rc3 (2018-04-29 14:17:42 -0700)
are available in the Git repository at:
git://github.com/hisilicon/linux-hisi.git tags/hisi-drivers-for-4.18
for you to fetch changes up to adf3457b4ce6940885be3e5ee832c6949fba4166:
HISI LPC: Add ACPI UART support (2018-05-10 17:45:52 +0100)
----------------------------------------------------------------
ARM64: hisi: SoC driver updates for 4.18
- Update hisi LPC bus driver to use the platform driver APIs
other than the MFD APIs to support connected device like UART
----------------------------------------------------------------
John Garry (3):
HISI LPC: Stop using MFD APIs
HISI LPC: Re-Add ACPI child enumeration support
HISI LPC: Add ACPI UART support
drivers/bus/Kconfig | 1 -
drivers/bus/hisi_lpc.c | 159 ++++++++++++++++++++++++++++++-------------------
2 files changed, 97 insertions(+), 63 deletions(-)
^ permalink raw reply
* [PATCH v2 2/4] phy: rockchip-typec: support variable phy config value
From: Sean Paul @ 2018-05-11 14:41 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1525861364-26323-2-git-send-email-hl@rock-chips.com>
On Wed, May 09, 2018 at 06:22:42PM +0800, Lin Huang wrote:
> the phy config values used to fix in dp firmware, but some boards
> need change these values to do training and get the better eye diagram
> result. So support that in phy driver.
>
FTR, I've previously reviewed this at
https://chromium-review.googlesource.com/c/chromiumos/third_party/kernel/+/985573
This patch should come _after_ the dt binding addition.
> Signed-off-by: Chris Zhong <zyw@rock-chips.com>
> Signed-off-by: Lin Huang <hl@rock-chips.com>
> ---
> Changes in v2:
> - update patch following Enric suggest
>
> drivers/phy/rockchip/phy-rockchip-typec.c | 284 +++++++++++++++++++-----------
> include/soc/rockchip/rockchip_phy_typec.h | 64 +++++++
> 2 files changed, 250 insertions(+), 98 deletions(-)
> create mode 100644 include/soc/rockchip/rockchip_phy_typec.h
>
/snip
> diff --git a/include/soc/rockchip/rockchip_phy_typec.h b/include/soc/rockchip/rockchip_phy_typec.h
> new file mode 100644
> index 0000000..4a328221
> --- /dev/null
> +++ b/include/soc/rockchip/rockchip_phy_typec.h
> @@ -0,0 +1,64 @@
> +/* SPDX-License-Identifier: GPL-2.0 */
> +/*
> + * Copyright (C) Fuzhou Rockchip Electronics Co.Ltd
> + * Author: Lin Huang <hl@rock-chips.com>
> + */
> +
> +#ifndef __SOC_ROCKCHIP_PHY_TYPEC_H
> +#define __SOC_ROCKCHIP_PHY_TYPEC_H
> +
> +struct usb3phy_reg {
> + u32 offset;
> + u32 enable_bit;
> + u32 write_enable;
> +};
> +
> +/**
> + * struct rockchip_usb3phy_port_cfg: usb3-phy port configuration.
> + * @reg: the base address for usb3-phy config.
> + * @typec_conn_dir: the register of type-c connector direction.
> + * @usb3tousb2_en: the register of type-c force usb2 to usb2 enable.
> + * @external_psm: the register of type-c phy external psm clock.
> + * @pipe_status: the register of type-c phy pipe status.
> + * @usb3_host_disable: the register of type-c usb3 host disable.
> + * @usb3_host_port: the register of type-c usb3 host port.
> + * @uphy_dp_sel: the register of type-c phy DP select control.
> + */
> +struct rockchip_usb3phy_port_cfg {
> + unsigned int reg;
> + struct usb3phy_reg typec_conn_dir;
> + struct usb3phy_reg usb3tousb2_en;
> + struct usb3phy_reg external_psm;
> + struct usb3phy_reg pipe_status;
> + struct usb3phy_reg usb3_host_disable;
> + struct usb3phy_reg usb3_host_port;
> + struct usb3phy_reg uphy_dp_sel;
> +};
> +
> +struct phy_config {
> + int swing;
> + int pe;
> +};
> +
> +struct rockchip_typec_phy {
> + struct device *dev;
> + void __iomem *base;
> + struct extcon_dev *extcon;
> + struct regmap *grf_regs;
> + struct clk *clk_core;
> + struct clk *clk_ref;
> + struct reset_control *uphy_rst;
> + struct reset_control *pipe_rst;
> + struct reset_control *tcphy_rst;
> + const struct rockchip_usb3phy_port_cfg *port_cfgs;
> + /* mutex to protect access to individual PHYs */
> + struct mutex lock;
> + struct phy_config config[3][4];
> + u8 need_software_training;
I thought we decided to always do sw training and then fallback to fw training.
If so, we don't need this.
Sean
> + bool flip;
> + u8 mode;
> + int (*typec_phy_config)(struct phy *phy, int link_rate,
> + int lanes, u8 swing, u8 pre_emp);
> +};
> +
> +#endif
> --
> 2.7.4
>
--
Sean Paul, Software Engineer, Google / Chromium OS
^ permalink raw reply
* [PATCH 2/3] perf/arm-cci: Remove pointless PMU disabling
From: Mark Rutland @ 2018-05-11 14:38 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <0278134025d69817f28ee50a704fb63715a397d8.1526048005.git.robin.murphy@arm.com>
On Fri, May 11, 2018 at 03:29:13PM +0100, Robin Murphy wrote:
> The CCI PMU driver bears some legacy remnants of the arm_pmu framework
> from when it was split in c6f85cb4305b ("bus: cci: move away from
> arm_pmu framework"). In particular this perf_pmu_{dis,en}able() dance
> around pmu->add which was fixed for arm_pmu in a9e469d1c89b
> ("drivers/perf: arm_pmu: remove pointless PMU disabling").
>
> For the exact same reasons (i.e. perf core already does this around the
> call anyway), give cci_pmu_add() the exact same change, which also
> prevents having to export those core functions to build it as a module.
>
> Signed-off-by: Robin Murphy <robin.murphy@arm.com>
Acked-by: Mark Rutland <mark.rutland@arm.com>
Mark.
> ---
> drivers/perf/arm-cci.c | 13 +++----------
> 1 file changed, 3 insertions(+), 10 deletions(-)
>
> diff --git a/drivers/perf/arm-cci.c b/drivers/perf/arm-cci.c
> index 53c774b20563..7029d8fe8f44 100644
> --- a/drivers/perf/arm-cci.c
> +++ b/drivers/perf/arm-cci.c
> @@ -1184,16 +1184,11 @@ static int cci_pmu_add(struct perf_event *event, int flags)
> struct cci_pmu_hw_events *hw_events = &cci_pmu->hw_events;
> struct hw_perf_event *hwc = &event->hw;
> int idx;
> - int err = 0;
> -
> - perf_pmu_disable(event->pmu);
>
> /* If we don't have a space for the counter then finish early. */
> idx = pmu_get_event_idx(hw_events, event);
> - if (idx < 0) {
> - err = idx;
> - goto out;
> - }
> + if (idx < 0)
> + return idx;
>
> event->hw.idx = idx;
> hw_events->events[idx] = event;
> @@ -1205,9 +1200,7 @@ static int cci_pmu_add(struct perf_event *event, int flags)
> /* Propagate our changes to the userspace mapping. */
> perf_event_update_userpage(event);
>
> -out:
> - perf_pmu_enable(event->pmu);
> - return err;
> + return 0;
> }
>
> static void cci_pmu_del(struct perf_event *event, int flags)
> --
> 2.17.0.dirty
>
^ permalink raw reply
* Delivery Status Notification (Failure)
From: Pintu Kumar @ 2018-05-11 14:37 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <f6f7b18644136323f4485d6123b330d0dde207a4.camel@pengutronix.de>
On Fri, May 11, 2018 at 6:34 PM, Lucas Stach <l.stach@pengutronix.de> wrote:
> Am Freitag, den 11.05.2018, 13:39 +0100 schrieb Russell King - ARM Linux:
>> On Fri, May 11, 2018 at 05:07:37PM +0530, Pintu Kumar wrote:
>> > Hi,
>> >
>> > I need one help.
>> > I am using i.MX7 Sabre board with kernel version 4.1.15
>> >
>> > Let's say I am interested in GPIO number: 21
>> > I wanted to set CPU affinity for particular GPIO->IRQ number, so I
>> > tried the below steps:
>> > root at 10:~# echo 21 > /sys/class/gpio/export
>> > root at 10:~# echo "rising" > /sys/class/gpio/gpio21/edge
>> > root at 10:~# cat /proc/interrupts | grep 21
>> > 47: 0 0 gpio-mxc 21 Edge gpiolib
>> > root at 10:~# cat /sys/class/gpio/gpio21/direction
>> > in
>> > root at 10:~# cat /proc/irq/47/smp_affinity
>> > 3
>> > root at 10:~# echo 2 > /proc/irq/47/smp_affinity
>> > -bash: echo: write error: Input/output error
>> >
>> > But I get input/output error.
>> > When I debug further, found that irq_can_set_affinity is returning 0:
>> > [ 0.000000] genirq: irq_can_set_affinity (0): balance: 1,
>> > irq_data.chip: a81b7e48, irq_set_affinity: (null)
>> > [ 0.000000] write_irq_affinity: FAIL
>> >
>> > I also tried first setting /proc/irq/default_smp_affinity to 2 (from 3).
>> > This change is working, but the smp_affinity setting for the new IRQ
>> > is not working.
>> >
>> > When I try to set smp_affinity for mmc0, then it works.
>> > # cat /proc/interrupts | grep mmc
>> > 295: 55 0 GPCV2 22 Edge mmc0
>> > 296: 0 0 GPCV2 23 Edge mmc1
>> > 297: 52 0 GPCV2 24 Edge mmc2
>> >
>> > root at 10:~# echo 2 > /proc/irq/295/smp_affinity
>> > root at 10:~#
>> >
>> >
>> > So, I wanted to know what are the conditions for which setting
>> > smp_affinity for an IRQ will work ?
>> >
>> > Is there any way by which I can set CPU affinity to a GPIO -> IRQ ?
>> > Whether, irq_set_affinity_hint() will work in this case ?
>>
>> IRQ affinity is only supported where interrupts are _directly_ wired to
>> the GIC. It's the GIC which does the interrupt steering to the CPU
>> cores.
>>
>> Interrupts on downstream interrupt controllers (such as GPCV2) have no
>> ability to be directed independently to other CPUs - the only possible
>> way to change the mapping is to move _all_ interrupts on that controller,
>> and any downstream chained interrupts at GIC level.
>>
>> Hence why Interrupt 295 has no irq_set_affinity function: there is no way
>> for the interrupt controller itself to change the affinity of the input
>> interrupt.
>
> The GPCv2 though is a secondary IRQ controller which has a 1:1 mapping
> of its input IRQs to the upstream GIC IRQ lines. Affinity can thus be
> handled by forwarding the request to the GIC by
> irq_chip_set_affinity_parent().
>
> As this is handled correctly in the upstream kernel since the first
> commit introducing support for the GPCv2, it seems the issue is only
> present in some downstream kernel.
>
OK. Thanks so much for your reply.
I saw some of the drivers using irq_set_affinity_hint() to force the
IRQ affinity to a particular CPU.
This is the sample:
{
cpumask_clear(mask);
cpumask_set_cpu(cpu, mask);
irq_set_affinity_hint(irq, mask);
}
Whether this logic will work for a particular GPIO pin ?
> Regards,
> Lucas
^ permalink raw reply
* [PATCH v2] arm: port KCOV to arm
From: Mark Rutland @ 2018-05-11 14:37 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180511143248.112484-1-dvyukov@google.com>
On Fri, May 11, 2018 at 04:32:48PM +0200, Dmitry Vyukov wrote:
> KCOV is code coverage collection facility used, in particular, by syzkaller
> system call fuzzer. There is some interest in using syzkaller on arm devices.
> So port KCOV to arm.
>
> On implementation level this merely declares that KCOV is supported and
> disables instrumentation of 3 special cases. Reasons for disabling are
> commented in code.
>
> Tested with qemu-system-arm/vexpress-a15.
>
> Signed-off-by: Dmitry Vyukov <dvyukov@google.com>
> Cc: Russell King <linux@armlinux.org.uk>
> Cc: Mark Rutland <mark.rutland@arm.com>
> Cc: Abbott Liu <liuwenliang@huawei.com>
> Cc: Catalin Marinas <catalin.marinas@arm.com>
> Cc: Koguchi Takuo <takuo.koguchi.sw@hitachi.com>
> Cc: linux-arm-kernel at lists.infradead.org
> Cc: linux-mm at kvack.org
> Cc: syzkaller at googlegroups.com
>
> ---
>
> Changes since v1:
> - remove disable of instrumentation for arch/arm/mm/fault.c
> - disable instrumentation of arch/arm/kvm/hyp/*
> - resort ARCH_HAS_KCOV alphabetically
> ---
> arch/arm/Kconfig | 3 ++-
> arch/arm/boot/compressed/Makefile | 3 +++
> arch/arm/kvm/hyp/Makefile | 8 ++++++++
> arch/arm/vdso/Makefile | 3 +++
> 4 files changed, 16 insertions(+), 1 deletion(-)
>
> diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
> index 3493f840e89c..34591796c36f 100644
> --- a/arch/arm/Kconfig
> +++ b/arch/arm/Kconfig
> @@ -8,9 +8,10 @@ config ARM
> select ARCH_HAS_DEVMEM_IS_ALLOWED
> select ARCH_HAS_ELF_RANDOMIZE
> select ARCH_HAS_FORTIFY_SOURCE
> + select ARCH_HAS_KCOV
> select ARCH_HAS_PTE_SPECIAL if ARM_LPAE
> - select ARCH_HAS_SET_MEMORY
> select ARCH_HAS_PHYS_TO_DMA
> + select ARCH_HAS_SET_MEMORY
> select ARCH_HAS_STRICT_KERNEL_RWX if MMU && !XIP_KERNEL
> select ARCH_HAS_STRICT_MODULE_RWX if MMU
> select ARCH_HAS_TICK_BROADCAST if GENERIC_CLOCKEVENTS_BROADCAST
It might be worth mentioning in the commit message that this also cleans
up an existing unordered entry in the arm Kconfig.
Otherwise, this looks good to me, assumign it goes in after my kcov core
fixups. FWIW:
Acked-by: Mark Rutland <mark.rutland@arm.com>
Thanks,
Mark.
> diff --git a/arch/arm/boot/compressed/Makefile b/arch/arm/boot/compressed/Makefile
> index 6a4e7341ecd3..5f5f081e4879 100644
> --- a/arch/arm/boot/compressed/Makefile
> +++ b/arch/arm/boot/compressed/Makefile
> @@ -25,6 +25,9 @@ endif
>
> GCOV_PROFILE := n
>
> +# Prevents link failures: __sanitizer_cov_trace_pc() is not linked in.
> +KCOV_INSTRUMENT := n
> +
> #
> # Architecture dependencies
> #
> diff --git a/arch/arm/kvm/hyp/Makefile b/arch/arm/kvm/hyp/Makefile
> index 7fc0638f263a..d2b5ec9c4b92 100644
> --- a/arch/arm/kvm/hyp/Makefile
> +++ b/arch/arm/kvm/hyp/Makefile
> @@ -23,3 +23,11 @@ obj-$(CONFIG_KVM_ARM_HOST) += hyp-entry.o
> obj-$(CONFIG_KVM_ARM_HOST) += switch.o
> CFLAGS_switch.o += $(CFLAGS_ARMV7VE)
> obj-$(CONFIG_KVM_ARM_HOST) += s2-setup.o
> +
> +# KVM code is run at a different exception code with a different map, so
> +# compiler instrumentation that inserts callbacks or checks into the code may
> +# cause crashes. Just disable it.
> +GCOV_PROFILE := n
> +KASAN_SANITIZE := n
> +UBSAN_SANITIZE := n
> +KCOV_INSTRUMENT := n
> diff --git a/arch/arm/vdso/Makefile b/arch/arm/vdso/Makefile
> index bb4118213fee..f4efff9d3afb 100644
> --- a/arch/arm/vdso/Makefile
> +++ b/arch/arm/vdso/Makefile
> @@ -30,6 +30,9 @@ CFLAGS_vgettimeofday.o = -O2
> # Disable gcov profiling for VDSO code
> GCOV_PROFILE := n
>
> +# Prevents link failures: __sanitizer_cov_trace_pc() is not linked in.
> +KCOV_INSTRUMENT := n
> +
> # Force dependency
> $(obj)/vdso.o : $(obj)/vdso.so
>
> --
> 2.17.0.441.gb46fe60e1d-goog
>
^ permalink raw reply
* [PATCH] arm: port KCOV to arm
From: Dmitry Vyukov @ 2018-05-11 14:37 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180508103016.GW16141@n2100.armlinux.org.uk>
On Tue, May 8, 2018 at 12:30 PM, Russell King - ARM Linux
<linux@armlinux.org.uk> wrote:
> On Thu, Apr 26, 2018 at 03:08:46PM +0200, Dmitry Vyukov wrote:
>> KCOV is code coverage collection facility used, in particular, by syzkaller
>> system call fuzzer. There is some interest in using syzkaller on arm devices.
>> So port KCOV to arm.
>>
>> On implementation level this merely declares that KCOV is supported and
>> disables instrumentation of 3 special cases. Reasons for disabling are
>> commented in code.
>>
>> Tested with qemu-system-arm/vexpress-a15.
>>
>> Signed-off-by: Dmitry Vyukov <dvyukov@google.com>
>> Cc: Russell King <linux@armlinux.org.uk>
>> Cc: Mark Rutland <mark.rutland@arm.com>
>> Cc: Abbott Liu <liuwenliang@huawei.com>
>> Cc: Catalin Marinas <catalin.marinas@arm.com>
>> Cc: Koguchi Takuo <takuo.koguchi.sw@hitachi.com>
>> Cc: Atul Prakash <atulp@google.com>
>> Cc: linux at armlinux.org.uk
>> Cc: linux-arm-kernel at lists.infradead.org
>> Cc: syzkaller at googlegroups.com
>> ---
>> arch/arm/Kconfig | 1 +
>> arch/arm/boot/compressed/Makefile | 3 +++
>> arch/arm/mm/Makefile | 4 ++++
>> arch/arm/vdso/Makefile | 3 +++
>> 4 files changed, 11 insertions(+)
>>
>> diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
>> index a7f8e7f4b88f..60558a6bb744 100644
>> --- a/arch/arm/Kconfig
>> +++ b/arch/arm/Kconfig
>> @@ -105,6 +105,7 @@ config ARM
>> select REFCOUNT_FULL
>> select RTC_LIB
>> select SYS_SUPPORTS_APM_EMULATION
>> + select ARCH_HAS_KCOV
>> # Above selects are sorted alphabetically; please add new ones
>> # according to that. Thanks.
>
> Please read this comment and rework your patch, thanks.
Now that Mark's fixes are in mm tree, I mailed v2 with the following changes:
Changes since v1:
- remove disable of instrumentation for arch/arm/mm/fault.c
- disable instrumentation of arch/arm/kvm/hyp/*
- resort ARCH_HAS_KCOV alphabetically
^ permalink raw reply
* [PATCH v4 3/3] ARM: dts: sun7i: Add support for the Ainol AW1 tablet
From: Maxime Ripard @ 2018-05-11 14:36 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180507220413.21990-3-contact@paulk.fr>
On Tue, May 08, 2018 at 12:04:13AM +0200, Paul Kocialkowski wrote:
> +++ b/arch/arm/boot/dts/sun7i-a20-ainol-aw1.dts
> @@ -0,0 +1,297 @@
> +/*
> + * SPDX-License-Identifier: (GPL-2.0+ OR MIT)
This really should be the first line, and with a C++ style comment, as
in:
// SPDX-License-Identifier: (GPL-2.0+ OR MIT)
/*
* Copyright (C) ...
See Documentation/process/license-rules.rst
> + backlight: backlight {
> + compatible = "pwm-backlight";
> + pwms = <&pwm 0 50000 PWM_POLARITY_INVERTED>;
> + brightness-levels = < 0 1 1 1 1 2 2 2
> + 2 3 3 3 3 4 4 4
> + 5 5 5 6 6 6 7 7
> + 8 8 8 9 9 9 10 10
> + 10 11 11 12 12 12 13 13
> + 14 14 14 15 15 16 16 17
> + 17 17 18 18 19 19 20 20
> + 21 21 21 22 22 23 23 24
> + 24 25 25 26 26 27 27 28
> + 28 29 30 30 31 31 32 32
> + 33 33 34 35 35 36 36 37
> + 38 38 39 39 40 41 41 42
> + 43 43 44 44 45 46 47 47
> + 48 49 49 50 51 51 52 53
> + 54 54 55 56 57 57 58 59
> + 60 61 61 62 63 64 65 65
> + 66 67 68 69 70 71 71 72
> + 73 74 75 76 77 78 79 80
> + 81 82 83 84 85 86 87 88
> + 89 90 91 92 93 94 95 96
> + 97 98 99 101 102 103 104 105
> + 106 108 109 110 111 112 114 115
> + 116 117 119 120 121 123 124 125
> + 127 128 129 131 132 133 135 136
> + 138 139 141 142 144 145 147 148
> + 150 151 153 154 156 157 159 161
> + 162 164 166 167 169 171 173 174
> + 176 178 180 181 183 185 187 189
> + 191 192 194 196 198 200 202 204
> + 206 208 210 212 214 216 219 221
> + 223 225 227 229 232 234 236 238
> + 241 242 244 246 248 250 253 255>;
You kind of overdid it here :)
What I meant to say before was that if you have 10 elements (and you
really should have something in that magnitude) each step should
increase the perceived brightness by 10%.
In this particular case, I really think having something close to <0 4
8 16 32 64 128 255> would be enough.
And in general, that kind of odd looking table without any more
context is just screaming for a comment :)
Maxime
--
Maxime Ripard, Bootlin (formerly Free Electrons)
Embedded Linux and Kernel engineering
https://bootlin.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20180511/7d3492e5/attachment.sig>
^ permalink raw reply
* [PATCH v2] arm: port KCOV to arm
From: Dmitry Vyukov @ 2018-05-11 14:36 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180511143248.112484-1-dvyukov@google.com>
On Fri, May 11, 2018 at 4:32 PM, Dmitry Vyukov <dvyukov@google.com> wrote:
> KCOV is code coverage collection facility used, in particular, by syzkaller
> system call fuzzer. There is some interest in using syzkaller on arm devices.
> So port KCOV to arm.
>
> On implementation level this merely declares that KCOV is supported and
> disables instrumentation of 3 special cases. Reasons for disabling are
> commented in code.
>
> Tested with qemu-system-arm/vexpress-a15.
>
> Signed-off-by: Dmitry Vyukov <dvyukov@google.com>
> Cc: Russell King <linux@armlinux.org.uk>
> Cc: Mark Rutland <mark.rutland@arm.com>
> Cc: Abbott Liu <liuwenliang@huawei.com>
> Cc: Catalin Marinas <catalin.marinas@arm.com>
> Cc: Koguchi Takuo <takuo.koguchi.sw@hitachi.com>
> Cc: linux-arm-kernel at lists.infradead.org
> Cc: linux-mm at kvack.org
> Cc: syzkaller at googlegroups.com
>
> ---
>
> Changes since v1:
> - remove disable of instrumentation for arch/arm/mm/fault.c
> - disable instrumentation of arch/arm/kvm/hyp/*
> - resort ARCH_HAS_KCOV alphabetically
Andrew, this is for MM tree because this depends on the following
patches in MM tree:
kcov: prefault the kcov_area
kcov: ensure irq code sees a valid area
sched/core / kcov: avoid kcov_area during task switch
> ---
> arch/arm/Kconfig | 3 ++-
> arch/arm/boot/compressed/Makefile | 3 +++
> arch/arm/kvm/hyp/Makefile | 8 ++++++++
> arch/arm/vdso/Makefile | 3 +++
> 4 files changed, 16 insertions(+), 1 deletion(-)
>
> diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
> index 3493f840e89c..34591796c36f 100644
> --- a/arch/arm/Kconfig
> +++ b/arch/arm/Kconfig
> @@ -8,9 +8,10 @@ config ARM
> select ARCH_HAS_DEVMEM_IS_ALLOWED
> select ARCH_HAS_ELF_RANDOMIZE
> select ARCH_HAS_FORTIFY_SOURCE
> + select ARCH_HAS_KCOV
> select ARCH_HAS_PTE_SPECIAL if ARM_LPAE
> - select ARCH_HAS_SET_MEMORY
> select ARCH_HAS_PHYS_TO_DMA
> + select ARCH_HAS_SET_MEMORY
> select ARCH_HAS_STRICT_KERNEL_RWX if MMU && !XIP_KERNEL
> select ARCH_HAS_STRICT_MODULE_RWX if MMU
> select ARCH_HAS_TICK_BROADCAST if GENERIC_CLOCKEVENTS_BROADCAST
> diff --git a/arch/arm/boot/compressed/Makefile b/arch/arm/boot/compressed/Makefile
> index 6a4e7341ecd3..5f5f081e4879 100644
> --- a/arch/arm/boot/compressed/Makefile
> +++ b/arch/arm/boot/compressed/Makefile
> @@ -25,6 +25,9 @@ endif
>
> GCOV_PROFILE := n
>
> +# Prevents link failures: __sanitizer_cov_trace_pc() is not linked in.
> +KCOV_INSTRUMENT := n
> +
> #
> # Architecture dependencies
> #
> diff --git a/arch/arm/kvm/hyp/Makefile b/arch/arm/kvm/hyp/Makefile
> index 7fc0638f263a..d2b5ec9c4b92 100644
> --- a/arch/arm/kvm/hyp/Makefile
> +++ b/arch/arm/kvm/hyp/Makefile
> @@ -23,3 +23,11 @@ obj-$(CONFIG_KVM_ARM_HOST) += hyp-entry.o
> obj-$(CONFIG_KVM_ARM_HOST) += switch.o
> CFLAGS_switch.o += $(CFLAGS_ARMV7VE)
> obj-$(CONFIG_KVM_ARM_HOST) += s2-setup.o
> +
> +# KVM code is run at a different exception code with a different map, so
> +# compiler instrumentation that inserts callbacks or checks into the code may
> +# cause crashes. Just disable it.
> +GCOV_PROFILE := n
> +KASAN_SANITIZE := n
> +UBSAN_SANITIZE := n
> +KCOV_INSTRUMENT := n
> diff --git a/arch/arm/vdso/Makefile b/arch/arm/vdso/Makefile
> index bb4118213fee..f4efff9d3afb 100644
> --- a/arch/arm/vdso/Makefile
> +++ b/arch/arm/vdso/Makefile
> @@ -30,6 +30,9 @@ CFLAGS_vgettimeofday.o = -O2
> # Disable gcov profiling for VDSO code
> GCOV_PROFILE := n
>
> +# Prevents link failures: __sanitizer_cov_trace_pc() is not linked in.
> +KCOV_INSTRUMENT := n
> +
> # Force dependency
> $(obj)/vdso.o : $(obj)/vdso.so
>
> --
> 2.17.0.441.gb46fe60e1d-goog
>
^ permalink raw reply
* [PATCH v2 1/4] drm/rockchip: add transfer function for cdn-dp
From: Sean Paul @ 2018-05-11 14:35 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1525861364-26323-1-git-send-email-hl@rock-chips.com>
On Wed, May 09, 2018 at 06:22:41PM +0800, Lin Huang wrote:
> From: Chris Zhong <zyw@rock-chips.com>
>
> We may support training outside firmware, so we need support
> dpcd read/write to get the message or do some setting with
> display.
>
> Signed-off-by: Chris Zhong <zyw@rock-chips.com>
> Signed-off-by: Lin Huang <hl@rock-chips.com>
FTR, I've already done one pass at [1]. All of those nits look fixed, so
Reviewed-by: Sean Paul <seanpaul@chromium.org>
[1]- https://chromium-review.googlesource.com/c/chromiumos/third_party/kernel/+/985572
> ---
>
> Changes in v2:
> - update patch following Enric suggest
>
> drivers/gpu/drm/rockchip/cdn-dp-core.c | 55 ++++++++++++++++++++++++----
> drivers/gpu/drm/rockchip/cdn-dp-core.h | 1 +
> drivers/gpu/drm/rockchip/cdn-dp-reg.c | 67 ++++++++++++++++++++++++++++++----
> drivers/gpu/drm/rockchip/cdn-dp-reg.h | 14 ++++++-
> 4 files changed, 120 insertions(+), 17 deletions(-)
>
> diff --git a/drivers/gpu/drm/rockchip/cdn-dp-core.c b/drivers/gpu/drm/rockchip/cdn-dp-core.c
> index c6fbdcd..cce64c1 100644
> --- a/drivers/gpu/drm/rockchip/cdn-dp-core.c
> +++ b/drivers/gpu/drm/rockchip/cdn-dp-core.c
> @@ -176,8 +176,8 @@ static int cdn_dp_get_sink_count(struct cdn_dp_device *dp, u8 *sink_count)
> u8 value;
>
> *sink_count = 0;
> - ret = cdn_dp_dpcd_read(dp, DP_SINK_COUNT, &value, 1);
> - if (ret)
> + ret = drm_dp_dpcd_read(&dp->aux, DP_SINK_COUNT, &value, 1);
> + if (ret < 0)
> return ret;
>
> *sink_count = DP_GET_SINK_COUNT(value);
> @@ -374,9 +374,9 @@ static int cdn_dp_get_sink_capability(struct cdn_dp_device *dp)
> if (!cdn_dp_check_sink_connection(dp))
> return -ENODEV;
>
> - ret = cdn_dp_dpcd_read(dp, DP_DPCD_REV, dp->dpcd,
> - DP_RECEIVER_CAP_SIZE);
> - if (ret) {
> + ret = drm_dp_dpcd_read(&dp->aux, DP_DPCD_REV, dp->dpcd,
> + sizeof(dp->dpcd));
> + if (ret < 0) {
> DRM_DEV_ERROR(dp->dev, "Failed to get caps %d\n", ret);
> return ret;
> }
> @@ -582,8 +582,8 @@ static bool cdn_dp_check_link_status(struct cdn_dp_device *dp)
> if (!port || !dp->link.rate || !dp->link.num_lanes)
> return false;
>
> - if (cdn_dp_dpcd_read(dp, DP_LANE0_1_STATUS, link_status,
> - DP_LINK_STATUS_SIZE)) {
> + if (drm_dp_dpcd_read_link_status(&dp->aux, link_status) !=
> + DP_LINK_STATUS_SIZE) {
> DRM_ERROR("Failed to get link status\n");
> return false;
> }
> @@ -1012,6 +1012,40 @@ static int cdn_dp_pd_event(struct notifier_block *nb,
> return NOTIFY_DONE;
> }
>
> +static ssize_t cdn_dp_aux_transfer(struct drm_dp_aux *aux,
> + struct drm_dp_aux_msg *msg)
> +{
> + struct cdn_dp_device *dp = container_of(aux, struct cdn_dp_device, aux);
> + int ret;
> + u8 status;
> +
> + switch (msg->request & ~DP_AUX_I2C_MOT) {
> + case DP_AUX_NATIVE_WRITE:
> + case DP_AUX_I2C_WRITE:
> + case DP_AUX_I2C_WRITE_STATUS_UPDATE:
> + ret = cdn_dp_dpcd_write(dp, msg->address, msg->buffer,
> + msg->size);
> + break;
> + case DP_AUX_NATIVE_READ:
> + case DP_AUX_I2C_READ:
> + ret = cdn_dp_dpcd_read(dp, msg->address, msg->buffer,
> + msg->size);
> + break;
> + default:
> + return -EINVAL;
> + }
> +
> + status = cdn_dp_get_aux_status(dp);
> + if (status == AUX_STATUS_ACK)
> + msg->reply = DP_AUX_NATIVE_REPLY_ACK;
> + else if (status == AUX_STATUS_NACK)
> + msg->reply = DP_AUX_NATIVE_REPLY_NACK;
> + else if (status == AUX_STATUS_DEFER)
> + msg->reply = DP_AUX_NATIVE_REPLY_DEFER;
> +
> + return ret;
> +}
> +
> static int cdn_dp_bind(struct device *dev, struct device *master, void *data)
> {
> struct cdn_dp_device *dp = dev_get_drvdata(dev);
> @@ -1030,6 +1064,13 @@ static int cdn_dp_bind(struct device *dev, struct device *master, void *data)
> dp->active = false;
> dp->active_port = -1;
> dp->fw_loaded = false;
> + dp->aux.name = "DP-AUX";
> + dp->aux.transfer = cdn_dp_aux_transfer;
> + dp->aux.dev = dev;
> +
> + ret = drm_dp_aux_register(&dp->aux);
> + if (ret)
> + return ret;
>
> INIT_WORK(&dp->event_work, cdn_dp_pd_event_work);
>
> diff --git a/drivers/gpu/drm/rockchip/cdn-dp-core.h b/drivers/gpu/drm/rockchip/cdn-dp-core.h
> index f57e296..46159b2 100644
> --- a/drivers/gpu/drm/rockchip/cdn-dp-core.h
> +++ b/drivers/gpu/drm/rockchip/cdn-dp-core.h
> @@ -78,6 +78,7 @@ struct cdn_dp_device {
> struct platform_device *audio_pdev;
> struct work_struct event_work;
> struct edid *edid;
> + struct drm_dp_aux aux;
>
> struct mutex lock;
> bool connected;
> diff --git a/drivers/gpu/drm/rockchip/cdn-dp-reg.c b/drivers/gpu/drm/rockchip/cdn-dp-reg.c
> index eb3042c..afdfda0 100644
> --- a/drivers/gpu/drm/rockchip/cdn-dp-reg.c
> +++ b/drivers/gpu/drm/rockchip/cdn-dp-reg.c
> @@ -221,7 +221,11 @@ static int cdn_dp_reg_write_bit(struct cdn_dp_device *dp, u16 addr,
> sizeof(field), field);
> }
>
> -int cdn_dp_dpcd_read(struct cdn_dp_device *dp, u32 addr, u8 *data, u16 len)
> +/*
> + * Returns the number of bytes transferred on success, or a negative error
> + * code on failure. -ETIMEDOUT is returned if mailbox message not send success;
> + */
> +ssize_t cdn_dp_dpcd_read(struct cdn_dp_device *dp, u32 addr, u8 *data, u16 len)
> {
> u8 msg[5], reg[5];
> int ret;
> @@ -247,24 +251,40 @@ int cdn_dp_dpcd_read(struct cdn_dp_device *dp, u32 addr, u8 *data, u16 len)
> goto err_dpcd_read;
>
> ret = cdn_dp_mailbox_read_receive(dp, data, len);
> + if (!ret)
> + return len;
>
> err_dpcd_read:
> + DRM_DEV_ERROR(dp->dev, "dpcd read failed: %d\n", ret);
> return ret;
> }
>
> -int cdn_dp_dpcd_write(struct cdn_dp_device *dp, u32 addr, u8 value)
> +#define CDN_AUX_HEADER_SIZE 5
> +#define CDN_AUX_MSG_SIZE 20
> +/*
> + * Returns the number of bytes transferred on success, or a negative error
> + * code on failure. -ETIMEDOUT is returned if mailbox message not send success;
> + * -EINVAL is return if get the wrong data size after message send.
> + */
> +ssize_t cdn_dp_dpcd_write(struct cdn_dp_device *dp, u32 addr, u8 *data, u16 len)
> {
> - u8 msg[6], reg[5];
> + u8 msg[CDN_AUX_MSG_SIZE + CDN_AUX_HEADER_SIZE];
> + u8 reg[CDN_AUX_HEADER_SIZE];
> int ret;
>
> - msg[0] = 0;
> - msg[1] = 1;
> + if (WARN_ON(len > CDN_AUX_MSG_SIZE) || WARN_ON(len <= 0))
> + return -EINVAL;
> +
> + msg[0] = (len >> 8) & 0xff;
> + msg[1] = len & 0xff;
> msg[2] = (addr >> 16) & 0xff;
> msg[3] = (addr >> 8) & 0xff;
> msg[4] = addr & 0xff;
> - msg[5] = value;
> +
> + memcpy(msg + CDN_AUX_HEADER_SIZE, data, len);
> +
> ret = cdn_dp_mailbox_send(dp, MB_MODULE_ID_DP_TX, DPTX_WRITE_DPCD,
> - sizeof(msg), msg);
> + CDN_AUX_HEADER_SIZE + len, msg);
> if (ret)
> goto err_dpcd_write;
>
> @@ -277,8 +297,12 @@ int cdn_dp_dpcd_write(struct cdn_dp_device *dp, u32 addr, u8 value)
> if (ret)
> goto err_dpcd_write;
>
> - if (addr != (reg[2] << 16 | reg[3] << 8 | reg[4]))
> + if ((len != (reg[0] << 8 | reg[1])) ||
> + (addr != (reg[2] << 16 | reg[3] << 8 | reg[4]))) {
> ret = -EINVAL;
> + } else {
> + return len;
> + }
>
> err_dpcd_write:
> if (ret)
> @@ -286,6 +310,33 @@ int cdn_dp_dpcd_write(struct cdn_dp_device *dp, u32 addr, u8 value)
> return ret;
> }
>
> +int cdn_dp_get_aux_status(struct cdn_dp_device *dp)
> +{
> + u8 status;
> + int ret;
> +
> + ret = cdn_dp_mailbox_send(dp, MB_MODULE_ID_DP_TX,
> + DPTX_GET_LAST_AUX_STAUS, 0, NULL);
> + if (ret)
> + goto err_get_hpd;
> +
> + ret = cdn_dp_mailbox_validate_receive(dp, MB_MODULE_ID_DP_TX,
> + DPTX_GET_LAST_AUX_STAUS,
> + sizeof(status));
> + if (ret)
> + goto err_get_hpd;
> +
> + ret = cdn_dp_mailbox_read_receive(dp, &status, sizeof(status));
> + if (ret)
> + goto err_get_hpd;
> +
> + return status;
> +
> +err_get_hpd:
> + DRM_DEV_ERROR(dp->dev, "get aux status failed: %d\n", ret);
> + return ret;
> +}
> +
> int cdn_dp_load_firmware(struct cdn_dp_device *dp, const u32 *i_mem,
> u32 i_size, const u32 *d_mem, u32 d_size)
> {
> diff --git a/drivers/gpu/drm/rockchip/cdn-dp-reg.h b/drivers/gpu/drm/rockchip/cdn-dp-reg.h
> index c4bbb4a83..6580b11 100644
> --- a/drivers/gpu/drm/rockchip/cdn-dp-reg.h
> +++ b/drivers/gpu/drm/rockchip/cdn-dp-reg.h
> @@ -328,6 +328,13 @@
> #define GENERAL_BUS_SETTINGS 0x03
> #define GENERAL_TEST_ACCESS 0x04
>
> +/* AUX status*/
> +#define AUX_STATUS_ACK 0
> +#define AUX_STATUS_NACK 1
> +#define AUX_STATUS_DEFER 2
> +#define AUX_STATUS_SINK_ERROR 3
> +#define AUX_STATUS_BUS_ERROR 4
> +
> #define DPTX_SET_POWER_MNG 0x00
> #define DPTX_SET_HOST_CAPABILITIES 0x01
> #define DPTX_GET_EDID 0x02
> @@ -469,8 +476,11 @@ int cdn_dp_set_host_cap(struct cdn_dp_device *dp, u8 lanes, bool flip);
> int cdn_dp_event_config(struct cdn_dp_device *dp);
> u32 cdn_dp_get_event(struct cdn_dp_device *dp);
> int cdn_dp_get_hpd_status(struct cdn_dp_device *dp);
> -int cdn_dp_dpcd_write(struct cdn_dp_device *dp, u32 addr, u8 value);
> -int cdn_dp_dpcd_read(struct cdn_dp_device *dp, u32 addr, u8 *data, u16 len);
> +ssize_t cdn_dp_dpcd_write(struct cdn_dp_device *dp, u32 addr,
> + u8 *data, u16 len);
> +ssize_t cdn_dp_dpcd_read(struct cdn_dp_device *dp, u32 addr,
> + u8 *data, u16 len);
> +int cdn_dp_get_aux_status(struct cdn_dp_device *dp);
> int cdn_dp_get_edid_block(void *dp, u8 *edid,
> unsigned int block, size_t length);
> int cdn_dp_train_link(struct cdn_dp_device *dp);
> --
> 2.7.4
>
--
Sean Paul, Software Engineer, Google / Chromium OS
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox