* Applied "ASoC: sun4i-codec: Rename sun4i_codec_widgets for consistency" to the asoc tree
From: Mark Brown @ 2016-09-26 16:43 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20160915143922.4890-2-dannym@scratchpost.org>
The patch
ASoC: sun4i-codec: Rename sun4i_codec_widgets for consistency
has been applied to the asoc tree at
git://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound.git
All being well this means that it will be integrated into the linux-next
tree (usually sometime in the next 24 hours) and sent to Linus during
the next merge window (or sooner if it is a bug fix), however if
problems are discovered then the patch may be dropped or reverted.
You may get further e-mails resulting from automated or manual testing
and review of the tree, please engage with people reporting problems and
send followup patches addressing any issues that are reported if needed.
If any updates are required or you are submitting further changes they
should be sent as incremental updates against current git, existing
patches will not be replaced.
Please add any relevant lists and maintainers to the CCs when replying
to this mail.
Thanks,
Mark
>From c9e902f4b37a3c108eb5dc51f1340c09becd7232 Mon Sep 17 00:00:00 2001
From: Danny Milosavljevic <dannym@scratchpost.org>
Date: Sat, 24 Sep 2016 22:05:01 +0200
Subject: [PATCH] ASoC: sun4i-codec: Rename sun4i_codec_widgets for consistency
Rename "sun4i_codec_widgets" to "sun4i_codec_controls" for
consistency with the struct field name.
Signed-off-by: Danny Milosavljevic <dannym@scratchpost.org>
Acked-by: Maxime Ripard <maxime.ripard@free-electrons.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
---
sound/soc/sunxi/sun4i-codec.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/sound/soc/sunxi/sun4i-codec.c b/sound/soc/sunxi/sun4i-codec.c
index e51f363ff786..e047ec06d538 100644
--- a/sound/soc/sunxi/sun4i-codec.c
+++ b/sound/soc/sunxi/sun4i-codec.c
@@ -509,7 +509,7 @@ static const struct snd_kcontrol_new sun4i_codec_pa_mute =
static DECLARE_TLV_DB_SCALE(sun4i_codec_pa_volume_scale, -6300, 100, 1);
-static const struct snd_kcontrol_new sun4i_codec_widgets[] = {
+static const struct snd_kcontrol_new sun4i_codec_controls[] = {
SOC_SINGLE_TLV("Power Amplifier Volume", SUN4I_CODEC_DAC_ACTL,
SUN4I_CODEC_DAC_ACTL_PA_VOL, 0x3F, 0,
sun4i_codec_pa_volume_scale),
@@ -629,8 +629,8 @@ static const struct snd_soc_dapm_route sun4i_codec_codec_dapm_routes[] = {
static struct snd_soc_codec_driver sun4i_codec_codec = {
.component_driver = {
- .controls = sun4i_codec_widgets,
- .num_controls = ARRAY_SIZE(sun4i_codec_widgets),
+ .controls = sun4i_codec_controls,
+ .num_controls = ARRAY_SIZE(sun4i_codec_controls),
.dapm_widgets = sun4i_codec_codec_dapm_widgets,
.num_dapm_widgets = ARRAY_SIZE(sun4i_codec_codec_dapm_widgets),
.dapm_routes = sun4i_codec_codec_dapm_routes,
--
2.9.3
^ permalink raw reply related
* [PATCH 1/3] dt-bindings: Add a binding for the RPi firmware GPIO driver.
From: Stephen Warren @ 2016-09-26 16:40 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <87ponu931e.fsf@eliezer.anholt.net>
On 09/23/2016 07:08 AM, Eric Anholt wrote:
> Linus Walleij <linus.walleij@linaro.org> writes:
>
>> On Mon, Sep 19, 2016 at 6:13 PM, Eric Anholt <eric@anholt.net> wrote:
>>
>>> The RPi firmware exposes all of the board's GPIO lines through
>>> property calls. Linux chooses to control most lines directly through
>>> the pinctrl driver, but for the FXL6408 GPIO expander on the Pi3, we
>>> need to access them through the firmware.
>>>
>>> Signed-off-by: Eric Anholt <eric@anholt.net>
>>
>> Aha
>>
>>> +++ b/Documentation/devicetree/bindings/gpio/gpio-raspberrypi-firmware.txt
>>> @@ -0,0 +1,22 @@
>>> +Raspberry Pi power domain driver
>>
>> Really? :)
>
> Thanks.
>
>>> +Required properties:
>>> +
>>> +- compatible: Should be "raspberrypi,firmware-gpio"
>>
>> Usually this is vendor,compat, is the vendors name "raspberrypi"?
>
> Yes, this driver is for part of the Raspberry Pi Foundation's firmware
> code (you can find the same pattern in the firmware and firmware power
> domain drivers).
>
>>> +- gpio-controller: Marks the device node as a gpio controller
>>> +- #gpio-cells: Should be <2> for GPIO number and flags
>>> +- ngpios: Number of GPIO lines to control. See gpio.txt
>>
>> Is this ever anything else than 8? Else omit it and hardcode
>> 8 in the driver instead.
>
> (see below)
>
>>> +- firmware: Reference to the RPi firmware device node
>>
>> Reference the DT binding for this.
>>
>>> +- raspberrypi,firmware-gpio-offset:
>>> + Number the firmware uses for the first GPIO line
>>> + controlled by this driver
>>
>> Does this differ between different instances of this hardware or
>> can it just be open coded in the driver instead?
>
> This is which range (128-135) of the firmware's GPIOs we're controlling.
> If another GPIO expander appears later (quite believable, I think
> they're down to 1 spare line on this expander), then we would just make
> another node with a new offset and ngpios for that expander.
Why would we make another node for that? Wouldn't we always have a
single node to represent the FW's control over GPIOs, and have that node
expose all GPIOs that the FW supports. Which GPIO IDs clients actually
use will simply be determined by the HW schematic, and kernel-side SW
would just act as a conduit to pass those IDs between clients and the FW.
> Sort of related: I also worry that we have races with the firmware for
> the platform GPIO bits, since both ARM and firmware are doing RMWs (or,
> even worse, maybe just Ws?) of the registers controlled by the pinctrl
> driver. Hopefully I can get the firmware to pass control of devices
> like this over to Linux, with firmware making requests to us, but I
> don't know if that will happen and we may need to access other GPIOs
> using this interface :(
Aren't there write-to-set/write-to-clear registers? If not, then either
FW owns everything in a particular register or Linux does; the HW won't
allow sharing.
^ permalink raw reply
* [PATCH 1/1 v8] ARM: imx: Added perf functionality to mmdc driver
From: Zhi Li @ 2016-09-26 16:40 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1474307849-7341-1-git-send-email-Frank.Li@nxp.com>
On Mon, Sep 19, 2016 at 12:57 PM, Frank Li <Frank.Li@nxp.com> wrote:
> From: Zhengyu Shen <zhengyu.shen@nxp.com>
>
> MMDC is a multi-mode DDR controller that supports DDR3/DDR3L x16/x32/x64
> and LPDDR2 two channel x16/x32 memory types. MMDC is configurable, high
> performance, and optimized. MMDC is present on i.MX6 Quad and i.MX6
> QuadPlus devices, but this driver only supports i.MX6 Quad at the moment.
> MMDC provides registers for performance counters which read via this
> driver to help debug memory throughput and similar issues.
>
> $ perf stat -a -e mmdc/busy-cycles/,mmdc/read-accesses/,mmdc/read-bytes/,mmdc/total-cycles/,mmdc/write-accesses/,mmdc/write-bytes/ dd if=/dev/zero of=/dev/null bs=1M count=5000
> Performance counter stats for 'dd if=/dev/zero of=/dev/null bs=1M count=5000':
>
> 898021787 mmdc/busy-cycles/
> 14819600 mmdc/read-accesses/
> 471.30 MB mmdc/read-bytes/
> 2815419216 mmdc/total-cycles/
> 13367354 mmdc/write-accesses/
> 427.76 MB mmdc/write-bytes/
>
> 5.334757334 seconds time elapsed
>
> Signed-off-by: Zhengyu Shen <zhengyu.shen@nxp.com>
> Signed-off-by: Frank Li <frank.li@nxp.com>
> ---
Mark:
Any additional comments for this version?
best regards
Frank Li
> Changes from v7 to v8
> fix a group event check problem, should be slibling.
>
> Changes from v6 to v7
> use mmdc_pmu prefix
> remove unnecessary check
> improve group event check according to mark's feedback.
> check pmu_mmdc->mmdc_events[cfg] at event_add
> only check == 0 at event_del
>
> Changes from v5 to v6
> Improve group event error handle
>
> Changes from v4 to v5
> Remove mmdc_pmu:irq
> remove static variable cpuhp_mmdc_pmu
> remove spin_lock
> check is_sampling_event(event)
> remove unnecessary cast
> use hw_perf_event::prev_count
>
> Changes from v3 to v4:
> Tested and fixed crash relating to removing events with perf fuzzer
> Adjusted formatting
> Moved all perf event code under CONFIG_PERF_EVENTS
> Switched cpuhp_setup_state to cpuhp_setup_state_nocalls
>
> Changes from v2 to v3:
> Use WARN_ONCE instead of returning generic error values
> Replace CPU Notifiers with newer state machine hotplug
> Added additional checks on event_init for grouping and sampling
> Remove useless mmdc_enable_profiling function
> Added comments
> Moved start index of events from 0x01 to 0x00
> Added a counter to pmu_mmdc to only stop hrtimer after all events are finished
> Replace readl_relaxed and writel_relaxed with readl and writel
> Removed duplicate update function
> Used devm_kasprintf when naming mmdcs probed
>
> Changes from v1 to v2:
> Added cpumask and migration handling support to driver
> Validated event during event_init
> Added code to properly stop counters
> Used perf_invalid_context instead of perf_sw_context
> Added hrtimer to poll for overflow
> Added better description
> Added support for multiple mmdcs
>
> arch/arm/mach-imx/mmdc.c | 459 ++++++++++++++++++++++++++++++++++++++++++++++-
> 1 file changed, 457 insertions(+), 2 deletions(-)
>
> diff --git a/arch/arm/mach-imx/mmdc.c b/arch/arm/mach-imx/mmdc.c
> index db9621c..d82d14c 100644
> --- a/arch/arm/mach-imx/mmdc.c
> +++ b/arch/arm/mach-imx/mmdc.c
> @@ -1,5 +1,5 @@
> /*
> - * Copyright 2011 Freescale Semiconductor, Inc.
> + * Copyright 2011,2016 Freescale Semiconductor, Inc.
> * Copyright 2011 Linaro Ltd.
> *
> * The code contained herein is licensed under the GNU General Public
> @@ -10,12 +10,16 @@
> * http://www.gnu.org/copyleft/gpl.html
> */
>
> +#include <linux/hrtimer.h>
> #include <linux/init.h>
> +#include <linux/interrupt.h>
> #include <linux/io.h>
> #include <linux/module.h>
> #include <linux/of.h>
> #include <linux/of_address.h>
> #include <linux/of_device.h>
> +#include <linux/perf_event.h>
> +#include <linux/slab.h>
>
> #include "common.h"
>
> @@ -27,8 +31,458 @@
> #define BM_MMDC_MDMISC_DDR_TYPE 0x18
> #define BP_MMDC_MDMISC_DDR_TYPE 0x3
>
> +#define TOTAL_CYCLES 0x0
> +#define BUSY_CYCLES 0x1
> +#define READ_ACCESSES 0x2
> +#define WRITE_ACCESSES 0x3
> +#define READ_BYTES 0x4
> +#define WRITE_BYTES 0x5
> +
> +/* Enables, resets, freezes, overflow profiling*/
> +#define DBG_DIS 0x0
> +#define DBG_EN 0x1
> +#define DBG_RST 0x2
> +#define PRF_FRZ 0x4
> +#define CYC_OVF 0x8
> +
> +#define MMDC_MADPCR0 0x410
> +#define MMDC_MADPSR0 0x418
> +#define MMDC_MADPSR1 0x41C
> +#define MMDC_MADPSR2 0x420
> +#define MMDC_MADPSR3 0x424
> +#define MMDC_MADPSR4 0x428
> +#define MMDC_MADPSR5 0x42C
> +
> +#define MMDC_NUM_COUNTERS 6
> +
> +#define to_mmdc_pmu(p) container_of(p, struct mmdc_pmu, pmu)
> +
> static int ddr_type;
>
> +#ifdef CONFIG_PERF_EVENTS
> +
> +static DEFINE_IDA(mmdc_ida);
> +
> +PMU_EVENT_ATTR_STRING(total-cycles, mmdc_pmu_total_cycles, "event=0x00")
> +PMU_EVENT_ATTR_STRING(busy-cycles, mmdc_pmu_busy_cycles, "event=0x01")
> +PMU_EVENT_ATTR_STRING(read-accesses, mmdc_pmu_read_accesses, "event=0x02")
> +PMU_EVENT_ATTR_STRING(write-accesses, mmdc_pmu_write_accesses, "config=0x03")
> +PMU_EVENT_ATTR_STRING(read-bytes, mmdc_pmu_read_bytes, "event=0x04")
> +PMU_EVENT_ATTR_STRING(read-bytes.unit, mmdc_pmu_read_bytes_unit, "MB");
> +PMU_EVENT_ATTR_STRING(read-bytes.scale, mmdc_pmu_read_bytes_scale, "0.000001");
> +PMU_EVENT_ATTR_STRING(write-bytes, mmdc_pmu_write_bytes, "event=0x05")
> +PMU_EVENT_ATTR_STRING(write-bytes.unit, mmdc_pmu_write_bytes_unit, "MB");
> +PMU_EVENT_ATTR_STRING(write-bytes.scale, mmdc_pmu_write_bytes_scale, "0.000001");
> +
> +struct mmdc_pmu {
> + struct pmu pmu;
> + void __iomem *mmdc_base;
> + cpumask_t cpu;
> + struct hrtimer hrtimer;
> + unsigned int active_events;
> + struct device *dev;
> + struct perf_event *mmdc_events[MMDC_NUM_COUNTERS];
> + struct hlist_node node;
> +};
> +
> +/*
> + * Polling period is set to one second, overflow of total-cycles (the fastest
> + * increasing counter) takes ten seconds so one second is safe
> + */
> +static unsigned int mmdc_pmu_poll_period_us = 1000000;
> +
> +module_param_named(pmu_pmu_poll_period_us, mmdc_pmu_poll_period_us, uint,
> + S_IRUGO | S_IWUSR);
> +
> +static ktime_t mmdc_pmu_timer_period(void)
> +{
> + return ns_to_ktime((u64)mmdc_pmu_poll_period_us * 1000);
> +}
> +
> +static ssize_t mmdc_pmu_cpumask_show(struct device *dev,
> + struct device_attribute *attr, char *buf)
> +{
> + struct mmdc_pmu *pmu_mmdc = dev_get_drvdata(dev);
> +
> + return cpumap_print_to_pagebuf(true, buf, &pmu_mmdc->cpu);
> +}
> +
> +static struct device_attribute mmdc_pmu_cpumask_attr =
> + __ATTR(cpumask, S_IRUGO, mmdc_pmu_cpumask_show, NULL);
> +
> +static struct attribute *mmdc_pmu_cpumask_attrs[] = {
> + &mmdc_pmu_cpumask_attr.attr,
> + NULL,
> +};
> +
> +static struct attribute_group mmdc_pmu_cpumask_attr_group = {
> + .attrs = mmdc_pmu_cpumask_attrs,
> +};
> +
> +static struct attribute *mmdc_pmu_events_attrs[] = {
> + &mmdc_pmu_total_cycles.attr.attr,
> + &mmdc_pmu_busy_cycles.attr.attr,
> + &mmdc_pmu_read_accesses.attr.attr,
> + &mmdc_pmu_write_accesses.attr.attr,
> + &mmdc_pmu_read_bytes.attr.attr,
> + &mmdc_pmu_read_bytes_unit.attr.attr,
> + &mmdc_pmu_read_bytes_scale.attr.attr,
> + &mmdc_pmu_write_bytes.attr.attr,
> + &mmdc_pmu_write_bytes_unit.attr.attr,
> + &mmdc_pmu_write_bytes_scale.attr.attr,
> + NULL,
> +};
> +
> +static struct attribute_group mmdc_pmu_events_attr_group = {
> + .name = "events",
> + .attrs = mmdc_pmu_events_attrs,
> +};
> +
> +PMU_FORMAT_ATTR(event, "config:0-63");
> +static struct attribute *mmdc_pmu_format_attrs[] = {
> + &format_attr_event.attr,
> + NULL,
> +};
> +
> +static struct attribute_group mmdc_pmu_format_attr_group = {
> + .name = "format",
> + .attrs = mmdc_pmu_format_attrs,
> +};
> +
> +static const struct attribute_group *attr_groups[] = {
> + &mmdc_pmu_events_attr_group,
> + &mmdc_pmu_format_attr_group,
> + &mmdc_pmu_cpumask_attr_group,
> + NULL,
> +};
> +
> +static u32 mmdc_pmu_read_counter(struct mmdc_pmu *pmu_mmdc, int cfg)
> +{
> + void __iomem *mmdc_base, *reg;
> +
> + mmdc_base = pmu_mmdc->mmdc_base;
> +
> + switch (cfg) {
> + case TOTAL_CYCLES:
> + reg = mmdc_base + MMDC_MADPSR0;
> + break;
> + case BUSY_CYCLES:
> + reg = mmdc_base + MMDC_MADPSR1;
> + break;
> + case READ_ACCESSES:
> + reg = mmdc_base + MMDC_MADPSR2;
> + break;
> + case WRITE_ACCESSES:
> + reg = mmdc_base + MMDC_MADPSR3;
> + break;
> + case READ_BYTES:
> + reg = mmdc_base + MMDC_MADPSR4;
> + break;
> + case WRITE_BYTES:
> + reg = mmdc_base + MMDC_MADPSR5;
> + break;
> + default:
> + return WARN_ONCE(1,
> + "invalid configuration %d for mmdc counter", cfg);
> + }
> + return readl(reg);
> +}
> +
> +static int mmdc_pmu_offline_cpu(unsigned int cpu, struct hlist_node *node)
> +{
> + struct mmdc_pmu *pmu_mmdc = hlist_entry_safe(node, struct mmdc_pmu, node);
> + int target;
> +
> + if (!cpumask_test_and_clear_cpu(cpu, &pmu_mmdc->cpu))
> + return 0;
> +
> + target = cpumask_any_but(cpu_online_mask, cpu);
> + if (target >= nr_cpu_ids)
> + return 0;
> +
> + perf_pmu_migrate_context(&pmu_mmdc->pmu, cpu, target);
> + cpumask_set_cpu(target, &pmu_mmdc->cpu);
> +
> + return 0;
> +}
> +
> +static bool mmdc_pmu_group_event_is_valid(struct perf_event *event,
> + struct pmu *pmu,
> + unsigned long *used_counters)
> +{
> + int cfg = event->attr.config;
> +
> + if (is_software_event(event))
> + return true;
> +
> + if (event->pmu != pmu)
> + return false;
> +
> + return !test_and_set_bit(cfg, used_counters);
> +}
> +
> +/*
> + * Each event has a single fixed-purpose counter, so we can only have a
> + * single active event for each at any point in time. Here we just check
> + * for duplicates, and rely on mmdc_pmu_event_init to verify that the HW
> + * event numbers are valid.
> + */
> +static bool mmdc_pmu_group_is_valid(struct perf_event *event)
> +{
> + struct pmu *pmu = event->pmu;
> + struct perf_event *leader = event->group_leader;
> + struct perf_event *sibling;
> + unsigned long counter_mask = 0;
> +
> + set_bit(leader->attr.config, &counter_mask);
> +
> + if (event != leader) {
> + if (!mmdc_pmu_group_event_is_valid(event, pmu, &counter_mask))
> + return false;
> + }
> +
> + list_for_each_entry(sibling, &leader->sibling_list, group_entry) {
> + if (!mmdc_pmu_group_event_is_valid(sibling, pmu, &counter_mask))
> + return false;
> + }
> +
> + return true;
> +}
> +
> +static int mmdc_pmu_event_init(struct perf_event *event)
> +{
> + struct mmdc_pmu *pmu_mmdc = to_mmdc_pmu(event->pmu);
> + int cfg = event->attr.config;
> +
> + if (event->attr.type != event->pmu->type)
> + return -ENOENT;
> +
> + if (is_sampling_event(event) || event->attach_state & PERF_ATTACH_TASK)
> + return -EOPNOTSUPP;
> +
> + if (event->cpu < 0) {
> + dev_warn(pmu_mmdc->dev, "Can't provide per-task data!\n");
> + return -EOPNOTSUPP;
> + }
> +
> + if (event->attr.exclude_user ||
> + event->attr.exclude_kernel ||
> + event->attr.exclude_hv ||
> + event->attr.exclude_idle ||
> + event->attr.exclude_host ||
> + event->attr.exclude_guest ||
> + event->attr.sample_period)
> + return -EINVAL;
> +
> + if (cfg < 0 || cfg >= MMDC_NUM_COUNTERS)
> + return -EINVAL;
> +
> + if (!mmdc_pmu_group_is_valid(event))
> + return -EINVAL;
> +
> + event->cpu = cpumask_first(&pmu_mmdc->cpu);
> + return 0;
> +}
> +
> +static void mmdc_pmu_event_update(struct perf_event *event)
> +{
> + struct mmdc_pmu *pmu_mmdc = to_mmdc_pmu(event->pmu);
> + struct hw_perf_event *hwc = &event->hw;
> + u64 delta, prev_raw_count, new_raw_count;
> +
> + do {
> + prev_raw_count = local64_read(&hwc->prev_count);
> + new_raw_count = mmdc_pmu_read_counter(pmu_mmdc,
> + event->attr.config);
> + } while (local64_cmpxchg(&hwc->prev_count, prev_raw_count,
> + new_raw_count) != prev_raw_count);
> +
> + delta = (new_raw_count - prev_raw_count) & 0xFFFFFFFF;
> +
> + local64_add(delta, &event->count);
> +}
> +
> +static void mmdc_pmu_event_start(struct perf_event *event, int flags)
> +{
> + struct mmdc_pmu *pmu_mmdc = to_mmdc_pmu(event->pmu);
> + struct hw_perf_event *hwc = &event->hw;
> + void __iomem *mmdc_base, *reg;
> +
> + mmdc_base = pmu_mmdc->mmdc_base;
> + reg = mmdc_base + MMDC_MADPCR0;
> +
> + /*
> + * hrtimer is required because mmdc does not provide an interrupt so
> + * polling is necessary
> + */
> + hrtimer_start(&pmu_mmdc->hrtimer, mmdc_pmu_timer_period(),
> + HRTIMER_MODE_REL_PINNED);
> +
> + local64_set(&hwc->prev_count, 0);
> +
> + writel(DBG_RST, reg);
> + writel(DBG_EN, reg);
> +}
> +
> +static int mmdc_pmu_event_add(struct perf_event *event, int flags)
> +{
> + struct mmdc_pmu *pmu_mmdc = to_mmdc_pmu(event->pmu);
> + struct hw_perf_event *hwc = &event->hw;
> +
> + int cfg = event->attr.config;
> +
> + if (flags & PERF_EF_START)
> + mmdc_pmu_event_start(event, flags);
> +
> + if (pmu_mmdc->mmdc_events[cfg] != NULL)
> + return -EAGAIN;
> +
> + pmu_mmdc->mmdc_events[cfg] = event;
> + pmu_mmdc->active_events++;
> +
> + local64_set(&hwc->prev_count, mmdc_pmu_read_counter(pmu_mmdc, cfg));
> +
> + return 0;
> +}
> +
> +static void mmdc_pmu_event_stop(struct perf_event *event, int flags)
> +{
> + struct mmdc_pmu *pmu_mmdc = to_mmdc_pmu(event->pmu);
> + void __iomem *mmdc_base, *reg;
> +
> + mmdc_base = pmu_mmdc->mmdc_base;
> + reg = mmdc_base + MMDC_MADPCR0;
> +
> + writel(PRF_FRZ, reg);
> + mmdc_pmu_event_update(event);
> +}
> +
> +static void mmdc_pmu_event_del(struct perf_event *event, int flags)
> +{
> + struct mmdc_pmu *pmu_mmdc = to_mmdc_pmu(event->pmu);
> + int cfg = event->attr.config;
> +
> + pmu_mmdc->mmdc_events[cfg] = NULL;
> + pmu_mmdc->active_events--;
> +
> + if (pmu_mmdc->active_events == 0)
> + hrtimer_cancel(&pmu_mmdc->hrtimer);
> +
> + mmdc_pmu_event_stop(event, PERF_EF_UPDATE);
> +}
> +
> +static void mmdc_pmu_overflow_handler(struct mmdc_pmu *pmu_mmdc)
> +{
> + int i;
> +
> + for (i = 0; i < MMDC_NUM_COUNTERS; i++) {
> + struct perf_event *event = pmu_mmdc->mmdc_events[i];
> +
> + if (event)
> + mmdc_pmu_event_update(event);
> + }
> +}
> +
> +static enum hrtimer_restart mmdc_pmu_timer_handler(struct hrtimer *hrtimer)
> +{
> + struct mmdc_pmu *pmu_mmdc = container_of(hrtimer, struct mmdc_pmu,
> + hrtimer);
> +
> + mmdc_pmu_overflow_handler(pmu_mmdc);
> + hrtimer_forward_now(hrtimer, mmdc_pmu_timer_period());
> +
> + return HRTIMER_RESTART;
> +}
> +
> +static int mmdc_pmu_init(struct mmdc_pmu *pmu_mmdc,
> + void __iomem *mmdc_base, struct device *dev)
> +{
> + int mmdc_num;
> +
> + *pmu_mmdc = (struct mmdc_pmu) {
> + .pmu = (struct pmu) {
> + .task_ctx_nr = perf_invalid_context,
> + .attr_groups = attr_groups,
> + .event_init = mmdc_pmu_event_init,
> + .add = mmdc_pmu_event_add,
> + .del = mmdc_pmu_event_del,
> + .start = mmdc_pmu_event_start,
> + .stop = mmdc_pmu_event_stop,
> + .read = mmdc_pmu_event_update,
> + },
> + .mmdc_base = mmdc_base,
> + .dev = dev,
> + .active_events = 0,
> + };
> +
> + mmdc_num = ida_simple_get(&mmdc_ida, 0, 0, GFP_KERNEL);
> +
> + return mmdc_num;
> +}
> +
> +static int imx_mmdc_remove(struct platform_device *pdev)
> +{
> + struct mmdc_pmu *pmu_mmdc = platform_get_drvdata(pdev);
> +
> + perf_pmu_unregister(&pmu_mmdc->pmu);
> + cpuhp_remove_state_nocalls(CPUHP_ONLINE);
> + kfree(pmu_mmdc);
> + return 0;
> +}
> +
> +static int imx_mmdc_perf_init(struct platform_device *pdev, void __iomem *mmdc_base)
> +{
> + struct mmdc_pmu *pmu_mmdc;
> + char *name;
> + int mmdc_num;
> + int ret;
> +
> + pmu_mmdc = kzalloc(sizeof(*pmu_mmdc), GFP_KERNEL);
> + if (!pmu_mmdc) {
> + pr_err("failed to allocate PMU device!\n");
> + return -ENOMEM;
> + }
> +
> + mmdc_num = mmdc_pmu_init(pmu_mmdc, mmdc_base, &pdev->dev);
> + if (mmdc_num == 0)
> + name = "mmdc";
> + else
> + name = devm_kasprintf(&pdev->dev,
> + GFP_KERNEL, "mmdc%d", mmdc_num);
> +
> + hrtimer_init(&pmu_mmdc->hrtimer, CLOCK_MONOTONIC,
> + HRTIMER_MODE_REL);
> + pmu_mmdc->hrtimer.function = mmdc_pmu_timer_handler;
> +
> + cpuhp_state_add_instance_nocalls(CPUHP_ONLINE,
> + &pmu_mmdc->node);
> + cpumask_set_cpu(smp_processor_id(), &pmu_mmdc->cpu);
> + ret = cpuhp_setup_state_multi(CPUHP_AP_NOTIFY_ONLINE,
> + "MMDC_ONLINE", NULL,
> + mmdc_pmu_offline_cpu);
> + if (ret) {
> + pr_err("cpuhp_setup_state_multi failure\n");
> + goto pmu_register_err;
> + }
> +
> + ret = perf_pmu_register(&(pmu_mmdc->pmu), name, -1);
> + platform_set_drvdata(pdev, pmu_mmdc);
> + if (ret)
> + goto pmu_register_err;
> + return 0;
> +
> +pmu_register_err:
> + pr_warn("MMDC Perf PMU failed (%d), disabled\n", ret);
> + hrtimer_cancel(&pmu_mmdc->hrtimer);
> + kfree(pmu_mmdc);
> + return ret;
> +}
> +
> +#else
> +#define imx_mmdc_remove NULL
> +#define imx_mmdc_perf_init(pdev, mmdc_base) 0
> +#endif
> +
> static int imx_mmdc_probe(struct platform_device *pdev)
> {
> struct device_node *np = pdev->dev.of_node;
> @@ -62,7 +516,7 @@ static int imx_mmdc_probe(struct platform_device *pdev)
> return -EBUSY;
> }
>
> - return 0;
> + return imx_mmdc_perf_init(pdev, mmdc_base);
> }
>
> int imx_mmdc_get_ddr_type(void)
> @@ -81,6 +535,7 @@ static struct platform_driver imx_mmdc_driver = {
> .of_match_table = imx_mmdc_dt_ids,
> },
> .probe = imx_mmdc_probe,
> + .remove = imx_mmdc_remove,
> };
>
> static int __init imx_mmdc_init(void)
> --
> 2.5.2
>
^ permalink raw reply
* [PATCH 1/3] dt-bindings: Add a binding for the RPi firmware GPIO driver.
From: Stephen Warren @ 2016-09-26 16:38 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1903581972.81288.e9d48a65-997b-4986-a9d0-10632895df40.open-xchange@email.1und1.de>
On 09/23/2016 12:39 PM, Stefan Wahren wrote:
> Hi Eric,
>
>> Eric Anholt <eric@anholt.net> hat am 19. September 2016 um 18:13 geschrieben:
>>
>>
>> The RPi firmware exposes all of the board's GPIO lines through
>> property calls. Linux chooses to control most lines directly through
>> the pinctrl driver, but for the FXL6408 GPIO expander on the Pi3, we
>> need to access them through the firmware.
>>
>> Signed-off-by: Eric Anholt <eric@anholt.net>
>> ---
>> .../bindings/gpio/gpio-raspberrypi-firmware.txt | 22
>> ++++++++++++++++++++++
>> 1 file changed, 22 insertions(+)
>> create mode 100644
>> Documentation/devicetree/bindings/gpio/gpio-raspberrypi-firmware.txt
>>
>> diff --git
>> a/Documentation/devicetree/bindings/gpio/gpio-raspberrypi-firmware.txt
>> b/Documentation/devicetree/bindings/gpio/gpio-raspberrypi-firmware.txt
>> new file mode 100644
>> index 000000000000..2b635c23a6f8
>> --- /dev/null
>> +++ b/Documentation/devicetree/bindings/gpio/gpio-raspberrypi-firmware.txt
>> @@ -0,0 +1,22 @@
>> +Raspberry Pi power domain driver
>> +
>> +Required properties:
>> +
>> +- compatible: Should be "raspberrypi,firmware-gpio"
>
> i think the compatible should be more specific like
>
> raspberrypi,rpi3-firmware-gpio
>
> and all information which aren't requestable from the firmware should be stored
> in a info structure. This makes the driver easier to extend in the future by
> adding new compatibles and their info structures.
Is this actually specific to the Pi3 at all? Isn't the FW the same
across all Pis; the part that's specific to the Pi3 is whether it's
useful to use that API?
As such, I'd suggest just raspberrypi,firmware-gpio as the compatible value.
^ permalink raw reply
* [linux-sunxi] [PATCH v6 0/3] ASoC: sun4i-codec: Distinguish sun4i from sun7i
From: Mark Brown @ 2016-09-26 16:33 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20160925100827.5dc3240d@scratchpost.org>
On Sun, Sep 25, 2016 at 10:08:27AM +0200, Danny Milosavljevic wrote:
Please fix your mail client to word wrap within paragraphs at something
substantially less than 80 columns. Doing this makes your messages much
easier to read and reply to.
> I see that the v5 patches 2 and 3 have already been applied in the mean time - and the functional content in v6 is identical.
> Therefore, the only thing that needs to be looked at is patch 1 - where I modified the commit message only compared to v5.
Please do not submit new versions of already applied patches, please
submit incremental updates to the existing code. Modifying existing
commits creates problems for other users building on top of those
commits so it's best practice to only change pubished git commits if
absolutely essential.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 455 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20160926/98dad3ce/attachment-0001.sig>
^ permalink raw reply
* Applied "ASoC: rk3399_gru_sound: fix recording pop at first attempt" to the asoc tree
From: Mark Brown @ 2016-09-26 16:15 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1474552206-31742-1-git-send-email-zhengxing@rock-chips.com>
The patch
ASoC: rk3399_gru_sound: fix recording pop at first attempt
has been applied to the asoc tree at
git://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound.git
All being well this means that it will be integrated into the linux-next
tree (usually sometime in the next 24 hours) and sent to Linus during
the next merge window (or sooner if it is a bug fix), however if
problems are discovered then the patch may be dropped or reverted.
You may get further e-mails resulting from automated or manual testing
and review of the tree, please engage with people reporting problems and
send followup patches addressing any issues that are reported if needed.
If any updates are required or you are submitting further changes they
should be sent as incremental updates against current git, existing
patches will not be replaced.
Please add any relevant lists and maintainers to the CCs when replying
to this mail.
Thanks,
Mark
>From 3a6f9dce6116cc54e31dc10d176ceecb1a7e4e7f Mon Sep 17 00:00:00 2001
From: Wonjoon Lee <woojoo.lee@samsung.com>
Date: Thu, 22 Sep 2016 21:50:06 +0800
Subject: [PATCH] ASoC: rk3399_gru_sound: fix recording pop at first attempt
Pop happens when mclk applied but dmic's own boot-time
Specify dmic delay times in dt to make sure
clocks are ready earlier than dmic working
Signed-off-by: Wonjoon Lee <woojoo.lee@samsung.com>
Signed-off-by: Xing Zheng <zhengxing@rock-chips.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
---
.../bindings/sound/rockchip,rk3399-gru-sound.txt | 7 +++++++
sound/soc/rockchip/rk3399_gru_sound.c | 14 ++++++++++++++
2 files changed, 21 insertions(+)
diff --git a/Documentation/devicetree/bindings/sound/rockchip,rk3399-gru-sound.txt b/Documentation/devicetree/bindings/sound/rockchip,rk3399-gru-sound.txt
index f19b6c830a34..eac91db07178 100644
--- a/Documentation/devicetree/bindings/sound/rockchip,rk3399-gru-sound.txt
+++ b/Documentation/devicetree/bindings/sound/rockchip,rk3399-gru-sound.txt
@@ -6,10 +6,17 @@ Required properties:
connected to the codecs
- rockchip,codec: The phandle of the MAX98357A/RT5514/DA7219 codecs
+Optional properties:
+- dmic-wakeup-delay-ms : specify delay time (ms) for DMIC ready.
+ If this option is specified, which means it's required dmic need
+ delay for DMIC to ready so that rt5514 can avoid recording before
+ DMIC send valid data
+
Example:
sound {
compatible = "rockchip,rk3399-gru-sound";
rockchip,cpu = <&i2s0>;
rockchip,codec = <&max98357a &rt5514 &da7219>;
+ dmic-wakeup-delay-ms = <20>;
};
diff --git a/sound/soc/rockchip/rk3399_gru_sound.c b/sound/soc/rockchip/rk3399_gru_sound.c
index ee0648927afc..9ed735a6cf49 100644
--- a/sound/soc/rockchip/rk3399_gru_sound.c
+++ b/sound/soc/rockchip/rk3399_gru_sound.c
@@ -38,6 +38,8 @@
#define SOUND_FS 256
+unsigned int rt5514_dmic_delay;
+
static struct snd_soc_jack rockchip_sound_jack;
static const struct snd_soc_dapm_widget rockchip_dapm_widgets[] = {
@@ -123,6 +125,9 @@ static int rockchip_sound_rt5514_hw_params(struct snd_pcm_substream *substream,
return ret;
}
+ /* Wait for DMIC stable */
+ msleep(rt5514_dmic_delay);
+
return 0;
}
@@ -343,6 +348,15 @@ static int rockchip_sound_probe(struct platform_device *pdev)
return -ENODEV;
}
+ /* Set DMIC delay */
+ ret = device_property_read_u32(&pdev->dev, "dmic-delay",
+ &rt5514_dmic_delay);
+ if (ret) {
+ rt5514_dmic_delay = 0;
+ dev_dbg(&pdev->dev,
+ "no optional property 'dmic-delay' found, default: no delay\n");
+ }
+
rockchip_dailinks[DAILINK_RT5514_DSP].cpu_name = kstrdup_const(dev_name(dev), GFP_KERNEL);
rockchip_dailinks[DAILINK_RT5514_DSP].cpu_dai_name = kstrdup_const(dev_name(dev), GFP_KERNEL);
rockchip_dailinks[DAILINK_RT5514_DSP].platform_name = kstrdup_const(dev_name(dev), GFP_KERNEL);
--
2.9.3
^ permalink raw reply related
* [RFC PATCH 0/3] efi: MMC proxy support for the UEFI varstore
From: Mark Rutland @ 2016-09-26 15:53 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20160922125854.GC26596@leverpostej>
On Thu, Sep 22, 2016 at 01:58:54PM +0100, Mark Rutland wrote:
> On Thu, Sep 22, 2016 at 12:30:03PM +0100, Ard Biesheuvel wrote:
> > This series proposes an approach to work around this. It implements the UEFI
> > MMC host protocol in the kernel, in a way that makes it possible to expose it
> > to the firmware. At the same time, the firmware needs be set up for this, i.e.,
> > it needs to expose its MMC host protocol pointer via a UEFI configuration table,
> > so that the kernel can override it if it decides to expose this functionality
> > to the firmware.
>
> At a high level, and assuming a number of details from previous
> discussions, I think the general approach of having the kernel mediate
> access to the MMC makes sense.
> I have a few other general concerns:
Another few thoughts I had:
* The UEFI spec mandates that a certain amount of stack space is available to
runtime services which we call. If UEFI can call back into the kernel, it's
not clear how much of the stack is available to either UEFI or the kernel.
This is a rather fragile area -- kernel stack usage can vary wildly depending
on configuration options.
* CPU state management. Runtime services can temporarily mask interrupts, and
may require interrupts to remain masked over calls back into the kernel. That
and other concerns mean that deadlock is going to be very difficult to avoid.
* It gets in the way of (though doesn't strictly prevent) sandboxing. One thing
I'd like to do is run UEFI services in a more restricted environment (e.g. a
VM if we have EL2 available), to aid robustness and debugging. Having a single
entry/exit point, and not having to proxy calls would make this far simpler.
Overall, I'd far prefer that we have a strict one-way call policy (as is the
case today with UEFI), even if that means we have to make a number of calls to
achieve some functionality. In addition to the above, that also sidesteps the
lifetime issues I mentioned previously (modulo some FW-side state retained
across kexec and so on).
Thanks,
Mark.
^ permalink raw reply
* [PATCHv2 0/2] net: fec: Reset ethernet PHY whenever the enet_out clock is being enabled
From: Jörg Krause @ 2016-09-26 15:37 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20160112203002.GZ24441@pengutronix.de>
Hi all,
On Tue, 2016-01-12 at 21:30 +0100, Uwe Kleine-K?nig wrote:
> Hello,
>
> On Tue, Jan 12, 2016 at 05:04:44PM +0100, Lothar Wa?mann wrote:
> >
> > >
> > > On Tue, Jan 12, 2016 at 04:17:54PM +0100, Lothar Wa?mann wrote:
> > > >
> > > > This patchset fixes a regression introduced by
> > > > commit e8fcfcd5684a ("net: fec: optimize the clock management
> > > > to save power")
> > > > for ethernet PHYs that are using ENET_OUT as reference clock
> > > > (on i.MX6 or i.MX28)
> > > >
> > > > Changes vs. v1:
> > > > - fixed reference to the commit that introduced the regression.
> > > > - dropped patch to use gpiod framework. This should be added
> > > > later,
> > > > ? after the affected DTBs have been updated to specify the
> > > > correct
> > > > ? gpio_flags.
> > > >
> > > > Patch overview:
> > > > 1. cleanup patch to remove redundant NULL checks
> > > > 2. call fec_reset_phy() after the ENET_OUT clock has been
> > > > enabled
> > >
> > > I definitely want to test these on my SolidRun boards before
> > > these get
> > > merged: the AR8035 on there is configured via pin-straps, and
> > > then
> > > further tweaked with PHY quirks.??Resetting with the iMX6 in the
> > > wrong state may result in the AR8035 being reconfigured (even
> > > jumping
> > > to a different MDIO address) and certainly would need the PHY
> > > quirks
> > > re-running.
> > >
> > As far as I can tell, all SolidRun boards do not specify the
> > enet_out
> > clock in the dtb, so the PHY reset behaviour should be unaffected
> > by
> > this patch on those boards, since the additional fec_reset_phy()
> > call is
> > framed by:
> > if (fep->clk_enet_out) {
> > ...
> > }
> >
> > But verifying this explicitly is of course a good idea.
>
> If the SolidRun boards don't do this, this doesn't mean it's safe in
> general. The problem is real, isn't it?
Anything new on this topic? I am facing the same issue with Linux
Kernel 4.7 and the MCSC LAN8720A on an i.MX28 board.
I found this patch on patchwork and it works for me.
Best regard
J?rg Krause
^ permalink raw reply
* [PATCH v2] ARM/dt: Respect property size when parsing CPUs
From: Russell King - ARM Linux @ 2016-09-26 15:19 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <7955b34dcafcc20829c0521c0a0371c27d102f1f.1474898916.git.robin.murphy@arm.com>
On Mon, Sep 26, 2016 at 03:25:24PM +0100, Robin Murphy wrote:
> Whilst MPIDR values themselves are less than 32 bits, it is still
> perfectly valid for a DT to have #address-cells > 1 in the CPUs node,
> resulting in the "reg" property having leading zero cell(s). In that
> situation, the big-endian nature of the data conspires with the current
> behaviour of only reading the first cell to cause the kernel to think
> all CPUs have ID 0, and become resoundingly unhappy as a consequence.
>
> Take the full property length into account when parsing CPUs so as to
> be correct under any circumstances.
Please drop this into the patch system, thanks.
--
RMK's Patch system: http://www.armlinux.org.uk/developer/patches/
FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up
according to speedtest.net.
^ permalink raw reply
* [PATCH] serial: imx: Fix DCD reading
From: Fabio Estevam @ 2016-09-26 15:08 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAOMZO5B0Dkx8NTJPrNwR4WE1JJQEY1vczV=d1OtROzzDOGfQAQ@mail.gmail.com>
On Mon, Sep 26, 2016 at 11:28 AM, Fabio Estevam <festevam@gmail.com> wrote:
> Hi Uwe,
>
> On Mon, Sep 26, 2016 at 11:25 AM, Uwe Kleine-K?nig
> <u.kleine-koenig@pengutronix.de> wrote:
>
>>> Great, so it affects 4.5+ kernels and should probably have:
>>>
>>> Cc: <stable@vger.kernel.org> # 4.5+
>>
>> This is usually not necessary if there is a Fixes: line.
>
> I thought Greg prefers the explicit Cc: stable line as documented in
> Documentation/stable_kernel_rules.txt.
>
> Greg?
Ok, in this previous discussion Greg stated that he prefers Cc: stable
to be present:
http://www.spinics.net/lists/linux-gpio/msg10659.html
^ permalink raw reply
* [PATCH] ARM: dts: gose: use generic pinctrl properties in SDHI nodes
From: Simon Horman @ 2016-09-26 14:55 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1474020294-1544-1-git-send-email-horms+renesas@verge.net.au>
On Fri, Sep 16, 2016 at 12:04:54PM +0200, Simon Horman wrote:
> Since 16ccaf5bb5a5 ("pinctrl: sh-pfc: Accept standard function, pins and
> groups properties") renesas pfc drivers accept generic "function", "pins"
> and "groups" properties.
>
> Signed-off-by: Simon Horman <horms+renesas@verge.net.au>
I have queued this up.
^ permalink raw reply
* [PATCH] ARM: shmobile: Sort Kconfig selections
From: Simon Horman @ 2016-09-26 14:48 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1474619320-28888-1-git-send-email-geert+renesas@glider.be>
On Fri, Sep 23, 2016 at 10:28:40AM +0200, Geert Uytterhoeven wrote:
> Sort alphabetically all symbols selected by ARCH_RENESAS
>
> Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
Thanks, I have queued this up.
^ permalink raw reply
* [PATCH v4 2/5] ARM: dts: imx6q: Add Engicam i.CoreM6 Quad/Dual initial support
From: Jagan Teki @ 2016-09-26 14:28 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAOf5uwk3FJ4K4gL8xNNAp-z_AesjwTwSz986gfveVJsOU+N8Ow@mail.gmail.com>
Hi Fabio,
On Mon, Sep 26, 2016 at 7:26 PM, Michael Trimarchi
<michael@amarulasolutions.com> wrote:
> Hi
>
> On Mon, Sep 26, 2016 at 3:55 PM, Fabio Estevam <festevam@gmail.com> wrote:
>> On Mon, Sep 26, 2016 at 10:54 AM, Michael Trimarchi
>> <michael@amarulasolutions.com> wrote:
>>
>>>> Why don't you simply do like this?
>>>>
>>>> reg_3p3v: regulator-3p3v {
>>>> compatible = "regulator-fixed";
>>>> regulator-name = "3P3V";
>>>> regulator-min-microvolt = <3300000>;
>>>> regulator-max-microvolt = <3300000>;
>>>> };
>>>
>>> Should dts rispect the schematic connection?
>>
>> Yes
>
> So boot on and always on are used to declare their status and their
> behavionr. I don't
> see the point to not specify them in this way
Please try to understand that due to the case where we used fixed
voltage regulators on SOM as mentioned By Metteo and Michael dt nodes
should have regulator-always-on and regulator-boot-on properties. And
even we added one of our module which is already in ML[1]
Hope this is helpful conclude this thread.
[1] http://git.kernel.org/cgit/linux/kernel/git/next/linux-next.git/commit/?id=a58e4e608bc88735581fdd9861676e522fa3c20d
thanks!
--
Jagan Teki
Free Software Engineer | Amarula Solutions
U-Boot, Linux | Upstream Maintainer
Hyderabad, India.
^ permalink raw reply
* [PATCH] serial: imx: Fix DCD reading
From: Fabio Estevam @ 2016-09-26 14:28 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20160926142506.ix53ekhykp2svodu@pengutronix.de>
Hi Uwe,
On Mon, Sep 26, 2016 at 11:25 AM, Uwe Kleine-K?nig
<u.kleine-koenig@pengutronix.de> wrote:
>> Great, so it affects 4.5+ kernels and should probably have:
>>
>> Cc: <stable@vger.kernel.org> # 4.5+
>
> This is usually not necessary if there is a Fixes: line.
I thought Greg prefers the explicit Cc: stable line as documented in
Documentation/stable_kernel_rules.txt.
Greg?
^ permalink raw reply
* [PATCH v2] ARM/dt: Respect property size when parsing CPUs
From: Robin Murphy @ 2016-09-26 14:25 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <31c4684aa8ef7ef210cc74da5f1b02ff2882a099.1474645829.git.robin.murphy@arm.com>
Whilst MPIDR values themselves are less than 32 bits, it is still
perfectly valid for a DT to have #address-cells > 1 in the CPUs node,
resulting in the "reg" property having leading zero cell(s). In that
situation, the big-endian nature of the data conspires with the current
behaviour of only reading the first cell to cause the kernel to think
all CPUs have ID 0, and become resoundingly unhappy as a consequence.
Take the full property length into account when parsing CPUs so as to
be correct under any circumstances.
CC: Russell King <linux@armlinux.org.uk>
Signed-off-by: Robin Murphy <robin.murphy@arm.com>
---
v2: Check that any and all upper cells are zero rather than just
ignoring them.
I think if we want to properly validate the DT as per Lorenzo's old
patch, that can follow on afterwards; here I'm really just concerned
with making sure the existing behaviour is actually robust and correct.
arch/arm/kernel/devtree.c | 14 +++++++++++---
1 file changed, 11 insertions(+), 3 deletions(-)
diff --git a/arch/arm/kernel/devtree.c b/arch/arm/kernel/devtree.c
index 40ecd5f514a2..f676febbb270 100644
--- a/arch/arm/kernel/devtree.c
+++ b/arch/arm/kernel/devtree.c
@@ -88,6 +88,8 @@ void __init arm_dt_init_cpu_maps(void)
return;
for_each_child_of_node(cpus, cpu) {
+ const __be32 *cell;
+ int prop_bytes;
u32 hwid;
if (of_node_cmp(cpu->type, "cpu"))
@@ -99,7 +101,8 @@ void __init arm_dt_init_cpu_maps(void)
* properties is considered invalid to build the
* cpu_logical_map.
*/
- if (of_property_read_u32(cpu, "reg", &hwid)) {
+ cell = of_get_property(cpu, "reg", &prop_bytes);
+ if (!cell || prop_bytes < sizeof(*cell)) {
pr_debug(" * %s missing reg property\n",
cpu->full_name);
of_node_put(cpu);
@@ -107,10 +110,15 @@ void __init arm_dt_init_cpu_maps(void)
}
/*
- * 8 MSBs must be set to 0 in the DT since the reg property
+ * Bits n:24 must be set to 0 in the DT since the reg property
* defines the MPIDR[23:0].
*/
- if (hwid & ~MPIDR_HWID_BITMASK) {
+ do {
+ hwid = be32_to_cpu(*cell++);
+ prop_bytes -= sizeof(*cell);
+ } while (!hwid && prop_bytes > 0);
+
+ if (prop_bytes || (hwid & ~MPIDR_HWID_BITMASK)) {
of_node_put(cpu);
return;
}
--
2.8.1.dirty
^ permalink raw reply related
* [PATCH] serial: imx: Fix DCD reading
From: Uwe Kleine-König @ 2016-09-26 14:25 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAOMZO5Aw8pkt_tnM=M0SewN-Xjqq84E-mef-ewGs8aTv0xcHjQ@mail.gmail.com>
Hello Fabio,
On Mon, Sep 26, 2016 at 11:13:37AM -0300, Fabio Estevam wrote:
> On Mon, Sep 26, 2016 at 11:09 AM, Uwe Kleine-K?nig
> <u.kleine-koenig@pengutronix.de> wrote:
> > On Mon, Sep 26, 2016 at 03:55:31PM +0200, Sascha Hauer wrote:
> >> The USR2_DCDIN bit is tested for in register usr1. As the name
> >> suggests the usr2 register should be used instead. This fixes
> >> reading the Carrier detect status.
> >>
> >> Signed-off-by: Sascha Hauer <s.hauer@pengutronix.de>
> > Fixes: 90ebc4838666 ("serial: imx: repair and complete handshaking")
> > Acked-by: Uwe Kleine-K?nig <u.kleine-koenig@pengutronix.de>
>
> Great, so it affects 4.5+ kernels and should probably have:
>
> Cc: <stable@vger.kernel.org> # 4.5+
This is usually not necessary if there is a Fixes: line.
Best regards
Uwe
--
Pengutronix e.K. | Uwe Kleine-K?nig |
Industrial Linux Solutions | http://www.pengutronix.de/ |
^ permalink raw reply
* [PATCH] serial: imx: Fix DCD reading
From: Fabio Estevam @ 2016-09-26 14:13 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20160926140938.ikjatvprk3t4lsed@pengutronix.de>
On Mon, Sep 26, 2016 at 11:09 AM, Uwe Kleine-K?nig
<u.kleine-koenig@pengutronix.de> wrote:
> Hallo,
>
> On Mon, Sep 26, 2016 at 03:55:31PM +0200, Sascha Hauer wrote:
>> The USR2_DCDIN bit is tested for in register usr1. As the name
>> suggests the usr2 register should be used instead. This fixes
>> reading the Carrier detect status.
>>
>> Signed-off-by: Sascha Hauer <s.hauer@pengutronix.de>
> Fixes: 90ebc4838666 ("serial: imx: repair and complete handshaking")
> Acked-by: Uwe Kleine-K?nig <u.kleine-koenig@pengutronix.de>
Great, so it affects 4.5+ kernels and should probably have:
Cc: <stable@vger.kernel.org> # 4.5+
^ permalink raw reply
* BUG: serial: imx: imprecise data abort
From: Holger Schurig @ 2016-09-26 14:12 UTC (permalink / raw)
To: linux-arm-kernel
Hi all,
on an i.MX6Q we had a situation where we got "Imprecise Data Aborts".
The backtraces of those aborts were useless, all over the place.
But we found out that we can trigger this bug with this procedure:
- make some external PC send constantly through the serial port
to the i.MX6Q.
- run a serial program on the i.MX6Q that receives the data and
echos it back
- let this program terminate and restart every over second (we
used a 4 second interval)
Chances were good that we reproduced the issue with various kernels
(up to 4.7.2).
In the drivers/tty/serial/tty/imx.c I disabled all DMA, because this was
my first suspicion. But to no avail. Eventually we asked some company
to help us. They produced the following patch. With this patch, we can
now run for a long time without any imprecise data abort (actually we
run into another issue, but according to
https://lkml.org/lkml/2016/5/16/452 "tty crash in Linux 4.6" this is
already in the working).
It's entirely clear to me that below WIP-patch has ZERO chance of being
added. It's not just checkpatch that will barf over it. :-)
My goal is to make the more knowledgeable people aware of the issue and
to give them a pointer, so that they can tell me how to fix the issue
in a correct way.
Holger
--- linux-4.6.orig/drivers/tty/serial/imx.c
+++ linux-4.6/drivers/tty/serial/imx.c
@@ -234,6 +234,9 @@
unsigned int ucr3;
};
+static unsigned int DBG_Starttx = 0;
+atomic_t imx_uart_is_in_irq = ATOMIC_INIT(0);
+
static struct imx_uart_data imx_uart_devdata[] = {
[IMX1_UART] = {
.uts_reg = IMX1_UTS,
@@ -386,8 +389,8 @@
}
}
- temp = readl(sport->port.membase + UCR2);
- writel(temp & ~UCR2_RXEN, sport->port.membase + UCR2);
+ //temp = readl(sport->port.membase + UCR2);
+ //writel(temp & ~UCR2_RXEN, sport->port.membase + UCR2);
/* disable the `Receiver Ready Interrrupt` */
temp = readl(sport->port.membase + UCR1);
@@ -577,6 +580,7 @@
}
if (!sport->dma_is_enabled) {
+ //DBG_Starttx++;
temp = readl(sport->port.membase + UCR1);
writel(temp | UCR1_TXMPTYEN, sport->port.membase + UCR1);
}
spin_lock_irqsave(&sport->port.lock, flags);
while (readl(sport->port.membase + USR2) & USR2_RDR) {
+ //skip if not enabled
+ if(((readl(sport->port.membase + UCR2) & UCR2_RXEN) ==0 )
+ || ((readl(sport->port.membase + UCR1) & UCR1_UARTEN) ==0 ))
+ goto out;
+
flg = TTY_NORMAL;
sport->port.icount.rx++;
+
+
rx = readl(sport->port.membase + URXD0);
@@ -735,6 +746,7 @@
unsigned int sts;
unsigned int sts2;
+ atomic_add(1,&imx_uart_is_in_irq);
sts = readl(sport->port.membase + USR1);
sts2 = readl(sport->port.membase + USR2);
@@ -761,7 +773,7 @@
sport->port.icount.overrun++;
writel(USR2_ORE, sport->port.membase + USR2);
}
-
+ atomic_sub(1,&imx_uart_is_in_irq);
return IRQ_HANDLED;
}
@@ -896,6 +908,7 @@
struct imx_port *sport = (struct imx_port *)data;
unsigned long flags;
+ atomic_add(1,&imx_uart_is_in_irq);
if (sport->port.state) {
spin_lock_irqsave(&sport->port.lock, flags);
imx_mctrl_check(sport);
@@ -903,6 +916,7 @@
mod_timer(&sport->timer, jiffies + MCTRL_TIMEOUT);
}
+ atomic_sub(1,&imx_uart_is_in_irq);
}
#define RX_BUF_SIZE (PAGE_SIZE)
@@ -1251,7 +1267,7 @@
}
spin_lock_irqsave(&sport->port.lock, flags);
imx_stop_tx(port);
- imx_stop_rx(port);
+// imx_stop_rx(port);
imx_disable_dma(sport);
spin_unlock_irqrestore(&sport->port.lock, flags);
imx_uart_dma_exit(sport);
@@ -1261,7 +1277,7 @@
spin_lock_irqsave(&sport->port.lock, flags);
temp = readl(sport->port.membase + UCR2);
- temp &= ~(UCR2_TXEN);
+ //temp &= ~(UCR2_TXEN);
writel(temp, sport->port.membase + UCR2);
spin_unlock_irqrestore(&sport->port.lock, flags);
@@ -1276,13 +1292,16 @@
spin_lock_irqsave(&sport->port.lock, flags);
temp = readl(sport->port.membase + UCR1);
- temp &= ~(UCR1_TXMPTYEN | UCR1_RRDYEN | UCR1_RTSDEN | UCR1_UARTEN);
+ //temp &= ~(UCR1_TXMPTYEN | UCR1_RRDYEN | UCR1_RTSDEN | UCR1_UARTEN);
+ temp &= ~(UCR1_TXMPTYEN | UCR1_RRDYEN | UCR1_RTSDEN);
writel(temp, sport->port.membase + UCR1);
spin_unlock_irqrestore(&sport->port.lock, flags);
- clk_disable_unprepare(sport->clk_per);
- clk_disable_unprepare(sport->clk_ipg);
+ while(atomic_read(&imx_uart_is_in_irq) == 1);
+
+ //clk_disable_unprepare(sport->clk_per);
+ //clk_disable_unprepare(sport->clk_ipg);
}
static void imx_flush_buffer(struct uart_port *port)
@@ -1732,8 +1750,8 @@
if (locked)
spin_unlock_irqrestore(&sport->port.lock, flags);
- clk_disable(sport->clk_ipg);
- clk_disable(sport->clk_per);
+ //clk_disable(sport->clk_ipg);
+ //clk_disable(sport->clk_per);
}
/*
@@ -1834,7 +1852,7 @@
retval = uart_set_options(&sport->port, co, baud, parity, bits, flow);
- clk_disable(sport->clk_ipg);
+ /*clk_disable(sport->clk_ipg);
if (retval) {
clk_unprepare(sport->clk_ipg);
goto error_console;
@@ -1843,7 +1861,7 @@
retval = clk_prepare(sport->clk_per);
if (retval)
clk_disable_unprepare(sport->clk_ipg);
-
+ */
error_console:
return retval;
}
@@ -2034,7 +2052,7 @@
UCR1_TXMPTYEN | UCR1_RTSDEN);
writel_relaxed(reg, sport->port.membase + UCR1);
- clk_disable_unprepare(sport->clk_ipg);
+ //clk_disable_unprepare(sport->clk_ipg);
/*
* Allocate the IRQ(s) i.MX1 has three interrupts whereas later
@@ -2136,7 +2154,7 @@
serial_imx_save_context(sport);
- clk_disable(sport->clk_ipg);
+ //clk_disable(sport->clk_ipg);
return 0;
}
@@ -2153,7 +2171,7 @@
serial_imx_restore_context(sport);
- clk_disable(sport->clk_ipg);
+ //clk_disable(sport->clk_ipg);
return 0;
}
^ permalink raw reply
* [PATCH] serial: imx: Fix DCD reading
From: Uwe Kleine-König @ 2016-09-26 14:09 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20160926135531.31888-1-s.hauer@pengutronix.de>
Hallo,
On Mon, Sep 26, 2016 at 03:55:31PM +0200, Sascha Hauer wrote:
> The USR2_DCDIN bit is tested for in register usr1. As the name
> suggests the usr2 register should be used instead. This fixes
> reading the Carrier detect status.
>
> Signed-off-by: Sascha Hauer <s.hauer@pengutronix.de>
Fixes: 90ebc4838666 ("serial: imx: repair and complete handshaking")
Acked-by: Uwe Kleine-K?nig <u.kleine-koenig@pengutronix.de>
Thanks
Uwe
--
Pengutronix e.K. | Uwe Kleine-K?nig |
Industrial Linux Solutions | http://www.pengutronix.de/ |
^ permalink raw reply
* [PATCH] serial: imx: Fix DCD reading
From: Fabio Estevam @ 2016-09-26 14:08 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20160926135531.31888-1-s.hauer@pengutronix.de>
Hi Sascha,
On Mon, Sep 26, 2016 at 10:55 AM, Sascha Hauer <s.hauer@pengutronix.de> wrote:
> The USR2_DCDIN bit is tested for in register usr1. As the name
> suggests the usr2 register should be used instead. This fixes
> reading the Carrier detect status.
>
> Signed-off-by: Sascha Hauer <s.hauer@pengutronix.de>
Good catch:
Reviewed-by: Fabio Estevam <fabio.estevam@nxp.com>
Shouldn't this have stable on Cc?
^ permalink raw reply
* [PATCH 2/3] arm64: hw_breakpoint: Handle inexact watchpoint addresses
From: Will Deacon @ 2016-09-26 14:06 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1474643941-109020-2-git-send-email-labath@google.com>
Hi Pavel,
On Fri, Sep 23, 2016 at 04:19:00PM +0100, Pavel Labath wrote:
> Arm64 hardware does not always report a watchpoint hit address that
> matches one of the watchpoints set. It can also report an address
> "near" the watchpoint if a single instruction access both watched and
> unwatched addresses. There is no straight-forward way, short of
> disassembling the offending instruction, to map that address back to
> the watchpoint.
>
> Previously, when the hardware reported a watchpoint hit on an address
> that did not match our watchpoint (this happens in case of instructions
> which access large chunks of memory such as "stp") the process would
> enter a loop where we would be continually resuming it (because we did
> not recognise that watchpoint hit) and it would keep hitting the
> watchpoint again and again. The tracing process would never get
> notified of the watchpoint hit.
>
> This commit fixes the problem by looking at the watchpoints near the
> address reported by the hardware. If the address does not exactly match
> one of the watchpoints we have set, it attributes the hit to the
> nearest watchpoint we have. This heuristic is a bit dodgy, but I don't
> think we can do much more, given the hardware limitations.
>
> Signed-off-by: Pavel Labath <labath@google.com>
> ---
> arch/arm64/kernel/hw_breakpoint.c | 98 +++++++++++++++++++++++++--------------
> 1 file changed, 64 insertions(+), 34 deletions(-)
If the first patch in the series is no longer required (as you stated in
your follow-up reply), then you can just drop it.
> diff --git a/arch/arm64/kernel/hw_breakpoint.c b/arch/arm64/kernel/hw_breakpoint.c
> index 14562ae..3ce27ea 100644
> --- a/arch/arm64/kernel/hw_breakpoint.c
> +++ b/arch/arm64/kernel/hw_breakpoint.c
> @@ -664,49 +664,63 @@ unlock:
> }
> NOKPROBE_SYMBOL(breakpoint_handler);
>
> +/*
> + * Arm64 hardware does not always report a watchpoint hit address that matches
> + * one of the watchpoints set. It can also report an address "near" the
> + * watchpoint if a single instruction access both watched and unwatched
> + * addresses. There is no straight-forward way, short of disassembling the
> + * offending instruction, to map that address back to the watchpoint. This
> + * function computes the distance of the memory access from the watchpoint as a
> + * heuristic for the likelyhood that a given access triggered the watchpoint.
> + *
> + * See Section D2.10.5 "Determining the memory location that caused a Watchpoint
> + * exception" of ARMv8 Architecture Reference Manual for details.
> + *
> + * The function returns the distance of the address from the bytes watched by
> + * the watchpoint. In case of an exact match, it returns 0.
> + */
> +static u64 get_distance_from_watchpoint(unsigned long addr, int i,
> + struct arch_hw_breakpoint *info)
> +{
> + u64 wp_low, wp_high;
> + int first_bit;
> +
> + first_bit = ffs(info->ctrl.len);
> + if (first_bit == 0)
> + return -1;
> +
> + wp_low = info->address + first_bit - 1;
> + wp_high = info->address + fls(info->ctrl.len) - 1;
This would all be cleaner if you just called get_hbp_len(info->ctrl.len)
to get the size of the watchpoint. We don't do anything sophisticated
with the BAS, so you can assume everything is base + len.
> @@ -723,10 +748,15 @@ static int watchpoint_handler(unsigned long addr, unsigned int esr,
> /* Do we need to handle the stepping? */
> if (is_default_overflow_handler(wp))
> step = 1;
> -
> -unlock:
> - rcu_read_unlock();
> }
> + if (min_dist > 0 && min_dist != -1) {
min_dist is unsigned, so this could be:
if (min_dist + 1 > 1)
Will
^ permalink raw reply
* [PATCH v5] devicetree: bindings: uart: Add new compatible string for ZynqMP
From: Nava kishore Manne @ 2016-09-26 14:06 UTC (permalink / raw)
To: linux-arm-kernel
From: Nava kishore Manne <nava.manne@xilinx.com>
This patch Adds the new compatible string for ZynqMP SoC.
Signed-off-by: Nava kishore Manne <navam@xilinx.com>
---
Changes for v5:
-Fixed some minor comments.
Changes for v4:
-Modified the ChangeLog comment.
Changes for v3:
-Added changeLog comment.
Changes for v2:
-None
Documentation/devicetree/bindings/serial/cdns,uart.txt | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/Documentation/devicetree/bindings/serial/cdns,uart.txt b/Documentation/devicetree/bindings/serial/cdns,uart.txt
index a3eb154..30c885c 100644
--- a/Documentation/devicetree/bindings/serial/cdns,uart.txt
+++ b/Documentation/devicetree/bindings/serial/cdns,uart.txt
@@ -1,7 +1,9 @@
Binding for Cadence UART Controller
Required properties:
-- compatible : should be "cdns,uart-r1p8", or "xlnx,xuartps"
+- compatible :
+ Use "cdns,uart-r1p8", or "xlnx,xuartps" for Zynq-7xxx SoC.
+ Use "cdns,uart-r1p12" for Zynq Ultrascale+ MPSoC.
- reg: Should contain UART controller registers location and length.
- interrupts: Should contain UART controller interrupts.
- clocks: Must contain phandles to the UART clocks
--
2.1.2
^ permalink raw reply related
* [PATCH v4 2/5] ARM: dts: imx6q: Add Engicam i.CoreM6 Quad/Dual initial support
From: Michael Trimarchi @ 2016-09-26 13:56 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAOMZO5BHhA8rd0URLNGGLZKN00zFz9d5vsq4CuRWsKyT6yq-oA@mail.gmail.com>
Hi
On Mon, Sep 26, 2016 at 3:55 PM, Fabio Estevam <festevam@gmail.com> wrote:
> On Mon, Sep 26, 2016 at 10:54 AM, Michael Trimarchi
> <michael@amarulasolutions.com> wrote:
>
>>> Why don't you simply do like this?
>>>
>>> reg_3p3v: regulator-3p3v {
>>> compatible = "regulator-fixed";
>>> regulator-name = "3P3V";
>>> regulator-min-microvolt = <3300000>;
>>> regulator-max-microvolt = <3300000>;
>>> };
>>
>> Should dts rispect the schematic connection?
>
> Yes
So boot on and always on are used to declare their status and their
behavionr. I don't
see the point to not specify them in this way
Michael
--
| Michael Nazzareno Trimarchi Amarula Solutions BV |
| COO - Founder Cruquiuskade 47 |
| +31(0)851119172 Amsterdam 1018 AM NL |
| [`as] http://www.amarulasolutions.com |
^ permalink raw reply
* [PATCH] serial: imx: Fix DCD reading
From: Sascha Hauer @ 2016-09-26 13:55 UTC (permalink / raw)
To: linux-arm-kernel
The USR2_DCDIN bit is tested for in register usr1. As the name
suggests the usr2 register should be used instead. This fixes
reading the Carrier detect status.
Signed-off-by: Sascha Hauer <s.hauer@pengutronix.de>
---
drivers/tty/serial/imx.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/tty/serial/imx.c b/drivers/tty/serial/imx.c
index 0df2b1c..615c027 100644
--- a/drivers/tty/serial/imx.c
+++ b/drivers/tty/serial/imx.c
@@ -740,12 +740,13 @@ static unsigned int imx_get_hwmctrl(struct imx_port *sport)
{
unsigned int tmp = TIOCM_DSR;
unsigned usr1 = readl(sport->port.membase + USR1);
+ unsigned usr2 = readl(sport->port.membase + USR2);
if (usr1 & USR1_RTSS)
tmp |= TIOCM_CTS;
/* in DCE mode DCDIN is always 0 */
- if (!(usr1 & USR2_DCDIN))
+ if (!(usr2 & USR2_DCDIN))
tmp |= TIOCM_CAR;
if (sport->dte_mode)
--
2.9.3
^ permalink raw reply related
* [PATCH v4 2/5] ARM: dts: imx6q: Add Engicam i.CoreM6 Quad/Dual initial support
From: Fabio Estevam @ 2016-09-26 13:55 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAOf5uw=HwErWWqvQ30ZJpb3CupqdvGZ9FnGAxh4+JVTrT6wTjw@mail.gmail.com>
On Mon, Sep 26, 2016 at 10:54 AM, Michael Trimarchi
<michael@amarulasolutions.com> wrote:
>> Why don't you simply do like this?
>>
>> reg_3p3v: regulator-3p3v {
>> compatible = "regulator-fixed";
>> regulator-name = "3P3V";
>> regulator-min-microvolt = <3300000>;
>> regulator-max-microvolt = <3300000>;
>> };
>
> Should dts rispect the schematic connection?
Yes
^ 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