* [PATCH 3/3] iommu: armsmmu: set iommu ops for rpmsg bus
From: Bjorn Andersson @ 2018-05-07 19:28 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <57fc5480-c57e-dfd3-e6af-5e5bba296430@arm.com>
On Fri, Mar 2, 2018 at 8:59 AM, Robin Murphy <robin.murphy@arm.com> wrote:
> On 02/03/18 14:55, srinivas.kandagatla at linaro.org wrote:
>>
>> From: Srinivas Kandagatla <srinivas.kandagatla@linaro.org>
>>
>> On Qualcomm SoCs, ADSP exposes many functions like audio and
>> others. These services need iommu access to allocate any
>> memory for the DSP. As these drivers are childeren of
>> rpmsg bus, able to allocate memory from iommus is basic
>> requirement. So set arm smmu iommu ops for this bus type.
>
Forgot to answer this and the dma_ops patch seems to be going in the
right direction.
>
> Documentation/rpmsg.txt: "Every rpmsg device is a communication channel with
> a remote processor (thus rpmsg devices are called channels)."
>
> I'd instinctively assume that a remote processor already has its own memory,
> and that a communication channel doesn't somehow go directly through an
> IOMMU, so that "basic requirement" seems like a pretty big assumption.
>
As of today rpmsg exclusively uses system memory for implementing the
communication fifos, but this memory is owned/handled by the rpmsg
bus. The need here is for drivers on top of the rpmsg_bus,
implementing some application-level protocol that requires indirection
buffers; e.g. to achieve zero copy of audio or image buffers that the
remote processor is expected to operate on. In this case the device
sitting on top of the rpmsg bus will have to map the buffer to the
appropriate context and can then send application specific control
requests referencing this mapping.
As different parts of the firmware might operate in different contexts
it's not feasible to utilize the parent's (the rpmsg_bus) context for
these indirection buffers.
>> Signed-off-by: Srinivas Kandagatla <srinivas.kandagatla@linaro.org>
>> ---
>> drivers/iommu/arm-smmu.c | 5 +++++
>> 1 file changed, 5 insertions(+)
>>
>> diff --git a/drivers/iommu/arm-smmu.c b/drivers/iommu/arm-smmu.c
>> index e6920d32ac9e..9b63489af15c 100644
>> --- a/drivers/iommu/arm-smmu.c
>> +++ b/drivers/iommu/arm-smmu.c
>> @@ -53,6 +53,7 @@
>> #include <linux/spinlock.h>
>> #include <linux/amba/bus.h>
>> +#include <linux/rpmsg.h>
>> #include "io-pgtable.h"
>> #include "arm-smmu-regs.h"
>> @@ -2168,6 +2169,10 @@ static void arm_smmu_bus_init(void)
>> bus_set_iommu(&pci_bus_type, &arm_smmu_ops);
>> }
>> #endif
>> +#ifdef CONFIG_RPMSG
>
>
> Ah, so this will at least build OK with RPMSG=m, but I doubt it does what
> you want it to in that case.
>
Things have been refactored but the core has remained tristate,
causing extra head aches in various areas. I think it's very
reasonable to review the rpmsg config options and make CONFIG_RPMSG
bool.
So with the addition of making CONFIG_RPMSG bool the patch has my Acked-by.
That said I'm generally concerned about the first probed iommu
implementation assigning itself as the sole iommu implementation for
all busses, but I guess we haven't yet hit the point where there are
different iommu implementations in a single SoC?
Regards,
Bjorn
^ permalink raw reply
* [RFC PATCH] driver core: make deferring probe forever optional
From: Rob Herring @ 2018-05-07 19:55 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180507183106.GF2259@tuxbook-pro>
On Mon, May 7, 2018 at 1:31 PM, Bjorn Andersson
<bjorn.andersson@linaro.org> wrote:
> On Tue 01 May 14:31 PDT 2018, Rob Herring wrote:
>
>> Deferred probe will currently wait forever on dependent devices to probe,
>> but sometimes a driver will never exist. It's also not always critical for
>> a driver to exist. Platforms can rely on default configuration from the
>> bootloader or reset defaults for things such as pinctrl and power domains.
>
> But how do you know if this is the case?
Because the platform worked before adding the dependency in the dts.
>> This is often the case with initial platform support until various drivers
>> get enabled.
>
> Can you please name platform that has enough support for Alexander to
> care about backwards and forwards compatibility but lacks a pinctrl
> driver.
Alex will have to answer that. I do agree pinctrl drivers shouldn't be
that hard because it is all just translating a bunch of pin data into
one-time (mostly) register writes, so it shouldn't take that long to
implement support. OTOH, maybe a pinctrl driver is low priority
because nothing needs it yet. Either a given board works with the
defaults and only some new board needs to change things or you don't
need pinctrl until low power modes are implemented. However, power
domains have the same problem and it can take years for those to get
proper support.
Alex proposed declaring dts files stable and then enforcing
compatibility after that point. If anyone believes that will work,
then please send a patch marking all the platforms in the kernel tree
that are stable.
>> There's at least 2 scenarios where deferred probe can render
>> a platform broken. Both involve using a DT which has more devices and
>> dependencies than the kernel supports. The 1st case is a driver may be
>> disabled in the kernel config.
>
> I agree that there is a chance that you _might_ get some parts of the
> system working by relying on the boot loader configuration, but
> misconfiguration issues applies to any other fundamental providers, such
> as clocks, regulators, power domains and gpios as well.
If it is only a chance, then perhaps we shouldn't allow things
upstream without proper drivers for all these things. That will only
give users the wrong impression.
>> The 2nd case is the kernel version may
>> simply not have the dependent driver. This can happen if using a newer DT
>> (provided by firmware perhaps) with a stable kernel version.
>>
>
> As above, this is in no way limited to pinctrl drivers.
Yes, I wasn't trying to imply that with this patch. I was just
starting with 1 example. IOMMUs (which essentially is already doing
what this patch does) and power domains are the main other 2. Clocks
is an obvious one too, but from the discussion I referenced that
problem is a bit different as platforms change from dummy fixed-clocks
to a real clock controller driver. That will need a different
solution.
>> Unfortunately, this change breaks with modules as we have no way of
>> knowing when modules are done loading. One possibility is to make this
>> opt in or out based on compatible strings rather than at a subsystem level.
>> Ideally this information could be extracted automatically somehow. OTOH,
>> maybe the lists are pretty small. There's only a handful of subsystems
>> that can be optional, and then only so many drivers in those that can be
>> modules (at least for pinctrl, many drivers are built-in only).
>>
>
> On the Qualcomm platform most drivers are tristate and on most platforms
> there are size restrictions in the proprietary boot loader preventing us
> from boot the kernel after switching all these frameworks from tristate
> to bool (which feels like a more appropriate solution than your hack).
BTW, QCom platforms are almost the only ones with pinctrl drivers as
modules. They are also happen to be PIA to configure correctly for a
board.
However, I would like a solution that works with modules. It would be
nice to know when userspace finished processing all the coldplug
uevents. That would be sufficient to support modules. I researched
that a bit and it doesn't seem the kernel can tell when that has
happened.
>
>> Cc: Alexander Graf <agraf@suse.de>
>> Signed-off-by: Rob Herring <robh@kernel.org>
>> ---
>> This patch came out of a discussion on the ARM boot-architecture
>> list[1] about DT forwards and backwards compatibility issues. There are
>> issues with newer DTs breaking on older, stable kernels. Some of these
>> are difficult to solve, but cases of optional devices not having
>> kernel support should be solvable.
>>
>
> There are two cases here:
> 1) DT contains compatibles that isn't supported by the kernel. In this
> case the associated device will remain in the probe deferral list and
> user space won't know about the device.
>
> 2) DT contains compatibles known to the kernel but has new optional
> properties that makes things functional or works around hardware bugs.
>
>> I tested this on a RPi3 B with the pinctrl driver forced off. With this
>> change, the MMC/SD and UART drivers can function without the pinctrl
>> driver.
>>
>
> Cool, so what about graphics, audio, networking, usb and all the other
> things that people actually expect when they _use_ a distro?
I often care about none of those things. When I do, I'd rather boot to
a working console with those broken than have to debug why the kernel
panicked.
>> [1] https://lists.linaro.org/pipermail/boot-architecture/2018-April/000466.html
>>
>> drivers/base/dd.c | 16 ++++++++++++++++
>> drivers/pinctrl/devicetree.c | 2 +-
>> include/linux/device.h | 2 ++
>> 3 files changed, 19 insertions(+), 1 deletion(-)
>>
>> diff --git a/drivers/base/dd.c b/drivers/base/dd.c
>> index c9f54089429b..5848808b9d7a 100644
>> --- a/drivers/base/dd.c
>> +++ b/drivers/base/dd.c
>> @@ -226,6 +226,15 @@ void device_unblock_probing(void)
>> driver_deferred_probe_trigger();
>> }
>>
>> +
>> +int driver_deferred_probe_optional(void)
>> +{
>> + if (initcalls_done)
>> + return -ENODEV;
>
> You forgot the humongous printout here that tells the users that we do
> not want any bug reports related hardware not working as expected after
> this point.
I assume you were joking, but I would happily add a WARN here. Spewing
new warnings while still booting is a better UX than just panicking.
Ideally, it would be once per missing dependency.
Rob
^ permalink raw reply
* [PATCH v3 3/3] ARM: dts: sun7i: Add support for the Ainol AW1 tablet
From: Paul Kocialkowski @ 2018-05-07 20:15 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180507071931.tebv45yxrojxxkeb@flea>
Hi,
Le lundi 07 mai 2018 ? 09:19 +0200, Maxime Ripard a ?crit :
> Hi,
>
> On Sun, May 06, 2018 at 11:49:01PM +0200, Paul Kocialkowski wrote:
> > This adds support for the Ainol AW1, an A20-based 7" tablet from Ainol.
> >
> > The following board-specific features are supported:
> > * LCD panel
> > * Backlight
> > * USB OTG
> > * Buttons
> > * Touchscreen (doesn't work without non-free firmware)
> > * Accelerometer
> > * Battery
> >
> > The following are untested:
> > * Audio output
> > * Audio speakers
> > * USB via SPCI connector
> >
> > The following are not supported:
> > * Wi-Fi
> > * Bluetooth
> > * NAND
> > * Audio via SPCI connector
> > * Audio via Bluetooth I2S
> >
> > Signed-off-by: Paul Kocialkowski <contact@paulk.fr>
> > ---
> > arch/arm/boot/dts/Makefile | 1 +
> > arch/arm/boot/dts/sun7i-a20-ainol-aw1.dts | 275 ++++++++++++++++++++++
> > 2 files changed, 276 insertions(+)
> > create mode 100644 arch/arm/boot/dts/sun7i-a20-ainol-aw1.dts
> >
> > diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile
> > index 7e2424957809..4a80971f2bc9 100644
> > --- a/arch/arm/boot/dts/Makefile
> > +++ b/arch/arm/boot/dts/Makefile
> > @@ -946,6 +946,7 @@ dtb-$(CONFIG_MACH_SUN6I) += \
> > sun6i-a31s-sinovoip-bpi-m2.dtb \
> > sun6i-a31s-yones-toptech-bs1078-v2.dtb
> > dtb-$(CONFIG_MACH_SUN7I) += \
> > + sun7i-a20-ainol-aw1.dtb \
> > sun7i-a20-bananapi.dtb \
> > sun7i-a20-bananapi-m1-plus.dtb \
> > sun7i-a20-bananapro.dtb \
> > diff --git a/arch/arm/boot/dts/sun7i-a20-ainol-aw1.dts b/arch/arm/boot/dts/sun7i-a20-ainol-aw1.dts
> > new file mode 100644
> > index 000000000000..9a1d54a9f9a0
> > --- /dev/null
> > +++ b/arch/arm/boot/dts/sun7i-a20-ainol-aw1.dts
> > @@ -0,0 +1,275 @@
> > +/*
> > + * Copyright (C) 2018 Paul Kocialkowski <contact@paulk.fr>
> > + *
> > + * SPDX-License-Identifier: GPL-2.0+
>
> This should be your first line.
Alright then. For reference, I based this off sun8i-h3-libretech-all-h3-
cc.dts, that has the copyright first.
> Also, we usually license our DT under
> a dual license (GPL and MIT) so that other projects (like FreeBSD) can
> use them as well, instead of duplicating them. It would be great if
> you'd consider it.
Ah, I didn't think of BSD-licensed systems like FreeBSD off-hand.
Since they are apparently working on ARM support, it's probably worth
publishing this under a non-copyleft license.
> > + */
> > +
> > +/dts-v1/;
> > +#include "sun7i-a20.dtsi"
> > +#include "sunxi-common-regulators.dtsi"
> > +
> > +#include <dt-bindings/gpio/gpio.h>
> > +#include <dt-bindings/input/input.h>
> > +#include <dt-bindings/interrupt-controller/irq.h>
> > +#include <dt-bindings/pwm/pwm.h>
> > +
> > +/ {
> > + model = "Ainol AW1";
> > + compatible = "ainol,ainol-aw1", "allwinner,sun7i-a20";
> > +
> > + aliases {
> > + serial0 = &uart0;
> > + };
> > +
> > + chosen {
> > + stdout-path = "serial0:115200n8";
> > + };
> > +
> > + backlight: backlight {
> > + compatible = "pwm-backlight";
> > + pwms = <&pwm 0 50000 PWM_POLARITY_INVERTED>;
> > + brightness-levels = <0 10 20 30 40 50 60 70 80 90 100>;
>
> The increase in perceived brightness should be linear. Usually, for
> PWMs backed backlight, an exponential list is a much better
> approximation.
Thanks for the hint, it never occurred to me that pwm duty cycle was not
linear with brightness, but that makes sense. I'll give that a try (on
255 values instead of 10 to keep some level of precision in low
brightness). The way to go here is probably use a base-255 logarithm
such as: duty cycle = range * log(i+1)/log(255) with i the linear
brightness value (0 to 255) and range the amplitude of our values (that
gets divided by the maximum brightness, so it's really up to hardware
precision at this point). I'll go with a range of 255 as well.
> > + default-brightness-level = <5>;
> > + enable-gpios = <&pio 7 7 GPIO_ACTIVE_HIGH>; /* PH7 */
> > + };
> > +
> > + panel: panel {
> > + compatible = "innolux,at070tn90";
> > + #address-cells = <1>;
> > + #size-cells = <0>;
> > + power-supply = <&panel_power>;
> > + backlight = <&backlight>;
> > +
> > + port at 0 {
> > + reg = <0>;
> > + #address-cells = <1>;
> > + #size-cells = <0>;
> > +
> > + panel_input: endpoint at 0 {
> > + reg = <0>;
> > + remote-endpoint = <&tcon0_out_panel>;
> > + };
> > + };
> > + };
> > +
> > + panel_power: panel_power {
> > + compatible = "regulator-fixed";
> > + pinctrl-names = "default";
> > + pinctrl-0 = <&panel_power_pin>;
> > + regulator-name = "panel-power";
> > + regulator-min-microvolt = <10400000>;
> > + regulator-max-microvolt = <10400000>;
> > + gpio = <&pio 7 8 GPIO_ACTIVE_HIGH>; /* PH8 */
> > + enable-active-high;
> > + regulator-boot-on;
> > + };
> > +};
> > +
> > +&codec {
> > + allwinner,pa-gpios = <&pio 7 15 GPIO_ACTIVE_HIGH>; /* PH15 */
> > + status = "okay";
> > +};
> > +
> > +&cpu0 {
> > + cpu-supply = <®_dcdc2>;
> > +};
> > +
> > +&de {
> > + status = "okay";
> > +};
> > +
> > +&ehci0 {
> > + status = "okay";
> > +};
> > +
> > +&ehci1 {
> > + status = "okay";
> > +};
> > +
> > +&i2c0 {
> > + pinctrl-names = "default";
> > + pinctrl-0 = <&i2c0_pins_a>;
> > + status = "okay";
> > +
> > + axp209: pmic at 34 {
> > + reg = <0x34>;
> > + interrupt-parent = <&nmi_intc>;
> > + interrupts = <0 IRQ_TYPE_LEVEL_LOW>;
> > + };
> > +};
> > +
> > +&i2c1 {
> > + pinctrl-names = "default";
> > + pinctrl-0 = <&i2c1_pins_a>;
> > + status = "okay";
> > +
> > + lis3dh: accelerometer at 18 {
> > + compatible = "st,lis3dh-accel";
> > + reg = <0x18>;
> > + vdd-supply = <®_vcc3v3>;
> > + vddio-supply = <®_vcc3v3>;
> > + st,drdy-int-pin = <1>;
> > + };
> > +};
> > +
> > +&i2c2 {
> > + pinctrl-names = "default";
> > + pinctrl-0 = <&i2c2_pins_a>;
> > + status = "okay";
> > + clock-frequency = <400000>;
> > +
> > + gsl1680: touchscreen at 40 {
> > + compatible = "silead,gsl1680";
> > + reg = <0x40>;
> > + interrupt-parent = <&pio>;
> > + interrupts = <7 21 IRQ_TYPE_EDGE_FALLING>; /* EINT21 (PH21) */
> > + power-gpios = <&pio 7 20 GPIO_ACTIVE_HIGH>; /* PH20 */
> > + firmware-name = "gsl1680-ainol-aw1.fw";
> > + touchscreen-size-x = <480>;
> > + touchscreen-size-y = <800>;
> > + touchscreen-swapped-x-y;
> > + touchscreen-inverted-y;
> > + silead,max-fingers = <5>;
> > + };
> > +};
> > +
> > +&lradc {
> > + vref-supply = <®_ldo2>;
> > + status = "okay";
> > +
> > + button at 571 {
> > + label = "Volume Up";
> > + linux,code = <KEY_VOLUMEUP>;
> > + channel = <0>;
> > + voltage = <571428>;
> > + };
> > +
> > + button at 761 {
> > + label = "Volume Down";
> > + linux,code = <KEY_VOLUMEDOWN>;
> > + channel = <0>;
> > + voltage = <761904>;
> > + };
> > +
> > + button at 952 {
> > + label = "Home";
> > + linux,code = <KEY_HOME>;
> > + channel = <0>;
> > + voltage = <952380>;
> > + };
> > +};
> > +
> > +&mmc0 {
> > + pinctrl-names = "default";
> > + pinctrl-0 = <&mmc0_pins_a>;
> > + vmmc-supply = <®_vcc3v3>;
>
> You have the regulators described in your DT, you'd better use them
> instead of the one coming from sunxi-common-regulators.dtsi.
Well, according to the reference A20 design, the mmc pins and the card
are powered by the 3.3V power rail, that comes from a regular step-down
regulator sourcing from IPSOUT, so I don't see what regulator I should
better use. Do you have a suggestion?
> > + bus-width = <4>;
> > + cd-gpios = <&pio 7 1 GPIO_ACTIVE_HIGH>; /* PH1 */
> > + cd-inverted;
> > + status = "okay";
> > +};
> > +
> > +&ohci0 {
> > + status = "okay";
> > +};
> > +
> > +&ohci1 {
> > + status = "okay";
> > +};
> > +
> > +&otg_sram {
> > + status = "okay";
> > +};
> > +
> > +&pio {
> > + panel_power_pin: panel_power_pin at 0 {
> > + pins = "PH8";
> > + function = "gpio_out";
> > + };
> > +};
>
> You don't need that pinctrl node.
I'll get rid of it then. You mentioned that regulator-simple uses the
old GPIO API, so I assumed it meant that a pinctrl node is still needed.
For reference, it uses of_get_named_gpio (not the devm-managed fashion).
Cheers,
Paul
--
Developer of free digital technology and hardware support.
Website: https://www.paulk.fr/
Coding blog: https://code.paulk.fr/
Git repositories: https://git.paulk.fr/ https://git.code.paulk.fr/
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: This is a digitally signed message part
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20180507/0e18e2ce/attachment.sig>
^ permalink raw reply
* [PATCH v2 0/6] ARM: clang support
From: Stefan Agner @ 2018-05-07 20:24 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180325180959.28008-1-stefan@agner.ch>
On 25.03.2018 20:09, Stefan Agner wrote:
> This patchset fixes some remaining issues when building the ARM
> architecture using LLVM/clang. The patchset requires the following
> kbuild change:
> https://lkml.org/lkml/2018/3/19/1756
>
> With that patch and this patchset applied and I can successfully
> build (and boot) the multi_v7_defconfig with 4.16-rc5 using clang
> 5.0.1 and 6.0.0.
Russel, Arnd, any comment on this patch series? How can we get it
merged?
I was thinking patch 1 through armsoc since that is the way previous
patches have been merged.
Note sure about patch 2, Russel can you comment on Thierry's email?
And patch 3 through 6 through Russel's tree?
--
Stefan
>
> This version also adds a patch to mitigate a often printed warning
> about duplicate 'const' declaration specifier when using get_user().
>
> Stefan Agner (6):
> bus: arm-cci: use asm unreachable
> efi/libstub/arm: add support for building with clang
> ARM: trusted_foundations: do not use naked function
> ARM: drop no-thumb-interwork in EABI mode
> ARM: add support for building ARM kernel with clang
> ARM: uaccess: remove const to avoid duplicate specifier
>
> arch/arm/Makefile | 2 +-
> arch/arm/boot/compressed/Makefile | 2 +-
> arch/arm/firmware/trusted_foundations.c | 14 +++++++++-----
> arch/arm/include/asm/uaccess.h | 2 +-
> drivers/bus/arm-cci.c | 2 --
> drivers/firmware/efi/libstub/Makefile | 3 ++-
> 6 files changed, 14 insertions(+), 11 deletions(-)
^ permalink raw reply
* [PATCH v2 18/27] coresight: catu: Add support for scatter gather tables
From: Mathieu Poirier @ 2018-05-07 20:25 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1525165857-11096-19-git-send-email-suzuki.poulose@arm.com>
On Tue, May 01, 2018 at 10:10:48AM +0100, Suzuki K Poulose wrote:
> This patch adds the support for setting up a SG table for use
> by the CATU. We reuse the tmc_sg_table to represent the table/data
> pages, even though the table format is different.
>
> Similar to ETR SG table, CATU uses a 4KB page size for data buffers
> as well as page tables. All table entries are 64bit wide and have
> the following format:
>
> 63 12 1 0
> x-----------------------------------x
> | Address [63-12] | SBZ | V |
> x-----------------------------------x
>
> Where [V] -> 0 - Pointer is invalid
> 1 - Pointer is Valid
>
> CATU uses only first half of the page for data page pointers.
> i.e, single table page will only have 256 page pointers, addressing
> upto 1MB of data. The second half of a table page contains only two
> pointers at the end of the page (i.e, pointers at index 510 and 511),
> which are used as links to the "Previous" and "Next" page tables
> respectively.
>
> The first table page has an "Invalid" previous pointer and the
> next pointer entry points to the second page table if there is one.
> Similarly the last table page has an "Invalid" next pointer to
> indicate the end of the table chain.
>
> We create a circular buffer (i.e, first_table[prev] => last_table
> and last_table[next] => first_table) by default and provide
> helpers to make the buffer linear from a given offset. When we
> set the buffer to linear, we also mark the "pointers" in the
> outside the given "range" as invalid. We have to do this only
> for the starting and ending tables, as we disconnect the other
> table by invalidating the links. This will allow the ETR buf to
> be restored from a given offset with any size.
>
> Cc: Mathieu Poirier <mathieu.poirier@linaro.org>
> Signed-off-by: Suzuki K Poulose <suzuki.poulose@arm.com>
> ---
> drivers/hwtracing/coresight/coresight-catu.c | 409 +++++++++++++++++++++++++++
> 1 file changed, 409 insertions(+)
>
> diff --git a/drivers/hwtracing/coresight/coresight-catu.c b/drivers/hwtracing/coresight/coresight-catu.c
> index 2cd69a6..4cc2928 100644
> --- a/drivers/hwtracing/coresight/coresight-catu.c
> +++ b/drivers/hwtracing/coresight/coresight-catu.c
> @@ -16,10 +16,419 @@
>
> #include "coresight-catu.h"
> #include "coresight-priv.h"
> +#include "coresight-tmc.h"
>
> #define csdev_to_catu_drvdata(csdev) \
> dev_get_drvdata(csdev->dev.parent)
>
> +/*
> + * CATU uses a page size of 4KB for page tables as well as data pages.
> + * Each 64bit entry in the table has the following format.
> + *
> + * 63 12 1 0
> + * ------------------------------------
> + * | Address [63-12] | SBZ | V|
> + * ------------------------------------
> + *
> + * Where bit[0] V indicates if the address is valid or not.
> + * Each 4K table pages have upto 256 data page pointers, taking upto 2K
> + * size. There are two Link pointers, pointing to the previous and next
> + * table pages respectively at the end of the 4K page. (i.e, entry 510
> + * and 511).
> + * E.g, a table of two pages could look like :
> + *
> + * Table Page 0 Table Page 1
> + * SLADDR ===> x------------------x x--> x-----------------x
> + * INADDR ->| Page 0 | V | | | Page 256 | V | <- INADDR+1M
> + * |------------------| | |-----------------|
> + * INADDR+4K ->| Page 1 | V | | | |
> + * |------------------| | |-----------------|
> + * | Page 2 | V | | | |
> + * |------------------| | |-----------------|
> + * | ... | V | | | ... |
> + * |------------------| | |-----------------|
> + * INADDR+1020K| Page 255 | V | | | Page 511 | V |
> + * SLADDR+2K==>|------------------| | |-----------------|
> + * | UNUSED | | | | |
> + * |------------------| | | |
> + * | UNUSED | | | | |
> + * |------------------| | | |
> + * | ... | | | | |
> + * |------------------| | |-----------------|
> + * | IGNORED | 0 | | | Table Page 0| 1 |
> + * |------------------| | |-----------------|
> + * | Table Page 1| 1 |--x | IGNORED | 0 |
> + * x------------------x x-----------------x
> + * SLADDR+4K==>
> + *
> + * The base input address (used by the ETR, programmed in INADDR_{LO,HI})
> + * must be aligned to 1MB (the size addressable by a single page table).
> + * The CATU maps INADDR{LO:HI} to the first page in the table pointed
> + * to by SLADDR{LO:HI} and so on.
> + *
> + */
> +typedef u64 cate_t;
> +
> +#define CATU_PAGE_SHIFT 12
> +#define CATU_PAGE_SIZE (1UL << CATU_PAGE_SHIFT)
> +#define CATU_PAGES_PER_SYSPAGE (PAGE_SIZE / CATU_PAGE_SIZE)
> +
> +/* Page pointers are only allocated in the first 2K half */
> +#define CATU_PTRS_PER_PAGE ((CATU_PAGE_SIZE >> 1) / sizeof(cate_t))
> +#define CATU_PTRS_PER_SYSPAGE (CATU_PAGES_PER_SYSPAGE * CATU_PTRS_PER_PAGE)
> +#define CATU_LINK_PREV ((CATU_PAGE_SIZE / sizeof(cate_t)) - 2)
> +#define CATU_LINK_NEXT ((CATU_PAGE_SIZE / sizeof(cate_t)) - 1)
> +
> +#define CATU_ADDR_SHIFT 12
> +#define CATU_ADDR_MASK ~(((cate_t)1 << CATU_ADDR_SHIFT) - 1)
> +#define CATU_ENTRY_VALID ((cate_t)0x1)
> +#define CATU_ENTRY_INVALID ((cate_t)0)
> +#define CATU_VALID_ENTRY(addr) \
> + (((cate_t)(addr) & CATU_ADDR_MASK) | CATU_ENTRY_VALID)
> +#define CATU_ENTRY_ADDR(entry) ((cate_t)(entry) & ~((cate_t)CATU_ENTRY_VALID))
> +
> +/*
> + * Index into the CATU entry pointing to the page within
> + * the table. Each table entry can point to a 4KB page, with
> + * a total of 255 entries in the table adding upto 1MB per table.
> + *
> + * So, bits 19:12 gives you the index of the entry in
> + * the table.
> + */
> +static inline unsigned long catu_offset_to_entry_idx(unsigned long offset)
> +{
> + return (offset & (SZ_1M - 1)) >> 12;
> +}
> +
> +static inline void catu_update_state(cate_t *catep, int valid)
> +{
> + *catep &= ~CATU_ENTRY_VALID;
> + *catep |= valid ? CATU_ENTRY_VALID : CATU_ENTRY_INVALID;
> +}
> +
> +/*
> + * Update the valid bit for a given range of indices [start, end)
> + * in the given table @table.
> + */
> +static inline void catu_update_state_range(cate_t *table, int start,
> + int end, int valid)
Indentation
> +{
> + int i;
> + cate_t *pentry = &table[start];
> + cate_t state = valid ? CATU_ENTRY_VALID : CATU_ENTRY_INVALID;
> +
> + /* Limit the "end" to maximum range */
> + if (end > CATU_PTRS_PER_PAGE)
> + end = CATU_PTRS_PER_PAGE;
> +
> + for (i = start; i < end; i++, pentry++) {
> + *pentry &= ~(cate_t)CATU_ENTRY_VALID;
> + *pentry |= state;
> + }
> +}
> +
> +/*
> + * Update valid bit for all entries in the range [start, end)
> + */
> +static inline void
> +catu_table_update_offset_range(cate_t *table,
> + unsigned long start,
> + unsigned long end,
> + int valid)
> +{
> + catu_update_state_range(table,
> + catu_offset_to_entry_idx(start),
> + catu_offset_to_entry_idx(end),
> + valid);
> +}
> +
> +static inline void catu_table_update_prev(cate_t *table, int valid)
> +{
> + catu_update_state(&table[CATU_LINK_PREV], valid);
> +}
> +
> +static inline void catu_table_update_next(cate_t *table, int valid)
> +{
> + catu_update_state(&table[CATU_LINK_NEXT], valid);
> +}
> +
> +/*
> + * catu_get_table : Retrieve the table pointers for the given @offset
> + * within the buffer. The buffer is wrapped around to a valid offset.
> + *
> + * Returns : The CPU virtual address for the beginning of the table
> + * containing the data page pointer for @offset. If @daddrp is not NULL,
> + * @daddrp points the DMA address of the beginning of the table.
> + */
> +static inline cate_t *catu_get_table(struct tmc_sg_table *catu_table,
> + unsigned long offset,
> + dma_addr_t *daddrp)
> +{
> + unsigned long buf_size = tmc_sg_table_buf_size(catu_table);
> + unsigned int table_nr, pg_idx, pg_offset;
> + struct tmc_pages *table_pages = &catu_table->table_pages;
> + void *ptr;
> +
> + /* Make sure offset is within the range */
> + offset %= buf_size;
> +
> + /*
> + * Each table can address 1MB and a single kernel page can
> + * contain "CATU_PAGES_PER_SYSPAGE" CATU tables.
> + */
> + table_nr = offset >> 20;
> + /* Find the table page where the table_nr lies in */
> + pg_idx = table_nr / CATU_PAGES_PER_SYSPAGE;
> + pg_offset = (table_nr % CATU_PAGES_PER_SYSPAGE) * CATU_PAGE_SIZE;
> + if (daddrp)
> + *daddrp = table_pages->daddrs[pg_idx] + pg_offset;
> + ptr = page_address(table_pages->pages[pg_idx]);
> + return (cate_t *)((unsigned long)ptr + pg_offset);
> +}
> +
> +#ifdef CATU_DEBUG
> +static void catu_dump_table(struct tmc_sg_table *catu_table)
> +{
> + int i;
> + cate_t *table;
> + unsigned long table_end, buf_size, offset = 0;
> +
> + buf_size = tmc_sg_table_buf_size(catu_table);
> + dev_dbg(catu_table->dev,
> + "Dump table %p, tdaddr: %llx\n",
> + catu_table, catu_table->table_daddr);
> +
> + while (offset < buf_size) {
> + table_end = offset + SZ_1M < buf_size ?
> + offset + SZ_1M : buf_size;
> + table = catu_get_table(catu_table, offset, NULL);
> + for (i = 0; offset < table_end; i++, offset += CATU_PAGE_SIZE)
> + dev_dbg(catu_table->dev, "%d: %llx\n", i, table[i]);
> + dev_dbg(catu_table->dev, "Prev : %llx, Next: %llx\n",
> + table[CATU_LINK_PREV], table[CATU_LINK_NEXT]);
> + dev_dbg(catu_table->dev, "== End of sub-table ===");
> + }
> + dev_dbg(catu_table->dev, "== End of Table ===");
> +}
> +
> +#else
> +static inline void catu_dump_table(struct tmc_sg_table *catu_table)
> +{
> +}
> +#endif
I think this approach is better than peppering the code with #ifdefs as it was
done for ETR. Please fix that to replicate what you've done here.
> +
> +/*
> + * catu_update_table: Update the start and end tables for the
> + * region [base, base + size) to, validate/invalidate the pointers
> + * outside the area.
> + *
> + * CATU expects the table base address (SLADDR) aligned to 4K.
> + * If the @base is not aligned to 1MB, we should mark all the
> + * pointers in the start table before @base "INVALID".
> + * Similarly all pointers in the last table beyond (@base + @size)
> + * should be marked INVALID.
> + * The table page containinig the "base" is marked first (by
> + * marking the previous link INVALID) and the table page
> + * containing "base + size" is marked last (by marking next
> + * link INVALID).
> + * By default we have to update the state of pointers
> + * for offsets in the range :
> + * Start table: [0, ALIGN_DOWN(base))
> + * End table : [ALIGN(end + 1), SZ_1M)
> + * But, if we the buffer wraps around and ends in the same table
> + * as the "base", (i,e this should be :
> + * [ALIGN(end + 1), base)
> + *
> + * Returns the dma_address for the start_table, which can be set as
> + * SLADDR.
> + */
> +static dma_addr_t catu_update_table(struct tmc_sg_table *catu_table,
> + u64 base, u64 size, int valid)
> +{
> + cate_t *start_table, *end_table;
> + dma_addr_t taddr;
> + u64 buf_size, end = base + size - 1;
> + unsigned int start_off = 0; /* Offset to begin in start_table */
> + unsigned int end_off = SZ_1M; /* Offset to end in the end_table */
> +
> + buf_size = tmc_sg_table_buf_size(catu_table);
> + if (end > buf_size)
> + end -= buf_size;
> +
> + /* Get both the virtual and the DMA address of the first table */
> + start_table = catu_get_table(catu_table, base, &taddr);
> + end_table = catu_get_table(catu_table, end, NULL);
> +
> + /* Update the "PREV" link for the starting table */
> + catu_table_update_prev(start_table, valid);
> +
> + /* Update the "NEXT" link only if this is not the start_table */
> + if (end_table != start_table) {
> + catu_table_update_next(end_table, valid);
> + } else if (end < base) {
> + /*
> + * If the buffer has wrapped around and we have got the
> + * "end" before "base" in the same table, we need to be
> + * extra careful. We only need to invalidate the ptrs
> + * in between the "end" and "base".
> + */
> + start_off = ALIGN(end, CATU_PAGE_SIZE);
> + end_off = 0;
> + }
> +
> + /* Update the pointers in the starting table before the "base" */
> + catu_table_update_offset_range(start_table,
> + start_off,
> + base,
> + valid);
> + if (end_off)
> + catu_table_update_offset_range(end_table,
> + end,
> + end_off,
> + valid);
> +
> + catu_dump_table(catu_table);
> + return taddr;
> +}
> +
> +/*
> + * catu_set_table : Set the buffer to act as linear buffer
> + * from @base of @size.
> + *
> + * Returns : The DMA address for the table containing base.
> + * This can then be programmed into SLADDR.
> + */
> +static dma_addr_t
> +catu_set_table(struct tmc_sg_table *catu_table, u64 base, u64 size)
> +{
> + /* Make all the entries outside this range invalid */
> + dma_addr_t sladdr = catu_update_table(catu_table, base, size, 0);
> + /* Sync the changes to memory for CATU */
> + tmc_sg_table_sync_table(catu_table);
> + return sladdr;
> +}
> +
> +static void __maybe_unused
> +catu_reset_table(struct tmc_sg_table *catu_table, u64 base, u64 size)
> +{
> + /* Make all the entries outside this range valid */
> + (void)catu_update_table(catu_table, base, size, 1);
> +}
> +
> +/*
> + * catu_populate_table : Populate the given CATU table.
> + * The table is always populated as a circular table.
> + * i.e, the "prev" link of the "first" table points to the "last"
> + * table and the "next" link of the "last" table points to the
> + * "first" table. The buffer should be made linear by calling
> + * catu_set_table().
> + */
> +static void
> +catu_populate_table(struct tmc_sg_table *catu_table)
> +{
> + int i, dpidx, s_dpidx;
> + unsigned long offset, buf_size, last_offset;
> + dma_addr_t data_daddr;
> + dma_addr_t prev_taddr, next_taddr, cur_taddr;
> + cate_t *table_ptr, *next_table;
> +
> + buf_size = tmc_sg_table_buf_size(catu_table);
> + dpidx = s_dpidx = 0;
> + offset = 0;
> +
> + table_ptr = catu_get_table(catu_table, 0, &cur_taddr);
> + /*
> + * Use the address of the "last" table as the "prev" link
> + * for the first table.
> + */
> + (void)catu_get_table(catu_table, buf_size - 1, &prev_taddr);
> +
> + while (offset < buf_size) {
> + /*
> + * The @offset is always 1M aligned here and we have an
> + * empty table @table_ptr to fill. Each table can address
> + * upto 1MB data buffer. The last table may have fewer
> + * entries if the buffer size is not aligned.
> + */
> + last_offset = (offset + SZ_1M) < buf_size ?
> + (offset + SZ_1M) : buf_size;
> + for (i = 0; offset < last_offset; i++) {
> +
> + data_daddr = catu_table->data_pages.daddrs[dpidx] +
> + s_dpidx * CATU_PAGE_SIZE;
> +#ifdef CATU_DEBUG
> + dev_dbg(catu_table->dev,
> + "[table %5d:%03d] 0x%llx\n",
> + (offset >> 20), i, data_daddr);
> +#endif
I'm not a fan of adding #ifdefs in the code like this. I think it is better to
have a wrapper (that resolves to nothing if CATU_DEBUG is not defined) and
handle the output in there.
> + table_ptr[i] = CATU_VALID_ENTRY(data_daddr);
> + offset += CATU_PAGE_SIZE;
> + /* Move the pointers for data pages */
> + s_dpidx = (s_dpidx + 1) % CATU_PAGES_PER_SYSPAGE;
> + if (s_dpidx == 0)
> + dpidx++;
> + }
> +
> + /*
> + * If we have finished all the valid entries, fill the rest of
> + * the table (i.e, last table page) with invalid entries,
> + * to fail the lookups.
> + */
> + if (offset == buf_size)
> + catu_table_update_offset_range(table_ptr,
> + offset - 1, SZ_1M, 0);
> +
> + /*
> + * Find the next table by looking up the table that contains
> + * @offset. For the last table, this will return the very
> + * first table (as the offset == buf_size, and thus returns
> + * the table for offset = 0.)
> + */
> + next_table = catu_get_table(catu_table, offset, &next_taddr);
> + table_ptr[CATU_LINK_PREV] = CATU_VALID_ENTRY(prev_taddr);
> + table_ptr[CATU_LINK_NEXT] = CATU_VALID_ENTRY(next_taddr);
> +
> +#ifdef CATU_DEBUG
> + dev_dbg(catu_table->dev,
> + "[table%5d]: Cur: 0x%llx Prev: 0x%llx, Next: 0x%llx\n",
> + (offset >> 20) - 1, cur_taddr, prev_taddr, next_taddr);
> +#endif
> +
> + /* Update the prev/next addresses */
> + prev_taddr = cur_taddr;
> + cur_taddr = next_taddr;
> + table_ptr = next_table;
> + }
> +}
> +
> +static struct tmc_sg_table __maybe_unused *
> +catu_init_sg_table(struct device *catu_dev, int node,
> + ssize_t size, void **pages)
> +{
> + int nr_tpages;
> + struct tmc_sg_table *catu_table;
> +
> + /*
> + * Each table can address upto 1MB and we can have
> + * CATU_PAGES_PER_SYSPAGE tables in a system page.
> + */
> + nr_tpages = DIV_ROUND_UP(size, SZ_1M) / CATU_PAGES_PER_SYSPAGE;
> + catu_table = tmc_alloc_sg_table(catu_dev, node, nr_tpages,
> + size >> PAGE_SHIFT, pages);
> + if (IS_ERR(catu_table))
> + return catu_table;
> +
> + catu_populate_table(catu_table);
> + /* Make the buf linear from offset 0 */
> + (void)catu_set_table(catu_table, 0, size);
> +
> + dev_dbg(catu_dev,
> + "Setup table %p, size %ldKB, %d table pages\n",
> + catu_table, (unsigned long)size >> 10, nr_tpages);
I think this should also be wrapped in a special output debug function.
> + catu_dump_table(catu_table);
> + return catu_table;
> +}
> +
> coresight_simple_reg32(struct catu_drvdata, control, CATU_CONTROL);
> coresight_simple_reg32(struct catu_drvdata, status, CATU_STATUS);
> coresight_simple_reg32(struct catu_drvdata, mode, CATU_MODE);
> --
> 2.7.4
>
^ permalink raw reply
* [PATCHv2 3/3] arm64: dts: stratix10: add sdram ecc
From: Dinh Nguyen @ 2018-05-07 20:50 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180507165943.GE733@pd.tnic>
On Mon, May 7, 2018 at 11:59 AM, Borislav Petkov <bp@alien8.de> wrote:
> On Fri, Apr 27, 2018 at 01:37:18PM -0500, thor.thayer at linux.intel.com wrote:
>> From: Thor Thayer <thor.thayer@linux.intel.com>
>>
>> Add the Stratix10 ECC Manager and SDRAM EDAC nodes to the
>> device tree.
>>
>> Signed-off-by: Thor Thayer <thor.thayer@linux.intel.com>
>> ---
>> v2 Remove unused SysMan syscon
>> Remove unused SDRAM ECC register defines
>> Remove unused address, size and range from device tree.
>> ---
>> arch/arm64/boot/dts/altera/socfpga_stratix10.dtsi | 12 ++++++++++++
>> 1 file changed, 12 insertions(+)
>>
>> diff --git a/arch/arm64/boot/dts/altera/socfpga_stratix10.dtsi b/arch/arm64/boot/dts/altera/socfpga_stratix10.dtsi
>> index c89d0c307f8d..688391f3bf78 100644
>> --- a/arch/arm64/boot/dts/altera/socfpga_stratix10.dtsi
>> +++ b/arch/arm64/boot/dts/altera/socfpga_stratix10.dtsi
>> @@ -387,5 +387,17 @@
>> resets = <&rst WATCHDOG3_RESET>;
>> status = "disabled";
>> };
>> +
>> + eccmgr {
>> + compatible = "altr,socfpga-s10-ecc-manager";
>> + interrupts = <0 15 4>, <0 95 4>;
>> + interrupt-controller;
>> + #interrupt-cells = <2>;
>> +
>> + sdramedac {
>> + compatible = "altr,sdram-edac-s10";
>> + interrupts = <16 4>, <48 4>;
>> + };
>> + };
>> };
>> };
>> --
>> 2.7.4
>>
>> --
>
> Hey Rob,
>
> ACK here too?
>
> Also, this one:
>
> https://lkml.kernel.org/r/1525203036-21774-1-git-send-email-thor.thayer at linux.intel.com
>
> ?
>
Just in case you need mine, since the edits here match what was in the
in the bindings doc.
Acked-by: Dinh Nguyen <dinguyen@kernel.org>
Thanks,
Dinh
^ permalink raw reply
* [PATCH] iio: adc: stm32-dfsdm: Add support for stm32mp1
From: Rob Herring @ 2018-05-07 20:51 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1525266323-4922-1-git-send-email-fabrice.gasnier@st.com>
On Wed, May 02, 2018 at 03:05:23PM +0200, Fabrice Gasnier wrote:
> Add support for DFSDM (Digital Filter For Sigma Delta Modulators)
> to STM32MP1. This variant is close to STM32H7 DFSDM, it implements
> 6 filter instances. Registers map is also increased.
>
> Signed-off-by: Fabrice Gasnier <fabrice.gasnier@st.com>
> ---
> .../bindings/iio/adc/st,stm32-dfsdm-adc.txt | 7 +++++--
> drivers/iio/adc/stm32-dfsdm-core.c | 21 +++++++++++++++++++++
> 2 files changed, 26 insertions(+), 2 deletions(-)
Reviewed-by: Rob Herring <robh@kernel.org>
^ permalink raw reply
* [PATCH v7 1/6] dt-bindings: define vendor prefix for Wi2Wi, Inc.
From: Rob Herring @ 2018-05-07 20:54 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <7c03df30ceec8b171ab88787c1ef9556c96b30f6.1525340143.git.hns@goldelico.com>
On Thu, May 03, 2018 at 11:35:46AM +0200, H. Nikolaus Schaller wrote:
> Introduce vendor prefix for Wi2Wi, Inc. for W2SG0004 GPS module
> and W2CBW003 Bluetooth/WiFi combo (CSR/Marvell).
>
> Signed-off-by: H. Nikolaus Schaller <hns@goldelico.com>
> Acked-by: Rob Herring <robh@kernel.org>
> ---
> Documentation/devicetree/bindings/vendor-prefixes.txt | 1 +
> 1 file changed, 1 insertion(+)
Applied this one so you don't have to keep sending it.
Rob
^ permalink raw reply
* [PATCH v2 2/2] ARM: dts: am335x: Replaced register offsets with defines
From: Tony Lindgren @ 2018-05-07 21:02 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180505085921.5513-3-cquast@baylibre.com>
Hi,
Thanks for updating these, adding Linus Walleij to Cc too.
* Christina Quast <cquast@baylibre.com> [180505 09:02]:
> The defines are taken from dt-bindings/pinctrl/am335x.h
If we're going to replace all of these, I'd go a step further
where we make pinctrl-single use the newish #pinctrl-cells but
set it to 2 instead of 1. Then set the pull flags as one value
using the generic pinctrl defines and the second value being
the selected mux mode.
Then the offset really should be from the padconf mux area,
not from the control module base. And then we would just have
a new macro for these being:
AM33XX_PINCTRL(AM335X_PIN_UART1_RXD, PIN_INPUT, MUX_MODE0)
Where the PIN_INPUT ideally would be a Linux generic define.
Otherwise we'd be churning these same files over and
over.
Regards,
Tony
^ permalink raw reply
* [PATCH 3/7] pinctrl: sunxi: add support for H6 R_PIO pin controller
From: Rob Herring @ 2018-05-07 21:05 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180503183847.11046-4-icenowy@aosc.io>
On Fri, May 04, 2018 at 02:38:43AM +0800, Icenowy Zheng wrote:
> Allwinner H6 SoC has a R_PIO pin controller like other Allwinner SoCs,
> which controls the PL and PM pin banks.
>
> Add support for it.
>
> Signed-off-by: Icenowy Zheng <icenowy@aosc.io>
> ---
> .../bindings/pinctrl/allwinner,sunxi-pinctrl.txt | 1 +
Acked-by: Rob Herring <robh@kernel.org>
In the future, please split bindings to separate patches.
> drivers/pinctrl/sunxi/Kconfig | 4 +
> drivers/pinctrl/sunxi/Makefile | 1 +
> drivers/pinctrl/sunxi/pinctrl-sun50i-h6-r.c | 128 +++++++++++++++++++++
> 4 files changed, 134 insertions(+)
> create mode 100644 drivers/pinctrl/sunxi/pinctrl-sun50i-h6-r.c
^ permalink raw reply
* [PATCH v2 0/6] ARM: clang support
From: Arnd Bergmann @ 2018-05-07 21:09 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <d099cce32d109caefd2fc39196ce5bca@agner.ch>
On Mon, May 7, 2018 at 4:24 PM, Stefan Agner <stefan@agner.ch> wrote:
> On 25.03.2018 20:09, Stefan Agner wrote:
>> This patchset fixes some remaining issues when building the ARM
>> architecture using LLVM/clang. The patchset requires the following
>> kbuild change:
>> https://lkml.org/lkml/2018/3/19/1756
>>
>> With that patch and this patchset applied and I can successfully
>> build (and boot) the multi_v7_defconfig with 4.16-rc5 using clang
>> 5.0.1 and 6.0.0.
>
> Russel, Arnd, any comment on this patch series? How can we get it
> merged?
>
> I was thinking patch 1 through armsoc since that is the way previous
> patches have been merged.
Please resend it to arm at kernel.org.
Lorenzo, Robin, Will, Suzuki: could one of you look at the patch and
provide an Ack
and maybe send a patch to add a MAINTAINERS file entry for the the
arm-cci driver to make it less ambiguous to who's responsible for it?
I know very little about the code and don't want to be the main person having
to decide if a patch can go in or not.
> Note sure about patch 2,
This should be up to Ard to pick up or comment on. I think I had
previously suggested a similar patch to him, but don't remember
what happened to that.
> Russel can you comment on Thierry's email?
>
> And patch 3 through 6 through Russel's tree?
Sounds good to me. Please submit those through
http://www.arm.linux.org.uk/developer/patches/ once they are
ready. I think patches 4, 5 and 6 are good to go in, while patch
3 has an unfinished discussion.
It might also be a good idea to pick up the CONFIG_FRAME_POINTER
problem and disable that option for clang based builds now, using
the new infrastructure we have for detecting compiler features at
Kconfig time.
Arnd
^ permalink raw reply
* [PATCHv2 3/3] arm64: dts: stratix10: add sdram ecc
From: Dinh Nguyen @ 2018-05-07 21:10 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CADhT+weyJFhMyPbVt0n2EVe7OpeHHLjhxjw7aY2_8GBZ-7h7Xg@mail.gmail.com>
Hi Boris,
On Mon, May 7, 2018 at 3:50 PM, Dinh Nguyen <dinh.linux@gmail.com> wrote:
> On Mon, May 7, 2018 at 11:59 AM, Borislav Petkov <bp@alien8.de> wrote:
>> On Fri, Apr 27, 2018 at 01:37:18PM -0500, thor.thayer at linux.intel.com wrote:
>>> From: Thor Thayer <thor.thayer@linux.intel.com>
>>>
>>> Add the Stratix10 ECC Manager and SDRAM EDAC nodes to the
>>> device tree.
>>>
>>> Signed-off-by: Thor Thayer <thor.thayer@linux.intel.com>
>>> ---
>>> v2 Remove unused SysMan syscon
>>> Remove unused SDRAM ECC register defines
>>> Remove unused address, size and range from device tree.
>>> ---
>>> arch/arm64/boot/dts/altera/socfpga_stratix10.dtsi | 12 ++++++++++++
>>> 1 file changed, 12 insertions(+)
>>>
>>> diff --git a/arch/arm64/boot/dts/altera/socfpga_stratix10.dtsi b/arch/arm64/boot/dts/altera/socfpga_stratix10.dtsi
>>> index c89d0c307f8d..688391f3bf78 100644
>>> --- a/arch/arm64/boot/dts/altera/socfpga_stratix10.dtsi
>>> +++ b/arch/arm64/boot/dts/altera/socfpga_stratix10.dtsi
>>> @@ -387,5 +387,17 @@
>>> resets = <&rst WATCHDOG3_RESET>;
>>> status = "disabled";
>>> };
>>> +
>>> + eccmgr {
>>> + compatible = "altr,socfpga-s10-ecc-manager";
>>> + interrupts = <0 15 4>, <0 95 4>;
>>> + interrupt-controller;
>>> + #interrupt-cells = <2>;
>>> +
>>> + sdramedac {
>>> + compatible = "altr,sdram-edac-s10";
>>> + interrupts = <16 4>, <48 4>;
>>> + };
>>> + };
>>> };
>>> };
>>> --
>>> 2.7.4
>>>
>>> --
>>
>> Hey Rob,
>>
>> ACK here too?
>>
>> Also, this one:
>>
>> https://lkml.kernel.org/r/1525203036-21774-1-git-send-email-thor.thayer at linux.intel.com
>>
>> ?
>>
>
> Just in case you need mine, since the edits here match what was in the
> in the bindings doc.
>
> Acked-by: Dinh Nguyen <dinguyen@kernel.org>
>
Do you mind if I take this patch through arm-soc? I have a pull
request to arm-soc that is pending.
http://lists.infradead.org/pipermail/linux-arm-kernel/2018-April/573133.html
In that pull request, there is a patch:
https://git.kernel.org/pub/scm/linux/kernel/git/dinguyen/linux.git/commit/?h=socfpga_for_next_v4.18_dts_v1&id=d93101abe41e9596555a0f7f6f775e543b71c441
This patch has some major changes to the socfpga_stratix10.dtsi file
that will conflict with this patch.
If it's okay with you.
Thanks,
Dinh
^ permalink raw reply
* [PATCH v3 2/3] platform: move the early platform device support to arch/sh
From: Arnd Bergmann @ 2018-05-07 21:13 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180504132731.14574-3-brgl@bgdev.pl>
On Fri, May 4, 2018 at 9:27 AM, Bartosz Golaszewski <brgl@bgdev.pl> wrote:
> From: Bartosz Golaszewski <bgolaszewski@baylibre.com>
>
> SuperH is the only user of the current implementation of early platform
> device support. We want to introduce a more robust approach to early
> probing. As the first step - move all the current early platform code
> to arch/sh.
>
> In order not to export internal drivers/base functions to arch code for
> this temporary solution - copy the two needed routines for driver
> matching from drivers/base/platform.c to arch/sh/drivers/platform_early.c.
>
> Also: call early_platform_cleanup() from subsys_initcall() so that it's
> called after all early devices are probed.
>
> Signed-off-by: Bartosz Golaszewski <bgolaszewski@baylibre.com>
I had not gotten around to look at this in enough detail so far, but
looking now, it seems all good.
Acked-by: Arnd Bergmann <arnd@arndb.de>
^ permalink raw reply
* [PATCH] PCI: pciehp: Add quirk for QDF2400 Command Completed erratum
From: Bjorn Helgaas @ 2018-05-07 21:35 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1525602662-1873-1-git-send-email-okaya@codeaurora.org>
On Sun, May 06, 2018 at 06:30:53AM -0400, Sinan Kaya wrote:
> The QDF2400 controller does not set the Command Completed bit unless
> writes to the Slot Command register change "Control" bits. Command
> Completed is never set for writes that only change software notification
> "Enable" bits. This results in timeouts like this:
>
> pciehp 0000:00:00.0:pcie004: Timeout on hotplug command 0x1038
>
> Cc: stable at vger.kernel.org
> Signed-off-by: Sinan Kaya <okaya@codeaurora.org>
Since there's no bisection benefit for keeping these separate, I folded
this into the original quirk and added Mika's reviewed-by.
I also added the following ID patch and used PCI_VENDOR_ID_QCOM:
commit 333c8c1216c1e7ead6af7b3d667b43eb425b5034
Author: Bjorn Helgaas <bhelgaas@google.com>
Date: Mon May 7 15:52:55 2018 -0500
PCI: Add Qualcomm vendor ID
Add the Qualcomm vendor ID to pci_ids.h and use it in quirks.
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
diff --git a/drivers/pci/quirks.c b/drivers/pci/quirks.c
index 2990ad1e7c99..e7bf44515fd6 100644
--- a/drivers/pci/quirks.c
+++ b/drivers/pci/quirks.c
@@ -4361,8 +4361,8 @@ static const struct pci_dev_acs_enabled {
{ PCI_VENDOR_ID_INTEL, 0x15b7, pci_quirk_mf_endpoint_acs },
{ PCI_VENDOR_ID_INTEL, 0x15b8, pci_quirk_mf_endpoint_acs },
/* QCOM QDF2xxx root ports */
- { 0x17cb, 0x400, pci_quirk_qcom_rp_acs },
- { 0x17cb, 0x401, pci_quirk_qcom_rp_acs },
+ { PCI_VENDOR_ID_QCOM, 0x0400, pci_quirk_qcom_rp_acs },
+ { PCI_VENDOR_ID_QCOM, 0x0401, pci_quirk_qcom_rp_acs },
/* Intel PCH root ports */
{ PCI_VENDOR_ID_INTEL, PCI_ANY_ID, pci_quirk_intel_pch_acs },
{ PCI_VENDOR_ID_INTEL, PCI_ANY_ID, pci_quirk_intel_spt_pch_acs },
diff --git a/include/linux/pci_ids.h b/include/linux/pci_ids.h
index cc608fc55334..883cb7bf78aa 100644
--- a/include/linux/pci_ids.h
+++ b/include/linux/pci_ids.h
@@ -2387,6 +2387,8 @@
#define PCI_VENDOR_ID_LENOVO 0x17aa
+#define PCI_VENDOR_ID_QCOM 0x17cb
+
#define PCI_VENDOR_ID_CDNS 0x17cd
#define PCI_VENDOR_ID_ARECA 0x17d3
> ---
> drivers/pci/hotplug/pciehp_hpc.c | 6 ++++++
> 1 file changed, 6 insertions(+)
>
> diff --git a/drivers/pci/hotplug/pciehp_hpc.c b/drivers/pci/hotplug/pciehp_hpc.c
> index e70eba5..974a8f1 100644
> --- a/drivers/pci/hotplug/pciehp_hpc.c
> +++ b/drivers/pci/hotplug/pciehp_hpc.c
> @@ -914,3 +914,9 @@ static void quirk_cmd_compl(struct pci_dev *pdev)
> }
> DECLARE_PCI_FIXUP_CLASS_EARLY(PCI_VENDOR_ID_INTEL, PCI_ANY_ID,
> PCI_CLASS_BRIDGE_PCI, 8, quirk_cmd_compl);
> +
> +DECLARE_PCI_FIXUP_CLASS_EARLY(0x17cb, 0x400,
> + PCI_CLASS_BRIDGE_PCI, 8, quirk_cmd_compl);
> +
> +DECLARE_PCI_FIXUP_CLASS_EARLY(0x17cb, 0x401,
> + PCI_CLASS_BRIDGE_PCI, 8, quirk_cmd_compl);
> --
> 2.7.4
>
>
> _______________________________________________
> linux-arm-kernel mailing list
> linux-arm-kernel at lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* [PATCH] PCI: pciehp: Add quirk for QDF2400 Command Completed erratum
From: okaya at codeaurora.org @ 2018-05-07 21:41 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180507213531.GB133147@bhelgaas-glaptop.roam.corp.google.com>
On 2018-05-07 22:35, Bjorn Helgaas wrote:
> On Sun, May 06, 2018 at 06:30:53AM -0400, Sinan Kaya wrote:
>> The QDF2400 controller does not set the Command Completed bit unless
>> writes to the Slot Command register change "Control" bits. Command
>> Completed is never set for writes that only change software
>> notification
>> "Enable" bits. This results in timeouts like this:
>>
>> pciehp 0000:00:00.0:pcie004: Timeout on hotplug command 0x1038
>>
>> Cc: stable at vger.kernel.org
>> Signed-off-by: Sinan Kaya <okaya@codeaurora.org>
>
> Since there's no bisection benefit for keeping these separate, I folded
> this into the original quirk and added Mika's reviewed-by.
>
> I also added the following ID patch and used PCI_VENDOR_ID_QCOM:
Thanks for the clean up.
>
> commit 333c8c1216c1e7ead6af7b3d667b43eb425b5034
> Author: Bjorn Helgaas <bhelgaas@google.com>
> Date: Mon May 7 15:52:55 2018 -0500
>
> PCI: Add Qualcomm vendor ID
>
> Add the Qualcomm vendor ID to pci_ids.h and use it in quirks.
>
> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
>
> diff --git a/drivers/pci/quirks.c b/drivers/pci/quirks.c
> index 2990ad1e7c99..e7bf44515fd6 100644
> --- a/drivers/pci/quirks.c
> +++ b/drivers/pci/quirks.c
> @@ -4361,8 +4361,8 @@ static const struct pci_dev_acs_enabled {
> { PCI_VENDOR_ID_INTEL, 0x15b7, pci_quirk_mf_endpoint_acs },
> { PCI_VENDOR_ID_INTEL, 0x15b8, pci_quirk_mf_endpoint_acs },
> /* QCOM QDF2xxx root ports */
> - { 0x17cb, 0x400, pci_quirk_qcom_rp_acs },
> - { 0x17cb, 0x401, pci_quirk_qcom_rp_acs },
> + { PCI_VENDOR_ID_QCOM, 0x0400, pci_quirk_qcom_rp_acs },
> + { PCI_VENDOR_ID_QCOM, 0x0401, pci_quirk_qcom_rp_acs },
> /* Intel PCH root ports */
> { PCI_VENDOR_ID_INTEL, PCI_ANY_ID, pci_quirk_intel_pch_acs },
> { PCI_VENDOR_ID_INTEL, PCI_ANY_ID, pci_quirk_intel_spt_pch_acs },
> diff --git a/include/linux/pci_ids.h b/include/linux/pci_ids.h
> index cc608fc55334..883cb7bf78aa 100644
> --- a/include/linux/pci_ids.h
> +++ b/include/linux/pci_ids.h
> @@ -2387,6 +2387,8 @@
>
> #define PCI_VENDOR_ID_LENOVO 0x17aa
>
> +#define PCI_VENDOR_ID_QCOM 0x17cb
> +
> #define PCI_VENDOR_ID_CDNS 0x17cd
>
> #define PCI_VENDOR_ID_ARECA 0x17d3
>
>> ---
>> drivers/pci/hotplug/pciehp_hpc.c | 6 ++++++
>> 1 file changed, 6 insertions(+)
>>
>> diff --git a/drivers/pci/hotplug/pciehp_hpc.c
>> b/drivers/pci/hotplug/pciehp_hpc.c
>> index e70eba5..974a8f1 100644
>> --- a/drivers/pci/hotplug/pciehp_hpc.c
>> +++ b/drivers/pci/hotplug/pciehp_hpc.c
>> @@ -914,3 +914,9 @@ static void quirk_cmd_compl(struct pci_dev *pdev)
>> }
>> DECLARE_PCI_FIXUP_CLASS_EARLY(PCI_VENDOR_ID_INTEL, PCI_ANY_ID,
>> PCI_CLASS_BRIDGE_PCI, 8, quirk_cmd_compl);
>> +
>> +DECLARE_PCI_FIXUP_CLASS_EARLY(0x17cb, 0x400,
>> + PCI_CLASS_BRIDGE_PCI, 8, quirk_cmd_compl);
>> +
>> +DECLARE_PCI_FIXUP_CLASS_EARLY(0x17cb, 0x401,
>> + PCI_CLASS_BRIDGE_PCI, 8, quirk_cmd_compl);
>> --
>> 2.7.4
>>
>>
>> _______________________________________________
>> linux-arm-kernel mailing list
>> linux-arm-kernel at lists.infradead.org
>> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* [PATCH] PCI: Check whether bridges allow access to extended config space
From: Bjorn Helgaas @ 2018-05-07 21:56 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180504200600.GA9529@bhelgaas-glaptop.roam.corp.google.com>
On Fri, May 04, 2018 at 03:06:00PM -0500, Bjorn Helgaas wrote:
> On Fri, May 04, 2018 at 03:45:07PM +0000, Gilles Buloz wrote:
> > Le 04/05/2018 00:31, Bjorn Helgaas a ?crit :
> > > [+cc LKML]
> > >
> > > On Thu, May 03, 2018 at 12:40:27PM +0000, Gilles Buloz wrote:
> > >> Subject: [PATCH] For exception at PCI probe due to bridge reporting UR
> > >>
> > >> Even if a device supports extended config access, no such access must be
> > >> done to this device If there's a bridge not supporting that in the path
> > >> to this device. Doing such access with UR reporting enabled on the root
> > >> bridge leads to an exception.
> > >>
> > >> This is the case on a LS1043A CPU (NXP QorIQ Layerscape) platform with
> > >> the following bus topology :
> > >> LS1043 PCIe root
> > >> -> PEX8112 PCIe-to-PCI bridge (not supporting ext cfg on PCI side)
> > >> -> PMC slot connector (for legacy PMC modules)
> > >> With a PMC module topology as follows :
> > >> PMC connector
> > >> -> PCI-to-PCIe bridge
> > >> -> PCIe switch (4 ports)
> > >> -> 4 PCIe devices (one on each port)
> > >> In this case all devices behind the PEX8112 are supporting extended config
> > >> access but this is prohibited by the PEX8112. Without this patch, an
> > >> exception (synchronous abort) occurs in pci_cfg_space_size_ext().
> > >>
> > >> This patch checks the parent bridge of each allocated child bus to know if
> > >> extended config access is supported on the child bus, and sets a flag in
> > >> child->bus_flags if not supported. This flag is inherited by all children
> > >> buses of this child bus and then is checked to avoid this unsupported
> > >> accesses to every device on these buses.
> > > Hi Gilles,
> > >
> > > Thanks for the patch! I reworked it a little bit to simplify the code
> > > in pci_alloc_child_bus(). Can you test it and make sure I didn't
> > > break anything?
> > >
> > Hi Bjorn,
> >
> > Your rework works as expected. Tested on LS1043A platform with kernel
> > 4.17-rc1, and with some backport on kernel 4.1.35
Thanks for testing it! I applied it to pci/enumeration for v4.18.
I think the ASPM issue below is unrelated. But I would like to figure out
what's going on there, too, if you have any more information.
> > Info : with kernel 4.17-rc1, it turns out I need pcie_aspm=off to
> > have the PMC devices behind the PCI-to-PCIe bridge of the PMC safely
> > detected/configured. But this is not caused by the patch.
>
> > Without pcie_aspm=off I saw this at one boot :
> > "pci 0000:02:0e.0: ASPM: Could not configure common clock" for this bridge, but devices
> > correctly detected/configured
> > but at most boots I get :
> > no ASPM message but "pci 0000:04:02.0: bridge configuration invalid ([bus ff-ff]), reconfiguring "
> > instead, and some devices are missing. Also lspci show "rev ff" for some devices.
> > I don't see this problem on 4.1.35 with the same backported patch.
>
> This is interesting, especially since you have this unusual topology
> of a path to the device that is PCIe, then conventional PCI, then PCIe
> again. We *should* be able to use ASPM on the PCIe links, but it's
> definitely not a well-tested scenario.
>
> Can you tell if something is actually broken? Sinan's recent change,
> 04875177dbe0 ("PCI/ASPM: Don't warn if already in common clock mode"),
> which appeared in v4.17-rc1, turns off the message in some cases.
>
> The "bridge configuration invalid" message just means the firmware
> didn't configure the bridge. We *should* still set it up correctly,
> but please report a bug if we don't.
>
> lspci showing "ff" for some devices might be a symptom of the devices
> being powered off. In that case config reads normally return ~0 data
> (though on your platform maybe it would cause exceptions). I've seen
> this in other situations and wondered if it would be worth adding a
> hint to lspci so it could say "device may be powered off".
>
> Anyway, if you are seeing something broken (more than just the
> messages), please start a new thread about each one. If you do, could
> you please:
>
> - open a report at https://bugzilla.kernel.org/, in the Drivers/PCI
> component (open a separate bug for each issue you see)
>
> - use kernel version 4.17-rc1 and mark it as a regression if
> appropriate
>
> - attach (don't paste inline) the complete dmesg log and "lspci -vv"
> output (as root) to the bug
>
> - post a note to linux-pci at vger.kernel.org, cc Fred, Sinan, and me,
> and include the link to the bugzilla
>
> Bjorn
^ permalink raw reply
* [PATCH v2 19/27] coresight: catu: Plug in CATU as a backend for ETR buffer
From: Mathieu Poirier @ 2018-05-07 22:02 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1525165857-11096-20-git-send-email-suzuki.poulose@arm.com>
On Tue, May 01, 2018 at 10:10:49AM +0100, Suzuki K Poulose wrote:
> Now that we can use a CATU with a scatter gather table, add support
> for the TMC ETR to make use of the connected CATU in translate mode.
> This is done by adding CATU as new buffer mode. CATU's SLADDR must
> always be 4K aligned. Thus the INADDR (base VA) is always 1M aligned
> and we adjust the DBA for the ETR to align to the "offset" within
> the 1MB page.
>
> Cc: Mathieu Poirier <mathieu.poirier@linaro.org>
> Signed-off-by: Suzuki K Poulose <suzuki.poulose@arm.com>
> ---
> drivers/hwtracing/coresight/coresight-catu.c | 189 +++++++++++++++++++++++-
> drivers/hwtracing/coresight/coresight-catu.h | 30 ++++
> drivers/hwtracing/coresight/coresight-tmc-etr.c | 23 ++-
> drivers/hwtracing/coresight/coresight-tmc.h | 1 +
> 4 files changed, 235 insertions(+), 8 deletions(-)
>
> diff --git a/drivers/hwtracing/coresight/coresight-catu.c b/drivers/hwtracing/coresight/coresight-catu.c
> index 4cc2928..a4792fa 100644
> --- a/drivers/hwtracing/coresight/coresight-catu.c
> +++ b/drivers/hwtracing/coresight/coresight-catu.c
> @@ -22,6 +22,21 @@
> dev_get_drvdata(csdev->dev.parent)
>
> /*
> + * catu_etr_buf - CATU buffer descriptor
> + * @catu_table - SG table for the CATU
> + * @sladdr - Table base address for CATU
> + * @start_offset - Current offset where the ETR starts writing
> + * within the buffer.
> + * @cur_size - Current size used by the ETR.
> + */
> +struct catu_etr_buf {
> + struct tmc_sg_table *catu_table;
> + u64 sladdr;
> + u64 start_offset;
> + u64 cur_size;
> +};
> +
> +/*
> * CATU uses a page size of 4KB for page tables as well as data pages.
> * Each 64bit entry in the table has the following format.
> *
> @@ -87,6 +102,9 @@ typedef u64 cate_t;
> (((cate_t)(addr) & CATU_ADDR_MASK) | CATU_ENTRY_VALID)
> #define CATU_ENTRY_ADDR(entry) ((cate_t)(entry) & ~((cate_t)CATU_ENTRY_VALID))
>
> +/* CATU expects the INADDR to be aligned to 1M. */
> +#define CATU_DEFAULT_INADDR (1ULL << 20)
> +
> /*
> * Index into the CATU entry pointing to the page within
> * the table. Each table entry can point to a 4KB page, with
> @@ -401,7 +419,7 @@ catu_populate_table(struct tmc_sg_table *catu_table)
> }
> }
>
> -static struct tmc_sg_table __maybe_unused *
> +static struct tmc_sg_table *
> catu_init_sg_table(struct device *catu_dev, int node,
> ssize_t size, void **pages)
> {
> @@ -429,6 +447,149 @@ catu_init_sg_table(struct device *catu_dev, int node,
> return catu_table;
> }
>
> +static void catu_free_etr_buf(struct etr_buf *etr_buf)
> +{
> + struct catu_etr_buf *catu_buf;
> +
> + if (!etr_buf || etr_buf->mode != ETR_MODE_CATU || !etr_buf->private)
> + return;
> + catu_buf = etr_buf->private;
> + tmc_free_sg_table(catu_buf->catu_table);
> + kfree(catu_buf);
> +}
> +
> +static ssize_t catu_get_data_etr_buf(struct etr_buf *etr_buf, u64 offset,
> + size_t len, char **bufpp)
> +{
> + struct catu_etr_buf *catu_buf = etr_buf->private;
> +
> + return tmc_sg_table_get_data(catu_buf->catu_table, offset, len, bufpp);
> +}
> +
> +static void catu_sync_etr_buf(struct etr_buf *etr_buf, u64 rrp, u64 rwp)
> +{
> + struct catu_etr_buf *catu_buf = etr_buf->private;
> + s64 r_offset, w_offset;
> + unsigned long buf_size = tmc_sg_table_buf_size(catu_buf->catu_table);
> +
> + /*
> + * ETR started off at etr_buf->hwaddr which corresponds to
> + * start_offset within the trace buffer. Convert the RRP/RWP
> + * offsets within the trace buffer.
> + */
> + r_offset = (s64)rrp - etr_buf->hwaddr + catu_buf->start_offset;
> + r_offset -= (r_offset > buf_size) ? buf_size : 0;
> +
> + w_offset = (s64)rwp - etr_buf->hwaddr + catu_buf->start_offset;
> + w_offset -= (w_offset > buf_size) ? buf_size : 0;
> +
> + if (!etr_buf->full) {
> + etr_buf->len = w_offset - r_offset;
> + if (w_offset < r_offset)
> + etr_buf->len += buf_size;
> + } else {
> + etr_buf->len = etr_buf->size;
> + }
> +
> + etr_buf->offset = r_offset;
> + tmc_sg_table_sync_data_range(catu_buf->catu_table,
> + r_offset, etr_buf->len);
> +}
> +
> +static inline void catu_set_etr_buf(struct etr_buf *etr_buf, u64 base, u64 size)
> +{
> + struct catu_etr_buf *catu_buf = etr_buf->private;
> +
> + catu_buf->start_offset = base;
> + catu_buf->cur_size = size;
> +
> + /*
> + * CATU always maps 1MB aligned addresses. ETR should start at
> + * the offset within the first table.
> + */
> + etr_buf->hwaddr = CATU_DEFAULT_INADDR + (base & (SZ_1M - 1));
> + etr_buf->size = size;
> + etr_buf->rwp = etr_buf->rrp = etr_buf->hwaddr;
> +}
> +
> +static int catu_restore_etr_buf(struct etr_buf *etr_buf,
> + unsigned long r_offset,
> + unsigned long w_offset,
> + unsigned long size,
> + u32 status,
> + bool has_save_restore)
> +{
> + struct catu_etr_buf *catu_buf = etr_buf->private;
> + u64 end = w_offset + size;
> + u64 cur_end = catu_buf->start_offset + catu_buf->cur_size;
> +
> + /*
> + * We cannot support rotation without a full table
> + * at the end. i.e, the buffer size should be aligned
> + * to 1MB.
> + */
> + if (tmc_sg_table_buf_size(catu_buf->catu_table) & (SZ_1M - 1))
> + return -EINVAL;
> +
> + /*
> + * We don't have to make any changes to the table if the
> + * current (start, end) and the new (start, end) are in the
> + * same pages respectively.
> + */
> + if ((w_offset ^ catu_buf->start_offset) & ~(CATU_PAGE_SIZE - 1) ||
> + (end ^ cur_end) & ~(CATU_PAGE_SIZE - 1)) {
> + catu_reset_table(catu_buf->catu_table, catu_buf->start_offset,
> + catu_buf->cur_size);
> + catu_buf->sladdr = catu_set_table(catu_buf->catu_table,
> + w_offset, size);
> + }
> +
> + catu_set_etr_buf(etr_buf, w_offset, size);
> +
> + return 0;
> +}
> +
> +static int catu_alloc_etr_buf(struct tmc_drvdata *tmc_drvdata,
> + struct etr_buf *etr_buf, int node, void **pages)
> +{
> + struct coresight_device *csdev;
> + struct device *catu_dev;
> + struct tmc_sg_table *catu_table;
> + struct catu_etr_buf *catu_buf;
> +
> + csdev = tmc_etr_get_catu_device(tmc_drvdata);
> + if (!csdev)
> + return -ENODEV;
> + catu_dev = csdev->dev.parent;
> + catu_buf = kzalloc(sizeof(*catu_buf), GFP_KERNEL);
> + if (!catu_buf)
> + return -ENOMEM;
> +
> + catu_table = catu_init_sg_table(catu_dev, node, etr_buf->size, pages);
> + if (IS_ERR(catu_table)) {
> + kfree(catu_buf);
> + return PTR_ERR(catu_table);
> + }
> +
> + etr_buf->mode = ETR_MODE_CATU;
> + etr_buf->private = catu_buf;
> + catu_buf->catu_table = catu_table;
> +
> + /* By default make the buffer linear from 0 with full size */
> + catu_set_etr_buf(etr_buf, 0, etr_buf->size);
> + catu_dump_table(catu_table);
> +
> + return 0;
> +}
> +
> +const struct etr_buf_operations etr_catu_buf_ops = {
> + .alloc = catu_alloc_etr_buf,
> + .free = catu_free_etr_buf,
> + .sync = catu_sync_etr_buf,
> + .get_data = catu_get_data_etr_buf,
> + .restore = catu_restore_etr_buf,
> +};
> +
> coresight_simple_reg32(struct catu_drvdata, control, CATU_CONTROL);
> coresight_simple_reg32(struct catu_drvdata, status, CATU_STATUS);
> coresight_simple_reg32(struct catu_drvdata, mode, CATU_MODE);
> @@ -467,9 +628,11 @@ static inline int catu_wait_for_ready(struct catu_drvdata *drvdata)
> CATU_STATUS, CATU_STATUS_READY, 1);
> }
>
> -static int catu_enable_hw(struct catu_drvdata *drvdata, void *__unused)
> +static int catu_enable_hw(struct catu_drvdata *drvdata, void *data)
> {
> u32 control;
> + u32 mode;
> + struct etr_buf *etr_buf = data;
>
> if (catu_wait_for_ready(drvdata))
> dev_warn(drvdata->dev, "Timeout while waiting for READY\n");
> @@ -481,9 +644,27 @@ static int catu_enable_hw(struct catu_drvdata *drvdata, void *__unused)
> }
>
> control |= BIT(CATU_CONTROL_ENABLE);
> - catu_write_mode(drvdata, CATU_MODE_PASS_THROUGH);
> +
> + if (etr_buf && etr_buf->mode == ETR_MODE_CATU) {
> + struct catu_etr_buf *catu_buf = etr_buf->private;
> +
> + mode = CATU_MODE_TRANSLATE;
> + catu_write_axictrl(drvdata, CATU_OS_AXICTRL);
> + catu_write_sladdr(drvdata, catu_buf->sladdr);
> + catu_write_inaddr(drvdata, CATU_DEFAULT_INADDR);
> + } else {
> + mode = CATU_MODE_PASS_THROUGH;
> + catu_write_sladdr(drvdata, 0);
> + catu_write_inaddr(drvdata, 0);
> + }
> +
> + catu_write_irqen(drvdata, 0);
> + catu_write_mode(drvdata, mode);
> catu_write_control(drvdata, control);
> - dev_dbg(drvdata->dev, "Enabled in Pass through mode\n");
> + dev_dbg(drvdata->dev, "Enabled in %s mode\n",
> + (mode == CATU_MODE_PASS_THROUGH) ?
> + "Pass through" :
> + "Translate");
> return 0;
> }
>
> diff --git a/drivers/hwtracing/coresight/coresight-catu.h b/drivers/hwtracing/coresight/coresight-catu.h
> index cd58d6f..b673a73 100644
> --- a/drivers/hwtracing/coresight/coresight-catu.h
> +++ b/drivers/hwtracing/coresight/coresight-catu.h
> @@ -29,6 +29,32 @@
> #define CATU_MODE_PASS_THROUGH 0U
> #define CATU_MODE_TRANSLATE 1U
>
> +#define CATU_AXICTRL_ARCACHE_SHIFT 4
> +#define CATU_AXICTRL_ARCACHE_MASK 0xf
> +#define CATU_AXICTRL_ARPROT_MASK 0x3
> +#define CATU_AXICTRL_ARCACHE(arcache) \
> + (((arcache) & CATU_AXICTRL_ARCACHE_MASK) << CATU_AXICTRL_ARCACHE_SHIFT)
> +
> +#define CATU_AXICTRL_VAL(arcache, arprot) \
> + (CATU_AXICTRL_ARCACHE(arcache) | ((arprot) & CATU_AXICTRL_ARPROT_MASK))
> +
> +#define AXI3_AxCACHE_WB_READ_ALLOC 0x7
> +/*
> + * AXI - ARPROT bits:
> + * See AMBA AXI & ACE Protocol specification (ARM IHI 0022E)
> + * sectionA4.7 Access Permissions.
> + *
> + * Bit 0: 0 - Unprivileged access, 1 - Privileged access
> + * Bit 1: 0 - Secure access, 1 - Non-secure access.
> + * Bit 2: 0 - Data access, 1 - instruction access.
> + *
> + * CATU AXICTRL:ARPROT[2] is res0 as we always access data.
> + */
> +#define CATU_OS_ARPROT 0x2
> +
> +#define CATU_OS_AXICTRL \
> + CATU_AXICTRL_VAL(AXI3_AxCACHE_WB_READ_ALLOC, CATU_OS_ARPROT)
> +
> #define CATU_STATUS_READY 8
> #define CATU_STATUS_ADRERR 0
> #define CATU_STATUS_AXIERR 4
> @@ -71,6 +97,8 @@ catu_write_##name(struct catu_drvdata *drvdata, u64 val) \
>
> CATU_REG32(control, CATU_CONTROL);
> CATU_REG32(mode, CATU_MODE);
> +CATU_REG32(irqen, CATU_IRQEN);
> +CATU_REG32(axictrl, CATU_AXICTRL);
> CATU_REG_PAIR(sladdr, CATU_SLADDRLO, CATU_SLADDRHI)
> CATU_REG_PAIR(inaddr, CATU_INADDRLO, CATU_INADDRHI)
>
> @@ -86,4 +114,6 @@ static inline bool coresight_is_catu_device(struct coresight_device *csdev)
> subtype == CORESIGHT_DEV_SUBTYPE_HELPER_CATU;
> }
>
> +extern const struct etr_buf_operations etr_catu_buf_ops;
> +
> #endif
> diff --git a/drivers/hwtracing/coresight/coresight-tmc-etr.c b/drivers/hwtracing/coresight/coresight-tmc-etr.c
> index 25e7feb..41dde0a 100644
> --- a/drivers/hwtracing/coresight/coresight-tmc-etr.c
> +++ b/drivers/hwtracing/coresight/coresight-tmc-etr.c
> @@ -941,6 +941,9 @@ static const struct etr_buf_operations etr_sg_buf_ops = {
> static const struct etr_buf_operations *etr_buf_ops[] = {
> [ETR_MODE_FLAT] = &etr_flat_buf_ops,
> [ETR_MODE_ETR_SG] = &etr_sg_buf_ops,
> +#ifdef CONFIG_CORESIGHT_CATU
> + [ETR_MODE_CATU] = &etr_catu_buf_ops,
> +#endif
> };
>
> static inline int tmc_etr_mode_alloc_buf(int mode,
> @@ -953,6 +956,9 @@ static inline int tmc_etr_mode_alloc_buf(int mode,
> switch (mode) {
> case ETR_MODE_FLAT:
> case ETR_MODE_ETR_SG:
> +#ifdef CONFIG_CORESIGHT_CATU
> + case ETR_MODE_CATU:
> +#endif
I really wish we could avoid doing something like this (and the above) but every
alternate solution I come up with is either uglier or on par with it...
Unless someone comes up with a bright idea we'll simply have to let it be.
While looking for a solution I noticed that tmc_etr_get_catu_device()
could be moved to coresight-catu.h. That way we wouldn't have to include
coresight-catu.h every time coresight-tmc.h is present in a file.
> rc = etr_buf_ops[mode]->alloc(drvdata, etr_buf, node, pages);
> if (!rc)
> etr_buf->ops = etr_buf_ops[mode];
> @@ -977,11 +983,15 @@ static struct etr_buf *tmc_alloc_etr_buf(struct tmc_drvdata *drvdata,
> int rc = -ENOMEM;
> bool has_etr_sg, has_iommu;
> bool has_flat, has_save_restore;
> + bool has_sg, has_catu;
> struct etr_buf *etr_buf;
>
> has_etr_sg = tmc_etr_has_cap(drvdata, TMC_ETR_SG);
> has_iommu = iommu_get_domain_for_dev(drvdata->dev);
> has_save_restore = tmc_etr_has_cap(drvdata, TMC_ETR_SAVE_RESTORE);
> + has_catu = !!tmc_etr_get_catu_device(drvdata);
> +
> + has_sg = has_catu || has_etr_sg;
>
> /*
> * We can normally use flat DMA buffer provided that the buffer
> @@ -1006,7 +1016,7 @@ static struct etr_buf *tmc_alloc_etr_buf(struct tmc_drvdata *drvdata,
> if ((flags & ETR_BUF_F_RESTORE_STATUS) && !has_save_restore)
> return ERR_PTR(-EINVAL);
>
> - if (!has_flat && !has_etr_sg) {
> + if (!has_flat && !has_sg) {
> dev_dbg(drvdata->dev,
> "No available backends for ETR buffer with flags %x\n",
> flags);
> @@ -1032,17 +1042,22 @@ static struct etr_buf *tmc_alloc_etr_buf(struct tmc_drvdata *drvdata,
> *
> */
> if (!pages && has_flat &&
> - (!has_etr_sg || has_iommu || size < SZ_1M))
> + (!has_sg || has_iommu || size < SZ_1M))
> rc = tmc_etr_mode_alloc_buf(ETR_MODE_FLAT, drvdata,
> etr_buf, node, pages);
> if (rc && has_etr_sg)
> rc = tmc_etr_mode_alloc_buf(ETR_MODE_ETR_SG, drvdata,
> etr_buf, node, pages);
> + if (rc && has_catu)
> + rc = tmc_etr_mode_alloc_buf(ETR_MODE_CATU, drvdata,
> + etr_buf, node, pages);
> if (rc) {
> kfree(etr_buf);
> return ERR_PTR(rc);
> }
>
> + dev_dbg(drvdata->dev, "allocated buffer of size %ldKB in mode %d\n",
> + (unsigned long)size >> 10, etr_buf->mode);
> return etr_buf;
> }
>
> @@ -1136,7 +1151,7 @@ static inline void tmc_etr_enable_catu(struct tmc_drvdata *drvdata)
> struct coresight_device *catu = tmc_etr_get_catu_device(drvdata);
>
> if (catu && helper_ops(catu)->enable)
> - helper_ops(catu)->enable(catu, NULL);
> + helper_ops(catu)->enable(catu, drvdata->etr_buf);
> }
>
> static inline void tmc_etr_disable_catu(struct tmc_drvdata *drvdata)
> @@ -1144,7 +1159,7 @@ static inline void tmc_etr_disable_catu(struct tmc_drvdata *drvdata)
> struct coresight_device *catu = tmc_etr_get_catu_device(drvdata);
>
> if (catu && helper_ops(catu)->disable)
> - helper_ops(catu)->disable(catu, NULL);
> + helper_ops(catu)->disable(catu, drvdata->etr_buf);
> }
>
> static void tmc_etr_enable_hw(struct tmc_drvdata *drvdata)
> diff --git a/drivers/hwtracing/coresight/coresight-tmc.h b/drivers/hwtracing/coresight/coresight-tmc.h
> index 1bdfb38..1f6aa49 100644
> --- a/drivers/hwtracing/coresight/coresight-tmc.h
> +++ b/drivers/hwtracing/coresight/coresight-tmc.h
> @@ -139,6 +139,7 @@ enum tmc_mem_intf_width {
> enum etr_mode {
> ETR_MODE_FLAT, /* Uses contiguous flat buffer */
> ETR_MODE_ETR_SG, /* Uses in-built TMC ETR SG mechanism */
> + ETR_MODE_CATU, /* Use SG mechanism in CATU */
> };
>
> /* ETR buffer should support save-restore */
> --
> 2.7.4
>
^ permalink raw reply
* [PATCH v4 1/3] drm/panel: Add RGB666 variant of Innolux AT070TN90
From: Paul Kocialkowski @ 2018-05-07 22:04 UTC (permalink / raw)
To: linux-arm-kernel
This adds timings for the RGB666 variant of the Innolux AT070TN90 panel,
as found on the Ainol AW1 tablet.
The panel also supports RGB888 output. When RGB666 mode is used instead,
the two extra lanes per component are grounded.
In the future, it might become necessary to introduce a dedicated
device-tree property to specify the bus format to use instead of the
default one for the panel. This will allow supporting different bus
formats for the same panel modes.
Signed-off-by: Paul Kocialkowski <contact@paulk.fr>
---
drivers/gpu/drm/panel/panel-simple.c | 26 ++++++++++++++++++++++++++
1 file changed, 26 insertions(+)
diff --git a/drivers/gpu/drm/panel/panel-simple.c b/drivers/gpu/drm/panel/panel-simple.c
index cbf1ab404ee7..32e30d5a8f08 100644
--- a/drivers/gpu/drm/panel/panel-simple.c
+++ b/drivers/gpu/drm/panel/panel-simple.c
@@ -1063,6 +1063,29 @@ static const struct panel_desc innolux_at043tn24 = {
.bus_flags = DRM_BUS_FLAG_DE_HIGH | DRM_BUS_FLAG_PIXDATA_POSEDGE,
};
+static const struct drm_display_mode innolux_at070tn90_mode = {
+ .clock = 40000,
+ .hdisplay = 800,
+ .hsync_start = 800 + 112,
+ .hsync_end = 800 + 112 + 1,
+ .htotal = 800 + 112 + 1 + 87,
+ .vdisplay = 480,
+ .vsync_start = 480 + 141,
+ .vsync_end = 480 + 141 + 1,
+ .vtotal = 480 + 141 + 1 + 38,
+ .vrefresh = 60,
+};
+
+static const struct panel_desc innolux_at070tn90 = {
+ .modes = &innolux_at070tn90_mode,
+ .num_modes = 1,
+ .size = {
+ .width = 154,
+ .height = 86,
+ },
+ .bus_format = MEDIA_BUS_FMT_RGB666_1X18,
+};
+
static const struct drm_display_mode innolux_at070tn92_mode = {
.clock = 33333,
.hdisplay = 800,
@@ -2151,6 +2174,9 @@ static const struct of_device_id platform_of_match[] = {
}, {
.compatible = "innolux,at043tn24",
.data = &innolux_at043tn24,
+ }, {
+ .compatible = "innolux,at070tn90",
+ .data = &innolux_at070tn90,
}, {
.compatible = "innolux,at070tn92",
.data = &innolux_at070tn92,
--
2.17.0
^ permalink raw reply related
* [PATCH v4 2/3] ARM: dts: sun7i: Add RGB666 pins definition
From: Paul Kocialkowski @ 2018-05-07 22:04 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180507220413.21990-1-contact@paulk.fr>
This adds the pins definition for RGB666 LCD panels on the A20. It was
inspired by the A33 definition, that concernes the same set of pins.
Signed-off-by: Paul Kocialkowski <contact@paulk.fr>
---
arch/arm/boot/dts/sun7i-a20.dtsi | 8 ++++++++
1 file changed, 8 insertions(+)
diff --git a/arch/arm/boot/dts/sun7i-a20.dtsi b/arch/arm/boot/dts/sun7i-a20.dtsi
index e529e4ff2174..b3ee36cd7fa7 100644
--- a/arch/arm/boot/dts/sun7i-a20.dtsi
+++ b/arch/arm/boot/dts/sun7i-a20.dtsi
@@ -781,6 +781,14 @@
function = "ir1";
};
+ lcd0_rgb666_pins: lcd0-rgb666 {
+ pins = "PD2", "PD3", "PD4", "PD5", "PD6", "PD7",
+ "PD10", "PD11", "PD12", "PD13", "PD14", "PD15",
+ "PD18", "PD19", "PD20", "PD21", "PD22", "PD23",
+ "PD24", "PD25", "PD26", "PD27";
+ function = "lcd0";
+ };
+
mmc0_pins_a: mmc0 at 0 {
pins = "PF0", "PF1", "PF2",
"PF3", "PF4", "PF5";
--
2.17.0
^ permalink raw reply related
* [PATCH v4 3/3] ARM: dts: sun7i: Add support for the Ainol AW1 tablet
From: Paul Kocialkowski @ 2018-05-07 22:04 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180507220413.21990-1-contact@paulk.fr>
This adds support for the Ainol AW1, an A20-based 7" tablet from Ainol.
The following board-specific features are supported:
* LCD panel
* Backlight
* USB OTG
* Buttons
* Touchscreen (doesn't work without non-free firmware)
* Accelerometer
* Battery
The following are untested:
* Audio output
* Audio speakers
* USB via SPCI connector
The following are not supported:
* Wi-Fi
* Bluetooth
* NAND
* Audio via SPCI connector
* Audio via Bluetooth I2S
Signed-off-by: Paul Kocialkowski <contact@paulk.fr>
---
arch/arm/boot/dts/Makefile | 1 +
arch/arm/boot/dts/sun7i-a20-ainol-aw1.dts | 297 ++++++++++++++++++++++
2 files changed, 298 insertions(+)
create mode 100644 arch/arm/boot/dts/sun7i-a20-ainol-aw1.dts
diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile
index 7e2424957809..4a80971f2bc9 100644
--- a/arch/arm/boot/dts/Makefile
+++ b/arch/arm/boot/dts/Makefile
@@ -946,6 +946,7 @@ dtb-$(CONFIG_MACH_SUN6I) += \
sun6i-a31s-sinovoip-bpi-m2.dtb \
sun6i-a31s-yones-toptech-bs1078-v2.dtb
dtb-$(CONFIG_MACH_SUN7I) += \
+ sun7i-a20-ainol-aw1.dtb \
sun7i-a20-bananapi.dtb \
sun7i-a20-bananapi-m1-plus.dtb \
sun7i-a20-bananapro.dtb \
diff --git a/arch/arm/boot/dts/sun7i-a20-ainol-aw1.dts b/arch/arm/boot/dts/sun7i-a20-ainol-aw1.dts
new file mode 100644
index 000000000000..9a732e4cd076
--- /dev/null
+++ b/arch/arm/boot/dts/sun7i-a20-ainol-aw1.dts
@@ -0,0 +1,297 @@
+/*
+ * SPDX-License-Identifier: (GPL-2.0+ OR MIT)
+ *
+ * Copyright (C) 2018 Paul Kocialkowski <contact@paulk.fr>
+ */
+
+/dts-v1/;
+#include "sun7i-a20.dtsi"
+#include "sunxi-common-regulators.dtsi"
+
+#include <dt-bindings/gpio/gpio.h>
+#include <dt-bindings/input/input.h>
+#include <dt-bindings/interrupt-controller/irq.h>
+#include <dt-bindings/pwm/pwm.h>
+
+/ {
+ model = "Ainol AW1";
+ compatible = "ainol,ainol-aw1", "allwinner,sun7i-a20";
+
+ aliases {
+ serial0 = &uart0;
+ };
+
+ chosen {
+ stdout-path = "serial0:115200n8";
+ };
+
+ 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>;
+ default-brightness-level = <128>;
+ enable-gpios = <&pio 7 7 GPIO_ACTIVE_HIGH>; /* PH7 */
+ };
+
+ panel: panel {
+ compatible = "innolux,at070tn90";
+ #address-cells = <1>;
+ #size-cells = <0>;
+ power-supply = <&panel_power>;
+ backlight = <&backlight>;
+
+ port at 0 {
+ reg = <0>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ panel_input: endpoint at 0 {
+ reg = <0>;
+ remote-endpoint = <&tcon0_out_panel>;
+ };
+ };
+ };
+
+ panel_power: panel_power {
+ compatible = "regulator-fixed";
+ regulator-name = "panel-power";
+ regulator-min-microvolt = <10400000>;
+ regulator-max-microvolt = <10400000>;
+ gpio = <&pio 7 8 GPIO_ACTIVE_HIGH>; /* PH8 */
+ enable-active-high;
+ regulator-boot-on;
+ };
+};
+
+&codec {
+ allwinner,pa-gpios = <&pio 7 15 GPIO_ACTIVE_HIGH>; /* PH15 */
+ status = "okay";
+};
+
+&cpu0 {
+ cpu-supply = <®_dcdc2>;
+};
+
+&de {
+ status = "okay";
+};
+
+&ehci0 {
+ status = "okay";
+};
+
+&ehci1 {
+ status = "okay";
+};
+
+&i2c0 {
+ pinctrl-names = "default";
+ pinctrl-0 = <&i2c0_pins_a>;
+ status = "okay";
+
+ axp209: pmic at 34 {
+ reg = <0x34>;
+ interrupt-parent = <&nmi_intc>;
+ interrupts = <0 IRQ_TYPE_LEVEL_LOW>;
+ };
+};
+
+&i2c1 {
+ pinctrl-names = "default";
+ pinctrl-0 = <&i2c1_pins_a>;
+ status = "okay";
+
+ lis3dh: accelerometer at 18 {
+ compatible = "st,lis3dh-accel";
+ reg = <0x18>;
+ vdd-supply = <®_vcc3v3>;
+ vddio-supply = <®_vcc3v3>;
+ st,drdy-int-pin = <1>;
+ };
+};
+
+&i2c2 {
+ pinctrl-names = "default";
+ pinctrl-0 = <&i2c2_pins_a>;
+ status = "okay";
+ clock-frequency = <400000>;
+
+ gsl1680: touchscreen at 40 {
+ compatible = "silead,gsl1680";
+ reg = <0x40>;
+ interrupt-parent = <&pio>;
+ interrupts = <7 21 IRQ_TYPE_EDGE_FALLING>; /* EINT21 (PH21) */
+ power-gpios = <&pio 7 20 GPIO_ACTIVE_HIGH>; /* PH20 */
+ firmware-name = "gsl1680-ainol-aw1.fw";
+ touchscreen-size-x = <480>;
+ touchscreen-size-y = <800>;
+ touchscreen-swapped-x-y;
+ touchscreen-inverted-y;
+ silead,max-fingers = <5>;
+ };
+};
+
+&lradc {
+ vref-supply = <®_ldo2>;
+ status = "okay";
+
+ button at 571 {
+ label = "Volume Up";
+ linux,code = <KEY_VOLUMEUP>;
+ channel = <0>;
+ voltage = <571428>;
+ };
+
+ button at 761 {
+ label = "Volume Down";
+ linux,code = <KEY_VOLUMEDOWN>;
+ channel = <0>;
+ voltage = <761904>;
+ };
+
+ button at 952 {
+ label = "Home";
+ linux,code = <KEY_HOME>;
+ channel = <0>;
+ voltage = <952380>;
+ };
+};
+
+&mmc0 {
+ pinctrl-names = "default";
+ pinctrl-0 = <&mmc0_pins_a>;
+ vmmc-supply = <®_vcc3v3>;
+ bus-width = <4>;
+ cd-gpios = <&pio 7 1 GPIO_ACTIVE_HIGH>; /* PH1 */
+ cd-inverted;
+ status = "okay";
+};
+
+&ohci0 {
+ status = "okay";
+};
+
+&ohci1 {
+ status = "okay";
+};
+
+&otg_sram {
+ status = "okay";
+};
+
+&pwm {
+ pinctrl-names = "default";
+ pinctrl-0 = <&pwm0_pins_a>;
+ status = "okay";
+};
+
+&tcon0 {
+ pinctrl-names = "default";
+ pinctrl-0 = <&lcd0_rgb666_pins>;
+ status = "okay";
+};
+
+&tcon0_out {
+ tcon0_out_panel: endpoint at 0 {
+ reg = <0>;
+ remote-endpoint = <&panel_input>;
+ };
+};
+
+&uart0 {
+ pinctrl-names = "default";
+ pinctrl-0 = <&uart0_pins_a>;
+ status = "okay";
+};
+
+&usb_otg {
+ dr_mode = "otg";
+ status = "okay";
+};
+
+&usbphy {
+ usb0_id_det-gpio = <&pio 7 4 GPIO_ACTIVE_HIGH>; /* PH4 */
+ usb0_vbus_power-supply = <&usb_power_supply>;
+ usb0_vbus-supply = <®_usb0_vbus>;
+ usb1_vbus-supply = <®_usb1_vbus>;
+ usb2_vbus-supply = <®_usb2_vbus>;
+ status = "okay";
+};
+
+#include "axp209.dtsi"
+
+&battery_power_supply {
+ status = "okay";
+};
+
+®_dcdc2 {
+ regulator-always-on;
+ regulator-min-microvolt = <1000000>;
+ regulator-max-microvolt = <1450000>;
+ regulator-name = "vdd-cpu";
+};
+
+®_dcdc3 {
+ regulator-always-on;
+ regulator-min-microvolt = <1000000>;
+ regulator-max-microvolt = <1400000>;
+ regulator-name = "vdd-int-dll";
+};
+
+®_ldo1 {
+ regulator-name = "vdd-rtc";
+};
+
+®_ldo2 {
+ regulator-always-on;
+ regulator-min-microvolt = <3000000>;
+ regulator-max-microvolt = <3000000>;
+ regulator-name = "avcc";
+};
+
+®_usb0_vbus {
+ status = "okay";
+};
+
+®_usb1_vbus {
+ status = "okay";
+};
+
+®_usb2_vbus {
+ status = "okay";
+};
+
+&usb_power_supply {
+ status = "okay";
+};
--
2.17.0
^ permalink raw reply related
* [RESEND PATCH] pinctrl: rockchip: Disable interrupt when changing it's capability
From: Brian Norris @ 2018-05-07 22:15 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180503065553.7762-1-jeffy.chen@rock-chips.com>
+ Doug
Hi Jeffy,
On Thu, May 03, 2018 at 02:55:53PM +0800, Jeffy Chen wrote:
> We saw spurious irq when changing irq's trigger type, for example
> setting gpio-keys's wakeup irq trigger type.
>
> And according to the TRM:
> "Programming the GPIO registers for interrupt capability, edge-sensitive
> or level-sensitive interrupts, and interrupt polarity should be
> completed prior to enabling the interrupts on Port A in order to prevent
> spurious glitches on the interrupt lines to the interrupt controller."
>
> Reported-by: Brian Norris <briannorris@google.com>
> Signed-off-by: Jeffy Chen <jeffy.chen@rock-chips.com>
> ---
>
> drivers/pinctrl/pinctrl-rockchip.c | 10 ++++++++++
> 1 file changed, 10 insertions(+)
>
> diff --git a/drivers/pinctrl/pinctrl-rockchip.c b/drivers/pinctrl/pinctrl-rockchip.c
> index 3924779f55785..7ff45ec8330d1 100644
> --- a/drivers/pinctrl/pinctrl-rockchip.c
> +++ b/drivers/pinctrl/pinctrl-rockchip.c
> @@ -2727,9 +2727,19 @@ static int rockchip_irq_set_type(struct irq_data *d, unsigned int type)
> return -EINVAL;
> }
>
> + /**
The typical multiline comment style is to use only 1 asterisk -- 2
asterisks usually denote something more formal, like kerneldoc.
> + * According to the TRM, we should keep irq disabled during programming
> + * interrupt capability to prevent spurious glitches on the interrupt
> + * lines to the interrupt controller.
> + */
It's also worth noting that this case may come up in
rockchip_irq_demux() for EDGE_BOTH triggers:
/*
* Triggering IRQ on both rising and falling edge
* needs manual intervention.
*/
if (bank->toggle_edge_mode & BIT(irq)) {
...
polarity = readl_relaxed(bank->reg_base +
GPIO_INT_POLARITY);
if (data & BIT(irq))
polarity &= ~BIT(irq);
else
polarity |= BIT(irq);
writel(polarity,
bank->reg_base + GPIO_INT_POLARITY);
AIUI, this case is not actually a problem, because this polarity
reconfiguration happens before we call generic_handle_irq(), so the
extra spurious interrupt is handled and cleared after this point. But it
seems like this should be noted somewhere in either the commit message,
the code comments, or both.
On the other hand...this also implies there may be a race condition
there, where we might lose an interrupt if there is an edge between the
re-configuration of the polarity in rockchip_irq_demux() and the
clearing/handling of the interrupt (handle_edge_irq() ->
chip->irq_ack()). If we have an edge between there, then we might ack
it, but leave the polarity such that we aren't ready for the next
(inverted) edge.
I'm not 100% sure about the above, so it might be good to verify it. But
I also expect this means there's really no way to 100% reliably
implement both-edge trigger types on hardware like this that doesn't
directly implement it. So I'm not sure what we'd do with that knowledge.
> + data = readl(bank->reg_base + GPIO_INTEN);
> + writel_relaxed(data & ~mask, gc->reg_base + GPIO_INTEN);
Not sure if this is a needless optimization: but couldn't you only
disable the interrupt (and make the level and polarity changes) only if
the level or polarity are actually changing? For example, it's possible
to end up here when changing from EDGE_BOTH to EDGE_RISING, but we might
not actually program a new value.
Brian
> +
> writel_relaxed(level, gc->reg_base + GPIO_INTTYPE_LEVEL);
> writel_relaxed(polarity, gc->reg_base + GPIO_INT_POLARITY);
>
> + writel_relaxed(data, gc->reg_base + GPIO_INTEN);
> +
> irq_gc_unlock(gc);
> raw_spin_unlock_irqrestore(&bank->slock, flags);
> clk_disable(bank->clk);
> --
> 2.11.0
>
>
^ permalink raw reply
* [PATCH v2 21/27] coresight: Convert driver messages to dev_dbg
From: Mathieu Poirier @ 2018-05-07 22:28 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1525165857-11096-22-git-send-email-suzuki.poulose@arm.com>
On Tue, May 01, 2018 at 10:10:51AM +0100, Suzuki K Poulose wrote:
> Convert component enable/disable messages from dev_info to dev_dbg.
> This is required to prevent LOCKDEP splats when operating in perf
> mode where we could be called with locks held to enable a coresight
> path. If someone wants to really see the messages, they can always
> enable it at runtime via dynamic_debug.
I'm also in favor of moving to dev_dbg() - the messages they produce are useless
unless serious debugging of the CS framework is happening. But as Robin Murphy
pointed out it would be great to fix the problem for real rather than masking
it.
I understand this kind of work would be outside the scope of this set. As such
I'd take this patch but the log message would need to be modified to avoid
talking about LOCKDEP splats, only to make sure nobody thinks the problem has
been fixed.
That being said I work extensively with the CS framework every day (with option
CONFIG_LOCKED_SUPPORT=y) and haven't seen any splats. Perhaps you have a
recipe to reproduce the problem?
>
> Cc: Mathieu Poirier <mathieu.poirier@linaro.org>
> Signed-off-by: Suzuki K Poulose <suzuki.poulose@arm.com>
> ---
> drivers/hwtracing/coresight/coresight-dynamic-replicator.c | 4 ++--
> drivers/hwtracing/coresight/coresight-etb10.c | 6 +++---
> drivers/hwtracing/coresight/coresight-etm3x.c | 4 ++--
> drivers/hwtracing/coresight/coresight-etm4x.c | 4 ++--
> drivers/hwtracing/coresight/coresight-funnel.c | 4 ++--
> drivers/hwtracing/coresight/coresight-replicator.c | 4 ++--
> drivers/hwtracing/coresight/coresight-stm.c | 4 ++--
> drivers/hwtracing/coresight/coresight-tmc-etf.c | 8 ++++----
> drivers/hwtracing/coresight/coresight-tmc-etr.c | 4 ++--
> drivers/hwtracing/coresight/coresight-tmc.c | 4 ++--
> drivers/hwtracing/coresight/coresight-tpiu.c | 4 ++--
> 11 files changed, 25 insertions(+), 25 deletions(-)
>
> diff --git a/drivers/hwtracing/coresight/coresight-dynamic-replicator.c b/drivers/hwtracing/coresight/coresight-dynamic-replicator.c
> index 043da86..c41d95c 100644
> --- a/drivers/hwtracing/coresight/coresight-dynamic-replicator.c
> +++ b/drivers/hwtracing/coresight/coresight-dynamic-replicator.c
> @@ -64,7 +64,7 @@ static int replicator_enable(struct coresight_device *csdev, int inport,
>
> CS_LOCK(drvdata->base);
>
> - dev_info(drvdata->dev, "REPLICATOR enabled\n");
> + dev_dbg(drvdata->dev, "REPLICATOR enabled\n");
> return 0;
> }
>
> @@ -83,7 +83,7 @@ static void replicator_disable(struct coresight_device *csdev, int inport,
>
> CS_LOCK(drvdata->base);
>
> - dev_info(drvdata->dev, "REPLICATOR disabled\n");
> + dev_dbg(drvdata->dev, "REPLICATOR disabled\n");
> }
>
> static const struct coresight_ops_link replicator_link_ops = {
> diff --git a/drivers/hwtracing/coresight/coresight-etb10.c b/drivers/hwtracing/coresight/coresight-etb10.c
> index 74232e6..d9c2f87 100644
> --- a/drivers/hwtracing/coresight/coresight-etb10.c
> +++ b/drivers/hwtracing/coresight/coresight-etb10.c
> @@ -163,7 +163,7 @@ static int etb_enable(struct coresight_device *csdev, u32 mode)
> spin_unlock_irqrestore(&drvdata->spinlock, flags);
>
> out:
> - dev_info(drvdata->dev, "ETB enabled\n");
> + dev_dbg(drvdata->dev, "ETB enabled\n");
> return 0;
> }
>
> @@ -269,7 +269,7 @@ static void etb_disable(struct coresight_device *csdev)
>
> local_set(&drvdata->mode, CS_MODE_DISABLED);
>
> - dev_info(drvdata->dev, "ETB disabled\n");
> + dev_dbg(drvdata->dev, "ETB disabled\n");
> }
>
> static void *etb_alloc_buffer(struct coresight_device *csdev, int cpu,
> @@ -512,7 +512,7 @@ static void etb_dump(struct etb_drvdata *drvdata)
> }
> spin_unlock_irqrestore(&drvdata->spinlock, flags);
>
> - dev_info(drvdata->dev, "ETB dumped\n");
> + dev_dbg(drvdata->dev, "ETB dumped\n");
> }
>
> static int etb_open(struct inode *inode, struct file *file)
> diff --git a/drivers/hwtracing/coresight/coresight-etm3x.c b/drivers/hwtracing/coresight/coresight-etm3x.c
> index 39f42fd..9d4a663 100644
> --- a/drivers/hwtracing/coresight/coresight-etm3x.c
> +++ b/drivers/hwtracing/coresight/coresight-etm3x.c
> @@ -510,7 +510,7 @@ static int etm_enable_sysfs(struct coresight_device *csdev)
> drvdata->sticky_enable = true;
> spin_unlock(&drvdata->spinlock);
>
> - dev_info(drvdata->dev, "ETM tracing enabled\n");
> + dev_dbg(drvdata->dev, "ETM tracing enabled\n");
> return 0;
>
> err:
> @@ -613,7 +613,7 @@ static void etm_disable_sysfs(struct coresight_device *csdev)
> spin_unlock(&drvdata->spinlock);
> cpus_read_unlock();
>
> - dev_info(drvdata->dev, "ETM tracing disabled\n");
> + dev_dbg(drvdata->dev, "ETM tracing disabled\n");
> }
>
> static void etm_disable(struct coresight_device *csdev,
> diff --git a/drivers/hwtracing/coresight/coresight-etm4x.c b/drivers/hwtracing/coresight/coresight-etm4x.c
> index e84d80b..c9c73c2 100644
> --- a/drivers/hwtracing/coresight/coresight-etm4x.c
> +++ b/drivers/hwtracing/coresight/coresight-etm4x.c
> @@ -274,7 +274,7 @@ static int etm4_enable_sysfs(struct coresight_device *csdev)
> drvdata->sticky_enable = true;
> spin_unlock(&drvdata->spinlock);
>
> - dev_info(drvdata->dev, "ETM tracing enabled\n");
> + dev_dbg(drvdata->dev, "ETM tracing enabled\n");
> return 0;
>
> err:
> @@ -387,7 +387,7 @@ static void etm4_disable_sysfs(struct coresight_device *csdev)
> spin_unlock(&drvdata->spinlock);
> cpus_read_unlock();
>
> - dev_info(drvdata->dev, "ETM tracing disabled\n");
> + dev_dbg(drvdata->dev, "ETM tracing disabled\n");
> }
>
> static void etm4_disable(struct coresight_device *csdev,
> diff --git a/drivers/hwtracing/coresight/coresight-funnel.c b/drivers/hwtracing/coresight/coresight-funnel.c
> index 9f8ac0be..18b5361 100644
> --- a/drivers/hwtracing/coresight/coresight-funnel.c
> +++ b/drivers/hwtracing/coresight/coresight-funnel.c
> @@ -72,7 +72,7 @@ static int funnel_enable(struct coresight_device *csdev, int inport,
>
> funnel_enable_hw(drvdata, inport);
>
> - dev_info(drvdata->dev, "FUNNEL inport %d enabled\n", inport);
> + dev_dbg(drvdata->dev, "FUNNEL inport %d enabled\n", inport);
> return 0;
> }
>
> @@ -96,7 +96,7 @@ static void funnel_disable(struct coresight_device *csdev, int inport,
>
> funnel_disable_hw(drvdata, inport);
>
> - dev_info(drvdata->dev, "FUNNEL inport %d disabled\n", inport);
> + dev_dbg(drvdata->dev, "FUNNEL inport %d disabled\n", inport);
> }
>
> static const struct coresight_ops_link funnel_link_ops = {
> diff --git a/drivers/hwtracing/coresight/coresight-replicator.c b/drivers/hwtracing/coresight/coresight-replicator.c
> index 3756e71..4f77812 100644
> --- a/drivers/hwtracing/coresight/coresight-replicator.c
> +++ b/drivers/hwtracing/coresight/coresight-replicator.c
> @@ -42,7 +42,7 @@ static int replicator_enable(struct coresight_device *csdev, int inport,
> {
> struct replicator_drvdata *drvdata = dev_get_drvdata(csdev->dev.parent);
>
> - dev_info(drvdata->dev, "REPLICATOR enabled\n");
> + dev_dbg(drvdata->dev, "REPLICATOR enabled\n");
> return 0;
> }
>
> @@ -51,7 +51,7 @@ static void replicator_disable(struct coresight_device *csdev, int inport,
> {
> struct replicator_drvdata *drvdata = dev_get_drvdata(csdev->dev.parent);
>
> - dev_info(drvdata->dev, "REPLICATOR disabled\n");
> + dev_dbg(drvdata->dev, "REPLICATOR disabled\n");
> }
>
> static const struct coresight_ops_link replicator_link_ops = {
> diff --git a/drivers/hwtracing/coresight/coresight-stm.c b/drivers/hwtracing/coresight/coresight-stm.c
> index 15e7ef38..4c88d99 100644
> --- a/drivers/hwtracing/coresight/coresight-stm.c
> +++ b/drivers/hwtracing/coresight/coresight-stm.c
> @@ -218,7 +218,7 @@ static int stm_enable(struct coresight_device *csdev,
> stm_enable_hw(drvdata);
> spin_unlock(&drvdata->spinlock);
>
> - dev_info(drvdata->dev, "STM tracing enabled\n");
> + dev_dbg(drvdata->dev, "STM tracing enabled\n");
> return 0;
> }
>
> @@ -281,7 +281,7 @@ static void stm_disable(struct coresight_device *csdev,
> pm_runtime_put(drvdata->dev);
>
> local_set(&drvdata->mode, CS_MODE_DISABLED);
> - dev_info(drvdata->dev, "STM tracing disabled\n");
> + dev_dbg(drvdata->dev, "STM tracing disabled\n");
> }
> }
>
> diff --git a/drivers/hwtracing/coresight/coresight-tmc-etf.c b/drivers/hwtracing/coresight/coresight-tmc-etf.c
> index 1dd44fd..0a32734 100644
> --- a/drivers/hwtracing/coresight/coresight-tmc-etf.c
> +++ b/drivers/hwtracing/coresight/coresight-tmc-etf.c
> @@ -244,7 +244,7 @@ static int tmc_enable_etf_sink(struct coresight_device *csdev, u32 mode)
> if (ret)
> return ret;
>
> - dev_info(drvdata->dev, "TMC-ETB/ETF enabled\n");
> + dev_dbg(drvdata->dev, "TMC-ETB/ETF enabled\n");
> return 0;
> }
>
> @@ -267,7 +267,7 @@ static void tmc_disable_etf_sink(struct coresight_device *csdev)
>
> spin_unlock_irqrestore(&drvdata->spinlock, flags);
>
> - dev_info(drvdata->dev, "TMC-ETB/ETF disabled\n");
> + dev_dbg(drvdata->dev, "TMC-ETB/ETF disabled\n");
> }
>
> static int tmc_enable_etf_link(struct coresight_device *csdev,
> @@ -286,7 +286,7 @@ static int tmc_enable_etf_link(struct coresight_device *csdev,
> drvdata->mode = CS_MODE_SYSFS;
> spin_unlock_irqrestore(&drvdata->spinlock, flags);
>
> - dev_info(drvdata->dev, "TMC-ETF enabled\n");
> + dev_dbg(drvdata->dev, "TMC-ETF enabled\n");
> return 0;
> }
>
> @@ -306,7 +306,7 @@ static void tmc_disable_etf_link(struct coresight_device *csdev,
> drvdata->mode = CS_MODE_DISABLED;
> spin_unlock_irqrestore(&drvdata->spinlock, flags);
>
> - dev_info(drvdata->dev, "TMC-ETF disabled\n");
> + dev_dbg(drvdata->dev, "TMC-ETF disabled\n");
> }
>
> static void *tmc_alloc_etf_buffer(struct coresight_device *csdev, int cpu,
> diff --git a/drivers/hwtracing/coresight/coresight-tmc-etr.c b/drivers/hwtracing/coresight/coresight-tmc-etr.c
> index 41dde0a..1ef0f62 100644
> --- a/drivers/hwtracing/coresight/coresight-tmc-etr.c
> +++ b/drivers/hwtracing/coresight/coresight-tmc-etr.c
> @@ -1350,7 +1350,7 @@ static int tmc_enable_etr_sink_sysfs(struct coresight_device *csdev)
> tmc_etr_free_sysfs_buf(free_buf);
>
> if (!ret)
> - dev_info(drvdata->dev, "TMC-ETR enabled\n");
> + dev_dbg(drvdata->dev, "TMC-ETR enabled\n");
>
> return ret;
> }
> @@ -1393,7 +1393,7 @@ static void tmc_disable_etr_sink(struct coresight_device *csdev)
>
> spin_unlock_irqrestore(&drvdata->spinlock, flags);
>
> - dev_info(drvdata->dev, "TMC-ETR disabled\n");
> + dev_dbg(drvdata->dev, "TMC-ETR disabled\n");
> }
>
> static const struct coresight_ops_sink tmc_etr_sink_ops = {
> diff --git a/drivers/hwtracing/coresight/coresight-tmc.c b/drivers/hwtracing/coresight/coresight-tmc.c
> index 4d41b4b..7adcde3 100644
> --- a/drivers/hwtracing/coresight/coresight-tmc.c
> +++ b/drivers/hwtracing/coresight/coresight-tmc.c
> @@ -92,7 +92,7 @@ static int tmc_read_prepare(struct tmc_drvdata *drvdata)
> }
>
> if (!ret)
> - dev_info(drvdata->dev, "TMC read start\n");
> + dev_dbg(drvdata->dev, "TMC read start\n");
>
> return ret;
> }
> @@ -114,7 +114,7 @@ static int tmc_read_unprepare(struct tmc_drvdata *drvdata)
> }
>
> if (!ret)
> - dev_info(drvdata->dev, "TMC read end\n");
> + dev_dbg(drvdata->dev, "TMC read end\n");
>
> return ret;
> }
> diff --git a/drivers/hwtracing/coresight/coresight-tpiu.c b/drivers/hwtracing/coresight/coresight-tpiu.c
> index 805f7c2..c7f0827 100644
> --- a/drivers/hwtracing/coresight/coresight-tpiu.c
> +++ b/drivers/hwtracing/coresight/coresight-tpiu.c
> @@ -80,7 +80,7 @@ static int tpiu_enable(struct coresight_device *csdev, u32 mode)
>
> tpiu_enable_hw(drvdata);
>
> - dev_info(drvdata->dev, "TPIU enabled\n");
> + dev_dbg(drvdata->dev, "TPIU enabled\n");
> return 0;
> }
>
> @@ -106,7 +106,7 @@ static void tpiu_disable(struct coresight_device *csdev)
>
> tpiu_disable_hw(drvdata);
>
> - dev_info(drvdata->dev, "TPIU disabled\n");
> + dev_dbg(drvdata->dev, "TPIU disabled\n");
> }
>
> static const struct coresight_ops_sink tpiu_sink_ops = {
> --
> 2.7.4
>
^ permalink raw reply
* coresight: documentation: update sysfs section
From: Kim Phillips @ 2018-05-07 22:29 UTC (permalink / raw)
To: linux-arm-kernel
- Align and show updated ls devices output from the TC2, based on
current driver
- Provide an example from an ETMv4 based system (Juno)
- Reflect changes to the way the RAM write pointer is accessed since
it got changed in commit 7d83d17795ef ("coresight: tmc: adding sysFS
management entries").
Cc: Mathieu Poirier <mathieu.poirier@linaro.org>
Cc: Jonathan Corbet <corbet@lwn.net>
Signed-off-by: Kim Phillips <kim.phillips@arm.com>
---
Documentation/trace/coresight.txt | 40 ++++++++++++++++++-------------
1 file changed, 24 insertions(+), 16 deletions(-)
diff --git a/Documentation/trace/coresight.txt b/Documentation/trace/coresight.txt
index 6f0120c3a4f1..d23d6354b372 100644
--- a/Documentation/trace/coresight.txt
+++ b/Documentation/trace/coresight.txt
@@ -144,10 +144,21 @@ If everything goes well during the registration process the new devices will
show up under /sys/bus/coresight/devices, as showns here for a TC2 platform:
root:~# ls /sys/bus/coresight/devices/
-replicator 20030000.tpiu 2201c000.ptm 2203c000.etm 2203e000.etm
-20010000.etb 20040000.funnel 2201d000.ptm 2203d000.etm
+20010000.etb 20040000.funnel 2201d000.ptm 2203d000.etm replicator
+20030000.tpiu 2201c000.ptm 2203c000.etm 2203e000.etm
root:~#
+and here for a Juno platform:
+
+root at juno:~# ls /sys/bus/coresight/devices/
+20010000.etf 20120000.replicator 22040000.etm 230c0000.funnel
+20030000.tpiu 20130000.funnel 220c0000.funnel 23140000.etm
+20040000.funnel 20140000.etf 22140000.etm 23240000.etm
+20070000.etr 20150000.funnel 23040000.etm 23340000.etm
+root at juno:~#
+
+Note the Juno uses an Embedded Trace Router (ETR) instead of an ETB.
+
The functions take a "struct coresight_device", which looks like this:
struct coresight_desc {
@@ -193,16 +204,16 @@ the information carried in "THIS_MODULE".
How to use the tracer modules
-----------------------------
-Before trace collection can start, a coresight sink needs to be identify.
+Before trace collection can start, a coresight sink needs to be identified.
There is no limit on the amount of sinks (nor sources) that can be enabled at
any given moment. As a generic operation, all device pertaining to the sink
class will have an "active" entry in sysfs:
root:/sys/bus/coresight/devices# ls
-replicator 20030000.tpiu 2201c000.ptm 2203c000.etm 2203e000.etm
-20010000.etb 20040000.funnel 2201d000.ptm 2203d000.etm
+20010000.etb 20040000.funnel 2201d000.ptm 2203d000.etm replicator
+20030000.tpiu 2201c000.ptm 2203c000.etm 2203e000.etm
root:/sys/bus/coresight/devices# ls 20010000.etb
-enable_sink status trigger_cntr
+enable_sink mgmt power subsystem trigger_cntr uevent
root:/sys/bus/coresight/devices# echo 1 > 20010000.etb/enable_sink
root:/sys/bus/coresight/devices# cat 20010000.etb/enable_sink
1
@@ -216,16 +227,13 @@ trigger a trace capture:
root:/sys/bus/coresight/devices# echo 1 > 2201c000.ptm/enable_source
root:/sys/bus/coresight/devices# cat 2201c000.ptm/enable_source
1
-root:/sys/bus/coresight/devices# cat 20010000.etb/status
-Depth: 0x2000
-Status: 0x1
-RAM read ptr: 0x0
-RAM wrt ptr: 0x19d3 <----- The write pointer is moving
-Trigger cnt: 0x0
-Control: 0x1
-Flush status: 0x0
-Flush ctrl: 0x2001
-root:/sys/bus/coresight/devices#
+
+Observe the write pointer moving:
+
+root:/sys/bus/coresight/devices# cat 20010000.etb/mgmt/rwp
+0x1a8
+root:/sys/bus/coresight/devices# cat 20010000.etb/mgmt/rwp
+0x19a6
Trace collection is stopped the same way:
--
2.17.0
^ permalink raw reply related
* [RFC PATCH] driver core: make deferring probe forever optional
From: Bjorn Andersson @ 2018-05-07 22:34 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAL_Jsq+PRUR5rCeV820XZuQmQH3gD-X=6a5fNuF-9qVbq5dqFg@mail.gmail.com>
On Mon 07 May 12:55 PDT 2018, Rob Herring wrote:
> On Mon, May 7, 2018 at 1:31 PM, Bjorn Andersson
> <bjorn.andersson@linaro.org> wrote:
> > On Tue 01 May 14:31 PDT 2018, Rob Herring wrote:
> >
> >> Deferred probe will currently wait forever on dependent devices to probe,
> >> but sometimes a driver will never exist. It's also not always critical for
> >> a driver to exist. Platforms can rely on default configuration from the
> >> bootloader or reset defaults for things such as pinctrl and power domains.
> >
> > But how do you know if this is the case?
>
> Because the platform worked before adding the dependency in the dts.
>
I'm worried about how to write dts files and drivers to support all
permutation of forward and backward dependencies. And you most
definitely have the same case with bootloader-enabled clocks,
regulators and interconnects.
> >> This is often the case with initial platform support until various drivers
> >> get enabled.
> >
> > Can you please name platform that has enough support for Alexander to
> > care about backwards and forwards compatibility but lacks a pinctrl
> > driver.
>
> Alex will have to answer that. I do agree pinctrl drivers shouldn't be
> that hard because it is all just translating a bunch of pin data into
> one-time (mostly) register writes, so it shouldn't take that long to
> implement support. OTOH, maybe a pinctrl driver is low priority
> because nothing needs it yet. Either a given board works with the
> defaults and only some new board needs to change things or you don't
> need pinctrl until low power modes are implemented. However, power
> domains have the same problem and it can take years for those to get
> proper support.
>
> Alex proposed declaring dts files stable and then enforcing
> compatibility after that point. If anyone believes that will work,
> then please send a patch marking all the platforms in the kernel tree
> that are stable.
>
That might be a reasonable idea, but at least in our corner the current
decision that devicetree should be backwards compatible does make it
quite cumbersome to break this assumption - and in the cases we have had
to do it it's really been necessary.
> >> There's at least 2 scenarios where deferred probe can render
> >> a platform broken. Both involve using a DT which has more devices and
> >> dependencies than the kernel supports. The 1st case is a driver may be
> >> disabled in the kernel config.
> >
> > I agree that there is a chance that you _might_ get some parts of the
> > system working by relying on the boot loader configuration, but
> > misconfiguration issues applies to any other fundamental providers, such
> > as clocks, regulators, power domains and gpios as well.
>
> If it is only a chance, then perhaps we shouldn't allow things
> upstream without proper drivers for all these things. That will only
> give users the wrong impression.
>
It's not as much the drivers that's the problem here as it is the
composition of the drivers. For this particular case it would be
convenient not to ship the partial dtb, or at least not ship it with the
promise that it's stable.
> >> The 2nd case is the kernel version may
> >> simply not have the dependent driver. This can happen if using a newer DT
> >> (provided by firmware perhaps) with a stable kernel version.
> >>
> >
> > As above, this is in no way limited to pinctrl drivers.
>
> Yes, I wasn't trying to imply that with this patch. I was just
> starting with 1 example. IOMMUs (which essentially is already doing
> what this patch does) and power domains are the main other 2.
qcom,iommu-v1 is bool, but depends on e.g. CONFIG_MSM_GCC_8916 which is
tristate. So you would need to s/tristate/bool/ everything in
drivers/clk/qcom/Kconfig as well. Not to mention that there are
interconnects and power domains actually involved here as well...
> Clocks is an obvious one too, but from the discussion I referenced
> that problem is a bit different as platforms change from dummy
> fixed-clocks to a real clock controller driver. That will need a
> different solution.
So how are you going to deal with the case when a vendor decides to ship
their firmware package with all clocks enabled and only fixed clocks
described in DT and as they upstream a clock driver and patch their
firmware to do the right thing?
(Or the much less extreme case where this happens for a single clock,
regulator, pinctrl, interconnect, etc to fix some bug/power management
behavior)
And is this really a problem that does not exists in the ACPI world?
>
> >> Unfortunately, this change breaks with modules as we have no way of
> >> knowing when modules are done loading. One possibility is to make this
> >> opt in or out based on compatible strings rather than at a subsystem level.
> >> Ideally this information could be extracted automatically somehow. OTOH,
> >> maybe the lists are pretty small. There's only a handful of subsystems
> >> that can be optional, and then only so many drivers in those that can be
> >> modules (at least for pinctrl, many drivers are built-in only).
> >>
> >
> > On the Qualcomm platform most drivers are tristate and on most platforms
> > there are size restrictions in the proprietary boot loader preventing us
> > from boot the kernel after switching all these frameworks from tristate
> > to bool (which feels like a more appropriate solution than your hack).
>
> BTW, QCom platforms are almost the only ones with pinctrl drivers as
> modules. They are also happen to be PIA to configure correctly for a
> board.
>
There are a few pinctrl drivers for chips sitting on i2c busses, as such
changing this requirement would trickle down to a number of possible i2c
masters as well.
Sorry to hear that you find it so difficult to configure the pinctrl,
it's (almost) entirely using the common pinctrl bindings. Perhaps we
need to add some documentation of the hardware in the binding?
> However, I would like a solution that works with modules. It would be
> nice to know when userspace finished processing all the coldplug
> uevents. That would be sufficient to support modules. I researched
> that a bit and it doesn't seem the kernel can tell when that has
> happened.
>
It's not that far from the issue I have in remoteproc, where I would
like to boot a DSP as soon as the firmware is available - which might be
probed at any time after boot.
[..]
> >> I tested this on a RPi3 B with the pinctrl driver forced off. With this
> >> change, the MMC/SD and UART drivers can function without the pinctrl
> >> driver.
> >>
> >
> > Cool, so what about graphics, audio, networking, usb and all the other
> > things that people actually expect when they _use_ a distro?
>
> I often care about none of those things. When I do, I'd rather boot to
> a working console with those broken than have to debug why the kernel
> panicked.
>
But that's developer-you speaking, developer-me totally agree.
But when I take the role of being a user of a distro I most definitely
do expect functionality beyond the basics used by the boot loader (UART
and dependencies of the primary storage device).
My argument is simply that in neither of these cases this patch is
helpful.
[..]
> >> +int driver_deferred_probe_optional(void)
> >> +{
> >> + if (initcalls_done)
> >> + return -ENODEV;
> >
> > You forgot the humongous printout here that tells the users that we do
> > not want any bug reports related hardware not working as expected after
> > this point.
>
> I assume you were joking, but I would happily add a WARN here.
About the print yes, but I most definitely do not want to debug issues
related to this!
The crazy issues you get from having electrical properties slightly off
(e.g. drive-strength of the SD-card pins) or the fact that any driver
using pinmuxing will depend on the modprobe ordering.
> Spewing new warnings while still booting is a better UX than just
> panicking. Ideally, it would be once per missing dependency.
>
Having a convenient way of listing all unmatched devices or devices
sitting in probe deferral would be quite convenient, as a development
tool. I know this hassle was the starting point of some of Frank's
tools.
Regards,
Bjorn
^ permalink raw reply
* [PATCH v4 3/9] dt-bindings: input: touchscreen: add pressure threshold touchscreen property
From: Dmitry Torokhov @ 2018-05-07 22:38 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1525084335-11276-4-git-send-email-eugen.hristev@microchip.com>
On Mon, Apr 30, 2018 at 01:32:09PM +0300, Eugen Hristev wrote:
> Add a common touchscreen optional property that will specify
> the minimum pressure applied to the screen that is needed
> such that the driver will report the touch event.
>
> Signed-off-by: Eugen Hristev <eugen.hristev@microchip.com>
> Reviewed-by: Rob Herring <robh@kernel.org>
> ---
> Documentation/devicetree/bindings/input/touchscreen/touchscreen.txt | 3 +++
> 1 file changed, 3 insertions(+)
>
> diff --git a/Documentation/devicetree/bindings/input/touchscreen/touchscreen.txt b/Documentation/devicetree/bindings/input/touchscreen/touchscreen.txt
> index 537643e..c84047a 100644
> --- a/Documentation/devicetree/bindings/input/touchscreen/touchscreen.txt
> +++ b/Documentation/devicetree/bindings/input/touchscreen/touchscreen.txt
> @@ -7,6 +7,9 @@ Optional properties for Touchscreens:
> (in pixels)
> - touchscreen-max-pressure : maximum reported pressure (arbitrary range
> dependent on the controller)
> + - touchscreen-threshold-pressure: minimum pressure on the touchscreen to be
> + achieved in order for the touchscreen
> + driver to report a touch event.
Why do we move from the pattern and call it trheshold and not
touchscreen-min-pressure?
> - touchscreen-fuzz-x : horizontal noise value of the absolute input
> device (in pixels)
> - touchscreen-fuzz-y : vertical noise value of the absolute input
> --
> 2.7.4
>
Thanks.
--
Dmitry
^ 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