* [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 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
* [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
* [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
* 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
* [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
* [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
* [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: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
* 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 2/3] gpio: Add a driver for the Raspberry Pi's firmware GPIO calls.
From: Stephen Warren @ 2016-09-26 16:46 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <87mviy92qw.fsf@eliezer.anholt.net>
On 09/23/2016 07:15 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:
>>
>>> This driver will be used for accessing the FXL6408 GPIO exander on the
>>> Pi3. We can't drive it directly from Linux because the firmware is
>>> continuously polling one of the expander's lines to do its
>>> undervoltage detection.
>>>
>>> Signed-off-by: Eric Anholt <eric@anholt.net>
>> (...)
>>
>>> +config GPIO_RASPBERRYPI
>>> + tristate "Raspberry Pi firmware-based GPIO access"
>>> + depends on OF_GPIO && RASPBERRYPI_FIRMWARE && (ARCH_BCM2835 || COMPILE_TEST)
>>> + help
>>> + Turns on support for using the Raspberry Pi firmware to
>>> + control GPIO pins. Used for access to the FXL6408 GPIO
>>> + expander on the Pi 3.
>>
>> Maybe it should be named GPIO_RPI_FXL6408 ?
>>
>> (No strong opinion.)
>
> See DT binding comment -- I think since this driver has no dependency on
> being to the 6408 on the pi3, we shouldn't needlessly bind it to the
> FXL6408. (the help comment was just context for why you would want the
> driver today).
I'd suggest including "FW" or "FIRMWARE" in the Kconfig option too; the
Raspberry Pi has multiple GPIO drivers; one accessing the BCM283x HW
directly and the other going through the FW. It'd be good if each
Kconfig name was pretty explicit re: which one it represented.
^ permalink raw reply
* [PATCHv9 0/6] dmaengine: rcar-dmac: add iommu support for slave transfers
From: Vinod Koul @ 2016-09-26 16:47 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20160810112219.17964-1-niklas.soderlund+renesas@ragnatech.se>
On Wed, Aug 10, 2016 at 01:22:13PM +0200, Niklas S?derlund wrote:
> Hi,
>
> This series tries to solve the problem with DMA with device registers
> (MMIO registers) that are behind an IOMMU for the rcar-dmac driver. A
> recent patch '9575632 (dmaengine: make slave address physical)'
> clarifies that DMA slave address provided by clients is the physical
> address. This puts the task of mapping the DMA slave address from a
> phys_addr_t to a dma_addr_t on the DMA engine.
>
> Without an IOMMU this is easy since the phys_addr_t and dma_addr_t are
> the same and no special care is needed. However if you have a IOMMU you
> need to map the DMA slave phys_addr_t to a dma_addr_t using something
> like this.
>
> This series is based on top of v4.8-rc1. And I'm hoping to be able to collect a
> Ack from Russell King on patch 4/6 that adds the ARM specific part and then be
> able to take the whole series through the dmaengine tree. If this is not the
> best route I'm more then happy to do it another way.
>
> It's tested on a Koelsch with CONFIG_IPMMU_VMSA and by enabling the
> ipmmu_ds node in r8a7791.dtsi. I verified operation by interacting with
> /dev/mmcblk1, i2c and the serial console which are devices behind the
> iommu.
>
> Furthermore I have audited to the best of my ability all call paths
> involved to make sure that the dma_addr_t obtained from
> dma_map_resource() to is not used in a way where it would be expected
> for the mapping to be RAM (have a struct page). Many thanks to Christoph
> Hellwig and Laurent Pinchart for there input in this effort.
Applied, thanks
--
~Vinod
^ permalink raw reply
* [PATCH 1/2] clk: rockchip: add I2S internal clock IDs for rk3288
From: John Keeping @ 2016-09-26 17:04 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <21692410.II2VYnELL8@phil>
On Sun, 25 Sep 2016 23:50:29 +0200, Heiko Stuebner wrote:
> Am Mittwoch, 7. September 2016, 19:18:23 CEST schrieb John Keeping:
> > On Wed, 07 Sep 2016 19:58:31 +0200, Heiko Stuebner wrote:
> > > Am Mittwoch, 7. September 2016, 17:53:29 CEST schrieb John Keeping:
> > > > To minimize jitter on the I2S clocks, it is important that the
> > > > denominator in the fractional divider is much greater than the
> > > > numerator. Add identifiers for these internal clocks so that the
> > > > specific clock topology and rates can be specified in the device tree.
> > >
> > > The TRM states that the denominator must be bigger than 20. Is this the
> > > one
> > > you found or did you find further constraints?
> >
> > Is it not that the denominator must be bigger than 20 times the
> > numerator? That's what we found, although it seems that the greater the
> > divisor the better, so our aim is dividing down from 594MHz from GPLL to
> > the target rate in i2s_frac.
>
> That is good to know ... the TRM probably lost the real information during
> translation or so and only states that hard value. Looking at the rk3368 TRM
> just now, the value really is 20 times greater than the numerator.
>
>
> > > Did you try teaching the fractional divider to handle these constraints
> > > before going this way?
> >
> > No, I hadn't looked at doing that. I'm not sure how that would work,
> > we'd need to add support for fractional divider changing the parent rate
> > wouldn't we?
>
> Doug had a somewhat similar problem, mentioning the lack of a "bestdiv"
> equivalent that the standard divider provides. I'm not sure if there isn't a
> way to provide something like this and/or make the fractional clock honor
> specific requirments concerning numerator/denominator - any mathematicians
> around? :-)
Yes, this is difficult, although I expect a simple approach of setting
the input as fast as possible would work reasonably well in practice.
But even when the input is a mux with a fixed set of possible rates it
is difficult to extract its maximum frequency within the clock
framework.
> One could also replace the generic fraction divider use with a rockchip-
> specific implementation that somehow handles that.
I hadn't considered that, I assumed there would be a strong preference
for enhancing the generic code rather than writing a special case
implementation.
> > > Exporting the internal clocks really would be sort of plan d or e, after
> > > handling this in the clock framework failed. Especially as i2s rates are
> > > probably dependant on the media being handled (frequencies and such), so
> > > setting fractional rates statically in the dts won't help you much in the
> > > general case, as any new playback could trigger a clk_set_rate call
> > > anyway?
> >
> > We're not setting the fractional rate specifically, instead we're
> > setting the i2s_pre rate and parent explicitly and banning the i2s_src
> > mux setting to i2s_pre, which means that clk_set_rate on sclk_i2s0 will
> > always change i2s_frac but leave i2s_pre alone.
>
> But then you are again in the situation where some requested rate can ignore
> those fractional-divider constraints? In general I really don't like encoding
> such board-specific behaviour into the generic clock tree, like needing to
> disable parent relationships.
Yes, I wouldn't suggest changing the clock mux in the upstream kernel.
I was hoping specifying an assigned parent in DT would be enough to keep
the parent set correctly, but it doesn't seem to be.
> It works for your board now but does not necessarily for all other boards,
> which might require other "hacks" and also doesn't solve the general problem
> for all other fractional dividers we have.
The sensible heuristic is to minimize the length of the clock path when
there are two equally good routes, which would handle the case where the
I2S clock can be generated without the need for a fractional divider.
But I don't think the clock framework has any way to take into account
that a mux may end up bypassing another clock.
It seems that even without the fractional divider we can't get low
enough jitter to meet our requirements, so we've decided to use an
external clock for I2S. As a result of that, we're no longer using this
part of the clock tree at all, so I'm happy to drop these patches.
John
^ permalink raw reply
* [PATCH] ARM: dts: exynos: Add reboot reason support for Trats2
From: Krzysztof Kozlowski @ 2016-09-26 17:07 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20160925073445.GA2469@kozik-lap>
On Sun, Sep 25, 2016 at 09:34:45AM +0200, Krzysztof Kozlowski wrote:
> On Sat, Sep 24, 2016 at 11:04:49PM +0200, Wolfgang Wiedmeyer wrote:
> >
> > Krzysztof Kozlowski writes:
> >
> > > On Thu, Sep 22, 2016 at 08:59:03PM +0200, Wolfgang Wiedmeyer wrote:
> > >>
> > >> Krzysztof Kozlowski writes:
> > >>
> > >> > On Thu, Sep 22, 2016 at 06:48:35PM +0200, Wolfgang Wiedmeyer wrote:
> > >> >> This allows to reboot the device into recovery mode and into the download
> > >> >> mode of the bootloader.
> > >> >
> > >> > Which bootloader? Probably UBoot... or Samsung stock one? Could you put
> > >> > that information here?
> > >>
> > >> I'm only working with the stock one. I was under the impression that the
> > >> stock bootloader cannot be replaced on a i9300 because there's a
> > >> signature check. Is UBoot loaded after the stock one on Trats2 or how
> > >> does this work? I didn't find information on that.
> > >
> > > +CC Marek,
> > >
> > > Trats2 is working with U-Boot. Just U-Boot. However I never converted S3
> > > into Trats2 on my own. I always used targets prepared to be "Trats2"
> > > type.
> >
> > It would be awesome to be able to run U-Boot on i9300. Is there a way to
> > test this by not risking to brick the device, e.g. by booting from the
> > SD card? Then I could send an updated version of the patch that is
> > compatible with U-Boot :)
>
> I don't think the stock bootloader supports chaining another bootloader
> from SD card. There is a way of booting from SD card by shortening a
> resistor but it is an emergency rescue procedure to overwrite existing
> bootloader with data from SD card (to restore device). This thread might
> be interesting:
> http://forum.xda-developers.com/showpost.php?p=47234165&postcount=220
> https://smyl.es/samsung-galaxy-iii-s3-gt-i9300-jtag-leaked-document-how-to-repair-soft-bricked-galaxy-s3/
>
> On xda-developers you might find more data about this (including the
> procedure for emergency restore from SD card). Somehow people flash and
> unbrick their devices when playing with CyanogenMod...
Hi Wolfgang,
Few more info from my side. It is (rather) not possible to just flash
GT-I9300 with U-Boot. It still requires S-Boot as a primary bootloader
(probably different than the stock one). I think such binary S-Boot was
published along with Tizen images for Trats2 (called RD-PQ). These
images however started to disappear from download.tizen.org. You can
still find some, e.g.:
http://download.tizen.org/releases/system/Tizen_RD-PQ_System_20130716_1.tar
(better download it soon :) ) This 'tar' should be uploaded through
Lthor (also from tizen.org) however it might require appropriate
Partition Information Table (PIT).
On Tizen Wiki you might find some guides for flashing/upgrading-PIT on Trats2.
However, please be careful, as all of these steps (and linked binary) are
targeted to existing RD-PQ/Trats2 boards. They are not intended as a
way of converting GT-I9300 into Trats2. The conversion might work but...
it might not.
Before playing with it, I think it would be wise to have the emergency
recovery procedure (with SD card) ready.
Best regards,
Krzysztof
^ permalink raw reply
* [PATCH v26 6/7] arm64: kdump: update a kernel doc
From: Matthias Brugger @ 2016-09-26 17:21 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <57DC18FC.9000807@arm.com>
On 16/09/16 18:08, James Morse wrote:
> Hi Akashi,
>
> On 07/09/16 05:29, AKASHI Takahiro wrote:
>> This patch adds arch specific descriptions about kdump usage on arm64
>> to kdump.txt.
>
>> diff --git a/Documentation/kdump/kdump.txt b/Documentation/kdump/kdump.txt
>
>> @@ -249,6 +249,13 @@ Dump-capture kernel config options (Arch Dependent, arm)
>>
>> AUTO_ZRELADDR=y
>>
>> +Dump-capture kernel config options (Arch Dependent, arm64)
>> +----------------------------------------------------------
>> +
>> +- Please note that kvm of the dump-capture kernel will not be enabled
>> + on non-VHE systems even if it is configured. This is because the CPU
>> + cannot be reset to EL2 on panic.
>
> Nit:
> cannot be -> will not be
>
> We could try to do this, but its more code that could prevent us reaching the
> kdump kernel, so we choose not to.
>
>
>> @@ -370,6 +381,9 @@ For s390x:
>> For arm:
>> "1 maxcpus=1 reset_devices"
>>
>> +For arm64:
>> + "1 maxcpus=1 reset_devices"
>> +
>
> 'maxcpus=1' is a bit fragile. Since 44dbcc93ab67145 ("arm64: Fix behavior of
> maxcpus=N") udev on ubuntu vivid (running on Juno) has taken it upon itself to
> bring the secondary cores online, even when booted with 'maxcpus=1'.
>
This looks pretty much like a bug to me and should get fixed on their site.
> Can we change the recomendation to "1 nosmp reset_devices"?
>
>
> Thanks,
>
> James
>
>
> _______________________________________________
> linux-arm-kernel mailing list
> linux-arm-kernel at lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
>
^ permalink raw reply
* [PATCH 00/24] ste_dma40: Fine-tuning for several function implementations
From: Vinod Koul @ 2016-09-26 17:39 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <92810066-69b6-94e7-dcec-a28594b1328f@users.sourceforge.net>
On Sat, Sep 17, 2016 at 05:05:16PM +0200, SF Markus Elfring wrote:
> From: Markus Elfring <elfring@users.sourceforge.net>
> Date: Sat, 17 Sep 2016 16:56:56 +0200
>
> Several update suggestions were taken into account
> from static source code analysis.
Applied all, thanks
--
~Vinod
^ permalink raw reply
* [PATCH v3] dmaengine: s3c24xx: Add dma_slave_map for s3c2440 devices
From: Vinod Koul @ 2016-09-26 17:43 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1474570275-7238-1-git-send-email-sam.van.den.berge@telenet.be>
On Thu, Sep 22, 2016 at 08:51:15PM +0200, Sam Van Den Berge wrote:
> This patch updates the s3c24xx dma driver to be able to pass a
> dma_slave_map array via the platform data. This is needed to
> be able to use the new, simpler dmaengine API [1].
> I used the virtual DMA channels as a parameter for the dma_filter
> function. By doing that, I could reuse the existing filter function in
> drivers/dma/s3c24xx-dma.c.
>
> I have tested this on my mini2440 board with the audio driver.
> According to my observations, dma_request_slave_channel in the
> function dmaengine_pcm_new in the file
> sound/soc/soc-generic-dmaengine-pcm.c now returns a valid DMA channel
> whereas before no DMA channel was returned at that point.
>
> Entries for DMACH_XD0, DMACH_XD1 and DMACH_TIMER are missing because I
> don't realy know which driver to use for these.
Applied, thanks
--
~Vinod
^ permalink raw reply
* [PATCH] dmaengine: sun6i: Add support for Allwinner A83T (sun8i) variant
From: Vinod Koul @ 2016-09-26 17:45 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <79efe054-3640-45ec-9c11-3f60d497b1e0@orsmsx104.amr.corp.intel.com>
On Sun, Sep 18, 2016 at 09:59:50AM +0200, Jean-Francois Moine wrote:
> The A83T SoC has the same dma engine as the A31 (sun6i), with a reduced
> amount of endpoints and physical channels.
Applied, thanks
--
~Vinod
^ permalink raw reply
* [PATCH 1/3] dt-bindings: Add a binding for the RPi firmware GPIO driver.
From: Stefan Wahren @ 2016-09-26 18:42 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <fa11c543-2ad3-b2ae-f816-62a1acd42911@wwwdotorg.org>
> Stephen Warren <swarren@wwwdotorg.org> hat am 26. September 2016 um 18:38
> geschrieben:
>
>
> 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?
AFAIK only the Raspberry Pi 3 has a GPIO expander which is accessible via the
common FW. My suggestion tries to follow the basic guideline "A precise
compatible string is better than a vague one" from Device Tree for Dummies [1].
So in case the next Raspberry Pi would have a different GPIO expander with
different parameters we could add a new compatible.
But you are right the word order in "rpi3-firmware-gpio" suggests that there are
different FW which is wrong. At the end it's only a compatible string. So no
strong opinion about the naming.
[1] -
https://events.linuxfoundation.org/sites/events/files/slides/petazzoni-device-tree-dummies.pdf
> 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
* [PATCH] clk: lpc32xx: fix pwm clock divider computation
From: Sylvain Lemieux @ 2016-09-26 18:44 UTC (permalink / raw)
To: linux-arm-kernel
From: Sylvain Lemieux <slemieux@tycoint.com>
A zero value in the PWM clock divider register
(PWM1_FREQ/PWM2_FREQ) turn off the PWM clock.
The "CLK_DIVIDER_ALLOW_ZERO" option is used for hardware that handle
the zero divider by not modifying their clock input (i.e. bypass).
See "/include/linux/clk-provider.h" for details.
Remove the CLK_DIVIDER_ALLOW_ZERO option and add support to handle
the clock rate computation of the PWM clock divider 0 value.
Signed-off-by: Sylvain Lemieux <slemieux@tycoint.com>
---
Note:
* Should we include a new CLK_DIVIDER option for this case
(i.e. clock off when zero ) in "clk-provider.h"?
drivers/clk/nxp/clk-lpc32xx.c | 52 +++++++++++++++++++++++++++++++++++++++----
1 file changed, 48 insertions(+), 4 deletions(-)
diff --git a/drivers/clk/nxp/clk-lpc32xx.c b/drivers/clk/nxp/clk-lpc32xx.c
index 34c9735..3ca3a14 100644
--- a/drivers/clk/nxp/clk-lpc32xx.c
+++ b/drivers/clk/nxp/clk-lpc32xx.c
@@ -959,6 +959,25 @@ static unsigned long clk_divider_recalc_rate(struct clk_hw *hw,
divider->flags);
}
+static unsigned long clk_divider_pwm_recalc_rate(struct clk_hw *hw,
+ unsigned long parent_rate)
+{
+ struct lpc32xx_clk_div *divider = to_lpc32xx_div(hw);
+ unsigned int val;
+
+ regmap_read(clk_regmap, divider->reg, &val);
+
+ val >>= divider->shift;
+ val &= div_mask(divider->width);
+
+ /* Handle 0 divider -> PWM clock is off. */
+ if(val == 0)
+ return 0;
+
+ return divider_recalc_rate(hw, parent_rate, val, divider->table,
+ divider->flags);
+}
+
static long clk_divider_round_rate(struct clk_hw *hw, unsigned long rate,
unsigned long *prate)
{
@@ -999,6 +1018,12 @@ static const struct clk_ops lpc32xx_clk_divider_ops = {
.set_rate = clk_divider_set_rate,
};
+static const struct clk_ops lpc32xx_clk_pwm_divider_ops = {
+ .recalc_rate = clk_divider_pwm_recalc_rate,
+ .round_rate = clk_divider_round_rate,
+ .set_rate = clk_divider_set_rate,
+};
+
static u8 clk_mux_get_parent(struct clk_hw *hw)
{
struct lpc32xx_clk_mux *mux = to_lpc32xx_mux(hw);
@@ -1151,6 +1176,25 @@ struct clk_hw_proto {
}, \
}
+#define LPC32XX_DEFINE_PWM_DIV(_idx, _reg, _shift, _width, _tab, _fl) \
+[CLK_PREFIX(_idx)] = { \
+ .type = CLK_DIV, \
+ { \
+ .hw0 = { \
+ .ops = &lpc32xx_clk_pwm_divider_ops, \
+ { \
+ .div = { \
+ .reg = LPC32XX_CLKPWR_ ## _reg, \
+ .shift = (_shift), \
+ .width = (_width), \
+ .table = (_tab), \
+ .flags = (_fl), \
+ }, \
+ }, \
+ }, \
+ }, \
+}
+
#define LPC32XX_DEFINE_GATE(_idx, _reg, _bit, _flags) \
[CLK_PREFIX(_idx)] = { \
.type = CLK_GATE, \
@@ -1281,14 +1325,14 @@ static struct clk_hw_proto clk_hw_proto[LPC32XX_CLK_HW_MAX] = {
LPC32XX_DEFINE_GATE(MCPWM, TIMCLK_CTRL1, 6, 0),
LPC32XX_DEFINE_MUX(PWM1_MUX, PWMCLK_CTRL, 1, 0x1, NULL, 0),
- LPC32XX_DEFINE_DIV(PWM1_DIV, PWMCLK_CTRL, 4, 4, NULL,
- CLK_DIVIDER_ONE_BASED | CLK_DIVIDER_ALLOW_ZERO),
+ LPC32XX_DEFINE_PWM_DIV(PWM1_DIV, PWMCLK_CTRL, 4, 4, NULL,
+ CLK_DIVIDER_ONE_BASED),
LPC32XX_DEFINE_GATE(PWM1_GATE, PWMCLK_CTRL, 0, 0),
LPC32XX_DEFINE_COMPOSITE(PWM1, PWM1_MUX, PWM1_DIV, PWM1_GATE),
LPC32XX_DEFINE_MUX(PWM2_MUX, PWMCLK_CTRL, 3, 0x1, NULL, 0),
- LPC32XX_DEFINE_DIV(PWM2_DIV, PWMCLK_CTRL, 8, 4, NULL,
- CLK_DIVIDER_ONE_BASED | CLK_DIVIDER_ALLOW_ZERO),
+ LPC32XX_DEFINE_PWM_DIV(PWM2_DIV, PWMCLK_CTRL, 8, 4, NULL,
+ CLK_DIVIDER_ONE_BASED),
LPC32XX_DEFINE_GATE(PWM2_GATE, PWMCLK_CTRL, 2, 0),
LPC32XX_DEFINE_COMPOSITE(PWM2, PWM2_MUX, PWM2_DIV, PWM2_GATE),
--
1.8.3.1
^ permalink raw reply related
* [RFC/PATCH] usb: misc: Add a driver for TC7USB40MU
From: Stephen Boyd @ 2016-09-26 18:44 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20160926032927.GA25395@b29397-desktop>
Quoting Peter Chen (2016-09-25 20:29:27)
> On Thu, Sep 22, 2016 at 11:51:02AM -0700, Stephen Boyd wrote:
> > Quoting Peter Chen (2016-09-16 18:16:05)
> > > On Wed, Sep 14, 2016 at 01:55:02AM -0700, Stephen Boyd wrote:
> > > > Quoting Stephen Boyd (2016-09-13 18:42:46)
> > > > > On the db410c 96boards platform we have a TC7USB40MU[1] on the
> > > > > board to mux the D+/D- lines from the SoC between a micro usb
> > > > > "device" port and a USB hub for "host" roles. Upon a role switch,
> > > > > we need to change this mux to forward the D+/D- lines to either
> > > > > the port or the hub. Therefore, introduce a driver for this
> > > > > device that intercepts extcon USB_HOST events and logically
> > > > > asserts a gpio to mux the "host" D+/D- lines when a host cable is
> > > > > attached. When the cable goes away, it will logically deassert
> > > > > the gpio and mux the "device" lines.
> > > > >
> > > > > [1] https://toshiba.semicon-storage.com/ap-en/product/logic/bus-switch/detail.TC7USB40MU.html
> > > > >
> > > > > Cc: MyungJoo Ham <myungjoo.ham@samsung.com>
> > > > > Cc: Chanwoo Choi <cw00.choi@samsung.com>
> > > > > Cc: <devicetree@vger.kernel.org>
> > > > > Signed-off-by: Stephen Boyd <stephen.boyd@linaro.org>
> > > > > ---
> > > > >
> > > > > Should I make the extcon part optional? I could see a case where there are two
> > > > > "OTG" ports connected to the mux (or two hubs), and for some reason the
> > > > > software may want to mux between them at runtime. If we mandate an extcon,
> > > > > that won't be possible to support. Perhaps it would be better to have
> > > > > the node, but connect it to the usb controller with a phandle (maybe of_graph
> > > > > endpoints would be useful too) so that when the controller wants to mux over
> > > > > a port it can do so.
> > > >
> > > > Here's some dts mock-up on top of the db410c for the of_graph stuff. I
> > > > haven't written any code around it, but the idea is to allow the binding
> > > > to specify how the mux is connected to upstream and downstream D+/D-
> > > > lines. This way, we can do some dt parsing of the endpoints and their
> > > > parent nodes to figure out if the mux needs to be set high or low to use
> > > > a device connector or a usb hub based on if the id cable is present.
> > > > Maybe I'm over thinking things though and we could just have a DT
> > > > property for that.
> > > >
> > > > soc {
> > > > usb at 78d9000 {
> > > > extcon = <&usb_id>, <&usb_id>;
> > >
> > > Why you have two same extcon phandler? From my mind, one should id,
> > > another should is vbus. Besides, I find extcon-usb-gpio.c is lack of
> > > vbus support, how you support vbus detection for
> > > connection/disconnection with PC for your chipidea msm patch set?
> >
> > This was already in the dts files for db410c. In the chipidea binding
> > one is for EXTCON_USB (vbus) and one is for EXTCON_USB_HOST (id). My
> > understanding is that extcon-usb-gpio.c sends events for both EXTCON_USB
> > and EXTCON_USB_HOST when the gpio changes state. vbus detection is not
> > that great on this board because we only have on gpio for this.
>
> I think extcon-usb-gpio.c needs to extend for supporting vbus event,
> otherwise, the micro-b cable's connect/disconnect will introduce
> EXTCON_USB_HOST event, if you use two <&usb_idx> for both id and
> vbus event.
>
Sorry, I'm lost now. extcon-usb-gpio.c already supports EXTCON_USB as an
event. Is the problem that we're using two of the same phandles in the
binding?
^ permalink raw reply
* [PATCH] ARM: dts: lpc32xx: add pwm-cells to base dts file
From: Sylvain Lemieux @ 2016-09-26 18:47 UTC (permalink / raw)
To: linux-arm-kernel
From: Sylvain Lemieux <slemieux@tycoint.com>
There is no need to define the "pwm-cells" in the board
specific dts file; move the entry to the base dts file.
Signed-off-by: Sylvain Lemieux <slemieux@tycoint.com>
---
Note:
* This patch should be apply after
"ARM: dts: lpc32xx: set default parent clock for pwm1 & pwm2"
http://www.spinics.net/lists/arm-kernel/msg530277.html
- There is no dependency between the patches.
arch/arm/boot/dts/lpc32xx.dtsi | 2 ++
1 file changed, 2 insertions(+)
diff --git a/arch/arm/boot/dts/lpc32xx.dtsi b/arch/arm/boot/dts/lpc32xx.dtsi
index 218d9fa..c031c94 100644
--- a/arch/arm/boot/dts/lpc32xx.dtsi
+++ b/arch/arm/boot/dts/lpc32xx.dtsi
@@ -472,6 +472,7 @@
assigned-clocks = <&clk LPC32XX_CLK_PWM1>;
assigned-clock-parents = <&clk LPC32XX_CLK_PERIPH>;
status = "disabled";
+ #pwm-cells = <2>;
};
pwm2: pwm at 4005C004 {
@@ -481,6 +482,7 @@
assigned-clocks = <&clk LPC32XX_CLK_PWM2>;
assigned-clock-parents = <&clk LPC32XX_CLK_PERIPH>;
status = "disabled";
+ #pwm-cells = <2>;
};
timer3: timer at 40060000 {
--
1.8.3.1
^ permalink raw reply related
* [PATCH] ARM: dts: lpc32xx: set pwm1 & pwm2 default clock rate
From: Sylvain Lemieux @ 2016-09-26 18:54 UTC (permalink / raw)
To: linux-arm-kernel
From: Sylvain Lemieux <slemieux@tycoint.com>
Probably most of NXP LPC32xx boards have 13MHz main oscillator
and therefore for HCLK PLL and ARM core clock rate default
hardware setting of 16 * 13MHz = 208MHz and the AHB bus clock
rate of 208MHz / 2 = 104MHz.
The change explicitly defines the peripheral PWM1/PWM2 default
clock output rate of 104MHz. If needed it can be redefined
in a board DTS file.
Signed-off-by: Sylvain Lemieux <slemieux.tyco@gmail.com>
---
Note:
* There is a dependency on the following patch:
"ARM: dts: lpc32xx: set default parent clock for pwm1 & pwm2"
http://www.spinics.net/lists/arm-kernel/msg530277.html
* This patch should be apply after
"ARM: dts: lpc32xx: add pwm-cells to base dts file"
http://www.spinics.net/lists/arm-kernel/msg534050.html
- There is no dependency between the patches.
arch/arm/boot/dts/lpc32xx.dtsi | 2 ++
1 file changed, 2 insertions(+)
diff --git a/arch/arm/boot/dts/lpc32xx.dtsi b/arch/arm/boot/dts/lpc32xx.dtsi
index c031c94..d669200 100644
--- a/arch/arm/boot/dts/lpc32xx.dtsi
+++ b/arch/arm/boot/dts/lpc32xx.dtsi
@@ -471,6 +471,7 @@
clocks = <&clk LPC32XX_CLK_PWM1>;
assigned-clocks = <&clk LPC32XX_CLK_PWM1>;
assigned-clock-parents = <&clk LPC32XX_CLK_PERIPH>;
+ assigned-clock-rates = <104000000>;
status = "disabled";
#pwm-cells = <2>;
};
@@ -481,6 +482,7 @@
clocks = <&clk LPC32XX_CLK_PWM2>;
assigned-clocks = <&clk LPC32XX_CLK_PWM2>;
assigned-clock-parents = <&clk LPC32XX_CLK_PERIPH>;
+ assigned-clock-rates = <104000000>;
status = "disabled";
#pwm-cells = <2>;
};
--
1.8.3.1
^ permalink raw reply related
* [RFC/PATCH] usb: misc: Add a driver for TC7USB40MU
From: Stephen Boyd @ 2016-09-26 18:59 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20160923143513.GA29714@rob-hp-laptop>
Quoting Rob Herring (2016-09-23 07:35:13)
> On Wed, Sep 14, 2016 at 01:55:02AM -0700, Stephen Boyd wrote:
> > Quoting Stephen Boyd (2016-09-13 18:42:46)
> > > On the db410c 96boards platform we have a TC7USB40MU[1] on the
> > > board to mux the D+/D- lines from the SoC between a micro usb
> > > "device" port and a USB hub for "host" roles. Upon a role switch,
> > > we need to change this mux to forward the D+/D- lines to either
> > > the port or the hub. Therefore, introduce a driver for this
> > > device that intercepts extcon USB_HOST events and logically
> > > asserts a gpio to mux the "host" D+/D- lines when a host cable is
> > > attached. When the cable goes away, it will logically deassert
> > > the gpio and mux the "device" lines.
> > >
> > > [1] https://toshiba.semicon-storage.com/ap-en/product/logic/bus-switch/detail.TC7USB40MU.html
> > >
> > > Cc: MyungJoo Ham <myungjoo.ham@samsung.com>
> > > Cc: Chanwoo Choi <cw00.choi@samsung.com>
> > > Cc: <devicetree@vger.kernel.org>
> > > Signed-off-by: Stephen Boyd <stephen.boyd@linaro.org>
> > > ---
> > >
> > > Should I make the extcon part optional? I could see a case where there are two
> > > "OTG" ports connected to the mux (or two hubs), and for some reason the
> > > software may want to mux between them at runtime. If we mandate an extcon,
> > > that won't be possible to support. Perhaps it would be better to have
> > > the node, but connect it to the usb controller with a phandle (maybe of_graph
> > > endpoints would be useful too) so that when the controller wants to mux over
> > > a port it can do so.
>
> I've mentioned my opinion on extcon before. The first clue that it needs
> work is a Linux subsystem name is used for the binding.
>
> > Here's some dts mock-up on top of the db410c for the of_graph stuff. I
> > haven't written any code around it, but the idea is to allow the binding
> > to specify how the mux is connected to upstream and downstream D+/D-
> > lines. This way, we can do some dt parsing of the endpoints and their
> > parent nodes to figure out if the mux needs to be set high or low to use
> > a device connector or a usb hub based on if the id cable is present.
> > Maybe I'm over thinking things though and we could just have a DT
> > property for that.
>
> I think the connector nodes are on the right track, but of-graph doesn't
> work here because we already have a way to describe USB buses in DT.
> Following that, would something like this work for you? The vbus-supply
> and id-gpios are just examples and may not always be there like if the
> hub controls each port's vbus directly.
My philosophical problem with this is that I don't view this usb-switch
as a usb device. It isn't addressable via the typical USB addressing
scheme. It's just a simple chip wired down on the board that muxes two
wires without considering what goes across those wires.
I would agree if this switch was a usb device itself that had a vid/pid
that we could talk to to switch the mux. But that isn't the case here.
>
> usb-controller at 1234 {
> usb-switch at 0 {
> compatible = "toshiba,tc7usb40mu";
> hub at 0 {
> compatible = "some-hub";
> port at 0 {
> compatible = "usb-A-connector"
> vbus-supply = ...;
> };
> port at 1 {
> compatible = "usb-A-connector"
> vbus-supply = ...;
> };
>
> };
> connector at 1 {
> compatible = "usb-ub-connector";
> vbus-supply = ...;
> id-gpios = <>;
> };
> };
> };
>
What do we do about a hub downstream of the mux like usb3503? If that's
on the i2c bus and we need to do some initial setup, shouldn't we put
the hub under the i2c bus (because that's the addressing scheme) instead
of under the switch and then use of-graph to describe the connections
that aren't being used for addressing? My understanding of of-graph is
pretty weak so perhaps I missed something.
^ permalink raw reply
* [PATCH v2] ARM: dts: socfpga: Add Macnica sodia board
From: Dinh Nguyen @ 2016-09-26 19:19 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20160924235945.32128-1-iwamatsu@nigauri.org>
On 09/24/2016 06:59 PM, Nobuhiro Iwamatsu wrote:
> Add support for board based on the Altera Cyclone V SoC.
> This board has the following functions:
> - 1 GiB of DRAM
> - 1 Gigabit ethernet
> - 1 SD card slot
> - 1 USB gadget port
> - QSPI NOR Flash
> - I2C EEPROMs and I2C RTC
> - DVI output
> - Audio port
>
> This commit supports without QSPI, DVI and Audio.
>
> Signed-off-by: Nobuhiro Iwamatsu <iwamatsu@nigauri.org>
> ---
> V2: move the PHY of setting to the Ethetnet PHY node level.
>
Applied. Thanks!
Dinh
^ 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