* [PATCH v7 00/16] ACPI IORT ARM SMMU support
From: Lorenzo Pieralisi @ 2016-11-15 10:12 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAJZ5v0j09fsp4Y66v2UANOGnW4FNO7PWxpZY=Pgw=bUccEL_eA@mail.gmail.com>
Hi Rafael,
On Thu, Nov 10, 2016 at 12:36:12AM +0100, Rafael J. Wysocki wrote:
> Hi Lorenzo,
>
> On Wed, Nov 9, 2016 at 3:19 PM, Lorenzo Pieralisi
> <lorenzo.pieralisi@arm.com> wrote:
> > This patch series is v7 of a previous posting:
> >
> > https://lkml.org/lkml/2016/10/18/506
>
> I don't see anything objectionable in this series.
>
> Please let me know which patches in particular to look at in detail.
Are patches 7 and consequently 16 (that builds on top of 7) ok with
you ? They should be equivalent to nop on anything other than ARM64
but they touch ACPI core so they require an ACK if they are ok please.
Thank you very much !
Lorenzo
^ permalink raw reply
* [PATCH 1/2] ARM: dts: sun5i: Add touchscreen node to reference-design-tablet.dtsi
From: Hans de Goede @ 2016-11-15 10:12 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161114200802.vdduhyxnkgmpsyd5@lukather>
Hi,
On 14-11-16 21:08, Maxime Ripard wrote:
> Hi,
>
> On Sun, Nov 13, 2016 at 08:22:02PM +0100, Hans de Goede wrote:
>> Just like on sun8i all sun5i tablets use the same interrupt and power
>> gpios for their touchscreens. I've checked all known a13 fex files and
>> only the UTOO P66 uses a different gpio for the interrupt.
>>
>> Add a touchscreen node to sun5i-reference-design-tablet.dtsi, which
>> fills in the necessary gpios to avoid duplication in the tablet dts files,
>> just like we do in sun8i-reference-design-tablet.dtsi.
>>
>> This will make future patches adding touchscreen nodes to a13 tablets
>> simpler.
>>
>> Signed-off-by: Hans de Goede <hdegoede@redhat.com>
>> ---
>> arch/arm/boot/dts/sun5i-a13-utoo-p66.dts | 38 ++++++++--------------
>> .../boot/dts/sun5i-reference-design-tablet.dtsi | 25 ++++++++++++++
>> 2 files changed, 39 insertions(+), 24 deletions(-)
>>
>> diff --git a/arch/arm/boot/dts/sun5i-a13-utoo-p66.dts b/arch/arm/boot/dts/sun5i-a13-utoo-p66.dts
>> index a8b0bcc..3d7ff10 100644
>> --- a/arch/arm/boot/dts/sun5i-a13-utoo-p66.dts
>> +++ b/arch/arm/boot/dts/sun5i-a13-utoo-p66.dts
>> @@ -83,22 +83,6 @@
>> allwinner,pins = "PG3";
>> };
>>
>> -&i2c1 {
>> - icn8318: touchscreen at 40 {
>> - compatible = "chipone,icn8318";
>> - reg = <0x40>;
>> - interrupt-parent = <&pio>;
>> - interrupts = <6 9 IRQ_TYPE_EDGE_FALLING>; /* EINT9 (PG9) */
>> - pinctrl-names = "default";
>> - pinctrl-0 = <&ts_wake_pin_p66>;
>> - wake-gpios = <&pio 1 3 GPIO_ACTIVE_HIGH>; /* PB3 */
>> - touchscreen-size-x = <800>;
>> - touchscreen-size-y = <480>;
>> - touchscreen-inverted-x;
>> - touchscreen-swapped-x-y;
>> - };
>> -};
>> -
>> &mmc2 {
>> pinctrl-names = "default";
>> pinctrl-0 = <&mmc2_pins_a>;
>> @@ -121,20 +105,26 @@
>> allwinner,drive = <SUN4I_PINCTRL_10_MA>;
>> allwinner,pull = <SUN4I_PINCTRL_PULL_UP>;
>> };
>> -
>> - ts_wake_pin_p66: ts_wake_pin at 0 {
>> - allwinner,pins = "PB3";
>> - allwinner,function = "gpio_out";
>> - allwinner,drive = <SUN4I_PINCTRL_10_MA>;
>> - allwinner,pull = <SUN4I_PINCTRL_NO_PULL>;
>> - };
>> -
>> };
>>
>> ®_usb0_vbus {
>> gpio = <&pio 1 4 GPIO_ACTIVE_HIGH>; /* PB4 */
>> };
>>
>> +&touchscreen {
>> + compatible = "chipone,icn8318";
>> + reg = <0x40>;
>> + /* The P66 uses a different EINT then the reference design */
>> + interrupts = <6 9 IRQ_TYPE_EDGE_FALLING>; /* EINT9 (PG9) */
>> + /* The icn8318 binding expects wake-gpios instead of power-gpios */
>> + wake-gpios = <&pio 1 3 GPIO_ACTIVE_HIGH>; /* PB3 */
>> + touchscreen-size-x = <800>;
>> + touchscreen-size-y = <480>;
>> + touchscreen-inverted-x;
>> + touchscreen-swapped-x-y;
>> + status = "okay";
>> +};
>> +
>> &uart1 {
>> /* The P66 uses the uart pins as gpios */
>> status = "disabled";
>> diff --git a/arch/arm/boot/dts/sun5i-reference-design-tablet.dtsi b/arch/arm/boot/dts/sun5i-reference-design-tablet.dtsi
>> index 20cc940..7af488a 100644
>> --- a/arch/arm/boot/dts/sun5i-reference-design-tablet.dtsi
>> +++ b/arch/arm/boot/dts/sun5i-reference-design-tablet.dtsi
>> @@ -41,6 +41,7 @@
>> */
>> #include "sunxi-reference-design-tablet.dtsi"
>>
>> +#include <dt-bindings/interrupt-controller/irq.h>
>> #include <dt-bindings/pwm/pwm.h>
>>
>> / {
>> @@ -84,6 +85,23 @@
>> };
>>
>> &i2c1 {
>> + /*
>> + * The gsl1680 is rated at 400KHz and it will not work reliable at
>> + * 100KHz, this has been confirmed on multiple different q8 tablets.
>> + * All other devices on this bus are also rated for 400KHz.
>> + */
>> + clock-frequency = <400000>;
>> +
>> + touchscreen: touchscreen {
>> + interrupt-parent = <&pio>;
>> + interrupts = <6 11 IRQ_TYPE_EDGE_FALLING>; /* EINT11 (PG11) */
>> + pinctrl-names = "default";
>> + pinctrl-0 = <&ts_power_pin>;
>> + power-gpios = <&pio 1 3 GPIO_ACTIVE_HIGH>; /* PB3 */
>> + /* Tablet dts must provide reg and compatible */
>> + status = "disabled";
>> + };
>> +
>> pcf8563: rtc at 51 {
>> compatible = "nxp,pcf8563";
>> reg = <0x51>;
>> @@ -125,6 +143,13 @@
>> allwinner,pull = <SUN4I_PINCTRL_PULL_UP>;
>> };
>>
>> + ts_power_pin: ts_power_pin {
>> + allwinner,pins = "PB3";
>> + allwinner,function = "gpio_out";
>> + allwinner,drive = <SUN4I_PINCTRL_10_MA>;
>> + allwinner,pull = <SUN4I_PINCTRL_NO_PULL>;
>> + };
>> +
>
> For the next release, we'll switch to the generic pin mux properties
> ("pins" and "function"), and we actually implemented the fact that the
> drive and pull properties are optional, so you can drop them both.
>
> You'll need next + http://lists.infradead.org/pipermail/linux-arm-kernel/2016-November/467123.html
Ok, before I send a v2 first a question about this, for the touchscreen
case I actually need:
allwinner,drive = <SUN4I_PINCTRL_10_MA>;
allwinner,pull = <SUN4I_PINCTRL_NO_PULL>;
Because otherwise when the touchscreen controller is powered by a separate
regulator and that regulator is off, then it may draw just enough current
from its enable pin to be sort-of listening to the i2c bus and mess up
that bus.
So is this the default, or do we get the power-on default when not
specifying these? If it is the power-on default then we do need to
specify these, because AFAICT the power-on drive strength typically
is 20 mA.
Regards,
Hans
^ permalink raw reply
* [PATCH 2/2] ARM: davinci_all_defconfig: enable the mstpri and ddrctl drivers
From: Sekhar Nori @ 2016-11-15 10:12 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1479144724-14231-3-git-send-email-bgolaszewski@baylibre.com>
On Monday 14 November 2016 11:02 PM, Bartosz Golaszewski wrote:
> With the da8xx memory controller and master peripheral priority
> drivers merged and corresponding device tree changes in place we can
> now enable appropriate options by default.
>
> Signed-off-by: Bartosz Golaszewski <bgolaszewski@baylibre.com>
Applied to v4.10/defconfig
Thanks,
Sekhar
^ permalink raw reply
* PM regression with LED changes in next-20161109
From: Hans de Goede @ 2016-11-15 10:09 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <6d88b2a7-a506-89bf-fc76-af707ed7a00f@samsung.com>
Hi,
On 15-11-16 11:01, Jacek Anaszewski wrote:
> Hi,
>
> On 11/14/2016 01:51 PM, Hans de Goede wrote:
<snip>
>> Ugh, I see I accidentally send a v4 twice, instead of
>> calling the version which dropped those called v5 as
>> I should have, sorry.
>>
>> The v4 which I would like to see merged, the one with
>> those calls dropped, is here:
>>
>> https://patchwork.kernel.org/patch/9423093/
>
> Right I've had an impression that I've already seen something
> different than "first" v4.
>
> Regarding the patch - adding led_notify_brightness_change() to
> brightness_store() can have similar power consumption related
> implications if brightness is set frequently via sysfs.
That means that userspace is waking up frequently to write the
sysfs file, so in that case userspace is already draining
a lot of energy, so I don't think that is something we need to
worry about.
> I'm leaning
> towards adding a new brightness file similar to user_brightness
> discussed in this thread.
>
> It would cover shortcomings and read/write inconsistencies that
> brightness file currently has, but without breaking existing users.
>
> I'd not however go for "user_brightness" name due to the possible
> brightness adjustments made autonomously by firmware. I'm afraid
> that devising a meaningful name for the new file will be hard,
> so the simplest would be just brighntess2. Dedicated section
> in leds-class.txt should be devoted to it.
Ok, let me quote myself from another part of this thread:
We've 2 sorts of brightness really:
1) transient brightness, aka current brightness, when blinking or
triggers are used this will switch many times a second
between off and some on level.
2) non-transient brightness, for non blinking leds this is the
actual brightness, for blinking leds this is the brightness
level used when the led is on.
Now we want to have a sysfs attribute reflecting 2, so that
userspace can poll on that, both for my use-case as well as so
that userspace process a can detect changes made by writing to
the brightness file by process b.
So maybe we need to simply call the new attribute
non_transient_brightness instead of user_brightness?
non_transient_brightness certainly seems like a better name
then brightness2 ?
Regards,
Hans
^ permalink raw reply
* [PATCH v7 04/16] drivers: iommu: make of_iommu_set/get_ops() DT agnostic
From: Lorenzo Pieralisi @ 2016-11-15 10:07 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <313844ca-d948-1297-84b2-669f3a7d57d2@arm.com>
On Mon, Nov 14, 2016 at 06:25:16PM +0000, Robin Murphy wrote:
> On 14/11/16 15:52, Joerg Roedel wrote:
> > On Mon, Nov 14, 2016 at 12:00:47PM +0000, Robin Murphy wrote:
> >> If we've already made the decision to move away from bus ops, I don't
> >> see that it makes sense to deliberately introduce new dependencies on
> >> them. Besides, as it stands, this patch literally implements "tell the
> >> iommu-core which hardware-iommus exist in the system and a seperate
> >> iommu_ops ptr for each of them" straight off.
> >
> > Not sure which code you are looking at, but as I see it we have only
> > per-device iommu-ops now (with this patch). That is different from
> > having core-visible hardware-iommu instances where devices could link
> > to.
>
> The per-device IOMMU ops are already there since 57f98d2f61e1. This
> patch generalises the other end, moving the "registering an IOMMU
> instance" (i.e. iommu_fwentry) bit into the IOMMU core, from being
> OF-specific. I'd be perfectly happy if we rename iommu_fwentry to
> iommu_instance, fwnode_iommu_set_ops() to iommu_register_instance(), and
> such if that makes the design intent clearer.
I second that and I need to know what to do with this patch sooner
rather than later so it is time we make a decision please.
Joerg, what's your opinion ?
Thanks,
Lorenzo
> If you'd also prefer to replace iommu_fwspec::ops with an opaque
> iommu_fwspec::iommu_instance pointer so that things are a bit more
> centralised (and users are forced to go through the API rather then call
> ops directly), I'd have no major objection either. My main point is that
> we've been deliberately putting the relevant building blocks in place -
> the of_iommu_{get,set}_ops stuff was designed from the start to
> accommodate per-instance ops, via the ops pointer *being* the instance
> token; the iommu_fwspec stuff is deliberately intended to provide
> per-device ops on top of that. The raw functionality is either there in
> iommu.c already, or moving there in patches already written, so if it
> doesn't look right all we need to focus on is making it look right.
>
> > Also the rest of iommu-core code still makes use of the per-bus ops. The
> > per-device ops are only used for the of_xlate fn-ptr.
>
> Hence my aforementioned patches intended for 4.10, directly following on
> from introducing iommu_fwspec in 4.9:
>
> http://www.mail-archive.com/iommu at lists.linux-foundation.org/msg14576.html
>
> ...the purpose being to provide a smooth transition from per-bus ops to
> per-device, per-instance ops. Apply those and we're 90% of the way there
> for OF-based IOMMU drivers (not that any of those actually need
> per-instance ops, admittedly; I did prototype it for the ARM SMMU ages
> ago, but it didn't seem worth the bother). Lorenzo's series broadens the
> scope to ACPI-based systems and moves the generically-useful parts into
> the core where we can easily build on them further if necessary. The
> major remaining work is to convert external callers of the current
> bus-dependent functions like iommu_domain_alloc(), iommu_present(), etc.
> to device-based alternatives.
>
> Robin.
^ permalink raw reply
* [PATCH 1/2] ARM: dts: da850: add the mstpri and ddrctl nodes
From: Sekhar Nori @ 2016-11-15 10:05 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1479144724-14231-2-git-send-email-bgolaszewski@baylibre.com>
On Monday 14 November 2016 11:02 PM, Bartosz Golaszewski wrote:
> Add the nodes for the MSTPRI configuration and DDR2/mDDR memory
> controller drivers to da850.dtsi.
>
> Signed-off-by: Bartosz Golaszewski <bgolaszewski@baylibre.com>
> ---
> arch/arm/boot/dts/da850.dtsi | 9 +++++++++
> 1 file changed, 9 insertions(+)
>
> diff --git a/arch/arm/boot/dts/da850.dtsi b/arch/arm/boot/dts/da850.dtsi
> index 1bb1f6d..1635218 100644
> --- a/arch/arm/boot/dts/da850.dtsi
> +++ b/arch/arm/boot/dts/da850.dtsi
> @@ -440,6 +440,11 @@
> interrupts = <52>;
> status = "disabled";
> };
> +
> + mstpri: mstpri at 14110 {
> + compatible = "ti,da850-mstpri";
> + reg = <0x14110 0x0c>;
> + };
Instead of adding the node to the end, can you place it above the
cfgchip node to keep it sorted by reg. We have not really followed that
in this file. May be we should have. But lets start with this.
> };
> aemif: aemif at 68000000 {
> compatible = "ti,da850-aemif";
> @@ -451,4 +456,8 @@
> 1 0 0x68000000 0x00008000>;
> status = "disabled";
> };
> + ddrctl: ddrctl at b0000000 {
> + compatible = "ti,da850-ddr-controller";
> + reg = <0xb0000000 0xe8>;
> + };
Can you name the node memory-controller at b0000000? Thats the generic name
suggested by ePAPR 1.1 for memory controllers.
I could not find any naming suggestions for the bus master priority
controller above, but based on the pattern used for other controllers,
may be it should be called priority-controller at 14110 instead of mstpri at 14110
Thanks,
Sekhar
^ permalink raw reply
* [PATCH] ARM: dma-mapping: preallocate DMA-debug hash tables in pure_initcall
From: Marek Szyprowski @ 2016-11-15 10:04 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CGME20161115100459eucas1p152b644d5d329192a0902c836b13f35ba@eucas1p1.samsung.com>
fs_initcall is definitely too late to initialize DMA-debug hash tables,
because some drivers might get probed and use DMA mapping framework
already in core_initcall. Late initialization of DMA-debug results in
false warning about accessing memory, that was not allocated, like this
one:
------------[ cut here ]------------
WARNING: CPU: 5 PID: 1 at lib/dma-debug.c:1104 check_unmap+0xa1c/0xe50
exynos-sysmmu 10a60000.sysmmu: DMA-API: device driver tries to free DMA memory it has not allocated [device
address=0x000000006ebd0000] [size=16384 bytes]
Modules linked in:
CPU: 5 PID: 1 Comm: swapper/0 Not tainted 4.9.0-rc5-00028-g39dde3d-dirty #44
Hardware name: SAMSUNG EXYNOS (Flattened Device Tree)
[<c0119dd4>] (unwind_backtrace) from [<c01122bc>] (show_stack+0x20/0x24)
[<c01122bc>] (show_stack) from [<c062714c>] (dump_stack+0x84/0xa0)
[<c062714c>] (dump_stack) from [<c0132560>] (__warn+0x14c/0x180)
[<c0132560>] (__warn) from [<c01325dc>] (warn_slowpath_fmt+0x48/0x50)
[<c01325dc>] (warn_slowpath_fmt) from [<c06814f8>] (check_unmap+0xa1c/0xe50)
[<c06814f8>] (check_unmap) from [<c06819c4>] (debug_dma_unmap_page+0x98/0xc8)
[<c06819c4>] (debug_dma_unmap_page) from [<c076c3e8>] (exynos_iommu_domain_free+0x158/0x380)
[<c076c3e8>] (exynos_iommu_domain_free) from [<c0764a30>] (iommu_domain_free+0x34/0x60)
[<c0764a30>] (iommu_domain_free) from [<c011f168>] (release_iommu_mapping+0x30/0xb8)
[<c011f168>] (release_iommu_mapping) from [<c011f23c>] (arm_iommu_release_mapping+0x4c/0x50)
[<c011f23c>] (arm_iommu_release_mapping) from [<c0b061ac>] (s5p_mfc_probe+0x640/0x80c)
[<c0b061ac>] (s5p_mfc_probe) from [<c07e6750>] (platform_drv_probe+0x70/0x148)
[<c07e6750>] (platform_drv_probe) from [<c07e25c0>] (driver_probe_device+0x12c/0x6b0)
[<c07e25c0>] (driver_probe_device) from [<c07e2c6c>] (__driver_attach+0x128/0x17c)
[<c07e2c6c>] (__driver_attach) from [<c07df74c>] (bus_for_each_dev+0x88/0xc8)
[<c07df74c>] (bus_for_each_dev) from [<c07e1b6c>] (driver_attach+0x34/0x58)
[<c07e1b6c>] (driver_attach) from [<c07e1350>] (bus_add_driver+0x18c/0x32c)
[<c07e1350>] (bus_add_driver) from [<c07e4198>] (driver_register+0x98/0x148)
[<c07e4198>] (driver_register) from [<c07e5cb0>] (__platform_driver_register+0x58/0x74)
[<c07e5cb0>] (__platform_driver_register) from [<c174cb30>] (s5p_mfc_driver_init+0x1c/0x20)
[<c174cb30>] (s5p_mfc_driver_init) from [<c0102690>] (do_one_initcall+0x64/0x258)
[<c0102690>] (do_one_initcall) from [<c17014c0>] (kernel_init_freeable+0x3d0/0x4d0)
[<c17014c0>] (kernel_init_freeable) from [<c116eeb4>] (kernel_init+0x18/0x134)
[<c116eeb4>] (kernel_init) from [<c010bbd8>] (ret_from_fork+0x14/0x3c)
---[ end trace dc54c54bd3581296 ]---
This patch moves initialization of DMA-debug to pure_initcall.
Reported-by: Seung-Woo Kim <sw0312.kim@samsung.com>
Signed-off-by: Marek Szyprowski <m.szyprowski@samsung.com>
---
arch/arm/mm/dma-mapping.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/arm/mm/dma-mapping.c b/arch/arm/mm/dma-mapping.c
index ab4f745..d1abbcf 100644
--- a/arch/arm/mm/dma-mapping.c
+++ b/arch/arm/mm/dma-mapping.c
@@ -1167,7 +1167,7 @@ static int __init dma_debug_do_init(void)
dma_debug_init(PREALLOC_DMA_DEBUG_ENTRIES);
return 0;
}
-fs_initcall(dma_debug_do_init);
+pure_initcall(dma_debug_do_init);
#ifdef CONFIG_ARM_DMA_USE_IOMMU
--
1.9.1
^ permalink raw reply related
* PM regression with LED changes in next-20161109
From: Jacek Anaszewski @ 2016-11-15 10:01 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <15cafbf5-d842-e184-2fd4-65f8272f505a@redhat.com>
Hi,
On 11/14/2016 01:51 PM, Hans de Goede wrote:
> Hi,
>
> On 14-11-16 10:12, Jacek Anaszewski wrote:
>> Hi,
>>
>> On 11/13/2016 02:52 PM, Hans de Goede wrote:
>>> Hi,
>>>
>>> On 13-11-16 12:44, Jacek Anaszewski wrote:
>>>> Hi,
>>>>
>>>> On 11/12/2016 10:14 PM, Hans de Goede wrote:
>>>
>>> <snip>
>>>
>>>>>>> So I would like to propose creating a new read-write
>>>>>>> user_brightness file.
>>>>>>>
>>>>>>> The write behavior would be 100% identical to the brightness
>>>>>>> file (in code terms it will call the same store function).
>>>>>>>
>>>>>>> The the read behavior otoh will be different: it will shows
>>>>>>> the last brightness as set by the user, this would show the
>>>>>>> read behavior we really want of brightness: show the real
>>>>>>> brightness when not blinking / triggers are active and show
>>>>>>> the brightness used when on when blinking / triggers are active.
>>>>>>>
>>>>>>> We could then add poll support on this new user_brightness
>>>>>>> file, thus avoiding the problem with the extra cpu-load on
>>>>>>> notifications on blinking / triggers.
>>>>>>
>>>>>> I agree that user_brightness allows to solve the issues you raised
>>>>>> about inconsistent write and read brightness' semantics
>>>>>> (which is not that painful IMHO).
>>>>>>
>>>>>> Reporting non-user brightness changes on user_brightness file
>>>>>> doesn't sound reasonable though.
>>>>>
>>>>> The changes I'm interested in are user brightness changes they
>>>>> are just not done through sysfs, but through a hardwired hotkey,
>>>>> they are however very much done by the user.
>>>>
>>>> Ah, so this file name would be misleading especially taking into
>>>> account
>>>> the context in which "user" is used in kernel, which predominantly
>>>> means "userspace", e.g. copy_to_user(), copy_from_user().
>>>>
>>>>>> Also, how would we read the
>>>>>> brightness set by the firmware? We'd have to read brightness
>>>>>> file, so still two files would have to be opened which is
>>>>>> a second drawback of this approach.
>>>>>
>>>>> No, look carefully at the definition of the read behavior
>>>>> I plan to put in the ABI doc:
>>>>
>>>> OK, "user" was what confused me. So in this case changes made
>>>> by the firmware even if in a result of user activity
>>>> (pressing hardware key) obviously cannot be treated similarly
>>>> to the changes made from the userspace context.
>>>
>>> In the end both result on the brightness of the device
>>> changing, so any userspace process interested in monitoring
>>> the brightness will want to know about both type of changes.
>>>
>>>> Unless you're able to give references to the kernel code which
>>>> contradict my judgement.
>>>
>>> AFAIK the audio code will signal volume changes done by
>>> hardwired buttons the same way as audio changes done
>>> by userspace calling into the kernel. This also makes
>>> sense because in the end, what is interesting for a
>>> mixer app, is that the volume changed, and what the
>>> new volume is.
>>
>> OK, so it is indeed similar to your LED use case. Nonetheless
>> in case of LED controllers it is also possible that hardware
>> adjusts LED brightness in case of low battery voltage.
>>
>> If a device is able e.g. to generate an interrupt to notify this
>> kind of event, then we would like also to be able to notify the client
>> about that. It wouldn't be user generated brightness change though.
>>
>>>>> "Reading this file will return the actual led brightness
>>>>> when not blinking and no triggers are active; reading this
>>>>> file will return the brightness used when the led is on
>>>>> when blinking or triggers are active."
>>>>
>>>> This is unnecessarily entangled. Blinking means timer trigger
>>>> is active.
>>>
>>> Ok.
>>>
>>>>> So for e.g. the backlit keyboard case reading this single
>>>>> file will return the actual brightness of the backlight,
>>>>> since this does not involve blinking or triggers.
>>>>>
>>>>> Basically the idea is that the user_brightness file
>>>>> will have the semantics which IMHO the brightness file
>>>>> itself should have had from the beginning, but which
>>>>> we can't change now due to ABI reasons.
>>>>
>>>> And in fact introducing user_brightness file would indeed
>>>> fix that shortcoming. However without providing notifications
>>>> of hw brightness changes on it.
>>>
>>> See above, I believe such a file should report any
>>> changes in brightness, except those caused by triggers,
>>> so it would report hw brightness changes.
>>>
>>> Anyways if you're not interested in fixing the
>>> shortcomings of the current read behavior on the
>>> brightness file (I'm fine with that, I can live
>>> with the shortcomings) I suggest that we simply go
>>> with v2 of my poll() patch.
>>
>> v2 entails power consumption related issues.
>>
>> Generally I think that we could add the file you proposed,
>> however it would be good to devise a name which will cover
>> also the cases when brightness is changed by firmware without
>> user interaction.
>>
>>>>>> Having no difference in this area between the two approaches
>>>>>> I'm still in favour of the read-only file for notifying
>>>>>> brightness changes procured by hardware.
>>>>>
>>>>> That brings back the needing 2 fds problem; and does
>>>>> not solve userspace not being able to reliably read
>>>>> the led on brightness when blinking or using triggers.
>>>>>
>>>>> And this also has the issue that one is doing poll() on
>>>>> one fd to detect changes on another fd,
>>>>
>>>> It is not necessarily true. We can treat the polling on
>>>> hw_brightness_change file as a means to detect brightness
>>>> changes procured by hardware and we can read that brightness
>>>> by executing read on this same fd. It could return -ENODATA
>>>> if no such an event has occurred so far.
>>>
>>> That would still require 2 fds as userspace also wants to
>>> be able to set the keyboard backlight, but allowing read()
>>> on the hw_brightness_change file at least fixes the weirdness
>>> where userspace gets woken from poll() without being able to
>>> read. So if you insist on going the hw_brightness_change file
>>> route, then I can live with that (and upower will simply
>>> need to open 2 fds, that is doable).
>>>
>>> But, BUT, I would greatly prefer to just go for v4 of my
>>> patch, which fixes the only real problem we've seen with
>>> my patch as original merged without adding a new, somewhat
>>> convoluted sysfs attribute.
>>
>> Hmm, v4 still calls led_notify_brightness_change(led_cdev)
>> from both __led_set_brightness() and __led_set_brightness_blocking().
>
> Ugh, I see I accidentally send a v4 twice, instead of
> calling the version which dropped those called v5 as
> I should have, sorry.
>
> The v4 which I would like to see merged, the one with
> those calls dropped, is here:
>
> https://patchwork.kernel.org/patch/9423093/
Right I've had an impression that I've already seen something
different than "first" v4.
Regarding the patch - adding led_notify_brightness_change() to
brightness_store() can have similar power consumption related
implications if brightness is set frequently via sysfs. I'm leaning
towards adding a new brightness file similar to user_brightness
discussed in this thread.
It would cover shortcomings and read/write inconsistencies that
brightness file currently has, but without breaking existing users.
I'd not however go for "user_brightness" name due to the possible
brightness adjustments made autonomously by firmware. I'm afraid
that devising a meaningful name for the new file will be hard,
so the simplest would be just brighntess2. Dedicated section
in leds-class.txt should be devoted to it.
--
Best regards,
Jacek Anaszewski
^ permalink raw reply
* [PATCH v2] staging: vc04_services: rework ioctl code path
From: Greg KH @ 2016-11-15 9:55 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161111061531.23507-1-mzoran@crowfest.net>
On Thu, Nov 10, 2016 at 10:15:31PM -0800, Michael Zoran wrote:
> VCHIQ/vc04_services has a userland device interface
> that includes ioctls. The current ioctl implementation
> is a single monolithic function over 1,000+ lines
> that handles 17 different ioctls through a complex
> maze of switch and if statements.
>
> The change reimplements that code path by breaking
> up the code into smaller, easier to maintain functions
> and uses a dispatch table to invoke the correct function.
>
> Testing:
>
> 1. vchiq_test -f 10 and vchiq_test -p 1 were run from a native
> 64-bit OS(debian sid).
>
> 2. vchiq_test -f 10 and vchiq_test -p 1 where run from a 32-bit
> chroot install from the same OS.
>
> Both test cases pass.
>
> This is V2 of this patch. Changes include:
>
> 1. More code has been moved to the dispatch routine.
> The dispatch routine is now responsible for copying the top-level
> data into and out of kernel space by using the data encoded in
> the ioctl command number.
>
> 2. The number of parameters have been reduced for the handling
> functions by giving a different prototype to ioctls that pass
> no arguments.
>
> 3. Macros in linux/compat.h are now used for compatibility data
> structures.
>
> Signed-off-by: Michael Zoran <mzoran@crowfest.net>
> ---
> .../vc04_services/interface/vchiq_arm/vchiq_arm.c | 1733 +++++++++++++-------
> .../interface/vchiq_arm/vchiq_ioctl.h | 96 ++
> 2 files changed, 1200 insertions(+), 629 deletions(-)
This is a rough patch to review, can you break this up into a patch
series that moves each ioctl to a separate function as needed?
thanks,
greg k-h
^ permalink raw reply
* [RESEND PATCH v1 05/11] dt-bindings: perf: hisi: Add Devicetree bindings for Hisilicon SoC PMU
From: Mark Rutland @ 2016-11-15 9:51 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <58290014.2020401@gmail.com>
On Mon, Nov 14, 2016 at 05:36:44AM +0530, Anurup M wrote:
> On Friday 11 November 2016 12:00 AM, Mark Rutland wrote:
> >On Thu, Nov 03, 2016 at 01:42:01AM -0400, Anurup M wrote:
> >>+ - scl-id : The Super Cluster ID. This can be the ID of the CPU die
> >>+ or IO die in the chip.
> >What's this needed for?
> This is used as suffix to the PMU name. hisi_l3c<scl-id>. (hisi_l3c2
> - for scl-id = 2).
> This is to identify the pmu correspond to which CPU die in the socket.
> >>+ - num-events : No of events supported by this PMU device.
> >>+
> >>+ - num-counters : No of hardware counters available for counting.
> >This isn't probeable or well-known?
> My idea is to have the common properties of SoC PMU added here.
> The num-events, num-counters etc. So that handling can be made
> common in the driver.
> Is it not recommended? Please share your comments.
This feels like something that should be well-known for the programming
model of the device. If the number of events and/or counters shange, I'd
expect other things to also change such that the device is no longer
compatible with previous versions.
[...]
> The below two properties (module-id, cfgen-map) differs between
> chips hip05/06 and hip07.
The module-id property sounds like a HW description, but it's not
entirely clear to me what cfgen-map is; more comments on that below.
> Please suggest.
> >>+ - module-id : Module ID to input for djtag. This property is an array of
> >>+ module_id for each L3 cache banks.
> >>+
> >>+ - num-banks : Number of banks or instances of the device.
> >What's a bank? Surely they have separate instances of the PMU?
> Yes each bank is a separate instance of PMU.
> If it is recommended to have each L3 cache bank registered as
> separate PMU with perf, then this property will be removed.
Generally, I think that separate instances are preferable.
> >What order are these in?
> The bank number will start from "1" till "4" for L3 cache as there
> are four banks in hip05/06/07 chips.
> >>+ - cfgen-map : Config enable array to select the bank.
> >Huh?
As above, it's not clear to me what this property represents. Could you
please clarify?
Thanks,
Mark.
^ permalink raw reply
* [PATCH 2/2] ARM: davinci: PM: rework init: cleanup
From: Sekhar Nori @ 2016-11-15 9:39 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161114230441.356-3-khilman@baylibre.com>
On Tuesday 15 November 2016 04:34 AM, Kevin Hilman wrote:
> A follow-on cleanup renaming 'pdata' since it is no longer
> platform_data.
>
> Signed-off-by: Kevin Hilman <khilman@baylibre.com>
Looks good to me. Thanks for separating this out. Makes it much easier
to review.
In the subject line though, instead of just calling it cleanup, how
about a bit more descriptive statement like "remove references to pdata".
Thanks,
Sekhar
^ permalink raw reply
* [PATCH 1/2] ARM: davinci: PM: rework init, support DT platforms
From: Sekhar Nori @ 2016-11-15 9:36 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161114230441.356-2-khilman@baylibre.com>
Hi Kevin,
Looks good to me overall, I have some minor comments.
On Tuesday 15 November 2016 04:34 AM, Kevin Hilman wrote:
> Remove fake platform device used for PM init. Move pdata values which
> are common across all current platforms into pm.c.
>
> Also add PM support for DT platforms (vi da8xx-dt.c)
Can you please separate out PM enabling on DT platform to a separate
patch? Its a small change, but it will be nice to separate it from rest
of the cleanup.
> diff --git a/arch/arm/mach-davinci/include/mach/da8xx.h b/arch/arm/mach-davinci/include/mach/da8xx.h
> index f9f9713aacdd..3d7a13789661 100644
> --- a/arch/arm/mach-davinci/include/mach/da8xx.h
> +++ b/arch/arm/mach-davinci/include/mach/da8xx.h
> @@ -101,7 +101,6 @@ int da8xx_register_gpio(void *pdata);
> int da850_register_cpufreq(char *async_clk);
> int da8xx_register_cpuidle(void);
> void __iomem *da8xx_get_mem_ctlr(void);
> -int da850_register_pm(struct platform_device *pdev);
> int da850_register_sata(unsigned long refclkpn);
> int da850_register_vpif(void);
> int da850_register_vpif_display
> diff --git a/arch/arm/mach-davinci/pm.c b/arch/arm/mach-davinci/pm.c
> index 8929569b1f8a..fc6a5710b3fa 100644
> --- a/arch/arm/mach-davinci/pm.c
> +++ b/arch/arm/mach-davinci/pm.c
> @@ -23,13 +23,18 @@
> #include <mach/da8xx.h>
> #include "sram.h"
> #include <mach/pm.h>
> +#include <mach/mux.h>
Can you please add the mux.h inclusion above pm.h? Looks like the sram.h
inclusion is out of place already, but since you are touching this part,
can you please move it below along with rest of the local includes.
I see that linux/ includes are not sorted as well, but lets keep that
aside until someone needs to touch them.
> #include "clock.h"
> +#include "psc.h"
>
> +#define DA850_PLL1_BASE 0x01e1a000
> #define DEEPSLEEP_SLEEPCOUNT_MASK 0xFFFF
> +#define DEEPSLEEP_SLEEPCOUNT 128
>
> static void (*davinci_sram_suspend) (struct davinci_pm_config *);
> -static struct davinci_pm_config *pdata;
> +static struct davinci_pm_config pm_config;
> +static struct davinci_pm_config *pdata = &pm_config;
>
> static void davinci_sram_push(void *dest, void *src, unsigned int size)
> {
> @@ -117,17 +122,38 @@ static const struct platform_suspend_ops davinci_pm_ops = {
> .valid = suspend_valid_only_mem,
> };
>
> -static int __init davinci_pm_probe(struct platform_device *pdev)
> +int __init davinci_pm_init(void)
> {
> - pdata = pdev->dev.platform_data;
> - if (!pdata) {
> - dev_err(&pdev->dev, "cannot get platform data\n");
> - return -ENOENT;
> + int ret;
> +
> + ret = davinci_cfg_reg(DA850_RTC_ALARM);
> + if (ret)
> + return ret;
> +
> + pdata->sleepcount = DEEPSLEEP_SLEEPCOUNT;
> + pdata->ddr2_ctlr_base = da8xx_get_mem_ctlr();
> + pdata->deepsleep_reg = DA8XX_SYSCFG1_VIRT(DA8XX_DEEPSLEEP_REG);
> + pdata->ddrpsc_num = DA8XX_LPSC1_EMIF3C;
Some of these could be statically initialized in pm_config. Can you
please move the constants to static initialization.
Thanks,
Sekhar
^ permalink raw reply
* [PATCH v2] arm64: SMMU-v2: Workaround for Cavium ThunderX erratum 28168
From: Marc Zyngier @ 2016-11-15 9:26 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1479193220-6693-1-git-send-email-gakula@caviumnetworks.com>
On 15/11/16 07:00, Geetha sowjanya wrote:
> From: Tirumalesh Chalamarla <Tirumalesh.Chalamarla@cavium.com>
>
> This patch implements Cavium ThunderX erratum 28168.
>
> PCI requires stores complete in order. Due to erratum #28168
> PCI-inbound MSI-X store to the interrupt controller are delivered
> to the interrupt controller before older PCI-inbound memory stores
> are committed.
> Doing a sync on SMMU will make sure all prior data transfers are
> completed before invoking ISR.
>
> Signed-off-by: Tirumalesh Chalamarla <Tirumalesh.Chalamarla@cavium.com>
> Signed-off-by: Geetha sowjanya <gakula@caviumnetworks.com>
> ---
> arch/arm64/Kconfig | 11 +++++++++++
> arch/arm64/Kconfig.platforms | 1 +
> arch/arm64/include/asm/cpufeature.h | 3 ++-
> arch/arm64/kernel/cpu_errata.c | 16 ++++++++++++++++
> drivers/iommu/arm-smmu.c | 24 ++++++++++++++++++++++++
> drivers/irqchip/irq-gic-common.h | 1 +
> drivers/irqchip/irq-gic-v3.c | 19 +++++++++++++++++++
> 7 files changed, 74 insertions(+), 1 deletions(-)
>
> diff --git a/arch/arm64/Kconfig b/arch/arm64/Kconfig
> index 30398db..751972c 100644
> --- a/arch/arm64/Kconfig
> +++ b/arch/arm64/Kconfig
> @@ -474,6 +474,17 @@ config CAVIUM_ERRATUM_27456
>
> If unsure, say Y.
>
> +config CAVIUM_ERRATUM_28168
> + bool "Cavium erratum 28168: Make sure DMA data transfer is done before MSIX"
> + depends on ARCH_THUNDER && ARM64
> + default y
> + help
> + Due to erratum #28168 PCI-inbound MSI-X store to the interrupt
> + controller are delivered to the interrupt controller before older
> + PCI-inbound memory stores are committed. Doing a sync on SMMU
> + will make sure all prior data transfers are done before invoking ISR.
> +
> + If unsure, say Y.
Where is the entry in Documentation/arm64/silicon-errata.txt?
> endmenu
>
>
> diff --git a/arch/arm64/Kconfig.platforms b/arch/arm64/Kconfig.platforms
> index cfbdf02..2ac4ac6 100644
> --- a/arch/arm64/Kconfig.platforms
> +++ b/arch/arm64/Kconfig.platforms
> @@ -185,6 +185,7 @@ config ARCH_SPRD
>
> config ARCH_THUNDER
> bool "Cavium Inc. Thunder SoC Family"
> + select IRQ_PREFLOW_FASTEOI
> help
> This enables support for Cavium's Thunder Family of SoCs.
>
> diff --git a/arch/arm64/include/asm/cpufeature.h b/arch/arm64/include/asm/cpufeature.h
> index 758d74f..821fc3c 100644
> --- a/arch/arm64/include/asm/cpufeature.h
> +++ b/arch/arm64/include/asm/cpufeature.h
> @@ -40,8 +40,9 @@
> #define ARM64_HAS_32BIT_EL0 13
> #define ARM64_HYP_OFFSET_LOW 14
> #define ARM64_MISMATCHED_CACHE_LINE_SIZE 15
> +#define ARM64_WORKAROUND_CAVIUM_28168 16
>
> -#define ARM64_NCAPS 16
> +#define ARM64_NCAPS 17
>
> #ifndef __ASSEMBLY__
>
> diff --git a/arch/arm64/kernel/cpu_errata.c b/arch/arm64/kernel/cpu_errata.c
> index 0150394..0841a12 100644
> --- a/arch/arm64/kernel/cpu_errata.c
> +++ b/arch/arm64/kernel/cpu_errata.c
> @@ -122,6 +122,22 @@ static void cpu_enable_trap_ctr_access(void *__unused)
> MIDR_RANGE(MIDR_THUNDERX_81XX, 0x00, 0x00),
> },
> #endif
> +#ifdef CONFIG_CAVIUM_ERRATUM_28168
> + {
> + /* Cavium ThunderX, T88 pass 1.x - 2.1 */
> + .desc = "Cavium erratum 28168",
> + .capability = ARM64_WORKAROUND_CAVIUM_28168,
> + MIDR_RANGE(MIDR_THUNDERX, 0x00,
> + (1 << MIDR_VARIANT_SHIFT) | 1),
> + },
> + {
> + /* Cavium ThunderX, T81 pass 1.0 */
> + .desc = "Cavium erratum 28168",
> + .capability = ARM64_WORKAROUND_CAVIUM_28168,
> + MIDR_RANGE(MIDR_THUNDERX_81XX, 0x00, 0x00),
> + },
> +#endif
How is that a CPU bug? Shouldn't that be keyed on the SMMU version or
the ITs version?
> +
> {
> .desc = "Mismatched cache line size",
> .capability = ARM64_MISMATCHED_CACHE_LINE_SIZE,
> diff --git a/drivers/iommu/arm-smmu.c b/drivers/iommu/arm-smmu.c
> index c841eb7..1b4555c 100644
> --- a/drivers/iommu/arm-smmu.c
> +++ b/drivers/iommu/arm-smmu.c
> @@ -570,6 +570,30 @@ static void __arm_smmu_tlb_sync(struct arm_smmu_device *smmu)
> }
> }
>
> +/*
> + * Cavium ThunderX erratum 28168
> + *
> + * Due to erratum #28168 PCI-inbound MSI-X store to the interrupt
> + * controller are delivered to the interrupt controller before older
> + * PCI-inbound memory stores are committed. Doing a sync on SMMU
> + * will make sure all prior data transfers are completed before
> + * invoking ISR.
> + *
> + */
> +void cavium_arm_smmu_tlb_sync(struct device *dev)
> +{
> + struct iommu_fwspec *fwspec = dev->iommu_fwspec;
> + struct arm_smmu_device *smmu;
> +
> + smmu = fwspec_smmu(fwspec);
> + if (!smmu)
> + return;
> + __arm_smmu_tlb_sync(smmu);
> +
> +}
> +EXPORT_SYMBOL(cavium_arm_smmu_tlb_sync);
Why does this need to be exported? The only user can only be built-in.
> +
> +
> static void arm_smmu_tlb_sync(void *cookie)
> {
> struct arm_smmu_domain *smmu_domain = cookie;
> diff --git a/drivers/irqchip/irq-gic-common.h b/drivers/irqchip/irq-gic-common.h
> index 205e5fd..4e88f55 100644
> --- a/drivers/irqchip/irq-gic-common.h
> +++ b/drivers/irqchip/irq-gic-common.h
> @@ -38,4 +38,5 @@ void gic_enable_quirks(u32 iidr, const struct gic_quirk *quirks,
>
> void gic_set_kvm_info(const struct gic_kvm_info *info);
>
> +void cavium_arm_smmu_tlb_sync(struct device *dev);
Why should this be visible to GICv2 as well? I have the ugly feeling
this should stay private to the SMMU code and that a more standard
mechanism should be used... Robin, is there anything else we could
piggy-back on?
> #endif /* _IRQ_GIC_COMMON_H */
> diff --git a/drivers/irqchip/irq-gic-v3.c b/drivers/irqchip/irq-gic-v3.c
> index 19d642e..723cebe 100644
> --- a/drivers/irqchip/irq-gic-v3.c
> +++ b/drivers/irqchip/irq-gic-v3.c
> @@ -28,6 +28,8 @@
> #include <linux/of_irq.h>
> #include <linux/percpu.h>
> #include <linux/slab.h>
> +#include <linux/msi.h>
> +#include <linux/pci.h>
>
> #include <linux/irqchip.h>
> #include <linux/irqchip/arm-gic-common.h>
> @@ -736,6 +738,20 @@ static inline void gic_cpu_pm_init(void) { }
>
> #define GIC_ID_NR (1U << gic_data.rdists.id_bits)
>
> +/*
> + * Due to #28168 erratum in ThunderX,
> + * we need to make sure DMA data transfer is done before MSIX.
> + */
> +static void cavium_irq_perflow_handler(struct irq_data *data)
> +{
> + struct pci_dev *pdev;
> +
> + pdev = msi_desc_to_pci_dev(irq_data_get_msi_desc(data));
What happens if this is not a PCI device?
> + if ((pdev->vendor != 0x177d) &&
> + ((pdev->device & 0xA000) != 0xA000))
> + cavium_arm_smmu_tlb_sync(&pdev->dev);
I've asked that before. What makes Cavium devices so special that they
are not sensitive to this bug?
> +}
> +
> static int gic_irq_domain_map(struct irq_domain *d, unsigned int irq,
> irq_hw_number_t hw)
> {
> @@ -773,6 +789,9 @@ static int gic_irq_domain_map(struct irq_domain *d, unsigned int irq,
> return -EPERM;
> irq_domain_set_info(d, irq, hw, chip, d->host_data,
> handle_fasteoi_irq, NULL, NULL);
> + if (cpus_have_cap(ARM64_WORKAROUND_CAVIUM_28168))
> + __irq_set_preflow_handler(irq,
> + cavium_irq_perflow_handler);
What happens if SMMUv2 is not compiled in? Also, since this only affects
LPI signaling, why is this in the core GICv3 code and not in the ITS.
And more specifically, in the PCI part of the ITS, since you seem to
exclusively consider PCI?
> }
>
> return 0;
>
Thanks,
M.
--
Jazz is not dead. It just smells funny...
^ permalink raw reply
* [PATCH v3 3/3] pinctrl: sunxi: Make sunxi_pconf_group_set use sunxi_pconf_reg helper
From: Linus Walleij @ 2016-11-15 9:22 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161111095036.11803-4-wens@csie.org>
On Fri, Nov 11, 2016 at 10:50 AM, Chen-Yu Tsai <wens@csie.org> wrote:
> The sunxi_pconf_reg helper introduced in the last patch gives us the
> chance to rework sunxi_pconf_group_set to have it match the structure
> of sunxi_pconf_(group_)get and make it easier to understand.
>
> For each config to set, it:
>
> 1. checks if the parameter is supported.
> 2. checks if the argument is within limits.
> 3. converts argument to the register value.
> 4. writes to the register with spinlock held.
>
> As a result the function now blocks unsupported config parameters,
> instead of silently ignoring them.
>
> Signed-off-by: Chen-Yu Tsai <wens@csie.org>
> Acked-by: Maxime Ripard <maxime.ripard@free-electrons.com>
Patch applied.
Yours,
Linus Walleij
^ permalink raw reply
* [PATCH v3 2/3] pinctrl: sunxi: Add support for fetching pinconf settings from hardware
From: Linus Walleij @ 2016-11-15 9:21 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161111095036.11803-3-wens@csie.org>
On Fri, Nov 11, 2016 at 10:50 AM, Chen-Yu Tsai <wens@csie.org> wrote:
> The sunxi pinctrl driver only caches whatever pinconf setting was last
> set on a given pingroup. This is not particularly helpful, nor is it
> correct.
>
> Fix this by actually reading the hardware registers and returning
> the correct results or error codes. Also filter out unsupported
> pinconf settings. Since this driver has a peculiar setup of 1 pin
> per group, we can support both pin and pingroup pinconf setting
> read back with the same code. The sunxi_pconf_reg helper and code
> structure is inspired by pinctrl-msm.
>
> With this done we can also claim to support generic pinconf, by
> setting .is_generic = true in pinconf_ops.
>
> Also remove the cached config value. The behavior of this was never
> correct, as it only cached 1 setting instead of all of them. Since
> we can now read back settings directly from the hardware, it is no
> longer required.
>
> Signed-off-by: Chen-Yu Tsai <wens@csie.org>
Patch applied with Maxime's ACK.
Yours,
Linus Walleij
^ permalink raw reply
* [PATCH v3 1/3] pinctrl: sunxi: Fix PIN_CONFIG_BIAS_PULL_{DOWN, UP} argument
From: Linus Walleij @ 2016-11-15 9:19 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161111095036.11803-2-wens@csie.org>
On Fri, Nov 11, 2016 at 10:50 AM, Chen-Yu Tsai <wens@csie.org> wrote:
> According to pinconf-generic.h, the argument for
> PIN_CONFIG_BIAS_PULL_{DOWN,UP} is non-zero if the bias is enabled
> with a pull up/down resistor, zero if it is directly connected
> to VDD or ground.
>
> Since Allwinner hardware uses a weak pull resistor internally,
> the argument should be 1.
>
> Signed-off-by: Chen-Yu Tsai <wens@csie.org>
> Acked-by: Maxime Ripard <maxime.ripard@free-electrons.com>
Applied this v3 rather than the v2.
Yours,
Linus Walleij
^ permalink raw reply
* [PATCH v2 1/3] pinctrl: sunxi: Fix PIN_CONFIG_BIAS_PULL_{DOWN, UP} argument
From: Linus Walleij @ 2016-11-15 9:16 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161111024455.16883-2-wens@csie.org>
On Fri, Nov 11, 2016 at 3:44 AM, Chen-Yu Tsai <wens@csie.org> wrote:
> According to pinconf-generic.h, the argument for
> PIN_CONFIG_BIAS_PULL_{DOWN,UP} is non-zero if the bias is enabled
> with a pull up/down resistor, zero if it is directly connected
> to VDD or ground.
>
> Since Allwinner hardware uses a weak pull resistor internally,
> the argument should be 1.
>
> Signed-off-by: Chen-Yu Tsai <wens@csie.org>
Patch applied with Maxime's ACK.
Yours,
Linus Walleij
^ permalink raw reply
* [PATCH] pinctrl: sunxi: Free configs in pinctrl_map only if it is a config map
From: Linus Walleij @ 2016-11-15 9:15 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161111023510.14146-1-wens@csie.org>
On Fri, Nov 11, 2016 at 3:35 AM, Chen-Yu Tsai <wens@csie.org> wrote:
> In the recently refactored sunxi pinctrl library, we are only allocating
> one set of pin configs for each pinmux setting node. When the pinctrl_map
> structure is freed, the pin configs should also be freed. However the
> code assumed the first map would contain the configs, which actually
> never happens, as the mux function map gets added first.
>
> The proper way to do this is to look through all the maps and free the
> first one whose type is actually PIN_MAP_TYPE_CONFIGS_GROUP.
>
> Also slightly expand the comment explaining this.
>
> Fixes: f233dbca6227 ("pinctrl: sunxi: Rework the pin config building code")
> Signed-off-by: Chen-Yu Tsai <wens@csie.org>
Patch applied with Maxime's ACK.
Yours,
Linus Walleij
^ permalink raw reply
* [PATCH V1 2/2] PCI: thunder: Enable ACPI PCI controller for ThunderX pass1.x silicon version
From: Tomasz Nowicki @ 2016-11-15 9:14 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1479201298-25494-1-git-send-email-tn@semihalf.com>
ThunderX pass1.x requires to emulate the EA headers for on-chip devices
hence it has to use custom pci_thunder_ecam_ops for accessing PCI config
space (pci-thuner-ecam.c). Add new entries to MCFG quirk array where it
can be applied while probing ACPI based PCI host controller.
ThunderX pass1.x is using the same way for accessing off-chip devices
(so-called PEM) as silicon pass-2.x so we need to add PEM quirk
entries too.
Quirk is considered for ThunderX silicon pass1.x only which is identified
via MCFG revision 2.
Signed-off-by: Tomasz Nowicki <tn@semihalf.com>
---
drivers/acpi/pci_mcfg.c | 15 +++++++++++++++
drivers/pci/host/pci-thunder-ecam.c | 2 +-
include/linux/pci-ecam.h | 3 +++
3 files changed, 19 insertions(+), 1 deletion(-)
diff --git a/drivers/acpi/pci_mcfg.c b/drivers/acpi/pci_mcfg.c
index e4e2b9b..5e16211 100644
--- a/drivers/acpi/pci_mcfg.c
+++ b/drivers/acpi/pci_mcfg.c
@@ -76,6 +76,21 @@ static struct mcfg_fixup mcfg_quirks[] = {
/* SoC pass2.x */
THUNDER_MCFG_QUIRK(1, 0UL),
THUNDER_MCFG_QUIRK(1, 1UL),
+
+ /* SoC pass1.x */
+ THUNDER_MCFG_QUIRK(2, 0UL),
+ THUNDER_MCFG_QUIRK(2, 1UL),
+#endif
+#ifdef CONFIG_PCI_HOST_THUNDER_ECAM
+ /* SoC pass1.x */
+ { "CAVIUM", "THUNDERX", 2, 0, MCFG_BUS_ANY, &pci_thunder_ecam_ops },
+ { "CAVIUM", "THUNDERX", 2, 1, MCFG_BUS_ANY, &pci_thunder_ecam_ops },
+ { "CAVIUM", "THUNDERX", 2, 2, MCFG_BUS_ANY, &pci_thunder_ecam_ops },
+ { "CAVIUM", "THUNDERX", 2, 3, MCFG_BUS_ANY, &pci_thunder_ecam_ops },
+ { "CAVIUM", "THUNDERX", 2, 10, MCFG_BUS_ANY, &pci_thunder_ecam_ops },
+ { "CAVIUM", "THUNDERX", 2, 11, MCFG_BUS_ANY, &pci_thunder_ecam_ops },
+ { "CAVIUM", "THUNDERX", 2, 12, MCFG_BUS_ANY, &pci_thunder_ecam_ops },
+ { "CAVIUM", "THUNDERX", 2, 13, MCFG_BUS_ANY, &pci_thunder_ecam_ops },
#endif
};
diff --git a/drivers/pci/host/pci-thunder-ecam.c b/drivers/pci/host/pci-thunder-ecam.c
index d50a3dc..b6c17e2 100644
--- a/drivers/pci/host/pci-thunder-ecam.c
+++ b/drivers/pci/host/pci-thunder-ecam.c
@@ -346,7 +346,7 @@ static int thunder_ecam_config_write(struct pci_bus *bus, unsigned int devfn,
return pci_generic_config_write(bus, devfn, where, size, val);
}
-static struct pci_ecam_ops pci_thunder_ecam_ops = {
+struct pci_ecam_ops pci_thunder_ecam_ops = {
.bus_shift = 20,
.pci_ops = {
.map_bus = pci_ecam_map_bus,
diff --git a/include/linux/pci-ecam.h b/include/linux/pci-ecam.h
index 3f2a98f..5a1f291 100644
--- a/include/linux/pci-ecam.h
+++ b/include/linux/pci-ecam.h
@@ -62,6 +62,9 @@ extern struct pci_ecam_ops pci_generic_ecam_ops;
#ifdef CONFIG_PCI_HOST_THUNDER_PEM
extern struct pci_ecam_ops pci_thunder_pem_ops;
#endif
+#ifdef CONFIG_PCI_HOST_THUNDER_ECAM
+extern struct pci_ecam_ops pci_thunder_ecam_ops;
+#endif
/* ops for buggy ECAM that supports only 32-bit accesses */
extern struct pci_ecam_ops pci_32b_ops;
--
2.7.4
^ permalink raw reply related
* [PATCH V1 1/2] PCI: thunder: Enable ACPI PCI controller for ThunderX pass2.x silicon version
From: Tomasz Nowicki @ 2016-11-15 9:14 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1479201298-25494-1-git-send-email-tn@semihalf.com>
ThunderX PCIe controller to off-chip devices (so-called PEM) is not fully
compliant with ECAM standard. It uses non-standard configuration space
accessors (see pci_thunder_pem_ops) and custom configuration space granulation
(see bus_shift = 24). In order to access configuration space and
probe PEM as ACPI based PCI host controller we need to add MCFG quirk
infrastructure. This involves:
1. thunder_pem_init() ACPI extension so that we can probe PEM-specific
register ranges analogously to DT
2. Export PEM pci_thunder_pem_ops structure so it is visible to MCFG quirk
code.
3. New quirk entries for each PEM segment. Each contains platform IDs,
mentioned pci_thunder_pem_ops and CFG resources.
Quirk is considered for ThunderX silicon pass2.x only which is identified
via MCFG revision 1.
Signed-off-by: Tomasz Nowicki <tn@semihalf.com>
---
drivers/acpi/pci_mcfg.c | 20 +++++++
drivers/pci/host/pci-thunder-pem.c | 107 ++++++++++++++++++++++++++++++++-----
include/linux/pci-ecam.h | 4 ++
3 files changed, 117 insertions(+), 14 deletions(-)
diff --git a/drivers/acpi/pci_mcfg.c b/drivers/acpi/pci_mcfg.c
index ac21db3..e4e2b9b 100644
--- a/drivers/acpi/pci_mcfg.c
+++ b/drivers/acpi/pci_mcfg.c
@@ -57,6 +57,26 @@ static struct mcfg_fixup mcfg_quirks[] = {
{ "QCOM ", "QDF2432 ", 1, 5, MCFG_BUS_ANY, &pci_32b_ops },
{ "QCOM ", "QDF2432 ", 1, 6, MCFG_BUS_ANY, &pci_32b_ops },
{ "QCOM ", "QDF2432 ", 1, 7, MCFG_BUS_ANY, &pci_32b_ops },
+#ifdef CONFIG_PCI_HOST_THUNDER_PEM
+#define THUNDER_MCFG_RES(addr, node) \
+ DEFINE_RES_MEM(addr + (node << 44), 0x39 * SZ_16M)
+#define THUNDER_MCFG_QUIRK(rev, node) \
+ { "CAVIUM", "THUNDERX", rev, 4 + (10 * node), MCFG_BUS_ANY, \
+ &pci_thunder_pem_ops, THUNDER_MCFG_RES(0x88001f000000UL, node) }, \
+ { "CAVIUM", "THUNDERX", rev, 5 + (10 * node), MCFG_BUS_ANY, \
+ &pci_thunder_pem_ops, THUNDER_MCFG_RES(0x884057000000UL, node) }, \
+ { "CAVIUM", "THUNDERX", rev, 6 + (10 * node), MCFG_BUS_ANY, \
+ &pci_thunder_pem_ops, THUNDER_MCFG_RES(0x88808f000000UL, node) }, \
+ { "CAVIUM", "THUNDERX", rev, 7 + (10 * node), MCFG_BUS_ANY, \
+ &pci_thunder_pem_ops, THUNDER_MCFG_RES(0x89001f000000UL, node) }, \
+ { "CAVIUM", "THUNDERX", rev, 8 + (10 * node), MCFG_BUS_ANY, \
+ &pci_thunder_pem_ops, THUNDER_MCFG_RES(0x894057000000UL, node) }, \
+ { "CAVIUM", "THUNDERX", rev, 9 + (10 * node), MCFG_BUS_ANY, \
+ &pci_thunder_pem_ops, THUNDER_MCFG_RES(0x89808f000000UL, node) }
+ /* SoC pass2.x */
+ THUNDER_MCFG_QUIRK(1, 0UL),
+ THUNDER_MCFG_QUIRK(1, 1UL),
+#endif
};
static char mcfg_oem_id[ACPI_OEM_ID_SIZE];
diff --git a/drivers/pci/host/pci-thunder-pem.c b/drivers/pci/host/pci-thunder-pem.c
index 6abaf80..7bdc4cd 100644
--- a/drivers/pci/host/pci-thunder-pem.c
+++ b/drivers/pci/host/pci-thunder-pem.c
@@ -18,6 +18,7 @@
#include <linux/init.h>
#include <linux/of_address.h>
#include <linux/of_pci.h>
+#include <linux/pci-acpi.h>
#include <linux/pci-ecam.h>
#include <linux/platform_device.h>
@@ -284,6 +285,84 @@ static int thunder_pem_config_write(struct pci_bus *bus, unsigned int devfn,
return pci_generic_config_write(bus, devfn, where, size, val);
}
+#ifdef CONFIG_ACPI
+
+/*
+ * Retrieve PEM bridge register base and size from PNP0C02 sub-device under
+ * the RC.
+ *
+ * Device (RES0)
+ * {
+ * Name (_HID, "THRX0002")
+ * Name (_CID, "PNP0C02")
+ * Name (_CRS, ResourceTemplate () {
+ * // Device specific registers range
+ * QWordMemory(ResourceConsumer, PosDecode, MinFixed,
+ * MaxFixed, Cacheable, ReadWrite, 0,
+ * 0x87e0c2000000, 0x87E0C2FFFFFF, 0, 0x1000000)
+ * })
+ * }
+ */
+
+static const struct acpi_device_id thunder_pem_reg_ids[] = {
+ {"THRX0002", 0},
+ {"", 0},
+};
+
+static struct resource *thunder_pem_acpi_res(struct pci_config_window *cfg)
+{
+ struct device *dev = cfg->parent;
+ struct acpi_device *adev = to_acpi_device(dev);
+ struct acpi_device *child_adev;
+ struct resource *res_pem;
+
+ res_pem = devm_kzalloc(dev, sizeof(*res_pem), GFP_KERNEL);
+ if (!res_pem) {
+ dev_err(dev, "failed to allocate PEM resource\n");
+ return NULL;
+ }
+
+ list_for_each_entry(child_adev, &adev->children, node) {
+ struct resource_entry *entry;
+ struct list_head list;
+ unsigned long flags;
+ int ret;
+
+ ret = acpi_match_device_ids(child_adev, thunder_pem_reg_ids);
+ if (ret)
+ continue;
+
+ INIT_LIST_HEAD(&list);
+ flags = IORESOURCE_MEM;
+ ret = acpi_dev_get_resources(child_adev, &list,
+ acpi_dev_filter_resource_type_cb,
+ (void *)flags);
+ if (ret < 0) {
+ dev_err(&child_adev->dev,
+ "failed to parse _CRS method, error code %d\n",
+ ret);
+ return NULL;
+ } else if (ret == 0) {
+ dev_err(&child_adev->dev,
+ "no memory resources present in _CRS\n");
+ return NULL;
+ }
+
+ entry = list_first_entry(&list, struct resource_entry, node);
+ *res_pem = *entry->res;
+ acpi_dev_free_resource_list(&list);
+ return res_pem;
+ }
+
+ return NULL;
+}
+#else
+static struct resource *thunder_pem_acpi_res(struct pci_config_window *cfg)
+{
+ return NULL;
+}
+#endif
+
static int thunder_pem_init(struct pci_config_window *cfg)
{
struct device *dev = cfg->parent;
@@ -292,24 +371,24 @@ static int thunder_pem_init(struct pci_config_window *cfg)
struct thunder_pem_pci *pem_pci;
struct platform_device *pdev;
- /* Only OF support for now */
- if (!dev->of_node)
- return -EINVAL;
-
pem_pci = devm_kzalloc(dev, sizeof(*pem_pci), GFP_KERNEL);
if (!pem_pci)
return -ENOMEM;
- pdev = to_platform_device(dev);
-
- /*
- * The second register range is the PEM bridge to the PCIe
- * bus. It has a different config access method than those
- * devices behind the bridge.
- */
- res_pem = platform_get_resource(pdev, IORESOURCE_MEM, 1);
+ if (acpi_disabled) {
+ pdev = to_platform_device(dev);
+
+ /*
+ * The second register range is the PEM bridge to the PCIe
+ * bus. It has a different config access method than those
+ * devices behind the bridge.
+ */
+ res_pem = platform_get_resource(pdev, IORESOURCE_MEM, 1);
+ } else {
+ res_pem = thunder_pem_acpi_res(cfg);
+ }
if (!res_pem) {
- dev_err(dev, "missing \"reg[1]\"property\n");
+ dev_err(dev, "missing configuration region\n");
return -EINVAL;
}
@@ -332,7 +411,7 @@ static int thunder_pem_init(struct pci_config_window *cfg)
return 0;
}
-static struct pci_ecam_ops pci_thunder_pem_ops = {
+struct pci_ecam_ops pci_thunder_pem_ops = {
.bus_shift = 24,
.init = thunder_pem_init,
.pci_ops = {
diff --git a/include/linux/pci-ecam.h b/include/linux/pci-ecam.h
index f5740b7..3f2a98f 100644
--- a/include/linux/pci-ecam.h
+++ b/include/linux/pci-ecam.h
@@ -58,6 +58,10 @@ void __iomem *pci_ecam_map_bus(struct pci_bus *bus, unsigned int devfn,
int where);
/* default ECAM ops */
extern struct pci_ecam_ops pci_generic_ecam_ops;
+/* ECAM ops for known quirks */
+#ifdef CONFIG_PCI_HOST_THUNDER_PEM
+extern struct pci_ecam_ops pci_thunder_pem_ops;
+#endif
/* ops for buggy ECAM that supports only 32-bit accesses */
extern struct pci_ecam_ops pci_32b_ops;
--
2.7.4
^ permalink raw reply related
* [PATCH V1 0/2] Add support for ThunderX SoCs ACPI Host Controllers
From: Tomasz Nowicki @ 2016-11-15 9:14 UTC (permalink / raw)
To: linux-arm-kernel
These patches were part of https://lkml.org/lkml/2016/9/9/666 series,
however, only core part (first two patches) was approved. ThunderX quirk
example had some comments which are address in this series (resetting version
numbering).
Add ACPI PCI host controler support for ThunderX SoCs pass1.x & pass2.x using
ACPI quirk mechanism [1]. Patches rework ThunderX ECAM and PEM driver to work
with ACPI & DT boot method.
Patch set can be found here:
git at github.com:semihalf-nowicki-tomasz/linux.git (pci-quirks-thunderx-v1)
It is based on branch pci/ecam-v6 which can be found here:
[1] https://git.kernel.org/pub/scm/linux/kernel/git/helgaas/pci.git (pci/ecam-v6)
Tomasz Nowicki (2):
PCI: thunder: Enable ACPI PCI controller for ThunderX pass2.x silicon
version
PCI: thunder: Enable ACPI PCI controller for ThunderX pass1.x silicon
version
drivers/acpi/pci_mcfg.c | 35 ++++++++++++
drivers/pci/host/pci-thunder-ecam.c | 2 +-
drivers/pci/host/pci-thunder-pem.c | 107 +++++++++++++++++++++++++++++++-----
include/linux/pci-ecam.h | 7 +++
4 files changed, 136 insertions(+), 15 deletions(-)
--
2.7.4
^ permalink raw reply
* [PATCH v3 0/3] modversions: Fix CRC mangling under CONFIG_RELOCATABLE=y
From: Ard Biesheuvel @ 2016-11-15 9:13 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <87eg2kj757.fsf@concordia.ellerman.id.au>
On 10 November 2016 at 05:22, Michael Ellerman <mpe@ellerman.id.au> wrote:
> Ard Biesheuvel <ard.biesheuvel@linaro.org> writes:
>
>> On 27 October 2016 at 17:27, Ard Biesheuvel <ard.biesheuvel@linaro.org> wrote:
>>> This series is a followup to the single patch 'modversions: treat symbol
>>> CRCs as 32 bit quantities on 64 bit archs', of which two versions have
>>> been sent out so far [0][1]
>>>
>>> As pointed out by Michael, GNU ld behaves a bit differently between arm64
>>> and PowerPC64, and where the former gets rid of all runtime relocations
>>> related to CRCs, the latter is not as easily convinced.
>>>
>>> Patch #1 fixes the issue where CRCs are corrupted by the runtime relocation
>>> routines for 32-bit PowerPC, for which the original fix was effectively
>>> reverted by commit 0e0ed6406e61 ("powerpc/modules: Module CRC relocation fix
>>> causes perf issues")
>>>
>>> Patch #2 adds handling of R_PPC64_ADDR32 relocations against the NULL .dynsym
>>> symbol entry to the PPC64 runtime relocation routines, so it is prepared to
>>> deal with CRCs being emitted as 32-bit quantities.
>>>
>>> Patch #3 is the original patch from the v1 and v2 submissions.
>>>
>>> Changes since v2:
>>> - added #1 and #2
>>> - updated #3 to deal with CRC entries being emitted from assembler
>>> - added Rusty's ack (#3)
>>>
>>> Branch can be found here:
>>> https://git.kernel.org/cgit/linux/kernel/git/ardb/linux.git/log/?h=kcrctab-reloc
>>>
>>> [0] http://marc.info/?l=linux-kernel&m=147652300207369&w=2
>>> [1] http://marc.info/?l=linux-kernel&m=147695629614409&w=2
>>
>> Ping?
>
> Sorry, you didn't cc linuxppc-dev, so it's not in my patchwork list
> which tends to mean I miss it.
>
Ah, my mistake. Apologies.
> Will try and test and get back to you.
>
Thanks!
^ permalink raw reply
* [GIT PULL 5/5] i.MX defconfig updates for 4.10
From: Shawn Guo @ 2016-11-15 9:00 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1479200431-1765-1-git-send-email-shawnguo@kernel.org>
The following changes since commit 1001354ca34179f3db924eb66672442a173147dc:
Linux 4.9-rc1 (2016-10-15 12:17:50 -0700)
are available in the git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/shawnguo/linux.git tags/imx-defconfig-4.10
for you to fetch changes up to 3252e255371ad22c02d5c9d1740d408ce1b10f35:
ARM: imx_v6_v7_defconfig: Select the es8328 codec driver (2016-10-24 19:54:38 +0800)
----------------------------------------------------------------
i.MX defconfig updates for 4.10:
- Increase CMA size to 64 MiB, so that we can use etnaviv driver with
1920x1080 display devices.
- Enable ES8328 codec driver support, which is required by Kosagi
Novena boards.
----------------------------------------------------------------
Marek Vasut (2):
ARM: imx_v6_v7_defconfig: Increase CMA size
ARM: imx_v6_v7_defconfig: Select the es8328 codec driver
arch/arm/configs/imx_v6_v7_defconfig | 2 ++
1 file changed, 2 insertions(+)
^ permalink raw reply
* [GIT PULL 4/5] Freescale arm64 device tree updates for 4.10
From: Shawn Guo @ 2016-11-15 9:00 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1479200431-1765-1-git-send-email-shawnguo@kernel.org>
The following changes since commit 1001354ca34179f3db924eb66672442a173147dc:
Linux 4.9-rc1 (2016-10-15 12:17:50 -0700)
are available in the git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/shawnguo/linux.git tags/imx-dt64-4.10
for you to fetch changes up to 236f794e4463a6b53139702c1b609091f61a17ab:
arm64: dts: ls2080a: Add TMU device tree support for LS2080A (2016-11-15 15:05:36 +0800)
----------------------------------------------------------------
Freescale arm64 device tree updates for 4.10:
- Enable Thermal Monitoring Unit (TMU) for thermal management on
LS1043A and LS2080A.
- Add support for LS1046A SoC, which has similar peripherals as
LS1043A but integrates 4 A72 cores.
- Add two LS1046A based board support: LS1046A-QDS and LS1046A-RDB.
----------------------------------------------------------------
Hongtao Jia (2):
arm64: dts: ls1043a: Add TMU device tree support for LS1043A
arm64: dts: ls2080a: Add TMU device tree support for LS2080A
Mingkai Hu (2):
arm64: dts: add QorIQ LS1046A SoC support
arm64: dts: add LS1046A-RDB board support
Shaohui Xie (8):
dt-bindings: fsl: Add LS1043A/LS1046A/LS2080A SoC compatible strings
dt-bindings: fsl: add LS1043A/LS1046A/LS2080A compatible for SCFG and DCFG
dt-bindings: i2c: adds two more nxp devices
dt-bindings: qoriq-clock: add LS1043A/LS1046A/LS2080A compatible for clockgen
dt-bindings: ahci-fsl-qoriq: updated for SoC ls1046a
Documentation: DT: Add entry for QorIQ LS1046A-RDB board
Documentation: DT: Add entry for QorIQ LS1046A-QDS board
arm64: dts: add LS1046A-QDS board support
Documentation/devicetree/bindings/arm/fsl.txt | 34 +-
.../devicetree/bindings/ata/ahci-fsl-qoriq.txt | 2 +-
.../devicetree/bindings/clock/qoriq-clock.txt | 3 +
.../devicetree/bindings/i2c/trivial-devices.txt | 2 +
arch/arm64/boot/dts/freescale/Makefile | 2 +
arch/arm64/boot/dts/freescale/fsl-ls1043a-qds.dts | 2 +-
arch/arm64/boot/dts/freescale/fsl-ls1043a-rdb.dts | 2 +-
arch/arm64/boot/dts/freescale/fsl-ls1043a.dtsi | 78 ++++
arch/arm64/boot/dts/freescale/fsl-ls1046a-qds.dts | 212 +++++++++
arch/arm64/boot/dts/freescale/fsl-ls1046a-rdb.dts | 150 ++++++
arch/arm64/boot/dts/freescale/fsl-ls1046a.dtsi | 515 +++++++++++++++++++++
arch/arm64/boot/dts/freescale/fsl-ls2080a-qds.dts | 2 +-
arch/arm64/boot/dts/freescale/fsl-ls2080a-rdb.dts | 2 +-
arch/arm64/boot/dts/freescale/fsl-ls2080a-simu.dts | 2 +-
arch/arm64/boot/dts/freescale/fsl-ls2080a.dtsi | 116 ++++-
15 files changed, 1107 insertions(+), 17 deletions(-)
create mode 100644 arch/arm64/boot/dts/freescale/fsl-ls1046a-qds.dts
create mode 100644 arch/arm64/boot/dts/freescale/fsl-ls1046a-rdb.dts
create mode 100644 arch/arm64/boot/dts/freescale/fsl-ls1046a.dtsi
^ permalink raw reply
* [GIT PULL 3/5] i.MX device tree updates for 4.10
From: Shawn Guo @ 2016-11-15 9:00 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1479200431-1765-1-git-send-email-shawnguo@kernel.org>
The following changes since commit 1001354ca34179f3db924eb66672442a173147dc:
Linux 4.9-rc1 (2016-10-15 12:17:50 -0700)
are available in the git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/shawnguo/linux.git tags/imx-dt-4.10
for you to fetch changes up to c201369d4aa5f05b8a37d6d1eeabf248c7086454:
ARM: dts: imx6ull: add imx6ull support (2016-11-15 08:54:27 +0800)
----------------------------------------------------------------
i.MX device tree updates for 4.10:
- New boards support: i.MX6SX UDOO Neo, Boundary Devices Nitrogen6_SOM2,
Engicam i.CoreM6, Grinn i.MX6UL liteSOM/liteBoard, Toradex Colibri
iMX6 module, i.MX6ULL and EVK board.
- Remove skeleton.dtsi inclusion from all i.MX SoC dts files, as it's
been deprecated, since commit 9c0da3cc61f1233c ("ARM: dts: explicitly
mark skeleton.dtsi as deprecated").
- Misc device addition and enabling: OCOTP for Vybrid, MMDC for i.MX6QP,
TMU for LS1021A, FEC for imx6qdl-icore, DMA for Vybrid DSPI.
- A few cleanups: use hyphens for node names, fix white spaces, move
imx-weim parameters into SoC dtsi, replace gpio-key,wakeup with
wakeup-source, remove pwm-leds from imx6q-apalis-ixora, remove I2C3
from vf610-zii-dev-rev-b.
- Other small random changes: calibrate USB PHY for b650v3 board,
update TX D_CAL for USBPHY, use enable-gpios for backlight on
imx6qdl-apalis, etc.
----------------------------------------------------------------
Andreas F?rber (1):
ARM: dts: imx6sx: Add UDOO Neo support
Andrey Smirnov (2):
ARM: dts: vf610-zii-dev-rev-b: Remove I2C3
ARM: dts: vfxxx: Add node corresponding to OCOTP
Christopher Spinrath (1):
ARM: dts: imx6q-utilite-pro: i2c1 is muxed
Fabio Estevam (2):
ARM: dts: imx6sx-udoo: Add board specific compatible strings
ARM: dts: imx: Remove skeleton.dtsi
Frank Li (1):
ARM: dts: add new compatible string for i.MX6QP mmdc
Gary Bisson (5):
ARM: dts: imx: add Boundary Devices Nitrogen6_SOM2 support
ARM: dts: imx6qdl-sabrelite: use hyphens for nodes name
ARM: dts: imx6qdl-nitrogen6x: use hyphens for nodes name
ARM: dts: imx6qdl-nit6xlite: use hyphens for nodes name
ARM: dts: imx6qdl-nitrogen6_max: use hyphens for nodes name
Hongtao Jia (1):
ARM: dts: ls1021a: Add TMU device tree support for LS1021A
Jagan Teki (7):
ARM: dts: imx6qdl: Fix "WARNING: please, no space before tabs"
ARM: dts: imx6qdl: Fix "ERROR: code indent should use tabs where possible"
ARM: dts: imx6qdl-wandboard-revb: Fix "ERROR: trailing whitespace"
ARM: dts: imx6q: Add Engicam i.CoreM6 Quad/Dual initial support
ARM: dts: imx6q: Add Engicam i.CoreM6 DualLite/Solo initial support
ARM: dts: imx6qdl-icore: Add FEC support
ARM: dts: imx: Fix "ERROR: code indent should use tabs where possible"
Jaret Cantu (1):
ARM: dts: imx: b650v3: Calibrate USB PHY to pass eye diagram test
Joshua Clayton (1):
ARM: dts: imx6: Add imx-weim parameters to dtsi's
Marcin Niestroj (2):
ARM: dts: imx6ul: Add DTS for liteSOM module
ARM: dts: imx6ul: Add DTS for liteBoard
Marek Vasut (4):
ARM: dts: imx6sx: Fix LCDIF interrupt type
ARM: dts: novena: Enable PWM1
ARM: dts: mxs: Add new M28EVK manufacturer compat
ARM: dts: mx5: Add new M53EVK manufacturer compat
Peter Chen (4):
ARM: dts: imx6ul-14x14-evk: add USB dual-role support
ARM: dts: imx6sx-sdb: update TX D_CAL for USBPHY
ARM: dts: imx6ul-14x14-evk: update TX D_CAL for USBPHY
ARM: dts: imx6ull: add imx6ull support
Sanchayan Maity (5):
ARM: dts: imx6: Add support for Toradex Colibri iMX6 module
ARM: dts: imx6q-apalis-ixora: Remove use of pwm-leds
ARM: dts: imx6qdl-apalis: Use enable-gpios property for backlight
ARM: dts: vfxxx: Enable DMA for DSPI on Vybrid
ARM: dts: vfxxx: Enable DMA for DSPI2 and DSPI3
Sudeep Holla (1):
ARM: dts: imx6q: replace gpio-key,wakeup with wakeup-source for Utilite Pro
arch/arm/boot/dts/Makefile | 13 +-
arch/arm/boot/dts/imx1.dtsi | 4 +-
arch/arm/boot/dts/imx23.dtsi | 6 +-
arch/arm/boot/dts/imx25.dtsi | 4 +-
arch/arm/boot/dts/imx27.dtsi | 4 +-
arch/arm/boot/dts/imx28-m28.dtsi | 4 +-
arch/arm/boot/dts/imx28-m28evk.dts | 4 +-
arch/arm/boot/dts/imx28.dtsi | 4 +-
arch/arm/boot/dts/imx31.dtsi | 5 +-
arch/arm/boot/dts/imx35.dtsi | 4 +-
arch/arm/boot/dts/imx50.dtsi | 48 +-
arch/arm/boot/dts/imx51.dtsi | 48 +-
arch/arm/boot/dts/imx53-m53.dtsi | 4 +-
arch/arm/boot/dts/imx53-m53evk.dts | 4 +-
arch/arm/boot/dts/imx53.dtsi | 72 +-
arch/arm/boot/dts/imx6dl-colibri-eval-v3.dts | 253 +++++++
arch/arm/boot/dts/imx6dl-icore.dts | 59 ++
arch/arm/boot/dts/imx6dl-riotboard.dts | 2 +-
arch/arm/boot/dts/imx6dl-tx6dl-comtft.dts | 2 +-
arch/arm/boot/dts/imx6dl-tx6u-801x.dts | 2 +-
arch/arm/boot/dts/imx6q-apalis-ixora.dts | 22 -
arch/arm/boot/dts/imx6q-b650v3.dts | 6 +
arch/arm/boot/dts/imx6q-evi.dts | 3 -
arch/arm/boot/dts/imx6q-icore.dts | 59 ++
arch/arm/boot/dts/imx6q-nitrogen6_som2.dts | 53 ++
arch/arm/boot/dts/imx6q-novena.dts | 4 +
arch/arm/boot/dts/imx6q-phytec-pbab01.dts | 2 +-
arch/arm/boot/dts/imx6q-tx6q-1010-comtft.dts | 2 +-
arch/arm/boot/dts/imx6q-tx6q-1010.dts | 2 +-
arch/arm/boot/dts/imx6q-tx6q-1020-comtft.dts | 2 +-
arch/arm/boot/dts/imx6q-tx6q-1020.dts | 2 +-
arch/arm/boot/dts/imx6q-utilite-pro.dts | 53 +-
arch/arm/boot/dts/imx6qdl-apalis.dtsi | 9 +
arch/arm/boot/dts/imx6qdl-apf6dev.dtsi | 14 +-
arch/arm/boot/dts/imx6qdl-colibri.dtsi | 890 +++++++++++++++++++++++++
arch/arm/boot/dts/imx6qdl-gw52xx.dtsi | 4 +-
arch/arm/boot/dts/imx6qdl-gw53xx.dtsi | 4 +-
arch/arm/boot/dts/imx6qdl-gw54xx.dtsi | 4 +-
arch/arm/boot/dts/imx6qdl-gw552x.dtsi | 2 +-
arch/arm/boot/dts/imx6qdl-icore.dtsi | 265 ++++++++
arch/arm/boot/dts/imx6qdl-nit6xlite.dtsi | 32 +-
arch/arm/boot/dts/imx6qdl-nitrogen6_max.dtsi | 18 +-
arch/arm/boot/dts/imx6qdl-nitrogen6_som2.dtsi | 770 +++++++++++++++++++++
arch/arm/boot/dts/imx6qdl-nitrogen6x.dtsi | 12 +-
arch/arm/boot/dts/imx6qdl-phytec-pfla02.dtsi | 6 +-
arch/arm/boot/dts/imx6qdl-sabreauto.dtsi | 4 +-
arch/arm/boot/dts/imx6qdl-sabrelite.dtsi | 10 +-
arch/arm/boot/dts/imx6qdl-sabresd.dtsi | 4 +-
arch/arm/boot/dts/imx6qdl-tx6.dtsi | 32 +-
arch/arm/boot/dts/imx6qdl-wandboard-revb1.dtsi | 2 +-
arch/arm/boot/dts/imx6qdl-wandboard.dtsi | 4 +-
arch/arm/boot/dts/imx6qdl.dtsi | 14 +-
arch/arm/boot/dts/imx6qp.dtsi | 7 +
arch/arm/boot/dts/imx6sl.dtsi | 7 +-
arch/arm/boot/dts/imx6sx-sdb.dtsi | 16 +-
arch/arm/boot/dts/imx6sx-udoo-neo-basic.dts | 69 ++
arch/arm/boot/dts/imx6sx-udoo-neo-extended.dts | 54 ++
arch/arm/boot/dts/imx6sx-udoo-neo-full.dts | 69 ++
arch/arm/boot/dts/imx6sx-udoo-neo.dtsi | 293 ++++++++
arch/arm/boot/dts/imx6sx.dtsi | 17 +-
arch/arm/boot/dts/imx6ul-14x14-evk.dts | 10 +-
arch/arm/boot/dts/imx6ul-liteboard.dts | 147 ++++
arch/arm/boot/dts/imx6ul-litesom.dtsi | 82 +++
arch/arm/boot/dts/imx6ul.dtsi | 4 +-
arch/arm/boot/dts/imx6ull-14x14-evk.dts | 52 ++
arch/arm/boot/dts/imx6ull-pinfunc.h | 56 ++
arch/arm/boot/dts/imx6ull.dtsi | 43 ++
arch/arm/boot/dts/imx7s.dtsi | 4 +-
arch/arm/boot/dts/ls1021a.dtsi | 84 ++-
arch/arm/boot/dts/vf-colibri.dtsi | 4 +
arch/arm/boot/dts/vf610-zii-dev-rev-b.dts | 14 -
arch/arm/boot/dts/vfxxx.dtsi | 18 +
72 files changed, 3638 insertions(+), 268 deletions(-)
create mode 100644 arch/arm/boot/dts/imx6dl-colibri-eval-v3.dts
create mode 100644 arch/arm/boot/dts/imx6dl-icore.dts
create mode 100644 arch/arm/boot/dts/imx6q-icore.dts
create mode 100644 arch/arm/boot/dts/imx6q-nitrogen6_som2.dts
create mode 100644 arch/arm/boot/dts/imx6qdl-colibri.dtsi
create mode 100644 arch/arm/boot/dts/imx6qdl-icore.dtsi
create mode 100644 arch/arm/boot/dts/imx6qdl-nitrogen6_som2.dtsi
create mode 100644 arch/arm/boot/dts/imx6sx-udoo-neo-basic.dts
create mode 100644 arch/arm/boot/dts/imx6sx-udoo-neo-extended.dts
create mode 100644 arch/arm/boot/dts/imx6sx-udoo-neo-full.dts
create mode 100644 arch/arm/boot/dts/imx6sx-udoo-neo.dtsi
create mode 100644 arch/arm/boot/dts/imx6ul-liteboard.dts
create mode 100644 arch/arm/boot/dts/imx6ul-litesom.dtsi
create mode 100644 arch/arm/boot/dts/imx6ull-14x14-evk.dts
create mode 100644 arch/arm/boot/dts/imx6ull-pinfunc.h
create mode 100644 arch/arm/boot/dts/imx6ull.dtsi
^ 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