* [PATCH v3 0/2] KVM: ARM: Enable vtimers with user space gic
From: Alexander Graf @ 2016-09-16 12:44 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <6b92c411-8b27-a4c0-6969-38e32bbf18ab@redhat.com>
> On 16 Sep 2016, at 14:40, Paolo Bonzini <pbonzini@redhat.com> wrote:
>
>
>
> On 16/09/2016 14:29, Christoffer Dall wrote:
>>> It may be useful for migrating a gicv2 VM to a gicv3 host without gicv2 emulation as well.
>>
>> I don't see why you'd do this; the VGIC hardware can perfectly well be
>> used for nesting as well, and this works rather well.
>
> Can GICv3 emulate GICv2 in a guest?
It depends on the gicv3 configuration. As an SOC vendor you can either enable gicv2 compatibility or disable it. ThunderX for example is gicv3 only. LS2085 can handle gicv2 in the guest with gicv3 on the host.
Alex
^ permalink raw reply
* [PATCH V6 0/3] Adding support for address filters
From: Adrian Hunter @ 2016-09-16 12:49 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1473957428-28311-1-git-send-email-mathieu.poirier@linaro.org>
On 15/09/16 19:37, Mathieu Poirier wrote:
> This patch set makes it possible to use the current filter
> framework with address filters. That way address filters for
> HW tracers such as CoreSight and IntelPT can be communicated
> to the kernel drivers.
FYI, I am working on patches to add support for entering address filters
using symbol names. I will probably send them next week.
>
> In this revision precursor work is done to make function
> perf_evsel__append_filter() generic, along with changes to
> current customers. From there the work on address filters is
> introduced.
>
> Thanks,
> Mathieu
>
> ---
> Changes for V6:
> - Split work in 3 (small) patches.
> - Adding tracepoint and address filter append() functions
>
> Changes for V5:
> - Modified perf_evsel__append_filter() to take a string format
> rather than an operation.
>
> Changes for V4:
> - Added support for address filters over more than one
> nibble.
> - Removed Jiri's ack, this version is too different from
> what was reviewed.
>
> Changes for V3:
> - Added Jiri's ack.
> - Rebased to v4.8-rc5.
>
> Changes for V2:
> - Rebased to v4.8-rc4.
> - Revisited error path.
>
> Mathieu Poirier (3):
> perf tools: making perf_evsel__append_filter() generic
> perf tools: new tracepoint specific function
> perf tools: adding support for address filters
>
> tools/perf/builtin-trace.c | 8 ++++++--
> tools/perf/util/evsel.c | 16 +++++++++++++---
> tools/perf/util/evsel.h | 5 +++--
> tools/perf/util/parse-events.c | 41 +++++++++++++++++++++++++++++++++++------
> 4 files changed, 57 insertions(+), 13 deletions(-)
>
^ permalink raw reply
* [PATCHv9 0/6] dmaengine: rcar-dmac: add iommu support for slave transfers
From: Robin Murphy @ 2016-09-16 12:49 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1757972.L4qX7sAfEW@avalon>
On 16/09/16 13:05, Laurent Pinchart wrote:
[...]
>>>> One concern I have is that we might get an awkward situation if we ever
>>>> encounter one DMA engine hardware that is used in different systems that
>>>> all have an IOMMU, but on some of them the connection between the DMA
>>>> master and the slave FIFO bypasses the IOMMU while on others the IOMMU
>>>> is required.
>>>
>>> Do you mean systems where some of the channels of a specific DMA engine go
>>> through the IOMMU while others do not ? We indeed have no solution today
>>> for such a situation.
>>>
>>> The problem is a bit broader than that, we'll also have an issue with DMA
>>> engines that have different channels served by different IOMMUs. I recall
>>> discussing this in the past with you, and the solution you proposed was to
>>> add a channel index to struct dma_attrs seems good to me. To support the
>>> case where some channels don't go through an IOMMU we would only need
>>> support for null entries in the IOMMUs list associated with a device (for
>>> instance in the DT case null entries in the iommus property).
>>
>> I think at that point we just create the channels as child devices of
>> the main dmaengine device so they each get their own DMA ops, and can do
>> whatever. The Qualcomm HIDMA driver already does that for a very similar
>> reason (so that the IOMMU can map individual channels into different
>> guest VMs).
>
> That's another option, but it seems more like a workaround to me, instead of a
> proper solution to fix the more global problem of multiple memory paths within
> a single device. I have other hardware devices that can act as bus masters
> through different paths (for instance a display-related device that fetches
> data and commands through different paths). Luckily so far all those paths are
> served by the same IOMMU, but there's no guarantee this will remain true in
> the future. Furthermore, even today, the IOMMU connected to that device has
> the ability to selectively enable and disable its ports. I have to keep them
> all enabled due to the lack of channel information in the DMA mapping and
> IOMMU APIs, leading to increased power consumption.
Indeed, I think both the Exynos and Rockchip IOMMU drivers already do
cater for a device mastering though multiple discrete IOMMUs, not being
the fancy multi-port multi-context ones like yours and mine.
I guess what we could really do with is a decent abstraction of
multi-master peripherals at the device level; a "threads within the same
process" sort of granularity, as it were. I'd envisage it more along the
lines of how we handle NUMA, i.e. dma_map_page_attrs(...) becomes a
wrapper for dma_map_page_attrs_multi(..., CHANNEL_ALL), and trickier
users can call the latter with the a more specific channel(s) argument
(maybe it's a bitmask rather than an index). Meanwhile,
dev->archdata.dma_ops may point to a device-specific array of
dma_map_ops, which the DMA API backend iterates over if necessary.
Strangely, that doesn't actually sound too horrible.
Robin.
>
>>> Now I see that struct dma_attrs has been replaced by unsigned long in
>>>
>>> commit 00085f1efa387a8ce100e3734920f7639c80caa3
>>> Author: Krzysztof Kozlowski <k.kozlowski@samsung.com>
>>> Date: Wed Aug 3 13:46:00 2016 -0700
>>>
>>> dma-mapping: use unsigned long for dma_attrs
>>>
>>> We still have enough bits to reserve some of them for a channel number,
>>> but I'm not very happy with that patch as I can see how a future proposal
>>> to handle the channel number through the DMA attributes will get rejected
>>> on the grounds of bits starvation then :-(
>>>
>>>> I don't have any idea for how this could be handled in a generic way, so
>>>> my best answer here is to hope we never get there, and if we do, handle
>>>> it using some local hack in the driver.
>
^ permalink raw reply
* [PATCH v3 0/2] KVM: ARM: Enable vtimers with user space gic
From: Paolo Bonzini @ 2016-09-16 12:54 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <10C5B047-6A7F-4255-BE56-5358AF88DA5E@suse.de>
On 16/09/2016 14:44, Alexander Graf wrote:
>
>> On 16 Sep 2016, at 14:40, Paolo Bonzini <pbonzini@redhat.com>
>> wrote:
>>
>>
>>
>> On 16/09/2016 14:29, Christoffer Dall wrote:
>>>> It may be useful for migrating a gicv2 VM to a gicv3 host
>>>> without gicv2 emulation as well.
>>>
>>> I don't see why you'd do this; the VGIC hardware can perfectly
>>> well be used for nesting as well, and this works rather well.
>>
>> Can GICv3 emulate GICv2 in a guest?
>
> It depends on the gicv3 configuration. As an SOC vendor you can
> either enable gicv2 compatibility or disable it. ThunderX for example
> is gicv3 only.
And QEMU complains on startup and exits, I hope.
I am not too optimistic about having migration from kernel GIC to
userspace GIC, honestly. But GICv2 emulation on GICv3-only hosts is a
very reasonable thing to want, if only for testing/debugging purposes.
Paolo
^ permalink raw reply
* genirq: Setting trigger mode 0 for irq 11 failed (txx9_irq_set_type+0x0/0xb8)
From: Marc Zyngier @ 2016-09-16 12:55 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1474023805.17258.10.camel@gmail.com>
+Krzystof, Kukjin,
On 16/09/16 12:03, Alban Browaeys wrote:
> Le vendredi 16 septembre 2016 ? 08:51 +0100, Marc Zyngier a ?crit :
>> Hi Alban,
>>
>> On 16/09/16 00:02, Alban Browaeys wrote:
>>> I am seeing this on arm odroid u2 devicetree :
>>> genirq: Setting trigger mode 0 for irq 16 failed
>>> (gic_set_type+0x0/0x64)
>>
>> Passing IRQ_TYPE_NONE to a cascading interrupt is risky at best...
>> Can you point me to the various DTs and their failing interrupts?
>
> mine is:
> https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tree/arch/arm/boot/dts/exynos4412-odroidu3.dts
>
> I got a report of this issue to another odroid :
> https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tree/arch/arm/boot/dts/exynos4412-odroidx2.dts
>
>
>
> they both get their settings from :
> https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tree/arch/arm/boot/dts/exynos4412.dtsi
>
> relevant in the chain are:
> - combiner modified:
> https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tree/arch/arm/boot/dts/exynos4x12.dtsi#n460
How wonderful. This section is an utter pile of crap. Really.
Having 0 as the trigger is illegal, and the valid values are fully
documented in the GIC binding. No wonder things start breaking.
> - gic:
> https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tree/arch/arm/boot/dts/exynos4x12-pinctrl.dtsi#n576
> - gic and combiner initial settings:
> https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tree/arch/arm/boot/dts/exynos4.dtsi#n134
>
>
>
>> Also, can you please give the following patch a go and let me know
>> if that fixes the issue (I'm interested in the potential warning
>> here).
>
> 1st batch of warnings is :
>
> ------------[ cut here ]------------
> WARNING: CPU: 0 PID: 0 at kernel/irq/chip.c:833 __irq_do_set_handler+0x1c0/0x1c4
> Modules linked in:
> CPU: 0 PID: 0 Comm: swapper/0 Not tainted 4.8.0-rc6-debug+ #30
> Hardware name: ODROID-U2/U3
> [<c010fc74>] (unwind_backtrace) from [<c010c9a0>] (show_stack+0x10/0x14)
> [<c010c9a0>] (show_stack) from [<c035cafc>] (dump_stack+0xa8/0xd4)
> [<c035cafc>] (dump_stack) from [<c01214dc>] (__warn+0xe8/0x100)
> [<c01214dc>] (__warn) from [<c01215a4>] (warn_slowpath_null+0x20/0x28)
> [<c01215a4>] (warn_slowpath_null) from [<c017d394>] (__irq_do_set_handler+0x1c0/0x1c4)
> [<c017d394>] (__irq_do_set_handler) from [<c017d450>] (irq_set_chained_handler_and_data+0x38/0x54)
> [<c017d450>] (irq_set_chained_handler_and_data) from [<c0a15878>] (combiner_of_init+0x1a0/0x1c4)
> [<c0a15878>] (combiner_of_init) from [<c0a1ead4>] (of_irq_init+0x194/0x2e8)
> [<c0a1ead4>] (of_irq_init) from [<c0a07450>] (exynos_init_irq+0x8/0x3c)
> [<c0a07450>] (exynos_init_irq) from [<c0a0190c>] (init_IRQ+0x2c/0x88)
> [<c0a0190c>] (init_IRQ) from [<c0a00b78>] (start_kernel+0x284/0x388)
> [<c0a00b78>] (start_kernel) from [<40008078>] (0x40008078)
> ---[ end trace f68728a0d3053b52 ]---
That's our above friend the combiner.
>
> 2nd batch is :
>
> ------------[ cut here ]------------
> WARNING: CPU: 1 PID: 1 at kernel/irq/chip.c:833 __irq_do_set_handler+0x1c0/0x1c4
> Modules linked in:
> CPU: 1 PID: 1 Comm: swapper/0 Tainted: G W 4.8.0-rc6-debug+ #30
> Hardware name: ODROID-U2/U3
> [<c010fc74>] (unwind_backtrace) from [<c010c9a0>] (show_stack+0x10/0x14)
> [<c010c9a0>] (show_stack) from [<c035cafc>] (dump_stack+0xa8/0xd4)
> [<c035cafc>] (dump_stack) from [<c01214dc>] (__warn+0xe8/0x100)
> [<c01214dc>] (__warn) from [<c01215a4>] (warn_slowpath_null+0x20/0x28)
> [<c01215a4>] (warn_slowpath_null) from [<c017d394>] (__irq_do_set_handler+0x1c0/0x1c4)
> [<c017d394>] (__irq_do_set_handler) from [<c017d450>] (irq_set_chained_handler_and_data+0x38/0x54)
> [<c017d450>] (irq_set_chained_handler_and_data) from [<c038e340>] (exynos_eint_wkup_init+0x188/0x2dc)
> [<c038e340>] (exynos_eint_wkup_init) from [<c038d668>] (samsung_pinctrl_probe+0x874/0xa18)
> [<c038d668>] (samsung_pinctrl_probe) from [<c04342c8>] (platform_drv_probe+0x4c/0xb0)
> [<c04342c8>] (platform_drv_probe) from [<c043267c>] (driver_probe_device+0x24c/0x440)
> [<c043267c>] (driver_probe_device) from [<c0430658>] (bus_for_each_drv+0x64/0x98)
> [<c0430658>] (bus_for_each_drv) from [<c04322e8>] (__device_attach+0xb4/0x144)
> [<c04322e8>] (__device_attach) from [<c04316f4>] (bus_probe_device+0x88/0x90)
> [<c04316f4>] (bus_probe_device) from [<c042f850>] (device_add+0x428/0x5c8)
> [<c042f850>] (device_add) from [<c054c3f8>] (of_platform_device_create_pdata+0x84/0xb8)
> [<c054c3f8>] (of_platform_device_create_pdata) from [<c054c59c>] (of_platform_bus_create+0x164/0x440)
> [<c054c59c>] (of_platform_bus_create) from [<c054ca20>] (of_platform_populate+0x80/0x114)
> [<c054ca20>] (of_platform_populate) from [<c0a1d458>] (of_platform_default_populate_init+0x6c/0x80)
> [<c0a1d458>] (of_platform_default_populate_init) from [<c01018d4>] (do_one_initcall+0x50/0x198)
> [<c01018d4>] (do_one_initcall) from [<c0a00ecc>] (kernel_init_freeable+0x250/0x2f0)
> [<c0a00ecc>] (kernel_init_freeable) from [<c06c1064>] (kernel_init+0x8/0x114)
> [<c06c1064>] (kernel_init) from [<c0108710>] (ret_from_fork+0x14/0x24)
> ---[ end trace f68728a0d3053b66 ]---
And that's from the following stuff:
&pinctrl_0 {
compatible = "samsung,exynos4x12-pinctrl";
reg = <0x11400000 0x1000>;
interrupts = <0 47 0>;
};
&pinctrl_1 {
compatible = "samsung,exynos4x12-pinctrl";
reg = <0x11000000 0x1000>;
interrupts = <0 46 0>;
wakup_eint: wakeup-interrupt-controller {
compatible = "samsung,exynos4210-wakeup-eint";
interrupt-parent = <&gic>;
interrupts = <0 32 0>;
};
};
[...]
&pinctrl_3 {
compatible = "samsung,exynos4x12-pinctrl";
reg = <0x106E0000 0x1000>;
interrupts = <0 72 0>;
};
which perpetuates this fine tradition...
At that stage, I'm not sure I should care. Does the workaround make your
platform usable? The Samsung maintainers should really try and fix their
DT, because it is a miracle this has made it that far.
I'm also interested in hearing from Geert, whose platform doesn't seem
to be DT driven.
Thanks,
M.
--
Jazz is not dead. It just smells funny...
^ permalink raw reply
* [PATCHv9 0/6] dmaengine: rcar-dmac: add iommu support for slave transfers
From: Laurent Pinchart @ 2016-09-16 12:58 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <4397626.d3mSLX4nFk@wuerfel>
Hi Arnd,
On Friday 16 Sep 2016 14:22:31 Arnd Bergmann wrote:
> On Friday, September 16, 2016 3:09:29 PM CEST Laurent Pinchart wrote:
> >> I wasn't thinking quite that far, though that is also a theoretical
> >> problem. However, the simple solution would be to have a bit in the DMA
> >> specifier let the driver know whether translation is needed or not.
> >>
> >> The simpler case I was thinking of is where the entire DMA engine
> >> either goes through an IOMMU or doesn't (depending on the integration
> >> into the SoC), so we'd have to find out through some DT property
> >> or compatible string in the DMA enginen driver.
> >
> > Don't we already get that information from the iommus DT property ? If the
> > DMA engine goes through an IOMMU the property will be set, otherwise it
> > will not.
>
> It depends. A dmaengine typically at least has two DMA masters,
> possibly more. It's likely that some dmaengine implementations are
> connected to RAM through an IOMMU, but have direct access to an
> I/O bus for the slave FIFOs.
Sure, but I expect the DMA engine DT node to list all the relevant IOMMU(s)
(if any) in the iommus property in a way that allows the DMA engine driver to
know what IOMMU port is used for what purpose. It will then be up to the DMA
engine driver to select the right port identifier to pass to the DMA mapping
API.
I'm not sure how this would work with Robin's proposal of creating one device
per channel though, as there would still be a single node in DT for the DMA
engine device. Furthermore, a single channel might indeed have multiple DMA
masters, not all of them being served by an IOMMU. We would thus still need
memory port identifiers in the DMA mapping API.
> >>> The problem is a bit broader than that, we'll also have an issue with
> >>> DMA engines that have different channels served by different IOMMUs.
> >>
> >> Do you mean a theoretical problem, or a chip that you already know
> >> exists?
> >
> > That's theoretical. The problem I'm facing today is a DMA engine whose
> > channels are served by different ports of the same IOMMU. This works in a
> > suboptimal way because I have to keep all the IOMMU ports enabled
> > regardless of whether they're used or not, as the DMA engine and IOMMU
> > APIs don't carry channel information.
>
> Ok
--
Regards,
Laurent Pinchart
^ permalink raw reply
* [PATCH v2 1/3] ipmi: add an Aspeed BT IPMI BMC driver
From: Cédric Le Goater @ 2016-09-16 13:00 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20160916122949.GA23381@Red>
On 09/16/2016 02:29 PM, LABBE Corentin wrote:
> Hello
>
> I have some minor comment below:
>
> On Fri, Sep 16, 2016 at 12:39:25PM +0200, C?dric Le Goater wrote:
>> From: Alistair Popple <alistair@popple.id.au>
>>
>> This patch adds a simple device driver to expose the iBT interface on
>> Aspeed SOCs (AST2400 and AST2500) as a character device. Such SOCs are
>> commonly used as BMCs (BaseBoard Management Controllers) and this
>> driver implements the BMC side of the BT interface.
>>
>> The BT (Block Transfer) interface is used to perform in-band IPMI
>> communication between a host and its BMC. Entire messages are buffered
>> before sending a notification to the other end, host or BMC, that
>> there is data to be read. Usually, the host emits requests and the BMC
>> responses but the specification provides a mean for the BMC to send
>> SMS Attention (BMC-to-Host attention or System Management Software
>> attention) messages.
>>
>> For this purpose, the driver introduces a specific ioctl on the
>> device: 'BT_BMC_IOCTL_SMS_ATN' that can be used by the system running
>> on the BMC to signal the host of such an event.
>>
>> The device name defaults to '/dev/ipmi-bt-host'
>>
>> Signed-off-by: Alistair Popple <alistair@popple.id.au>
>> Signed-off-by: Jeremy Kerr <jk@ozlabs.org>
>> Signed-off-by: Joel Stanley <joel@jms.id.au>
>> [clg: - checkpatch fixes
>> - added a devicetree binding documentation
>> - replace 'bt_host' by 'bt_bmc' to reflect that the driver is
>> the BMC side of the IPMI BT interface
>> - renamed the device to 'ipmi-bt-host'
>> - introduced a temporary buffer to copy_{to,from}_user
>> - used platform_get_irq()
>> - moved the driver under drivers/char/ipmi/ but kept it as a misc
>> device
>> - changed the compatible cell to "aspeed,ast2400-bt-bmc"
>> ]
>> Signed-off-by: C?dric Le Goater <clg@kaod.org>
>> ---
>>
>> Changes since v1:
>>
>> - replace 'bt_host' by 'bt_bmc' to reflect that the driver is
>> the BMC side of the IPMI BT interface
>> - renamed the device to 'ipmi-bt-host'
>> - introduced a temporary buffer to copy_{to,from}_user
>> - used platform_get_irq()
>> - moved the driver under drivers/char/ipmi/ but kept it as a misc
>> device
>> - changed the compatible cell to "aspeed,ast2400-bt-bmc"
>>
>> .../bindings/char/ipmi/aspeed,ast2400-bt-bmc.txt | 23 +
>> drivers/Makefile | 2 +-
>> drivers/char/ipmi/Kconfig | 7 +
>> drivers/char/ipmi/Makefile | 1 +
>> drivers/char/ipmi/bt-bmc.c | 486 +++++++++++++++++++++
>> include/uapi/linux/Kbuild | 1 +
>> include/uapi/linux/bt-bmc.h | 18 +
>> 7 files changed, 537 insertions(+), 1 deletion(-)
>> create mode 100644 Documentation/devicetree/bindings/char/ipmi/aspeed,ast2400-bt-bmc.txt
>> create mode 100644 drivers/char/ipmi/bt-bmc.c
>> create mode 100644 include/uapi/linux/bt-bmc.h
>>
>> diff --git a/Documentation/devicetree/bindings/char/ipmi/aspeed,ast2400-bt-bmc.txt b/Documentation/devicetree/bindings/char/ipmi/aspeed,ast2400-bt-bmc.txt
>> new file mode 100644
>> index 000000000000..fbbacd958240
>> --- /dev/null
>
> [..]
>
>> +#include <linux/module.h>
>> +#include <linux/moduleparam.h>
>> +#include <linux/errno.h>
>> +#include <linux/poll.h>
>> +#include <linux/sched.h>
>> +#include <linux/spinlock.h>
>> +#include <linux/slab.h>
>> +#include <linux/init.h>
>> +#include <linux/device.h>
>> +#include <linux/of.h>
>> +#include <linux/of_irq.h>
>> +#include <linux/platform_device.h>
>> +#include <linux/io.h>
>> +#include <linux/interrupt.h>
>> +#include <linux/delay.h>
>> +#include <linux/miscdevice.h>
>> +#include <linux/timer.h>
>> +#include <linux/jiffies.h>
>> +#include <linux/bt-bmc.h>
>
> Please sort them in alphabetical order, some of them seems not needed also (like spinlock.h)
sure. I will clean them up.
>> +
>> +/*
>> + * This is a BMC device used to communicate to the host
>> + */
>> +#define DEVICE_NAME "ipmi-bt-host"
>> +
>> +#define BT_IO_BASE 0xe4
>> +#define BT_IRQ 10
>> +
>> +#define BT_CR0 0x0
>> +#define BT_CR0_IO_BASE 16
>> +#define BT_CR0_IRQ 12
>> +#define BT_CR0_EN_CLR_SLV_RDP 0x8
>> +#define BT_CR0_EN_CLR_SLV_WRP 0x4
>> +#define BT_CR0_ENABLE_IBT 0x1
>> +#define BT_CR1 0x4
>> +#define BT_CR1_IRQ_H2B 0x01
>> +#define BT_CR1_IRQ_HBUSY 0x40
>> +#define BT_CR2 0x8
>> +#define BT_CR2_IRQ_H2B 0x01
>> +#define BT_CR2_IRQ_HBUSY 0x40
>> +#define BT_CR3 0xc
>> +#define BT_CTRL 0x10
>> +#define BT_CTRL_B_BUSY 0x80
>> +#define BT_CTRL_H_BUSY 0x40
>> +#define BT_CTRL_OEM0 0x20
>> +#define BT_CTRL_SMS_ATN 0x10
>> +#define BT_CTRL_B2H_ATN 0x08
>> +#define BT_CTRL_H2B_ATN 0x04
>> +#define BT_CTRL_CLR_RD_PTR 0x02
>> +#define BT_CTRL_CLR_WR_PTR 0x01
>> +#define BT_BMC2HOST 0x14
>> +#define BT_INTMASK 0x18
>> +#define BT_INTMASK_B2H_IRQEN 0x01
>> +#define BT_INTMASK_B2H_IRQ 0x02
>> +#define BT_INTMASK_BMC_HWRST 0x80
>
> Why to use 3 space after some define ?
The difference in alignment is to distinguish the register number from
the bits signification. Is that OK ?
> [..]
>
>> +
>> +#define BT_BMC_BUFFER_SIZE 256
>
> Put this define with others
>
> [..]
ok
>> +
>> +static irqreturn_t bt_bmc_irq(int irq, void *arg)
>> +{
>> + struct bt_bmc *bt_bmc = arg;
>> + uint32_t reg;
>
> u32 is prefered other uint32_t, do you have run checkpatch --strict ?
no. I just did and I see it is catching quite a few new issues. I will
send a v3 with fixes.
>> +
>> + reg = ioread32(bt_bmc->base + BT_CR2);
>> + reg &= BT_CR2_IRQ_H2B | BT_CR2_IRQ_HBUSY;
>> + if (!reg)
>> + return IRQ_NONE;
>> +
>> + /* ack pending IRQs */
>> + iowrite32(reg, bt_bmc->base + BT_CR2);
>> +
>> + wake_up(&bt_bmc->queue);
>> + return IRQ_HANDLED;
>> +}
>> +
>> +static int bt_bmc_config_irq(struct bt_bmc *bt_bmc,
>> + struct platform_device *pdev)
>> +{
>> + struct device *dev = &pdev->dev;
>> + uint32_t reg;
>> + int rc;
>> +
>> + bt_bmc->irq = platform_get_irq(pdev, 0);
>> + if (!bt_bmc->irq)
>> + return -ENODEV;
>> +
>> + rc = devm_request_irq(dev, bt_bmc->irq, bt_bmc_irq, IRQF_SHARED,
>> + DEVICE_NAME, bt_bmc);
>> + if (rc < 0) {
>> + dev_warn(dev, "Unable to request IRQ %d\n", bt_bmc->irq);
>> + bt_bmc->irq = 0;
>> + return rc;
>> + }
>> +
>> + /* Configure IRQs on the bmc clearing the H2B and HBUSY bits;
>> + * H2B will be asserted when the bmc has data for us; HBUSY
>> + * will be cleared (along with B2H) when we can write the next
>> + * message to the BT buffer
>> + */
>
> This comment doesnt have the style recommended for new driver.
ah yes. I missed that one.
>> + reg = ioread32(bt_bmc->base + BT_CR1);
>> + reg |= BT_CR1_IRQ_H2B | BT_CR1_IRQ_HBUSY;
>> + iowrite32(reg, bt_bmc->base + BT_CR1);
>> +
>> + return 0;
>> +}
>> +
>> +static int bt_bmc_probe(struct platform_device *pdev)
>> +{
>> + struct bt_bmc *bt_bmc;
>> + struct device *dev;
>> + struct resource *res;
>> + int rc;
>> +
>> + if (!pdev || !pdev->dev.of_node)
>> + return -ENODEV;
>> +
>> + dev = &pdev->dev;
>> + dev_info(dev, "Found bt bmc device\n");
>> +
>> + bt_bmc = devm_kzalloc(dev, sizeof(*bt_bmc), GFP_KERNEL);
>> + if (!bt_bmc)
>> + return -ENOMEM;
>> +
>> + dev_set_drvdata(&pdev->dev, bt_bmc);
>> +
>> + res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
>> + if (!res) {
>> + dev_err(dev, "Unable to find resources\n");
>> + rc = -ENXIO;
>> + goto out_free;
>> + }
>> +
>> + bt_bmc->base = devm_ioremap_resource(&pdev->dev, res);
>> + if (!bt_bmc->base) {
>> + rc = -ENOMEM;
>> + goto out_free;
>> + }
>> +
>> + init_waitqueue_head(&bt_bmc->queue);
>> +
>> + bt_bmc->miscdev.minor = MISC_DYNAMIC_MINOR,
>> + bt_bmc->miscdev.name = DEVICE_NAME,
>> + bt_bmc->miscdev.fops = &bt_bmc_fops,
>> + bt_bmc->miscdev.parent = dev;
>> + rc = misc_register(&bt_bmc->miscdev);
>> + if (rc) {
>> + dev_err(dev, "Unable to register device\n");
>
> Be more precise by saying misc device
ok
>
>> + goto out_unmap;
>> + }
>> +
>> + bt_bmc_config_irq(bt_bmc, pdev);
>> +
>> + if (bt_bmc->irq) {
>> + dev_info(dev, "Using IRQ %d\n", bt_bmc->irq);
>> + } else {
>> + dev_info(dev, "No IRQ; using timer\n");
>> + setup_timer(&bt_bmc->poll_timer, poll_timer,
>> + (unsigned long)bt_bmc);
>> + bt_bmc->poll_timer.expires = jiffies + msecs_to_jiffies(10);
>> + add_timer(&bt_bmc->poll_timer);
>> + }
>> +
>> + iowrite32((BT_IO_BASE << BT_CR0_IO_BASE) |
>> + (BT_IRQ << BT_CR0_IRQ) |
>> + BT_CR0_EN_CLR_SLV_RDP |
>> + BT_CR0_EN_CLR_SLV_WRP |
>> + BT_CR0_ENABLE_IBT,
>> + bt_bmc->base + BT_CR0);
>> +
>> + clr_b_busy(bt_bmc);
>> +
>> + return 0;
>> +
>> +out_unmap:
>> + devm_iounmap(&pdev->dev, bt_bmc->base);
>
> Why do you use devm_iounmap/devm_kfree since the interest with devm_ functions
> is that all cleanup is done when driver is removed.
Indeed. So I can cleanup bt_bmc_remove() also.
>> +
>> +out_free:
>> + devm_kfree(dev, bt_bmc);
>> + return rc;
>
> I think you should remove the space after this return
Thanks,
C.
> Regards
>
> Corentin Labbe
>
^ permalink raw reply
* [PATCHv9 0/6] dmaengine: rcar-dmac: add iommu support for slave transfers
From: Laurent Pinchart @ 2016-09-16 13:01 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <cea119f1-18d5-675d-ee33-c22b0c8e7693@arm.com>
Hi Robin,
On Friday 16 Sep 2016 13:49:21 Robin Murphy wrote:
> On 16/09/16 13:05, Laurent Pinchart wrote:
> [...]
>
> >>>> One concern I have is that we might get an awkward situation if we ever
> >>>> encounter one DMA engine hardware that is used in different systems
> >>>> that all have an IOMMU, but on some of them the connection between the
> >>>> DMA master and the slave FIFO bypasses the IOMMU while on others the
> >>>> IOMMU is required.
> >>>
> >>> Do you mean systems where some of the channels of a specific DMA engine
> >>> go through the IOMMU while others do not ? We indeed have no solution
> >>> today for such a situation.
> >>>
> >>> The problem is a bit broader than that, we'll also have an issue with
> >>> DMA engines that have different channels served by different IOMMUs. I
> >>> recall discussing this in the past with you, and the solution you
> >>> proposed was to add a channel index to struct dma_attrs seems good to
> >>> me. To support the case where some channels don't go through an IOMMU we
> >>> would only need support for null entries in the IOMMUs list associated
> >>> with a device (for instance in the DT case null entries in the iommus
> >>> property).
> >>
> >> I think at that point we just create the channels as child devices of
> >> the main dmaengine device so they each get their own DMA ops, and can do
> >> whatever. The Qualcomm HIDMA driver already does that for a very similar
> >> reason (so that the IOMMU can map individual channels into different
> >> guest VMs).
> >
> > That's another option, but it seems more like a workaround to me, instead
> > of a proper solution to fix the more global problem of multiple memory
> > paths within a single device. I have other hardware devices that can act
> > as bus masters through different paths (for instance a display-related
> > device that fetches data and commands through different paths). Luckily
> > so far all those paths are served by the same IOMMU, but there's no
> > guarantee this will remain true in the future. Furthermore, even today,
> > the IOMMU connected to that device has the ability to selectively enable
> > and disable its ports. I have to keep them all enabled due to the lack of
> > channel information in the DMA mapping and IOMMU APIs, leading to
> > increased power consumption.
>
> Indeed, I think both the Exynos and Rockchip IOMMU drivers already do
> cater for a device mastering though multiple discrete IOMMUs, not being
> the fancy multi-port multi-context ones like yours and mine.
>
> I guess what we could really do with is a decent abstraction of
> multi-master peripherals at the device level; a "threads within the same
> process" sort of granularity, as it were. I'd envisage it more along the
> lines of how we handle NUMA, i.e. dma_map_page_attrs(...) becomes a
> wrapper for dma_map_page_attrs_multi(..., CHANNEL_ALL), and trickier
> users can call the latter with the a more specific channel(s) argument
> (maybe it's a bitmask rather than an index).
That's pretty much what I've discussed with Arnd in the past, except that we
were planning to add the channel to struct dma_attrs. Hence my disappointment
seeing the structure go away.
> Meanwhile, dev->archdata.dma_ops may point to a device-specific array of
> dma_map_ops, which the DMA API backend iterates over if necessary.
>
> Strangely, that doesn't actually sound too horrible.
--
Regards,
Laurent Pinchart
^ permalink raw reply
* [PATCH v26 7/7] Documentation: dt: chosen properties for arm64 kdump
From: Rob Herring @ 2016-09-16 13:03 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20160907043203.6309-1-takahiro.akashi@linaro.org>
On Wed, Sep 07, 2016 at 01:32:03PM +0900, AKASHI Takahiro wrote:
> From: James Morse <james.morse@arm.com>
>
> Add documentation for
> linux,crashkernel-base and crashkernel-size,
> linux,elfcorehdr
> used by arm64 kexec/kdump to decribe the kdump reserved area, and
> the elfcorehdr's location within it.
>
> Signed-off-by: James Morse <james.morse@arm.com>
> [takahiro.akashi at linaro.org: added "linux,crashkernel-base" and "-size" ]
> Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org>
> ---
> Documentation/devicetree/bindings/chosen.txt | 30 ++++++++++++++++++++++++++++
> 1 file changed, 30 insertions(+)
Acked-by: Rob Herring <robh@kernel.org>
^ permalink raw reply
* [PATCH -next] clk: zx296718: use builtin_platform_driver to simplify the code
From: Wei Yongjun @ 2016-09-16 13:03 UTC (permalink / raw)
To: linux-arm-kernel
From: Wei Yongjun <weiyongjun1@huawei.com>
Use the builtin_platform_driver() macro to make the code simpler.
Signed-off-by: Wei Yongjun <weiyongjun1@huawei.com>
---
drivers/clk/zte/clk-zx296718.c | 6 +-----
1 file changed, 1 insertion(+), 5 deletions(-)
diff --git a/drivers/clk/zte/clk-zx296718.c b/drivers/clk/zte/clk-zx296718.c
index 025e324..b4fe8dd 100644
--- a/drivers/clk/zte/clk-zx296718.c
+++ b/drivers/clk/zte/clk-zx296718.c
@@ -917,8 +917,4 @@ static struct platform_driver zx_clk_driver = {
},
};
-static int __init zx_clkc_init(void)
-{
- return platform_driver_register(&zx_clk_driver);
-}
-device_initcall(zx_clkc_init);
+builtin_platform_driver(zx_clk_driver);
^ permalink raw reply related
* genirq: Setting trigger mode 0 for irq 11 failed (txx9_irq_set_type+0x0/0xb8)
From: Krzysztof Kozlowski @ 2016-09-16 13:16 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <57DBEBC8.7000209@arm.com>
On Fri, Sep 16, 2016 at 2:55 PM, Marc Zyngier <marc.zyngier@arm.com> wrote:
> +Krzystof, Kukjin,
>
> On 16/09/16 12:03, Alban Browaeys wrote:
>> Le vendredi 16 septembre 2016 ? 08:51 +0100, Marc Zyngier a ?crit :
>>> Hi Alban,
>>>
>>> On 16/09/16 00:02, Alban Browaeys wrote:
>>>> I am seeing this on arm odroid u2 devicetree :
>>>> genirq: Setting trigger mode 0 for irq 16 failed
>>>> (gic_set_type+0x0/0x64)
>>>
>>> Passing IRQ_TYPE_NONE to a cascading interrupt is risky at best...
>>> Can you point me to the various DTs and their failing interrupts?
>>
>> mine is:
>> https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tree/arch/arm/boot/dts/exynos4412-odroidu3.dts
>>
>> I got a report of this issue to another odroid :
>> https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tree/arch/arm/boot/dts/exynos4412-odroidx2.dts
>>
>>
>>
>> they both get their settings from :
>> https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tree/arch/arm/boot/dts/exynos4412.dtsi
>>
>> relevant in the chain are:
>> - combiner modified:
>> https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tree/arch/arm/boot/dts/exynos4x12.dtsi#n460
>
> How wonderful. This section is an utter pile of crap. Really.
> Having 0 as the trigger is illegal, and the valid values are fully
> documented in the GIC binding. No wonder things start breaking.
+CC Marek Szyprowski,
Yes, that is interesting pile. Lately we stomped into it as well... I
started fixing this today but didn't finish it yet.
> And that's from the following stuff:
>
> &pinctrl_0 {
> compatible = "samsung,exynos4x12-pinctrl";
> reg = <0x11400000 0x1000>;
> interrupts = <0 47 0>;
> };
>
> &pinctrl_1 {
> compatible = "samsung,exynos4x12-pinctrl";
> reg = <0x11000000 0x1000>;
> interrupts = <0 46 0>;
>
> wakup_eint: wakeup-interrupt-controller {
> compatible = "samsung,exynos4210-wakeup-eint";
> interrupt-parent = <&gic>;
> interrupts = <0 32 0>;
> };
> };
>
> [...]
>
> &pinctrl_3 {
> compatible = "samsung,exynos4x12-pinctrl";
> reg = <0x106E0000 0x1000>;
> interrupts = <0 72 0>;
> };
>
> which perpetuates this fine tradition...
>
> At that stage, I'm not sure I should care. Does the workaround make your
> platform usable? The Samsung maintainers should really try and fix their
> DT, because it is a miracle this has made it that far.
Miracle or coincidence. :)
Thanks Geert and Alban for bringing this up, I'll add also yours reported-by.
Best regards,
Krzysztof
^ permalink raw reply
* [PATCH RFC 0/8] Add R8A7743/SK-RZG1M board support
From: Sergei Shtylyov @ 2016-09-16 13:26 UTC (permalink / raw)
To: linux-arm-kernel
Hello.
Here's the set of 8 patches against Simon Horman's 'renesas.git' repo,
'renesas-devel-20160916-v4.8-rc6' tag. I'm adding the device tree support for
the R8A7743-based SK-RZG1M board. The SoC is close to R8A7791 and the board
seems identical to the R8A7791/Porter board. Only serial console is supported
for now, no DHCP/NFS support yet, it will be done RSN... :-)
[1/8] ARM: shmobile: r8a7743: add clock index macros
[2/8] ARM: shmobile: r8a7743: add power domain index macros
[3/8] soc: renesas: rcar-sysc: add R8A7743 support
[4/8] ARM: shmobile: r8a7743: basic SoC support
[5/8] ARM: dts: r8a7743: initial SoC device tree
[6/8] ARM: dts: r8a7743: add SYS-DMAC support
[7/8] ARM: dts: r8a7743: add [H]SCIF support
[8/8] ARM: dts: sk-rzg1m: initial device tree
WBR, Sergei
^ permalink raw reply
* [PATCH v5 1/2] ARM: dts: imx6: Add support for Toradex Apalis iMX6Q/D SoM
From: Marcel Ziswiler @ 2016-09-16 13:28 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <97a3d506-35a0-2a15-18ef-2719c0596cc1@mentor.com>
Hi Vladimir
On Mon, 2016-08-29 at 16:28 +0300, Vladimir Zapolskiy wrote:
> Hi Marcel,
>
> On 02/05/2016 06:12 PM, Marcel Ziswiler wrote:
> >
> > From: Petr ?tetiar <ynezz@true.cz>
> >
> > Signed-off-by: Marcel Ziswiler <marcel.ziswiler@toradex.com>
> > Signed-off-by: Petr ?tetiar <ynezz@true.cz>
> > Reviewed-by: Stefan Agner <stefan@agner.ch>
> > ---
> >
> because the change is in mainline now below is kind of out of date
> information, but you may find it helpful.
>
> [snip]
>
> >
> > - fixed HDMI DDC (requires GPIO-based bitbanging I2C to be enabled)
> This is not needed.
>
> [snip]
>
> >
> > + /* DDC_I2C: I2C2_SDA/SCL on MXM3 205/207 */
> > + i2cddc: i2c at 0 {
> > + compatible = "i2c-gpio";
> > + pinctrl-names = "default";
> > + pinctrl-0 = <&pinctrl_i2c_ddc>;
> > + gpios = <&gpio3 16 GPIO_ACTIVE_HIGH /* sda */
> > + ?&gpio2 30 GPIO_ACTIVE_HIGH /* scl */
> > + >;
> > + i2c-gpio,delay-us = <2>; /* ~100 kHz */
> > + status = "disabled";
> > + };
> > +
> This is not needed.
>
> [snip]
>
> >
> > + pinctrl_i2c_ddc: gpioi2cddcgrp {
> > + fsl,pins = <
> > + /* DDC bitbang */
> > + MX6QDL_PAD_EIM_EB2__GPIO2_IO30 0x1b0b0
> > + MX6QDL_PAD_EIM_D16__GPIO3_IO16 0x1b0b0
> > + >;
> > + };
> > +
> Practically you don't need this overcomplicated GPIO-based bitbanging
> to emulate I2C, because the DW HDMI controller has a reduced I2C
> controller on board, you may take a look at its support published
> here:
>
> ????http://www.spinics.net/lists/dri-devel/msg116308.html
>
> To utilize it the pads should be set to HDMI function instead of
> I2C or GPIO.
Works nicely indeed, thanks for letting us know.
> --
> With best wishes,
> Vladimir
Best wishes to you too!
Cheers
Marcel
^ permalink raw reply
* [PATCH v9 07/10] arm: arm64: pmu: Assign platform PMU CPU affinity
From: Will Deacon @ 2016-09-16 13:29 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1473892358-22574-8-git-send-email-jeremy.linton@arm.com>
On Wed, Sep 14, 2016 at 05:32:35PM -0500, Jeremy Linton wrote:
> On systems with multiple PMU types the PMU to CPU affinity
> needs to be detected and set. The CPU to interrupt affinity
> should also be set.
>
> Signed-off-by: Jeremy Linton <jeremy.linton@arm.com>
> ---
> drivers/perf/arm_pmu.c | 63 ++++++++++++++++++++++++++++++++++++++++++--------
> 1 file changed, 53 insertions(+), 10 deletions(-)
>
> diff --git a/drivers/perf/arm_pmu.c b/drivers/perf/arm_pmu.c
> index 58117d7..63f16a5 100644
> --- a/drivers/perf/arm_pmu.c
> +++ b/drivers/perf/arm_pmu.c
> @@ -11,6 +11,7 @@
> */
> #define pr_fmt(fmt) "hw perfevents: " fmt
>
> +#include <linux/acpi.h>
> #include <linux/bitmap.h>
> #include <linux/cpumask.h>
> #include <linux/cpu_pm.h>
> @@ -24,6 +25,7 @@
> #include <linux/irq.h>
> #include <linux/irqdesc.h>
>
> +#include <asm/cpu.h>
> #include <asm/cputype.h>
> #include <asm/irq_regs.h>
>
> @@ -876,25 +878,67 @@ static void cpu_pmu_destroy(struct arm_pmu *cpu_pmu)
> }
>
> /*
> - * CPU PMU identification and probing.
> + * CPU PMU identification and probing. Its possible to have
> + * multiple CPU types in an ARM machine. Assure that we are
> + * picking the right PMU types based on the CPU in question
> */
> -static int probe_current_pmu(struct arm_pmu *pmu,
> - const struct pmu_probe_info *info)
> +static int probe_plat_pmu(struct arm_pmu *pmu,
> + const struct pmu_probe_info *info,
> + unsigned int pmuid)
> {
> - int cpu = get_cpu();
> - unsigned int cpuid = read_cpuid_id();
> int ret = -ENODEV;
> + int cpu;
> + int aff_ctr = 0;
> + static int duplicate_pmus;
> + struct platform_device *pdev = pmu->plat_device;
> + int irq = platform_get_irq(pdev, 0);
>
> - pr_info("probing PMU on CPU %d\n", cpu);
> + if (irq >= 0 && !irq_is_percpu(irq)) {
> + pmu->irq_affinity = kcalloc(pdev->num_resources, sizeof(int),
> + GFP_KERNEL);
> + if (!pmu->irq_affinity)
> + return -ENOMEM;
> + }
>
> + for_each_possible_cpu(cpu) {
> + unsigned int cpuid = read_specific_cpuid(cpu);
> +
> + if (cpuid == pmuid) {
> + cpumask_set_cpu(cpu, &pmu->supported_cpus);
> + if (pmu->irq_affinity) {
> + pmu->irq_affinity[aff_ctr] = cpu;
> + aff_ctr++;
> + }
> + }
> + }
> +
> + /* find the type of PMU given the CPU */
> for (; info->init != NULL; info++) {
> - if ((cpuid & info->mask) != info->cpuid)
> + if ((pmuid & info->mask) != info->cpuid)
> continue;
> ret = info->init(pmu);
> + /*
> + * if this pmu declaration is unspecified and we have
> + * previously found a PMU on this platform then append
> + * a PMU number to the pmu name. This avoids changing
> + * the names of PMUs that are specific to a class of CPUs.
> + * The assumption is that if we match a specific PMU in the
> + * provided pmu_probe_info then it's unique, and another PMU
> + * in the system will match a different entry rather than
> + * needing the _number to assure its unique.
> + */
> + if ((!info->cpuid) && (duplicate_pmus)) {
Hmm, the duplicate_pmus check looks a little odd here. Doesn't it mean
that you'd end up with things like:
"arm,armv8-pmuv3"
"arm,armv8-pmuv3_1"
which looks needlessly fiddly to parse. Is this intentional?
Will
^ permalink raw reply
* [PATCH v3 0/2] KVM: ARM: Enable vtimers with user space gic
From: Christoffer Dall @ 2016-09-16 13:30 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <da8191ca-6fb1-f960-872c-d6bc27172db8@redhat.com>
On Fri, Sep 16, 2016 at 02:31:42PM +0200, Paolo Bonzini wrote:
>
>
> On 16/09/2016 14:30, Christoffer Dall wrote:
> > > > > This patch set allows user space to receive vtimer events as well as mask
> > > > > them, so that we can handle all vtimer related interrupt injection from user
> > > > > space, enabling us to use architected timer with user space gic emulation.
> > > >
> > > > I have already voiced my concerns in the past, including face to face,
> > > > and I'm going to repeat it: I not keen at all on adding a new userspace
> > > > interface that is going to bitrot extremely quickly.
> > >
> > > You don't have automated tests set up? It's not going to bitrot if you
> > > test it, either with kvm-unit-tests or just by smoke-testing Linux.
> > > It's _for_ the raspi, but it's not limited to it.
> >
> > Our automated testing situation is not great, no. Something we're
> > looking at, but have resource problems with.
>
> But it's not a good reason to hold back a feature...
>
I didn't say that exactly, but choosing not to merge something we cannot
maintain and which we're not paid to look after and where there's a
minimal interest, is not entirely unreasonable.
That being said, I'm not categorically against these patches, but I
share Marc's view that we've already seen that non-vgic support had been
broken for multiple versions without anyone complaining, and without
automated testing or substantial interest in the work, the patches
really are likely to bit-rot.
But I haven't even looked at the patches in detail, I was just replying
to the comment about testing.
-Christoffer
^ permalink raw reply
* [PATCH v7 0/5] mfd: tps65218: Clean ups
From: Mark Brown @ 2016-09-16 13:31 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <ab94aff0-8470-57e5-2039-12f09bb0ca33@ti.com>
On Fri, Sep 16, 2016 at 05:12:38PM +0530, Keerthy wrote:
> Should i repost this series? I do not see this series in linux-next yet.
Please don't send content free pings and please allow a reasonable time
for review. People get busy, go on holiday, attend conferences and so
on so unless there is some reason for urgency (like critical bug fixes)
please allow at least a couple of weeks for review. If there have been
review comments then people may be waiting for those to be addressed.
Sending content free pings adds to the mail volume (if they are seen at
all) which is often the problem and since they can't be reviewed
directly if something has gone wrong you'll have to resend the patches
anyway, though there are some other maintainers who like them - if in
doubt look at how patches for the subsystem are normally handled.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 473 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20160916/aff69cd5/attachment.sig>
^ permalink raw reply
* [PATCH RFC 4/8] ARM: shmobile: r8a7743: basic SoC support
From: Sergei Shtylyov @ 2016-09-16 13:33 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <3533019.Wim1Kuh1ic@wasted.cogentembedded.com>
Add minimal support for the RZ/G1M (R8A7743) SoC.
Based on the original (and large) patch by Dmitry Shifrin
<dmitry.shifrin@cogentembedded.com>.
Signed-off-by: Sergei Shtylyov <sergei.shtylyov@cogentembedded.com>
---
arch/arm/mach-shmobile/Kconfig | 5 ++++
arch/arm/mach-shmobile/Makefile | 1
arch/arm/mach-shmobile/setup-r8a7743.c | 34 +++++++++++++++++++++++++++++++++
3 files changed, 40 insertions(+)
Index: renesas/arch/arm/mach-shmobile/Kconfig
===================================================================
--- renesas.orig/arch/arm/mach-shmobile/Kconfig
+++ renesas/arch/arm/mach-shmobile/Kconfig
@@ -68,6 +68,11 @@ config ARCH_R8A7740
select ARCH_RMOBILE
select RENESAS_INTC_IRQPIN
+config ARCH_R8A7743
+ bool "RZ/G1M (R8A77430)"
+ select ARCH_RCAR_GEN2
+ select I2C
+
config ARCH_R8A7778
bool "R-Car M1A (R8A77781)"
select ARCH_RCAR_GEN1
Index: renesas/arch/arm/mach-shmobile/Makefile
===================================================================
--- renesas.orig/arch/arm/mach-shmobile/Makefile
+++ renesas/arch/arm/mach-shmobile/Makefile
@@ -9,6 +9,7 @@ obj-y := timer.o
obj-$(CONFIG_ARCH_SH73A0) += setup-sh73a0.o
obj-$(CONFIG_ARCH_R8A73A4) += setup-r8a73a4.o
obj-$(CONFIG_ARCH_R8A7740) += setup-r8a7740.o
+obj-$(CONFIG_ARCH_R8A7743) += setup-r8a7743.o
obj-$(CONFIG_ARCH_R8A7778) += setup-r8a7778.o
obj-$(CONFIG_ARCH_R8A7779) += setup-r8a7779.o pm-r8a7779.o
obj-$(CONFIG_ARCH_R8A7790) += setup-r8a7790.o
Index: renesas/arch/arm/mach-shmobile/setup-r8a7743.c
===================================================================
--- /dev/null
+++ renesas/arch/arm/mach-shmobile/setup-r8a7743.c
@@ -0,0 +1,34 @@
+/*
+ * r8a7743 processor support
+ *
+ * Copyright (C) 2016 Cogent Embedded, Inc.
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation; of the License.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ */
+
+#include <linux/init.h>
+
+#include <asm/mach/arch.h>
+
+#include "common.h"
+#include "rcar-gen2.h"
+
+static const char * const r8a7743_boards_compat_dt[] __initconst = {
+ "renesas,r8a7743",
+ NULL,
+};
+
+DT_MACHINE_START(R8A7743_DT, "Generic R8A7743 (Flattened Device Tree)")
+ .init_early = shmobile_init_delay,
+ .init_time = rcar_gen2_timer_init,
+ .init_late = shmobile_init_late,
+ .reserve = rcar_gen2_reserve,
+ .dt_compat = r8a7743_boards_compat_dt,
+MACHINE_END
^ permalink raw reply
* [PATCH v9 08/10] arm64: pmu: Detect and enable multiple PMUs in an ACPI system
From: Punit Agrawal @ 2016-09-16 13:33 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1473892358-22574-9-git-send-email-jeremy.linton@arm.com>
Jeremy Linton <jeremy.linton@arm.com> writes:
> Its possible that an ACPI system has multiple CPU types in it
> with differing PMU counters. Iterate the CPU's and make a determination
> about how many of each type exist in the system. Then take and create
> a PMU platform device for each type, and assign it the interrupts parsed
> from the MADT. Creating a platform device is necessary because the PMUs
> are not described as devices in the DSDT table.
>
> This code is loosely based on earlier work by Mark Salter.
>
> Signed-off-by: Jeremy Linton <jeremy.linton@arm.com>
> ---
> drivers/perf/arm_pmu.c | 8 +-
> drivers/perf/arm_pmu_acpi.c | 224 ++++++++++++++++++++++++++++++++++++++++++++
> 2 files changed, 231 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/perf/arm_pmu.c b/drivers/perf/arm_pmu.c
> index 63f16a5..47ab4e9 100644
> --- a/drivers/perf/arm_pmu.c
> +++ b/drivers/perf/arm_pmu.c
> @@ -1074,7 +1074,13 @@ int arm_pmu_device_probe(struct platform_device *pdev,
> if (!ret)
> ret = init_fn(pmu);
> } else if (probe_table) {
> - ret = probe_plat_pmu(pmu, probe_table, read_cpuid_id());
> + if (acpi_disabled) {
> + /* use the current cpu. */
> + ret = probe_plat_pmu(pmu, probe_table,
> + read_cpuid_id());
> + } else {
> + ret = probe_plat_pmu(pmu, probe_table, pdev->id);
> + }
> }
>
> if (ret) {
> diff --git a/drivers/perf/arm_pmu_acpi.c b/drivers/perf/arm_pmu_acpi.c
> index dbd4e10..7c56ee4 100644
> --- a/drivers/perf/arm_pmu_acpi.c
> +++ b/drivers/perf/arm_pmu_acpi.c
> @@ -2,13 +2,17 @@
> * ARM ACPI PMU support
> *
> * Copyright (C) 2015 Red Hat Inc.
> + * Copyright (C) 2016 ARM Ltd.
> * Author: Mark Salter <msalter@redhat.com>
> + * Jeremy Linton <jeremy.linton@arm.com>
> *
> * This work is licensed under the terms of the GNU GPL, version 2. See
> * the COPYING file in the top-level directory.
> *
> */
>
> +#define pr_fmt(fmt) "ACPI-PMU: " fmt
> +
> #include <asm/cpu.h>
> #include <linux/acpi.h>
> #include <linux/irq.h>
> @@ -23,6 +27,12 @@ struct pmu_irq {
> bool registered;
> };
>
> +struct pmu_types {
> + struct list_head list;
> + int cpu_type;
Apologies for not noticing this earlier but cpu_type should be u32 to
match partnum (which is derived from reg_midr).
> + int cpu_count;
> +};
> +
> static struct pmu_irq pmu_irqs[NR_CPUS];
>
> /*
> @@ -38,3 +48,217 @@ void __init arm_pmu_parse_acpi(int cpu, struct acpi_madt_generic_interrupt *gic)
> else
> pmu_irqs[cpu].trigger = ACPI_LEVEL_SENSITIVE;
> }
> +
> +static void __init arm_pmu_acpi_handle_alloc_failure(struct list_head *pmus)
> +{
> + struct pmu_types *pmu, *safe_temp;
> +
> + list_for_each_entry_safe(pmu, safe_temp, pmus, list) {
> + list_del(&pmu->list);
> + kfree(pmu);
> + }
> +}
> +
> +/* Count number and type of CPU cores in the system. */
> +static bool __init arm_pmu_acpi_determine_cpu_types(struct list_head *pmus)
> +{
> + int i;
> + bool unused_madt_entries = false;
> +
> + for_each_possible_cpu(i) {
> + struct cpuinfo_arm64 *cinfo = per_cpu_ptr(&cpu_data, i);
> + u32 partnum = MIDR_PARTNUM(cinfo->reg_midr);
> + struct pmu_types *pmu;
> +
> + if (cinfo->reg_midr == 0) {
When can the above condition be true? Worth a comment.
> + unused_madt_entries = true;
> + continue;
> + }
> +
> + list_for_each_entry(pmu, pmus, list) {
> + if (pmu->cpu_type == partnum) {
> + pmu->cpu_count++;
> + break;
> + }
> + }
> +
> + /* we didn't find the CPU type, add an entry to identify it */
> + if (&pmu->list == pmus) {
> + pmu = kzalloc(sizeof(struct pmu_types), GFP_KERNEL);
> + if (!pmu) {
> + pr_err("Unable to allocate pmu_types\n");
> + /*
> + * Instead of waiting to cleanup possible
> + * allocation failures in the caller clean
> + * them up immediately. Functionally this
> + * doesn't make any difference, except in
> + * genuine heterogeneous systems where it
> + * guarantees the whole subsystem is
> + * disabled rather than running with just
> + * a single set of homogeneous CPU's PMU
> + * active. That assumes there aren't
> + * any further memory allocation failures.
> + */
> + arm_pmu_acpi_handle_alloc_failure(pmus);
> + break;
> + } else {
> + pmu->cpu_type = partnum;
> + pmu->cpu_count++;
> + list_add_tail(&pmu->list, pmus);
> + }
> + }
> + }
> +
> + return unused_madt_entries;
> +}
> +
> +/*
> + * Registers the group of PMU interfaces which correspond to the 'last_cpu_id'.
> + * This group utilizes 'count' resources in the 'res'.
> + */
> +static int __init arm_pmu_acpi_register_pmu(int count, struct resource *res,
> + int last_cpu_id)
> +{
> + int i;
> + int err = -ENOMEM;
> + bool free_gsi = false;
> + struct platform_device *pdev;
> +
> + if (count) {
> + pdev = platform_device_alloc(ARMV8_PMU_PDEV_NAME, last_cpu_id);
> + if (pdev) {
> + err = platform_device_add_resources(pdev, res, count);
> + if (!err) {
> + err = platform_device_add(pdev);
> + if (err) {
> + pr_warn("Unable to register PMU device\n");
> + free_gsi = true;
> + }
> + } else {
> + pr_warn("Unable to add resources to device\n");
> + free_gsi = true;
> + platform_device_put(pdev);
> + }
> + } else {
> + pr_warn("Unable to allocate platform device\n");
> + free_gsi = true;
> + }
> + }
The above if block is quite hard to review. I've had the same comment on
previous versions as well.
> +
> + /* unmark (and possibly unregister) registered GSIs */
> + for_each_possible_cpu(i) {
> + if (pmu_irqs[i].registered) {
> + if (free_gsi)
> + acpi_unregister_gsi(pmu_irqs[i].gsi);
> + pmu_irqs[i].registered = false;
> + }
> + }
> +
> + return err;
> +}
> +
> +int arm_pmu_acpi_retrieve_irq(struct resource *res, int cpu)
The return value of this function isn't used anywhere. Any reason it
can't be void?
> +{
> + int irq = -ENODEV;
> +
> + if (pmu_irqs[cpu].registered) {
> + pr_info("CPU %d's interrupt is already registered\n", cpu);
> + } else {
> + irq = acpi_register_gsi(NULL, pmu_irqs[cpu].gsi,
> + pmu_irqs[cpu].trigger,
> + ACPI_ACTIVE_HIGH);
> + pmu_irqs[cpu].registered = true;
> + res->start = irq;
> + res->end = irq;
> + res->flags = IORESOURCE_IRQ;
> + if (pmu_irqs[cpu].trigger == ACPI_EDGE_SENSITIVE)
> + res->flags |= IORESOURCE_IRQ_HIGHEDGE;
> + else
> + res->flags |= IORESOURCE_IRQ_HIGHLEVEL;
> + }
> + return irq;
> +}
> +
> +/*
> + * For the given cpu/pmu type, walk all known GSIs, register them, and add
> + * them to the resource structure. Return the number of GSI's contained
> + * in the res structure, and the id of the last CPU/PMU we added.
> + */
> +static int __init arm_pmu_acpi_gsi_res(struct pmu_types *pmus,
> + struct resource *res, int *last_cpu_id)
> +{
> + int i, count;
> +
> + /* lets group all the PMU's from similar CPU's together */
> + count = 0;
> + for_each_possible_cpu(i) {
> + struct cpuinfo_arm64 *cinfo = per_cpu_ptr(&cpu_data, i);
> +
> + if (pmus->cpu_type == MIDR_PARTNUM(cinfo->reg_midr)) {
> + if ((pmu_irqs[i].gsi == 0) && (cinfo->reg_midr != 0)) {
> + pr_info("CPU %d is assigned interrupt 0\n", i);
> + continue;
> + }
> + /* likely not online */
> + if (!cinfo->reg_midr)
> + continue;
> +
> + arm_pmu_acpi_retrieve_irq(&res[count], i);
> + count++;
> + (*last_cpu_id) = cinfo->reg_midr;
> + }
> + }
> + return count;
> +}
> +
> +static int __init pmu_acpi_init(void)
> +{
> + struct resource *res;
> + int err = -ENOMEM;
> + int count, cpu_id;
> + struct pmu_types *pmu, *safe_temp;
> + bool unused_madt_entries;
> + LIST_HEAD(pmus);
> +
> + if (acpi_disabled)
> + return 0;
> +
> + unused_madt_entries = arm_pmu_acpi_determine_cpu_types(&pmus);
> +
> + list_for_each_entry_safe(pmu, safe_temp, &pmus, list) {
> + if (unused_madt_entries)
> + pmu->cpu_count = num_possible_cpus();
So if there is any unbooted cpu ...
> +
> + res = kcalloc(pmu->cpu_count,
> + sizeof(struct resource), GFP_KERNEL);
... we allocate potentially large number (num_possible_cpus()) of
resources for each PMU.
This is needlessly wasteful. Under what conditions have you found
reg_midr to be 0?
> +
> + /* for a given PMU type collect all the GSIs. */
> + if (res) {
> + count = arm_pmu_acpi_gsi_res(pmu, res,
> + &cpu_id);
> + /*
> + * register this set of interrupts
> + * with a new PMU device
> + */
> + if (count) {
> + if (unused_madt_entries)
> + count = num_possible_cpus();
> + err = arm_pmu_acpi_register_pmu(count, res,
> + cpu_id);
> + if (!err)
> + pr_info("Register %d devices for %X\n",
> + count, pmu->cpu_type);
> + kfree(res);
> + }
> + } else {
> + pr_warn("PMU unable to allocate interrupt resource\n");
> + }
> +
> + list_del(&pmu->list);
> + kfree(pmu);
> + }
> +
> + return err;
> +}
> +
> +arch_initcall(pmu_acpi_init);
^ permalink raw reply
* [PATCH RFC 5/8] ARM: dts: r8a7743: initial SoC device tree
From: Sergei Shtylyov @ 2016-09-16 13:35 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <3533019.Wim1Kuh1ic@wasted.cogentembedded.com>
The initial R8A7743 SoC device tree including CPU cores, GIC, timer, SYSC,
and the required clock descriptions.
Based on the original (and large) patch by Dmitry Shifrin
<dmitry.shifrin@cogentembedded.com>.
Signed-off-by: Sergei Shtylyov <sergei.shtylyov@cogentembedded.com>
---
arch/arm/boot/dts/r8a7743.dtsi | 210 +++++++++++++++++++++++++++++++++++++++++
1 file changed, 210 insertions(+)
Index: renesas/arch/arm/boot/dts/r8a7743.dtsi
===================================================================
--- /dev/null
+++ renesas/arch/arm/boot/dts/r8a7743.dtsi
@@ -0,0 +1,210 @@
+/*
+ * Device Tree Source for the r8a7743 SoC
+ *
+ * Copyright (C) 2016 Cogent Embedded Inc.
+ *
+ * This file is licensed under the terms of the GNU General Public License
+ * version 2. This program is licensed "as is" without any warranty of any
+ * kind, whether express or implied.
+ */
+
+#include <dt-bindings/interrupt-controller/irq.h>
+#include <dt-bindings/interrupt-controller/arm-gic.h>
+#include <dt-bindings/clock/r8a7743-clock.h>
+#include <dt-bindings/power/r8a7743-sysc.h>
+
+/ {
+ compatible = "renesas,r8a7743";
+ #address-cells = <2>;
+ #size-cells = <2>;
+
+ cpus {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ cpu0: cpu at 0 {
+ device_type = "cpu";
+ compatible = "arm,cortex-a15";
+ reg = <0>;
+ clock-frequency = <1500000000>;
+ clocks = <&cpg_clocks R8A7743_CLK_Z>;
+ power-domains = <&sysc R8A7743_PD_CA15_CPU0>;
+ next-level-cache = <&L2_CA15>;
+ };
+
+ cpu1: cpu at 1 {
+ device_type = "cpu";
+ compatible = "arm,cortex-a15";
+ reg = <1>;
+ clock-frequency = <1500000000>;
+ power-domains = <&sysc R8A7743_PD_CA15_CPU1>;
+ next-level-cache = <&L2_CA15>;
+ };
+
+ L2_CA15: cache-controller at 0 {
+ compatible = "cache";
+ reg = <0>;
+ cache-unified;
+ cache-level = <2>;
+ power-domains = <&sysc R8A7743_PD_CA15_SCU>;
+ };
+ };
+
+ soc {
+ compatible = "simple-bus";
+ interrupt-parent = <&gic>;
+
+ #address-cells = <2>;
+ #size-cells = <2>;
+ ranges;
+
+ gic: interrupt-controller at f1001000 {
+ compatible = "arm,gic-400";
+ #interrupt-cells = <3>;
+ #address-cells = <0>;
+ interrupt-controller;
+ reg = <0 0xf1001000 0 0x1000>,
+ <0 0xf1002000 0 0x1000>,
+ <0 0xf1004000 0 0x2000>,
+ <0 0xf1006000 0 0x2000>;
+ interrupts = <GIC_PPI 9
+ (GIC_CPU_MASK_SIMPLE(2) |
+ IRQ_TYPE_LEVEL_HIGH)>;
+ };
+
+ timer {
+ compatible = "arm,armv7-timer";
+ interrupts = <GIC_PPI 13 (GIC_CPU_MASK_SIMPLE(2) |
+ IRQ_TYPE_LEVEL_LOW)>,
+ <GIC_PPI 14 (GIC_CPU_MASK_SIMPLE(2) |
+ IRQ_TYPE_LEVEL_LOW)>,
+ <GIC_PPI 11 (GIC_CPU_MASK_SIMPLE(2) |
+ IRQ_TYPE_LEVEL_LOW)>,
+ <GIC_PPI 10 (GIC_CPU_MASK_SIMPLE(2) |
+ IRQ_TYPE_LEVEL_LOW)>;
+ };
+
+ sysc: system-controller at e6180000 {
+ compatible = "renesas,r8a7743-sysc";
+ reg = <0 0xe6180000 0 0x0200>;
+ #power-domain-cells = <1>;
+ };
+
+ /* Special CPG clocks */
+ cpg_clocks: cpg_clocks at e6150000 {
+ compatible = "renesas,r8a7743-cpg-clocks",
+ "renesas,rcar-gen2-cpg-clocks";
+ reg = <0 0xe6150000 0 0x1000>;
+ clocks = <&extal_clk &usb_extal_clk>;
+ #clock-cells = <1>;
+ clock-output-names = "main", "pll0", "pll1", "pll3",
+ "lb", "qspi", "sdh", "sd0", "z",
+ "rcan";
+ #power-domain-cells = <0>;
+ };
+
+ /* Fixed factor clocks */
+ pll1_div2_clk: pll1_div2 {
+ compatible = "fixed-factor-clock";
+ clocks = <&cpg_clocks R8A7743_CLK_PLL1>;
+ #clock-cells = <0>;
+ clock-div = <2>;
+ clock-mult = <1>;
+ };
+ zs_clk: zs {
+ compatible = "fixed-factor-clock";
+ clocks = <&cpg_clocks R8A7743_CLK_PLL1>;
+ #clock-cells = <0>;
+ clock-div = <6>;
+ clock-mult = <1>;
+ };
+ p_clk: p {
+ compatible = "fixed-factor-clock";
+ clocks = <&cpg_clocks R8A7743_CLK_PLL1>;
+ #clock-cells = <0>;
+ clock-div = <24>;
+ clock-mult = <1>;
+ };
+ mp_clk: mp {
+ compatible = "fixed-factor-clock";
+ clocks = <&pll1_div2_clk>;
+ #clock-cells = <0>;
+ clock-div = <15>;
+ clock-mult = <1>;
+ };
+
+ /* Gate clocks */
+ mstp2_clks: mstp2_clks at e6150138 {
+ compatible = "renesas,r8a7743-mstp-clocks",
+ "renesas,cpg-mstp-clocks";
+ reg = <0 0xe6150138 0 4>, <0 0xe6150040 0 4>;
+ clocks = <&mp_clk>, <&mp_clk>, <&mp_clk>, <&mp_clk>,
+ <&mp_clk>, <&mp_clk>, <&zs_clk>, <&zs_clk>;
+ #clock-cells = <1>;
+ clock-indices = <
+ R8A7743_CLK_SCIFA2 R8A7743_CLK_SCIFA1
+ R8A7743_CLK_SCIFA0 R8A7743_CLK_SCIFB0
+ R8A7743_CLK_SCIFB1 R8A7743_CLK_SCIFB2
+ R8A7743_CLK_SYS_DMAC1 R8A7743_CLK_SYS_DMAC0
+ >;
+ clock-output-names =
+ "scifa2", "scifa1", "scifa0",
+ "scifb0", "scifb1", "scifb2",
+ "sys-dmac1", "sys-dmac0";
+ };
+ mstp7_clks: mstp7_clks at e615014c {
+ compatible = "renesas,r8a7743-mstp-clocks",
+ "renesas,cpg-mstp-clocks";
+ reg = <0 0xe615014c 0 4>, <0 0xe61501c4 0 4>;
+ clocks = <&zs_clk>, <&p_clk>, <&p_clk>, <&zs_clk>,
+ <&zs_clk>, <&p_clk>, <&p_clk>, <&p_clk>,
+ <&p_clk>;
+ #clock-cells = <1>;
+ clock-indices = <
+ R8A7743_CLK_HSCIF2 R8A7743_CLK_SCIF5
+ R8A7743_CLK_SCIF4 R8A7743_CLK_HSCIF1
+ R8A7743_CLK_HSCIF0 R8A7743_CLK_SCIF3
+ R8A7743_CLK_SCIF2 R8A7743_CLK_SCIF1
+ R8A7743_CLK_SCIF0
+ >;
+ clock-output-names =
+ "hscif2", "scif5", "scif4", "hscif1", "hscif0",
+ "scif3", "scif2", "scif1", "scif0";
+ };
+ mstp11_clks: mstp11_clks at e615099c {
+ compatible = "renesas,r8a7743-mstp-clocks",
+ "renesas,cpg-mstp-clocks";
+ reg = <0 0xe615099c 0 4>, <0 0xe61509ac 0 4>;
+ clocks = <&mp_clk>, <&mp_clk>, <&mp_clk>;
+ #clock-cells = <1>;
+ clock-indices = <
+ R8A7743_CLK_SCIFA3 R8A7743_CLK_SCIFA4
+ R8A7743_CLK_SCIFA5
+ >;
+ clock-output-names = "scifa3", "scifa4", "scifa5";
+ };
+ };
+
+ /* External root clock */
+ extal_clk: extal {
+ compatible = "fixed-clock";
+ #clock-cells = <0>;
+ /* This value must be overriden by the board. */
+ clock-frequency = <0>;
+ };
+
+ /* External USB clock - can be overridden by the board */
+ usb_extal_clk: usb_extal {
+ compatible = "fixed-clock";
+ #clock-cells = <0>;
+ clock-frequency = <48000000>;
+ };
+
+ /* External SCIF clock */
+ scif_clk: scif {
+ compatible = "fixed-clock";
+ #clock-cells = <0>;
+ /* This value must be overridden by the board. */
+ clock-frequency = <0>;
+ };
+};
^ permalink raw reply
* genirq: Setting trigger mode 0 for irq 11 failed (txx9_irq_set_type+0x0/0xb8)
From: Alban Browaeys @ 2016-09-16 13:35 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <57DBEBC8.7000209@arm.com>
Le vendredi 16 septembre 2016 ? 13:55 +0100, Marc Zyngier a ?crit?:
> At that stage, I'm not sure I should care. Does the workaround make
> your
> platform usable?
However awkward this was all about logs and clearing worries. There was
no change in behavior ?between the three cases : upstream, upstream
commit reverted and patched upstream.
Mind this hardware (the Odroid U2) has no hardware buttons. Only power
on plug.
Best regards,
Alban
^ permalink raw reply
* [PATCH RFC 6/8] ARM: dts: r8a7743: add SYS-DMAC support
From: Sergei Shtylyov @ 2016-09-16 13:36 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <3533019.Wim1Kuh1ic@wasted.cogentembedded.com>
Describe SYS-DMAC0/1 in the R8A7743 device tree.
Based on the original (and large) patch by Dmitry Shifrin
<dmitry.shifrin@cogentembedded.com>.
Signed-off-by: Sergei Shtylyov <sergei.shtylyov@cogentembedded.com>
---
arch/arm/boot/dts/r8a7743.dtsi | 64 +++++++++++++++++++++++++++++++++++++++++
1 file changed, 64 insertions(+)
Index: renesas/arch/arm/boot/dts/r8a7743.dtsi
===================================================================
--- renesas.orig/arch/arm/boot/dts/r8a7743.dtsi
+++ renesas/arch/arm/boot/dts/r8a7743.dtsi
@@ -90,6 +90,70 @@
#power-domain-cells = <1>;
};
+ dmac0: dma-controller at e6700000 {
+ compatible = "renesas,dmac-r8a7743",
+ "renesas,rcar-dmac";
+ reg = <0 0xe6700000 0 0x20000>;
+ interrupts = <GIC_SPI 197 IRQ_TYPE_LEVEL_HIGH
+ GIC_SPI 200 IRQ_TYPE_LEVEL_HIGH
+ GIC_SPI 201 IRQ_TYPE_LEVEL_HIGH
+ GIC_SPI 202 IRQ_TYPE_LEVEL_HIGH
+ GIC_SPI 203 IRQ_TYPE_LEVEL_HIGH
+ GIC_SPI 204 IRQ_TYPE_LEVEL_HIGH
+ GIC_SPI 205 IRQ_TYPE_LEVEL_HIGH
+ GIC_SPI 206 IRQ_TYPE_LEVEL_HIGH
+ GIC_SPI 207 IRQ_TYPE_LEVEL_HIGH
+ GIC_SPI 208 IRQ_TYPE_LEVEL_HIGH
+ GIC_SPI 209 IRQ_TYPE_LEVEL_HIGH
+ GIC_SPI 210 IRQ_TYPE_LEVEL_HIGH
+ GIC_SPI 211 IRQ_TYPE_LEVEL_HIGH
+ GIC_SPI 212 IRQ_TYPE_LEVEL_HIGH
+ GIC_SPI 213 IRQ_TYPE_LEVEL_HIGH
+ GIC_SPI 214 IRQ_TYPE_LEVEL_HIGH>;
+ interrupt-names = "error",
+ "ch0", "ch1", "ch2", "ch3",
+ "ch4", "ch5", "ch6", "ch7",
+ "ch8", "ch9", "ch10", "ch11",
+ "ch12", "ch13", "ch14";
+ clocks = <&mstp2_clks R8A7743_CLK_SYS_DMAC0>;
+ clock-names = "fck";
+ power-domains = <&sysc R8A7743_PD_ALWAYS_ON>;
+ #dma-cells = <1>;
+ dma-channels = <15>;
+ };
+
+ dmac1: dma-controller at e6720000 {
+ compatible = "renesas,dmac-r8a7743",
+ "renesas,rcar-dmac";
+ reg = <0 0xe6720000 0 0x20000>;
+ interrupts = <GIC_SPI 220 IRQ_TYPE_LEVEL_HIGH
+ GIC_SPI 216 IRQ_TYPE_LEVEL_HIGH
+ GIC_SPI 217 IRQ_TYPE_LEVEL_HIGH
+ GIC_SPI 218 IRQ_TYPE_LEVEL_HIGH
+ GIC_SPI 219 IRQ_TYPE_LEVEL_HIGH
+ GIC_SPI 308 IRQ_TYPE_LEVEL_HIGH
+ GIC_SPI 309 IRQ_TYPE_LEVEL_HIGH
+ GIC_SPI 310 IRQ_TYPE_LEVEL_HIGH
+ GIC_SPI 311 IRQ_TYPE_LEVEL_HIGH
+ GIC_SPI 312 IRQ_TYPE_LEVEL_HIGH
+ GIC_SPI 313 IRQ_TYPE_LEVEL_HIGH
+ GIC_SPI 314 IRQ_TYPE_LEVEL_HIGH
+ GIC_SPI 315 IRQ_TYPE_LEVEL_HIGH
+ GIC_SPI 316 IRQ_TYPE_LEVEL_HIGH
+ GIC_SPI 317 IRQ_TYPE_LEVEL_HIGH
+ GIC_SPI 318 IRQ_TYPE_LEVEL_HIGH>;
+ interrupt-names = "error",
+ "ch0", "ch1", "ch2", "ch3",
+ "ch4", "ch5", "ch6", "ch7",
+ "ch8", "ch9", "ch10", "ch11",
+ "ch12", "ch13", "ch14";
+ clocks = <&mstp2_clks R8A7743_CLK_SYS_DMAC1>;
+ clock-names = "fck";
+ power-domains = <&sysc R8A7743_PD_ALWAYS_ON>;
+ #dma-cells = <1>;
+ dma-channels = <15>;
+ };
+
/* Special CPG clocks */
cpg_clocks: cpg_clocks at e6150000 {
compatible = "renesas,r8a7743-cpg-clocks",
^ permalink raw reply
* [PATCH RFC 7/8] ARM: dts: r8a7743: add [H]SCIF support
From: Sergei Shtylyov @ 2016-09-16 13:37 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <3533019.Wim1Kuh1ic@wasted.cogentembedded.com>
Describe [H]SCIFs in the R8A7743 device tree.
Based on the original (and large) patch by Dmitry Shifrin
<dmitry.shifrin@cogentembedded.com>.
Signed-off-by: Sergei Shtylyov <sergei.shtylyov@cogentembedded.com>
---
arch/arm/boot/dts/r8a7743.dtsi | 262 +++++++++++++++++++++++++++++++++++++++++
1 file changed, 262 insertions(+)
Index: renesas/arch/arm/boot/dts/r8a7743.dtsi
===================================================================
--- renesas.orig/arch/arm/boot/dts/r8a7743.dtsi
+++ renesas/arch/arm/boot/dts/r8a7743.dtsi
@@ -154,6 +154,268 @@
dma-channels = <15>;
};
+ scifa0: serial at e6c40000 {
+ compatible = "renesas,scifa-r8a7743",
+ "renesas,rcar-gen2-scifa", "renesas,scifa";
+ reg = <0 0xe6c40000 0 64>;
+ interrupts = <GIC_SPI 144 IRQ_TYPE_LEVEL_HIGH>;
+ clocks = <&mstp2_clks R8A7743_CLK_SCIFA0>;
+ clock-names = "fck";
+ dmas = <&dmac0 0x21>, <&dmac0 0x22>,
+ <&dmac1 0x21>, <&dmac1 0x22>;
+ dma-names = "tx", "rx", "tx", "rx";
+ power-domains = <&sysc R8A7743_PD_ALWAYS_ON>;
+ status = "disabled";
+ };
+
+ scifa1: serial at e6c50000 {
+ compatible = "renesas,scifa-r8a7743",
+ "renesas,rcar-gen2-scifa", "renesas,scifa";
+ reg = <0 0xe6c50000 0 64>;
+ interrupts = <GIC_SPI 145 IRQ_TYPE_LEVEL_HIGH>;
+ clocks = <&mstp2_clks R8A7743_CLK_SCIFA1>;
+ clock-names = "fck";
+ dmas = <&dmac0 0x25>, <&dmac0 0x26>,
+ <&dmac1 0x25>, <&dmac1 0x26>;
+ dma-names = "tx", "rx", "tx", "rx";
+ power-domains = <&sysc R8A7743_PD_ALWAYS_ON>;
+ status = "disabled";
+ };
+
+ scifa2: serial at e6c60000 {
+ compatible = "renesas,scifa-r8a7743",
+ "renesas,rcar-gen2-scifa", "renesas,scifa";
+ reg = <0 0xe6c60000 0 64>;
+ interrupts = <GIC_SPI 151 IRQ_TYPE_LEVEL_HIGH>;
+ clocks = <&mstp2_clks R8A7743_CLK_SCIFA2>;
+ clock-names = "fck";
+ dmas = <&dmac0 0x27>, <&dmac0 0x28>,
+ <&dmac1 0x27>, <&dmac1 0x28>;
+ dma-names = "tx", "rx", "tx", "rx";
+ power-domains = <&sysc R8A7743_PD_ALWAYS_ON>;
+ status = "disabled";
+ };
+
+ scifa3: serial at e6c70000 {
+ compatible = "renesas,scifa-r8a7743",
+ "renesas,rcar-gen2-scifa", "renesas,scifa";
+ reg = <0 0xe6c70000 0 64>;
+ interrupts = <GIC_SPI 29 IRQ_TYPE_LEVEL_HIGH>;
+ clocks = <&mstp11_clks R8A7743_CLK_SCIFA3>;
+ clock-names = "fck";
+ dmas = <&dmac0 0x1b>, <&dmac0 0x1c>,
+ <&dmac1 0x1b>, <&dmac1 0x1c>;
+ dma-names = "tx", "rx", "tx", "rx";
+ power-domains = <&sysc R8A7743_PD_ALWAYS_ON>;
+ status = "disabled";
+ };
+
+ scifa4: serial at e6c78000 {
+ compatible = "renesas,scifa-r8a7743",
+ "renesas,rcar-gen2-scifa", "renesas,scifa";
+ reg = <0 0xe6c78000 0 64>;
+ interrupts = <GIC_SPI 30 IRQ_TYPE_LEVEL_HIGH>;
+ clocks = <&mstp11_clks R8A7743_CLK_SCIFA4>;
+ clock-names = "fck";
+ dmas = <&dmac0 0x1f>, <&dmac0 0x20>,
+ <&dmac1 0x1f>, <&dmac1 0x20>;
+ dma-names = "tx", "rx", "tx", "rx";
+ power-domains = <&sysc R8A7743_PD_ALWAYS_ON>;
+ status = "disabled";
+ };
+
+ scifa5: serial at e6c80000 {
+ compatible = "renesas,scifa-r8a7743",
+ "renesas,rcar-gen2-scifa", "renesas,scifa";
+ reg = <0 0xe6c80000 0 64>;
+ interrupts = <GIC_SPI 31 IRQ_TYPE_LEVEL_HIGH>;
+ clocks = <&mstp11_clks R8A7743_CLK_SCIFA5>;
+ clock-names = "fck";
+ dmas = <&dmac0 0x23>, <&dmac0 0x24>,
+ <&dmac1 0x23>, <&dmac1 0x24>;
+ dma-names = "tx", "rx", "tx", "rx";
+ power-domains = <&sysc R8A7743_PD_ALWAYS_ON>;
+ status = "disabled";
+ };
+
+ scifb0: serial at e6c20000 {
+ compatible = "renesas,scifb-r8a7743",
+ "renesas,rcar-gen2-scifb", "renesas,scifb";
+ reg = <0 0xe6c20000 0 64>;
+ interrupts = <GIC_SPI 148 IRQ_TYPE_LEVEL_HIGH>;
+ clocks = <&mstp2_clks R8A7743_CLK_SCIFB0>;
+ clock-names = "fck";
+ dmas = <&dmac0 0x3d>, <&dmac0 0x3e>,
+ <&dmac1 0x3d>, <&dmac1 0x3e>;
+ dma-names = "tx", "rx", "tx", "rx";
+ power-domains = <&sysc R8A7743_PD_ALWAYS_ON>;
+ status = "disabled";
+ };
+
+ scifb1: serial at e6c30000 {
+ compatible = "renesas,scifb-r8a7743",
+ "renesas,rcar-gen2-scifb", "renesas,scifb";
+ reg = <0 0xe6c30000 0 64>;
+ interrupts = <GIC_SPI 149 IRQ_TYPE_LEVEL_HIGH>;
+ clocks = <&mstp2_clks R8A7743_CLK_SCIFB1>;
+ clock-names = "fck";
+ dmas = <&dmac0 0x19>, <&dmac0 0x1a>,
+ <&dmac1 0x19>, <&dmac1 0x1a>;
+ dma-names = "tx", "rx", "tx", "rx";
+ power-domains = <&sysc R8A7743_PD_ALWAYS_ON>;
+ status = "disabled";
+ };
+
+ scifb2: serial at e6ce0000 {
+ compatible = "renesas,scifb-r8a7743",
+ "renesas,rcar-gen2-scifb", "renesas,scifb";
+ reg = <0 0xe6ce0000 0 64>;
+ interrupts = <GIC_SPI 150 IRQ_TYPE_LEVEL_HIGH>;
+ clocks = <&mstp2_clks R8A7743_CLK_SCIFB2>;
+ clock-names = "fck";
+ dmas = <&dmac0 0x1d>, <&dmac0 0x1e>,
+ <&dmac1 0x1d>, <&dmac1 0x1e>;
+ dma-names = "tx", "rx", "tx", "rx";
+ power-domains = <&sysc R8A7743_PD_ALWAYS_ON>;
+ status = "disabled";
+ };
+
+ scif0: serial at e6e60000 {
+ compatible = "renesas,scif-r8a7743",
+ "renesas,rcar-gen2-scif", "renesas,scif";
+ reg = <0 0xe6e60000 0 64>;
+ interrupts = <GIC_SPI 152 IRQ_TYPE_LEVEL_HIGH>;
+ clocks = <&mstp7_clks R8A7743_CLK_SCIF0>, <&zs_clk>,
+ <&scif_clk>;
+ clock-names = "fck", "brg_int", "scif_clk";
+ dmas = <&dmac0 0x29>, <&dmac0 0x2a>,
+ <&dmac1 0x29>, <&dmac1 0x2a>;
+ dma-names = "tx", "rx", "tx", "rx";
+ power-domains = <&sysc R8A7743_PD_ALWAYS_ON>;
+ status = "disabled";
+ };
+
+ scif1: serial at e6e68000 {
+ compatible = "renesas,scif-r8a7743",
+ "renesas,rcar-gen2-scif", "renesas,scif";
+ reg = <0 0xe6e68000 0 64>;
+ interrupts = <GIC_SPI 153 IRQ_TYPE_LEVEL_HIGH>;
+ clocks = <&mstp7_clks R8A7743_CLK_SCIF1>, <&zs_clk>,
+ <&scif_clk>;
+ clock-names = "fck", "brg_int", "scif_clk";
+ dmas = <&dmac0 0x2d>, <&dmac0 0x2e>,
+ <&dmac1 0x2d>, <&dmac1 0x2e>;
+ dma-names = "tx", "rx", "tx", "rx";
+ power-domains = <&sysc R8A7743_PD_ALWAYS_ON>;
+ status = "disabled";
+ };
+
+ scif2: serial at e6e58000 {
+ compatible = "renesas,scif-r8a7743",
+ "renesas,rcar-gen2-scif", "renesas,scif";
+ reg = <0 0xe6e58000 0 64>;
+ interrupts = <GIC_SPI 22 IRQ_TYPE_LEVEL_HIGH>;
+ clocks = <&mstp7_clks R8A7743_CLK_SCIF2>, <&zs_clk>,
+ <&scif_clk>;
+ clock-names = "fck", "brg_int", "scif_clk";
+ dmas = <&dmac0 0x2b>, <&dmac0 0x2c>,
+ <&dmac1 0x2b>, <&dmac1 0x2c>;
+ dma-names = "tx", "rx", "tx", "rx";
+ power-domains = <&sysc R8A7743_PD_ALWAYS_ON>;
+ status = "disabled";
+ };
+
+ scif3: serial at e6ea8000 {
+ compatible = "renesas,scif-r8a7743",
+ "renesas,rcar-gen2-scif", "renesas,scif";
+ reg = <0 0xe6ea8000 0 64>;
+ interrupts = <GIC_SPI 23 IRQ_TYPE_LEVEL_HIGH>;
+ clocks = <&mstp7_clks R8A7743_CLK_SCIF3>, <&zs_clk>,
+ <&scif_clk>;
+ clock-names = "fck", "brg_int", "scif_clk";
+ dmas = <&dmac0 0x2f>, <&dmac0 0x30>,
+ <&dmac1 0x2f>, <&dmac1 0x30>;
+ dma-names = "tx", "rx", "tx", "rx";
+ power-domains = <&sysc R8A7743_PD_ALWAYS_ON>;
+ status = "disabled";
+ };
+
+ scif4: serial at e6ee0000 {
+ compatible = "renesas,scif-r8a7743",
+ "renesas,rcar-gen2-scif",
+ "renesas,scif";
+ reg = <0 0xe6ee0000 0 64>;
+ interrupts = <GIC_SPI 24 IRQ_TYPE_LEVEL_HIGH>;
+ clocks = <&mstp7_clks R8A7743_CLK_SCIF4>, <&zs_clk>,
+ <&scif_clk>;
+ clock-names = "fck", "brg_int", "scif_clk";
+ dmas = <&dmac0 0xfb>, <&dmac0 0xfc>,
+ <&dmac1 0xfb>, <&dmac1 0xfc>;
+ dma-names = "tx", "rx", "tx", "rx";
+ power-domains = <&sysc R8A7743_PD_ALWAYS_ON>;
+ status = "disabled";
+ };
+
+ scif5: serial at e6ee8000 {
+ compatible = "renesas,scif-r8a7743",
+ "renesas,rcar-gen2-scif", "renesas,scif";
+ reg = <0 0xe6ee8000 0 64>;
+ interrupts = <GIC_SPI 25 IRQ_TYPE_LEVEL_HIGH>;
+ clocks = <&mstp7_clks R8A7743_CLK_SCIF5>, <&zs_clk>,
+ <&scif_clk>;
+ clock-names = "fck", "brg_int", "scif_clk";
+ dmas = <&dmac0 0xfd>, <&dmac0 0xfe>,
+ <&dmac1 0xfd>, <&dmac1 0xfe>;
+ dma-names = "tx", "rx", "tx", "rx";
+ power-domains = <&sysc R8A7743_PD_ALWAYS_ON>;
+ status = "disabled";
+ };
+
+ hscif0: serial at e62c0000 {
+ compatible = "renesas,hscif-r8a7743",
+ "renesas,rcar-gen2-hscif", "renesas,hscif";
+ reg = <0 0xe62c0000 0 96>;
+ interrupts = <GIC_SPI 154 IRQ_TYPE_LEVEL_HIGH>;
+ clocks = <&mstp7_clks R8A7743_CLK_HSCIF0>, <&zs_clk>,
+ <&scif_clk>;
+ clock-names = "fck", "brg_int", "scif_clk";
+ dmas = <&dmac0 0x39>, <&dmac0 0x3a>,
+ <&dmac1 0x39>, <&dmac1 0x3a>;
+ dma-names = "tx", "rx", "tx", "rx";
+ power-domains = <&sysc R8A7743_PD_ALWAYS_ON>;
+ status = "disabled";
+ };
+
+ hscif1: serial at e62c8000 {
+ compatible = "renesas,hscif-r8a7743",
+ "renesas,rcar-gen2-hscif", "renesas,hscif";
+ reg = <0 0xe62c8000 0 96>;
+ interrupts = <GIC_SPI 155 IRQ_TYPE_LEVEL_HIGH>;
+ clocks = <&mstp7_clks R8A7743_CLK_HSCIF1>, <&zs_clk>,
+ <&scif_clk>;
+ clock-names = "fck", "brg_int", "scif_clk";
+ dmas = <&dmac0 0x4d>, <&dmac0 0x4e>,
+ <&dmac1 0x4d>, <&dmac1 0x4e>;
+ dma-names = "tx", "rx", "tx", "rx";
+ power-domains = <&sysc R8A7743_PD_ALWAYS_ON>;
+ status = "disabled";
+ };
+
+ hscif2: serial at e62d0000 {
+ compatible = "renesas,hscif-r8a7743",
+ "renesas,rcar-gen2-hscif", "renesas,hscif";
+ reg = <0 0xe62d0000 0 96>;
+ interrupts = <GIC_SPI 21 IRQ_TYPE_LEVEL_HIGH>;
+ clocks = <&mstp7_clks R8A7743_CLK_HSCIF2>, <&zs_clk>,
+ <&scif_clk>;
+ clock-names = "fck", "brg_int", "scif_clk";
+ dmas = <&dmac0 0x3b>, <&dmac0 0x3c>,
+ <&dmac1 0x3b>, <&dmac1 0x3c>;
+ dma-names = "tx", "rx", "tx", "rx";
+ power-domains = <&sysc R8A7743_PD_ALWAYS_ON>;
+ status = "disabled";
+ };
+
/* Special CPG clocks */
cpg_clocks: cpg_clocks at e6150000 {
compatible = "renesas,r8a7743-cpg-clocks",
^ permalink raw reply
* [PATCH v1 1/3] ARM: dts: imx6qdl-apalis: Do not rely on DDC I2C bus bitbang for HDMI
From: Marcel Ziswiler @ 2016-09-16 13:38 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <9d2c17aa2e00e6ff4349a53de8247860d2382607.1473833908.git.maitysanchayan@gmail.com>
On Wed, 2016-09-14 at 12:05 +0530, Sanchayan Maity wrote:
> Remove the use of DDC I2C bus bitbang to support reading of EDID
> and rely on support from internal HDMI I2C master controller instead.
> As a result remove the device tree property ddc-i2c-bus.
>
> Signed-off-by: Sanchayan Maity <maitysanchayan@gmail.com>
> ---
> Hello,
>
> This patch is tested with the following patch applied
> https://patchwork.kernel.org/patch/9296883/
>
> and is based on the suggestions from Vladimir
> https://lkml.org/lkml/2016/8/29/322
>
> This and following two patches are based on top of shawn's
> for-next branch.
>
> Regards,
> Sanchayan.
> ---
> ?arch/arm/boot/dts/imx6q-apalis-ixora.dts |??6 ------
> ?arch/arm/boot/dts/imx6qdl-apalis.dtsi????| 25 +++++++++-------------
> ---
> ?2 files changed, 9 insertions(+), 22 deletions(-)
>
> diff --git a/arch/arm/boot/dts/imx6q-apalis-ixora.dts
> b/arch/arm/boot/dts/imx6q-apalis-ixora.dts
> index 207b85b..d99979e 100644
> --- a/arch/arm/boot/dts/imx6q-apalis-ixora.dts
> +++ b/arch/arm/boot/dts/imx6q-apalis-ixora.dts
> @@ -55,7 +55,6 @@
> ? ?????"fsl,imx6q";
> ?
> ? aliases {
> - i2c0 = &i2cddc;
> ? i2c1 = &i2c1;
> ? i2c2 = &i2c2;
> ? i2c3 = &i2c3;
I would suggest rising them up in rank.
> @@ -186,11 +185,6 @@
> ?};
> ?
> ?&hdmi {
> - ddc-i2c-bus = <&i2cddc>;
> - status = "okay";
> -};
> -
> -&i2cddc {
> ? status = "okay";
> ?};
> ?
> diff --git a/arch/arm/boot/dts/imx6qdl-apalis.dtsi
> b/arch/arm/boot/dts/imx6qdl-apalis.dtsi
> index 99e323b..8c67dd8 100644
> --- a/arch/arm/boot/dts/imx6qdl-apalis.dtsi
> +++ b/arch/arm/boot/dts/imx6qdl-apalis.dtsi
> @@ -53,18 +53,6 @@
> ? status = "disabled";
> ? };
> ?
> - /* DDC_I2C: I2C2_SDA/SCL on MXM3 205/207 */
> - i2cddc: i2c at 0 {
> - compatible = "i2c-gpio";
> - pinctrl-names = "default";
> - pinctrl-0 = <&pinctrl_i2c_ddc>;
> - gpios = <&gpio3 16 GPIO_ACTIVE_HIGH /* sda */
> - ?&gpio2 30 GPIO_ACTIVE_HIGH /* scl */
> - >;
> - i2c-gpio,delay-us = <2>; /* ~100 kHz */
> - status = "disabled";
> - };
> -
> ? reg_1p8v: regulator-1p8v {
> ? compatible = "regulator-fixed";
> ? regulator-name = "1P8V";
> @@ -209,6 +197,12 @@
> ? };
> ?};
> ?
> +&hdmi {
> + pinctrl-names = "default";
> + pinctrl-0 = <&pinctrl_hdmi_ddc>;
> + status = "disabled";
> +};
> +
> ?/*
> ? * GEN1_I2C: I2C1_SDA/SCL on MXM3 209/211 (e.g. RTC on carrier
> ? * board)
> @@ -633,11 +627,10 @@
> ? >;
> ? };
> ?
> - pinctrl_i2c_ddc: gpioi2cddcgrp {
> + pinctrl_hdmi_ddc: hdmiddcgrp {
> ? fsl,pins = <
> - /* DDC bitbang */
> - MX6QDL_PAD_EIM_EB2__GPIO2_IO30 0x1b0b0
> - MX6QDL_PAD_EIM_D16__GPIO3_IO16 0x1b0b0
> + MX6QDL_PAD_EIM_EB2__HDMI_TX_DDC_SCL
> 0x4001b8b1
> + MX6QDL_PAD_EIM_D16__HDMI_TX_DDC_SDA
> 0x4001b8b1
> ? >;
> ? };
?
Rest looks fine and tested working fine on top of 4.8.0-rc6-next-20160916.
^ permalink raw reply
* [PATCH RFC 8/8] ARM: dts: sk-rzg1m: initial device tree
From: Sergei Shtylyov @ 2016-09-16 13:38 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <3533019.Wim1Kuh1ic@wasted.cogentembedded.com>
Add the initial device tree for the R8A7743 SoC based SK-RZG1M board.
The board has one debug serial port (SCIF0); include support for it, so
that the serial console can work.
Based on the original (and large) patch by Dmitry Shifrin
<dmitry.shifrin@cogentembedded.com>.
Signed-off-by: Sergei Shtylyov <sergei.shtylyov@cogentembedded.com>
---
arch/arm/boot/dts/Makefile | 1
arch/arm/boot/dts/r8a7743-sk-rzg1m.dts | 44 +++++++++++++++++++++++++++++++++
2 files changed, 45 insertions(+)
Index: renesas/arch/arm/boot/dts/Makefile
===================================================================
--- renesas.orig/arch/arm/boot/dts/Makefile
+++ renesas/arch/arm/boot/dts/Makefile
@@ -654,6 +654,7 @@ dtb-$(CONFIG_ARCH_SHMOBILE_MULTI) += \
r7s72100-rskrza1.dtb \
r8a73a4-ape6evm.dtb \
r8a7740-armadillo800eva.dtb \
+ r8a7743-sk-rzg1m.dtb \
r8a7778-bockw.dtb \
r8a7779-marzen.dtb \
r8a7790-lager.dtb \
Index: renesas/arch/arm/boot/dts/r8a7743-sk-rzg1m.dts
===================================================================
--- /dev/null
+++ renesas/arch/arm/boot/dts/r8a7743-sk-rzg1m.dts
@@ -0,0 +1,44 @@
+/*
+ * Device Tree Source for the SK-RZG1M board
+ *
+ * Copyright (C) 2016 Cogent Embedded, Inc.
+ *
+ * This file is licensed under the terms of the GNU General Public License
+ * version 2. This program is licensed "as is" without any warranty of any
+ * kind, whether express or implied.
+ */
+
+/dts-v1/;
+#include "r8a7743.dtsi"
+
+/ {
+ model = "SK-RZG1M";
+ compatible = "renesas,sk-rzg1m", "renesas,r8a7743";
+
+ aliases {
+ serial0 = &scif0;
+ };
+
+ chosen {
+ bootargs = "ignore_loglevel";
+ stdout-path = "serial0:115200n8";
+ };
+
+ memory at 40000000 {
+ device_type = "memory";
+ reg = <0 0x40000000 0 0x40000000>;
+ };
+
+ memory at 200000000 {
+ device_type = "memory";
+ reg = <2 0x00000000 0 0x40000000>;
+ };
+};
+
+&extal_clk {
+ clock-frequency = <20000000>;
+};
+
+&scif0 {
+ status = "okay";
+};
^ permalink raw reply
* [PATCH v1 2/3] ARM: dts: imx6q-apalis-ixora: Remove use of pwm-leds
From: Marcel Ziswiler @ 2016-09-16 13:38 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <6111feb57b5fbaa29eeb6ba089bb2824bbf2f8ff.1473833908.git.maitysanchayan@gmail.com>
On Wed, 2016-09-14 at 12:05 +0530, Sanchayan Maity wrote:
> Remove use of pwm-leds and use the standard /sys/class/pwm
> interface from PWM subsystem.
>
> Signed-off-by: Sanchayan Maity <maitysanchayan@gmail.com>
Acked-by: Marcel Ziswiler <marcel.ziswiler@toradex.com>
> ---
> ?arch/arm/boot/dts/imx6q-apalis-ixora.dts | 22 ----------------------
> ?1 file changed, 22 deletions(-)
>
> diff --git a/arch/arm/boot/dts/imx6q-apalis-ixora.dts
> b/arch/arm/boot/dts/imx6q-apalis-ixora.dts
> index d99979e..70a3da0 100644
> --- a/arch/arm/boot/dts/imx6q-apalis-ixora.dts
> +++ b/arch/arm/boot/dts/imx6q-apalis-ixora.dts
> @@ -146,28 +146,6 @@
> ? gpios = <&gpio2 2 GPIO_ACTIVE_HIGH>;
> ? };
> ? };
> -
> - pwmleds {
> - compatible = "pwm-leds";
> -
> - ledpwm1 {
> - label = "PWM1";
> - pwms = <&pwm1 0 50000>;
> - max-brightness = <255>;
> - };
> -
> - ledpwm2 {
> - label = "PWM2";
> - pwms = <&pwm2 0 50000>;
> - max-brightness = <255>;
> - };
> -
> - ledpwm3 {
> - label = "PWM3";
> - pwms = <&pwm3 0 50000>;
> - max-brightness = <255>;
> - };
> - };
> ?};
> ?
> ?&backlight {
Tested working fine analogous to what we documented for Vybrid:
http://developer.toradex.com/knowledge-base/pwm-(linux)#Colibri_VFxx
^ 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