* [RFC PATCH 5/5] arm64: dts: sunxi: add support for the Orange Pi PC 2 board
From: Andre Przywara @ 2016-11-24 1:17 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1479950235-26821-1-git-send-email-andre.przywara@arm.com>
The Orange Pi PC 2 is a typical single board computer using the
Allwinner H5 SoC. Apart from the usual suspects it features three
separately driven USB ports and a Gigabit Ethernet port.
Also it has a SPI NOR flash soldered, from which the board can boot
from. This enables the SBC to behave like a "real computer" with
built-in firmware.
Add the board specific .dts file, which includes the H5 .dtsi and
enables the peripherals that we support so far.
Signed-off-by: Andre Przywara <andre.przywara@arm.com>
---
arch/arm64/boot/dts/allwinner/Makefile | 1 +
.../boot/dts/allwinner/sun50i-h5-orangepi-pc2.dts | 183 +++++++++++++++++++++
2 files changed, 184 insertions(+)
create mode 100644 arch/arm64/boot/dts/allwinner/sun50i-h5-orangepi-pc2.dts
diff --git a/arch/arm64/boot/dts/allwinner/Makefile b/arch/arm64/boot/dts/allwinner/Makefile
index 1e29a5a..b26bb46 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-h5-orangepi-pc2.dtb
always := $(dtb-y)
subdir-y := $(dts-dirs)
diff --git a/arch/arm64/boot/dts/allwinner/sun50i-h5-orangepi-pc2.dts b/arch/arm64/boot/dts/allwinner/sun50i-h5-orangepi-pc2.dts
new file mode 100644
index 0000000..a29ca6b
--- /dev/null
+++ b/arch/arm64/boot/dts/allwinner/sun50i-h5-orangepi-pc2.dts
@@ -0,0 +1,183 @@
+/*
+ * 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 file 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 file 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-h5.dtsi"
+
+#include <dt-bindings/gpio/gpio.h>
+#include <dt-bindings/input/input.h>
+#include <dt-bindings/pinctrl/sun4i-a10.h>
+
+/ {
+ model = "Xunlong Orange Pi PC 2";
+ compatible = "xunlong,orangepi-pc2", "allwinner,sun50i-h5";
+
+ reg_vcc3v3: vcc3v3 {
+ compatible = "regulator-fixed";
+ regulator-name = "vcc3v3";
+ regulator-min-microvolt = <3300000>;
+ regulator-max-microvolt = <3300000>;
+ };
+
+ aliases {
+ serial0 = &uart0;
+ };
+
+ chosen {
+ stdout-path = "serial0:115200n8";
+ };
+
+ leds {
+ compatible = "gpio-leds";
+ pinctrl-names = "default";
+ pinctrl-0 = <&leds_opc>, <&leds_r_opc>;
+
+ pwr_led {
+ label = "orangepi:green:pwr";
+ gpios = <&r_pio 0 10 GPIO_ACTIVE_HIGH>;
+ default-state = "on";
+ };
+
+ status_led {
+ label = "orangepi:red:status";
+ gpios = <&pio 0 15 GPIO_ACTIVE_HIGH>;
+ };
+ };
+
+ r_gpio_keys {
+ compatible = "gpio-keys";
+ pinctrl-names = "default";
+ pinctrl-0 = <&sw_r_opc>;
+
+ sw4 {
+ label = "sw4";
+ linux,code = <BTN_0>;
+ gpios = <&r_pio 0 3 GPIO_ACTIVE_LOW>;
+ };
+ };
+};
+
+&ehci1 {
+ status = "okay";
+};
+
+&ehci2 {
+ status = "okay";
+};
+
+&ehci3 {
+ status = "okay";
+};
+
+&ir {
+ pinctrl-names = "default";
+ pinctrl-0 = <&ir_pins_a>;
+ status = "okay";
+};
+
+&mmc0 {
+ pinctrl-names = "default";
+ pinctrl-0 = <&mmc0_pins_a>, <&mmc0_cd_pin>;
+ vmmc-supply = <®_vcc3v3>;
+ bus-width = <4>;
+ cd-gpios = <&pio 5 6 GPIO_ACTIVE_HIGH>; /* PF6 */
+ cd-inverted;
+ status = "okay";
+};
+
+&ohci1 {
+ status = "okay";
+};
+
+&ohci2 {
+ status = "okay";
+};
+
+&ohci3 {
+ status = "okay";
+};
+
+&pio {
+ leds_opc: led_pins at 0 {
+ allwinner,pins = "PA15";
+ allwinner,function = "gpio_out";
+ allwinner,drive = <SUN4I_PINCTRL_10_MA>;
+ allwinner,pull = <SUN4I_PINCTRL_NO_PULL>;
+ };
+};
+
+&r_pio {
+ leds_r_opc: led_pins at 0 {
+ allwinner,pins = "PL10";
+ allwinner,function = "gpio_out";
+ allwinner,drive = <SUN4I_PINCTRL_10_MA>;
+ allwinner,pull = <SUN4I_PINCTRL_NO_PULL>;
+ };
+
+ sw_r_opc: key_pins at 0 {
+ allwinner,pins = "PL3";
+ allwinner,function = "gpio_in";
+ allwinner,drive = <SUN4I_PINCTRL_10_MA>;
+ allwinner,pull = <SUN4I_PINCTRL_NO_PULL>;
+ };
+};
+
+&uart0 {
+ pinctrl-names = "default";
+ pinctrl-0 = <&uart0_pins_a>;
+ status = "okay";
+};
+
+&uart1 {
+ pinctrl-names = "default";
+ pinctrl-0 = <&uart1_pins>;
+};
+
+&uart2 {
+ pinctrl-names = "default";
+ pinctrl-0 = <&uart2_pins>;
+};
+
+&usbphy {
+ /* USB VBUS is always on */
+ status = "okay";
+};
--
2.8.2
^ permalink raw reply related
* [PATCH] cpufreq: dt: Add support for r8a7743 and r8a7745
From: Rafael J. Wysocki @ 2016-11-24 1:17 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161116100906.GA20987@vireshk-i7>
On Wednesday, November 16, 2016 03:39:06 PM Viresh Kumar wrote:
> On 16-11-16, 11:05, Geert Uytterhoeven wrote:
> > Add the compatible strings for supporting the generic cpufreq driver on
> > the Renesas RZ/G1M (r8a7743) and RZ/G1E (r8a7745) SoCs.
> >
> > Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
> > ---
> > Support for RZ/G1M and RZ/G1E is expected to land in v4.10.
>
> Acked-by: Viresh Kumar <viresh.kumar@linaro.org>
Applied.
Thanks,
Rafael
^ permalink raw reply
* [alsa-devel] [PATCH v2] clkdev: add devm_of_clk_get()
From: Kuninori Morimoto @ 2016-11-24 1:45 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161123191037.GE25626@codeaurora.org>
Hi Stephen
Thank you for your feedback
> I've seen bindings that have the 'clocks' property at the top
> level and the appropriate 'clock-names' property to relate the
> clocks to a subnode.
>
> sound_soc {
> clocks = <&xxx>, <&xxx>;
> clock-names = "cpu", "codec";
> ...
> cpu {
> ...
> };
> codec {
> ...
> };
> };
>
> Then the subnodes call clk_get() with the top level device and
> the name of their node and things match up. I suppose this
> binding is finalized though, so we can't really do that?
>
> I see that the gpio framework has a similar design called
> devm_get_gpiod_from_child(), so how about we add a
> devm_get_clk_from_child() API? That would more closely match the
> intent here, which is to restrict the clk_get() operation to
> child nodes of the device passed as the first argument.
>
> struct clk *devm_get_clk_from_child(struct device *dev,
> const char *con_id,
> struct device_node *child);
Thanks. I will check above 2 ideas.
Best regards
---
Kuninori Morimoto
^ permalink raw reply
* [PATCH 2/2] clk: uniphier: add clock data for cpufreq
From: Stephen Boyd @ 2016-11-24 2:10 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAK7LNAQ6XeSHd7DbvD1jWeMfOqk8+R27Q-fNDWtXxpRd=OFgjA@mail.gmail.com>
On 11/24, Masahiro Yamada wrote:
> Hi Stephen,
>
>
> 2016-11-24 9:05 GMT+09:00 Stephen Boyd <sboyd@codeaurora.org>:
>
> >> +#if 1
> >> + /*
> >> + * TODO:
> >> + * The return type of .round_rate() is "long", which is 32 bit wide on
> >> + * 32 bit systems. Clock rate greater than LONG_MAX (~ 2.15 GHz) is
> >> + * treated as an error. Needs a workaround until the problem is fixed.
> >> + */
> >
> > Just curious is the problem internal to the clk framework because
> > of the clk_ops::round_rate design? Or does the consumer, cpufreq
> > in this case, have to deal with rates that are larger than
> > unsigned long on a 32 bit system? If it's just a clk_ops problem
> > and we need to support rates up to 32 bits wide (~ 4.3 GHz) on
> > the system then the driver could be changed to use
> > .determine_rate() ops and that would allow us to use all the bits
> > of unsigned long to figure out rates.
> >
> > If the problem is rates even larger than unsigned long on 32 bit
> > systems, then at the least I'd like to see some sort of plan to
> > fix that in the framework before merging code. Hopefully it can
> > be done gradually, but as I start looking at it it seems more and
> > more complicated to support this so this will be a long term
> > project.
> >
> > We can discuss the clk API changes needed as well if those are
> > required, but that is another issue that requires changes in
> > other places outside of clk drivers.
> >
>
> I understand your point, but core frame-work changes
> need more careful review than clk data changes in low-level drivers.
> It is too late to be included in v4.10.
>
> If I drop 32bit SoC things, and send v2 only for 64bit SoCs,
> is that acceptable for 4.10-rc1?
Sure. That sounds fine for now. I'll reply to your other thread
with a plan of attack on how to do the framework changes. I think
we need to do those regardless of the outcome of your
investigation.
--
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project
^ permalink raw reply
* [PATCH v3] clk: qoriq: added ls1012a clock configuration
From: yuantian.tang at nxp.com @ 2016-11-24 2:36 UTC (permalink / raw)
To: linux-arm-kernel
From: Tang Yuantian <Yuantian.Tang@nxp.com>
Signed-off-by: Tang Yuantian <yuantian.tang@nxp.com>
---
v3:
- rebased to latest kernel and re-sorted the code
v2:
- remove commit message as it is duplicated to title
drivers/clk/clk-qoriq.c | 19 +++++++++++++++++++
1 file changed, 19 insertions(+)
diff --git a/drivers/clk/clk-qoriq.c b/drivers/clk/clk-qoriq.c
index 7dd4351..697310e 100644
--- a/drivers/clk/clk-qoriq.c
+++ b/drivers/clk/clk-qoriq.c
@@ -291,6 +291,14 @@ static const struct clockgen_muxinfo ls1046a_hwa2 = {
},
};
+static const struct clockgen_muxinfo ls1012a_cmux = {
+ {
+ [0] = { CLKSEL_VALID, CGA_PLL1, PLL_DIV1 },
+ {},
+ [2] = { CLKSEL_VALID, CGA_PLL1, PLL_DIV2 },
+ }
+};
+
static const struct clockgen_muxinfo t1023_hwa1 = {
{
{},
@@ -529,6 +537,16 @@ static const struct clockgen_chipinfo chipinfo[] = {
.flags = CG_PLL_8BIT,
},
{
+ .compat = "fsl,ls1012a-clockgen",
+ .cmux_groups = {
+ &ls1012a_cmux
+ },
+ .cmux_to_group = {
+ 0, -1
+ },
+ .pll_mask = 0x03,
+ },
+ {
.compat = "fsl,ls2080a-clockgen",
.cmux_groups = {
&clockgen2_cmux_cga12, &clockgen2_cmux_cgb
@@ -1316,6 +1334,7 @@ CLK_OF_DECLARE(qoriq_clockgen_2, "fsl,qoriq-clockgen-2.0", clockgen_init);
CLK_OF_DECLARE(qoriq_clockgen_ls1021a, "fsl,ls1021a-clockgen", clockgen_init);
CLK_OF_DECLARE(qoriq_clockgen_ls1043a, "fsl,ls1043a-clockgen", clockgen_init);
CLK_OF_DECLARE(qoriq_clockgen_ls1046a, "fsl,ls1046a-clockgen", clockgen_init);
+CLK_OF_DECLARE(qoriq_clockgen_ls1012a, "fsl,ls1012a-clockgen", clockgen_init);
CLK_OF_DECLARE(qoriq_clockgen_ls2080a, "fsl,ls2080a-clockgen", clockgen_init);
/* Legacy nodes */
--
2.1.0.27.g96db324
^ permalink raw reply related
* [PATCH v7 4/4] vcodec: mediatek: Add Maintainers entry for Mediatek JPEG driver
From: Rick Chang @ 2016-11-24 2:53 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1479786377-11567-5-git-send-email-rick.chang@mediatek.com>
Hi Hans,
Is it possible to update this patch? or I should create another new one.
I may need to update it.
Sorry for the inconvenience.
On Tue, 2016-11-22 at 11:46 +0800, Rick Chang wrote:
> Signed-off-by: Rick Chang <rick.chang@mediatek.com>
> Signed-off-by: Minghsiu Tsai <minghsiu.tsai@mediatek.com>
> ---
> MAINTAINERS | 7 +++++++
> 1 file changed, 7 insertions(+)
>
> diff --git a/MAINTAINERS b/MAINTAINERS
> index 93e9f42..a9e7ee0 100644
> --- a/MAINTAINERS
> +++ b/MAINTAINERS
> @@ -7818,6 +7818,13 @@ L: netdev at vger.kernel.org
> S: Maintained
> F: drivers/net/ethernet/mediatek/
>
> +MEDIATEK JPEG DRIVER
> +M: Rick Chang <rick.chang@mediatek.com>
> +M: Minghsiu Tsai <minghsiu.tsai@mediatek.com>
> +S: Supported
> +F: drivers/media/platform/mtk-jpeg/
> +F: Documentation/devicetree/bindings/media/mediatek-jpeg-decoder.txt
> +
> MEDIATEK MEDIA DRIVER
> M: Tiffany Lin <tiffany.lin@mediatek.com>
> M: Andrew-CT Chen <andrew-ct.chen@mediatek.com>
^ permalink raw reply
* [PATCH v16 13/15] acpi/arm64: Add memory-mapped timer support in GTDT driver
From: Fu Wei @ 2016-11-24 3:57 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CADyBb7sTVWC3d6kRDTA=SGYz9J4pwWvaJxXu3AMBAgQT4y7fTw@mail.gmail.com>
Hi Lorenzo,
On 23 November 2016 at 19:53, Fu Wei <fu.wei@linaro.org> wrote:
> Hi Lorenzo,
>
> On 18 November 2016 at 22:22, Lorenzo Pieralisi
> <lorenzo.pieralisi@arm.com> wrote:
>> On Wed, Nov 16, 2016 at 09:49:06PM +0800, fu.wei at linaro.org wrote:
>>> From: Fu Wei <fu.wei@linaro.org>
>>>
>>> On platforms booting with ACPI, architected memory-mapped timers'
>>> configuration data is provided by firmware through the ACPI GTDT
>>> static table.
>>>
>>> The clocksource architected timer kernel driver requires a firmware
>>> interface to collect timer configuration and configure its driver.
>>> this infrastructure is present for device tree systems, but it is
>>> missing on systems booting with ACPI.
>>>
>>> Implement the kernel infrastructure required to parse the static
>>> ACPI GTDT table so that the architected timer clocksource driver can
>>> make use of it on systems booting with ACPI, therefore enabling
>>> the corresponding timers configuration.
>>>
>>> Signed-off-by: Fu Wei <fu.wei@linaro.org>
>>> Signed-off-by: Hanjun Guo <hanjun.guo@linaro.org>
>>> ---
>>> drivers/acpi/arm64/gtdt.c | 95 +++++++++++++++++++++++++++++++++++++++++++++++
>>> include/linux/acpi.h | 1 +
>>> 2 files changed, 96 insertions(+)
>>>
>>> diff --git a/drivers/acpi/arm64/gtdt.c b/drivers/acpi/arm64/gtdt.c
>>> index 2de79aa..08d9506 100644
>>> --- a/drivers/acpi/arm64/gtdt.c
>>> +++ b/drivers/acpi/arm64/gtdt.c
>>> @@ -51,6 +51,14 @@ static inline bool is_timer_block(void *platform_timer)
>>> return gh->type == ACPI_GTDT_TYPE_TIMER_BLOCK;
>>> }
>>>
>>> +static inline struct acpi_gtdt_timer_block *get_timer_block(unsigned int index)
>>> +{
>>> + if (index >= acpi_gtdt_desc.timer_block_count || !timer_block)
>>> + return NULL;
>>> +
>>> + return timer_block[index];
>>> +}
>>> +
>>> static inline bool is_watchdog(void *platform_timer)
>>> {
>>> struct acpi_gtdt_header *gh = platform_timer;
>>> @@ -214,3 +222,90 @@ int __init acpi_gtdt_init(struct acpi_table_header *table)
>>> acpi_gtdt_release();
>>> return -EINVAL;
>>> }
>>> +
>>> +/*
>>> + * Get ONE GT block info for memory-mapped timer from GTDT table.
>>> + * @data: the GT block data (parsing result)
>>> + * @index: the index number of GT block
>>> + * Note: we already verify @data in caller, it can't be NULL here.
>>> + * Returns 0 if success, -EINVAL/-ENODEV if error.
>>> + */
>>
>> Documentation/kernel-doc-nano-HOWTO.txt
>
> Great thanks , will fix all the comments :-)
>
>>
>>> +int __init gtdt_arch_timer_mem_init(struct arch_timer_mem *data,
>>> + unsigned int index)
>>
>> Nit: acpi_arch_timer_mem_init() to make it consistent with other ACPI
>> calls ?
>
> yes, it makes sense, will do this way for the function which is exported
>
>>
>>> +{
>>> + struct acpi_gtdt_timer_block *block;
>>> + struct acpi_gtdt_timer_entry *frame;
>>> + int i;
>>> +
>>> + block = get_timer_block(index);
>>> + if (!block)
>>> + return -ENODEV;
>>> +
>>> + if (!block->timer_count) {
>>> + pr_err(FW_BUG "GT block present, but frame count is zero.");
>>> + return -ENODEV;
>>> + }
>>> +
>>> + if (block->timer_count > ARCH_TIMER_MEM_MAX_FRAMES) {
>>> + pr_err(FW_BUG "GT block lists %d frames, ACPI spec only allows 8\n",
>>> + block->timer_count);
>>> + return -EINVAL;
>>> + }
>>
>> Nit: these two checks can be carried out at GTDT init where the GTDT
>> is parsed first. Actually you could have two functions one to init
>
> this check is the verify the data in GT block, but the GTDT init
> won't get into the block,
> so I think that is better to keep this in GT block init function
> "acpi_arch_timer_mem_init()"
>
>> timers (say acpi_gtdt_timers_init()) and one watchdogs, that would
>> eliminate the duplicated timer_block/watchdog arrays (both sized
>> Platform Timer Count) and acpi_gtdt_timers_init() can return
>> the number of entries found so that you can loop with a determined
>> upper bound in the arm arch timer driver.
>
> Yes, I did this way in previous patchset, but we still need to do scan
> loop in both functions for
> two types of platform timer.
> So I decide to keep the scan loop in the acpi_gtdt_init to get the
> number and the entries pointer
> of each type of platform timers in one go. then we don't need to scan
> GTDT in two functions.
I have thought about this again, I think I should keep the loop in each
type of platform timers. The benefit we can get from this are:
(1) reduce the global variables:
static struct acpi_gtdt_timer_block **timer_block __initdata;
static struct acpi_gtdt_watchdog **watchdog __initdata;
make them in thire own init function.
(2) avoid allocating and free memory in different functions.
we also can return all the GT block info in one go.
>
>>
>> Just thinking aloud, these are just improvements I can carry them
>> out later, the more important question here is the interface between the
>> parsing code and the arch timer probing code which depends on other
>> patches and that needs to be agreed, this patch is not really a problem.
>
> yes, every time I modify the interface I have to change the driver :-(
>
>>
>>> + data->cntctlbase = (phys_addr_t)block->block_address;
>>> + /*
>>> + * We can NOT get the size info from GTDT table,
>>> + * but according to "Table * CNTCTLBase memory map" of
>>> + * <ARM Architecture Reference Manual> for ARMv8,
>>> + * it should be 4KB(Offset 0x000 ? 0xFFC).
>>
>> That's the reason why it is not explicit in the GTDT table :)
>>
>>> + data->size = SZ_4K;
>>> + data->num_frames = block->timer_count;
>>> +
>>> + frame = (void *)block + block->timer_offset;
>>> + if (frame + block->timer_count != (void *)block + block->header.length)
>>> + return -EINVAL;
>>> +
>>> + /*
>>> + * Get the GT timer Frame data for every GT Block Timer
>>> + */
>>> + for (i = 0; i < block->timer_count; i++, frame++) {
>>> + if (!frame->base_address || !frame->timer_interrupt)
>>> + return -EINVAL;
>>> +
>>> + data->frame[i].phys_irq = map_gt_gsi(frame->timer_interrupt,
>>> + frame->timer_flags);
>>> + if (data->frame[i].phys_irq <= 0) {
>>> + pr_warn("failed to map physical timer irq in frame %d.\n",
>>> + i);
>>> + return -EINVAL;
>>> + }
>>> +
>>> + if (frame->virtual_timer_interrupt) {
>>> + data->frame[i].virt_irq =
>>> + map_gt_gsi(frame->virtual_timer_interrupt,
>>> + frame->virtual_timer_flags);
>>> + if (data->frame[i].virt_irq <= 0) {
>>> + pr_warn("failed to map virtual timer irq in frame %d.\n",
>>> + i);
>>> + return -EINVAL;
>>
>> You should unregister phys_irq here for correctness, right ?
>
> yup, thanks for pointing this bug out. :-)
>
>>
>>> + }
>>> + }
>>> +
>>> + data->frame[i].frame_nr = frame->frame_number;
>>> + data->frame[i].cntbase = frame->base_address;
>>> + /*
>>> + * We can NOT get the size info from GTDT table,
>>> + * but according to "Table * CNTBaseN memory map" of
>>> + * <ARM Architecture Reference Manual> for ARMv8,
>>> + * it should be 4KB(Offset 0x000 ? 0xFFC).
>>
>> See above.
>
> yes, you are right, I will fix both comments
>
>>
>>> + */
>>> + data->frame[i].size = SZ_4K;
>>> + }
>>> +
>>> + if (acpi_gtdt_desc.timer_block_count)
>>> + pr_info("parsed No.%d of %d memory-mapped timer block(s).\n",
>>> + index, acpi_gtdt_desc.timer_block_count);
>>
>> I am not sure how helpful this message can be honestly.
>
> yup, I will simplify it :-)
>
>>
>>> +
>>> + return 0;
>>> +}
>>> diff --git a/include/linux/acpi.h b/include/linux/acpi.h
>>> index a1611d1..44b8c1b 100644
>>> --- a/include/linux/acpi.h
>>> +++ b/include/linux/acpi.h
>>> @@ -582,6 +582,7 @@ int acpi_gtdt_init(struct acpi_table_header *table);
>>> int acpi_gtdt_map_ppi(int type);
>>> bool acpi_gtdt_c3stop(int type);
>>> void acpi_gtdt_release(void);
>>> +int gtdt_arch_timer_mem_init(struct arch_timer_mem *data, unsigned int index);
>>
>> See above.
>>
>> Overall it looks fine as long as the interface with clocksource is
>> settled, which is what really needs to be agreed upon in this series.
>
> Thanks for your help :-)
>
>>
>> Lorenzo
>>
>>> #endif
>>>
>>> #else /* !CONFIG_ACPI */
>>> --
>>> 2.7.4
>>>
>
>
>
> --
> Best regards,
>
> Fu Wei
> Software Engineer
> Red Hat
--
Best regards,
Fu Wei
Software Engineer
Red Hat
^ permalink raw reply
* [RFC PATCH 2/5] dmaengine: allow sun6i-dma for more SoCs
From: Chen-Yu Tsai @ 2016-11-24 4:16 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1479950235-26821-3-git-send-email-andre.przywara@arm.com>
Hi,
On Thu, Nov 24, 2016 at 9:17 AM, Andre Przywara <andre.przywara@arm.com> wrote:
> The sun6i DMA driver is used in the Allwinner A64 and H5 SoC, which
> have arm64 capable cores. Add the generic sunxi config symbol to allow
> the driver to be selected by arm64 Kconfigs, which don't feature
> SoC specific MACH_xxxx configs.
>
> Signed-off-by: Andre Przywara <andre.przywara@arm.com>
> ---
> drivers/dma/Kconfig | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/dma/Kconfig b/drivers/dma/Kconfig
> index af63a6b..003c284 100644
> --- a/drivers/dma/Kconfig
> +++ b/drivers/dma/Kconfig
> @@ -157,7 +157,7 @@ config DMA_SUN4I
>
> config DMA_SUN6I
> tristate "Allwinner A31 SoCs DMA support"
> - depends on MACH_SUN6I || MACH_SUN8I || COMPILE_TEST
> + depends on MACH_SUN6I || MACH_SUN8I || COMPILE_TEST || ARCH_SUNXI
AFAIK ARCH_SUNXI encompasses/supersedes MACH_SUN*I.
(And I don't have to add MACH_SUN9I later :) )
ChenYu
> depends on RESET_CONTROLLER
> select DMA_ENGINE
> select DMA_VIRTUAL_CHANNELS
> --
> 2.8.2
>
^ permalink raw reply
* [PATCH 4/4] serial: imx: Add LED trigger support
From: kbuild test robot @ 2016-11-24 4:46 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161123100106.15969-5-s.hauer@pengutronix.de>
Hi Sascha,
[auto build test ERROR on tty/tty-testing]
[also build test ERROR on v4.9-rc6 next-20161123]
[if your patch is applied to the wrong git tree, please drop us a note to help improve the system]
url: https://github.com/0day-ci/linux/commits/Sascha-Hauer/serial-core-Add-LED-trigger-support/20161124-010846
base: https://git.kernel.org/pub/scm/linux/kernel/git/gregkh/tty.git tty-testing
config: s390-allmodconfig (attached as .config)
compiler: s390x-linux-gnu-gcc (Debian 6.1.1-9) 6.1.1 20160705
reproduce:
wget https://git.kernel.org/cgit/linux/kernel/git/wfg/lkp-tests.git/plain/sbin/make.cross -O ~/bin/make.cross
chmod +x ~/bin/make.cross
# save the attached .config to linux build tree
make.cross ARCH=s390
All errors (new ones prefixed by >>):
>> ERROR: "uart_remove_led_triggers" [drivers/tty/serial/imx.ko] undefined!
>> ERROR: "uart_led_trigger_rx" [drivers/tty/serial/imx.ko] undefined!
>> ERROR: "uart_led_trigger_tx" [drivers/tty/serial/imx.ko] undefined!
>> ERROR: "uart_add_led_triggers" [drivers/tty/serial/imx.ko] undefined!
ERROR: "uart_led_trigger_rx" [drivers/tty/serial/8250/8250_base.ko] undefined!
ERROR: "uart_led_trigger_tx" [drivers/tty/serial/8250/8250_base.ko] undefined!
ERROR: "uart_remove_led_triggers" [drivers/tty/serial/8250/8250.ko] undefined!
ERROR: "uart_add_led_triggers" [drivers/tty/serial/8250/8250.ko] undefined!
---
0-DAY kernel test infrastructure Open Source Technology Center
https://lists.01.org/pipermail/kbuild-all Intel Corporation
-------------- next part --------------
A non-text attachment was scrubbed...
Name: .config.gz
Type: application/gzip
Size: 43170 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20161124/34007947/attachment-0001.gz>
^ permalink raw reply
* [alsa-devel] [PATCH v2] clkdev: add devm_of_clk_get()
From: Kuninori Morimoto @ 2016-11-24 4:57 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <87a8cpejn5.wl%kuninori.morimoto.gx@renesas.com>
Hi Stephen, again
> > I've seen bindings that have the 'clocks' property at the top
> > level and the appropriate 'clock-names' property to relate the
> > clocks to a subnode.
> >
> > sound_soc {
> > clocks = <&xxx>, <&xxx>;
> > clock-names = "cpu", "codec";
> > ...
> > cpu {
> > ...
> > };
> > codec {
> > ...
> > };
> > };
> >
> > Then the subnodes call clk_get() with the top level device and
> > the name of their node and things match up. I suppose this
> > binding is finalized though, so we can't really do that?
> >
> > I see that the gpio framework has a similar design called
> > devm_get_gpiod_from_child(), so how about we add a
> > devm_get_clk_from_child() API? That would more closely match the
> > intent here, which is to restrict the clk_get() operation to
> > child nodes of the device passed as the first argument.
> >
> > struct clk *devm_get_clk_from_child(struct device *dev,
> > const char *con_id,
> > struct device_node *child);
Thanks, but, my point is that Linux already have "of_clk_get()",
but we don't have its devm_ version.
The point is that of_clk_get() can get clock from "device_node".
Why having devm_ version become so problem ?
Best regards
---
Kuninori Morimoto
^ permalink raw reply
* [PATCH v2] ARM: dts: da850: add the mstpri and ddrctl nodes
From: Sekhar Nori @ 2016-11-24 5:03 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <f88df859-3c0f-38f2-275d-ce6a9996fb6e@lechnology.com>
On Thursday 24 November 2016 04:18 AM, David Lechner wrote:
> On 11/23/2016 04:32 PM, Kevin Hilman wrote:
>> David Lechner <david@lechnology.com> writes:
>>
>>> On 11/23/2016 04:27 AM, Bartosz Golaszewski wrote:
>>>> 2016-11-22 23:23 GMT+01:00 David Lechner <david@lechnology.com>:
>>>>> On 11/15/2016 05:00 AM, Bartosz Golaszewski wrote:
>>>>>>
>>>>>> Add the nodes for the MSTPRI configuration and DDR2/mDDR memory
>>>>>> controller drivers to da850.dtsi.
>>>>>>
>>>>>> Signed-off-by: Bartosz Golaszewski <bgolaszewski@baylibre.com>
>>>>>> ---
>>>>>> v1 -> v2:
>>>>>> - moved the priority controller node above the cfgchip node
>>>>>> - renamed added nodes to better reflect their purpose
>>>>>>
>>>>>> arch/arm/boot/dts/da850.dtsi | 8 ++++++++
>>>>>> 1 file changed, 8 insertions(+)
>>>>>>
>>>>>> diff --git a/arch/arm/boot/dts/da850.dtsi
>>>>>> b/arch/arm/boot/dts/da850.dtsi
>>>>>> index 1bb1f6d..412eec6 100644
>>>>>> --- a/arch/arm/boot/dts/da850.dtsi
>>>>>> +++ b/arch/arm/boot/dts/da850.dtsi
>>>>>> @@ -210,6 +210,10 @@
>>>>>> };
>>>>>>
>>>>>> };
>>>>>> + prictrl: priority-controller at 14110 {
>>>>>> + compatible = "ti,da850-mstpri";
>>>>>> + reg = <0x14110 0x0c>;
>>>>>
>>>>>
>>>>> I think we should add status = "disabled"; here and let boards opt in.
>>>>>
>>>>>> + };
>>>>>> cfgchip: chip-controller at 1417c {
>>>>>> compatible = "ti,da830-cfgchip", "syscon",
>>>>>> "simple-mfd";
>>>>>> reg = <0x1417c 0x14>;
>>>>>> @@ -451,4 +455,8 @@
>>>>>> 1 0 0x68000000 0x00008000>;
>>>>>> status = "disabled";
>>>>>> };
>>>>>> + memctrl: memory-controller at b0000000 {
>>>>>> + compatible = "ti,da850-ddr-controller";
>>>>>> + reg = <0xb0000000 0xe8>;
>>>>>
>>>>>
>>>>> same here. status = "disabled";
>>>>>
>>>>>> + };
>>>>>> };
>>>>>>
>>>>
>>>> Hi David,
>>>>
>>>> I did that initially[1][2] and it was rejected by Kevin[3] and
>>>> Laurent[4].
>>>>
>>>> FYI this patch has already been queued by Sekhar.
>>>
>>> Thanks. I did not see those threads.
>>>
>>> FYI to maintainers, having these enabled by default causes error
>>> messages in the kernel log for other boards that are not supported by
>>> the drivers.
>>
>> Then the driver is too noisy and should be cleaned up.
>>
>>> Since there is only one board that is supported and soon
>>> to be 2 that are not, I would rather have this disabled by default to
>>> avoid the error messages.
>>
>> IMO, what exactly are the error messages? Sounds like the driver is
>> being too verbose, and calling things errors that are not really errors.
>
> It is just one line per driver.
>
> dev_err(dev, "no master priorities defined for this board\n");
>
> and
>
> dev_err(dev, "no settings defined for this board\n");
>
>
> Since "ti,da850-lcdk" is the only board supported in these drivers, all
> other boards will see these error messages.
Thats pretty bad. Sorry about that. The original justification for
keeping them enabled all the time was that they are in-SoC modules with
no external dependencies (like IO lines or voltage rails) so they can be
enabled on all boards that use DA850. While that remains true, the
configuration itself is board specific.
I think the error messages are still useful, so instead of silencing
them, I think we should go back to keeping these nodes disabled by
default and enabling only on boards which have support for it in the driver.
Thanks,
Sekhar
^ permalink raw reply
* [PATCH v4 3/3] dmaengine: sun6i: share the dma driver with sun50i
From: Chen-Yu Tsai @ 2016-11-24 5:04 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1479638740-20520-4-git-send-email-hao5781286@gmail.com>
Hi,
On Sun, Nov 20, 2016 at 6:45 PM, Hao Zhang <hao5781286@gmail.com> wrote:
> Changes the limited buswith to 8 bytes,and add
> the test in sun6i_dma_config function
>
> Accroding to sun6i dma driver, i think ,if the client
> doesn't configure the address width with dmaengine_slave_config
> function, it would use the default width. So we can add the test
> in sun6i_dma_config function called by dmaengine_slave_config,
> and test the configuration whether is support for the device.
>
One thing people haven't really noticed is that starting with
A80, A83T, H3, the DMA channel configuration registers have
been slightly changed when compared to A31/A23/A33. The DMA
burst length field offset was changed by 1.
We need to fix this.
ChenYu
> Signed-off-by: Hao Zhang <hao5781286@gmail.com>
> ---
> drivers/dma/sun6i-dma.c | 33 ++++++++++++++++++++++++++++++++-
> 1 file changed, 32 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/dma/sun6i-dma.c b/drivers/dma/sun6i-dma.c
> index a235878..f7c90b6 100644
> --- a/drivers/dma/sun6i-dma.c
> +++ b/drivers/dma/sun6i-dma.c
> @@ -250,7 +250,7 @@ static inline s8 convert_burst(u32 maxburst)
> static inline s8 convert_buswidth(enum dma_slave_buswidth addr_width)
> {
> if ((addr_width < DMA_SLAVE_BUSWIDTH_1_BYTE) ||
> - (addr_width > DMA_SLAVE_BUSWIDTH_4_BYTES))
> + (addr_width > DMA_SLAVE_BUSWIDTH_8_BYTES))
> return -EINVAL;
>
> return addr_width >> 1;
> @@ -758,6 +758,18 @@ static int sun6i_dma_config(struct dma_chan *chan,
> {
> struct sun6i_vchan *vchan = to_sun6i_vchan(chan);
>
> + if ((BIT(config->src_addr_width) | chan->device->src_addr_widths) !=
> + chan->device->src_addr_widths) {
> + dev_err(chan2dev(chan), "Invalid DMA configuration\n");
> + return -EINVAL;
> + }
> +
> + if ((BIT(config->dst_addr_width) | chan->device->dst_addr_widths) !=
> + chan->device->dst_addr_widths) {
> + dev_err(chan2dev(chan), "Invalid DMA configuration\n");
> + return -EINVAL;
> + }
> +
> memcpy(&vchan->cfg, config, sizeof(*config));
>
> return 0;
> @@ -1028,11 +1040,23 @@ static struct sun6i_dma_config sun8i_h3_dma_cfg = {
> .nr_max_vchans = 34,
> };
>
> +/*
> + * The A64 has 8 physical channels, a maximum DRQ port id of 27,
> + * and a total of 38 usable source and destination endpoints.
> + */
> +
> +static struct sun6i_dma_config sun50i_a64_dma_cfg = {
> + .nr_max_channels = 8,
> + .nr_max_requests = 27,
> + .nr_max_vchans = 38,
> +};
> +
> static const struct of_device_id sun6i_dma_match[] = {
> { .compatible = "allwinner,sun6i-a31-dma", .data = &sun6i_a31_dma_cfg },
> { .compatible = "allwinner,sun8i-a23-dma", .data = &sun8i_a23_dma_cfg },
> { .compatible = "allwinner,sun8i-a83t-dma", .data = &sun8i_a83t_dma_cfg },
> { .compatible = "allwinner,sun8i-h3-dma", .data = &sun8i_h3_dma_cfg },
> + { .compatible = "allwinner,sun50i-a64-dma", .data = &sun50i_a64_dma_cfg },
> { /* sentinel */ }
> };
> MODULE_DEVICE_TABLE(of, sun6i_dma_match);
> @@ -1112,6 +1136,13 @@ static int sun6i_dma_probe(struct platform_device *pdev)
> BIT(DMA_SLAVE_BUSWIDTH_4_BYTES);
> sdc->slave.directions = BIT(DMA_DEV_TO_MEM) |
> BIT(DMA_MEM_TO_DEV);
> +
> + if (of_device_is_compatible(pdev->dev.of_node,
> + "allwinner,sun50i-a64-dma")) {
> + sdc->slave.src_addr_widths |= BIT(DMA_SLAVE_BUSWIDTH_8_BYTES);
> + sdc->slave.dst_addr_widths |= BIT(DMA_SLAVE_BUSWIDTH_8_BYTES);
> + }
> +
> sdc->slave.residue_granularity = DMA_RESIDUE_GRANULARITY_BURST;
> sdc->slave.dev = &pdev->dev;
>
> --
> 2.7.4
>
^ permalink raw reply
* [PATCH 3/3] ARM: dts: da850: Add node for pullup/pulldown pinconf
From: Sekhar Nori @ 2016-11-24 5:54 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <06bc8517-8c33-85a1-9d5a-29042c7281db@lechnology.com>
On Wednesday 23 November 2016 09:54 PM, David Lechner wrote:
> On 11/23/2016 05:12 AM, Sekhar Nori wrote:
>> On Wednesday 23 November 2016 08:59 AM, David Lechner wrote:
>>> This SoC has a separate pin controller for configuring pullup/pulldown
>>> bias on groups of pins.
>>>
>>> Signed-off-by: David Lechner <david@lechnology.com>
>>> ---
>>> arch/arm/boot/dts/da850.dtsi | 5 +++++
>>> 1 file changed, 5 insertions(+)
>>>
>>> diff --git a/arch/arm/boot/dts/da850.dtsi b/arch/arm/boot/dts/da850.dtsi
>>> index 8945815..1c0224c 100644
>>> --- a/arch/arm/boot/dts/da850.dtsi
>>> +++ b/arch/arm/boot/dts/da850.dtsi
>>> @@ -210,6 +210,11 @@
>>> };
>>>
>>> };
>>> + pinconf: pin-controller at 22c00c {
>>> + compatible = "ti,da850-pupd";
>>> + reg = <0x22c00c 0x8>;
>>> + status = "disabled";
>>> + };
>>
>> Can you please place this below the i2c1 node. I am trying to keep the
>> nodes sorted by unit address. I know thats broken in many places today,
>> but lets add the new ones where they should eventually end up.
>
> I can do this, but it seems that the predominant sorting pattern here is
> to keep subsystems together (e.g. all i2c are together, all uart are
> together, etc.)
Yeah, but that quickly gives away as there are many singleton devices
and everyone tries to add theirs at the end of the list resulting in
merge conflicts.
> Would a separate patch to sort everything by unit address to get this
> cleaned up be acceptable?
Agree with Kevin that it would be churn. If done, it should be last
thing that gets done in a merge window. I would not attempt it in
relatively busy merge windows like this one.
Thanks,
Sekhar
^ permalink raw reply
* [PATCH v2 1/3] clk: uniphier: remove unneeded member name for union
From: Masahiro Yamada @ 2016-11-24 5:57 UTC (permalink / raw)
To: linux-arm-kernel
The struct member name of a union is unneeded. This makes the code
a bit shorter.
Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
---
Changes in v2:
- Newly added
drivers/clk/uniphier/clk-uniphier-core.c | 8 ++++----
drivers/clk/uniphier/clk-uniphier-mio.c | 2 +-
drivers/clk/uniphier/clk-uniphier.h | 6 +++---
3 files changed, 8 insertions(+), 8 deletions(-)
diff --git a/drivers/clk/uniphier/clk-uniphier-core.c b/drivers/clk/uniphier/clk-uniphier-core.c
index 26c53f7..726a10a 100644
--- a/drivers/clk/uniphier/clk-uniphier-core.c
+++ b/drivers/clk/uniphier/clk-uniphier-core.c
@@ -29,16 +29,16 @@ static struct clk_hw *uniphier_clk_register(struct device *dev,
switch (data->type) {
case UNIPHIER_CLK_TYPE_FIXED_FACTOR:
return uniphier_clk_register_fixed_factor(dev, data->name,
- &data->data.factor);
+ &data->factor);
case UNIPHIER_CLK_TYPE_FIXED_RATE:
return uniphier_clk_register_fixed_rate(dev, data->name,
- &data->data.rate);
+ &data->rate);
case UNIPHIER_CLK_TYPE_GATE:
return uniphier_clk_register_gate(dev, regmap, data->name,
- &data->data.gate);
+ &data->gate);
case UNIPHIER_CLK_TYPE_MUX:
return uniphier_clk_register_mux(dev, regmap, data->name,
- &data->data.mux);
+ &data->mux);
default:
dev_err(dev, "unsupported clock type\n");
return ERR_PTR(-EINVAL);
diff --git a/drivers/clk/uniphier/clk-uniphier-mio.c b/drivers/clk/uniphier/clk-uniphier-mio.c
index 218d20f..4974d38 100644
--- a/drivers/clk/uniphier/clk-uniphier-mio.c
+++ b/drivers/clk/uniphier/clk-uniphier-mio.c
@@ -30,7 +30,7 @@
.name = "sd" #ch "-sel", \
.type = UNIPHIER_CLK_TYPE_MUX, \
.idx = -1, \
- .data.mux = { \
+ .mux = { \
.parent_names = { \
"sd-44m", \
"sd-33m", \
diff --git a/drivers/clk/uniphier/clk-uniphier.h b/drivers/clk/uniphier/clk-uniphier.h
index 0244dba..4eb4f6d 100644
--- a/drivers/clk/uniphier/clk-uniphier.h
+++ b/drivers/clk/uniphier/clk-uniphier.h
@@ -62,7 +62,7 @@ struct uniphier_clk_data {
struct uniphier_clk_fixed_rate_data rate;
struct uniphier_clk_gate_data gate;
struct uniphier_clk_mux_data mux;
- } data;
+ };
};
#define UNIPHIER_CLK_FACTOR(_name, _idx, _parent, _mult, _div) \
@@ -70,7 +70,7 @@ struct uniphier_clk_data {
.name = (_name), \
.type = UNIPHIER_CLK_TYPE_FIXED_FACTOR, \
.idx = (_idx), \
- .data.factor = { \
+ .factor = { \
.parent_name = (_parent), \
.mult = (_mult), \
.div = (_div), \
@@ -83,7 +83,7 @@ struct uniphier_clk_data {
.name = (_name), \
.type = UNIPHIER_CLK_TYPE_GATE, \
.idx = (_idx), \
- .data.gate = { \
+ .gate = { \
.parent_name = (_parent), \
.reg = (_reg), \
.bit = (_bit), \
--
2.7.4
^ permalink raw reply related
* [PATCH v2 2/3] clk: uniphier: add CPU-gear change (cpufreq) support
From: Masahiro Yamada @ 2016-11-24 5:57 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1479967061-25975-1-git-send-email-yamada.masahiro@socionext.com>
Core support code for CPU frequency changes, which will be used by
the generic cpufreq driver.
The register view is different from the generic clk-mux; it has
a separate status register, and an update bit to load the register
setting.
Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
---
Changes in v2: None
drivers/clk/uniphier/Makefile | 3 +
drivers/clk/uniphier/clk-uniphier-core.c | 3 +
drivers/clk/uniphier/clk-uniphier-cpugear.c | 115 ++++++++++++++++++++++++++++
drivers/clk/uniphier/clk-uniphier.h | 17 +++-
4 files changed, 136 insertions(+), 2 deletions(-)
create mode 100644 drivers/clk/uniphier/clk-uniphier-cpugear.c
diff --git a/drivers/clk/uniphier/Makefile b/drivers/clk/uniphier/Makefile
index f27b3603..665d1d6 100644
--- a/drivers/clk/uniphier/Makefile
+++ b/drivers/clk/uniphier/Makefile
@@ -1,8 +1,11 @@
obj-y += clk-uniphier-core.o
+
+obj-y += clk-uniphier-cpugear.o
obj-y += clk-uniphier-fixed-factor.o
obj-y += clk-uniphier-fixed-rate.o
obj-y += clk-uniphier-gate.o
obj-y += clk-uniphier-mux.o
+
obj-y += clk-uniphier-sys.o
obj-y += clk-uniphier-mio.o
obj-y += clk-uniphier-peri.o
diff --git a/drivers/clk/uniphier/clk-uniphier-core.c b/drivers/clk/uniphier/clk-uniphier-core.c
index 726a10a..b6c02f5 100644
--- a/drivers/clk/uniphier/clk-uniphier-core.c
+++ b/drivers/clk/uniphier/clk-uniphier-core.c
@@ -27,6 +27,9 @@ static struct clk_hw *uniphier_clk_register(struct device *dev,
const struct uniphier_clk_data *data)
{
switch (data->type) {
+ case UNIPHIER_CLK_TYPE_CPUGEAR:
+ return uniphier_clk_register_cpugear(dev, regmap, data->name,
+ &data->cpugear);
case UNIPHIER_CLK_TYPE_FIXED_FACTOR:
return uniphier_clk_register_fixed_factor(dev, data->name,
&data->factor);
diff --git a/drivers/clk/uniphier/clk-uniphier-cpugear.c b/drivers/clk/uniphier/clk-uniphier-cpugear.c
new file mode 100644
index 0000000..9bff26e
--- /dev/null
+++ b/drivers/clk/uniphier/clk-uniphier-cpugear.c
@@ -0,0 +1,115 @@
+/*
+ * Copyright (C) 2016 Socionext Inc.
+ * Author: Masahiro Yamada <yamada.masahiro@socionext.com>
+ *
+ * This program 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 program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ */
+
+#include <linux/clk-provider.h>
+#include <linux/delay.h>
+#include <linux/device.h>
+#include <linux/regmap.h>
+
+#include "clk-uniphier.h"
+
+#define UNIPHIER_CLK_CPUGEAR_STAT 0 /* status */
+#define UNIPHIER_CLK_CPUGEAR_SET 4 /* set */
+#define UNIPHIER_CLK_CPUGEAR_UPD 8 /* update */
+#define UNIPHIER_CLK_CPUGEAR_UPD_BIT BIT(0)
+
+struct uniphier_clk_cpugear {
+ struct clk_hw hw;
+ struct regmap *regmap;
+ unsigned int regbase;
+ unsigned int mask;
+};
+
+#define to_uniphier_clk_cpugear(_hw) \
+ container_of(_hw, struct uniphier_clk_cpugear, hw)
+
+static int uniphier_clk_cpugear_set_parent(struct clk_hw *hw, u8 index)
+{
+ struct uniphier_clk_cpugear *gear = to_uniphier_clk_cpugear(hw);
+ int ret;
+ unsigned int val;
+
+ ret = regmap_write_bits(gear->regmap,
+ gear->regbase + UNIPHIER_CLK_CPUGEAR_SET,
+ gear->mask, index);
+ if (ret)
+ return ret;
+
+ ret = regmap_write_bits(gear->regmap,
+ gear->regbase + UNIPHIER_CLK_CPUGEAR_SET,
+ UNIPHIER_CLK_CPUGEAR_UPD_BIT,
+ UNIPHIER_CLK_CPUGEAR_UPD_BIT);
+ if (ret)
+ return ret;
+
+ return regmap_read_poll_timeout(gear->regmap,
+ gear->regbase + UNIPHIER_CLK_CPUGEAR_UPD,
+ val, !(val & UNIPHIER_CLK_CPUGEAR_UPD_BIT),
+ 0, 1);
+}
+
+static u8 uniphier_clk_cpugear_get_parent(struct clk_hw *hw)
+{
+ struct uniphier_clk_cpugear *gear = to_uniphier_clk_cpugear(hw);
+ int num_parents = clk_hw_get_num_parents(hw);
+ int ret;
+ unsigned int val;
+
+ ret = regmap_read(gear->regmap,
+ gear->regbase + UNIPHIER_CLK_CPUGEAR_STAT, &val);
+ if (ret)
+ return ret;
+
+ val &= gear->mask;
+
+ return val < num_parents ? val : -EINVAL;
+}
+
+static const struct clk_ops uniphier_clk_cpugear_ops = {
+ .determine_rate = __clk_mux_determine_rate,
+ .set_parent = uniphier_clk_cpugear_set_parent,
+ .get_parent = uniphier_clk_cpugear_get_parent,
+};
+
+struct clk_hw *uniphier_clk_register_cpugear(struct device *dev,
+ struct regmap *regmap,
+ const char *name,
+ const struct uniphier_clk_cpugear_data *data)
+{
+ struct uniphier_clk_cpugear *gear;
+ struct clk_init_data init;
+ int ret;
+
+ gear = devm_kzalloc(dev, sizeof(*gear), GFP_KERNEL);
+ if (!gear)
+ return ERR_PTR(-ENOMEM);
+
+ init.name = name;
+ init.ops = &uniphier_clk_cpugear_ops;
+ init.flags = CLK_SET_RATE_PARENT;
+ init.parent_names = data->parent_names;
+ init.num_parents = data->num_parents,
+
+ gear->regmap = regmap;
+ gear->regbase = data->regbase;
+ gear->mask = data->mask;
+ gear->hw.init = &init;
+
+ ret = devm_clk_hw_register(dev, &gear->hw);
+ if (ret)
+ return ERR_PTR(ret);
+
+ return &gear->hw;
+}
diff --git a/drivers/clk/uniphier/clk-uniphier.h b/drivers/clk/uniphier/clk-uniphier.h
index 4eb4f6d..62816f8 100644
--- a/drivers/clk/uniphier/clk-uniphier.h
+++ b/drivers/clk/uniphier/clk-uniphier.h
@@ -20,15 +20,24 @@ struct clk_hw;
struct device;
struct regmap;
-#define UNIPHIER_CLK_MUX_MAX_PARENTS 8
+#define UNIPHIER_CLK_CPUGEAR_MAX_PARENTS 16
+#define UNIPHIER_CLK_MUX_MAX_PARENTS 8
enum uniphier_clk_type {
+ UNIPHIER_CLK_TYPE_CPUGEAR,
UNIPHIER_CLK_TYPE_FIXED_FACTOR,
UNIPHIER_CLK_TYPE_FIXED_RATE,
UNIPHIER_CLK_TYPE_GATE,
UNIPHIER_CLK_TYPE_MUX,
};
+struct uniphier_clk_cpugear_data {
+ const char *parent_names[UNIPHIER_CLK_CPUGEAR_MAX_PARENTS];
+ unsigned int num_parents;
+ unsigned int regbase;
+ unsigned int mask;
+};
+
struct uniphier_clk_fixed_factor_data {
const char *parent_name;
unsigned int mult;
@@ -58,6 +67,7 @@ struct uniphier_clk_data {
enum uniphier_clk_type type;
int idx;
union {
+ struct uniphier_clk_cpugear_data cpugear;
struct uniphier_clk_fixed_factor_data factor;
struct uniphier_clk_fixed_rate_data rate;
struct uniphier_clk_gate_data gate;
@@ -90,7 +100,10 @@ struct uniphier_clk_data {
}, \
}
-
+struct clk_hw *uniphier_clk_register_cpugear(struct device *dev,
+ struct regmap *regmap,
+ const char *name,
+ const struct uniphier_clk_cpugear_data *data);
struct clk_hw *uniphier_clk_register_fixed_factor(struct device *dev,
const char *name,
const struct uniphier_clk_fixed_factor_data *data);
--
2.7.4
^ permalink raw reply related
* [PATCH v2 3/3] clk: uniphier: add cpufreq data for LD11, LD20 SoCs
From: Masahiro Yamada @ 2016-11-24 5:57 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1479967061-25975-1-git-send-email-yamada.masahiro@socionext.com>
Add more data to 64bit SoCs for the cpufreq support.
Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
---
Changes in v2:
- Drop clock data of 32 bit SoCs. Add 64 bit SoC data for now.
drivers/clk/uniphier/clk-uniphier-sys.c | 32 ++++++++++++++++++++++++++++++++
drivers/clk/uniphier/clk-uniphier.h | 30 +++++++++++++++++++++++++++++-
2 files changed, 61 insertions(+), 1 deletion(-)
diff --git a/drivers/clk/uniphier/clk-uniphier-sys.c b/drivers/clk/uniphier/clk-uniphier-sys.c
index 5d02999..d049316 100644
--- a/drivers/clk/uniphier/clk-uniphier-sys.c
+++ b/drivers/clk/uniphier/clk-uniphier-sys.c
@@ -125,16 +125,35 @@ const struct uniphier_clk_data uniphier_pxs2_sys_clk_data[] = {
};
const struct uniphier_clk_data uniphier_ld11_sys_clk_data[] = {
+ UNIPHIER_CLK_FACTOR("cpll", -1, "ref", 392, 5), /* 1960 MHz */
+ UNIPHIER_CLK_FACTOR("mpll", -1, "ref", 64, 1), /* 1600 MHz */
UNIPHIER_CLK_FACTOR("spll", -1, "ref", 80, 1), /* 2000 MHz */
+ UNIPHIER_CLK_FACTOR("vspll", -1, "ref", 80, 1), /* 2000 MHz */
UNIPHIER_CLK_FACTOR("uart", 0, "spll", 1, 34),
UNIPHIER_CLK_FACTOR("i2c", 1, "spll", 1, 40),
UNIPHIER_LD11_SYS_CLK_STDMAC(8), /* HSC, MIO */
UNIPHIER_CLK_FACTOR("usb2", -1, "ref", 24, 25),
+ /* CPU gears */
+ UNIPHIER_CLK_DIV4("cpll", 2, 3, 4, 8),
+ UNIPHIER_CLK_DIV4("mpll", 2, 3, 4, 8),
+ UNIPHIER_CLK_DIV3("spll", 3, 4, 8),
+ /* Note: both gear1 and gear4 are spll/4. This is not a bug. */
+ UNIPHIER_CLK_CPUGEAR("cpu-ca53", 33, 0x8080, 0xf, 8,
+ "cpll/2", "spll/4", "cpll/3", "spll/3",
+ "spll/4", "spll/8", "cpll/4", "cpll/8"),
+ UNIPHIER_CLK_CPUGEAR("cpu-ipp", 34, 0x8100, 0xf, 8,
+ "mpll/2", "spll/4", "mpll/3", "spll/3",
+ "spll/4", "spll/8", "mpll/4", "mpll/8"),
{ /* sentinel */ }
};
const struct uniphier_clk_data uniphier_ld20_sys_clk_data[] = {
+ UNIPHIER_CLK_FACTOR("cpll", -1, "ref", 88, 1), /* ARM: 2200 MHz */
+ UNIPHIER_CLK_FACTOR("gppll", -1, "ref", 52, 1), /* Mali: 1300 MHz */
+ UNIPHIER_CLK_FACTOR("mpll", -1, "ref", 64, 1), /* Codec: 1600 MHz */
UNIPHIER_CLK_FACTOR("spll", -1, "ref", 80, 1), /* 2000 MHz */
+ UNIPHIER_CLK_FACTOR("s2pll", -1, "ref", 88, 1), /* IPP: 2200 MHz */
+ UNIPHIER_CLK_FACTOR("vppll", -1, "ref", 504, 5), /* 2520 MHz */
UNIPHIER_CLK_FACTOR("uart", 0, "spll", 1, 34),
UNIPHIER_CLK_FACTOR("i2c", 1, "spll", 1, 40),
UNIPHIER_LD20_SYS_CLK_SD,
@@ -147,5 +166,18 @@ const struct uniphier_clk_data uniphier_ld20_sys_clk_data[] = {
UNIPHIER_CLK_GATE("usb30", 14, NULL, 0x210c, 14),
UNIPHIER_CLK_GATE("usb30-phy0", 16, NULL, 0x210c, 12),
UNIPHIER_CLK_GATE("usb30-phy1", 17, NULL, 0x210c, 13),
+ /* CPU gears */
+ UNIPHIER_CLK_DIV4("cpll", 2, 3, 4, 8),
+ UNIPHIER_CLK_DIV4("spll", 2, 3, 4, 8),
+ UNIPHIER_CLK_DIV4("s2pll", 2, 3, 4, 8),
+ UNIPHIER_CLK_CPUGEAR("cpu-ca72", 32, 0x8000, 0xf, 8,
+ "cpll/2", "spll/2", "cpll/3", "spll/3",
+ "spll/4", "spll/8", "cpll/4", "cpll/8"),
+ UNIPHIER_CLK_CPUGEAR("cpu-ca53", 33, 0x8080, 0xf, 8,
+ "cpll/2", "spll/2", "cpll/3", "spll/3",
+ "spll/4", "spll/8", "cpll/4", "cpll/8"),
+ UNIPHIER_CLK_CPUGEAR("cpu-ipp", 34, 0x8100, 0xf, 8,
+ "s2pll/2", "spll/2", "s2pll/3", "spll/3",
+ "spll/4", "spll/8", "s2pll/4", "s2pll/8"),
{ /* sentinel */ }
};
diff --git a/drivers/clk/uniphier/clk-uniphier.h b/drivers/clk/uniphier/clk-uniphier.h
index 62816f8..81d7e5c 100644
--- a/drivers/clk/uniphier/clk-uniphier.h
+++ b/drivers/clk/uniphier/clk-uniphier.h
@@ -75,6 +75,20 @@ struct uniphier_clk_data {
};
};
+#define UNIPHIER_CLK_CPUGEAR(_name, _idx, _regbase, _mask, \
+ _num_parents, ...) \
+ { \
+ .name = (_name), \
+ .type = UNIPHIER_CLK_TYPE_CPUGEAR, \
+ .idx = (_idx), \
+ .cpugear = { \
+ .parent_names = { __VA_ARGS__ }, \
+ .num_parents = (_num_parents), \
+ .regbase = (_regbase), \
+ .mask = (_mask) \
+ }, \
+ }
+
#define UNIPHIER_CLK_FACTOR(_name, _idx, _parent, _mult, _div) \
{ \
.name = (_name), \
@@ -87,7 +101,6 @@ struct uniphier_clk_data {
}, \
}
-
#define UNIPHIER_CLK_GATE(_name, _idx, _parent, _reg, _bit) \
{ \
.name = (_name), \
@@ -100,6 +113,21 @@ struct uniphier_clk_data {
}, \
}
+#define UNIPHIER_CLK_DIV(parent, div) \
+ UNIPHIER_CLK_FACTOR(parent "/" #div, -1, parent, 1, div)
+
+#define UNIPHIER_CLK_DIV2(parent, div0, div1) \
+ UNIPHIER_CLK_DIV(parent, div0), \
+ UNIPHIER_CLK_DIV(parent, div1)
+
+#define UNIPHIER_CLK_DIV3(parent, div0, div1, div2) \
+ UNIPHIER_CLK_DIV2(parent, div0, div1), \
+ UNIPHIER_CLK_DIV(parent, div2)
+
+#define UNIPHIER_CLK_DIV4(parent, div0, div1, div2, div3) \
+ UNIPHIER_CLK_DIV2(parent, div0, div1), \
+ UNIPHIER_CLK_DIV2(parent, div2, div3)
+
struct clk_hw *uniphier_clk_register_cpugear(struct device *dev,
struct regmap *regmap,
const char *name,
--
2.7.4
^ permalink raw reply related
* [PATCH v4 0/2] da8xx: fix section mismatch in new drivers
From: Sekhar Nori @ 2016-11-24 6:01 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1479908400-10136-1-git-send-email-bgolaszewski@baylibre.com>
On Wednesday 23 November 2016 07:09 PM, Bartosz Golaszewski wrote:
> Sekhar noticed there's a section mismatch in the da8xx-mstpri and
> da8xx-ddrctl drivers. This is caused by calling
> of_flat_dt_get_machine_name() which has an __init annotation.
>
> This series makes the drivers drop the call and not print the
> machine name in the error message.
Applied both. Thanks!
Regards,
Sekhar
^ permalink raw reply
* ath9k ARMv7 OOPS in v4.8.6, v4.2.8
From: miaoqing at codeaurora.org @ 2016-11-24 6:06 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <aaba8b1e30dd4c22be52e50befb202b2@aptaiexm02f.ap.qualcomm.com>
>> Okay, so i was 0, so running UP probably isn't going to help. r7 is
>> also spec_priv->rfs_chan_spec_scan.
>>
>> So, I think the question is... how is this NULL - and has it always
>> been NULL...
>
> The problem appears to be that ath_cmn_process_fft() isn't called that
> often. When it is, it crashes in ath_cmn_is_fft_buf_full() because
> spec_priv->rfs_chan_spec_scan is NULL when ATH9K_DEBUGFS=n. :-(
>
> I'm running with ATH9K_DEBUGFS=y now. If it goes a couple of days
> without crashing, I'll gin up a patch.
>
A similar patch was applied to ath-next branch:
https://patchwork.kernel.org/patch/9431163/.
--
Miaoqing
^ permalink raw reply
* [GIT PULL 0/3] ARM: exynos: Second round for v4.10
From: Krzysztof Kozlowski @ 2016-11-24 6:08 UTC (permalink / raw)
To: linux-arm-kernel
Hi,
Second, probably last round of patches for v4.10.
Best regards,
Krzysztof
^ permalink raw reply
* [GIT PULL 1/3] ARM: exynos: Soc/mach for v4.10
From: Krzysztof Kozlowski @ 2016-11-24 6:08 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1479967709-6619-1-git-send-email-krzk@kernel.org>
Hi,
This contains previous dts branch because SCU node in dts is needed
prior to removing it from mach code.
Below you will find full pull request and one stripped from dependency.
Best regards,
Krzysztof
The following changes since commit 1001354ca34179f3db924eb66672442a173147dc:
Linux 4.9-rc1 (2016-10-15 12:17:50 -0700)
are available in the git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/krzk/linux.git tags/samsung-soc-4.10
for you to fetch changes up to c689de56c0a7c8387ea00509f94fa483ae61d979:
ARM: Drop fixed 200 Hz timer requirement from Samsung platforms (2016-11-23 19:34:55 +0200)
----------------------------------------------------------------
Samsung mach/soc update for v4.10:
1. Use SCU mapping from Device Tree instead of statically mapped one.
2. Drop fixed requirement for HZ=200 on Samsung platforms.
----------------------------------------------------------------
Javier Martinez Canillas (1):
ARM: dts: exynos: Document eMMC/SD/SDIO devices in Snow and Peach boards
Krzysztof Kozlowski (3):
ARM: dts: exynos: Remove exynos4415.dtsi
Merge tag 'samsung-dt-4.10' into next/soc
ARM: Drop fixed 200 Hz timer requirement from Samsung platforms
Pankaj Dubey (4):
ARM: EXYNOS: Remove smp_init_cpus hook from platsmp.c
ARM: dts: exynos: Add SCU device node to exynos4.dtsi
ARM: EXYNOS: Remove static mapping of SCU SFR
ARM: EXYNOS: Remove unused soc_is_exynos{4,5}
Randy Li (2):
ARM: dts: exynos: Add TOPEET itop core board SCP package version
ARM: dts: exynos: Add TOPEET itop elite based board
Sylwester Nawrocki (3):
ARM: dts: exynos: Remove "simple-bus" compatible from fimc-is node
ARM: dts: exynos: Add entries for sound support on Odroid-XU board
ARM: S3C24XX: Add DMA slave maps for remaining s3c24xx SoCs
.../bindings/arm/samsung/samsung-boards.txt | 3 +
arch/arm/Kconfig | 3 +-
arch/arm/boot/dts/Makefile | 1 +
arch/arm/boot/dts/exynos4.dtsi | 5 +
arch/arm/boot/dts/exynos4412-itop-elite.dts | 240 ++++++++
arch/arm/boot/dts/exynos4412-itop-scp-core.dtsi | 501 ++++++++++++++++
arch/arm/boot/dts/exynos4415-pinctrl.dtsi | 575 ------------------
arch/arm/boot/dts/exynos4415.dtsi | 650 ---------------------
arch/arm/boot/dts/exynos4x12.dtsi | 2 +-
arch/arm/boot/dts/exynos5250-snow-common.dtsi | 4 +
arch/arm/boot/dts/exynos5410-odroidxu.dts | 69 +++
arch/arm/boot/dts/exynos5410-pinctrl.dtsi | 9 +
arch/arm/boot/dts/exynos5410.dtsi | 59 ++
arch/arm/boot/dts/exynos5420-peach-pit.dts | 3 +
arch/arm/boot/dts/exynos5800-peach-pi.dts | 3 +
arch/arm/mach-exynos/common.h | 6 +-
arch/arm/mach-exynos/exynos.c | 22 -
arch/arm/mach-exynos/include/mach/map.h | 2 -
arch/arm/mach-exynos/platsmp.c | 65 +--
arch/arm/mach-exynos/pm.c | 4 +-
arch/arm/mach-exynos/suspend.c | 4 +-
arch/arm/mach-s3c24xx/common.c | 76 +++
arch/arm/plat-samsung/include/plat/map-s5p.h | 4 -
23 files changed, 1004 insertions(+), 1306 deletions(-)
create mode 100644 arch/arm/boot/dts/exynos4412-itop-elite.dts
create mode 100644 arch/arm/boot/dts/exynos4412-itop-scp-core.dtsi
delete mode 100644 arch/arm/boot/dts/exynos4415-pinctrl.dtsi
delete mode 100644 arch/arm/boot/dts/exynos4415.dtsi
Pull request details for Soc only:
##################################
----------------------------------------------------------------
Samsung mach/soc update for v4.10:
1. Use SCU mapping from Device Tree instead of statically mapped one.
2. Drop fixed requirement for HZ=200 on Samsung platforms.
----------------------------------------------------------------
Krzysztof Kozlowski (1):
ARM: Drop fixed 200 Hz timer requirement from Samsung platforms
Pankaj Dubey (3):
ARM: EXYNOS: Remove static mapping of SCU SFR
ARM: EXYNOS: Remove unused soc_is_exynos{4,5}
ARM: EXYNOS: Remove smp_init_cpus hook from platsmp.c
Sylwester Nawrocki (1):
ARM: S3C24XX: Add DMA slave maps for remaining s3c24xx SoCs
^ permalink raw reply
* [GIT PULL 2/3] ARM: dts: exynos: DT for v4.10, second round
From: Krzysztof Kozlowski @ 2016-11-24 6:08 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1479967709-6619-1-git-send-email-krzk@kernel.org>
Hi,
On top of previous pull/tag.
Possible trivial conflict:
--- a/arch/arm/boot/dts/exynos5440.dtsi
+++ b/arch/arm/boot/dts/exynos5440.dtsi
@@@ -197,10 -188,10 +197,10 @@@
};
gmac: ethernet at 00230000 {
- compatible = "snps,dwmac-3.70a";
+ compatible = "snps,dwmac-3.70a", "snps,dwmac";
reg = <0x00230000 0x8000>;
interrupt-parent = <&gic>;
- interrupts = <0 31 4>;
+ interrupts = <GIC_SPI 31 4>;
interrupt-names = "macirq";
phy-mode = "sgmii";
clocks = <&clock CLK_GMAC0>;
Best regards,
Krzysztof
The following changes since commit 05a3589f46f913fbe91704f12fdca46a0eb0a27b:
ARM: dts: exynos: Add SCU device node to exynos4.dtsi (2016-11-05 17:39:50 +0200)
are available in the git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/krzk/linux.git tags/samsung-dt-4.10-2
for you to fetch changes up to 79700041b37f0aca5da3ea27858ad6c42f99a474:
ARM: dts: exynos: Remove the cd-gpios property for eMMC of Odroid XU3/4 (2016-11-23 19:17:11 +0200)
----------------------------------------------------------------
Samsung DeviceTree second update for v4.10:
1. Cleanups in MSHC nodes.
2. Enable ADC on Odroid boards.
3. Fix interrupt flags on recently added DMA sound nodes in Exynos5410.
----------------------------------------------------------------
Jaehoon Chung (2):
ARM: dts: exynos: Replace "clock-freq-min-max" with "max-frequency"
ARM: dts: exynos: Remove the cd-gpios property for eMMC of Odroid XU3/4
Krzysztof Kozlowski (1):
ARM: dts: exynos: Fix invalid GIC interrupt flags in audio block of Exynos5410
Markus Reichl (1):
ARM: dts: exynos: Add ADCs on 4412 and 5422 based odroid boards.
Niklas Cassel (1):
ARM: dts: exynos: Specify snps, dwmac in compatible string for gmac
arch/arm/boot/dts/exynos3250-artik5-eval.dts | 2 +-
arch/arm/boot/dts/exynos3250-artik5.dtsi | 2 +-
arch/arm/boot/dts/exynos3250-monk.dts | 2 +-
arch/arm/boot/dts/exynos3250-rinato.dts | 2 +-
arch/arm/boot/dts/exynos4412-odroidx.dts | 5 +++++
arch/arm/boot/dts/exynos5410.dtsi | 4 ++--
arch/arm/boot/dts/exynos5422-odroidxu3-common.dtsi | 12 +++++++++++-
arch/arm/boot/dts/exynos5440.dtsi | 2 +-
8 files changed, 23 insertions(+), 8 deletions(-)
^ permalink raw reply
* [GIT PULL 3/3] arm64: dts: exynos: DT for v4.10, second round
From: Krzysztof Kozlowski @ 2016-11-24 6:08 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1479967709-6619-1-git-send-email-krzk@kernel.org>
Hi,
On top of previous pull/tag.
Best regards,
Krzysztof
The following changes since commit 8ac46fc57df82efbc19194dddd335b6c7a960c31:
arm64: dts: exynos: Add dts file for Exynos5433-based TM2E board (2016-11-03 22:19:57 +0200)
are available in the git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/krzk/linux.git tags/samsung-dt64-4.10-2
for you to fetch changes up to 2a4c744fcb1549023478e4b9e724d268d8202158:
arm64: dts: exynos: Enable HS400 mode for eMMC for TM2 (2016-11-23 19:27:56 +0200)
----------------------------------------------------------------
Samsung DeviceTree arm64 second update for v4.10:
1. Add Performance Monitor Unit to Exynos7.
2. Add MFC, JPEG and Gscaler to Exynos5433 based TM2 board.
3. Cleanups and fixes for recently added TM2 and TM2E boards.
----------------------------------------------------------------
Alim Akhtar (1):
arm64: dts: Add ARM PMU node for exynos7
Jaehoon Chung (2):
arm64: dts: exynos: Add the mshc_2 node for supporting T-Flash
arm64: dts: exynos: Enable HS400 mode for eMMC for TM2
Marek Szyprowski (8):
arm64: dts: exynos: Fix IRQ type flags for Exynos5433 SoC
arm64: dts: exynos: Fix FSYS CMU parent clocks in Exynos5433 SoC
arm64: dts: exynos: Add missing parent clocks to audio block in Exynos5433 SoC
arm64: dts: exynos: Move FSYS CMU configuration from Exynos5433 dtsi to TM2 dts
arm64: dts: exynos: TM2 - remove unused UART3 and set clocks directly on CMU
arm64: dts: exynos: TM2 - add support for GScaler devices
arm64: dts: exynos: TM2 - add support for JPEG codec device
arm64: dts: exynos: TM2 - add support for MFC video codec device
Sylwester Nawrocki (1):
arm64: dts: exynos: Assign parent clock of the clkout clock for TM2 board
arch/arm64/boot/dts/exynos/exynos5433-pinctrl.dtsi | 22 +-
arch/arm64/boot/dts/exynos/exynos5433-tm2.dts | 85 +++++-
arch/arm64/boot/dts/exynos/exynos5433.dtsi | 286 ++++++++++++++-------
arch/arm64/boot/dts/exynos/exynos7.dtsi | 18 +-
4 files changed, 306 insertions(+), 105 deletions(-)
^ permalink raw reply
* Re: [PATCH v1 & v6 1/2] PM/devfreq: add suspend frequency support
From: MyungJoo Ham @ 2016-11-24 6:14 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CGME20161124061416epcms1p44a0152bca14312f1229cab835ea0297f@epcms1p4>
On Thu, Nov 24, 2016 at 11:18 AM, hl <hl@rock-chips.com> wrote:
> Hi MyungJoo Ham,
[]
>>
>> We still need to sync the all status even i call target() in
>> devfreq_suspend/resume_device
>> directly, so still need update_devfreq() other setp except
>> devfreq->governor->get_target_freq(devfreq, &freq);
>
> And i think it better to be governor behaviors, for userspace they may not
> want to change
> the suspend frequency like other governor, the frequency should decide by
> the user, if they
> want this function, they should like other governor to rigister a
> devfreq_monitor_suspend().
> What do you think about my rev6 patch?
If I understand the intention correctly, this is for the stability of
the device due to the behavior or bootloader/SoC-initializer, which
has nothing to do with governors.
Even if users are using userspace, as long as they set the custom
frequencies lower than the default, they have the possibility of
being unstable as ondemand is going to have.
To reuse the update_devfreq() code, you may do something like:
static int _update_freq(struct devfreq *devfreq, bool is_suspending)
{
/* original contents of update_freq with if statement with is_suspending wrapping get_target_freq */
}
int update_freq(struct devfreq *devfreq)
{
return _update_freq(devfreq, false);
}
There should be other good non-invasive methods that are not governoe-specific as well.
Cheers,
MyungJoo
^ permalink raw reply
* [PATCH 1/2] ARM: omap2: am437x: rollback to use omap3_gptimer_timer_init()
From: Keerthy @ 2016-11-24 6:19 UTC (permalink / raw)
To: linux-arm-kernel
From: Grygorii Strashko <grygorii.strashko@ti.com>
The commit 55ee7017ee31 ("arm: omap2: board-generic: use
omap4_local_timer_init for AM437x") unintentionally changes the
clocksource devices for AM437x from OMAP GP Timer to SyncTimer32K.
Unfortunately, the SyncTimer32K is starving from frequency deviation
as mentioned in commit 5b5c01359152 ("ARM: OMAP2+: AM43x: Use gptimer
as clocksource") and, as reported by Franklin [1], even its monotonic
nature is under question (most probably there is a HW issue, but it's
still under investigation).
Taking into account above facts It's reasonable to rollback to the use
of omap3_gptimer_timer_init().
[1] http://www.spinics.net/lists/linux-omap/msg127425.html
Reported-by: Cooper Jr., Franklin <fcooper@ti.com>
Signed-off-by: Grygorii Strashko <grygorii.strashko@ti.com>
Signed-off-by: Lokesh Vutla <lokeshvutla@ti.com>
Signed-off-by: Keerthy <j-keerthy@ti.com>
---
arch/arm/mach-omap2/board-generic.c | 2 +-
arch/arm/mach-omap2/timer.c | 9 +++++----
2 files changed, 6 insertions(+), 5 deletions(-)
diff --git a/arch/arm/mach-omap2/board-generic.c b/arch/arm/mach-omap2/board-generic.c
index 36d9943..dc9e34e 100644
--- a/arch/arm/mach-omap2/board-generic.c
+++ b/arch/arm/mach-omap2/board-generic.c
@@ -304,7 +304,7 @@ static void __init rx51_reserve(void)
.init_late = am43xx_init_late,
.init_irq = omap_gic_of_init,
.init_machine = omap_generic_init,
- .init_time = omap4_local_timer_init,
+ .init_time = omap3_gptimer_timer_init,
.dt_compat = am43_boards_compat,
.restart = omap44xx_restart,
MACHINE_END
diff --git a/arch/arm/mach-omap2/timer.c b/arch/arm/mach-omap2/timer.c
index 5e2e221..b2f2448 100644
--- a/arch/arm/mach-omap2/timer.c
+++ b/arch/arm/mach-omap2/timer.c
@@ -510,18 +510,19 @@ void __init omap3_secure_sync32k_timer_init(void)
}
#endif /* CONFIG_ARCH_OMAP3 */
-#if defined(CONFIG_ARCH_OMAP3) || defined(CONFIG_SOC_AM33XX)
+#if defined(CONFIG_ARCH_OMAP3) || defined(CONFIG_SOC_AM33XX) || \
+ defined(CONFIG_SOC_AM43XX)
void __init omap3_gptimer_timer_init(void)
{
__omap_sync32k_timer_init(2, "timer_sys_ck", NULL,
1, "timer_sys_ck", "ti,timer-alwon", true);
-
- clocksource_probe();
+ if (of_have_populated_dt())
+ clocksource_probe();
}
#endif
#if defined(CONFIG_ARCH_OMAP4) || defined(CONFIG_SOC_OMAP5) || \
- defined(CONFIG_SOC_DRA7XX) || defined(CONFIG_SOC_AM43XX)
+ defined(CONFIG_SOC_DRA7XX)
static void __init omap4_sync32k_timer_init(void)
{
__omap_sync32k_timer_init(1, "timer_32k_ck", "ti,timer-alwon",
--
1.9.1
^ permalink raw reply related
* [PATCH 2/2] ARM: omap: timers: reduce rating of gp_timer clocksource
From: Keerthy @ 2016-11-24 6:19 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1479968355-18860-1-git-send-email-j-keerthy@ti.com>
From: Grygorii Strashko <grygorii.strashko@ti.com>
Now ARM Global timer (rating 300) will not be selected as clocksource,
because it's initialized after OMAP GP Timer (rating 300) and
Timekeeping core will not allow to replace clocksource with new one if
both of them have the same rating.
Reduce rating of OMAP GP Timer (300->290) when it's used as
clocksource device - this will allow to select ARM Global timer (300)
as clocksource when enabled.
Signed-off-by: Grygorii Strashko <grygorii.strashko@ti.com>
Signed-off-by: Dave Gerlach <d-gerlach@ti.com>
Signed-off-by: Keerthy <j-keerthy@ti.com>
---
arch/arm/mach-omap2/timer.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/arm/mach-omap2/timer.c b/arch/arm/mach-omap2/timer.c
index b2f2448..a0dbb0b 100644
--- a/arch/arm/mach-omap2/timer.c
+++ b/arch/arm/mach-omap2/timer.c
@@ -376,7 +376,7 @@ static cycle_t clocksource_read_cycles(struct clocksource *cs)
}
static struct clocksource clocksource_gpt = {
- .rating = 300,
+ .rating = 290,
.read = clocksource_read_cycles,
.mask = CLOCKSOURCE_MASK(32),
.flags = CLOCK_SOURCE_IS_CONTINUOUS,
--
1.9.1
^ 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