* [PATCH v2 5/6] ARM: davinci: da8xx: add pdata-quirks, use for VPIF capture
From: Kevin Hilman @ 2017-01-09 20:55 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20170109205531.3435-1-khilman@baylibre.com>
For da8xx DT platforms, use pdata-quirks to add legacy platform data for
vpif_capture driver.
Passing legacy platform_data is required until the V4L2 framework, and
subdevice drivers (such as the tvp514x) grow a way of selecting input
and output routing (c.f. V4L2 s_routing API)
Signed-off-by: Kevin Hilman <khilman@baylibre.com>
---
arch/arm/mach-davinci/Makefile | 2 +-
arch/arm/mach-davinci/da8xx-dt.c | 2 +
arch/arm/mach-davinci/pdata-quirks.c | 115 +++++++++++++++++++++++++++++++++++
3 files changed, 118 insertions(+), 1 deletion(-)
diff --git a/arch/arm/mach-davinci/Makefile b/arch/arm/mach-davinci/Makefile
index 0a2e6da45f28..df96ca9eab6d 100644
--- a/arch/arm/mach-davinci/Makefile
+++ b/arch/arm/mach-davinci/Makefile
@@ -21,7 +21,7 @@ obj-$(CONFIG_AINTC) += irq.o
obj-$(CONFIG_CP_INTC) += cp_intc.o
# Board specific
-obj-$(CONFIG_MACH_DA8XX_DT) += da8xx-dt.o
+obj-$(CONFIG_MACH_DA8XX_DT) += da8xx-dt.o pdata-quirks.o
obj-$(CONFIG_MACH_DAVINCI_EVM) += board-dm644x-evm.o
obj-$(CONFIG_MACH_SFFSDR) += board-sffsdr.o
obj-$(CONFIG_MACH_NEUROS_OSD2) += board-neuros-osd2.o
diff --git a/arch/arm/mach-davinci/da8xx-dt.c b/arch/arm/mach-davinci/da8xx-dt.c
index 9ee44da6eb7b..fe4a9e30d937 100644
--- a/arch/arm/mach-davinci/da8xx-dt.c
+++ b/arch/arm/mach-davinci/da8xx-dt.c
@@ -42,6 +42,7 @@ static struct of_dev_auxdata da850_auxdata_lookup[] __initdata = {
OF_DEV_AUXDATA("ti,da830-ohci", 0x01e25000, "ohci-da8xx", NULL),
OF_DEV_AUXDATA("ti,da830-musb", 0x01e00000, "musb-da8xx", NULL),
OF_DEV_AUXDATA("ti,da830-usb-phy", 0x01c1417c, "da8xx-usb-phy", NULL),
+ OF_DEV_AUXDATA("ti,da850-vpif", 0x01e17000, "vpif", NULL),
{}
};
@@ -62,6 +63,7 @@ static void __init da850_init_machine(void)
of_platform_default_populate(NULL, da850_auxdata_lookup, NULL);
davinci_pm_init();
+ pdata_quirks_init();
}
static const char *const da850_boards_compat[] __initconst = {
diff --git a/arch/arm/mach-davinci/pdata-quirks.c b/arch/arm/mach-davinci/pdata-quirks.c
index 5b57da475065..142a2684c445 100644
--- a/arch/arm/mach-davinci/pdata-quirks.c
+++ b/arch/arm/mach-davinci/pdata-quirks.c
@@ -10,13 +10,122 @@
#include <linux/kernel.h>
#include <linux/of_platform.h>
+#include <media/i2c/tvp514x.h>
+
#include <mach/common.h>
+#include <mach/da8xx.h>
struct pdata_init {
const char *compatible;
void (*fn)(void);
};
+#if IS_ENABLED(CONFIG_VIDEO_DAVINCI_VPIF_CAPTURE)
+
+#define TVP5147_CH0 "tvp514x-0"
+#define TVP5147_CH1 "tvp514x-1"
+
+/* VPIF capture configuration */
+static struct tvp514x_platform_data tvp5146_pdata = {
+ .clk_polarity = 0,
+ .hs_polarity = 1,
+ .vs_polarity = 1,
+};
+
+#define TVP514X_STD_ALL (V4L2_STD_NTSC | V4L2_STD_PAL)
+
+static const struct vpif_input da850_ch0_inputs[] = {
+ {
+ .input = {
+ .index = 0,
+ .name = "Composite",
+ .type = V4L2_INPUT_TYPE_CAMERA,
+ .capabilities = V4L2_IN_CAP_STD,
+ .std = TVP514X_STD_ALL,
+ },
+ .input_route = INPUT_CVBS_VI2B,
+ .output_route = OUTPUT_10BIT_422_EMBEDDED_SYNC,
+ .subdev_name = TVP5147_CH0,
+ },
+};
+
+static const struct vpif_input da850_ch1_inputs[] = {
+ {
+ .input = {
+ .index = 0,
+ .name = "S-Video",
+ .type = V4L2_INPUT_TYPE_CAMERA,
+ .capabilities = V4L2_IN_CAP_STD,
+ .std = TVP514X_STD_ALL,
+ },
+ .input_route = INPUT_SVIDEO_VI2C_VI1C,
+ .output_route = OUTPUT_10BIT_422_EMBEDDED_SYNC,
+ .subdev_name = TVP5147_CH1,
+ },
+};
+
+static struct vpif_subdev_info da850_vpif_capture_sdev_info[] = {
+ {
+ .name = TVP5147_CH0,
+ .board_info = {
+ I2C_BOARD_INFO("tvp5146", 0x5d),
+ .platform_data = &tvp5146_pdata,
+ },
+ },
+ {
+ .name = TVP5147_CH1,
+ .board_info = {
+ I2C_BOARD_INFO("tvp5146", 0x5c),
+ .platform_data = &tvp5146_pdata,
+ },
+ },
+};
+
+static struct vpif_capture_config da850_vpif_capture_config = {
+ .subdev_info = da850_vpif_capture_sdev_info,
+ .subdev_count = ARRAY_SIZE(da850_vpif_capture_sdev_info),
+ .chan_config[0] = {
+ .inputs = da850_ch0_inputs,
+ .input_count = ARRAY_SIZE(da850_ch0_inputs),
+ .vpif_if = {
+ .if_type = VPIF_IF_BT656,
+ .hd_pol = 1,
+ .vd_pol = 1,
+ .fid_pol = 0,
+ },
+ },
+ .chan_config[1] = {
+ .inputs = da850_ch1_inputs,
+ .input_count = ARRAY_SIZE(da850_ch1_inputs),
+ .vpif_if = {
+ .if_type = VPIF_IF_BT656,
+ .hd_pol = 1,
+ .vd_pol = 1,
+ .fid_pol = 0,
+ },
+ },
+ .card_name = "DA850/OMAP-L138 Video Capture",
+};
+
+static void __init da850_vpif_legacy_init(void)
+{
+ int ret;
+
+ /* LCDK doesn't have the 2nd TVP514x on CH1 */
+ if (of_machine_is_compatible("ti,da850-lcdk"))
+ da850_vpif_capture_config.subdev_count = 1;
+
+ /* EVM (UI card) uses i2c adapter 1 (not default: zero) */
+ if (of_machine_is_compatible("ti,da850-evm"))
+ da850_vpif_capture_config.i2c_adapter_id = 1;
+
+ ret = da850_register_vpif_capture(&da850_vpif_capture_config);
+ if (ret)
+ pr_warn("%s: VPIF capture setup failed: %d\n",
+ __func__, ret);
+}
+#endif
+
static void pdata_quirks_check(struct pdata_init *quirks)
{
while (quirks->compatible) {
@@ -30,6 +139,12 @@ static void pdata_quirks_check(struct pdata_init *quirks)
}
static struct pdata_init pdata_quirks[] __initdata = {
+#if IS_ENABLED(CONFIG_VIDEO_DAVINCI_VPIF_CAPTURE)
+ { "ti,da850-lcdk", da850_vpif_legacy_init, },
+#if defined(CONFIG_DA850_UI_SD_VIDEO_PORT)
+ { "ti,da850-evm", da850_vpif_legacy_init, },
+#endif
+#endif
{ /* sentinel */ },
};
--
2.9.3
^ permalink raw reply related
* [PATCH v2 6/6] ARM: davinci: board-da850-evm: add I2C ID for VPIF
From: Kevin Hilman @ 2017-01-09 20:55 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20170109205531.3435-1-khilman@baylibre.com>
VPIF capture driver now has a way to specific I2C adapter ID (was
previously hard-coded.) Use the new interface.
Signed-off-by: Kevin Hilman <khilman@baylibre.com>
---
arch/arm/mach-davinci/board-da850-evm.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/arch/arm/mach-davinci/board-da850-evm.c b/arch/arm/mach-davinci/board-da850-evm.c
index aac3ab1a044f..e5d4ded38d12 100644
--- a/arch/arm/mach-davinci/board-da850-evm.c
+++ b/arch/arm/mach-davinci/board-da850-evm.c
@@ -1212,6 +1212,7 @@ static struct vpif_subdev_info da850_vpif_capture_sdev_info[] = {
static struct vpif_capture_config da850_vpif_capture_config = {
.subdev_info = da850_vpif_capture_sdev_info,
.subdev_count = ARRAY_SIZE(da850_vpif_capture_sdev_info),
+ .i2c_adapter_id = 1,
.chan_config[0] = {
.inputs = da850_ch0_inputs,
.input_count = ARRAY_SIZE(da850_ch0_inputs),
--
2.9.3
^ permalink raw reply related
* [PATCH 1/2] arm64: dma_mapping: allow PCI host driver to limit DMA mask
From: Christoph Hellwig @ 2017-01-09 20:57 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <b50e25af-3936-d22d-2e9b-5bf6be19c800@cogentembedded.com>
On Mon, Jan 09, 2017 at 11:34:55PM +0300, Nikita Yushchenko wrote:
> I believe the bounce buffering code you refer to is not in SATA/SCSI/MMC
> but in block layer, in particular it should be controlled by
> blk_queue_bounce_limit(). [Yes there is CONFIG_MMC_BLOCK_BOUNCE but it
> is something completely different, namely it is for request merging for
> hw not supporting scatter-gather]. And NVMe also uses block layer and
> thus should get same support.
NVMe shouldn't have to call blk_queue_bounce_limit -
blk_queue_bounce_limit is to set the DMA addressing limit of the device.
NVMe devices must support unlimited 64-bit addressing and thus calling
blk_queue_bounce_limit from NVMe does not make sense.
That being said currently the default for a queue without a call
to blk_queue_make_request which does the wrong thing on highmem
setups, so we should fix it. In fact BLK_BOUNCE_HIGH as-is doesn't
really make much sense these days as no driver should ever dereference
pages passed to it directly.
> Maybe fixing that, together with making NVMe use this API, could stop it
> from issuing dma_map()s of addresses beyond mask.
NVMe should never bounce, the fact that it currently possibly does
for highmem pages is a bug.
> As for PCI_DMA_BUS_IS_PHYS - ironically, what all current usages of this
> macro in the kernel do is - *disable* bounce buffers in block layer if
> PCI_DMA_BUS_IS_PHYS is zero.
That's not ironic but the whole point of the macro (horrible name and
the fact that it should be a dma_ops setting aside).
> - architecture should stop breaking 64-bit DMA when driver attempts to
> set 64-bit dma mask,
>
> - NVMe should issue proper blk_queue_bounce_limit() call based on what
> is actually set mask,
Or even better remove the call to dma_set_mask_and_coherent with
DMA_BIT_MASK(32). NVMe is designed around having proper 64-bit DMA
addressing, there is not point in trying to pretent it works without that
> - and blk_queue_bounce_limit() should also be fixed to actually set
> 0xffffffff limit, instead of replacing it with (max_low_pfn <<
> PAGE_SHIFT) as it does now.
We need to kill off BLK_BOUNCE_HIGH, it just doesn't make sense to
mix the highmem aspect with the addressing limits. In fact the whole
block bouncing scheme doesn't make much sense at all these days, we
should rely on swiotlb instead.
> What I mean is some API to allocate memory for use with streaming DMA in
> such way that bounce buffers won't be needed. There are many cases when
> at buffer allocation time, it is already known that buffer will be used
> for DMA with particular device. Bounce buffers will still be needed
> cases when no such information is available at allocation time, or when
> there is no directly-DMAable memory available at allocation time.
For block I/O that is never the case.
^ permalink raw reply
* [PATCH 0/5] meson-gx: reset RGMII PHYs and configure TX delay
From: Kevin Hilman @ 2017-01-09 22:52 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAFBinCDpBew7wreNPn6=J3jKsw_Ok=Ed9_+Gxsefb661RvUdrA@mail.gmail.com>
Martin Blumenstingl <martin.blumenstingl@googlemail.com> writes:
> On Sat, Dec 3, 2016 at 12:47 AM, Martin Blumenstingl
> <martin.blumenstingl@googlemail.com> wrote:
>> This partially fixes the 1000Mbit/s ethernet TX throughput issues (on
>> networks which are not affected by the EEE problem, as reported here:
>> [1]).
>> The actual problem for the TX throughput issues was that the TX delay
>> was applied twice:
>> - once "accidentally" by the PHY (this was fixed with [2])
>> - once by the MAC because there was a hardcoded TX delay (of 2ns),
>> this will be configurable with the changes from [0]
>>
>> These are the dts changes which belong to my other series (in v2
>> these patches were part of the other series, upon request of the
>> net maintainers I have split the .dts changes into their own series so
>> we are able to take both through different trees):
>> "[PATCH net-next v3 0/2] stmmac: dwmac-meson8b: configurable
>> RGMII TX delay": [0].
>> Thus this series depends on the ACK for the binding changes in the
>> other series!
>>
>> I based these changes on my other series "[PATCH v2 0/2] GXL and GXM
>> SCPI improvements": [3]
> the DT binding changes for the meson8b-dwmac driver were ACK'ed by Rob
> Herring, so you can proceed with this series once you applied the SCPI
> patches.
Series queued for v4.11,
Thanks,
Kevin
^ permalink raw reply
* [PATCH] clk: scpi: don't add cpufreq device if the scpi dvfs node is disabled
From: Stephen Boyd @ 2017-01-10 0:08 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1483706070-12357-1-git-send-email-sudeep.holla@arm.com>
On 01/06, Sudeep Holla wrote:
> Currently we add the virtual cpufreq device unconditionally even when
> the SCPI DVFS clock provider node is disabled. This will cause cpufreq
> driver to throw errors when it gets initailised on boot/modprobe and
> also when the CPUs are hot-plugged back in.
>
> This patch fixes the issue by adding the virtual cpufreq device only if
> the SCPI DVFS clock provider is available and registered.
>
> Fixes: 9490f01e2471 ("clk: scpi: add support for cpufreq virtual device")
> Reported-by: Micha? Zegan <webczat_200@poczta.onet.pl>
> Cc: Neil Armstrong <narmstrong@baylibre.com>
> Cc: Michael Turquette <mturquette@baylibre.com>
> Cc: Stephen Boyd <sboyd@codeaurora.org>
> Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
> ---
Applied to clk-next
--
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project
^ permalink raw reply
* [PATCH v2 1/2] dt-bindings: Document the hi3660 clock bindings
From: Stephen Boyd @ 2017-01-10 0:21 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1482978805-6981-2-git-send-email-zhangfei.gao@linaro.org>
On 12/29, Zhangfei Gao wrote:
> Add DT bindings documentation for hi3660 SoC clock.
>
> Signed-off-by: Zhangfei Gao <zhangfei.gao@linaro.org>
> ---
Applied to clk-hi3660 and merged into clk-next
--
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project
^ permalink raw reply
* [PATCH v2 2/2] clk: hisilicon: Add clock driver for hi3660 SoC
From: Stephen Boyd @ 2017-01-10 0:22 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1482978805-6981-3-git-send-email-zhangfei.gao@linaro.org>
On 12/29, Zhangfei Gao wrote:
> Add clock drivers for hi3660 SoC, this driver controls the SoC
> registers to supply different clocks to different IPs in the SoC.
>
> Signed-off-by: Zhangfei Gao <zhangfei.gao@linaro.org>
> ---
Applied to clk-hi3660 and merged into clk-next. I took the
liberty of using a function pointer in probe though so we don't
need the enum anymore.
---8<---
diff --git a/drivers/clk/hisilicon/clk-hi3660.c b/drivers/clk/hisilicon/clk-hi3660.c
index 4e752c632378..96a9697b06cf 100644
--- a/drivers/clk/hisilicon/clk-hi3660.c
+++ b/drivers/clk/hisilicon/clk-hi3660.c
@@ -14,14 +14,6 @@
#include <linux/platform_device.h>
#include "clk.h"
-enum hi3660_clk_type {
- HI3660_CRGCTRL = 1,
- HI3660_PCTRL,
- HI3660_PMUCTRL,
- HI3660_SCTRL,
- HI3660_IOMCU,
-};
-
static const struct hisi_fixed_rate_clock hi3660_fixed_rate_clks[] = {
{ HI3660_CLKIN_SYS, "clkin_sys", NULL, 0, 19200000, },
{ HI3660_CLKIN_REF, "clkin_ref", NULL, 0, 32764, },
@@ -533,15 +525,15 @@ static void hi3660_clk_crgctrl_init(struct device_node *np)
static const struct of_device_id hi3660_clk_match_table[] = {
{ .compatible = "hisilicon,hi3660-crgctrl",
- .data = (void *)HI3660_CRGCTRL },
+ .data = hi3660_clk_crgctrl_init },
{ .compatible = "hisilicon,hi3660-pctrl",
- .data = (void *)HI3660_PCTRL },
+ .data = hi3660_clk_pctrl_init },
{ .compatible = "hisilicon,hi3660-pmuctrl",
- .data = (void *)HI3660_PMUCTRL },
+ .data = hi3660_clk_pmuctrl_init },
{ .compatible = "hisilicon,hi3660-sctrl",
- .data = (void *)HI3660_SCTRL },
+ .data = hi3660_clk_sctrl_init },
{ .compatible = "hisilicon,hi3660-iomcu",
- .data = (void *)HI3660_IOMCU },
+ .data = hi3660_clk_iomcu_init },
{ }
};
@@ -549,31 +541,14 @@ static int hi3660_clk_probe(struct platform_device *pdev)
{
struct device *dev = &pdev->dev;
struct device_node *np = pdev->dev.of_node;
- enum hi3660_clk_type type;
+ void (*init_func)(struct device_node *np);
- type = (enum hi3660_clk_type)of_device_get_match_data(dev);
- if (!type)
+ init_func = of_device_get_match_data(dev);
+ if (!init_func)
return -ENODEV;
- switch (type) {
- case HI3660_CRGCTRL:
- hi3660_clk_crgctrl_init(np);
- break;
- case HI3660_PCTRL:
- hi3660_clk_pctrl_init(np);
- break;
- case HI3660_PMUCTRL:
- hi3660_clk_pmuctrl_init(np);
- break;
- case HI3660_SCTRL:
- hi3660_clk_sctrl_init(np);
- break;
- case HI3660_IOMCU:
- hi3660_clk_iomcu_init(np);
- break;
- default:
- break;
- }
+ init_func(np);
+
return 0;
}
--
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project
^ permalink raw reply related
* [PATCH] clk: mvebu: adjust AP806 CPU clock frequencies to production chip
From: Stephen Boyd @ 2017-01-10 0:26 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1482408494-7429-1-git-send-email-thomas.petazzoni@free-electrons.com>
On 12/22, Thomas Petazzoni wrote:
> This commit adjusts the list of possible "Sample At Reset" values that
> define the CPU clock frequency of the AP806 (part of Marvell Armada
> 7K/8K) to the values that have been validated with the production
> chip. Earlier values were preliminary.
>
> Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
> ---
Applied to clk-next
--
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project
^ permalink raw reply
* [PATCH] clk: uniphier: remove unneeded #include <linux/delay.h>
From: Stephen Boyd @ 2017-01-10 0:27 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1482719673-17573-1-git-send-email-yamada.masahiro@socionext.com>
On 12/26, Masahiro Yamada wrote:
> This include was needed to suppress build error when this driver
> was initially merged because <linux/regmap.h> did not include
> <linux/delay.h> at that time. (developers' headache across
> sub-systems)
>
> The root cause has been fixed by commit adf08d481b52 ("regmap:
> include <linux/delay.h> from include/linux/regmap.h"), so this
> line can be dropped now.
>
> Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
> ---
Applied to clk-next
--
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project
^ permalink raw reply
* [PATCH v2 1/6] mmc: sunxi: Always set signal delay to 0 for A64
From: André Przywara @ 2017-01-10 0:30 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <5eff19eec2b110bb643a38e7fef221208f585589.1483980339.git-series.maxime.ripard@free-electrons.com>
On 09/01/17 16:46, Maxime Ripard wrote:
> Experience have shown that the using the autocalibration could severely
> degrade the performances of the MMC bus.
>
> Allwinner is using in its BSP a delay set to 0 for all the modes but HS400.
> Remove the calibration code for now, and add comments to document our
> findings.
>
> Signed-off-by: Maxime Ripard <maxime.ripard@free-electrons.com>
> ---
> drivers/mmc/host/sunxi-mmc.c | 50 ++++++++++++-------------------------
> 1 file changed, 17 insertions(+), 33 deletions(-)
>
> diff --git a/drivers/mmc/host/sunxi-mmc.c b/drivers/mmc/host/sunxi-mmc.c
> index b1d1303389a7..ea9552a0d820 100644
> --- a/drivers/mmc/host/sunxi-mmc.c
> +++ b/drivers/mmc/host/sunxi-mmc.c
> @@ -683,41 +683,19 @@ static int sunxi_mmc_oclk_onoff(struct sunxi_mmc_host *host, u32 oclk_en)
>
> static int sunxi_mmc_calibrate(struct sunxi_mmc_host *host, int reg_off)
> {
> - 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;
> -
> - writel(reg | SDXC_CAL_START, host->reg_base + reg_off);
> -
> - dev_dbg(mmc_dev(host->mmc), "calibration started\n");
> -
> - timeout = jiffies + HZ * SDXC_CAL_TIMEOUT;
> -
> - while (!((reg = readl(host->reg_base + reg_off)) & SDXC_CAL_DONE)) {
> - if (time_before(jiffies, timeout))
> - cpu_relax();
> - else {
> - reg &= ~SDXC_CAL_START;
> - writel(reg, host->reg_base + reg_off);
> -
> - return -ETIMEDOUT;
> - }
> - }
> -
> - delay = (reg >> SDXC_CAL_DL_SHIFT) & SDXC_CAL_DL_MASK;
> -
> - reg &= ~SDXC_CAL_START;
> - reg |= (delay << SDXC_CAL_DL_SW_SHIFT) | SDXC_CAL_DL_SW_EN;
> -
> - writel(reg, host->reg_base + reg_off);
> -
> - dev_dbg(mmc_dev(host->mmc), "calibration ended, reg is 0x%x\n", reg);
> + /*
> + * FIXME:
> + * This is not clear how the calibration is supposed to work
> + * yet. The best rate have been obtained by simply setting the
> + * delay to 0, as Allwinner does in its BSP.
> + *
> + * The only mode that doesn't have such a delay is HS400, that
> + * is in itself a TODO.
> + */
> + writel(SDXC_CAL_DL_SW_EN, host->reg_base + reg_off);
>
> return 0;
> }
> @@ -806,7 +784,13 @@ static int sunxi_mmc_clk_set_rate(struct sunxi_mmc_host *host,
> if (ret)
> return ret;
>
> - /* TODO: enable calibrate on sdc2 SDXC_REG_DS_DL_REG of A64 */
> + /*
> + * FIXME:
> + *
> + * In HS400 we'll also need to calibrate the data strobe
> + * signal. This should only happen on the MMC2 controller (at
> + * least on the A64 and older SoCs).
Which older SoCs have this calibration register and a DS signal?
Is that supposed to mean "other" SoCs?
Other than that:
Reviewed-by: Andre Przywara <andre.przywara@arm.com>
Cheers,
Andre.
^ permalink raw reply
* [PATCH v2 04/12] driver: clk: imx: Add clock driver for imx6sll
From: Stephen Boyd @ 2017-01-10 0:37 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1482832070-22668-5-git-send-email-ping.bai@nxp.com>
On 12/27, Bai Ping wrote:
> diff --git a/drivers/clk/imx/clk-imx6sll.c b/drivers/clk/imx/clk-imx6sll.c
> new file mode 100644
> index 0000000..73758fe1
> --- /dev/null
> +++ b/drivers/clk/imx/clk-imx6sll.c
> @@ -0,0 +1,369 @@
> +/*
> + * Copyright (C) 2016 Freescale Semiconductor, Inc.
> + *
> + * The code contained herein is licensed under the GNU General Public
> + * License. You may obtain a copy of the GNU General Public License
> + * Version 2 or later at the following locations:
> + *
> + * http://www.opensource.org/licenses/gpl-license.html
> + * http://www.gnu.org/copyleft/gpl.html
> + */
> +
> +#include <dt-bindings/clock/imx6sll-clock.h>
> +#include <linux/clk.h>
> +#include <linux/clkdev.h>
Is this used?
> +#include <linux/err.h>
> +#include <linux/init.h>
> +#include <linux/io.h>
> +#include <linux/of.h>
> +#include <linux/of_address.h>
> +#include <linux/of_irq.h>
Is this used?
> +#include <linux/types.h>
> +
> +#include "clk.h"
> +
> +#define CCM_ANALOG_PLL_BYPASS (0x1 << 16)
> +#define BM_CCM_CCDR_MMDC_CH0_MASK (0x2 << 16)
> +#define CCDR 0x4
> +#define xPLL_CLR(offset) (offset + 0x8)
> +
> +static const char *pll_bypass_src_sels[] = { "osc", "dummy", };
All these should be const char * const unless something is wrong.
> +static const char *pll1_bypass_sels[] = { "pll1", "pll1_bypass_src", };
> +static const char *pll2_bypass_sels[] = { "pll2", "pll2_bypass_src", };
> +static const char *pll3_bypass_sels[] = { "pll3", "pll3_bypass_src", };
> +static const char *pll4_bypass_sels[] = { "pll4", "pll4_bypass_src", };
> +static const char *pll5_bypass_sels[] = { "pll5", "pll5_bypass_src", };
> +static const char *pll6_bypass_sels[] = { "pll6", "pll6_bypass_src", };
[...]
> + clks[IMX6SLL_CLK_USDHC3] = imx_clk_gate2("usdhc3", "usdhc3_podf", base + 0x80, 6);
> +
> + /* mask handshake of mmdc */
> + writel_relaxed(BM_CCM_CCDR_MMDC_CH0_MASK, base + CCDR);
> +
> + for (i = 0; i < ARRAY_SIZE(clks); i++)
> + if (IS_ERR(clks[i]))
> + pr_err("i.MX6SLL clk %d: register failed with %ld\n", i, PTR_ERR(clks[i]));
> +
> + clk_data.clks = clks;
> + clk_data.clk_num = ARRAY_SIZE(clks);
> + of_clk_add_provider(np, of_clk_src_onecell_get, &clk_data);
> +
> + /* set perclk to from OSC */
> + clk_set_parent(clks[IMX6SLL_CLK_PERCLK_SEL], clks[IMX6SLL_CLK_OSC]);
Can this be done with assigned-clocks in DT?
> +
> + for (i = 0; i < ARRAY_SIZE(clks_init_on); i++)
> + clk_prepare_enable(clks[clks_init_on[i]]);
Critical clocks?
> +
> + if (IS_ENABLED(CONFIG_USB_MXS_PHY)) {
> + clk_prepare_enable(clks[IMX6SLL_CLK_USBPHY1_GATE]);
> + clk_prepare_enable(clks[IMX6SLL_CLK_USBPHY2_GATE]);
The phy driver can't enable these?
> + }
> +
> + /* Lower the AHB clock rate before changing the clock source. */
> + clk_set_rate(clks[IMX6SLL_CLK_AHB], 99000000);
> +
> + /* Change periph_pre clock to pll2_bus to adjust AXI rate to 264MHz */
> + clk_set_parent(clks[IMX6SLL_CLK_PERIPH_CLK2_SEL], clks[IMX6SLL_CLK_PLL3_USB_OTG]);
> + clk_set_parent(clks[IMX6SLL_CLK_PERIPH], clks[IMX6SLL_CLK_PERIPH_CLK2]);
> + clk_set_parent(clks[IMX6SLL_CLK_PERIPH_PRE], clks[IMX6SLL_CLK_PLL2_BUS]);
> + clk_set_parent(clks[IMX6SLL_CLK_PERIPH], clks[IMX6SLL_CLK_PERIPH_PRE]);
> +
> + clk_set_rate(clks[IMX6SLL_CLK_AHB], 132000000);
assigned-clocks for rates now? Or perhaps we shouldn't be
exposing these as clks if they have some sort of complicated rate
sequence switch that we can't guarantee with the clk_ops we have
today.
> +}
> +
> +CLK_OF_DECLARE(imx6sll, "fsl,imx6sll-ccm", imx6sll_clocks_init);
> +
Please drop this extra newline.
--
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project
^ permalink raw reply
* [PATCH v3] rtc: armada38x: Follow the new recommendation for errata implementation
From: Alexandre Belloni @ 2017-01-10 0:38 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161221102816.6939-1-gregory.clement@free-electrons.com>
On 21/12/2016 at 11:28:16 +0100, Gregory CLEMENT wrote :
> According to RES-3124064:
>
> The device supports CPU write and read access to the RTC time register.
> However, due to this restriction, read and write from/to internal RTC
> register may fail.
>
> Workaround:
> General setup:
> 1. Configure the RTC Mbus Bridge Timing Control register (offset 0x184A0)
> to value 0xFD4D4FFF
> Write RTC WRCLK Period to its maximum value (0x3FF)
> Write RTC WRCLK setup to 0x29
> Write RTC WRCLK High Time to 0x53 (default value)
> Write RTC Read Output Delay to its maximum value (0x1F)
> Mbus - Read All Byte Enable to 0x1 (default value)
> 2. Configure the RTC Test Configuration Register (offset 0xA381C) bit3
> to '1' (Reserved, Marvell internal)
>
> For any RTC register read operation:
> 1. Read the requested register 100 times.
> 2. Find the result that appears most frequently and use this result
> as the correct value.
>
> For any RTC register write operation:
> 1. Issue two dummy writes of 0x0 to the RTC Status register (offset
> 0xA3800).
> 2. Write the time to the RTC Time register (offset 0xA380C).
>
> This patch is based on the work of Shaker Daibes
>
> Signed-off-by: Gregory CLEMENT <gregory.clement@free-electrons.com>
> ---
> Hi,
>
> this patch followed the patch series sent here:
> http://lists.infradead.org/pipermail/linux-arm-kernel/2016-December/473232.html
>
> For now I kept the patch 2 converting to time64_t apart after Russell
> King feedback.
>
> Changelog:
>
> v2 -> v3:
> - Removed unrelated change
> - Remove Unnecessary blank line
> - Used u32 instead of uint32_t
> - use the new errata name: RES-3124064 instead of FE-3124064
>
> v1 -> v2:
> - merged the patch 1 and 3
> - substantially modified the 1st patch with I think a better
> implementation:
> - First I do not put anymore more a big array onto the stack as
> suggested by Andrew Lunn.
> - Then I optimize the way to find the correct value.
>
> Gregory
>
> drivers/rtc/rtc-armada38x.c | 118 +++++++++++++++++++++++++++++++++++---------
> 1 file changed, 95 insertions(+), 23 deletions(-)
>
Applied, thanks.
--
Alexandre Belloni, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com
^ permalink raw reply
* [PATCH v2 5/6] arm64: allwinner: a64: Add MMC pinctrl nodes
From: André Przywara @ 2017-01-10 0:54 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <f7a004f7905badbd8e6fea7fd8591a498b396b9d.1483980339.git-series.maxime.ripard@free-electrons.com>
On 09/01/17 16:46, Maxime Ripard wrote:
> The A64 only has a single set of pins for each MMC controller. Since we
> already have boards that require all of them, let's add them to the DTSI.
This matches my reworked version from the previous series, so:
Reviewed-by: Andre Przywara <andre.przywara@arm.com>
Cheers,
Andre.
>
> Signed-off-by: Maxime Ripard <maxime.ripard@free-electrons.com>
> ---
> arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi | 25 ++++++++++++++++++++-
> 1 file changed, 25 insertions(+), 0 deletions(-)
>
> diff --git a/arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi b/arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi
> index 143e9706438f..8e149498e096 100644
> --- a/arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi
> +++ b/arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi
> @@ -205,6 +205,31 @@
> function = "i2c1";
> };
>
> + mmc0_pins: mmc0-pins {
> + pins = "PF0", "PF1", "PF2", "PF3",
> + "PF4", "PF5";
> + function = "mmc0";
> + drive-strength = <30>;
> + bias-pull-up;
> + };
> +
> + mmc1_pins: mmc1-pins {
> + pins = "PG0", "PG1", "PG2", "PG3",
> + "PG4", "PG5";
> + function = "mmc1";
> + drive-strength = <30>;
> + bias-pull-up;
> + };
> +
> + mmc2_pins: mmc2-pins {
> + pins = "PC1", "PC5", "PC6", "PC8", "PC9",
> + "PC10","PC11", "PC12", "PC13",
> + "PC14", "PC15", "PC16";
> + function = "mmc2";
> + drive-strength = <30>;
> + bias-pull-up;
> + };
> +
> uart0_pins_a: uart0 at 0 {
> pins = "PB8", "PB9";
> function = "uart0";
>
^ permalink raw reply
* [PATCH v2] arm64: dts: rockchip: add "rockchip, grf" property for RK3399 PMUCRU/CRU
From: Xing Zheng @ 2017-01-10 0:57 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAD=FV=WjzU_2QSLET3Y9_5A5khXjqMYNzB2ifextKhekmvCsjw@mail.gmail.com>
Hi Doug,
? 2017?01?10? 02:52, Doug Anderson ??:
> This looks sane to me, but before you land it you need to first send
> up a (separate) patch that adjusts:
>
> Documentation/devicetree/bindings/clock/rockchip,rk3399-cru.txt
>
> ...it would also be sorta nice if you included an a patch in your
> series that actually uses this new functionality.
Sorry to miss it. Thanks for your reminding me.
--
- Xing Zheng
^ permalink raw reply
* [PATCHv2 1/2] arm: Cleanup sanity_check_meminfo
From: Laura Abbott @ 2017-01-10 1:07 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <alpine.LFD.2.20.1701052308020.21662@knanqh.ubzr>
On 01/05/2017 08:17 PM, Nicolas Pitre wrote:
> On Thu, 5 Jan 2017, Laura Abbott wrote:
>
>>
>> The logic for sanity_check_meminfo has become difficult to
>> follow. Clean up the code so it's more obvious what the code
>> is actually trying to do. Additionally, meminfo is now removed
>> so rename the function to better describe it's purpose.
>
> s/it's/its/
>
>> Signed-off-by: Laura Abbott <lauraa@codeaurora.org>
>> Signed-off-by: Laura Abbott <labbott@redhat.com>
>> ---
>> v2: Fixed code so b9a019899f61 ("ARM: 8590/1: sanity_check_meminfo():
>> avoid overflow on vmalloc_limit") should stay fixed. The casting and assignment
>> still seem ugly.
>
> Are you referring to the initial vmalloc_limit assignment?
>
I was referring to the min_t with u64 that gets assigned to phys_addr_t.
for lowmem_limit
>> @@ -1172,43 +1170,19 @@ void __init sanity_check_meminfo(void)
>> for_each_memblock(memory, reg) {
>> phys_addr_t block_start = reg->base;
>> phys_addr_t block_end = reg->base + reg->size;
>> - phys_addr_t size_limit = reg->size;
>>
>> - if (reg->base >= vmalloc_limit)
>> - highmem = 1;
>> - else
>> - size_limit = vmalloc_limit - reg->base;
>>
>> -
> [...]
>
> This leaves a spurious empty line. One was already there before your
> patch but this would be a good opportunity to remove it.
>
> Other than that...
>
> Reviewed-by: Nicolas Pitre <nico@linaro.org>
>
>
> Nicolas
>
Thanks,
Laura
^ permalink raw reply
* [PATCH v4 3/3] drm: zte: add overlay plane support
From: Shawn Guo @ 2017-01-10 1:17 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAOw6vbLrHuEa_L9uW6X-_ZMkfXyGjaFACFoedVYN1epeMW+9=w@mail.gmail.com>
Hi Sean,
On Mon, Jan 09, 2017 at 11:27:44AM -0500, Sean Paul wrote:
> > +static inline void zx_osd_int_update(struct zx_crtc *zcrtc)
> > +{
> > + struct zx_vou_hw *vou = zcrtc->vou;
> > + int i;
> > +
> > + vou_chn_set_update(zcrtc);
> > + zx_plane_set_update(zcrtc->primary);
> > +
> > + for (i = 0; i < VL_NUM; i++) {
> > + struct drm_plane *overlay = vou->overlays[i];
> > +
> > + if (overlay)
> > + zx_plane_set_update(overlay);
> > + }
>
> Hi Shawn,
> Thanks so much for revving this patch, it's looking really good. I
> just have one (1.5, really) suggestion.
>
> I don't think we need to keep vou->overlays around. You should be able
> to loop through all the planes registered with drm core and use
> crtc->state->plane_mask to determine which are active for a given crtc
> (this would also encapsulate the zcrtc->primary update above).
>
> I think you can also use if (plane->state->crtc) as your
> enable/disable check in zx_plane_set_update() and eliminate the new
> enabled flag.
Great. Since I'm still quite new to DRM subsystem, such core
infrastructural usage guide are really helpful for me. I tested the
changes as you suggested, and they worked just fine. So happy to see my
code gets cleaned up further.
> I fully realize this was my suggestion, and I apologize
> for the churn. I'll try not to do reviews past midnight again :-)
I'm so grateful to you for helping review my code, especially in
midnight time :)
Shawn
^ permalink raw reply
* [PATCHv3 0/2] Memblock cleanup plus memory removal fix
From: Laura Abbott @ 2017-01-10 1:18 UTC (permalink / raw)
To: linux-arm-kernel
Hi,
This is v3 of the series ot make sanity_check_meminfo (renamed in this series)
more readable and less error prone and fix an existing bug. This is just typo
and style fixes from v2.
Russell, if I don't hear any objections in a few days I am going to put this in
the patch tracker.
As a reminder, of the motivation fot this series, during the course of
https://marc.info/?l=linux-arm-kernel&m=148145259511248, Grygorii Strashko
reminded me of another issue where I proposed a patch but never followed up on
it. The patch in
http://lists.infradead.org/pipermail/linux-arm-kernel/2014-October/296978.html
did some cleanup and renaming of sanity_check_meminfo. I think this makes the
code more readable so I'd like to resurect it and rebase my fix
http://lists.infradead.org/pipermail/linux-arm-kernel/2016-December/474060.html
on top of it.
Laura Abbott (2):
arm: Cleanup sanity_check_meminfo
arm: Adjust memory boundaries after reservations
arch/arm/kernel/setup.c | 10 +++++--
arch/arm/mm/mmu.c | 69 +++++++++++++++++++------------------------------
arch/arm/mm/nommu.c | 8 +++---
3 files changed, 39 insertions(+), 48 deletions(-)
--
2.7.4
^ permalink raw reply
* [PATCHv3 1/2] arm: Cleanup sanity_check_meminfo
From: Laura Abbott @ 2017-01-10 1:18 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1484011113-8223-1-git-send-email-labbott@redhat.com>
The logic for sanity_check_meminfo has become difficult to
follow. Clean up the code so it's more obvious what the code
is actually trying to do. Additionally, meminfo is now removed
so rename the function to better describe its purpose.
Tested-by: Magnus Lilja <lilja.magnus@gmail.com>
Reviewed-by: Nicolas Pitre <nico@linaro.org>
Signed-off-by: Laura Abbott <lauraa@codeaurora.org>
Signed-off-by: Laura Abbott <labbott@redhat.com>
---
v3: Typo and style fixups
---
arch/arm/kernel/setup.c | 4 +--
arch/arm/mm/mmu.c | 66 ++++++++++++++++++-------------------------------
arch/arm/mm/nommu.c | 8 +++---
3 files changed, 30 insertions(+), 48 deletions(-)
diff --git a/arch/arm/kernel/setup.c b/arch/arm/kernel/setup.c
index 34e3f3c..8a8051c 100644
--- a/arch/arm/kernel/setup.c
+++ b/arch/arm/kernel/setup.c
@@ -81,7 +81,7 @@ __setup("fpe=", fpe_setup);
extern void init_default_cache_policy(unsigned long);
extern void paging_init(const struct machine_desc *desc);
extern void early_paging_init(const struct machine_desc *);
-extern void sanity_check_meminfo(void);
+extern void adjust_lowmem_bounds(void);
extern enum reboot_mode reboot_mode;
extern void setup_dma_zone(const struct machine_desc *desc);
@@ -1093,7 +1093,7 @@ void __init setup_arch(char **cmdline_p)
setup_dma_zone(mdesc);
xen_early_init();
efi_init();
- sanity_check_meminfo();
+ adjust_lowmem_bounds();
arm_memblock_init(mdesc);
early_ioremap_reset();
diff --git a/arch/arm/mm/mmu.c b/arch/arm/mm/mmu.c
index 4001dd1..b8f70a3 100644
--- a/arch/arm/mm/mmu.c
+++ b/arch/arm/mm/mmu.c
@@ -1152,13 +1152,11 @@ early_param("vmalloc", early_vmalloc);
phys_addr_t arm_lowmem_limit __initdata = 0;
-void __init sanity_check_meminfo(void)
+void __init adjust_lowmem_bounds(void)
{
phys_addr_t memblock_limit = 0;
- int highmem = 0;
u64 vmalloc_limit;
struct memblock_region *reg;
- bool should_use_highmem = false;
/*
* Let's use our own (unoptimized) equivalent of __pa() that is
@@ -1172,43 +1170,18 @@ void __init sanity_check_meminfo(void)
for_each_memblock(memory, reg) {
phys_addr_t block_start = reg->base;
phys_addr_t block_end = reg->base + reg->size;
- phys_addr_t size_limit = reg->size;
- if (reg->base >= vmalloc_limit)
- highmem = 1;
- else
- size_limit = vmalloc_limit - reg->base;
-
-
- if (!IS_ENABLED(CONFIG_HIGHMEM) || cache_is_vipt_aliasing()) {
-
- if (highmem) {
- pr_notice("Ignoring RAM at %pa-%pa (!CONFIG_HIGHMEM)\n",
- &block_start, &block_end);
- memblock_remove(reg->base, reg->size);
- should_use_highmem = true;
- continue;
- }
-
- if (reg->size > size_limit) {
- phys_addr_t overlap_size = reg->size - size_limit;
-
- pr_notice("Truncating RAM at %pa-%pa",
- &block_start, &block_end);
- block_end = vmalloc_limit;
- pr_cont(" to -%pa", &block_end);
- memblock_remove(vmalloc_limit, overlap_size);
- should_use_highmem = true;
- }
- }
-
- if (!highmem) {
- if (block_end > arm_lowmem_limit) {
- if (reg->size > size_limit)
- arm_lowmem_limit = vmalloc_limit;
- else
- arm_lowmem_limit = block_end;
- }
+ if (reg->base < vmalloc_limit) {
+ if (block_end > arm_lowmem_limit)
+ /*
+ * Compare as u64 to ensure vmalloc_limit does
+ * not get truncated. block_end should always
+ * fit in phys_addr_t so there should be no
+ * issue with assignment.
+ */
+ arm_lowmem_limit = min_t(u64,
+ vmalloc_limit,
+ block_end);
/*
* Find the first non-pmd-aligned page, and point
@@ -1233,9 +1206,6 @@ void __init sanity_check_meminfo(void)
}
}
- if (should_use_highmem)
- pr_notice("Consider using a HIGHMEM enabled kernel.\n");
-
high_memory = __va(arm_lowmem_limit - 1) + 1;
/*
@@ -1248,6 +1218,18 @@ void __init sanity_check_meminfo(void)
if (!memblock_limit)
memblock_limit = arm_lowmem_limit;
+ if (!IS_ENABLED(CONFIG_HIGHMEM) || cache_is_vipt_aliasing()) {
+ if (memblock_end_of_DRAM() > arm_lowmem_limit) {
+ phys_addr_t end = memblock_end_of_DRAM();
+
+ pr_notice("Ignoring RAM at %pa-%pa\n",
+ &memblock_limit, &end);
+ pr_notice("Consider using a HIGHMEM enabled kernel.\n");
+
+ memblock_remove(memblock_limit, end - memblock_limit);
+ }
+ }
+
memblock_set_current_limit(memblock_limit);
}
diff --git a/arch/arm/mm/nommu.c b/arch/arm/mm/nommu.c
index 2740967..13a25d6 100644
--- a/arch/arm/mm/nommu.c
+++ b/arch/arm/mm/nommu.c
@@ -85,7 +85,7 @@ static unsigned long irbar_read(void)
}
/* MPU initialisation functions */
-void __init sanity_check_meminfo_mpu(void)
+void __init adjust_lowmem_bounds_mpu(void)
{
phys_addr_t phys_offset = PHYS_OFFSET;
phys_addr_t aligned_region_size, specified_mem_size, rounded_mem_size;
@@ -274,7 +274,7 @@ void __init mpu_setup(void)
}
}
#else
-static void sanity_check_meminfo_mpu(void) {}
+static void adjust_lowmem_bounds_mpu(void) {}
static void __init mpu_setup(void) {}
#endif /* CONFIG_ARM_MPU */
@@ -295,10 +295,10 @@ void __init arm_mm_memblock_reserve(void)
#endif
}
-void __init sanity_check_meminfo(void)
+void __init adjust_lowmem_bounds(void)
{
phys_addr_t end;
- sanity_check_meminfo_mpu();
+ adjust_lowmem_bounds_mpu();
end = memblock_end_of_DRAM();
high_memory = __va(end - 1) + 1;
memblock_set_current_limit(end);
--
2.7.4
^ permalink raw reply related
* [PATCHv3 2/2] arm: Adjust memory boundaries after reservations
From: Laura Abbott @ 2017-01-10 1:18 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1484011113-8223-1-git-send-email-labbott@redhat.com>
adjust_lowmem_bounds is responsible for setting up the boundary for
lowmem/highmem. This needs to be setup before memblock reservations can
occur. At the time memblock reservations can occur, memory can also be
removed from the system. The lowmem/highmem boundary and end of memory
may be affected by this but it is currently not recalculated. On some
systems this may be harmless, on others this may result in incorrect
ranges being passed to the main memory allocator. Correct this by
recalculating the lowmem/highmem boundary after all reservations have
been made.
Tested-by: Magnus Lilja <lilja.magnus@gmail.com>
Signed-off-by: Laura Abbott <labbott@redhat.com>
---
v3: Typos and style fixes
---
arch/arm/kernel/setup.c | 6 ++++++
arch/arm/mm/mmu.c | 9 ++++++---
2 files changed, 12 insertions(+), 3 deletions(-)
diff --git a/arch/arm/kernel/setup.c b/arch/arm/kernel/setup.c
index 8a8051c..f4e5450 100644
--- a/arch/arm/kernel/setup.c
+++ b/arch/arm/kernel/setup.c
@@ -1093,8 +1093,14 @@ void __init setup_arch(char **cmdline_p)
setup_dma_zone(mdesc);
xen_early_init();
efi_init();
+ /*
+ * Make sure the calculation for lowmem/highmem is set appropriately
+ * before reserving/allocating any mmeory
+ */
adjust_lowmem_bounds();
arm_memblock_init(mdesc);
+ /* Memory may have been removed so recalculate the bounds. */
+ adjust_lowmem_bounds();
early_ioremap_reset();
diff --git a/arch/arm/mm/mmu.c b/arch/arm/mm/mmu.c
index b8f70a3..5cbfd9f 100644
--- a/arch/arm/mm/mmu.c
+++ b/arch/arm/mm/mmu.c
@@ -1157,6 +1157,7 @@ void __init adjust_lowmem_bounds(void)
phys_addr_t memblock_limit = 0;
u64 vmalloc_limit;
struct memblock_region *reg;
+ phys_addr_t lowmem_limit = 0;
/*
* Let's use our own (unoptimized) equivalent of __pa() that is
@@ -1172,14 +1173,14 @@ void __init adjust_lowmem_bounds(void)
phys_addr_t block_end = reg->base + reg->size;
if (reg->base < vmalloc_limit) {
- if (block_end > arm_lowmem_limit)
+ if (block_end > lowmem_limit)
/*
* Compare as u64 to ensure vmalloc_limit does
* not get truncated. block_end should always
* fit in phys_addr_t so there should be no
* issue with assignment.
*/
- arm_lowmem_limit = min_t(u64,
+ lowmem_limit = min_t(u64,
vmalloc_limit,
block_end);
@@ -1200,12 +1201,14 @@ void __init adjust_lowmem_bounds(void)
if (!IS_ALIGNED(block_start, PMD_SIZE))
memblock_limit = block_start;
else if (!IS_ALIGNED(block_end, PMD_SIZE))
- memblock_limit = arm_lowmem_limit;
+ memblock_limit = lowmem_limit;
}
}
}
+ arm_lowmem_limit = lowmem_limit;
+
high_memory = __va(arm_lowmem_limit - 1) + 1;
/*
--
2.7.4
^ permalink raw reply related
* [PATCH 0/3] arm64: dts: A64 board MMC support
From: Andre Przywara @ 2017-01-10 1:22 UTC (permalink / raw)
To: linux-arm-kernel
These patches here go on top of Maxime's latest A64 MMC series and
enable the MMC controllers on the boards using the A64 SoC.
As the BananaPi-M64 DT now looks different, lets adds support for
that board as well, with one major difference to the Pine64 being the eMMC
chip.
I could't find commit f9ca9b952ee1 Maxime mentioned in his cover letter,
so I applied his patches on top of sunxi/for-next and cherry-picked
b4b8664d29 to fix the arm64 build.
Cheers,
Andre.
Andre Przywara (3):
arm64: dts: Pine64: add MMC support
arm64: dts: sun50i: add UART1 pin nodes
arm64: dts: add BananaPi-M64 support
arch/arm64/boot/dts/allwinner/Makefile | 1 +
.../boot/dts/allwinner/sun50i-a64-bananapi-m64.dts | 120 +++++++++++++++++++++
.../arm64/boot/dts/allwinner/sun50i-a64-pine64.dts | 20 ++++
arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi | 10 ++
4 files changed, 151 insertions(+)
create mode 100644 arch/arm64/boot/dts/allwinner/sun50i-a64-bananapi-m64.dts
--
2.8.2
^ permalink raw reply
* [PATCH 1/3] arm64: dts: Pine64: add MMC support
From: Andre Przywara @ 2017-01-10 1:22 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1484011353-21480-1-git-send-email-andre.przywara@arm.com>
All Pine64 boards connect an micro-SD card slot to the first MMC
controller.
Enable the respective DT node and specify the (always-on) regulator
and card-detect pin.
As a micro-SD slot does not feature a write-protect switch, we disable
this feature.
Signed-off-by: Andre Przywara <andre.przywara@arm.com>
---
arch/arm64/boot/dts/allwinner/sun50i-a64-pine64.dts | 20 ++++++++++++++++++++
1 file changed, 20 insertions(+)
diff --git a/arch/arm64/boot/dts/allwinner/sun50i-a64-pine64.dts b/arch/arm64/boot/dts/allwinner/sun50i-a64-pine64.dts
index cf91051..c680ed3 100644
--- a/arch/arm64/boot/dts/allwinner/sun50i-a64-pine64.dts
+++ b/arch/arm64/boot/dts/allwinner/sun50i-a64-pine64.dts
@@ -44,6 +44,8 @@
#include "sun50i-a64.dtsi"
+#include <dt-bindings/gpio/gpio.h>
+
/ {
model = "Pine64";
compatible = "pine64,pine64", "allwinner,sun50i-a64";
@@ -55,6 +57,13 @@
chosen {
stdout-path = "serial0:115200n8";
};
+
+ reg_vcc3v3: vcc3v3 {
+ compatible = "regulator-fixed";
+ regulator-name = "vcc3v3";
+ regulator-min-microvolt = <3300000>;
+ regulator-max-microvolt = <3300000>;
+ };
};
&ehci1 {
@@ -71,6 +80,17 @@
bias-pull-up;
};
+&mmc0 {
+ pinctrl-names = "default";
+ pinctrl-0 = <&mmc0_pins>;
+ vmmc-supply = <®_vcc3v3>;
+ cd-gpios = <&pio 5 6 GPIO_ACTIVE_HIGH>;
+ cd-inverted;
+ disable-wp;
+ bus-width = <4>;
+ status = "okay";
+};
+
&ohci1 {
status = "okay";
};
--
2.8.2
^ permalink raw reply related
* [PATCH 2/3] arm64: dts: sun50i: add UART1 pin nodes
From: Andre Przywara @ 2017-01-10 1:22 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1484011353-21480-1-git-send-email-andre.przywara@arm.com>
On many boards UART1 connects to a Bluetooth chip, so add the pinctrl
nodes for the only pins providing access to that UART. That includes
those pins for hardware flow control (RTS/CTS).
Signed-off-by: Andre Przywara <andre.przywara@arm.com>
---
arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi | 10 ++++++++++
1 file changed, 10 insertions(+)
diff --git a/arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi b/arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi
index f46ae96..419b0b1 100644
--- a/arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi
+++ b/arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi
@@ -234,6 +234,16 @@
pins = "PB8", "PB9";
function = "uart0";
};
+
+ uart1_pins: uart1_pins {
+ pins = "PG6", "PG7";
+ function = "uart1";
+ };
+
+ uart1_rts_cts_pins: uart1_rts_cts_pins {
+ pins = "PG8", "PG9";
+ function = "uart1";
+ };
};
uart0: serial at 1c28000 {
--
2.8.2
^ permalink raw reply related
* [PATCH v2 2/2] clk: hisilicon: Add clock driver for hi3660 SoC
From: zhangfei @ 2017-01-10 1:22 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20170110002224.GH17126@codeaurora.org>
On 2017?01?10? 08:22, Stephen Boyd wrote:
> On 12/29, Zhangfei Gao wrote:
>> Add clock drivers for hi3660 SoC, this driver controls the SoC
>> registers to supply different clocks to different IPs in the SoC.
>>
>> Signed-off-by: Zhangfei Gao <zhangfei.gao@linaro.org>
>> ---
> Applied to clk-hi3660 and merged into clk-next. I took the
> liberty of using a function pointer in probe though so we don't
> need the enum anymore.
Good idea. It is simplified a lot.
Have verified on hikey960.
Thanks Stephen for the help.
^ permalink raw reply
* [PATCH 3/3] arm64: dts: add BananaPi-M64 support
From: Andre Przywara @ 2017-01-10 1:22 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1484011353-21480-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 | 120 +++++++++++++++++++++
2 files changed, 121 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..bc6f342 100644
--- a/arch/arm64/boot/dts/allwinner/Makefile
+++ b/arch/arm64/boot/dts/allwinner/Makefile
@@ -1,3 +1,4 @@
+dtb-$(CONFIG_ARCH_SUNXI) += sun50i-a64-bananapi-m64.dtb
dtb-$(CONFIG_ARCH_SUNXI) += sun50i-a64-pine64-plus.dtb sun50i-a64-pine64.dtb
always := $(dtb-y)
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..6872135
--- /dev/null
+++ b/arch/arm64/boot/dts/allwinner/sun50i-a64-bananapi-m64.dts
@@ -0,0 +1,120 @@
+/*
+ * 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"
+
+#include <dt-bindings/gpio/gpio.h>
+
+/ {
+ 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>;
+ };
+};
+
+&i2c1 {
+ pinctrl-names = "default";
+ pinctrl-0 = <&i2c1_pins>;
+ status = "okay";
+};
+
+&i2c1_pins {
+ bias-pull-up;
+};
+
+&mmc0 {
+ pinctrl-names = "default";
+ pinctrl-0 = <&mmc0_pins>;
+ vmmc-supply = <®_vcc3v3>;
+ cd-gpios = <&pio 5 6 GPIO_ACTIVE_HIGH>;
+ 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";
+};
+
+&uart0 {
+ pinctrl-names = "default";
+ pinctrl-0 = <&uart0_pins_a>;
+ status = "okay";
+};
+
+&uart1 {
+ pinctrl-names = "default";
+ pinctrl-0 = <&uart1_pins>, <&uart1_rts_cts_pins>;
+ status = "okay";
+};
--
2.8.2
^ permalink raw reply related
* [PATCH v3] arm64: dts: rockchip: add "rockchip, grf" property for RK3399 PMUCRU/CRU
From: Xing Zheng @ 2017-01-10 1:27 UTC (permalink / raw)
To: linux-arm-kernel
The structure rockchip_clk_provider needs to refer the GRF regmap
in somewhere, if the CRU node has not "rockchip,grf" property,
calling syscon_regmap_lookup_by_phandle will return an invalid GRF
regmap, and the MUXGRF type clock will be not supported.
Therefore, we need to add them.
Signed-off-by: Xing Zheng <zhengxing@rock-chips.com>
---
Changes in v3:
- add optional roperty rockchip,grf in rockchip,rk3399-cru.txt
Changes in v2:
- referring pmugrf for PMUGRU
- fix the typo "invaild" in COMMIT message
Documentation/devicetree/bindings/clock/rockchip,rk3399-cru.txt | 5 +++++
arch/arm64/boot/dts/rockchip/rk3399.dtsi | 2 ++
2 files changed, 7 insertions(+)
diff --git a/Documentation/devicetree/bindings/clock/rockchip,rk3399-cru.txt b/Documentation/devicetree/bindings/clock/rockchip,rk3399-cru.txt
index 3888dd3..f476b3d 100644
--- a/Documentation/devicetree/bindings/clock/rockchip,rk3399-cru.txt
+++ b/Documentation/devicetree/bindings/clock/rockchip,rk3399-cru.txt
@@ -13,6 +13,11 @@ Required Properties:
- #clock-cells: should be 1.
- #reset-cells: should be 1.
+Optional Properties:
+
+- rockchip,grf: phandle to the syscon managing the "general register files"
+ If missing pll rates are not changable, due to the missing pll lock status.
+
Each clock is assigned an identifier and client nodes can use this identifier
to specify the clock which they consume. All available clocks are defined as
preprocessor macros in the dt-bindings/clock/rk3399-cru.h headers and can be
diff --git a/arch/arm64/boot/dts/rockchip/rk3399.dtsi b/arch/arm64/boot/dts/rockchip/rk3399.dtsi
index c928015..081621b 100644
--- a/arch/arm64/boot/dts/rockchip/rk3399.dtsi
+++ b/arch/arm64/boot/dts/rockchip/rk3399.dtsi
@@ -1077,6 +1077,7 @@
pmucru: pmu-clock-controller at ff750000 {
compatible = "rockchip,rk3399-pmucru";
reg = <0x0 0xff750000 0x0 0x1000>;
+ rockchip,grf = <&pmugrf>;
#clock-cells = <1>;
#reset-cells = <1>;
assigned-clocks = <&pmucru PLL_PPLL>;
@@ -1086,6 +1087,7 @@
cru: clock-controller at ff760000 {
compatible = "rockchip,rk3399-cru";
reg = <0x0 0xff760000 0x0 0x1000>;
+ rockchip,grf = <&grf>;
#clock-cells = <1>;
#reset-cells = <1>;
assigned-clocks =
--
2.7.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