* [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
* [PATCH][v2] arm64: Add DTS support for FSL's LS1012A SoC
From: Yao Yuan @ 2016-11-24 7:18 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1479320647-24460-1-git-send-email-harninder.rai@nxp.com>
Hi Shawn and All,
Any comment for this LS1012A platform support patch?
Is this a good enough base for consequence dts update patches?
If yes, I'd like to send some dts patches for DSPI and QSPI based on this patch.
Thanks.
Yao
On 11/17/2016 02:24 AM, Harninder Rai wrote:
> LS1012A features an advanced 64-bit ARM v8 CortexA53 processor with 32 KB
> of parity protected L1-I cache, 32 KB of ECC protected L1-D cache, as well as 256
> KB of ECC protected L2 cache.
>
> Features summary
> One 64-bit ARM-v8 Cortex-A53 core with the following capabilities
> - Arranged as a cluster of one core supporting a 256 KB L2 cache with ECC
> protection
> - Speed up to 800 MHz
> - Parity-protected 32 KB L1 instruction cache and 32 KB L1 data cache
> - Neon SIMD engine
> - ARM v8 cryptography extensions
> One 16-bit DDR3L SDRAM memory controller ARM core-link CCI-400 cache
> coherent interconnect Cryptography acceleration (SEC) One Configurable x3
> SerDes One PCI Express Gen2 controller, supporting x1 operation One serial
> ATA (SATA Gen 3.0) controller One USB 3.0/2.0 controller with integrated PHY
>
> Following levels of DTSI/DTS files have been created for the LS1012A
> SoC family:
>
> - fsl-ls1012a.dtsi:
> DTS-Include file for FSL LS1012A SoC.
>
> - fsl-ls1012a-frdm.dts:
> DTS file for FSL LS1012A FRDM board.
>
> - fsl-ls1012a-qds.dts:
> DTS file for FSL LS1012A QDS board.
>
> - fsl-ls1012a-rdb.dts:
> DTS file for FSL LS1012A RDB board.
>
> Signed-off-by: Harninder Rai <harninder.rai@nxp.com>
> Signed-off-by: Bhaskar Upadhaya <Bhaskar.Upadhaya@nxp.com>
> ---
> Changes in v2: Incorporated Shawn's comments
> - Brief introduction of the SoC in commit message
> - Alphabetic ordering of labeled nodes
> - Better naming to be used for regulator node
> - Make timer node's comments more readable
> - Sort nodes with unit-address in order of the address
>
> arch/arm64/boot/dts/freescale/Makefile | 3 +
> arch/arm64/boot/dts/freescale/fsl-ls1012a-frdm.dts | 115 ++++++++++
> arch/arm64/boot/dts/freescale/fsl-ls1012a-qds.dts | 128 +++++++++++
> arch/arm64/boot/dts/freescale/fsl-ls1012a-rdb.dts | 59 +++++
> arch/arm64/boot/dts/freescale/fsl-ls1012a.dtsi | 245
> +++++++++++++++++++++
> 5 files changed, 550 insertions(+)
> create mode 100644 arch/arm64/boot/dts/freescale/fsl-ls1012a-frdm.dts
> create mode 100644 arch/arm64/boot/dts/freescale/fsl-ls1012a-qds.dts
> create mode 100644 arch/arm64/boot/dts/freescale/fsl-ls1012a-rdb.dts
> create mode 100644 arch/arm64/boot/dts/freescale/fsl-ls1012a.dtsi
>
^ permalink raw reply
* [PATCH v1 & v6 1/2] PM/devfreq: add suspend frequency support
From: hl @ 2016-11-24 7:34 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <5836927B.9010205@samsung.com>
Hi Chanwoo Choi,
I think the dev_pm_opp_get_suspend_opp() have implement most of
the funtion, all we need is just define the node in dts, like following:
&dmc_opp_table {
opp06 {
opp-suspend;
};
};
so i think my way semm more simple.
On 2016?11?24? 15:10, Chanwoo Choi wrote:
> + 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
>>
>
>
>
--
Lin Huang
^ permalink raw reply
* [PATCH v1 & v6 1/2] PM/devfreq: add suspend frequency support
From: Chanwoo Choi @ 2016-11-24 8:16 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <5836980F.6050006@rock-chips.com>
Hi Lin,
On 2016? 11? 24? 16:34, hl wrote:
> Hi Chanwoo Choi,
>
> I think the dev_pm_opp_get_suspend_opp() have implement most of
> the funtion, all we need is just define the node in dts, like following:
>
> &dmc_opp_table {
> opp06 {
> opp-suspend;
> };
> };
Two approaches use the 'opp-suspend' property.
I think that the method to support suspend-opp have to
guarantee following conditions:
- Support the all of devfreq's governors.
- Devfreq framework have the responsibility to change the
frequency/voltage for suspend-opp. If we uses the
new devfreq_suspend(), each devfreq device don't care
how to support the suspend-opp. Just the developer of each
devfreq device need to add 'opp-suspend' propet to OPP entry in DT file.
Best Regards,
Chanwoo Choi
>
> so i think my way semm more simple.
>
> On 2016?11?24? 15:10, Chanwoo Choi wrote:
>> + 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
* [PATCH 1/4] serial: core: Add LED trigger support
From: Sascha Hauer @ 2016-11-24 8:17 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <e9fc12b8-d4a7-067d-ef87-03f0aae39bd7@gmail.com>
On Wed, Nov 23, 2016 at 10:57:13AM -0800, Florian Fainelli wrote:
> On 11/23/2016 02:01 AM, 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.
>
> Looking at 8250, we call serial8250_tx_chars from __start_tx which is
> called form the uart_ops::start_tx, for RX I sort of agree, since this
> happens in interrupt handler. I suppose some drivers could actually
> queue work but not do it right away though?
RX is not the problem. When characters are received all drivers call
tty_flip_buffer_push() which could be used for LED triggering (either
directly or we replace the calls to tty_flip_buffer_push() with some
wrapper function).
The problem comes with TX. The serial core has a FIFO which gets
characters from the tty layer. There is no function which the serial
drivers could call to read from this FIFO, instead they have to open code
this.
Continuing with the 8250 driver serial8250_tx_chars() is not only called
from __start_tx(), but also from the interrupt handler. Transmission
works without the serial_core ever noticing.
>
> > 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
> > activity.
>
> Could we somehow remedy the lack of knowledge from the core as whether
> the HW sends/receives characters first before adding support for LED
> triggers? It would be more generic and future proof to require UART
> drivers to report to the core when they actually TX/RX, and then at the
> core level, utilize that knowledge to perform the LED trigger.
Maybe we could introduce a function to read from the TX FIFO. Having
open coded this in each and every driver is not nice anyway.
>
> Side note: are you positive using drv->dev_name is robust enough on
> systems with many different UART drivers, yet all of them being ttyS*?
If we have different UART drivers, only one of them provides ttyS*, no?
Other drivers will have to use another namespace.
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 v3] clk: qoriq: added ls1012a clock configuration
From: Scott Wood @ 2016-11-24 8:21 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1479955015-37514-1-git-send-email-yuantian.tang@nxp.com>
On 11/23/2016 08:50 PM, yuantian.tang at nxp.com wrote:
> 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
[snip]
> @@ -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);
You need a better sorting algorithm. :-P
-Scott
^ permalink raw reply
* [PATCH 1/4] serial: core: Add LED trigger support
From: Sascha Hauer @ 2016-11-24 8:26 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161123100819.GA20137@kroah.com>
On Wed, Nov 23, 2016 at 11:08:19AM +0100, Greg Kroah-Hartman 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
> > activity.
BTW last time LED triggers were discussed
(https://patchwork.kernel.org/patch/9212885/) You and Arnd mandated the
triggers should be implemented in the tty layer. By tty layer did you
really mean the tty layer or did you mean serial_core?
We could implement it in the tty layer, but tty doesn't know when the
characters are actually sent. There could be arbitrary time passing
between a tty_operations->put_char and the character being on the wire.
Also I am not sure if we want to have LED triggers for each and every
tty in the system
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 v1 & v6 1/2] PM/devfreq: add suspend frequency support
From: hl @ 2016-11-24 8:34 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <5836A1E0.1070707@samsung.com>
Hi Chanwoo Choi,
On 2016?11?24? 16:16, Chanwoo Choi wrote:
> Hi Lin,
>
> On 2016? 11? 24? 16:34, hl wrote:
>> Hi Chanwoo Choi,
>>
>> I think the dev_pm_opp_get_suspend_opp() have implement most of
>> the funtion, all we need is just define the node in dts, like following:
>>
>> &dmc_opp_table {
>> opp06 {
>> opp-suspend;
>> };
>> };
> Two approaches use the 'opp-suspend' property.
>
> I think that the method to support suspend-opp have to
> guarantee following conditions:
> - Support the all of devfreq's governors.
As MyungJoo Ham suggestion, i will set the suspend frequency in
devfreq_suspend_device(),
which will ingore governor.
> - Devfreq framework have the responsibility to change the
> frequency/voltage for suspend-opp. If we uses the
> new devfreq_suspend(), each devfreq device don't care
> how to support the suspend-opp. Just the developer of each
> devfreq device need to add 'opp-suspend' propet to OPP entry in DT file.
Why should support change the voltage in devfreq framework, i think it
shuold be handle in
specific driver, i think the devfreq only handle it can get the right
frequency, then pass it to
specific driver, i think the voltage should handle in the
devfreq->profile->target();
> Best Regards,
> Chanwoo Choi
>
>> so i think my way semm more simple.
>>
>> On 2016?11?24? 15:10, Chanwoo Choi wrote:
>>> + 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
>>>>
>>>
>>>
>
>
>
--
Lin Huang
^ permalink raw reply
* [RFC PATCH] ARM: dts: Add support for Turris Omnia
From: Uwe Kleine-König @ 2016-11-24 8:37 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161123003505.GL2691@lunn.ch>
On 11/23/2016 01:35 AM, Andrew Lunn wrote:
>> +++ b/arch/arm/boot/dts/armada-385-turris-omnia.dts
>> @@ -0,0 +1,279 @@
>> +/*
>> + * Device Tree file for the Turris Omnia
>> + * Schematic available at https://www.turris.cz/doc/_media/rtrom01-schema.pdf
>
> Cool that there is a link to the schematics. But please could you put
> it lower down. It is more likely to be seen if it comes after the
> copyright and license section.
I added to the top because that's where I would look. But checking other
dts files it seems indeed to be more common after the copyright stuff.
I'd suggest to even start a new comment (i.e.
* last blabla of copyright
*/
/*
* Schematic available at ...
) to be more "loud".
@Tomas: I think it doesn't make sense when we alternate sending patches
without prior arrangement. Do you already work on a v5? If not I can do
that to fix the last few comments. Not sure when a submission is too
late to enter v4.10, but I think the window isn't that big any more.
> No leds? No buttons via gpio-keys?
The leds are controlled by a Cortex-M0 and without intervention blink
according to a hardware function (network, power, pci). IMHO that's ok
for an initial setup.
And there are no buttons that are routed to the Armada CPU. Just a reset
button (well, ok, this one is routed to the Armada CPU, but you cannot
make this a gpio-key :-) and the other button is used to control the
brightness of the LEDs and is only routed to the M0.
Best regards
Uwe
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 488 bytes
Desc: OpenPGP digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20161124/8bd849c4/attachment-0001.sig>
^ permalink raw reply
* [PATCH net-next 1/4] net: mvneta: Convert to be 64 bits compatible
From: Jisheng Zhang @ 2016-11-24 8:37 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAPv3WKf0a63qQT+xwXfUatbgLFF58e6L8J10VtBOUTam+kUcjg@mail.gmail.com>
Hi Marcin, Gregory, Arnd,
On Wed, 23 Nov 2016 17:02:11 +0100 Marcin Wojtas wrote:
> Hi Gregory,
>
> 2016-11-23 14:07 GMT+01:00 Gregory CLEMENT:
> > Hi Jisheng, Arnd,
> >
> >
> > Thanks for your feedback.
> >
> >
> > On mer., nov. 23 2016, Arnd Bergmann wrote:
> >
> >> On Wednesday, November 23, 2016 5:53:41 PM CET Jisheng Zhang wrote:
> >>> On Tue, 22 Nov 2016 22:04:12 +0100 Arnd Bergmann wrote:
> >>>
> >>> > On Tuesday, November 22, 2016 5:48:41 PM CET Gregory CLEMENT wrote:
> >>> > > +#ifdef CONFIG_64BIT
> >>> > > + void *data_tmp;
> >>> > > +
> >>> > > + /* In Neta HW only 32 bits data is supported, so in order to
> >>> > > + * obtain whole 64 bits address from RX descriptor, we store
> >>> > > + * the upper 32 bits when allocating buffer, and put it back
> >>> > > + * when using buffer cookie for accessing packet in memory.
> >>> > > + * Frags should be allocated from single 'memory' region,
> >>> > > + * hence common upper address half should be sufficient.
> >>> > > + */
> >>> > > + data_tmp = mvneta_frag_alloc(pp->frag_size);
> >>> > > + if (data_tmp) {
> >>> > > + pp->data_high = (u64)upper_32_bits((u64)data_tmp) << 32;
> >>> > > + mvneta_frag_free(pp->frag_size, data_tmp);
> >>> > > + }
> >>> > >
> >>> >
> >>> > How does this work when the region spans a n*4GB address boundary?
> >>>
> >>> indeed. We also make use of this driver on 64bit platforms. We use
> >>> different solution to make the driver 64bit safe.
> >>>
> >>> solA: make use of the reserved field in the mvneta_rx_desc, such
> >>> as reserved2 etc. Yes, the field is marked as "for future use, PnC", but
> >>> now it's not used at all. This is one possible solution however.
> >>
> >> Right, this sounds like the most straightforward choice.
> >
> > The PnC (which stands for Parsing and Classification) is not used yet
> > indeed but this field will be needed when we will enable it. It is
> > something we want to do but it is not planned in a near future. However
> > from the datasheets I have it seems only present on the Armada XP. It is
> > not mentioned on datasheets for the Armada 38x or the Armada 3700.
> >
>
> It is not mentioned in A38x spec, but this SoC has exactly the same
> PnC as Armada XP (they differ only with used SRAM details). I wouldn't
> be surprised if it was supported on A3700 as well.
>
> > That would mean it was safe to use on of this field in 64-bits mode on
> > the Armada 3700.
> >
> > So I am going to take this approach.
> >
>
> I think for now it's safe and is much easier than handling extra
> software ring for virtual addresses.
>
solB (a SW shadow cookie) perhaps gives a better performance: in hot path,
such as mvneta_rx(), the driver accesses buf_cookie and buf_phys_addr of
rx_desc which is allocated by dma_alloc_coherent, it's noncacheable if the
device isn't cache-coherent. I didn't measure the performance difference,
because in fact we take solA as well internally. From your experience,
can the performance gain deserve the complex code?
Thanks,
Jisheng
^ permalink raw reply
* [PATCH v2] ARM: dts: da850: add the mstpri and ddrctl nodes
From: Bartosz Golaszewski @ 2016-11-24 8:48 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20fbc946-d56c-31a3-4ae7-cf61df96a3c3@ti.com>
2016-11-24 6:03 GMT+01:00 Sekhar Nori <nsekhar@ti.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
I'll send a patch.
Thanks,
Bartosz
^ permalink raw reply
* [PATCH 1/7] add binding for stm32 multifunctions timer driver
From: Lee Jones @ 2016-11-24 8:52 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CA+M3ks6rnago88JC0C5Uj6JpGZGuwyoOj-W8+r7Oj4s8_GuXyA@mail.gmail.com>
Rob,
Would you mind casting an eye on this please?
On Wed, 23 Nov 2016, Benjamin Gaignard wrote:
> 2016-11-23 10:21 GMT+01:00 Lee Jones <lee.jones@linaro.org>:
> > On Wed, 23 Nov 2016, Benjamin Gaignard wrote:
> >
> >> 2016-11-22 17:52 GMT+01:00 Lee Jones <lee.jones@linaro.org>:
> >> > On Tue, 22 Nov 2016, Benjamin Gaignard wrote:
> >> >
> >> >> Add bindings information for stm32 timer MFD
> >> >>
> >> >> Signed-off-by: Benjamin Gaignard <benjamin.gaignard@st.com>
> >> >> ---
> >> >> .../devicetree/bindings/mfd/stm32-timer.txt | 53 ++++++++++++++++++++++
> >> >> 1 file changed, 53 insertions(+)
> >> >> create mode 100644 Documentation/devicetree/bindings/mfd/stm32-timer.txt
> >> >>
> >> >> diff --git a/Documentation/devicetree/bindings/mfd/stm32-timer.txt b/Documentation/devicetree/bindings/mfd/stm32-timer.txt
> >> >> new file mode 100644
> >> >> index 0000000..3cefce1
> >> >> --- /dev/null
> >> >> +++ b/Documentation/devicetree/bindings/mfd/stm32-timer.txt
> >> >> @@ -0,0 +1,53 @@
> >> >> +STM32 multifunctions timer driver
> >> >
> >> > "STM32 Multi-Function Timer/PWM device bindings"
> >> >
> >> > Doesn't this shared device have a better name?
> >>
> >> In SoC documentation those hardware blocks are named "advanced-control
> >> timers", "general purpose timers" or "basic timers"
> >> "stm32-timer" name is already used for clock source driver, that why I
> >> have prefix it with mfd
> >
> > MFD is a Linuxisum and has no place in hardware description.
> >
> > Please used one of the names you mentioned above.
>
> I will go for "st,stm32-advanced-timer"
>
> >
> > Hopefully the one that best fits.
> >
> >> >> +stm32 timer MFD allow to handle at the same time pwm and IIO timer devices
> >> >
> >> > No need for this sentence.
> >> >
> >> OK
> >>
> >> >> +Required parameters:
> >> >> +- compatible: must be one of the follow value:
> >> >> + "st,stm32-mfd-timer1"
> >> >> + "st,stm32-mfd-timer2"
> >> >> + "st,stm32-mfd-timer3"
> >> >> + "st,stm32-mfd-timer4"
> >> >> + "st,stm32-mfd-timer5"
> >> >> + "st,stm32-mfd-timer6"
> >> >> + "st,stm32-mfd-timer7"
> >> >> + "st,stm32-mfd-timer8"
> >> >> + "st,stm32-mfd-timer9"
> >> >> + "st,stm32-mfd-timer10"
> >> >> + "st,stm32-mfd-timer11"
> >> >> + "st,stm32-mfd-timer12"
> >> >> + "st,stm32-mfd-timer13"
> >> >> + "st,stm32-mfd-timer14"
> >> >
> >> > We don't normally number devices.
> >> >
> >> > What's stopping you from simply doing:
> >> >
> >> > pwm1: pwm1 at 40010000 {
> >> > compatible = "st,stm32-pwm";
> >> > };
> >> > pwm2: pwm1 at 40020000 {
> >> > compatible = "st,stm32-pwm";
> >> > };
> >> > pwm3: pwm1 at 40030000 {
> >> > compatible = "st,stm32-pwm";
> >> > };
> >> >
> >>
> >> Because each instance of the hardware is slightly different: number of
> >> pwm channels, triggers capabilities, etc ..
> >> so I need to distinguish them.
> >> Since it look to be a problem I will follow your suggestion and add a
> >> property this driver to be able to identify each instance.
> >> Do you think that "id" parameter (integer for 1 to 14) is acceptable ?
> >
> > Unfortunately not. IDs aren't allowed in DT.
> >
> > What about "pwm-chans" and "trigger"?
> >
> > pwm-chans : Number of available channels available
>
> For pwm I need those 4 properties:
> st,pwm-number: the number of PWM devices
st,pwm-num-chan is already documented.
Please use that instead of creating new properties.
> st,complementary: if exist have complementary ouput
> st,32bit-counter: if exist have 32 bits counter
> st,breakinput-polarity: if set enable break input feature.
>
> Is it acceptable from pwm maintainer point of view ?
>
> > trigger : Boolean value specifying whether a timer is present
>
> Following our discussion on IRC I will try to code for your proposal:
>
> advanced-timer at 40010000 {
> compatible = "st,stm32-advanced-timer";
> reg = <0x40010000 0x400>;
> clocks = <&rcc 0 160>;
> clock-names = "clk_int";
>
> pwm at 0 {
> compatible = "st,stm32-pwm";
> st,pwm-number= <4>;
> st,complementary;
> st,breakinput;
> };
>
> timer at 0 {
> reg = <1>;
> compatible = "st,stm32-iio-timer";
> interrupts = <27>;
> triggers = <5 2 3 4>;
> };
> };
>
> triggers parameter will be used to know which trigger are valid for
> the IIO device
Except for "st,pwm-number" as mentioned above, this looks good to me.
Rob, would what do you think?
--
Lee Jones
Linaro STMicroelectronics Landing Team Lead
Linaro.org ? Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog
^ permalink raw reply
* [PATCH net-next 1/4] net: mvneta: Convert to be 64 bits compatible
From: Arnd Bergmann @ 2016-11-24 9:00 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161124163327.1cc261ab@xhacker>
On Thursday, November 24, 2016 4:37:36 PM CET Jisheng Zhang wrote:
> solB (a SW shadow cookie) perhaps gives a better performance: in hot path,
> such as mvneta_rx(), the driver accesses buf_cookie and buf_phys_addr of
> rx_desc which is allocated by dma_alloc_coherent, it's noncacheable if the
> device isn't cache-coherent. I didn't measure the performance difference,
> because in fact we take solA as well internally. From your experience,
> can the performance gain deserve the complex code?
Yes, a read from uncached memory is fairly slow, so if you have a chance
to avoid that it will probably help. When adding complexity to the code,
it probably makes sense to take a runtime profile anyway quantify how
much it gains.
On machines that have cache-coherent DMA, accessing the descriptor
should be fine, as you already have to load the entire cache line
to read the status field.
Looking at this snippet:
rx_status = rx_desc->status;
rx_bytes = rx_desc->data_size - (ETH_FCS_LEN + MVNETA_MH_SIZE);
data = (unsigned char *)rx_desc->buf_cookie;
phys_addr = rx_desc->buf_phys_addr;
pool_id = MVNETA_RX_GET_BM_POOL_ID(rx_desc);
bm_pool = &pp->bm_priv->bm_pools[pool_id];
if (!mvneta_rxq_desc_is_first_last(rx_status) ||
(rx_status & MVNETA_RXD_ERR_SUMMARY)) {
err_drop_frame_ret_pool:
/* Return the buffer to the pool */
mvneta_bm_pool_put_bp(pp->bm_priv, bm_pool,
rx_desc->buf_phys_addr);
err_drop_frame:
I think there is more room for optimizing if you start: you read
the status field twice (the second one in MVNETA_RX_GET_BM_POOL_ID)
and you can cache the buf_phys_addr along with the virtual address
once you add that.
Generally speaking, I'd recommend using READ_ONCE()/WRITE_ONCE()
to access the descriptor fields, to ensure the compiler doesn't
add extra references as well as to annotate the expensive
operations.
Arnd
^ permalink raw reply
* [PATCH 5/10] dt: bindings: Add bindings for Marvell Xenon SD Host Controller
From: Ulf Hansson @ 2016-11-24 9:05 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <87d1hno2d7.fsf@free-electrons.com>
On 22 November 2016 at 18:23, Gregory CLEMENT
<gregory.clement@free-electrons.com> wrote:
> Hi Rob,
>
> On jeu., nov. 10 2016, Ziji Hu <huziji@marvell.com> wrote:
>
> [...]
>
>>>> +
>>>> +- reg:
>>>> + * For "marvell,xenon-sdhci", one register area for Xenon IP.
>>>> +
>>>> + * For "marvell,armada-3700-sdhci", two register areas.
>>>> + The first one for Xenon IP register. The second one for the Armada 3700 SOC
>>>> + PHY PAD Voltage Control register.
>>>> + Please follow the examples with compatible "marvell,armada-3700-sdhci"
>>>> + in below.
>>>> + Please also check property marvell,pad-type in below.
>>>> +
>>>> +Optional Properties:
>>>> +- marvell,xenon-slotno:
>>>
>>> Multiple slots should be represented as child nodes IMO. I think some
>>> other bindings already do this.
>>>
>>
>> All the slots are entirely independent.
>> I prefer to consider it as multiple independent SDHCs placed in
>> a single IP, instead of that a IP contains multiple child slots.
>
> It was indeed what I tried to show in my answer for the 1st version:
> http://lists.infradead.org/pipermail/linux-arm-kernel/2016-October/461860.html
>
> Maybe you missed it.
>
> You also mentioned other bindings using child nodes, but for this one
> we have one controller with only one set of register with multiple slots
> (Atmel is an example). Here each slot have it own set of register.
>
> Actually giving the fact that each slot is controlled by a different set
> of register I wonder why the hardware can't also deduce the slot number
> from the address register. For me it looks like an hardware bug but we
> have to deal with it.
>
> Do you still think we needchild node here?
Using child-nodes for slots like what's done in the atmel case, is
currently broken. I would recommend to avoid using child-nodes for
slots, if possible.
To give you some more background, currently the mmc core treats child
nodes as embedded non-removable cards or SDIO funcs. However, we can
change to make child-nodes also allowed to describe slots, but it
requires a specific compatible for "slots" and of course then we also
need to update the DT parsing of the child-nodes in the mmc core.
Documentation/devicetree/bindings/mmc/mmc.txt
Documentation/devicetree/bindings/mmc/mmc-card.txt
>
>>
>> It is unlike the implementation which put multiple slots behind PCIe EP interface. sdhci-pci.c will handle each slot init one by one.
>> If Xenon SDHC slots are represented as child nodes, there should also be a main entry in Xenon driver to init each child node one by one.
>> In my very own opinion, it is inconvenient and unnecessary.
>
Kind regards
Uffe
^ permalink raw reply
* [PATCH 5/10] dt: bindings: Add bindings for Marvell Xenon SD Host Controller
From: Arnd Bergmann @ 2016-11-24 9:11 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAPDyKFpoifsKkse7Fc-bbZAoa=QGT=9QOQ-4D=f60ptx0hzZsA@mail.gmail.com>
On Thursday, November 24, 2016 10:05:45 AM CET Ulf Hansson wrote:
> > You also mentioned other bindings using child nodes, but for this one
> > we have one controller with only one set of register with multiple slots
> > (Atmel is an example). Here each slot have it own set of register.
> >
> > Actually giving the fact that each slot is controlled by a different set
> > of register I wonder why the hardware can't also deduce the slot number
> > from the address register. For me it looks like an hardware bug but we
> > have to deal with it.
> >
> > Do you still think we needchild node here?
>
> Using child-nodes for slots like what's done in the atmel case, is
> currently broken. I would recommend to avoid using child-nodes for
> slots, if possible.
>
> To give you some more background, currently the mmc core treats child
> nodes as embedded non-removable cards or SDIO funcs. However, we can
> change to make child-nodes also allowed to describe slots, but it
> requires a specific compatible for "slots" and of course then we also
> need to update the DT parsing of the child-nodes in the mmc core.
>
> Documentation/devicetree/bindings/mmc/mmc.txt
> Documentation/devicetree/bindings/mmc/mmc-card.txt
I don't see anything wrong with having child nodes for the slots
even with the current binding, under one condition:
The mmc.txt binding above must refer only to the child node, while
the parent node conceptually becomes a plain bus or MFD that
happens to encapsulate multiple MMC host controllers, and possibly
provides some shared registers to them.
Arnd
^ permalink raw reply
* [PATCH v7] PM/devfreq: add suspend frequency support
From: Lin Huang @ 2016-11-24 9:11 UTC (permalink / raw)
To: linux-arm-kernel
Add suspend frequency support and if needed set it to
the frequency obtained from the suspend opp (can be defined
using opp-v2 bindings and is optional).
Signed-off-by: Lin Huang <hl@rock-chips.com>
---
Changes in v2:
- use update_devfreq() instead devfreq_update_status()
Changes in v3:
- fix build error
Changes in v4:
- move dev_pm_opp_get_suspend_opp() to devfreq_add_device()
Changes in v5:
- delete devfreq_opp_get_suspend_opp() in devfreq.h
Changes in v6:
- return to use stop_polling check suspend status
Changes in v7:
- move handle suspend frequency in devfreq_suspend_device()
drivers/devfreq/devfreq.c | 47 ++++++++++++++++++++++++++++++++++-------------
include/linux/devfreq.h | 1 +
2 files changed, 35 insertions(+), 13 deletions(-)
diff --git a/drivers/devfreq/devfreq.c b/drivers/devfreq/devfreq.c
index da72d97..958abc8 100644
--- a/drivers/devfreq/devfreq.c
+++ b/drivers/devfreq/devfreq.c
@@ -212,16 +212,7 @@ static int devfreq_notify_transition(struct devfreq *devfreq,
return 0;
}
-/* Load monitoring helper functions for governors use */
-
-/**
- * update_devfreq() - Reevaluate the device and configure frequency.
- * @devfreq: the devfreq instance.
- *
- * Note: Lock devfreq->lock before calling update_devfreq
- * This function is exported for governors.
- */
-int update_devfreq(struct devfreq *devfreq)
+static int _update_devfreq(struct devfreq *devfreq, bool is_suspending)
{
struct devfreq_freqs freqs;
unsigned long freq, cur_freq;
@@ -237,9 +228,13 @@ int update_devfreq(struct devfreq *devfreq)
return -EINVAL;
/* Reevaluate the proper frequency */
- err = devfreq->governor->get_target_freq(devfreq, &freq);
- if (err)
- return err;
+ if (is_suspending && devfreq->suspend_freq) {
+ freq = devfreq->suspend_freq;
+ } else {
+ err = devfreq->governor->get_target_freq(devfreq, &freq);
+ if (err)
+ return err;
+ }
/*
* Adjust the frequency with user freq and QoS.
@@ -285,6 +280,21 @@ int update_devfreq(struct devfreq *devfreq)
devfreq->previous_freq = freq;
return err;
}
+
+/* Load monitoring helper functions for governors use */
+
+/**
+ * update_devfreq() - Reevaluate the device and configure frequency.
+ * @devfreq: the devfreq instance.
+ *
+ * Note: Lock devfreq->lock before calling update_devfreq
+ * This function is exported for governors.
+ */
+
+int update_devfreq(struct devfreq *devfreq)
+{
+ return _update_devfreq(devfreq, false);
+}
EXPORT_SYMBOL(update_devfreq);
/**
@@ -524,6 +534,7 @@ struct devfreq *devfreq_add_device(struct device *dev,
struct devfreq *devfreq;
struct devfreq_governor *governor;
int err = 0;
+ struct dev_pm_opp *suspend_opp;
if (!dev || !profile || !governor_name) {
dev_err(dev, "%s: Invalid parameters.\n", __func__);
@@ -558,6 +569,12 @@ struct devfreq *devfreq_add_device(struct device *dev,
devfreq->data = data;
devfreq->nb.notifier_call = devfreq_notifier_call;
+ rcu_read_lock();
+ suspend_opp = dev_pm_opp_get_suspend_opp(dev);
+ if (suspend_opp)
+ devfreq->suspend_freq = dev_pm_opp_get_freq(suspend_opp);
+ rcu_read_unlock();
+
if (!devfreq->profile->max_state && !devfreq->profile->freq_table) {
mutex_unlock(&devfreq->lock);
devfreq_set_freq_table(devfreq);
@@ -754,6 +771,10 @@ int devfreq_suspend_device(struct devfreq *devfreq)
if (!devfreq->governor)
return 0;
+ mutex_lock(&devfreq->lock);
+ _update_devfreq(devfreq, true);
+ mutex_unlock(&devfreq->lock);
+
return devfreq->governor->event_handler(devfreq,
DEVFREQ_GOV_SUSPEND, NULL);
}
diff --git a/include/linux/devfreq.h b/include/linux/devfreq.h
index 98c6993..517e394 100644
--- a/include/linux/devfreq.h
+++ b/include/linux/devfreq.h
@@ -172,6 +172,7 @@ struct devfreq {
struct delayed_work work;
unsigned long previous_freq;
+ unsigned long suspend_freq;
struct devfreq_dev_status last_status;
void *data; /* private data for governors */
--
2.6.6
^ permalink raw reply related
* [PATCH net-next 1/4] net: mvneta: Convert to be 64 bits compatible
From: Jisheng Zhang @ 2016-11-24 9:11 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <21520380.oWTKcrq8DS@wuerfel>
On Thu, 24 Nov 2016 10:00:36 +0100
Arnd Bergmann <arnd@arndb.de> wrote:
> On Thursday, November 24, 2016 4:37:36 PM CET Jisheng Zhang wrote:
> > solB (a SW shadow cookie) perhaps gives a better performance: in hot path,
> > such as mvneta_rx(), the driver accesses buf_cookie and buf_phys_addr of
> > rx_desc which is allocated by dma_alloc_coherent, it's noncacheable if the
> > device isn't cache-coherent. I didn't measure the performance difference,
> > because in fact we take solA as well internally. From your experience,
> > can the performance gain deserve the complex code?
>
> Yes, a read from uncached memory is fairly slow, so if you have a chance
> to avoid that it will probably help. When adding complexity to the code,
> it probably makes sense to take a runtime profile anyway quantify how
> much it gains.
>
> On machines that have cache-coherent DMA, accessing the descriptor
> should be fine, as you already have to load the entire cache line
> to read the status field.
>
> Looking at this snippet:
>
> rx_status = rx_desc->status;
> rx_bytes = rx_desc->data_size - (ETH_FCS_LEN + MVNETA_MH_SIZE);
> data = (unsigned char *)rx_desc->buf_cookie;
> phys_addr = rx_desc->buf_phys_addr;
> pool_id = MVNETA_RX_GET_BM_POOL_ID(rx_desc);
> bm_pool = &pp->bm_priv->bm_pools[pool_id];
>
> if (!mvneta_rxq_desc_is_first_last(rx_status) ||
> (rx_status & MVNETA_RXD_ERR_SUMMARY)) {
> err_drop_frame_ret_pool:
> /* Return the buffer to the pool */
> mvneta_bm_pool_put_bp(pp->bm_priv, bm_pool,
> rx_desc->buf_phys_addr);
> err_drop_frame:
>
>
> I think there is more room for optimizing if you start: you read
> the status field twice (the second one in MVNETA_RX_GET_BM_POOL_ID)
> and you can cache the buf_phys_addr along with the virtual address
> once you add that.
oh, yeah! buf_phy_addr could be included too.
>
> Generally speaking, I'd recommend using READ_ONCE()/WRITE_ONCE()
> to access the descriptor fields, to ensure the compiler doesn't
> add extra references as well as to annotate the expensive
> operations.
>
> Arnd
Got it. Thanks so much for the detailed guide.
^ 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