* [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
* [PATCH 1/4] serial: core: Add LED trigger support
From: Sascha Hauer @ 2016-11-24 6:41 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161123171302.GD19856@linaro.org>
On Wed, Nov 23, 2016 at 10:13:02AM -0700, Mathieu Poirier wrote:
> On Wed, Nov 23, 2016 at 11:01:03AM +0100, Sascha Hauer wrote:
> > With this patch the serial core provides LED triggers for RX and TX.
> >
> > As the serial core layer does not know when the hardware actually sends
> > or receives characters, this needs help from the UART drivers. The
> > LED triggers are registered in uart_add_led_triggers() called from
> > the UART drivers which want to support LED triggers. All the driver
> > has to do then is to call uart_led_trigger_[tx|rx] to indicate
> > activite.
>
> Hello Sascha,
>
> >
> > Signed-off-by: Sascha Hauer <s.hauer@pengutronix.de>
> > ---
> > drivers/tty/serial/serial_core.c | 73 ++++++++++++++++++++++++++++++++++++++++
> > include/linux/serial_core.h | 10 ++++++
> > 2 files changed, 83 insertions(+)
> >
> > diff --git a/drivers/tty/serial/serial_core.c b/drivers/tty/serial/serial_core.c
> > index f2303f3..3e8afb7 100644
> > --- a/drivers/tty/serial/serial_core.c
> > +++ b/drivers/tty/serial/serial_core.c
> > @@ -34,6 +34,7 @@
> > #include <linux/serial_core.h>
> > #include <linux/delay.h>
> > #include <linux/mutex.h>
> > +#include <linux/leds.h>
> >
> > #include <asm/irq.h>
> > #include <asm/uaccess.h>
> > @@ -2703,6 +2704,77 @@ static const struct attribute_group tty_dev_attr_group = {
> > .attrs = tty_dev_attrs,
> > };
> >
> > +void uart_led_trigger_tx(struct uart_port *uport)
> > +{
> > + unsigned long delay = 50;
> > +
> > + led_trigger_blink_oneshot(uport->led_trigger_tx, &delay, &delay, 0);
> > +}
> > +
> > +void uart_led_trigger_rx(struct uart_port *uport)
> > +{
> > + unsigned long delay = 50;
> > +
> > + led_trigger_blink_oneshot(uport->led_trigger_rx, &delay, &delay, 0);
>
> For both rx/tx the core constrains the delay_on/off along with the inversion.
> Instead of adding the led_trigger_rx/tx and led_trigger_rx/tx_name to the
> struct uart_port, wouldn't it be better to add a new struct led_trigger that
> would encapsulate those along wit the on/off delay and the inversion?
>
> That way those values could be communicated to the core at registration time
> instead of hard-coding things.
Not sure this goes into the right direction. Looking at the other
callers of led_trigger_blink_oneshot() most of them use an arbitrary
blink time of 30 or 50ms and the users seem to be happy with it. There
doesn't seem to be the desire to make that value configurable. If we
want to make it configurable, it's probably better to move the option
to the led device rather than putting the burden on every user of the
led triggers.
I don't think the inversion flag is meant for being configurable. It's
rather used for the default state of the LED. The CAN layer for example
turns the LED on when the interface is up and then blinks (turns off and
on again) on activity. For this it uses the inversion flag.
>
> > +}
> > +
> > +/**
> > + * uart_add_led_triggers - register LED triggers for a UART
> > + * @drv: pointer to the uart low level driver structure for this port
> > + * @uport: uart port structure to use for this port.
> > + *
> > + * Called by the driver to register LED triggers for a UART. It's the
> > + * drivers responsibility to call uart_led_trigger_rx/tx on received
> > + * and transmitted chars then.
> > + */
> > +int uart_add_led_triggers(struct uart_driver *drv, struct uart_port *uport)
> > +{
> > + int ret;
> > +
> > + if (!IS_ENABLED(CONFIG_LEDS_TRIGGERS))
> > + return 0;
>
> Since this is a public interface, checking for valid led_trigger_tx/rx before
> moving on with the rest of the initialisation is probably a good idea.
What do you mean? Should we return an error when CONFIG_LEDS_TRIGGERS is
disabled?
Sascha
--
Pengutronix e.K. | |
Industrial Linux Solutions | http://www.pengutronix.de/ |
Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0 |
Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917-5555 |
^ permalink raw reply
* [PATCH 0/2] ARM: dts: sun6i: Disable display pipeline by default
From: Chen-Yu Tsai @ 2016-11-24 6:43 UTC (permalink / raw)
To: linux-arm-kernel
Hi,
While we now support the internal display pipeline found on sun6i, it
is possible that we are unable to enable the display for some boards,
due to a lack of drivers for the panels or bridges found on them. If
the display pipeline is enabled, the driver will try to enable, and
possibly screw up the simple framebuffer U-boot had configured.
This series disables the display pipeline by default, and re-enables
it for the A31 Hummingbird, which already had its display pipeline
enabled.
The series can go in after 4.10-rc1, as a fix, but should not be delayed
till the next release.
Regards
ChenYu
Chen-Yu Tsai (2):
ARM: dts: sun6i: Disable display pipeline by default
ARM: dts: sun6i: hummingbird: Enable display engine again
arch/arm/boot/dts/sun6i-a31-hummingbird.dts | 4 ++++
arch/arm/boot/dts/sun6i-a31.dtsi | 1 +
2 files changed, 5 insertions(+)
--
2.10.2
^ permalink raw reply
* [PATCH 1/2] ARM: dts: sun6i: Disable display pipeline by default
From: Chen-Yu Tsai @ 2016-11-24 6:43 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161124064339.12615-1-wens@csie.org>
While we now support the internal display pipeline found on sun6i, it
is possible that we are unable to enable the display for some boards,
due to a lack of drivers for the panels or bridges found on them. If
the display pipeline is enabled, the driver will try to enable, and
possibly screw up the simple framebuffer U-boot had configured.
Disable the display pipeline by default.
Fixes: 6d0e5b70be13 ("ARM: dts: sun6i: Add device nodes for first
display pipeline")
Signed-off-by: Chen-Yu Tsai <wens@csie.org>
---
arch/arm/boot/dts/sun6i-a31.dtsi | 1 +
1 file changed, 1 insertion(+)
diff --git a/arch/arm/boot/dts/sun6i-a31.dtsi b/arch/arm/boot/dts/sun6i-a31.dtsi
index 20a0331ddfb5..4662d3344cd2 100644
--- a/arch/arm/boot/dts/sun6i-a31.dtsi
+++ b/arch/arm/boot/dts/sun6i-a31.dtsi
@@ -234,6 +234,7 @@
de: display-engine {
compatible = "allwinner,sun6i-a31-display-engine";
allwinner,pipelines = <&fe0>;
+ status = "disabled";
};
soc at 01c00000 {
--
2.10.2
^ permalink raw reply related
* [PATCH 2/2] ARM: dts: sun6i: hummingbird: Enable display engine again
From: Chen-Yu Tsai @ 2016-11-24 6:43 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161124064339.12615-1-wens@csie.org>
Now that we disable the display engine by default, we need to re-enable
it for the Hummingbird A31, which already had its display pipeline
enabled.
Signed-off-by: Chen-Yu Tsai <wens@csie.org>
---
arch/arm/boot/dts/sun6i-a31-hummingbird.dts | 4 ++++
1 file changed, 4 insertions(+)
diff --git a/arch/arm/boot/dts/sun6i-a31-hummingbird.dts b/arch/arm/boot/dts/sun6i-a31-hummingbird.dts
index b168d6df2b30..83643bbd51dc 100644
--- a/arch/arm/boot/dts/sun6i-a31-hummingbird.dts
+++ b/arch/arm/boot/dts/sun6i-a31-hummingbird.dts
@@ -140,6 +140,10 @@
cpu-supply = <®_dcdc3>;
};
+&de {
+ status = "okay";
+};
+
&ehci0 {
status = "okay";
};
--
2.10.2
^ permalink raw reply related
* [GIT PULL] Qualcomm Driver Updates for v4.10 - Part 2
From: Andy Gross @ 2016-11-24 7:05 UTC (permalink / raw)
To: linux-arm-kernel
Hi Olof, Kevin, and Arnd,
Please consider taking this additional set of updates for 4.10. These
apply on top of the previous tagged set of changes.
The following changes since commit e1ae0a7ee8849e12050933723e433a3d3ee26f7e:
Merge tag 'qcom-drivers-for-4.10' into drivers-for-4.10-2 (2016-11-23 11:01:54 -0600)
are available in the git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/agross/linux.git tags/qcom-drivers-for-4.10-2
for you to fetch changes up to ed19b86e817c5f30d557042f2e8ab68dc93940d4:
firmware: qcom: scm: Return PTR_ERR when devm_clk_get fails (2016-11-23 11:03:00 -0600)
----------------------------------------------------------------
Qualcomm ARM Based Driver Updates for v4.10 - Part 2
* Fixup QCOM SCM to support MSM8996
----------------------------------------------------------------
spjoshi at codeaurora.org (3):
dt-bindings: firmware: scm: Add MSM8996 DT bindings
firmware: qcom: scm: Remove core, iface and bus clocks dependency
firmware: qcom: scm: Return PTR_ERR when devm_clk_get fails
.../devicetree/bindings/firmware/qcom,scm.txt | 2 +
drivers/firmware/qcom_scm.c | 49 ++++++++++++++++------
2 files changed, 39 insertions(+), 12 deletions(-)
^ permalink raw reply
* [GIT PULL] Qualcomm ARM64 DT Updates for v4.10 - Part 2
From: Andy Gross @ 2016-11-24 7:05 UTC (permalink / raw)
To: linux-arm-kernel
Hi Olof, Kevin, and Arnd,
Please consider taking this additional set of updates for 4.10. These
apply on top of the previous tagged set of changes.
The following changes since commit 58432d74c9a7233bcfb23ef1108308dd17980e44:
Merge tag 'qcom-arm64-for-4.10' into arm64-for-4.10-2 (2016-11-23 11:10:57 -0600)
are available in the git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/agross/linux.git tags/qcom-arm64-for-4.10-2
for you to fetch changes up to c987775aa4af1034186ba17f67c21636451dc6d4:
arm64: dts: qcom: msm8916: Add ddr support to sdhc1 (2016-11-24 00:33:26 -0600)
----------------------------------------------------------------
Qualcomm ARM64 Updates for v4.10 - Part 2
* Add SDHC xo clk and 1.8V DDR support
----------------------------------------------------------------
Ritesh Harjani (2):
ARM: dts: Add xo to sdhc clock node on qcom platforms
arm64: dts: qcom: msm8916: Add ddr support to sdhc1
arch/arm64/boot/dts/qcom/msm8916.dtsi | 11 +++++++----
arch/arm64/boot/dts/qcom/msm8996.dtsi | 9 +++++----
2 files changed, 12 insertions(+), 8 deletions(-)
^ permalink raw reply
* [GIT PULL] Qualcomm Device Tree Changes for v4.10 - Part 2
From: Andy Gross @ 2016-11-24 7:05 UTC (permalink / raw)
To: linux-arm-kernel
Hi Olof, Kevin, and Arnd,
Please consider taking this additional set of updates for 4.10. These
apply on top of the previous tagged set of changes.
The following changes since commit d4714a5ab2132e899a531bcd267bd13555244927:
Merge tag 'qcom-dts-for-4.10-1' into dts-for-4.10-2 (2016-11-24 00:24:40 -0600)
are available in the git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/agross/linux.git tags/qcom-dts-for-4.10-2
for you to fetch changes up to a91b2e690d409476d711523be8a83062b9083fb2:
ARM: dts: Add xo to sdhc clock node on qcom platforms (2016-11-24 00:31:02 -0600)
----------------------------------------------------------------
Qualcomm Device Tree Changes for v4.10 - Part 2
* Add SDHC xo clk
----------------------------------------------------------------
Ritesh Harjani (1):
ARM: dts: Add xo to sdhc clock node on qcom platforms
arch/arm/boot/dts/qcom-apq8084.dtsi | 16 ++++++++++------
arch/arm/boot/dts/qcom-msm8974.dtsi | 16 ++++++++++------
2 files changed, 20 insertions(+), 12 deletions(-)
^ permalink raw reply
* [PATCH v1 & v6 1/2] PM/devfreq: add suspend frequency support
From: Chanwoo Choi @ 2016-11-24 7:10 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <58368C91.8030502@rock-chips.com>
+ Tobias Jakobi,
Hi Lin,
We need to discuss how to support the suspend-opp of devfreq device.
Now, there are two patch thread for suspend-opp of devfreq.
The Lin's approach modify the devfreq_suspend_device() to support suspend-opp.
The Tobias's approach[1] add new devfreq_suspend() and then call it on dpm_suspend()
when entering the suspend state.
[1] [RFC 0/4] PM / devfreq: draft for OPP suspend impl
- https://patchwork.kernel.org/patch/9443323/
- https://patchwork.kernel.org/patch/9443325/
- https://patchwork.kernel.org/patch/9443329/
- https://patchwork.kernel.org/patch/9443331/
I think we need to discuss it together.
Regards,
Chanwoo Choi
On 2016? 11? 24? 15:45, hl wrote:
> Hi MyungJoo Ham,
>
> On 2016?11?24? 14:14, MyungJoo Ham wrote:
>> 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.
>>
> Thanks for your suggestion, i will update the new version soon.
>>
>> Cheers,
>> MyungJoo
>>
>>
>>
>>
>> _______________________________________________
>> Linux-rockchip mailing list
>> Linux-rockchip at lists.infradead.org
>> http://lists.infradead.org/mailman/listinfo/linux-rockchip
>
> --
> Lin Huang
>
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox