* [PATCH] DTS: MCCMON6: IMX: Provide support for iMX6Q based Liebherr mccmon6 board
From: Vladimir Zapolskiy @ 2017-01-02 19:12 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20170102154437.63406b95@jawa>
Hi Lukasz,
please find some comments below as usual.
On 01/02/2017 04:44 PM, Lukasz Majewski wrote:
> Hi Vladimir,
>
> Thank you for review. Comments without my remarks have been applied
> already.
>
>> Hello Lukasz,
>>
>> On 12/27/2016 01:19 AM, Lukasz Majewski wrote:
>>> Signed-off-by: Lukasz Majewski <l.majewski@majess.pl>
>>
>> please add a commit message with a short description of the change.
>>
>> Also change subject line to "ARM: dts: imx6q: Add mccmon6 board
>> support".
>>
>>> ---
[snip]
>>> +/ {
>>> + model = "Monitor6 i.MX6 Quad Board";
>>
>> Missing hardware vendor name.
>>
>>> + compatible = "mccmon6", "fsl,imx6q";
>>
>> Missing hardware vendor prefix before "mccmon6".
>
> "lwn,mccmon6" ?
>
Something like that, but please ensure that you add "lwn" vendor in a separate
preceding change to Documentation/devicetree/bindings/vendor-prefixes.txt
>>
>>> +
>>> + memory {
>>> + reg = <0x10000000 0x80000000>;
>>> + };
>>> +
>>> + ethernet0 {
>>> + status = "okay";
>>> + };
>>
>> It looks like a useless device node, you have a description of &fec
>> already.
>>
>>> +
>>> + backlight_lvds: backlight {
>>> + compatible = "pwm-backlight";
>>> + pinctrl-names = "default";
>>> + pinctrl-0 = <&pinctrl_display>;
>>
>> I would recommend to rename "pinctrl_display" to "pinctrl_backlight".
>>
>>> + pwms = <&pwm2 0 5000000 PWM_POLARITY_INVERTED>;
>>
>> This should work when extension to the i.MX PWM driver is merged.
>
> Yes. The PWM -> apply is an ongoing work. But without the PMW patch the
> board is also fully operational (with reversed PWM :-) )
>
Right, I believe that the current PWM driver igonores the value passed
in the third cell, so it should be okay.
>>
>>> + brightness-levels = < 0 1 2 3 4 5 6
>>> 7 8 9
>>> + 10 11 12 13 14 15 16
>>> 17 18 19
>>> + 20 21 22 23 24 25 26
>>> 27 28 29
>>> + 30 31 32 33 34 35 36
>>> 37 38 39
>>> + 40 41 42 43 44 45 46
>>> 47 48 49
>>> + 50 51 52 53 54 55 56
>>> 57 58 59
>>> + 60 61 62 63 64 65 66
>>> 67 68 69
>>> + 70 71 72 73 74 75 76
>>> 77 78 79
>>> + 80 81 82 83 84 85 86
>>> 87 88 89
>>> + 90 91 92 93 94 95 96
>>> 97 98 99
>>> + 100 101 102 103 104 105 106
>>> 107 108 109
>>> + 110 111 112 113 114 115 116
>>> 117 118 119
>>> + 120 121 122 123 124 125 126
>>> 127 128 129
>>> + 130 131 132 133 134 135 136
>>> 137 138 139
>>> + 140 141 142 143 144 145 146
>>> 147 148 149
>>> + 150 151 152 153 154 155 156
>>> 157 158 159
>>> + 160 161 162 163 164 165 166
>>> 167 168 169
>>> + 170 171 172 173 174 175 176
>>> 177 178 179
>>> + 180 181 182 183 184 185 186
>>> 187 188 189
>>> + 190 191 192 193 194 195 196
>>> 197 198 199
>>> + 200 201 202 203 204 205 206
>>> 207 208 209
>>> + 210 211 212 213 214 215 216
>>> 217 218 219
>>> + 220 221 222 223 224 225 226
>>> 227 228 229
>>> + 230 231 232 233 234 235 236
>>> 237 238 239
>>> + 240 241 242 243 244 245 246
>>> 247 248 249
>>> + 250 251 252 253 254 255>;
>>
>> I'm not sure that actually need such a long list of brightness levels.
>
> Such brightness-level property is so verbose on purpose - in this board
> we need fine brightness adjustment (harsh environment operation).
Okay.
>>
>>> + default-brightness-level = <50>;
>>> + enable-gpios = <&gpio1 2 GPIO_ACTIVE_LOW>;
>>> + };
>>> +
[snip]
>>> + pinctrl_display: dispgrp {
>>> + fsl,pins = <
>>> + /* BLEN_OUT */
>>> + MX6QDL_PAD_GPIO_2__GPIO1_IO02
>>> 0x1b0b0
>>> + /* LVDS_PPEN_OUT */
>>> + MX6QDL_PAD_SD1_DAT2__GPIO1_IO19
>>> 0x1b0b0
>>
>> This GPIO should be moved to a pinctrl group of regulator-lvds device
>> node.
>
> You mean to provide separate:
>
> pinctrl_reg_lvds: req_lvds_grp {
> fsl,pins = <
> /* LVDS_PPEN_OUT */
> MX6QDL_PAD_SD1_DAT2__GPIO1_IO19
> >;
>
> and then
>
> reg_lvds: regulator-lvds {
> compatible = "regulator-fixed";
> regulator-name = "lvds_ppen";
> regulator-min-microvolt = <3300000>;
> regulator-max-microvolt = <3300000>;
> regulator-boot-on;
>
> pinctrl-names = "default";
> pinctrl-0 = <&pinctrl_reg_lvds>;
>
> gpio = <&gpio1 19 GPIO_ACTIVE_HIGH>;
> enable-active-high;
> };
>
This looks correct.
[snip]
>>> +
>>> +&uart1 {
>>> + pinctrl-names = "default";
>>> + pinctrl-0 = <&pinctrl_uart1>;
>>
>> Should you add "uart-has-rtscts" property?
>
> This is a simple "console" uart without rts/cts, so this property is
> not needed.
>
You are right, my review comment is valid for UART4 only.
[snip]
--
With best wishes,
Vladimir
^ permalink raw reply
* [GIT PULL] Qualcomm ARM DT Fixes for 4.10-rc2
From: Andy Gross @ 2017-01-02 20:03 UTC (permalink / raw)
To: linux-arm-kernel
The following changes since commit 0c744ea4f77d72b3dcebb7a8f2684633ec79be88:
Linux 4.10-rc2 (2017-01-01 14:31:53 -0800)
are available in the git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/agross/linux.git tags/qcom-arm-fixes-for-4.10-rc2
for you to fetch changes up to 542b9f0759ed74ca0f1a9f3ff090c95ea73eba91:
ARM: dts: qcom: apq8064: Add missing scm clock (2017-01-02 10:47:10 -0600)
----------------------------------------------------------------
Qualcomm ARM DTS Fixes for v4.10-rc2
* Add SCM clock for APQ8064 to fix boot failures
----------------------------------------------------------------
Bjorn Andersson (1):
ARM: dts: qcom: apq8064: Add missing scm clock
arch/arm/boot/dts/qcom-apq8064.dtsi | 4 ++++
1 file changed, 4 insertions(+)
^ permalink raw reply
* [PATCH 15/20] ARM/hw_breakpoint: Convert to hotplug state machine
From: Linus Walleij @ 2017-01-02 20:15 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20170102150015.GJ14217@n2100.armlinux.org.uk>
On Mon, Jan 2, 2017 at 4:00 PM, Russell King - ARM Linux
<linux@armlinux.org.uk> wrote:
> On Mon, Jan 02, 2017 at 03:34:32PM +0100, Linus Walleij wrote:
>> in the first line of arch_hw_breakpoint_init() in
>> arch/arm/kernel/hw_breakpoint.c
>>
>> I suspect that is not an accepable solution ...
>>
>> It hangs at PC is at write_wb_reg+0x20c/0x330
>> Which is c03101dc, and looks like this in objdump -d:
>>
>> c031020c: ee001eba mcr 14, 0, r1, cr0, cr10, {5}
>> c0310210: eaffffb3 b c03100e4 <write_wb_reg+0x114>
>
> ... and this is several instructions after the address you mention above.
> Presumably c03101dc is accessing a higher numbered register?
Ah sorry. It looks like this:
c03101dc: ee001ed0 mcr 14, 0, r1, cr0, cr0, {6}
c03101e0: eaffffbf b c03100e4 <write_wb_reg+0x114>
c03101e4: ee001ebf mcr 14, 0, r1, cr0, cr15, {5}
c03101e8: eaffffbd b c03100e4 <write_wb_reg+0x114>
c03101ec: ee001ebe mcr 14, 0, r1, cr0, cr14, {5}
c03101f0: eaffffbb b c03100e4 <write_wb_reg+0x114>
c03101f4: ee001ebd mcr 14, 0, r1, cr0, cr13, {5}
c03101f8: eaffffb9 b c03100e4 <write_wb_reg+0x114>
Yours,
Linus Walleij
^ permalink raw reply
* [PATCH] ARM: multi_v7_defconfig: enable Qualcomm RPMCC
From: Andy Gross @ 2017-01-02 20:35 UTC (permalink / raw)
To: linux-arm-kernel
This patch enables the Qualcomm RPM based Clock Controller present on
A-family boards.
Signed-off-by: Andy Gross <andy.gross@linaro.org>
---
arch/arm/configs/multi_v7_defconfig | 1 +
1 file changed, 1 insertion(+)
diff --git a/arch/arm/configs/multi_v7_defconfig b/arch/arm/configs/multi_v7_defconfig
index b01a438..4ff6779 100644
--- a/arch/arm/configs/multi_v7_defconfig
+++ b/arch/arm/configs/multi_v7_defconfig
@@ -824,6 +824,7 @@ CONFIG_QCOM_SMSM=y
CONFIG_QCOM_WCNSS_CTRL=m
CONFIG_ROCKCHIP_PM_DOMAINS=y
CONFIG_COMMON_CLK_QCOM=y
+CONFIG_QCOM_CLK_RPM=y
CONFIG_CHROME_PLATFORMS=y
CONFIG_STAGING_BOARD=y
CONFIG_CROS_EC_CHARDEV=m
--
1.9.1
^ permalink raw reply related
* [PATCH 1/3] ARM: OMAP1: USB: tidy up logging output
From: Aaro Koskinen @ 2017-01-02 20:57 UTC (permalink / raw)
To: linux-arm-kernel
KERN_CONT/pr_cont is now required to continue log messages, use that.
Signed-off-by: Aaro Koskinen <aaro.koskinen@iki.fi>
---
arch/arm/mach-omap1/usb.c | 20 ++++++++++----------
1 file changed, 10 insertions(+), 10 deletions(-)
diff --git a/arch/arm/mach-omap1/usb.c b/arch/arm/mach-omap1/usb.c
index 2506e59..d4aa118 100644
--- a/arch/arm/mach-omap1/usb.c
+++ b/arch/arm/mach-omap1/usb.c
@@ -95,17 +95,17 @@ omap_otg_init(struct omap_usb_config *config)
printk("USB: hmc %d", config->hmc_mode);
if (!alt_pingroup)
- printk(", usb2 alt %d wires", config->pins[2]);
+ pr_cont(", usb2 alt %d wires", config->pins[2]);
else if (config->pins[0])
- printk(", usb0 %d wires%s", config->pins[0],
+ pr_cont(", usb0 %d wires%s", config->pins[0],
is_usb0_device(config) ? " (dev)" : "");
if (config->pins[1])
- printk(", usb1 %d wires", config->pins[1]);
+ pr_cont(", usb1 %d wires", config->pins[1]);
if (!alt_pingroup && config->pins[2])
- printk(", usb2 %d wires", config->pins[2]);
+ pr_cont(", usb2 %d wires", config->pins[2]);
if (config->otg)
- printk(", Mini-AB on usb%d", config->otg - 1);
- printk("\n");
+ pr_cont(", Mini-AB on usb%d", config->otg - 1);
+ pr_cont("\n");
if (cpu_class_is_omap1()) {
u16 w;
@@ -573,13 +573,13 @@ static void __init omap_1510_usb_init(struct omap_usb_config *config)
printk("USB: hmc %d", config->hmc_mode);
if (config->pins[0])
- printk(", usb0 %d wires%s", config->pins[0],
+ pr_cont(", usb0 %d wires%s", config->pins[0],
is_usb0_device(config) ? " (dev)" : "");
if (config->pins[1])
- printk(", usb1 %d wires", config->pins[1]);
+ pr_cont(", usb1 %d wires", config->pins[1]);
if (config->pins[2])
- printk(", usb2 %d wires", config->pins[2]);
- printk("\n");
+ pr_cont(", usb2 %d wires", config->pins[2]);
+ pr_cont("\n");
/* use DPLL for 48 MHz function clock */
pr_debug("APLL %04x DPLL %04x REQ %04x\n", omap_readw(ULPD_APLL_CTRL),
--
2.9.2
^ permalink raw reply related
* [PATCH 2/3] ARM: OMAP1: USB: make omap_otg_init() static
From: Aaro Koskinen @ 2017-01-02 20:57 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20170102205705.19001-1-aaro.koskinen@iki.fi>
Make omap_otg_init() static.
Signed-off-by: Aaro Koskinen <aaro.koskinen@iki.fi>
---
arch/arm/mach-omap1/include/mach/usb.h | 2 --
arch/arm/mach-omap1/usb.c | 4 ++--
2 files changed, 2 insertions(+), 4 deletions(-)
diff --git a/arch/arm/mach-omap1/include/mach/usb.h b/arch/arm/mach-omap1/include/mach/usb.h
index a7c5559..eb76628 100644
--- a/arch/arm/mach-omap1/include/mach/usb.h
+++ b/arch/arm/mach-omap1/include/mach/usb.h
@@ -10,8 +10,6 @@
#include <linux/platform_data/usb-omap1.h>
-void omap_otg_init(struct omap_usb_config *config);
-
#if IS_ENABLED(CONFIG_USB)
void omap1_usb_init(struct omap_usb_config *pdata);
#else
diff --git a/arch/arm/mach-omap1/usb.c b/arch/arm/mach-omap1/usb.c
index d4aa118..0b4ed94 100644
--- a/arch/arm/mach-omap1/usb.c
+++ b/arch/arm/mach-omap1/usb.c
@@ -58,7 +58,7 @@
#ifdef CONFIG_ARCH_OMAP_OTG
-void __init
+static void __init
omap_otg_init(struct omap_usb_config *config)
{
u32 syscon;
@@ -166,7 +166,7 @@ omap_otg_init(struct omap_usb_config *config)
}
#else
-void omap_otg_init(struct omap_usb_config *config) {}
+static void omap_otg_init(struct omap_usb_config *config) {}
#endif
#if IS_ENABLED(CONFIG_USB_OMAP)
--
2.9.2
^ permalink raw reply related
* [PATCH 3/3] ARM: OMAP1: USB: delete redundant CPU class checks
From: Aaro Koskinen @ 2017-01-02 20:57 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20170102205705.19001-1-aaro.koskinen@iki.fi>
Delete redundant CPU class checks. This code is only used
on OMAP1 nowadays.
Signed-off-by: Aaro Koskinen <aaro.koskinen@iki.fi>
---
arch/arm/mach-omap1/usb.c | 27 ++++++++++++---------------
1 file changed, 12 insertions(+), 15 deletions(-)
diff --git a/arch/arm/mach-omap1/usb.c b/arch/arm/mach-omap1/usb.c
index 0b4ed94..455e2cf 100644
--- a/arch/arm/mach-omap1/usb.c
+++ b/arch/arm/mach-omap1/usb.c
@@ -1,5 +1,5 @@
/*
- * Platform level USB initialization for FS USB OTG controller on omap1 and 24xx
+ * Platform level USB initialization for FS USB OTG controller on omap1
*
* Copyright (C) 2004 Texas Instruments, Inc.
*
@@ -63,6 +63,7 @@ omap_otg_init(struct omap_usb_config *config)
{
u32 syscon;
int alt_pingroup = 0;
+ u16 w;
/* NOTE: no bus or clock setup (yet?) */
@@ -87,9 +88,8 @@ omap_otg_init(struct omap_usb_config *config)
if (config->otg)
syscon |= OTG_EN;
#endif
- if (cpu_class_is_omap1())
- pr_debug("USB_TRANSCEIVER_CTRL = %03x\n",
- omap_readl(USB_TRANSCEIVER_CTRL));
+ pr_debug("USB_TRANSCEIVER_CTRL = %03x\n",
+ omap_readl(USB_TRANSCEIVER_CTRL));
pr_debug("OTG_SYSCON_2 = %08x\n", omap_readl(OTG_SYSCON_2));
omap_writel(syscon, OTG_SYSCON_2);
@@ -107,19 +107,16 @@ omap_otg_init(struct omap_usb_config *config)
pr_cont(", Mini-AB on usb%d", config->otg - 1);
pr_cont("\n");
- if (cpu_class_is_omap1()) {
- u16 w;
+ /* leave USB clocks/controllers off until needed */
+ w = omap_readw(ULPD_SOFT_REQ);
+ w &= ~SOFT_USB_CLK_REQ;
+ omap_writew(w, ULPD_SOFT_REQ);
- /* leave USB clocks/controllers off until needed */
- w = omap_readw(ULPD_SOFT_REQ);
- w &= ~SOFT_USB_CLK_REQ;
- omap_writew(w, ULPD_SOFT_REQ);
+ w = omap_readw(ULPD_CLOCK_CTRL);
+ w &= ~USB_MCLK_EN;
+ w |= DIS_USB_PVCI_CLK;
+ omap_writew(w, ULPD_CLOCK_CTRL);
- w = omap_readw(ULPD_CLOCK_CTRL);
- w &= ~USB_MCLK_EN;
- w |= DIS_USB_PVCI_CLK;
- omap_writew(w, ULPD_CLOCK_CTRL);
- }
syscon = omap_readl(OTG_SYSCON_1);
syscon |= HST_IDLE_EN|DEV_IDLE_EN|OTG_IDLE_EN;
--
2.9.2
^ permalink raw reply related
* [PATCH 1/5] ARM: wire up HWCAP2 feature bits to the CPU modalias
From: Ard Biesheuvel @ 2017-01-02 21:06 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161031161319.GF1041@n2100.armlinux.org.uk>
On 31 October 2016 at 16:13, Russell King - ARM Linux
<linux@armlinux.org.uk> wrote:
> On Sat, Oct 29, 2016 at 11:08:36AM +0100, Ard Biesheuvel wrote:
>> On 18 October 2016 at 11:52, Ard Biesheuvel <ard.biesheuvel@linaro.org> wrote:
>> > Wire up the generic support for exposing CPU feature bits via the
>> > modalias in /sys/device/system/cpu. This allows udev to automatically
>> > load modules for things like crypto algorithms that are implemented
>> > using optional instructions.
>> >
>> > Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
>> > ---
>> > arch/arm/Kconfig | 1 +
>> > arch/arm/include/asm/cpufeature.h | 32 ++++++++++++++++++++
>> > 2 files changed, 33 insertions(+)
>> >
>>
>> Russell,
>>
>> do you have any concerns regarding this patch? If not, I will drop it
>> into the patch system.
>
> It's still something I need to look at... I've been offline last week,
> and sort-of offline the previous week, so I'm catching up.
>
Hi Russell,
Any thoughts yet?
Thanks,
Ard.
^ permalink raw reply
* [PATCH 00/20] i.MX Media Driver
From: Fabio Estevam @ 2017-01-02 21:09 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1483050455-10683-1-git-send-email-steve_longerbeam@mentor.com>
Hi Steve,
On Thu, Dec 29, 2016 at 8:27 PM, Steve Longerbeam <slongerbeam@gmail.com> wrote:
> This is a media driver for video capture on i.MX.
>
> Refer to Documentation/media/v4l-drivers/imx.rst for example capture
> pipelines on SabreSD, SabreAuto, and SabreLite reference platforms.
>
> This patchset includes the OF graph layout as proposed by Philipp Zabel,
> with only minor changes which are enumerated in the patch header.
Patches 13, 14 and 19 miss your Signed-off-by tag.
Tested the whole series on a mx6qsabresd:
Tested-by: Fabio Estevam <fabio.estevam@nxp.com>
^ permalink raw reply
* [PATCH v6 09/14] ACPI: platform: setup MSI domain for ACPI based platform device
From: Rafael J. Wysocki @ 2017-01-02 21:17 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1483363905-2806-10-git-send-email-hanjun.guo@linaro.org>
On Mon, Jan 2, 2017 at 2:31 PM, Hanjun Guo <hanjun.guo@linaro.org> wrote:
> With the platform msi domain created, we can set up the msi domain
> for a platform device when it's probed.
>
> In order to do that, we need to get the domain that the platform
> device connecting to, so the iort_get_platform_device_domain() is
> introduced to retrieve the domain from iort.
>
> After the domain is retrieved, we need a proper way to set the
> domain to paltform device, as some platform devices such as an
> irqchip needs the msi irqdomain to be the interrupt parent domain,
> we need to get irqdomain before platform device is probed but after
> the platform device is allocated (the time slot of setting the
> msi domain also works for other cases). So simply call
> acpi_configure_pmsi_domain() in acpi_platform_notify() for
> platform devices will work.
>
> Signed-off-by: Hanjun Guo <hanjun.guo@linaro.org>
> Cc: Rafael J. Wysocki <rjw@rjwysocki.net>
> Cc: Marc Zyngier <marc.zyngier@arm.com>
> Cc: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>
ACK for the glue.c part.
> ---
> drivers/acpi/arm64/iort.c | 43 +++++++++++++++++++++++++++++++++++++++++++
> drivers/acpi/glue.c | 6 ++++++
> include/linux/acpi_iort.h | 3 +++
> 3 files changed, 52 insertions(+)
>
> diff --git a/drivers/acpi/arm64/iort.c b/drivers/acpi/arm64/iort.c
> index bc68d93..6b72fcb 100644
> --- a/drivers/acpi/arm64/iort.c
> +++ b/drivers/acpi/arm64/iort.c
> @@ -527,6 +527,49 @@ struct irq_domain *iort_get_device_domain(struct device *dev, u32 req_id)
> return irq_find_matching_fwnode(handle, DOMAIN_BUS_PCI_MSI);
> }
>
> +/**
> + * iort_get_platform_device_domain() - Find MSI domain related to a
> + * platform device
> + * @dev: the dev pointer associated with the platform device
> + *
> + * Returns: the MSI domain for this device, NULL otherwise
> + */
> +static struct irq_domain *iort_get_platform_device_domain(struct device *dev)
> +{
> + struct acpi_iort_node *node, *msi_parent;
> + struct fwnode_handle *iort_fwnode;
> + struct acpi_iort_its_group *its;
> +
> + /* find its associated iort node */
> + node = iort_scan_node(ACPI_IORT_NODE_NAMED_COMPONENT,
> + iort_match_node_callback, dev);
> + if (!node)
> + return NULL;
> +
> + /* then find its msi parent node */
> + msi_parent = iort_node_get_id(node, NULL, IORT_MSI_TYPE, 0);
> + if (!msi_parent)
> + return NULL;
> +
> + /* Move to ITS specific data */
> + its = (struct acpi_iort_its_group *)msi_parent->node_data;
> +
> + iort_fwnode = iort_find_domain_token(its->identifiers[0]);
> + if (!iort_fwnode)
> + return NULL;
> +
> + return irq_find_matching_fwnode(iort_fwnode, DOMAIN_BUS_PLATFORM_MSI);
> +}
> +
> +void acpi_configure_pmsi_domain(struct device *dev)
> +{
> + struct irq_domain *msi_domain;
> +
> + msi_domain = iort_get_platform_device_domain(dev);
> + if (msi_domain)
> + dev_set_msi_domain(dev, msi_domain);
> +}
> +
> static int __get_pci_rid(struct pci_dev *pdev, u16 alias, void *data)
> {
> u32 *rid = data;
> diff --git a/drivers/acpi/glue.c b/drivers/acpi/glue.c
> index f8d6564..4a73f27 100644
> --- a/drivers/acpi/glue.c
> +++ b/drivers/acpi/glue.c
> @@ -6,6 +6,8 @@
> *
> * This file is released under the GPLv2.
> */
> +
> +#include <linux/acpi_iort.h>
> #include <linux/export.h>
> #include <linux/init.h>
> #include <linux/list.h>
> @@ -14,6 +16,7 @@
> #include <linux/rwsem.h>
> #include <linux/acpi.h>
> #include <linux/dma-mapping.h>
> +#include <linux/platform_device.h>
>
> #include "internal.h"
>
> @@ -315,6 +318,9 @@ static int acpi_platform_notify(struct device *dev)
> if (!adev)
> goto out;
>
> + if (dev->bus == &platform_bus_type)
> + acpi_configure_pmsi_domain(dev);
> +
> if (type && type->setup)
> type->setup(dev);
> else if (adev->handler && adev->handler->bind)
> diff --git a/include/linux/acpi_iort.h b/include/linux/acpi_iort.h
> index ef99fd52..33f5ac3 100644
> --- a/include/linux/acpi_iort.h
> +++ b/include/linux/acpi_iort.h
> @@ -38,6 +38,7 @@
> /* IOMMU interface */
> void iort_set_dma_mask(struct device *dev);
> const struct iommu_ops *iort_iommu_configure(struct device *dev);
> +void acpi_configure_pmsi_domain(struct device *dev);
> #else
> static inline void acpi_iort_init(void) { }
> static inline bool iort_node_match(u8 type) { return false; }
> @@ -58,6 +59,8 @@ static inline void iort_set_dma_mask(struct device *dev) { }
> static inline
> const struct iommu_ops *iort_iommu_configure(struct device *dev)
> { return NULL; }
> +
> +static inline void acpi_configure_pmsi_domain(struct device *dev) { }
> #endif
>
> #define IORT_ACPI_DECLARE(name, table_id, fn) \
> --
> 1.9.1
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-acpi" in
> the body of a message to majordomo at vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* [PATCH] cpufreq: s3c64xx: remove incorrect __init annotation
From: Rafael J. Wysocki @ 2017-01-02 21:19 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20170102173651.hvsfalhcmisv4mtv@kozik-lap>
On Mon, Jan 2, 2017 at 6:36 PM, Krzysztof Kozlowski <krzk@kernel.org> wrote:
> On Mon, Jan 02, 2017 at 12:39:03PM +0530, Viresh Kumar wrote:
>> On 16-12-16, 10:06, Arnd Bergmann wrote:
>> > s3c64xx_cpufreq_config_regulator is incorrectly annotated
>> > as __init, since the caller is also not init:
>> >
>> > WARNING: vmlinux.o(.text+0x92fe1c): Section mismatch in reference from the function s3c64xx_cpufreq_driver_init() to the function .init.text:s3c64xx_cpufreq_config_regulator()
>> >
>> > With modern gcc versions, the function gets inline, so we don't
>> > see the warning, this only happens with gcc-4.6 and older.
>> >
>> > Signed-off-by: Arnd Bergmann <arnd@arndb.de>
>> > ---
>> > drivers/cpufreq/s3c64xx-cpufreq.c | 2 +-
>> > 1 file changed, 1 insertion(+), 1 deletion(-)
>> >
>> > diff --git a/drivers/cpufreq/s3c64xx-cpufreq.c b/drivers/cpufreq/s3c64xx-cpufreq.c
>> > index 176e84cc3991..0cb9040eca49 100644
>> > --- a/drivers/cpufreq/s3c64xx-cpufreq.c
>> > +++ b/drivers/cpufreq/s3c64xx-cpufreq.c
>> > @@ -107,7 +107,7 @@ static int s3c64xx_cpufreq_set_target(struct cpufreq_policy *policy,
>> > }
>> >
>> > #ifdef CONFIG_REGULATOR
>> > -static void __init s3c64xx_cpufreq_config_regulator(void)
>> > +static void s3c64xx_cpufreq_config_regulator(void)
>> > {
>> > int count, v, i, found;
>> > struct cpufreq_frequency_table *freq;
>>
>> Acked-by: Viresh Kumar <viresh.kumar@linaro.org>
>
> Rafael,
> Are you going to pick it up?
I thought I did, didn't I?
Thanks,
Rafael
^ permalink raw reply
* [PATCH 0/2] ARM: orion5x: Move micon code to a MFD driver
From: Andrew Lunn @ 2017-01-02 21:24 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161229000137.5553-1-f.fainelli@gmail.com>
On Wed, Dec 28, 2016 at 04:01:35PM -0800, Florian Fainelli wrote:
> Hi all,
>
> This patch series removes some duplicate code between the Kurobox and the
> Terastation Pro 2 since they both use the same on-board microcontroller (micon)
> attached to their UART1 for system restart.
>
> Future patches will add support for the LEDs, temperature, FAN that the micro
> controller provides.
Hi Florian
Are you coordinating with Roger Shimizu <rogershimizu@gmail.com>. He
has a conflicting patchset doing something similar/different.
Andrew
^ permalink raw reply
* [PATCH v6 10/14] ACPI: ARM64: IORT: rework iort_node_get_id() for NC->SMMU->ITS case
From: Sinan Kaya @ 2017-01-02 22:30 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1483363905-2806-11-git-send-email-hanjun.guo@linaro.org>
Hi Hanjun,
On 1/2/2017 8:31 AM, Hanjun Guo wrote:
> iort_node_get_id() for now only support NC(named componant)->SMMU
> or NC->ITS cases, we also have other device topology such NC->
> SMMU->ITS, so rework iort_node_get_id() for those cases.
>
> Signed-off-by: Hanjun Guo <hanjun.guo@linaro.org>
> Tested-by: Majun <majun258@huawei.com>
> Tested-by: Xinwei Kong <kong.kongxinwei@hisilicon.com>
> Cc: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>
> ---
> drivers/acpi/arm64/iort.c | 61 ++++++++++++++++++++++++++---------------------
> 1 file changed, 34 insertions(+), 27 deletions(-)
>
> diff --git a/drivers/acpi/arm64/iort.c b/drivers/acpi/arm64/iort.c
> index 6b72fcb..99f079b 100644
> --- a/drivers/acpi/arm64/iort.c
> +++ b/drivers/acpi/arm64/iort.c
> @@ -292,22 +292,28 @@ static acpi_status iort_match_node_callback(struct acpi_iort_node *node,
> return status;
> }
>
> -static int iort_id_map(struct acpi_iort_id_mapping *map, u8 type, u32 rid_in,
> - u32 *rid_out)
> +static int iort_id_single_map(struct acpi_iort_id_mapping *map, u8 type,
> + u32 *rid_out)
> {
> /* Single mapping does not care for input id */
> if (map->flags & ACPI_IORT_ID_SINGLE_MAPPING) {
> if (type == ACPI_IORT_NODE_NAMED_COMPONENT ||
> type == ACPI_IORT_NODE_PCI_ROOT_COMPLEX) {
> - *rid_out = map->output_base;
> + if (rid_out)
> + *rid_out = map->output_base;
> return 0;
> }
>
> pr_warn(FW_BUG "[map %p] SINGLE MAPPING flag not allowed for node type %d, skipping ID map\n",
> map, type);
> - return -ENXIO;
> }
>
> + return -ENXIO;
> +}
> +
> +static int iort_id_map(struct acpi_iort_id_mapping *map, u32 rid_in,
> + u32 *rid_out)
> +{
> if (rid_in < map->input_base ||
> (rid_in >= map->input_base + map->id_count))
> return -ENXIO;
> @@ -324,33 +330,34 @@ struct acpi_iort_node *iort_node_get_id(struct acpi_iort_node *node,
> struct acpi_iort_node *parent;
> struct acpi_iort_id_mapping *map;
>
> - if (!node->mapping_offset || !node->mapping_count ||
> - index >= node->mapping_count)
> - return NULL;
> -
> - map = ACPI_ADD_PTR(struct acpi_iort_id_mapping, node,
> - node->mapping_offset);
> + while (node) {
> + if (!node->mapping_offset || !node->mapping_count ||
> + index >= node->mapping_count)
> + return NULL;
>
> - /* Firmware bug! */
> - if (!map->output_reference) {
> - pr_err(FW_BUG "[node %p type %d] ID map has NULL parent reference\n",
> - node, node->type);
> - return NULL;
> - }
> + map = ACPI_ADD_PTR(struct acpi_iort_id_mapping, node,
> + node->mapping_offset);
>
> - parent = ACPI_ADD_PTR(struct acpi_iort_node, iort_table,
> - map->output_reference);
> + /* Firmware bug! */
> + if (!map->output_reference) {
> + pr_err(FW_BUG "[node %p type %d] ID map has NULL parent reference\n",
> + node, node->type);
> + return NULL;
> + }
>
> - if (!(IORT_TYPE_MASK(parent->type) & type_mask))
> - return NULL;
> + parent = ACPI_ADD_PTR(struct acpi_iort_node, iort_table,
> + map->output_reference);
>
> - if (map[index].flags & ACPI_IORT_ID_SINGLE_MAPPING) {
> - if (node->type == ACPI_IORT_NODE_NAMED_COMPONENT ||
> - node->type == ACPI_IORT_NODE_PCI_ROOT_COMPLEX) {
> - if (id_out)
> - *id_out = map[index].output_base;
> - return parent;
> + /* go upstream to find its parent */
> + if (!(IORT_TYPE_MASK(parent->type) & type_mask)) {
> + node = parent;
> + continue;
> }
> +
> + if (iort_id_single_map(&map[index], node->type, id_out))
> + break;
> +
> + return parent;
> }
>
> return NULL;
> @@ -388,7 +395,7 @@ static struct acpi_iort_node *iort_node_map_rid(struct acpi_iort_node *node,
>
> /* Do the RID translation */
> for (i = 0; i < node->mapping_count; i++, map++) {
> - if (!iort_id_map(map, node->type, rid, &rid))
> + if (!iort_id_map(map, rid, &rid))
> break;
> }
>
>
I wanted to follow up on your note for NC->SMMU->ITS case as I do have this use case on the
Qualcomm QDF2400 server and HIDMA DMA Engine. HIDMA is capable of sending MSI interrupts
towards the GIC ITS.
I don't know if this patch is supposed to fix the NC->SMMU->ITS case as it suggests in the commit
message but it doesn't seems to be working for me. Maybe, it was a to do for you. It wasn't quite
clear from the commit.
I debugged the code and came up with the following patch. Feel free to incorporate/rework with
your existing patch.
A named node can have an output ID of 0x20 and SMMU can have an output
parameter of 0x80000. The device ID needs to be 0x80000+0x20 for this
use case.
With the addition of this patch on top of the first 11 patches, I'm also providing my tested by here
for the first 11 patches.
Tested-by: Sinan Kaya <okaya@codeaurora.org>
--
Sinan Kaya
Qualcomm Datacenter Technologies, Inc. as an affiliate of Qualcomm Technologies, Inc.
Qualcomm Technologies, Inc. is a member of the Code Aurora Forum, a Linux Foundation Collaborative Project.
-------------- next part --------------
>From c5ab7172a400bfd5b460374e70394fe78c260603 Mon Sep 17 00:00:00 2001
From: Sinan Kaya <okaya@codeaurora.org>
Date: Mon, 2 Jan 2017 17:16:45 -0500
Subject: [PATCH] ACPI: ARM64: IORT: rework iort_node_get_id() for
NC->SMMU->ITS case part #2
Code won't collect the output ID as it traverses NC->SMMU->ITS path.
Adding support for this use case.
A named node can have an output ID of 0x20 and SMMU can have an output
parameter of 0x80000. The device ID needs to be 0x80000+0x20 for this
use case.
Signed-off-by: Sinan Kaya <okaya@codeaurora.org>
---
drivers/acpi/arm64/iort.c | 58 ++++++++++++++++++++++++++---------------------
1 file changed, 32 insertions(+), 26 deletions(-)
diff --git a/drivers/acpi/arm64/iort.c b/drivers/acpi/arm64/iort.c
index 882e624..19cb97a 100644
--- a/drivers/acpi/arm64/iort.c
+++ b/drivers/acpi/arm64/iort.c
@@ -296,18 +296,16 @@ static int iort_id_single_map(struct acpi_iort_id_mapping *map, u8 type,
u32 *rid_out)
{
/* Single mapping does not care for input id */
- if (map->flags & ACPI_IORT_ID_SINGLE_MAPPING) {
- if (type == ACPI_IORT_NODE_NAMED_COMPONENT ||
- type == ACPI_IORT_NODE_PCI_ROOT_COMPLEX) {
- if (rid_out)
- *rid_out = map->output_base;
- return 0;
- }
-
- pr_warn(FW_BUG "[map %p] SINGLE MAPPING flag not allowed for node type %d, skipping ID map\n",
- map, type);
+ if (type == ACPI_IORT_NODE_NAMED_COMPONENT ||
+ type == ACPI_IORT_NODE_PCI_ROOT_COMPLEX) {
+ if (rid_out)
+ *rid_out = map->output_base;
+ return 0;
}
+ pr_warn(FW_BUG "[map %p] SINGLE MAPPING flag not allowed for node type %d, skipping ID map\n",
+ map, type);
+
return -ENXIO;
}
@@ -327,13 +325,20 @@ struct acpi_iort_node *iort_node_get_id(struct acpi_iort_node *node,
u32 *id_out, u8 type_mask,
int index)
{
- struct acpi_iort_node *parent;
- struct acpi_iort_id_mapping *map;
+ u32 id = 0;
while (node) {
- if (!node->mapping_offset || !node->mapping_count ||
- index >= node->mapping_count)
- return NULL;
+ struct acpi_iort_id_mapping *map;
+
+ if (IORT_TYPE_MASK(node->type) & type_mask) {
+ if (id_out)
+ *id_out = id;
+
+ return node;
+ }
+
+ if (!node->mapping_offset || !node->mapping_count)
+ goto fail_map;
map = ACPI_ADD_PTR(struct acpi_iort_id_mapping, node,
node->mapping_offset);
@@ -342,24 +347,25 @@ struct acpi_iort_node *iort_node_get_id(struct acpi_iort_node *node,
if (!map->output_reference) {
pr_err(FW_BUG "[node %p type %d] ID map has NULL parent reference\n",
node, node->type);
- return NULL;
+ goto fail_map;
}
- parent = ACPI_ADD_PTR(struct acpi_iort_node, iort_table,
- map->output_reference);
-
- /* go upstream to find its parent */
- if (!(IORT_TYPE_MASK(parent->type) & type_mask)) {
- node = parent;
- continue;
+ if (map->flags & ACPI_IORT_ID_SINGLE_MAPPING) {
+ if (iort_id_single_map(&map[index], node->type, &id))
+ goto fail_map;
+ } else {
+ if (iort_id_map(map, id, &id))
+ goto fail_map;
}
- if (iort_id_single_map(&map[index], node->type, id_out))
- break;
+ if (index == node->mapping_count)
+ goto fail_map;
- return parent;
+ node = ACPI_ADD_PTR(struct acpi_iort_node, iort_table,
+ map->output_reference);
}
+fail_map:
return NULL;
}
--
1.9.1
^ permalink raw reply related
* 4.10-rc1 on Nokia N900: regression, WARN_ON() omap_l3_smx.c
From: Pavel Machek @ 2017-01-02 22:48 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20170102181058.GF9325@atomide.com>
Hi!
> > I forgot I had v4.10-rc1 running, and now I got warning on all the
> > consoles (hand-copied).
> >
> >
> > Unhandled fault: external abort on non-linefetch (0x1028) at
> > 0xfa0ab060
> > ...
> > Comm: kworker/0:0 Not tainted.
> > Workqueue: events musb_irq_work
> > ...
> > PC is at musb_default_readb().
> > ...
>
> This means the clocks are not enabled at that point.
>
> > WARNING: CPU: 0 ... at drivers/bus/omap_l3_smx.c:166
> > omap3_l3_app_irq+0xcc/...
> > Tainted: GDW.
>
> If you comment out postcore_initcall_sync(omap3_l3_init);
> in drivers/bus/omap_l3_smx.c you'll see the proper stack
> trace instead of the l3 interrupt trace. The system will
> hang at that point most likely.
>
> > I do have patches to allow nfsroot over usb. But they worked ok in
> > v4.9... Does anyone see it, too?
>
> Hmm not much has changed since v4.9. Are you sure you
> had v4.9 or some earlier v4.9-rc version?
I believe v4.9 works.
But... this may be tricky to reproduce. It happened once so
far... after I reconnected N900 to computer when it was running for a
while. I do have USB cable with power meter on it, thus "flakey". Lets
see if it reappears...
Pavel
--
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 181 bytes
Desc: Digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20170102/09a252bc/attachment.sig>
^ permalink raw reply
* [PATCH] coresight: etm4x: Fix enabling of cycle accurate tracing in perf.
From: Mike Leach @ 2017-01-02 22:55 UTC (permalink / raw)
To: linux-arm-kernel
Using perf record 'cyclacc' option in cs_etm event was not setting up cycle
accurate trace correctly.
Corrects bit set in TRCCONFIGR to enable cycle accurate trace.
Programs TRCCCCTLR with a valid threshold value as required by ETMv4 spec.
Signed-off-by: Mike Leach <mike.leach@linaro.org>
---
drivers/hwtracing/coresight/coresight-etm4x.c | 7 +++++--
drivers/hwtracing/coresight/coresight-etm4x.h | 1 +
2 files changed, 6 insertions(+), 2 deletions(-)
diff --git a/drivers/hwtracing/coresight/coresight-etm4x.c b/drivers/hwtracing/coresight/coresight-etm4x.c
index 4db8d6a..07be032 100644
--- a/drivers/hwtracing/coresight/coresight-etm4x.c
+++ b/drivers/hwtracing/coresight/coresight-etm4x.c
@@ -216,8 +216,11 @@ static int etm4_parse_event_config(struct etmv4_drvdata *drvdata,
goto out;
/* Go from generic option to ETMv4 specifics */
- if (attr->config & BIT(ETM_OPT_CYCACC))
- config->cfg |= ETMv4_MODE_CYCACC;
+ if (attr->config & BIT(ETM_OPT_CYCACC)) {
+ config->cfg |= BIT(4);
+ /* TRM: Must program this for cycacc to work */
+ config->ccctlr = ETM_CYC_THRESHOLD_DEFAULT;
+ }
if (attr->config & BIT(ETM_OPT_TS))
config->cfg |= ETMv4_MODE_TIMESTAMP;
diff --git a/drivers/hwtracing/coresight/coresight-etm4x.h b/drivers/hwtracing/coresight/coresight-etm4x.h
index ba8d3f8..8a62c6c 100644
--- a/drivers/hwtracing/coresight/coresight-etm4x.h
+++ b/drivers/hwtracing/coresight/coresight-etm4x.h
@@ -146,6 +146,7 @@
#define ETM_ARCH_V4 0x40
#define ETMv4_SYNC_MASK 0x1F
#define ETM_CYC_THRESHOLD_MASK 0xFFF
+#define ETM_CYC_THRESHOLD_DEFAULT 256
#define ETMv4_EVENT_MASK 0xFF
#define ETM_CNTR_MAX_VAL 0xFFFF
#define ETM_TRACEID_MASK 0x3f
--
2.7.4
^ permalink raw reply related
* FYI: My boot farm going offline for a while
From: Olof Johansson @ 2017-01-02 23:03 UTC (permalink / raw)
To: linux-arm-kernel
Due to home improvement projects, I'll be shutting down the board farm
for a while. I'm also very tempted to bring it back in a much more
dense format, but that'll require some work on my behalf so it might
take a while.
Build reports should still be going out without much disruption.
-Olof
^ permalink raw reply
* [PATCH 0/5] arm64: sunxi: A64: enable MMC support
From: Andre Przywara @ 2017-01-02 23:03 UTC (permalink / raw)
To: linux-arm-kernel
So far the Allwinner A64/Pine64 DT was missing MMC support, because we
observed issues with that. Those have now been fixed (patch 1 and 2),
so we can enable the MMC IP block in the SoC .dtsi and the Pine64 .dts.
As this gives access to the SD card (as the only mass storage device on
most boards), this makes the kernel support actually useful.
The A64 MMC controller has more up its sleeves, but for now this level
of support is good enough.
Thanks a lot to Maxime for investigating the eMMC failure and coming up
with a nice fix for that.
Maxime: I picked that patch from some pastebin drop of yours, please holler
if there's something wrong with that (patch 2/5).
I send the BananaPi M64 .dts patch along with that series, as the eMMC on
that board now makes some difference.
Cheers,
Andre.
Andre Przywara (4):
drivers: mmc: sunxi: fix A64 calibration routine
arm64: dts: sun50i: add MMC nodes
arm64: dts: Pine64: add MMC support
arm64: dts: add BananaPi-M64 support
Maxime Ripard (1):
drivers: mmc: sunxi: limit A64 MMC2 to 8K DMA buffer
.../devicetree/bindings/mmc/sunxi-mmc.txt | 1 +
arch/arm64/boot/dts/allwinner/Makefile | 1 +
.../boot/dts/allwinner/sun50i-a64-bananapi-m64.dts | 125 +++++++++++++++++++++
.../arm64/boot/dts/allwinner/sun50i-a64-pine64.dts | 18 +++
arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi | 77 +++++++++++++
drivers/mmc/host/sunxi-mmc.c | 37 ++++--
6 files changed, 247 insertions(+), 12 deletions(-)
create mode 100644 arch/arm64/boot/dts/allwinner/sun50i-a64-bananapi-m64.dts
--
2.8.2
^ permalink raw reply
* [PATCH 1/5] drivers: mmc: sunxi: fix A64 calibration routine
From: Andre Przywara @ 2017-01-02 23:03 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1483398226-29321-1-git-send-email-andre.przywara@arm.com>
The calibration facility in the A64 MMC block seems to have been
misunderstood: the result value is not the value to program into the
delay bits, but is the number of delay cells that result in a full clock
cycle delay. So this value has to be scaled by the desired phase, which
we still have to know and program.
Change the calibration routine to take a phase parameter and scale the
calibration value accordingly.
Also introduce sun50i-a64 delay parameters to store the required phase.
Looking at the BSP kernel the sample delay for anything below HS200 is
0, so we go with that value.
Once the driver supports HS200 and faster modes, we can enter confirmed
working values in there.
Signed-off-by: Andre Przywara <andre.przywara@arm.com>
---
drivers/mmc/host/sunxi-mmc.c | 30 ++++++++++++++++++------------
1 file changed, 18 insertions(+), 12 deletions(-)
diff --git a/drivers/mmc/host/sunxi-mmc.c b/drivers/mmc/host/sunxi-mmc.c
index b1d1303..1e156e8 100644
--- a/drivers/mmc/host/sunxi-mmc.c
+++ b/drivers/mmc/host/sunxi-mmc.c
@@ -681,15 +681,13 @@ static int sunxi_mmc_oclk_onoff(struct sunxi_mmc_host *host, u32 oclk_en)
return 0;
}
-static int sunxi_mmc_calibrate(struct sunxi_mmc_host *host, int reg_off)
+static int sunxi_mmc_calibrate(struct sunxi_mmc_host *host, int reg_off,
+ int degrees)
{
u32 reg = readl(host->reg_base + reg_off);
u32 delay;
unsigned long timeout;
- if (!host->cfg->can_calibrate)
- return 0;
-
reg &= ~(SDXC_CAL_DL_MASK << SDXC_CAL_DL_SW_SHIFT);
reg &= ~SDXC_CAL_DL_SW_EN;
@@ -711,6 +709,7 @@ static int sunxi_mmc_calibrate(struct sunxi_mmc_host *host, int reg_off)
}
delay = (reg >> SDXC_CAL_DL_SHIFT) & SDXC_CAL_DL_MASK;
+ delay = degrees * delay / 360;
reg &= ~SDXC_CAL_START;
reg |= (delay << SDXC_CAL_DL_SW_SHIFT) | SDXC_CAL_DL_SW_EN;
@@ -748,6 +747,11 @@ static int sunxi_mmc_clk_set_phase(struct sunxi_mmc_host *host,
return -EINVAL;
}
+ if (host->cfg->can_calibrate)
+ return sunxi_mmc_calibrate(host, SDXC_REG_SAMP_DL_REG,
+ host->cfg->clk_delays[index].sample);
+ /* TODO: calibrate data strobe delay once HS-400 is supported. */
+
clk_set_phase(host->clk_sample, host->cfg->clk_delays[index].sample);
clk_set_phase(host->clk_output, host->cfg->clk_delays[index].output);
@@ -802,12 +806,6 @@ static int sunxi_mmc_clk_set_rate(struct sunxi_mmc_host *host,
if (ret)
return ret;
- ret = sunxi_mmc_calibrate(host, SDXC_REG_SAMP_DL_REG);
- if (ret)
- return ret;
-
- /* TODO: enable calibrate on sdc2 SDXC_REG_DS_DL_REG of A64 */
-
return sunxi_mmc_oclk_onoff(host, 1);
}
@@ -1061,6 +1059,14 @@ static const struct sunxi_mmc_clk_delay sun9i_mmc_clk_delays[] = {
[SDXC_CLK_50M_DDR_8BIT] = { .output = 72, .sample = 72 },
};
+static const struct sunxi_mmc_clk_delay sun50i_mmc_clk_delays[] = {
+ [SDXC_CLK_400K] = { .output = 90, .sample = 0 },
+ [SDXC_CLK_25M] = { .output = 90, .sample = 0 },
+ [SDXC_CLK_50M] = { .output = 90, .sample = 0 },
+ [SDXC_CLK_50M_DDR] = { .output = 90, .sample = 0 },
+ [SDXC_CLK_50M_DDR_8BIT] = { .output = 90, .sample = 0 },
+};
+
static const struct sunxi_mmc_cfg sun4i_a10_cfg = {
.idma_des_size_bits = 13,
.clk_delays = NULL,
@@ -1087,7 +1093,7 @@ static const struct sunxi_mmc_cfg sun9i_a80_cfg = {
static const struct sunxi_mmc_cfg sun50i_a64_cfg = {
.idma_des_size_bits = 16,
- .clk_delays = NULL,
+ .clk_delays = sun50i_mmc_clk_delays,
.can_calibrate = true,
};
@@ -1134,7 +1140,7 @@ static int sunxi_mmc_resource_request(struct sunxi_mmc_host *host,
return PTR_ERR(host->clk_mmc);
}
- if (host->cfg->clk_delays) {
+ if (host->cfg->clk_delays && !host->cfg->can_calibrate) {
host->clk_output = devm_clk_get(&pdev->dev, "output");
if (IS_ERR(host->clk_output)) {
dev_err(&pdev->dev, "Could not get output clock\n");
--
2.8.2
^ permalink raw reply related
* [PATCH 2/5] drivers: mmc: sunxi: limit A64 MMC2 to 8K DMA buffer
From: Andre Przywara @ 2017-01-02 23:03 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1483398226-29321-1-git-send-email-andre.przywara@arm.com>
From: Maxime Ripard <maxime.ripard@free-electrons.com>
Unlike the A64 user manual reports, the third MMC controller on the
A64 (and the only one capable of 8-bit HS400 eMMC transfers) has a
DMA buffer size limit of 8KB (much like the very old Allwinner SoCs).
This does not affect the other two controllers, so introduce a new
DT compatible string to let the driver use different settings for that
particular device. This will also help to enable the high-speed transfer
modes of that controller later.
Signed-off-by: Maxime Ripard <maxime.ripard@free-electrons.com>
Signed-off-by: Andre Przywara <andre.przywara@arm.com>
---
Documentation/devicetree/bindings/mmc/sunxi-mmc.txt | 1 +
drivers/mmc/host/sunxi-mmc.c | 7 +++++++
2 files changed, 8 insertions(+)
diff --git a/Documentation/devicetree/bindings/mmc/sunxi-mmc.txt b/Documentation/devicetree/bindings/mmc/sunxi-mmc.txt
index 55cdd80..3d9170f 100644
--- a/Documentation/devicetree/bindings/mmc/sunxi-mmc.txt
+++ b/Documentation/devicetree/bindings/mmc/sunxi-mmc.txt
@@ -14,6 +14,7 @@ Required properties:
* "allwinner,sun7i-a20-mmc"
* "allwinner,sun9i-a80-mmc"
* "allwinner,sun50i-a64-mmc"
+ * "allwinner,sun50i-a64-emmc"
- reg : mmc controller base registers
- clocks : a list with 4 phandle + clock specifier pairs
- clock-names : must contain "ahb", "mmc", "output" and "sample"
diff --git a/drivers/mmc/host/sunxi-mmc.c b/drivers/mmc/host/sunxi-mmc.c
index 1e156e8..165486bc 100644
--- a/drivers/mmc/host/sunxi-mmc.c
+++ b/drivers/mmc/host/sunxi-mmc.c
@@ -1097,12 +1097,19 @@ static const struct sunxi_mmc_cfg sun50i_a64_cfg = {
.can_calibrate = true,
};
+static const struct sunxi_mmc_cfg sun50i_a64_emmc_cfg = {
+ .idma_des_size_bits = 13,
+ .clk_delays = sun50i_mmc_clk_delays,
+ .can_calibrate = true,
+};
+
static const struct of_device_id sunxi_mmc_of_match[] = {
{ .compatible = "allwinner,sun4i-a10-mmc", .data = &sun4i_a10_cfg },
{ .compatible = "allwinner,sun5i-a13-mmc", .data = &sun5i_a13_cfg },
{ .compatible = "allwinner,sun7i-a20-mmc", .data = &sun7i_a20_cfg },
{ .compatible = "allwinner,sun9i-a80-mmc", .data = &sun9i_a80_cfg },
{ .compatible = "allwinner,sun50i-a64-mmc", .data = &sun50i_a64_cfg },
+ { .compatible = "allwinner,sun50i-a64-emmc", .data = &sun50i_a64_emmc_cfg },
{ /* sentinel */ }
};
MODULE_DEVICE_TABLE(of, sunxi_mmc_of_match);
--
2.8.2
^ permalink raw reply related
* [PATCH 3/5] arm64: dts: sun50i: add MMC nodes
From: Andre Przywara @ 2017-01-02 23:03 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1483398226-29321-1-git-send-email-andre.przywara@arm.com>
Signed-off-by: Andre Przywara <andre.przywara@arm.com>
---
arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi | 67 +++++++++++++++++++++++++++
1 file changed, 67 insertions(+)
diff --git a/arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi b/arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi
index e0dcab8..c680566 100644
--- a/arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi
+++ b/arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi
@@ -150,6 +150,32 @@
pins = "PB8", "PB9";
function = "uart0";
};
+
+ mmc0_pins: mmc0 at 0 {
+ pins = "PF0", "PF1", "PF2", "PF3", "PF4", "PF5";
+ function = "mmc0";
+ drive-strength = <30>;
+ };
+
+ mmc0_default_cd_pin: mmc0_cd_pin at 0 {
+ pins = "PF6";
+ function = "gpio_in";
+ bias-pull-up;
+ };
+
+ mmc1_pins: mmc1 at 0 {
+ pins = "PG0", "PG1", "PG2", "PG3", "PG4", "PG5";
+ function = "mmc1";
+ drive-strength = <30>;
+ };
+
+ mmc2_pins: mmc2 at 0 {
+ pins = "PC1", "PC5", "PC6", "PC8", "PC9",
+ "PC10", "PC11", "PC12", "PC13", "PC14",
+ "PC15", "PC16";
+ function = "mmc2";
+ drive-strength = <30>;
+ };
};
uart0: serial at 1c28000 {
@@ -240,6 +266,47 @@
#size-cells = <0>;
};
+ mmc0: mmc at 1c0f000 {
+ compatible = "allwinner,sun50i-a64-mmc",
+ "allwinner,sun5i-a13-mmc";
+ reg = <0x01c0f000 0x1000>;
+ clocks = <&ccu 31>, <&ccu 75>;
+ clock-names = "ahb", "mmc";
+ resets = <&ccu 8>;
+ reset-names = "ahb";
+ interrupts = <GIC_SPI 60 IRQ_TYPE_LEVEL_HIGH>;
+ status = "disabled";
+ #address-cells = <1>;
+ #size-cells = <0>;
+ };
+
+ mmc1: mmc at 1c10000 {
+ compatible = "allwinner,sun50i-a64-mmc",
+ "allwinner,sun5i-a13-mmc";
+ reg = <0x01c10000 0x1000>;
+ clocks = <&ccu 32>, <&ccu 76>;
+ clock-names = "ahb", "mmc";
+ resets = <&ccu 9>;
+ reset-names = "ahb";
+ interrupts = <GIC_SPI 61 IRQ_TYPE_LEVEL_HIGH>;
+ status = "disabled";
+ #address-cells = <1>;
+ #size-cells = <0>;
+ };
+
+ mmc2: mmc at 1c11000 {
+ compatible = "allwinner,sun50i-a64-emmc";
+ reg = <0x01c11000 0x1000>;
+ clocks = <&ccu 33>, <&ccu 77>;
+ clock-names = "ahb", "mmc";
+ resets = <&ccu 10>;
+ reset-names = "ahb";
+ interrupts = <GIC_SPI 62 IRQ_TYPE_LEVEL_HIGH>;
+ status = "disabled";
+ #address-cells = <1>;
+ #size-cells = <0>;
+ };
+
gic: interrupt-controller at 1c81000 {
compatible = "arm,gic-400";
reg = <0x01c81000 0x1000>,
--
2.8.2
^ permalink raw reply related
* [PATCH 4/5] arm64: dts: Pine64: add MMC support
From: Andre Przywara @ 2017-01-02 23:03 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1483398226-29321-1-git-send-email-andre.przywara@arm.com>
Signed-off-by: Andre Przywara <andre.przywara@arm.com>
---
arch/arm64/boot/dts/allwinner/sun50i-a64-pine64.dts | 18 ++++++++++++++++++
1 file changed, 18 insertions(+)
diff --git a/arch/arm64/boot/dts/allwinner/sun50i-a64-pine64.dts b/arch/arm64/boot/dts/allwinner/sun50i-a64-pine64.dts
index 4709590..c18ab03 100644
--- a/arch/arm64/boot/dts/allwinner/sun50i-a64-pine64.dts
+++ b/arch/arm64/boot/dts/allwinner/sun50i-a64-pine64.dts
@@ -55,6 +55,13 @@
chosen {
stdout-path = "serial0:115200n8";
};
+
+ reg_vcc3v3: vcc3v3 {
+ compatible = "regulator-fixed";
+ regulator-name = "vcc3v3";
+ regulator-min-microvolt = <3300000>;
+ regulator-max-microvolt = <3300000>;
+ };
};
&uart0 {
@@ -72,3 +79,14 @@
&i2c1_pins {
bias-pull-up;
};
+
+&mmc0 {
+ pinctrl-names = "default";
+ pinctrl-0 = <&mmc0_pins>, <&mmc0_default_cd_pin>;
+ vmmc-supply = <®_vcc3v3>;
+ cd-gpios = <&pio 5 6 0>;
+ cd-inverted;
+ disable-wp;
+ bus-width = <4>;
+ status = "okay";
+};
--
2.8.2
^ permalink raw reply related
* [PATCH 5/5] arm64: dts: add BananaPi-M64 support
From: Andre Przywara @ 2017-01-02 23:03 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1483398226-29321-1-git-send-email-andre.przywara@arm.com>
The Banana Pi M64 board is a typical single board computer based on the
Allwinner A64 SoC. Aside from the usual peripherals it features eMMC
storage, which is connected to the 8-bit capable SDHC2 controller.
Also it has a soldered WiFi/Bluetooth chip, so we enable UART1 and SDHC1
as those two interfaces are connected to it.
Signed-off-by: Andre Przywara <andre.przywara@arm.com>
---
arch/arm64/boot/dts/allwinner/Makefile | 1 +
.../boot/dts/allwinner/sun50i-a64-bananapi-m64.dts | 125 +++++++++++++++++++++
arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi | 10 ++
3 files changed, 136 insertions(+)
create mode 100644 arch/arm64/boot/dts/allwinner/sun50i-a64-bananapi-m64.dts
diff --git a/arch/arm64/boot/dts/allwinner/Makefile b/arch/arm64/boot/dts/allwinner/Makefile
index 1e29a5a..51ecb04 100644
--- a/arch/arm64/boot/dts/allwinner/Makefile
+++ b/arch/arm64/boot/dts/allwinner/Makefile
@@ -1,4 +1,5 @@
dtb-$(CONFIG_ARCH_SUNXI) += sun50i-a64-pine64-plus.dtb sun50i-a64-pine64.dtb
+dtb-$(CONFIG_ARCH_SUNXI) += sun50i-a64-bananapi-m64.dtb
always := $(dtb-y)
subdir-y := $(dts-dirs)
diff --git a/arch/arm64/boot/dts/allwinner/sun50i-a64-bananapi-m64.dts b/arch/arm64/boot/dts/allwinner/sun50i-a64-bananapi-m64.dts
new file mode 100644
index 0000000..941ea07
--- /dev/null
+++ b/arch/arm64/boot/dts/allwinner/sun50i-a64-bananapi-m64.dts
@@ -0,0 +1,125 @@
+/*
+ * Copyright (c) 2016 ARM Ltd.
+ *
+ * This file is dual-licensed: you can use it either under the terms
+ * of the GPL or the X11 license, at your option. Note that this dual
+ * licensing only applies to this file, and not this project as a
+ * whole.
+ *
+ * a) This library is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License as
+ * published by the Free Software Foundation; either version 2 of the
+ * License, or (at your option) any later version.
+ *
+ * This library is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ *
+ * Or, alternatively,
+ *
+ * b) Permission is hereby granted, free of charge, to any person
+ * obtaining a copy of this software and associated documentation
+ * files (the "Software"), to deal in the Software without
+ * restriction, including without limitation the rights to use,
+ * copy, modify, merge, publish, distribute, sublicense, and/or
+ * sell copies of the Software, and to permit persons to whom the
+ * Software is furnished to do so, subject to the following
+ * conditions:
+ *
+ * The above copyright notice and this permission notice shall be
+ * included in all copies or substantial portions of the Software.
+ *
+ * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND,
+ * EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES
+ * OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND
+ * NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT
+ * HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY,
+ * WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
+ * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR
+ * OTHER DEALINGS IN THE SOFTWARE.
+ */
+
+/dts-v1/;
+
+#include "sun50i-a64.dtsi"
+
+/ {
+ model = "BananaPi-M64";
+ compatible = "sinovoip,bananapi-m64", "allwinner,sun50i-a64";
+
+ aliases {
+ serial0 = &uart0;
+ serial1 = &uart1;
+ };
+
+ chosen {
+ stdout-path = "serial0:115200n8";
+ };
+
+ reg_vcc3v3: vcc3v3 {
+ compatible = "regulator-fixed";
+ regulator-name = "vcc3v3";
+ regulator-min-microvolt = <3300000>;
+ regulator-max-microvolt = <3300000>;
+ };
+};
+
+&uart0 {
+ pinctrl-names = "default";
+ pinctrl-0 = <&uart0_pins_a>;
+ status = "okay";
+};
+
+&uart1 {
+ pinctrl-names = "default";
+ pinctrl-0 = <&uart1_pins_4>;
+ status = "okay";
+};
+
+&i2c1 {
+ pinctrl-names = "default";
+ pinctrl-0 = <&i2c1_pins>;
+ status = "okay";
+};
+
+&i2c1_pins {
+ bias-pull-up;
+};
+
+&mmc0 {
+ pinctrl-names = "default";
+ pinctrl-0 = <&mmc0_pins>, <&mmc0_default_cd_pin>;
+ vmmc-supply = <®_vcc3v3>;
+ cd-gpios = <&pio 5 6 0>;
+ cd-inverted;
+ disable-wp;
+ bus-width = <4>;
+ status = "okay";
+};
+
+&mmc1 {
+ pinctrl-names = "default";
+ pinctrl-0 = <&mmc1_pins>;
+ vmmc-supply = <®_vcc3v3>;
+ bus-width = <4>;
+ non-removable;
+ status = "okay";
+};
+
+&mmc2 {
+ pinctrl-names = "default";
+ pinctrl-0 = <&mmc2_pins>;
+ vmmc-supply = <®_vcc3v3>;
+ bus-width = <8>;
+ non-removable;
+ cap-mmc-hw-reset;
+ status = "okay";
+};
+
+&mmc2_pins {
+ /* Increase drive strength for DDR modes */
+ drive-strength = <40>;
+ /* eMMC is missing pull-ups */
+ bias-pull-up;
+};
diff --git a/arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi b/arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi
index c680566..9de96ba 100644
--- a/arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi
+++ b/arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi
@@ -151,6 +151,16 @@
function = "uart0";
};
+ uart1_pins: uart1 at 0 {
+ pins = "PG6", "PG7";
+ function = "uart1";
+ };
+
+ uart1_pins_4: uart1_4 at 0 {
+ pins = "PG6", "PG7", "PG8", "PG9";
+ function = "uart1";
+ };
+
mmc0_pins: mmc0 at 0 {
pins = "PF0", "PF1", "PF2", "PF3", "PF4", "PF5";
function = "mmc0";
--
2.8.2
^ permalink raw reply related
* How should we handle variable address space sizes (Re: [RFC 3/4] x86/mm: define TASK_SIZE as current->mm->task_size)
From: hpa at zytor.com @ 2017-01-02 23:06 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CALCETrU+BJ2JDRocBy-6SD_G6FbD+Ez_yb1QJ6Z1KXBjVzKOHg@mail.gmail.com>
On January 2, 2017 8:52:41 AM PST, Andy Lutomirski <luto@amacapital.net> wrote:
>On Mon, Jan 2, 2017 at 1:49 AM, Kirill A. Shutemov
><kirill@shutemov.name> wrote:
>> On Fri, Dec 30, 2016 at 06:11:05PM -0800, Andy Lutomirski wrote:
>>> On Fri, Dec 30, 2016 at 7:56 AM, Dmitry Safonov
><dsafonov@virtuozzo.com> wrote:
>>> > Keep task's virtual address space size as mm_struct field which
>>> > exists for a long time - it's initialized in setup_new_exec()
>>> > depending on the new task's personality.
>>> > This way TASK_SIZE will always be the same as
>current->mm->task_size.
>>> > Previously, there could be an issue about different values of
>>> > TASK_SIZE and current->mm->task_size: e.g, a 32-bit process can
>unset
>>> > ADDR_LIMIT_3GB personality (with personality syscall) and
>>> > so TASK_SIZE will be 4Gb, which is larger than mm->task_size =
>3Gb.
>>> > As TASK_SIZE *and* current->mm->task_size are used both in code
>>> > frequently, this difference creates a subtle situations, for
>example:
>>> > one can mmap addresses > 3Gb, but they will be hidden in
>>> > /proc/pid/pagemap as it checks mm->task_size.
>>> > I've moved initialization of mm->task_size earlier in
>setup_new_exec()
>>> > as arch_pick_mmap_layout() initializes mmap_legacy_base with
>>> > TASK_UNMAPPED_BASE, which depends on TASK_SIZE.
>>>
>>> I don't like this patch so much because I think that we should
>figure
>>> out how this will all work in the long run first. I've added some
>>> more people to the thread because other arches have similar issues
>and
>>> because x86 is about to get considerably more complicated (choices
>>> include 3GB, 4GB, 47-bit, and 56-bit (the latter IIRC)).
>>>
>>> Here are a few of my thoughts on the matter. This isn't all that
>well
>>> thought out:
>>>
>>> The address space limit, especially if CRIU is in play, isn't really
>a
>>> hard limit. For example, you could allocate high memory then lower
>>> the limit. Similarly, I see no reason that an x32 program should be
>>> forbidden from mapping some high addresses or, similarly, that an
>i386
>>> program can't (if it really wanted to) do a 64-bit mmap() and get a
>>> high address.
>>>
>>> On that note, can we just *delete* the task_size check from pagemap?
>>> It's been there since the very beginning:
>>>
>>> commit 85863e475e59afb027b0113290e3796ee6020b7d
>>> Author: Matt Mackall <mpm@selenic.com>
>>> Date: Mon Feb 4 22:29:04 2008 -0800
>>>
>>> maps4: add /proc/pid/pagemap interface
>>>
>>> and there's no explanation for why it's needed.
>>>
>>> So maybe we should have a *number* (not a bit) that indicates the
>>> maximum address that mmap() will return unless an override is in
>use.
>>> Since common practice seems to be to stick this in the personality
>>> field, we may need some fancy encoding. Executing a setuid binary
>>> needs to reset to the default, and personality handles that.
>>
>> If we want to be able to specify arbitrary address as maximum, a
>fancy
>> encoding would need to claim 51 bits (63 VA - 12 in-page address) on
>x86
>> from the persona flag.
>> To me, it's stretching personality interface too far.
>>
>> Maybe it's easier to reset the rlimit for suid binaries?
>
>I guess I don't see why rlimit makes any sense, though. It's not a
>resource utilization control, hard vs soft limits make very little
>sense, requiring capabilities to exceed the hard limit doesn't help
>anything, and it's only useful to preserve it across execve() to work
>around bugs.
>
>So if it's going to be a number, let's just make it be a new number
>with a new API to control it.
>
>--Andy
It's an API that already exists, that's the plus. Hard and soft limits *do* make sense IMO.
--
Sent from my Android device with K-9 Mail. Please excuse my brevity.
^ permalink raw reply
* [PATCH 1/5] ARM: wire up HWCAP2 feature bits to the CPU modalias
From: Russell King - ARM Linux @ 2017-01-02 23:40 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAKv+Gu-hLD0xnLyywceJvPiB8ZkENNwWZTM--OHFvzw6MahYmw@mail.gmail.com>
On Mon, Jan 02, 2017 at 09:06:04PM +0000, Ard Biesheuvel wrote:
> On 31 October 2016 at 16:13, Russell King - ARM Linux
> <linux@armlinux.org.uk> wrote:
> > On Sat, Oct 29, 2016 at 11:08:36AM +0100, Ard Biesheuvel wrote:
> >> On 18 October 2016 at 11:52, Ard Biesheuvel <ard.biesheuvel@linaro.org> wrote:
> >> > Wire up the generic support for exposing CPU feature bits via the
> >> > modalias in /sys/device/system/cpu. This allows udev to automatically
> >> > load modules for things like crypto algorithms that are implemented
> >> > using optional instructions.
> >> >
> >> > Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
> >> > ---
> >> > arch/arm/Kconfig | 1 +
> >> > arch/arm/include/asm/cpufeature.h | 32 ++++++++++++++++++++
> >> > 2 files changed, 33 insertions(+)
> >> >
> >>
> >> Russell,
> >>
> >> do you have any concerns regarding this patch? If not, I will drop it
> >> into the patch system.
> >
> > It's still something I need to look at... I've been offline last week,
> > and sort-of offline the previous week, so I'm catching up.
> >
>
> Hi Russell,
>
> Any thoughts yet?
None, and the patch is well buried now that it'll take me a while to
find... back in mid-October? Yea, I'll have to drop everything and
go digging through my mailboxes to find it... and I'm just catching
up (again) after a week and a bit's time offline - yep, it's wonderful
timing. Sorry, no time to look at it right now, you're not the only
one wanting my attention at the moment.
Please try again in about a week's time - don't leave it a few months,
and please include the patch.
--
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 v2 1/2] Doc: devicetree: bindings: Add vendor prefix entry - lwn
From: Lukasz Majewski @ 2017-01-02 23:43 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1482794396-16153-1-git-send-email-l.majewski@majess.pl>
This patch adds entry for LWN - the Liebherr-Werk Nenzing GmbH company to
vendor-prefixes.txt file.
Signed-off-by: Lukasz Majewski <lukma@denx.de>
---
Changes for v2:
- New patch
---
Documentation/devicetree/bindings/vendor-prefixes.txt | 1 +
1 file changed, 1 insertion(+)
diff --git a/Documentation/devicetree/bindings/vendor-prefixes.txt b/Documentation/devicetree/bindings/vendor-prefixes.txt
index f0a48ea..dd8b2eb 100644
--- a/Documentation/devicetree/bindings/vendor-prefixes.txt
+++ b/Documentation/devicetree/bindings/vendor-prefixes.txt
@@ -158,6 +158,7 @@ lg LG Corporation
linux Linux-specific binding
lltc Linear Technology Corporation
lsi LSI Corp. (LSI Logic)
+lwn Liebherr-Werk Nenzing GmbH
marvell Marvell Technology Group Ltd.
maxim Maxim Integrated Products
meas Measurement Specialties
--
2.1.4
^ permalink raw reply related
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