Re: [PATCH 10/10] crypto: tcrypt: Added speed tests for Async AEAD crypto alogrithms
On Thu, Jul 02, 2015 at 10:48:40AM +0530, Lokesh Vutla wrote: Adding simple speed tests for a range of block sizes for Async AEAD crypto algorithms. Signed-off-by: Lokesh Vutla lokeshvu...@ti.com What's wrong with the existing AEAD speed tests? -- Email: Herbert Xu herb...@gondor.apana.org.au Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] thermal: consistently use int for temperatures
On Mon, Jul 6, 2015 at 9:19 AM, Sascha Hauer s.ha...@pengutronix.de wrote:
The thermal code uses int, long and unsigned long for temperatures
in different places.
Using an unsigned type limits the thermal framework to positive
temperatures without need. Also several drivers currently will report
temperatures near UINT_MAX for temperatures below 0°C. This will probably
immediately shut the machine down due to overtemperature if started below
0°C.
'long' is 64bit on several architectures. This is not needed since INT_MAX °mC
is above the melting point of all known materials.
Consistently use a plain 'int' for temperatures throughout the thermal code
and
the drivers. This only changes the places in the drivers where the temperature
is passed around as pointer, when drivers internally use another type this is
not changed.
Signed-off-by: Sascha Hauer s.ha...@pengutronix.de
Cc: Zhang Rui rui.zh...@intel.com
Cc: Eduardo Valentin edubez...@gmail.com
Cc: linux...@vger.kernel.org
Cc: linux-ker...@vger.kernel.org
Cc: Jean Delvare jdelv...@suse.de
Cc: Peter Feuerer pe...@piie.net
Cc: Heiko Stuebner he...@sntech.de
Cc: Lukasz Majewski l.majew...@samsung.com
Cc: Stephen Warren swar...@wwwdotorg.org
Cc: Thierry Reding thierry.red...@gmail.com
Cc: linux-a...@vger.kernel.org
Cc: platform-driver-...@vger.kernel.org
Cc: linux-arm-ker...@lists.infradead.org
Cc: linux-omap@vger.kernel.org
Cc: linux-samsung-...@vger.kernel.org
Cc: Guenter Roeck li...@roeck-us.net
Cc: Rafael J. Wysocki r...@rjwysocki.net
Cc: Maxime Ripard maxime.rip...@free-electrons.com
Cc: Darren Hart dvh...@infradead.org
Cc: lm-sens...@lm-sensors.org
For rcar-thermal:
Acked-by: Geert Uytterhoeven geert+rene...@glider.be
diff --git a/drivers/thermal/rcar_thermal.c b/drivers/thermal/rcar_thermal.c
index fe4e767..5d4ae7d 100644
--- a/drivers/thermal/rcar_thermal.c
+++ b/drivers/thermal/rcar_thermal.c
@@ -200,8 +200,7 @@ err_out_unlock:
return ret;
}
-static int rcar_thermal_get_temp(struct thermal_zone_device *zone,
-unsigned long *temp)
+static int rcar_thermal_get_temp(struct thermal_zone_device *zone, int *temp)
{
struct rcar_thermal_priv *priv = rcar_zone_to_priv(zone);
@@ -235,7 +234,7 @@ static int rcar_thermal_get_trip_type(struct
thermal_zone_device *zone,
}
static int rcar_thermal_get_trip_temp(struct thermal_zone_device *zone,
- int trip, unsigned long *temp)
+ int trip, int *temp)
{
struct rcar_thermal_priv *priv = rcar_zone_to_priv(zone);
struct device *dev = rcar_priv_to_dev(priv);
@@ -299,7 +298,7 @@ static void _rcar_thermal_irq_ctrl(struct
rcar_thermal_priv *priv, int enable)
static void rcar_thermal_work(struct work_struct *work)
{
struct rcar_thermal_priv *priv;
- unsigned long cctemp, nctemp;
+ int cctemp, nctemp;
priv = container_of(work, struct rcar_thermal_priv, work.work);
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say programmer or something like that.
-- Linus Torvalds
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 10/10] crypto: tcrypt: Added speed tests for Async AEAD crypto alogrithms
Hi, On Monday 06 July 2015 01:14 PM, Herbert Xu wrote: On Thu, Jul 02, 2015 at 10:48:40AM +0530, Lokesh Vutla wrote: Adding simple speed tests for a range of block sizes for Async AEAD crypto algorithms. Signed-off-by: Lokesh Vutla lokeshvu...@ti.com What's wrong with the existing AEAD speed tests? The existing AEAD test case does not do a wait_for_completion(), when the return value is EINPROGRESS or EBUSY like it is done for acipher_speed tests. Can I be updating the same test case for handling this? Correct me if I am wrong. Thanks and regards, Lokesh -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PULL gpio-for-next] gpio: make flags mandatory for gpiod_get functions
Hello, now that all patches that were in next hit Linus Torvalds' tree and v4.2-rc1 is out here comes the promised pull request that makes usage of the flags parameter mandatory for gpiod_get et al: The following changes since commit d770e558e21961ad6cfdf0ff7df0eb5d7d4f0754: Linux 4.2-rc1 (2015-07-05 11:01:52 -0700) are available in the git repository at: git://git.pengutronix.de/git/ukl/linux.git tags/gpiod-flags-for-4.3 for you to fetch changes up to b17d1bf16cc72a374a48d748940f79d40ff4: gpio: make flags mandatory for gpiod_get functions (2015-07-06 10:39:24 +0200) The last patch in this series makes the flags parameter for the various gpiod_get* functions mandatory and so allows to remove an ugly cpp hack introduced in commit 39b2bbe3d715 (gpio: add flags argument to gpiod_get*() functions) for v3.17-rc1. The other nine commits fix the last remaining users of these functions that don't pass flags yet. (Only etraxfs-uart wasn't fixed; this driver's use of the gpiod functions needs fixing anyhow.) According to the coccinelle-script I wrote all users (apart from etraxfs-uart) are fixed now. As some of the maintainers requested it, I'll resend the patches contained in this series as a reply to this mail. It would be great if this could be put into next via the gpio tree to give new users enough time to adapt their patches. Thanks Uwe Uwe Kleine-König (10): drm/msm/dp: use flags argument of devm_gpiod_get to set direction drm/tilcdc: panel: make better use of gpiod API iio: light: stk3310: use flags argument of devm_gpiod_get iio: magn: bmc150: use flags argument of devm_gpiod_get media: i2c/adp1653: set enable gpio to output NFC: nxp-nci_i2c: use flags argument of devm_gpiod_get_index phy: tusb1210: make better use of gpiod API usb: dwc3: pci: make better use of gpiod API usb: pass flags parameter to gpiod_get functions gpio: make flags mandatory for gpiod_get functions drivers/gpio/devres.c | 18 drivers/gpio/gpiolib.c | 16 +++ drivers/gpu/drm/msm/edp/edp_ctrl.c | 17 +-- drivers/gpu/drm/tilcdc/tilcdc_panel.c | 22 +++-- drivers/iio/light/stk3310.c| 6 +-- drivers/iio/magnetometer/bmc150_magn.c | 6 +-- drivers/media/i2c/adp1653.c| 2 +- drivers/nfc/nxp-nci/i2c.c | 10 ++--- drivers/phy/phy-tusb1210.c | 30 + drivers/usb/dwc3/dwc3-pci.c| 26 ++- drivers/usb/gadget/udc/pxa27x_udc.c| 2 +- drivers/usb/phy/phy-generic.c | 6 ++- include/linux/gpio/consumer.h | 82 ++ 13 files changed, 88 insertions(+), 155 deletions(-) -- Pengutronix e.K. | Uwe Kleine-König| Industrial Linux Solutions | http://www.pengutronix.de/ | -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] thermal: consistently use int for temperatures
On Mon, 6 Jul 2015 09:19:49 +0200, Sascha Hauer wrote: The thermal code uses int, long and unsigned long for temperatures in different places. Using an unsigned type limits the thermal framework to positive temperatures without need. Also several drivers currently will report temperatures near UINT_MAX for temperatures below 0°C. This will probably immediately shut the machine down due to overtemperature if started below 0°C. 'long' is 64bit on several architectures. This is not needed since INT_MAX °mC is above the melting point of all known materials. Consistently use a plain 'int' for temperatures throughout the thermal code and the drivers. This only changes the places in the drivers where the temperature is passed around as pointer, when drivers internally use another type this is not changed. Signed-off-by: Sascha Hauer s.ha...@pengutronix.de Cc: Zhang Rui rui.zh...@intel.com Cc: Eduardo Valentin edubez...@gmail.com Cc: linux...@vger.kernel.org Cc: linux-ker...@vger.kernel.org Cc: Jean Delvare jdelv...@suse.de Cc: Peter Feuerer pe...@piie.net Cc: Heiko Stuebner he...@sntech.de Cc: Lukasz Majewski l.majew...@samsung.com Cc: Stephen Warren swar...@wwwdotorg.org Cc: Thierry Reding thierry.red...@gmail.com Cc: linux-a...@vger.kernel.org Cc: platform-driver-...@vger.kernel.org Cc: linux-arm-ker...@lists.infradead.org Cc: linux-omap@vger.kernel.org Cc: linux-samsung-...@vger.kernel.org Cc: Guenter Roeck li...@roeck-us.net Cc: Rafael J. Wysocki r...@rjwysocki.net Cc: Maxime Ripard maxime.rip...@free-electrons.com Cc: Darren Hart dvh...@infradead.org Cc: lm-sens...@lm-sensors.org --- drivers/acpi/thermal.c | 12 +- drivers/hwmon/lm75.c | 2 +- drivers/hwmon/ntc_thermistor.c | 2 +- drivers/hwmon/tmp102.c | 2 +- drivers/input/touchscreen/sun4i-ts.c | 8 +++ drivers/platform/x86/acerhdf.c | 9 drivers/platform/x86/intel_mid_thermal.c | 9 drivers/power/power_supply_core.c | 2 +- drivers/thermal/armada_thermal.c | 2 +- drivers/thermal/db8500_thermal.c | 7 +++--- drivers/thermal/dove_thermal.c | 2 +- drivers/thermal/fair_share.c | 2 +- drivers/thermal/gov_bang_bang.c| 5 ++-- drivers/thermal/hisi_thermal.c | 4 ++-- drivers/thermal/imx_thermal.c | 27 +++--- drivers/thermal/int340x_thermal/int3400_thermal.c | 2 +- .../thermal/int340x_thermal/int340x_thermal_zone.c | 10 .../thermal/int340x_thermal/int340x_thermal_zone.h | 8 +++ .../int340x_thermal/processor_thermal_device.c | 4 ++-- drivers/thermal/intel_quark_dts_thermal.c | 13 +-- drivers/thermal/intel_soc_dts_iosf.c | 8 +++ drivers/thermal/kirkwood_thermal.c | 2 +- drivers/thermal/of-thermal.c | 14 +-- drivers/thermal/power_allocator.c | 16 ++--- drivers/thermal/qcom-spmi-temp-alarm.c | 2 +- drivers/thermal/rcar_thermal.c | 7 +++--- drivers/thermal/rockchip_thermal.c | 10 drivers/thermal/samsung/exynos_tmu.c | 23 +- drivers/thermal/spear_thermal.c| 2 +- drivers/thermal/st/st_thermal.c| 5 ++-- drivers/thermal/step_wise.c| 4 ++-- drivers/thermal/tegra_soctherm.c | 4 ++-- drivers/thermal/thermal_core.c | 26 ++--- drivers/thermal/thermal_hwmon.c| 10 drivers/thermal/ti-soc-thermal/ti-thermal-common.c | 10 drivers/thermal/x86_pkg_temp_thermal.c | 10 include/linux/thermal.h| 26 + 37 files changed, 148 insertions(+), 163 deletions(-) (...) No objection from me. For the hwmon parts: Reviewed-by: Jean Delvare jdelv...@suse.de -- Jean Delvare SUSE L3 Support -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 0/7] tty: 8250: omap: workaround for IP errata and a bug fix
This series works around Advisory 21 as documented in AM437x SoC errata[1]. AM335x and DRA7x also suffer from the same errata and chip design team is in the process of updating the errata documents of those devices as well. Patch 1/7 fixes a related bug but can be applied independently. Series applies to v4.2-rc1 [1] http://www.ti.com/lit/er/sprz408b/sprz408b.pdf Sekhar Nori (7): tty: serial: 8250: omap: fix kernel crash in suspend-to-ram Documentation: DT: omap_serial: document missing compatible tty: 8250: omap: introduce function to update mdr1 tty: 8250: omap eliminate use of of_machine_is_compatible() tty: 8250: workaround errata on disabling UART after using DMA tty: 8250: omap: workaround module disable errata on dra7x SoCs ARM: dts: dra7: workaround UART module disable errata .../devicetree/bindings/serial/omap_serial.txt | 3 + arch/arm/boot/dts/am33xx.dtsi | 12 +-- arch/arm/boot/dts/dra7.dtsi| 20 ++-- drivers/tty/serial/8250/8250_omap.c| 110 - 4 files changed, 103 insertions(+), 42 deletions(-) -- 2.4.4.408.g16da57c -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 4/7] tty: 8250: omap eliminate use of of_machine_is_compatible()
Use of of_machine_is_compatible() for AM335x specific DMA
quirk in 8250_omap driver makes it ugly to extend the
quirk for other platforms. Instead use a new compatible.
The new compatible will also make it easier to care of other
quirks specific to AM335x and like SoCs.
This patch does break backward DTB compatibility for users of
8250_omap driver on AM335x boards. However, the 8250_omap driver
is new and omap_serial is still the default choice driver for UART
and so choosing to break compatibility over keeping the code
around forever.
Signed-off-by: Sekhar Nori nsek...@ti.com
---
.../devicetree/bindings/serial/omap_serial.txt | 1 +
arch/arm/boot/dts/am33xx.dtsi | 12
drivers/tty/serial/8250/8250_omap.c| 35 +-
3 files changed, 28 insertions(+), 20 deletions(-)
diff --git a/Documentation/devicetree/bindings/serial/omap_serial.txt
b/Documentation/devicetree/bindings/serial/omap_serial.txt
index d3bd2b1ec401..0ee88209b341 100644
--- a/Documentation/devicetree/bindings/serial/omap_serial.txt
+++ b/Documentation/devicetree/bindings/serial/omap_serial.txt
@@ -5,6 +5,7 @@ Required properties:
- compatible : should be ti,omap3-uart for OMAP3 controllers
- compatible : should be ti,omap4-uart for OMAP4 controllers
- compatible : should be ti,am4372-uart for AM437x controllers
+- compatible : should be ti,am3352-uart for AM335x controllers
- reg : address and length of the register space
- interrupts or interrupts-extended : Should contain the uart interrupt
specifier or both the interrupt
diff --git a/arch/arm/boot/dts/am33xx.dtsi b/arch/arm/boot/dts/am33xx.dtsi
index 21fcc440fc1a..b76f9a2ce05d 100644
--- a/arch/arm/boot/dts/am33xx.dtsi
+++ b/arch/arm/boot/dts/am33xx.dtsi
@@ -210,7 +210,7 @@
};
uart0: serial@44e09000 {
- compatible = ti,omap3-uart;
+ compatible = ti,am3352-uart, ti,omap3-uart;
ti,hwmods = uart1;
clock-frequency = 4800;
reg = 0x44e09000 0x2000;
@@ -221,7 +221,7 @@
};
uart1: serial@48022000 {
- compatible = ti,omap3-uart;
+ compatible = ti,am3352-uart, ti,omap3-uart;
ti,hwmods = uart2;
clock-frequency = 4800;
reg = 0x48022000 0x2000;
@@ -232,7 +232,7 @@
};
uart2: serial@48024000 {
- compatible = ti,omap3-uart;
+ compatible = ti,am3352-uart, ti,omap3-uart;
ti,hwmods = uart3;
clock-frequency = 4800;
reg = 0x48024000 0x2000;
@@ -243,7 +243,7 @@
};
uart3: serial@481a6000 {
- compatible = ti,omap3-uart;
+ compatible = ti,am3352-uart, ti,omap3-uart;
ti,hwmods = uart4;
clock-frequency = 4800;
reg = 0x481a6000 0x2000;
@@ -252,7 +252,7 @@
};
uart4: serial@481a8000 {
- compatible = ti,omap3-uart;
+ compatible = ti,am3352-uart, ti,omap3-uart;
ti,hwmods = uart5;
clock-frequency = 4800;
reg = 0x481a8000 0x2000;
@@ -261,7 +261,7 @@
};
uart5: serial@481aa000 {
- compatible = ti,omap3-uart;
+ compatible = ti,am3352-uart, ti,omap3-uart;
ti,hwmods = uart6;
clock-frequency = 4800;
reg = 0x481aa000 0x2000;
diff --git a/drivers/tty/serial/8250/8250_omap.c
b/drivers/tty/serial/8250/8250_omap.c
index d9c96b993a84..52566387ec37 100644
--- a/drivers/tty/serial/8250/8250_omap.c
+++ b/drivers/tty/serial/8250/8250_omap.c
@@ -16,6 +16,7 @@
#include linux/platform_device.h
#include linux/slab.h
#include linux/of.h
+#include linux/of_device.h
#include linux/of_gpio.h
#include linux/of_irq.h
#include linux/delay.h
@@ -537,14 +538,14 @@ static void omap_serial_fill_features_erratas(struct
uart_8250_port *up,
switch (revision) {
case OMAP_UART_REV_46:
- priv-habit = UART_ERRATA_i202_MDR1_ACCESS;
+ priv-habit |= UART_ERRATA_i202_MDR1_ACCESS;
break;
case OMAP_UART_REV_52:
- priv-habit = UART_ERRATA_i202_MDR1_ACCESS |
+ priv-habit |= UART_ERRATA_i202_MDR1_ACCESS |
OMAP_UART_WER_HAS_TX_WAKEUP;
break;
case OMAP_UART_REV_63:
- priv-habit = UART_ERRATA_i202_MDR1_ACCESS |
+ priv-habit |= UART_ERRATA_i202_MDR1_ACCESS |
[PATCH 2/7] Documentation: DT: omap_serial: document missing compatible
The compatible ti,am4372-uart is used in arch/arm/boot/dts/am4372.dtsi but not documented. Add necessary documentation. Signed-off-by: Sekhar Nori nsek...@ti.com --- Documentation/devicetree/bindings/serial/omap_serial.txt | 1 + 1 file changed, 1 insertion(+) diff --git a/Documentation/devicetree/bindings/serial/omap_serial.txt b/Documentation/devicetree/bindings/serial/omap_serial.txt index 54c2a155c783..d3bd2b1ec401 100644 --- a/Documentation/devicetree/bindings/serial/omap_serial.txt +++ b/Documentation/devicetree/bindings/serial/omap_serial.txt @@ -4,6 +4,7 @@ Required properties: - compatible : should be ti,omap2-uart for OMAP2 controllers - compatible : should be ti,omap3-uart for OMAP3 controllers - compatible : should be ti,omap4-uart for OMAP4 controllers +- compatible : should be ti,am4372-uart for AM437x controllers - reg : address and length of the register space - interrupts or interrupts-extended : Should contain the uart interrupt specifier or both the interrupt -- 2.4.4.408.g16da57c -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH RESEND 1/7] tty: serial: 8250: omap: fix kernel crash in suspend-to-ram
omap_device infrastructure has a suspend_noirq hook which
runtime suspends all devices late in the suspend cycle (see
_od_suspend_noirq() in arch/arm/mach-omap2/omap_device.c)
This leads to a NULL pointer exception in 8250_omap driver
since by the time omap8250_runtime_suspend() is called, 8250_dma
driver has already set rxchan to NULL via serial8250_release_dma().
Make an explicit check to see if rxchan is NULL in
runtime_{suspend|resume} hooks to fix this.
Signed-off-by: Sekhar Nori nsek...@ti.com
---
Previous version: http://www.spinics.net/lists/linux-omap/msg119459.html
No change in this version except rebased to v4.2-rc1
drivers/tty/serial/8250/8250_omap.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/tty/serial/8250/8250_omap.c
b/drivers/tty/serial/8250/8250_omap.c
index d75a66c72750..20c5b9c4c288 100644
--- a/drivers/tty/serial/8250/8250_omap.c
+++ b/drivers/tty/serial/8250/8250_omap.c
@@ -1285,7 +1285,7 @@ static int omap8250_runtime_suspend(struct device *dev)
return -EBUSY;
}
- if (up-dma)
+ if (up-dma up-dma-rxchan)
omap_8250_rx_dma(up, UART_IIR_RX_TIMEOUT);
priv-latency = PM_QOS_CPU_DMA_LAT_DEFAULT_VALUE;
@@ -1310,7 +1310,7 @@ static int omap8250_runtime_resume(struct device *dev)
if (loss_cntx)
omap8250_restore_regs(up);
- if (up-dma)
+ if (up-dma up-dma-rxchan)
omap_8250_rx_dma(up, 0);
priv-latency = priv-calc_latency;
--
2.4.4.408.g16da57c
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 3/7] tty: 8250: omap: introduce function to update mdr1
updating mdr1 register on OMAP needs to take care of
errata i202. Introduce a function to update mdr1.
This will be useful later on when mdr1 needs to be
written to from other places. No functional change.
Signed-off-by: Sekhar Nori nsek...@ti.com
---
drivers/tty/serial/8250/8250_omap.c | 17 -
1 file changed, 12 insertions(+), 5 deletions(-)
diff --git a/drivers/tty/serial/8250/8250_omap.c
b/drivers/tty/serial/8250/8250_omap.c
index 20c5b9c4c288..d9c96b993a84 100644
--- a/drivers/tty/serial/8250/8250_omap.c
+++ b/drivers/tty/serial/8250/8250_omap.c
@@ -232,6 +232,15 @@ static void omap8250_update_scr(struct uart_8250_port *up,
serial_out(up, UART_OMAP_SCR, priv-scr);
}
+static void omap8250_update_mdr1(struct uart_8250_port *up,
+struct omap8250_priv *priv)
+{
+ if (priv-habit UART_ERRATA_i202_MDR1_ACCESS)
+ omap_8250_mdr1_errataset(up, priv);
+ else
+ serial_out(up, UART_OMAP_MDR1, priv-mdr1);
+}
+
static void omap8250_restore_regs(struct uart_8250_port *up)
{
struct omap8250_priv *priv = up-port.private_data;
@@ -282,11 +291,9 @@ static void omap8250_restore_regs(struct uart_8250_port
*up)
serial_out(up, UART_XOFF1, priv-xoff);
serial_out(up, UART_LCR, up-lcr);
- /* need mode A for FCR */
- if (priv-habit UART_ERRATA_i202_MDR1_ACCESS)
- omap_8250_mdr1_errataset(up, priv);
- else
- serial_out(up, UART_OMAP_MDR1, priv-mdr1);
+
+ omap8250_update_mdr1(up, priv);
+
up-port.ops-set_mctrl(up-port, up-port.mctrl);
}
--
2.4.4.408.g16da57c
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 0/3] ARM: OMAP2+: dra7: Fix DCAN1 stuck-in-transition
Paul/Tony, Any comments on this series? We need this for DCAN and core retention to work together for v4.3. cheers, -roger On 23/06/15 15:09, Roger Quadros wrote: Hi, On DRA7 platform, DCAN1 module has an issue when it's clockdomain (WKUPAON) is configured in HW_AUTO. After DCAN1 is enabled and disabled the module remains stuck in transition. Suggested workaround by Silicon team is to disable HW_AUTO for WKUPAON clockdomain when DCAN1 module is active. These patches provide a new flag for hwmod data to support this behaviour and fix up dra7 hwmod data as well to fix this issue on dra7x-evms. This patch allows DCAN1 to be functional as well as not prevent Core Retention as WKUPAON clockdomain is put back into HW_AUTO whenever DCAN1 is not active (e.g. runtime suspended). cheers, -roger Roger Quadros (3): ARM: OMAP2+: clockdomain: Add mechanism for disabling HW_AUTO ARM: OMAP2+ hwmod: Allow modules to disable HW_AUTO ARM: DRA7: hwmod: Fix DCAN1 stuck in transition arch/arm/mach-omap2/clockdomain.c | 71 +++ arch/arm/mach-omap2/clockdomain.h | 5 +++ arch/arm/mach-omap2/omap_hwmod.c | 14 +- arch/arm/mach-omap2/omap_hwmod.h | 1 + arch/arm/mach-omap2/omap_hwmod_7xx_data.c | 1 + 5 files changed, 90 insertions(+), 2 deletions(-) -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 7/7] ARM: dts: dra7: workaround UART module disable errata
Add ti,dra742-uart to the compatible list so the driver
workaround for UART module disable errata is enabled.
This does not break backward compatibility as existing DTBs
should continue to work with newer kernels albeit without the
capability of disabling the module when DMA is used.
Signed-off-by: Sekhar Nori nsek...@ti.com
---
arch/arm/boot/dts/dra7.dtsi | 20 ++--
1 file changed, 10 insertions(+), 10 deletions(-)
diff --git a/arch/arm/boot/dts/dra7.dtsi b/arch/arm/boot/dts/dra7.dtsi
index 8f1e25bcecbd..49940e516f0f 100644
--- a/arch/arm/boot/dts/dra7.dtsi
+++ b/arch/arm/boot/dts/dra7.dtsi
@@ -397,7 +397,7 @@
};
uart1: serial@4806a000 {
- compatible = ti,omap4-uart;
+ compatible = ti,dra742-uart, ti,omap4-uart;
reg = 0x4806a000 0x100;
interrupts-extended = crossbar_mpu GIC_SPI 67
IRQ_TYPE_LEVEL_HIGH;
ti,hwmods = uart1;
@@ -408,7 +408,7 @@
};
uart2: serial@4806c000 {
- compatible = ti,omap4-uart;
+ compatible = ti,dra742-uart, ti,omap4-uart;
reg = 0x4806c000 0x100;
interrupts = GIC_SPI 68 IRQ_TYPE_LEVEL_HIGH;
ti,hwmods = uart2;
@@ -419,7 +419,7 @@
};
uart3: serial@4802 {
- compatible = ti,omap4-uart;
+ compatible = ti,dra742-uart, ti,omap4-uart;
reg = 0x4802 0x100;
interrupts = GIC_SPI 69 IRQ_TYPE_LEVEL_HIGH;
ti,hwmods = uart3;
@@ -430,7 +430,7 @@
};
uart4: serial@4806e000 {
- compatible = ti,omap4-uart;
+ compatible = ti,dra742-uart, ti,omap4-uart;
reg = 0x4806e000 0x100;
interrupts = GIC_SPI 65 IRQ_TYPE_LEVEL_HIGH;
ti,hwmods = uart4;
@@ -441,7 +441,7 @@
};
uart5: serial@48066000 {
- compatible = ti,omap4-uart;
+ compatible = ti,dra742-uart, ti,omap4-uart;
reg = 0x48066000 0x100;
interrupts = GIC_SPI 100 IRQ_TYPE_LEVEL_HIGH;
ti,hwmods = uart5;
@@ -452,7 +452,7 @@
};
uart6: serial@48068000 {
- compatible = ti,omap4-uart;
+ compatible = ti,dra742-uart, ti,omap4-uart;
reg = 0x48068000 0x100;
interrupts = GIC_SPI 101 IRQ_TYPE_LEVEL_HIGH;
ti,hwmods = uart6;
@@ -463,7 +463,7 @@
};
uart7: serial@4842 {
- compatible = ti,omap4-uart;
+ compatible = ti,dra742-uart, ti,omap4-uart;
reg = 0x4842 0x100;
interrupts = GIC_SPI 218 IRQ_TYPE_LEVEL_HIGH;
ti,hwmods = uart7;
@@ -472,7 +472,7 @@
};
uart8: serial@48422000 {
- compatible = ti,omap4-uart;
+ compatible = ti,dra742-uart, ti,omap4-uart;
reg = 0x48422000 0x100;
interrupts = GIC_SPI 219 IRQ_TYPE_LEVEL_HIGH;
ti,hwmods = uart8;
@@ -481,7 +481,7 @@
};
uart9: serial@48424000 {
- compatible = ti,omap4-uart;
+ compatible = ti,dra742-uart, ti,omap4-uart;
reg = 0x48424000 0x100;
interrupts = GIC_SPI 220 IRQ_TYPE_LEVEL_HIGH;
ti,hwmods = uart9;
@@ -490,7 +490,7 @@
};
uart10: serial@4ae2b000 {
- compatible = ti,omap4-uart;
+ compatible = ti,dra742-uart, ti,omap4-uart;
reg = 0x4ae2b000 0x100;
interrupts = GIC_SPI 221 IRQ_TYPE_LEVEL_HIGH;
ti,hwmods = uart10;
--
2.4.4.408.g16da57c
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 5/7] tty: 8250: workaround errata on disabling UART after using DMA
AM335x, AM437x and DRA7x SoCs have an errata due to which UART
cannot be disabled after it has been used with DMA.
OMAP3 has a similar sounding errata which has been worked around
in a2fc36613ac1af2e9 (ARM: OMAP3: Use manual idle for UARTs
because of DMA errata). But the workaround used there does not
apply to AM335x, AM437x SoCs. These SoCs need a softreset of UART
before disabling them.
This patch implements that errata workaround. It is expected that
UART will be used with DMA so no explicit check for DMA usage
has been added for errata applicability.
Signed-off-by: Sekhar Nori nsek...@ti.com
---
drivers/tty/serial/8250/8250_omap.c | 55 +
1 file changed, 49 insertions(+), 6 deletions(-)
diff --git a/drivers/tty/serial/8250/8250_omap.c
b/drivers/tty/serial/8250/8250_omap.c
index 52566387ec37..af25869d145f 100644
--- a/drivers/tty/serial/8250/8250_omap.c
+++ b/drivers/tty/serial/8250/8250_omap.c
@@ -33,6 +33,11 @@
#define UART_ERRATA_i202_MDR1_ACCESS (1 0)
#define OMAP_UART_WER_HAS_TX_WAKEUP(1 1)
#define OMAP_DMA_TX_KICK (1 2)
+/*
+ * See Advisory 21 in AM437x errata SPRZ408B, updated April 2015.
+ * The same errata is applicable to AM335x and DRA7x processors too.
+ */
+#define UART_ERRATA_CLOCK_DISABLE (1 3)
#define OMAP_UART_FCR_RX_TRIG 6
#define OMAP_UART_FCR_TX_TRIG 4
@@ -54,6 +59,12 @@
#define OMAP_UART_MVR_MAJ_SHIFT8
#define OMAP_UART_MVR_MIN_MASK 0x3f
+/* SYSC register bitmasks */
+#define OMAP_UART_SYSC_SOFTRESET (1 1)
+
+/* SYSS register bitmasks */
+#define OMAP_UART_SYSS_RESETDONE (1 0)
+
#define UART_TI752_TLR_TX 0
#define UART_TI752_TLR_RX 4
@@ -1062,13 +1073,15 @@ static int omap8250_no_handle_irq(struct uart_port
*port)
return 0;
}
-static const u8 am3352_habit = OMAP_DMA_TX_KICK;
+static const u8 am3352_habit = OMAP_DMA_TX_KICK | UART_ERRATA_CLOCK_DISABLE;
+static const u8 am4372_habit = UART_ERRATA_CLOCK_DISABLE;
static const struct of_device_id omap8250_dt_ids[] = {
{ .compatible = ti,omap2-uart },
{ .compatible = ti,omap3-uart },
{ .compatible = ti,omap4-uart },
{ .compatible = ti,am3352-uart, .data = am3352_habit, },
+ { .compatible = ti,am4372-uart, .data = am4372_habit, },
{},
};
MODULE_DEVICE_TABLE(of, omap8250_dt_ids);
@@ -1279,13 +1292,13 @@ static int omap8250_lost_context(struct uart_8250_port
*up)
{
u32 val;
- val = serial_in(up, UART_OMAP_MDR1);
+ val = serial_in(up, UART_OMAP_SCR);
/*
-* If we lose context, then MDR1 is set to its reset value which is
-* UART_OMAP_MDR1_DISABLE. After set_termios() we set it either to 13x
-* or 16x but never to disable again.
+* If we lose context, then SCR is set to its reset value of zero.
+* After set_termios() we set bit 3 of SCR (TX_EMPTY_CTL_IT) to 1,
+* among other bits, to never set the register back to zero again.
*/
- if (val == UART_OMAP_MDR1_DISABLE)
+ if (!val)
return 1;
return 0;
}
@@ -1307,6 +1320,36 @@ static int omap8250_runtime_suspend(struct device *dev)
return -EBUSY;
}
+ if (priv-habit UART_ERRATA_CLOCK_DISABLE) {
+ int sysc;
+ int syss;
+ int timeout = 100;
+
+ sysc = serial_in(up, UART_OMAP_SYSC);
+
+ /* softreset the UART */
+ sysc |= OMAP_UART_SYSC_SOFTRESET;
+ serial_out(up, UART_OMAP_SYSC, sysc);
+
+ /* By experiments, 1us enough for reset complete on AM335x */
+ do {
+ udelay(1);
+ syss = serial_in(up, UART_OMAP_SYSS);
+ } while (--timeout !(syss OMAP_UART_SYSS_RESETDONE));
+
+ if (!timeout) {
+ dev_err(dev, timed out waiting for reset done\n);
+ return -ETIMEDOUT;
+ }
+
+ /*
+* For UART module wake-up to work, MDR1.MODESELECT should
+* not be set to Disable, so update it.
+*/
+ if (device_may_wakeup(dev))
+ omap8250_update_mdr1(up, priv);
+ }
+
if (up-dma up-dma-rxchan)
omap_8250_rx_dma(up, UART_IIR_RX_TIMEOUT);
--
2.4.4.408.g16da57c
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 6/7] tty: 8250: omap: workaround module disable errata on dra7x SoCs
Due to Advisory 21 as documented in AM437x errata document,
UART module cannot be disabled once DMA is used. The only
workaround is to softreset the module before disabling it.
DRA7x UARTs are compatible to AM437x UARTs in terms of
this errata and prescribed workaround.
Enable usage of workaround for this errata on DRA7x SoCs.
Signed-off-by: Sekhar Nori nsek...@ti.com
---
Documentation/devicetree/bindings/serial/omap_serial.txt | 1 +
drivers/tty/serial/8250/8250_omap.c | 1 +
2 files changed, 2 insertions(+)
diff --git a/Documentation/devicetree/bindings/serial/omap_serial.txt
b/Documentation/devicetree/bindings/serial/omap_serial.txt
index 0ee88209b341..7a71b5de77d6 100644
--- a/Documentation/devicetree/bindings/serial/omap_serial.txt
+++ b/Documentation/devicetree/bindings/serial/omap_serial.txt
@@ -6,6 +6,7 @@ Required properties:
- compatible : should be ti,omap4-uart for OMAP4 controllers
- compatible : should be ti,am4372-uart for AM437x controllers
- compatible : should be ti,am3352-uart for AM335x controllers
+- compatible : should be ti,dra742-uart for DRA7x controllers
- reg : address and length of the register space
- interrupts or interrupts-extended : Should contain the uart interrupt
specifier or both the interrupt
diff --git a/drivers/tty/serial/8250/8250_omap.c
b/drivers/tty/serial/8250/8250_omap.c
index af25869d145f..9811f0bcba25 100644
--- a/drivers/tty/serial/8250/8250_omap.c
+++ b/drivers/tty/serial/8250/8250_omap.c
@@ -1082,6 +1082,7 @@ static const struct of_device_id omap8250_dt_ids[] = {
{ .compatible = ti,omap4-uart },
{ .compatible = ti,am3352-uart, .data = am3352_habit, },
{ .compatible = ti,am4372-uart, .data = am4372_habit, },
+ { .compatible = ti,dra742-uart, .data = am4372_habit, },
{},
};
MODULE_DEVICE_TABLE(of, omap8250_dt_ids);
--
2.4.4.408.g16da57c
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] thermal: consistently use int for temperatures
Hi Sascha, The thermal code uses int, long and unsigned long for temperatures in different places. Using an unsigned type limits the thermal framework to positive temperatures without need. Also several drivers currently will report temperatures near UINT_MAX for temperatures below 0°C. This will probably immediately shut the machine down due to overtemperature if started below 0°C. 'long' is 64bit on several architectures. This is not needed since INT_MAX °mC is above the melting point of all known materials. Consistently use a plain 'int' for temperatures throughout the thermal code and the drivers. This only changes the places in the drivers where the temperature is passed around as pointer, when drivers internally use another type this is not changed. Signed-off-by: Sascha Hauer s.ha...@pengutronix.de Sascha, thanks for this cleanup work. Reviewed-by: Lukasz Majewski l.majew...@samsung.com -- Best regards, Lukasz Majewski Samsung RD Institute Poland (SRPOL) | Linux Platform Group -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 08/10] crypto: omap-aes: gmc: Add algo info
On Thu, Jul 02, 2015 at 10:48:38AM +0530, Lokesh Vutla wrote: Now the driver supports gcm mode, add omap-aes-gcm algo info to omap-aes driver. Signed-off-by: Lokesh Vutla lokeshvu...@ti.com You're using the old AEAD interface. We are now moving to the new AEAD interface so I will not be accepting any new implementations using the old interface. Please convert your driver over to the new interface. Also please merge your GCM patches into a single patch. Splitting out bug fixes makes no sense. Thanks, -- Email: Herbert Xu herb...@gondor.apana.org.au Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 10/10] crypto: tcrypt: Added speed tests for Async AEAD crypto alogrithms
On Mon, Jul 06, 2015 at 02:15:06PM +0530, Lokesh Vutla wrote: The existing AEAD test case does not do a wait_for_completion(), when the return value is EINPROGRESS or EBUSY like it is done for acipher_speed tests. Please fix them to do the wait. Thanks, -- Email: Herbert Xu herb...@gondor.apana.org.au Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH gpio-for-next 08/10] usb: dwc3: pci: make better use of gpiod API
Since 39b2bbe3d715 (gpio: add flags argument to gpiod_get*() functions)
which appeared in v3.17-rc1, the gpiod_get* functions take an additional
parameter that allows to specify direction and initial value for output.
Use this additional parameter and the _optional variant to simplify the
driver and improve error handling. Also expand the comment to explain
why it's not sensible to switch to devm_gpiod_get and why the gpiod_put
is also necessary.
Furthermore this is one caller less that stops us making the flags
argument to gpiod_get*() mandatory.
Tested-by: Heikki Krogerus heikki.kroge...@linux.intel.com
Signed-off-by: Uwe Kleine-König u.kleine-koe...@pengutronix.de
---
drivers/usb/dwc3/dwc3-pci.c | 26 --
1 file changed, 16 insertions(+), 10 deletions(-)
diff --git a/drivers/usb/dwc3/dwc3-pci.c b/drivers/usb/dwc3/dwc3-pci.c
index 27e4fc896e9d..f62617999f3c 100644
--- a/drivers/usb/dwc3/dwc3-pci.c
+++ b/drivers/usb/dwc3/dwc3-pci.c
@@ -83,17 +83,23 @@ static int dwc3_pci_quirks(struct pci_dev *pdev)
acpi_dev_add_driver_gpios(ACPI_COMPANION(pdev-dev),
acpi_dwc3_byt_gpios);
- /* These GPIOs will turn on the USB2 PHY */
- gpio = gpiod_get(pdev-dev, cs);
- if (!IS_ERR(gpio)) {
- gpiod_direction_output(gpio, 0);
- gpiod_set_value_cansleep(gpio, 1);
- gpiod_put(gpio);
- }
+ /*
+* These GPIOs will turn on the USB2 PHY. Note that we have to
+* put the gpio descriptors again here because the phy driver
+* might want to grab them, too.
+*/
+ gpio = gpiod_get_optional(pdev-dev, cs, GPIOD_OUT_LOW);
+ if (IS_ERR(gpio))
+ return PTR_ERR(gpio);
+
+ gpiod_set_value_cansleep(gpio, 1);
+ gpiod_put(gpio);
+
+ gpio = gpiod_get_optional(pdev-dev, reset, GPIOD_OUT_LOW);
+ if (IS_ERR(gpio))
+ return PTR_ERR(gpio);
- gpio = gpiod_get(pdev-dev, reset);
- if (!IS_ERR(gpio)) {
- gpiod_direction_output(gpio, 0);
+ if (gpio) {
gpiod_set_value_cansleep(gpio, 1);
gpiod_put(gpio);
usleep_range(1, 11000);
--
2.1.4
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 01/10] crypto: omap-aes: Add support for lengths not aligned with AES_BLOCK_SIZE
On Thu, Jul 02, 2015 at 10:48:31AM +0530, Lokesh Vutla wrote: OMAP AES driver returns an error if the data is not aligned with AES_BLOCK_SIZE bytes. But OMAP AES hw allows data input upto 1 byte aligned, but still zeros are to be appended and complete AES_BLOCK_SIZE has to be written. And correct length has to be passed in LENGTH field. Adding support for inputs not aligned with AES_BLOCK_SIZE. Signed-off-by: Lokesh Vutla lokeshvu...@ti.com Please explain the purpose of this patch. As it stands your change log makes no sense. If you're relaxing the check for GCM support then you should state that explicitly. Because partial blocks make no sense otherwise. Cheers, -- Email: Herbert Xu herb...@gondor.apana.org.au Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 08/10] crypto: omap-aes: gmc: Add algo info
Hi, On Monday 06 July 2015 01:05 PM, Herbert Xu wrote: On Thu, Jul 02, 2015 at 10:48:38AM +0530, Lokesh Vutla wrote: Now the driver supports gcm mode, add omap-aes-gcm algo info to omap-aes driver. Signed-off-by: Lokesh Vutla lokeshvu...@ti.com You're using the old AEAD interface. We are now moving to the new AEAD interface so I will not be accepting any new implementations using the old interface. Please convert your driver over to the new interface. Will convert omap-aes driver to new interface and repost. Thanks and regards, Lokesh Also please merge your GCM patches into a single patch. Splitting out bug fixes makes no sense. Thanks, -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] clocksource: Allow toggling between runtime and persistent clocksource for idle
Some persistent clocksources can be on a slow external bus. For shorter
latencies for RT use, let's allow toggling the clocksource during idle
between a faster non-persistent runtime clocksource and a slower persistent
clocksource.
Cc: Felipe Balbi ba...@ti.com
Cc: John Stultz john.stu...@linaro.org
Cc: Nishanth Menon n...@ti.com
Cc: Thomas Gleixner t...@linutronix.de
Cc: Yingjoe Chen yingjoe.c...@mediatek.com
Cc: Rafael J. Wysocki rafael.j.wyso...@intel.com
Cc: Peter Zijlstra pet...@infradead.org
Signed-off-by: Tony Lindgren t...@atomide.com
---
Anybody got better ideas for something like last_idled_cpu() type check
at the end of this patch?
---
include/linuxt-email-lkml-omap/clocksource.h | 2 ++
kernel/time/clocksource.c | 60 +++--
kernel/time/timekeeping.c | 13 +-
3 files changed, 72 insertions(+), 3 deletions(-)
diff --git a/include/linux/clocksource.h b/include/linux/clocksource.h
index 278dd27..7e5ff99 100644
--- a/include/linux/clocksource.h
+++ b/include/linux/clocksource.h
@@ -232,6 +232,8 @@ static inline void __clocksource_update_freq_khz(struct
clocksource *cs, u32 khz
extern int timekeeping_notify(struct clocksource *clock);
+extern int clocksource_pm_enter(void);
+extern void clocksource_pm_exit(void);
extern cycle_t clocksource_mmio_readl_up(struct clocksource *);
extern cycle_t clocksource_mmio_readl_down(struct clocksource *);
diff --git a/kernel/time/clocksource.c b/kernel/time/clocksource.c
index 841b72f..69dc307 100644
--- a/kernel/time/clocksource.c
+++ b/kernel/time/clocksource.c
@@ -93,6 +93,8 @@ clocks_calc_mult_shift(u32 *mult, u32 *shift, u32 from, u32
to, u32 maxsec)
/*[Clocksource internal variables]-
* curr_clocksource:
* currently selected clocksource.
+ * runtime_clocksource:
+ * preferred clocksource for runtime, can be local and non-persistent
* clocksource_list:
* linked list with the registered clocksources
* clocksource_mutex:
@@ -101,6 +103,7 @@ clocks_calc_mult_shift(u32 *mult, u32 *shift, u32 from, u32
to, u32 maxsec)
* Name of the user-specified clocksource.
*/
static struct clocksource *curr_clocksource;
+static struct clocksource *runtime_clocksource;
static LIST_HEAD(clocksource_list);
static DEFINE_MUTEX(clocksource_mutex);
static char override_name[CS_NAME_LEN];
@@ -525,7 +528,8 @@ static inline void clocksource_update_max_deferment(struct
clocksource *cs)
#ifndef CONFIG_ARCH_USES_GETTIMEOFFSET
-static struct clocksource *clocksource_find_best(bool oneshot, bool skipcur)
+static struct clocksource *clocksource_find_best(bool oneshot, bool persistent,
+bool skipcur)
{
struct clocksource *cs;
@@ -540,6 +544,8 @@ static struct clocksource *clocksource_find_best(bool
oneshot, bool skipcur)
list_for_each_entry(cs, clocksource_list, list) {
if (skipcur cs == curr_clocksource)
continue;
+ if (persistent !(cs-flags CLOCK_SOURCE_SUSPEND_NONSTOP))
+ continue;
if (oneshot !(cs-flags CLOCK_SOURCE_VALID_FOR_HRES))
continue;
return cs;
@@ -553,7 +559,7 @@ static void __clocksource_select(bool skipcur)
struct clocksource *best, *cs;
/* Find the best suitable clocksource */
- best = clocksource_find_best(oneshot, skipcur);
+ best = clocksource_find_best(oneshot, false, skipcur);
if (!best)
return;
@@ -802,6 +808,56 @@ int clocksource_unregister(struct clocksource *cs)
}
EXPORT_SYMBOL(clocksource_unregister);
+/**
+ * clocksource_pm_enter - change to a persistent clocksource before idle
+ *
+ * Changes system to use a persistent clocksource for idle. Intended to
+ * be called from CPUidle from the last active CPU.
+ */
+int clocksource_pm_enter(void)
+{
+ bool oneshot = tick_oneshot_mode_active();
+ struct clocksource *best;
+
+ if (WARN_ONCE(!mutex_trylock(clocksource_mutex),
+ Unable to get clocksource_mutex))
+ return -EINTR;
+
+ best = clocksource_find_best(oneshot, true, false);
+ if (best) {
+ if (curr_clocksource != best
+ !timekeeping_notify(best)) {
+ runtime_clocksource = curr_clocksource;
+ curr_clocksource = best;
+ }
+ }
+ mutex_unlock(clocksource_mutex);
+
+ return !!best;
+}
+
+/**
+ * clocksource_pm_exit - change to a runtime clocksrouce after idle
+ *
+ * Changes system to use the best clocksource for runtime. Intended to
+ * be called after waking up from CPUidle on the first active CPU.
+ */
+void clocksource_pm_exit(void)
+{
+ if (WARN_ONCE(!mutex_trylock(clocksource_mutex),
+ Unable to get clocksource_mutex))
+ return;
+
+ if (runtime_clocksource) {
+
Re: [PATCH 04/10] crypto: omap-aes: Use BIT() macro
On Thu, Jul 02, 2015 at 02:59:03AM -0500, Felipe Balbi wrote: On Thu, Jul 02, 2015 at 10:48:34AM +0530, Lokesh Vutla wrote: Use BIT()/GENMASK() macros for all register definitions instead of hand-writing bit masks. Signed-off-by: Lokesh Vutla lokeshvu...@ti.com --- drivers/crypto/omap-aes.c | 36 ++-- 1 file changed, 18 insertions(+), 18 deletions(-) diff --git a/drivers/crypto/omap-aes.c b/drivers/crypto/omap-aes.c index 96fc7f7..d974ab6 100644 --- a/drivers/crypto/omap-aes.c +++ b/drivers/crypto/omap-aes.c @@ -52,30 +52,30 @@ #define AES_REG_IV(dd, x) ((dd)-pdata-iv_ofs + ((x) * 0x04)) #define AES_REG_CTRL(dd) ((dd)-pdata-ctrl_ofs) -#define AES_REG_CTRL_CTR_WIDTH_MASK(3 7) -#define AES_REG_CTRL_CTR_WIDTH_32 (0 7) -#define AES_REG_CTRL_CTR_WIDTH_64 (1 7) -#define AES_REG_CTRL_CTR_WIDTH_96 (2 7) -#define AES_REG_CTRL_CTR_WIDTH_128 (3 7) -#define AES_REG_CTRL_CTR (1 6) -#define AES_REG_CTRL_CBC (1 5) -#define AES_REG_CTRL_KEY_SIZE (3 3) -#define AES_REG_CTRL_DIRECTION (1 2) -#define AES_REG_CTRL_INPUT_READY (1 1) -#define AES_REG_CTRL_OUTPUT_READY (1 0) -#define AES_REG_CTRL_MASK FLD_MASK(24, 2) +#define AES_REG_CTRL_CTR_WIDTH_MASKGENMASK(8, 7) +#define AES_REG_CTRL_CTR_WIDTH_32 0 +#define AES_REG_CTRL_CTR_WIDTH_64 BIT(7) +#define AES_REG_CTRL_CTR_WIDTH_96 BIT(8) +#define AES_REG_CTRL_CTR_WIDTH_128 GENMASK(8, 7) +#define AES_REG_CTRL_CTR BIT(6) +#define AES_REG_CTRL_CBC BIT(5) +#define AES_REG_CTRL_KEY_SIZE GENMASK(4, 3) +#define AES_REG_CTRL_DIRECTION BIT(2) +#define AES_REG_CTRL_INPUT_READY BIT(1) +#define AES_REG_CTRL_OUTPUT_READY BIT(0) +#define AES_REG_CTRL_MASK GENMASK(24, 2) this was defined a couple patches ago, why didn't you define it with GENMASK() to start with ? Indeed, this should be folded into the earlier patch. Thanks, -- Email: Herbert Xu herb...@gondor.apana.org.au Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] crypto: omap-des: Fix unmapping of dma channels
On Thu, Jul 02, 2015 at 06:33:28PM +0530, Lokesh Vutla wrote: dma_unmap_sg() is being called twice after completing the task. Looks like this is a copy paste error when creating des driver. With this the following warn appears during boot: [4.210457] [ cut here ] [4.215114] WARNING: CPU: 0 PID: 0 at lib/dma-debug.c:1080 check_unmap+0x710/0x9a0() [4.222899] omap-des 480a5000.des: DMA-API: device driver tries to free DMA memory it has not allocated [device address=0xab2ce000] [size=8 bytes] [4.236785] Modules linked in: [4.239860] CPU: 0 PID: 0 Comm: swapper/0 Not tainted 3.14.39-02999-g1bc045a-dirty #182 [4.247918] [c001678c] (unwind_backtrace) from [c0012574] (show_stack+0x10/0x14) [4.255710] [c0012574] (show_stack) from [c05a37e8] (dump_stack+0x84/0xb8) [4.262977] [c05a37e8] (dump_stack) from [c0046464] (warn_slowpath_common+0x68/0x8c) [4.271107] [c0046464] (warn_slowpath_common) from [c004651c] (warn_slowpath_fmt+0x30/0x40) [4.279854] [c004651c] (warn_slowpath_fmt) from [c02d50a4] (check_unmap+0x710/0x9a0) [4.287991] [c02d50a4] (check_unmap) from [c02d5478] (debug_dma_unmap_sg+0x90/0x19c) [4.296128] [c02d5478] (debug_dma_unmap_sg) from [c04a77d8] (omap_des_done_task+0x1cc/0x3e4) [4.304963] [c04a77d8] (omap_des_done_task) from [c004a090] (tasklet_action+0x84/0x124) [4.313370] [c004a090] (tasklet_action) from [c004a4ac] (__do_softirq+0xf0/0x20c) [4.321235] [c004a4ac] (__do_softirq) from [c004a840] (irq_exit+0x98/0xec) [4.328500] [c004a840] (irq_exit) from [c000f9ac] (handle_IRQ+0x50/0xb0) [4.335589] [c000f9ac] (handle_IRQ) from [c0008688] (gic_handle_irq+0x28/0x5c) Removing the duplicate call to dma_unmap_sg(). Reported-by: Tomi Valkeinen tomi.valkei...@ti.com Signed-off-by: Lokesh Vutla lokeshvu...@ti.com Applied to crypto. -- Email: Herbert Xu herb...@gondor.apana.org.au Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 03/10] crypto: aead: Add aead_request_cast() api
On Thu, Jul 02, 2015 at 10:48:33AM +0530, Lokesh Vutla wrote:
Add aead_request_cast() api to get pointer to aead_request
from cryto_async_request.
Signed-off-by: Lokesh Vutla lokeshvu...@ti.com
---
include/linux/crypto.h |6 ++
1 file changed, 6 insertions(+)
diff --git a/include/linux/crypto.h b/include/linux/crypto.h
index 10df5d2..20fac3d 100644
--- a/include/linux/crypto.h
+++ b/include/linux/crypto.h
@@ -1460,6 +1460,12 @@ static inline void aead_request_set_tfm(struct
aead_request *req,
req-base.tfm = crypto_aead_tfm(crypto_aead_crt(tfm)-base);
}
+static inline struct aead_request *aead_request_cast(
+ struct crypto_async_request *req)
+{
+ return container_of(req, struct aead_request, base);
+}
+
This should go into include/crypto/internal/aead.h.
Thanks,
--
Email: Herbert Xu herb...@gondor.apana.org.au
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 2/2] ARM: dts: am4372: Add emif node
* Tony Lindgren t...@atomide.com [150602 13:00]: * Felipe Balbi ba...@ti.com [150602 12:26]: On Wed, May 06, 2015 at 12:25:33PM -0500, Dave Gerlach wrote: Add node for TI AM4372 EMIF. Signed-off-by: Dave Gerlach d-gerl...@ti.com Tony, this patch fixes the regression I just reported at [1], care to pick this one up ? OK thanks yes tag this for v4.2 fixes. With the merge window now over, applying into omap-for-v4.2/fixes. Tony -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2] ARM: dts: am57xx-beagle-x15: Provide supply for usb2_phy2
* Roger Quadros rog...@ti.com [150617 07:54]:
Without this USB2 breaks if USB1 is disabled or USB1
initializes after USB2 e.g. due to deferred probing.
Fixes: 5a0f93c6576a (ARM: dts: Add am57xx-beagle-x15)
Signed-off-by: Roger Quadros rog...@ti.com
Cc: sta...@vger.kernel.org (v3.19+)
Applying into omap-for-v4.2/fixes thanks.
Tony
---
arch/arm/boot/dts/am57xx-beagle-x15.dts | 4
1 file changed, 4 insertions(+)
diff --git a/arch/arm/boot/dts/am57xx-beagle-x15.dts
b/arch/arm/boot/dts/am57xx-beagle-x15.dts
index 7128fad..c9df40e 100644
--- a/arch/arm/boot/dts/am57xx-beagle-x15.dts
+++ b/arch/arm/boot/dts/am57xx-beagle-x15.dts
@@ -544,6 +544,10 @@
phy-supply = ldousb_reg;
};
+usb2_phy2 {
+ phy-supply = ldousb_reg;
+};
+
usb1 {
dr_mode = host;
pinctrl-names = default;
--
2.1.4
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RESEND] [PATCH v2 1/2] arm: devtree: Set system_rev from DT revision
On Thursday 25 June 2015 07:01:38 Tony Lindgren wrote: * Pali Rohár pali.ro...@gmail.com [150506 04:45]: On Wednesday 06 May 2015 13:04:01 Arnd Bergmann wrote: It needs to be done in this code, so system_rev variable is set properly... What I mean is which code accesses this variable that early? ATAG code is doing it at same early stage, so I added it to same early stage... Yes we should do this early like the other atags. Also, it seems strange to have a string property and then use kstrtouint to convert it into a number. I think it should either be specified in a DT binding to be a string and then have the kernel not assume that it is a number, or we should define it to be binary. Arnd Variable system_rev is number and it always was. So chaning type will break more parts. And it is string DT property to be human readable. Some other developers suggested for v2 to change it to string (from number). Both of them would be human readable, you just use something else to read them ;-) If we have a string here, we should just change all uses of system_rev in the kernel accordingly, there are only a few of them: Let's just keep it as a hex as it was. After all it's an existing interface in /proc that user space programs may expect to be in hex format already. Pali, care to repost the whole set again right after -rc1 with with rev property naming and documentation added? Just keep it as hex and let's forget any string conversion. Regards, Tony Hello Tony, into which file should I put documentation about new DT properties? -- Pali Rohár pali.ro...@gmail.com signature.asc Description: This is a digitally signed message part.
[PATCH] extcon: Fix kernel hang for find_cable_index_by_name() users
Users of find_cable_index_by_name() will cause a kernel hang as the while loop counter is never incremented and end condition is never reached. Fixes: commit 73b6ecdb93e8 (extcon: Redefine the unique id of supported external connectors without 'enum extcon' type) Cc: Greg Kroah-Hartman gre...@linuxfoundation.org Signed-off-by: Roger Quadros rog...@ti.com --- drivers/extcon/extcon.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/drivers/extcon/extcon.c b/drivers/extcon/extcon.c index 76157ab..1acc830 100644 --- a/drivers/extcon/extcon.c +++ b/drivers/extcon/extcon.c @@ -138,6 +138,8 @@ static int find_cable_index_by_name(struct extcon_dev *edev, const char *name) id = i; break; } + + i++; } if (id == EXTCON_NONE) -- 2.1.4 -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RESEND] [PATCH v2 1/2] arm: devtree: Set system_rev from DT revision
* Pali Rohár pali.ro...@gmail.com [150706 05:25]: into which file should I put documentation about new DT properties? If it's Linux generic like linux,revision, then how about Documentation/devicetree/bindings/revision.txt? For the ATAGs, Documentation/devicetree/bindings/arm/atag.txt? Regards, Tony -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] Revert ARM: dts: am335x-boneblack: disable RTC-only sleep
* Johan Hovold jo...@kernel.org [150611 07:20]: This reverts commit 3d76be5b933e2a66d85a2f7444e68e99e8a48ad4. The latest revision of Beaglebone Black does not support RTC-only mode. To avoid potential hardware damage, RTC-only mode was disabled by default by commit 7a6cb0abe1aa (ARM: dts: am335x-boneblack: disable RTC-only sleep to avoid hardware damage). Unfortunately, an incorrect fix had already been applied, which instead of just disabling RTC-only mode, prevents the Beaglebone from powering down at all. Revert this patch to fix the power-off regression. Signed-off-by: Johan Hovold jo...@kernel.org --- The offending patch was incorrectly applied after Matthijs initial fix was posted and before the final fix (which only added some comments) was applied. Note that the final version of the fix 7a6cb0abe1aa (ARM: dts: am335x-boneblack: disable RTC-only sleep to avoid hardware damage) indicates that it should be backported to 3.12 even though RTC-only mode was first enabled in 3.19. Applying this now into omap-for-v4.2/fixes. Regards, Tony -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] ARM: dts: am4372.dtsi: disable rfbi
* Tomi Valkeinen tomi.valkei...@ti.com [150630 05:07]: When DSS nodes were added to am4372.dtsi, the rfbi node was not marked as disabled. This should have been done, as the rule of thumb is to disable all DSS nodes that are not used, and especially rfbi, as we don't have a driver for rfbi. Signed-off-by: Tomi Valkeinen tomi.valkei...@ti.com Applying into omap-for-v4.2/fixes thanks. Tony --- arch/arm/boot/dts/am4372.dtsi | 1 + 1 file changed, 1 insertion(+) diff --git a/arch/arm/boot/dts/am4372.dtsi b/arch/arm/boot/dts/am4372.dtsi index c80a3e233792..75831e556741 100644 --- a/arch/arm/boot/dts/am4372.dtsi +++ b/arch/arm/boot/dts/am4372.dtsi @@ -941,6 +941,7 @@ ti,hwmods = dss_rfbi; clocks = disp_clk; clock-names = fck; + status = disabled; }; }; -- 2.1.4 -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RESEND] [PATCH v2 1/2] arm: devtree: Set system_rev from DT revision
On Monday 06 July 2015 14:31:27 Tony Lindgren wrote: * Pali Rohár pali.ro...@gmail.com [150706 05:25]: into which file should I put documentation about new DT properties? If it's Linux generic like linux,revision, then how about Documentation/devicetree/bindings/revision.txt? For the ATAGs, Documentation/devicetree/bindings/arm/atag.txt? Regards, Tony Hm... now I'm thinking into which DT field should I put atags and revision. In previous emails you wrote to use linux,atags, now arm,atags? And put them into root node? Or other? In arch/arm/boot/compressed/atags_to_fdt.c code I see that most atag properties are converted into /chosen node in DT... So what do you prefer for revision and what for atags? Some mentioned examples: /revision /chosen/revision /linux,revision /chosen/linux,revision ... /atags /chosen/atags /linux,atags /chosen/linux,atags /arm,atags /chosen/arm,atags ... -- Pali Rohár pali.ro...@gmail.com signature.asc Description: This is a digitally signed message part.
Re: [PATCH] extcon: Fix kernel hang for find_cable_index_by_name() users
Hi, On 06/07/15 15:31, Roger Quadros wrote: Users of find_cable_index_by_name() will cause a kernel hang as the while loop counter is never incremented and end condition is never reached. Fixes: commit 73b6ecdb93e8 (extcon: Redefine the unique id of supported external connectors without 'enum extcon' type) Cc: Greg Kroah-Hartman gre...@linuxfoundation.org Signed-off-by: Roger Quadros rog...@ti.com Please ignore this patch. The extcon framework is broken bad in v4.2 and this patch is not sufficient to fix it. I will send another patch that fixes the issues that I'm facing in a while. cheers, -roger --- drivers/extcon/extcon.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/drivers/extcon/extcon.c b/drivers/extcon/extcon.c index 76157ab..1acc830 100644 --- a/drivers/extcon/extcon.c +++ b/drivers/extcon/extcon.c @@ -138,6 +138,8 @@ static int find_cable_index_by_name(struct extcon_dev *edev, const char *name) id = i; break; } + + i++; } if (id == EXTCON_NONE) -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 0/2] dmaengine: ti-dma-crossbar: Support for eDMA
On Fri, Jul 03, 2015 at 05:10:46PM +0300, Peter Ujfalusi wrote: On 07/02/2015 06:56 PM, Vinod Koul wrote: On Wed, Jul 01, 2015 at 03:41:26PM +0300, Peter Ujfalusi wrote: Hi, On 06/08/2015 04:22 PM, Peter Ujfalusi wrote: Hi, Changes since v01: - Drop change in compatible for the crossbar driver and do the configuration based on the DT structure. The ti-dma-crossbar driver in it's current form can work when it is used with sDMA (omap-dma). On DRA7x class of devices we have both sDMA and eDMA available. The sDMA driver expects to get the DMA request line with offset 1. The eDMA stack does not need the offset. The crosbbar itself is identical for sDMA and eDMA. At probe time the driver will do a match to figure out which dma engine it is connected to and based on that information it will configure the offset needed by the DMA driver. Gentle ping, it has been almost a month ago this series has been sent. Sorry I seem to have missed this series. I relooked at this and it looks fine. I will apply it once rc1 is out. If it needs rebase please resend No problem, the patch still applies cleanly. No luck, I tried on -rc1 an 1st fails, can you please rebase and resend -- ~Vinod -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: USB Ethernet gadget on Nokia n900
On Tuesday 28 October 2014 23:26:41 Tony Lindgren wrote: * Pavel Machek pa...@ucw.cz [141028 15:22]: On Tue 2014-10-28 23:04:50, Pavel Machek wrote: Hi! Here's a patch that should fix the issues for built-in USB gadgets. Pavel, care to see if this gets NFSroot over USB working again for you? It seems to have did the trick for me. (Plus I needed to add +CONFIG_ARM_ATAG_DTB_COMPAT=y +CONFIG_ARM_ATAG_DTB_COMPAT_CMDLINE_FROM_BOOTLOADER=y +# CONFIG_ARM_ATAG_DTB_COMPAT_CMDLINE_EXTEND is not set to be able to control the command line, that's why testing took me a while.) Networking now works against 3.17-based kernel. Thanks! It works on 3.18-rc1 kernel, too. (I had to hand-modify patch to apply to 3.17, no changes needed for 3.18-rc1.) Tested-by: Pavel Machek pa...@ucw.cz Whatever we decice to do to fix this regression, it should probably be backported to at least v3.16 stable for distro use, maybe earlier too. I'd assume this is broken on multiple platforms currently. Regards, Tony Hi Tony, it looks like this patch was not included into any kernel version... I'm still using it on top of 4.x kernels. Are you going to send this patch into upstream? Or do you have another fix for this problem? -- Pali Rohár pali.ro...@gmail.com signature.asc Description: This is a digitally signed message part.
Re: USB Ethernet gadget on Nokia n900
* Pali Rohár pali.ro...@gmail.com [150706 06:27]: On Tuesday 28 October 2014 23:26:41 Tony Lindgren wrote: * Pavel Machek pa...@ucw.cz [141028 15:22]: On Tue 2014-10-28 23:04:50, Pavel Machek wrote: Networking now works against 3.17-based kernel. Thanks! It works on 3.18-rc1 kernel, too. (I had to hand-modify patch to apply to 3.17, no changes needed for 3.18-rc1.) Tested-by: Pavel Machek pa...@ucw.cz Whatever we decice to do to fix this regression, it should probably be backported to at least v3.16 stable for distro use, maybe earlier too. I'd assume this is broken on multiple platforms currently. it looks like this patch was not included into any kernel version... I'm still using it on top of 4.x kernels. Are you going to send this patch into upstream? Or do you have another fix for this problem? I think Felipe mentioned a better built-in gether fix that's been reviewed on linux-usb list. Regards, Tony -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RESEND] [PATCH v2 1/2] arm: devtree: Set system_rev from DT revision
* Pali Rohár pali.ro...@gmail.com [150706 06:14]: On Monday 06 July 2015 14:31:27 Tony Lindgren wrote: * Pali Rohár pali.ro...@gmail.com [150706 05:25]: into which file should I put documentation about new DT properties? If it's Linux generic like linux,revision, then how about Documentation/devicetree/bindings/revision.txt? For the ATAGs, Documentation/devicetree/bindings/arm/atag.txt? Hm... now I'm thinking into which DT field should I put atags and revision. In previous emails you wrote to use linux,atags, now arm,atags? And put them into root node? Or other? In arch/arm/boot/compressed/atags_to_fdt.c code I see that most atag properties are converted into /chosen node in DT... So what do you prefer for revision and what for atags? I'd prefer linux,revision and arm,atags. Chances are the ATAGs won't be used on other architectures. I'm find with linux,atags too if people prefer that. Regards, Tony Some mentioned examples: /revision /chosen/revision /linux,revision /chosen/linux,revision ... /atags /chosen/atags /linux,atags /chosen/linux,atags /arm,atags /chosen/arm,atags ... -- Pali Rohár pali.ro...@gmail.com -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 0/5] ATAGs to DT patches
This patch series converts some legacy ATAGs into DT and provide them to userspace. It is needed for userspace applications which needs some informations from legacy bootloaders which are not DT compatible. Patch series is for now without DT documentation files. It was tested in QEMU for Nokia N900. File /proc/cpuinfo contains correct Revision line from ATAG_REVISION and /proc/atags contains full ATAGs structure. Pali Rohár (5): arm: devtree: Set system_rev from DT /revision arm: boot: convert ATAG_REVISION to DT /revision entry arm: atags: Fix declaration of function save_atags arm: devtree: Read ATAGs structure from DT /chosen/linux,atags entry arm: boot: store ATAGs structure into DT /chosen/linux,atags entry arch/arm/boot/compressed/atags_to_fdt.c |8 ++- arch/arm/kernel/atags.h |4 ++-- arch/arm/kernel/devtree.c | 36 --- 3 files changed, 42 insertions(+), 6 deletions(-) -- 1.7.9.5 -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 3/5] arm: atags: Fix declaration of function save_atags
In file atags_proc.c function save_atags() expect const argument, but in
atags.h file is declarated as non const. Fix declaration in atags.h file to
match what is expected.
Signed-off-by: Pali Rohár pali.ro...@gmail.com
---
arch/arm/kernel/atags.h |4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/arch/arm/kernel/atags.h b/arch/arm/kernel/atags.h
index ec4164d..2dfc30f 100644
--- a/arch/arm/kernel/atags.h
+++ b/arch/arm/kernel/atags.h
@@ -1,7 +1,7 @@
#ifdef CONFIG_ATAGS_PROC
-extern void save_atags(struct tag *tags);
+extern void save_atags(const struct tag *tags);
#else
-static inline void save_atags(struct tag *tags) { }
+static inline void save_atags(const struct tag *tags) { }
#endif
void convert_to_tag_list(struct tag *tags);
--
1.7.9.5
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 2/5] arm: boot: convert ATAG_REVISION to DT /revision entry
When uncompressing kernel image this patch convert ATAG_REVISION structure
into DT /revision entry. For legacy bootloaders which do not support DT
booting there is no other option how to pass ATAG_REVISION into kernel.
Signed-off-by: Pali Rohár pali.ro...@gmail.com
---
arch/arm/boot/compressed/atags_to_fdt.c |2 ++
1 file changed, 2 insertions(+)
diff --git a/arch/arm/boot/compressed/atags_to_fdt.c
b/arch/arm/boot/compressed/atags_to_fdt.c
index 9448aa0..e7e1cc9 100644
--- a/arch/arm/boot/compressed/atags_to_fdt.c
+++ b/arch/arm/boot/compressed/atags_to_fdt.c
@@ -171,6 +171,8 @@ int atags_to_fdt(void *atag_list, void *fdt, int
total_space)
cpu_to_fdt32(atag-u.mem.size);
}
+ } else if (atag-hdr.tag == ATAG_REVISION) {
+ setprop_cell(fdt, /, revision,
atag-u.revision.rev);
} else if (atag-hdr.tag == ATAG_INITRD2) {
uint32_t initrd_start, initrd_size;
initrd_start = atag-u.initrd.start;
--
1.7.9.5
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 5/5] arm: boot: store ATAGs structure into DT /chosen/linux,atags entry
Legacy bootloaders can pass additional information for kernel or legacy userspace applications. When booting DT kernel then ATAGs structure is not more visible after running kernel uncompress code. This patch stores full ATAGs structure into DT /chosen/linux,atags entry, so kernel can later reuse it and export via /proc/atags to userspace. Signed-off-by: Pali Rohár pali.ro...@gmail.com --- arch/arm/boot/compressed/atags_to_fdt.c |6 +- 1 file changed, 5 insertions(+), 1 deletion(-) diff --git a/arch/arm/boot/compressed/atags_to_fdt.c b/arch/arm/boot/compressed/atags_to_fdt.c index e7e1cc9..ae93973 100644 --- a/arch/arm/boot/compressed/atags_to_fdt.c +++ b/arch/arm/boot/compressed/atags_to_fdt.c @@ -112,7 +112,7 @@ int atags_to_fdt(void *atag_list, void *fdt, int total_space) * address and size for each bank */ uint32_t mem_reg_property[2 * 2 * NR_BANKS]; int memcount = 0; - int ret, memsize; + int ret, memsize, atag_size; /* make sure we've got an aligned pointer */ if ((u32)atag_list 0x3) @@ -189,5 +189,9 @@ int atags_to_fdt(void *atag_list, void *fdt, int total_space) 4 * memcount * memsize); } + /* include the terminating ATAG_NONE */ + atag_size = (char *)atag - (char *)atag_list + sizeof(struct tag_header); + setprop(fdt, /chosen, linux,atags, atag_list, atag_size); + return fdt_pack(fdt); } -- 1.7.9.5 -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 1/5] arm: devtree: Set system_rev from DT /revision
With this patch /revision DT entry is used to set global system_rev
variable. DT /revision is expected to be u32 numeric value.
TODO: add documentation
Signed-off-by: Pali Rohár pali.ro...@gmail.com
---
arch/arm/kernel/devtree.c | 12 ++--
1 file changed, 10 insertions(+), 2 deletions(-)
diff --git a/arch/arm/kernel/devtree.c b/arch/arm/kernel/devtree.c
index 11c54de..7d82749 100644
--- a/arch/arm/kernel/devtree.c
+++ b/arch/arm/kernel/devtree.c
@@ -19,6 +19,7 @@
#include linux/of_irq.h
#include linux/of_platform.h
#include linux/smp.h
+#include linux/libfdt_env.h
#include asm/cputype.h
#include asm/setup.h
@@ -26,6 +27,7 @@
#include asm/smp_plat.h
#include asm/mach/arch.h
#include asm/mach-types.h
+#include asm/system_info.h
#ifdef CONFIG_SMP
@@ -204,6 +206,8 @@ static const void * __init arch_get_next_mach(const char
*const **match)
const struct machine_desc * __init setup_machine_fdt(unsigned int dt_phys)
{
const struct machine_desc *mdesc, *mdesc_best = NULL;
+ unsigned long dt_root;
+ const u32 *rev;
#ifdef CONFIG_ARCH_MULTIPLATFORM
DT_MACHINE_START(GENERIC_DT, Generic DT based system)
@@ -215,17 +219,16 @@ const struct machine_desc * __init
setup_machine_fdt(unsigned int dt_phys)
if (!dt_phys || !early_init_dt_verify(phys_to_virt(dt_phys)))
return NULL;
+ dt_root = of_get_flat_dt_root();
mdesc = of_flat_dt_match_machine(mdesc_best, arch_get_next_mach);
if (!mdesc) {
const char *prop;
int size;
- unsigned long dt_root;
early_print(\nError: unrecognized/unsupported
device tree compatible list:\n[ );
- dt_root = of_get_flat_dt_root();
prop = of_get_flat_dt_prop(dt_root, compatible, size);
while (size 0) {
early_print('%s' , prop);
@@ -246,5 +249,10 @@ const struct machine_desc * __init
setup_machine_fdt(unsigned int dt_phys)
/* Change machine number to match the mdesc we're using */
__machine_arch_type = mdesc-nr;
+ /* Set system revision from DT */
+ rev = of_get_flat_dt_prop(dt_root, revision, NULL);
+ if (rev)
+ system_rev = fdt32_to_cpu(*rev);
+
return mdesc;
}
--
1.7.9.5
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 4/5] arm: devtree: Read ATAGs structure from DT /chosen/linux,atags entry
With this patch when linux kernel is compiled with ARM_ATAG_DTB_COMPAT it
reads ATAGs structure from /chosen/linux,atags entry and store it into
/proc/atags file. ATAGs structure is not parsed or evaluated, just kernel
exports it to userspace via procfs. It is needed for legacy userspace
application which expect some data from bootloader in /proc/atags file.
This patch keeps them running also on DT kernel if DT /chosen/linux,atags
entry exists.
TODO: add documentation
Signed-off-by: Pali Rohár pali.ro...@gmail.com
---
arch/arm/kernel/devtree.c | 24 +++-
1 file changed, 23 insertions(+), 1 deletion(-)
diff --git a/arch/arm/kernel/devtree.c b/arch/arm/kernel/devtree.c
index 7d82749..69ff048 100644
--- a/arch/arm/kernel/devtree.c
+++ b/arch/arm/kernel/devtree.c
@@ -20,6 +20,7 @@
#include linux/of_platform.h
#include linux/smp.h
#include linux/libfdt_env.h
+#include linux/libfdt.h
#include asm/cputype.h
#include asm/setup.h
@@ -29,6 +30,7 @@
#include asm/mach-types.h
#include asm/system_info.h
+#include atags.h
#ifdef CONFIG_SMP
extern struct of_cpu_method __cpu_method_of_table[];
@@ -208,6 +210,11 @@ const struct machine_desc * __init
setup_machine_fdt(unsigned int dt_phys)
const struct machine_desc *mdesc, *mdesc_best = NULL;
unsigned long dt_root;
const u32 *rev;
+ void *dt_virt;
+#ifdef CONFIG_ARM_ATAG_DTB_COMPAT
+ const void *atags;
+ unsigned long dt_chosen;
+#endif
#ifdef CONFIG_ARCH_MULTIPLATFORM
DT_MACHINE_START(GENERIC_DT, Generic DT based system)
@@ -216,7 +223,12 @@ const struct machine_desc * __init
setup_machine_fdt(unsigned int dt_phys)
mdesc_best = __mach_desc_GENERIC_DT;
#endif
- if (!dt_phys || !early_init_dt_verify(phys_to_virt(dt_phys)))
+ if (!dt_phys)
+ return NULL;
+
+ dt_virt = phys_to_virt(dt_phys);
+
+ if (!early_init_dt_verify(dt_virt))
return NULL;
dt_root = of_get_flat_dt_root();
@@ -254,5 +266,15 @@ const struct machine_desc * __init
setup_machine_fdt(unsigned int dt_phys)
if (rev)
system_rev = fdt32_to_cpu(*rev);
+#ifdef CONFIG_ARM_ATAG_DTB_COMPAT
+ /* Store DT /chosen/linux,atags into /proc/atags */
+ dt_chosen = fdt_path_offset(dt_virt, /chosen);
+ if (dt_chosen = 0) {
+ atags = of_get_flat_dt_prop(dt_chosen, linux,atags, NULL);
+ if (atags)
+ save_atags(atags);
+ }
+#endif
+
return mdesc;
}
--
1.7.9.5
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 1/2] extcon: fix hang and extcon_get/set_cable_state().
Users of find_cable_index_by_name() will cause a kernel hang
as the while loop counter is never incremented and end condition
is never reached.
extcon_get_cable_state() and extcon_set_cable_state() are broken
because they use cable index instead of cable id. This causes
the first cable state (cable.0) to be always invalid in sysfs
or extcon_get_cable_state() users.
Introduce a new function find_cable_id_by_name() that fixes
both of the above issues.
Fixes: commit 73b6ecdb93e8 (extcon: Redefine the unique id of supported
external connectors without 'enum extcon' type)
Cc: Greg Kroah-Hartman gre...@linuxfoundation.org
Signed-off-by: Roger Quadros rog...@ti.com
---
drivers/extcon/extcon.c | 36 +++-
1 file changed, 27 insertions(+), 9 deletions(-)
diff --git a/drivers/extcon/extcon.c b/drivers/extcon/extcon.c
index 76157ab..868c6e2 100644
--- a/drivers/extcon/extcon.c
+++ b/drivers/extcon/extcon.c
@@ -124,15 +124,12 @@ static int find_cable_index_by_id(struct extcon_dev
*edev, const unsigned int id
return -EINVAL;
}
-static int find_cable_index_by_name(struct extcon_dev *edev, const char *name)
+static int find_cable_id_by_name(struct extcon_dev *edev, const char *name)
{
- unsigned int id = EXTCON_NONE;
+ unsigned int id = -EINVAL;
int i = 0;
- if (edev-max_supported == 0)
- return -EINVAL;
-
- /* Find the the number of extcon cable */
+ /* Find the id of extcon cable */
while (extcon_name[i]) {
if (!strncmp(extcon_name[i], name, CABLE_NAME_MAX)) {
id = i;
@@ -140,6 +137,19 @@ static int find_cable_index_by_name(struct extcon_dev
*edev, const char *name)
}
}
+ return id;
+};
+
+static int find_cable_index_by_name(struct extcon_dev *edev, const char *name)
+{
+ unsigned int id = EXTCON_NONE;
+
+ if (edev-max_supported == 0)
+ return -EINVAL;
+
+ /* Find the the number of extcon cable */
+ id = find_cable_id_by_name(edev, name);
+
if (id == EXTCON_NONE)
return -EINVAL;
@@ -228,9 +238,11 @@ static ssize_t cable_state_show(struct device *dev,
struct extcon_cable *cable = container_of(attr, struct extcon_cable,
attr_state);
+ int i = cable-cable_index;
+
return sprintf(buf, %d\n,
extcon_get_cable_state_(cable-edev,
- cable-cable_index));
+
cable-edev-supported_cable[i]));
}
/**
@@ -341,6 +353,9 @@ int extcon_get_cable_state_(struct extcon_dev *edev, const
unsigned int id)
{
int index;
+ if (id == EXTCON_NONE)
+ return -EINVAL;
+
index = find_cable_index_by_id(edev, id);
if (index 0)
return index;
@@ -361,7 +376,7 @@ EXPORT_SYMBOL_GPL(extcon_get_cable_state_);
*/
int extcon_get_cable_state(struct extcon_dev *edev, const char *cable_name)
{
- return extcon_get_cable_state_(edev, find_cable_index_by_name
+ return extcon_get_cable_state_(edev, find_cable_id_by_name
(edev, cable_name));
}
EXPORT_SYMBOL_GPL(extcon_get_cable_state);
@@ -380,6 +395,9 @@ int extcon_set_cable_state_(struct extcon_dev *edev,
unsigned int id,
u32 state;
int index;
+ if (id == EXTCON_NONE)
+ return -EINVAL;
+
index = find_cable_index_by_id(edev, id);
if (index 0)
return index;
@@ -404,7 +422,7 @@ EXPORT_SYMBOL_GPL(extcon_set_cable_state_);
int extcon_set_cable_state(struct extcon_dev *edev,
const char *cable_name, bool cable_state)
{
- return extcon_set_cable_state_(edev, find_cable_index_by_name
+ return extcon_set_cable_state_(edev, find_cable_id_by_name
(edev, cable_name), cable_state);
}
EXPORT_SYMBOL_GPL(extcon_set_cable_state);
--
2.1.4
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 2/2] extcon: Fix extcon_cable_get_state() from getting old state after notification
Currently the extcon code notifiers the interested listeners
before it updates the extcon state with the new state.
This will cause the listeners that use extcon_cable_get_state()
to get the stale state and loose the new state.
Fix this by first changing the extcon state variable and then
notifying listeners.
Signed-off-by: Roger Quadros rog...@ti.com
---
drivers/extcon/extcon.c | 14 ++
1 file changed, 10 insertions(+), 4 deletions(-)
diff --git a/drivers/extcon/extcon.c b/drivers/extcon/extcon.c
index 868c6e2..26d1e1e 100644
--- a/drivers/extcon/extcon.c
+++ b/drivers/extcon/extcon.c
@@ -275,19 +275,25 @@ int extcon_update_state(struct extcon_dev *edev, u32
mask, u32 state)
spin_lock_irqsave(edev-lock, flags);
if (edev-state != ((edev-state ~mask) | (state mask))) {
+ u32 old_state;
+
if (check_mutually_exclusive(edev, (edev-state ~mask) |
(state mask))) {
spin_unlock_irqrestore(edev-lock, flags);
return -EPERM;
}
+ old_state = edev-state;
+ edev-state = ~mask;
+ edev-state |= state mask;
+
for (index = 0; index edev-max_supported; index++) {
- if (is_extcon_changed(edev-state, state, index,
attached))
- raw_notifier_call_chain(edev-nh[index],
attached, edev);
+ if (is_extcon_changed(old_state, edev-state, index,
+ attached))
+ raw_notifier_call_chain(edev-nh[index],
+ attached, edev);
}
- edev-state = ~mask;
- edev-state |= state mask;
/* This could be in interrupt handler */
prop_buf = (char *)get_zeroed_page(GFP_ATOMIC);
--
2.1.4
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] clocksource: Allow toggling between runtime and persistent clocksource for idle
On Mon, 6 Jul 2015, Tony Lindgren wrote:
* Thomas Gleixner t...@linutronix.de [150706 07:20]:
On Mon, 6 Jul 2015, Tony Lindgren wrote:
The timekeeping accuracy issue certainly needs some thinking, and
also the resolution between the clocksources can be different.. In the
test case I have the slow timer is always on and of a lower resolution
than the ARM global timer being used during runtime.
Got some handy timer test in mind you want me to run to provide data
on the accuracy?
John Stultz might have something.
+/**
+ * clocksource_pm_enter - change to a persistent clocksource before idle
+ *
+ * Changes system to use a persistent clocksource for idle. Intended to
+ * be called from CPUidle from the last active CPU.
+ */
+int clocksource_pm_enter(void)
+{
+ bool oneshot = tick_oneshot_mode_active();
+ struct clocksource *best;
+
+ if (WARN_ONCE(!mutex_trylock(clocksource_mutex),
+ Unable to get clocksource_mutex))
+ return -EINTR;
This trylock serves which purpose?
Well we don't want to start changing clocksource if something is
running like you pointed out.
Well yes, but
I really cannot see how this is proper serialized.
We need to allow this only from the last cpu before hitting idle.
And I cannot see anything which does so.
cpu0cpu1
is_idle
go_idle()
clocksource_pm_enter()
lock(cs_mutex);
wakeup()
clocksource_pm_exit()
trylock fails
...
unlock(cs_mutex);
-- Crap!
@@ -1086,7 +1086,18 @@ int timekeeping_notify(struct clocksource *clock)
if (tk-tkr_mono.clock == clock)
return 0;
- stop_machine(change_clocksource, clock, NULL);
+
+ /*
+ * We may want to toggle between a fast and a persistent
+ * clocksource from CPUidle on the last active CPU and can't
+ * use stop_machine at that point.
+ */
+ if (cpumask_test_cpu(smp_processor_id(), cpu_online_mask)
Can you please explain how this code gets called from an offline cpu?
Last cpu getting idled..
That does not make any sense at all. How is idle related to the online
mask? An idle cpu is still online.
+ !rcu_is_watching())
So pick some random combination of conditions and define that it is
correct, right? How on earth does !rcu_watching() tell that this is
the last running cpu.
We have called rcu_idle_enter() from cpuidle_idle_call(). Do you have
some better test in mind when the last cpu is about hit idle?
The cpuidle code should know that. And if it does not know, it better
should keep track of that information and based on it provide the
proper serialization, so the call into the timekeeping code is not a
subject to guess work and race conditions.
Thanks,
tglx
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] clocksource: Allow toggling between runtime and persistent clocksource for idle
On Mon, Jul 6, 2015 at 12:12 AM, Tony Lindgren t...@atomide.com wrote: Some persistent clocksources can be on a slow external bus. For shorter latencies for RT use, let's allow toggling the clocksource during idle between a faster non-persistent runtime clocksource and a slower persistent clocksource. So yea, as Thomas mentioned, this will cause problems for timekeeping accuracy, since we end up resetting the ntp state when we change clocksource (additionally you gain a bit of error each time you switch clocksources). So you'll most likely see trouble w/ ntpd steering the clock. I'm not sure its quite clear in the description as to the need here. Could you expand a bit as to the rational for why? I assume it has to do with you have a high-res clocksource that is good for fine-grained clock_gettime() calls, but wraps quickly, making it poor for long idle times. So you're trying to swap to a less fine grained clocksource that won't wrap so fast? The persistent-clock-like name muddies things further, since the persistent-clock is used for suspend, while it looks like this is just for idle times. thanks -john -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] clocksource: Allow toggling between runtime and persistent clocksource for idle
On Mon, Jul 6, 2015 at 10:34 AM, Thomas Gleixner t...@linutronix.de wrote: On Mon, 6 Jul 2015, John Stultz wrote: On Mon, Jul 6, 2015 at 12:12 AM, Tony Lindgren t...@atomide.com wrote: Some persistent clocksources can be on a slow external bus. For shorter latencies for RT use, let's allow toggling the clocksource during idle between a faster non-persistent runtime clocksource and a slower persistent clocksource. So yea, as Thomas mentioned, this will cause problems for timekeeping accuracy, since we end up resetting the ntp state when we change clocksource (additionally you gain a bit of error each time you switch clocksources). So you'll most likely see trouble w/ ntpd steering the clock. I'm not sure its quite clear in the description as to the need here. Could you expand a bit as to the rational for why? I assume it has to do with you have a high-res clocksource that is good for fine-grained clock_gettime() calls, but wraps quickly, making it poor for long idle times. So you're trying to swap to a less fine grained clocksource that won't wrap so fast? The persistent-clock-like name muddies things further, since the persistent-clock is used for suspend, while it looks like this is just for idle times. Though that are idle states where the cpu is powered off so the fast clock source is powered off as well We all know how well that works from the x86/TSC horror. It's just the same thing again with a different arch prefix. Right.. and it might be telling that on x86 systems with this issue, we don't play games with it and that sort of hardware just has to use the slower and less fine-grained clocksources all the time. thanks -john -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] base: power: wakeirq: don't leak dev-power.wakeirq
On Mon, Jul 06, 2015 at 08:06:17PM +0200, Michael Trimarchi wrote: Hi On Jul 6, 2015 8:01 PM, Felipe Balbi ba...@ti.com wrote: on a first call to dev_pm_attach_wake_irq(), if it fails, it will leave dev-power.wakeirq set to a dangling pointer. Instead, let's clear it to make sure a subsequent call to dev_pm_attach_wake_irq() has chance to succeed. Cc: Tony Lindgren tml...@atomide.com Signed-off-by: Felipe Balbi ba...@ti.com --- drivers/base/power/wakeirq.c | 9 - 1 file changed, 8 insertions(+), 1 deletion(-) diff --git a/drivers/base/power/wakeirq.c b/drivers/base/power/wakeirq.c index 7470004ca810..394d250a1ad8 100644 --- a/drivers/base/power/wakeirq.c +++ b/drivers/base/power/wakeirq.c @@ -50,9 +50,16 @@ static int dev_pm_attach_wake_irq(struct device *dev, int irq, err = device_wakeup_attach_irq(dev, wirq); if (err) - return err; + goto err_cleanup; return 0; + +err_cleanup: + spin_lock_irqsave(dev-power.lock, flags); + dev-power.wakeirq = NULL; + spin_unlock_irqrestore(dev-power.lock, flags); + Why here and not in the fuction that return the error? because the field was set here, why would I clear it elsewhere ? -- balbi signature.asc Description: Digital signature
Re: [PATCH v4] clk: change clk_ops' -determine_rate() prototype
On 07/06, Boris Brezillon wrote:
Clock rates are stored in an unsigned long field, but -determine_rate()
(which returns a rounded rate from a requested one) returns a long
value (errors are reported using negative error codes), which can lead
to long overflow if the clock rate exceed 2Ghz.
Change -determine_rate() prototype to return 0 or an error code, and pass
a pointer to a clk_rate_request structure containing the expected target
rate and the rate constraints imposed by clk users.
The clk_rate_request structure might be extended in the future to contain
other kind of constraints like the rounding policy, the maximum clock
inaccuracy or other things that are not yet supported by the CCF
(power consumption constraints ?).
Signed-off-by: Boris Brezillon boris.brezil...@free-electrons.com
Which files did you compile?
drivers/clk/mmp/clk-mix.c: In function ‘mmp_clk_mix_determine_rate’:
drivers/clk/mmp/clk-mix.c:221:13: error: ‘rate’ undeclared (first use in this
function)
diff --git a/arch/arm/mach-omap2/dpll3xxx.c b/arch/arm/mach-omap2/dpll3xxx.c
index 44e57ec..cd27457 100644
--- a/arch/arm/mach-omap2/dpll3xxx.c
+++ b/arch/arm/mach-omap2/dpll3xxx.c
@@ -462,43 +462,38 @@ void omap3_noncore_dpll_disable(struct clk_hw *hw)
/**
* omap3_noncore_dpll_determine_rate - determine rate for a DPLL
* @hw: pointer to the clock to determine rate for
- * @rate: target rate for the DPLL
- * @best_parent_rate: pointer for returning best parent rate
- * @best_parent_clk: pointer for returning best parent clock
+ * @req: target rate request
*
* Determines which DPLL mode to use for reaching a desired target rate.
* Checks whether the DPLL shall be in bypass or locked mode, and if
* locked, calculates the M,N values for the DPLL via round-rate.
- * Returns a positive clock rate with success, negative error value
- * in failure.
+ * Returns a 0 on success, negative error value in failure.
*/
-long omap3_noncore_dpll_determine_rate(struct clk_hw *hw, unsigned long rate,
-unsigned long min_rate,
-unsigned long max_rate,
-unsigned long *best_parent_rate,
-struct clk_hw **best_parent_clk)
+int omap3_noncore_dpll_determine_rate(struct clk_hw *hw,
+ struct clk_rate_request *req)
{
struct clk_hw_omap *clk = to_clk_hw_omap(hw);
struct dpll_data *dd;
- if (!hw || !rate)
+ if (!hw || !req || !req-rate)
Why do we need to check for req? It shouldn't be NULL.
return -EINVAL;
dd = clk-dpll_data;
if (!dd)
return -EINVAL;
- if (__clk_get_rate(dd-clk_bypass) == rate
+ if (__clk_get_rate(dd-clk_bypass) == req-rate
(dd-modes (1 DPLL_LOW_POWER_BYPASS))) {
- *best_parent_clk = __clk_get_hw(dd-clk_bypass);
+ req-best_parent_hw = __clk_get_hw(dd-clk_bypass);
} else {
- rate = omap2_dpll_round_rate(hw, rate, best_parent_rate);
- *best_parent_clk = __clk_get_hw(dd-clk_ref);
+ req-rate = omap2_dpll_round_rate(hw, req-rate,
+ req-best_parent_rate);
+ req-best_parent_hw = __clk_get_hw(dd-clk_ref);
}
- *best_parent_rate = rate;
+ req-best_parent_rate = req-rate;
- return rate;
+ return 0;
}
/**
diff --git a/arch/arm/mach-omap2/dpll44xx.c b/arch/arm/mach-omap2/dpll44xx.c
index f231be0..d615571 100644
--- a/arch/arm/mach-omap2/dpll44xx.c
+++ b/arch/arm/mach-omap2/dpll44xx.c
@@ -191,42 +191,36 @@ out:
/**
* omap4_dpll_regm4xen_determine_rate - determine rate for a DPLL
* @hw: pointer to the clock to determine rate for
- * @rate: target rate for the DPLL
- * @best_parent_rate: pointer for returning best parent rate
- * @best_parent_clk: pointer for returning best parent clock
+ * @req: target rate request
*
* Determines which DPLL mode to use for reaching a desired rate.
* Checks whether the DPLL shall be in bypass or locked mode, and if
* locked, calculates the M,N values for the DPLL via round-rate.
- * Returns a positive clock rate with success, negative error value
- * in failure.
+ * Returns 0 on success and a negative error value otherwise.
*/
-long omap4_dpll_regm4xen_determine_rate(struct clk_hw *hw, unsigned long
rate,
- unsigned long min_rate,
- unsigned long max_rate,
- unsigned long *best_parent_rate,
- struct clk_hw **best_parent_clk)
+int omap4_dpll_regm4xen_determine_rate(struct clk_hw *hw,
+struct clk_rate_request *req)
{
struct clk_hw_omap *clk = to_clk_hw_omap(hw);
struct dpll_data *dd;
- if
Re: [RESEND] [PATCH v2 1/2] arm: devtree: Set system_rev from DT revision
On Monday 06 July 2015 18:20:35 Pali Rohár wrote:
/chosen/linux,atags
This one. ATAGs are a Linux data struct.
Rob
Ok, and how read that property /chosen/linux,atags in function
setup_machine_fdt() from file arch/arm/kernel/devtree.c ?
of_get_flat_dt_prop() cannot be used unless somebody get me offset to
node /chosen...
Any idea?
fdt_path_offset() from libfdt.h seems to work...
Is solution like this one acceptable?
#include linux/libfdt.h
#include atags.h
... setup_machine_fdt(unsigned int dt_phys) {
dt_virt = phys_to_virt(dt_phys);
dt_chosen = fdt_path_offset(dt_virt, /chosen);
atags = of_get_flat_dt_prop(dt_chosen, linux,atags, NULL);
save_atags(atags);
}
(this is without checks for errors)
--
Pali Rohár
pali.ro...@gmail.com
signature.asc
Description: This is a digitally signed message part.
Re: [PATCH v3] clk: change clk_ops' -determine_rate() prototype
On Wed, 3 Jun 2015 16:37:28 -0700
Stephen Boyd sb...@codeaurora.org wrote:
On 05/20, Boris Brezillon wrote:
Clock rates are stored in an unsigned long field, but -determine_rate()
(which returns a rounded rate from a requested one) returns a long
value (errors are reported using negative error codes), which can lead
to long overflow if the clock rate exceed 2Ghz.
Change -determine_rate() prototype to return 0 or an error code, and pass
a pointer to a clk_rate_request structure containing the expected target
rate and the rate constraints imposed by clk users.
The clk_rate_request structure might be extended in the future to contain
other kind of constraints like the rounding policy, the maximum clock
inaccuracy or other things that are not yet supported by the CCF
(power consumption constraints ?).
Signed-off-by: Boris Brezillon boris.brezil...@free-electrons.com
CC: Jonathan Corbet cor...@lwn.net
CC: Tony Lindgren t...@atomide.com
CC: Ralf Baechle r...@linux-mips.org
CC: Emilio López emi...@elopez.com.ar
CC: Maxime Ripard maxime.rip...@free-electrons.com
CC: Tero Kristo t-kri...@ti.com
CC: linux-...@vger.kernel.org
CC: linux-ker...@vger.kernel.org
CC: linux-arm-ker...@lists.infradead.org
CC: linux-omap@vger.kernel.org
CC: linux-m...@linux-mips.org
---
Hi Stephen,
This patch is based on clk-next and contains the changes you suggested
in your previous review.
It was tested on sama5d4 and compile tested on several ARM platforms
(those enabled in multi_v7_defconfig).
Thanks. I think we should wait until the next -rc1 drops to apply the
patch for the next merge window. That will make it least likely to conflict
with other trees, and we can provide it on a stable branch should there
be clock providers going through other trees somewhere. Please
remind me if I forget.
Just sent a v4 fixing the bug you reported and rebasing my work on
4.2-rc1.
@@ -1186,15 +1191,21 @@ EXPORT_SYMBOL_GPL(__clk_determine_rate);
*/
unsigned long __clk_round_rate(struct clk *clk, unsigned long rate)
{
- unsigned long min_rate;
- unsigned long max_rate;
+
+ struct clk_rate_request req;
+ int ret;
if (!clk)
return 0;
- clk_core_get_boundaries(clk-core, min_rate, max_rate);
+ clk_core_get_boundaries(clk-core, req.min_rate, req.max_rate);
+ req.rate = rate;
+
+ ret = clk_core_round_rate_nolock(clk-core, req);
+ if (ret)
+ return ret;
This returns a negative int for unsigned long. Is that intentional?
--
Boris Brezillon, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] base: power: wakeirq: don't leak dev-power.wakeirq
on a first call to dev_pm_attach_wake_irq(), if it fails, it will leave dev-power.wakeirq set to a dangling pointer. Instead, let's clear it to make sure a subsequent call to dev_pm_attach_wake_irq() has chance to succeed. Cc: Tony Lindgren tml...@atomide.com Signed-off-by: Felipe Balbi ba...@ti.com --- drivers/base/power/wakeirq.c | 9 - 1 file changed, 8 insertions(+), 1 deletion(-) diff --git a/drivers/base/power/wakeirq.c b/drivers/base/power/wakeirq.c index 7470004ca810..394d250a1ad8 100644 --- a/drivers/base/power/wakeirq.c +++ b/drivers/base/power/wakeirq.c @@ -50,9 +50,16 @@ static int dev_pm_attach_wake_irq(struct device *dev, int irq, err = device_wakeup_attach_irq(dev, wirq); if (err) - return err; + goto err_cleanup; return 0; + +err_cleanup: + spin_lock_irqsave(dev-power.lock, flags); + dev-power.wakeirq = NULL; + spin_unlock_irqrestore(dev-power.lock, flags); + + return err; } /** -- 2.4.4 -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RESEND] [PATCH v2 1/2] arm: devtree: Set system_rev from DT revision
On Monday 06 July 2015 17:22:58 Rob Herring wrote: On Mon, Jul 6, 2015 at 8:12 AM, Pali Rohár pali.ro...@gmail.com wrote: On Monday 06 July 2015 14:31:27 Tony Lindgren wrote: * Pali Rohár pali.ro...@gmail.com [150706 05:25]: into which file should I put documentation about new DT properties? If it's Linux generic like linux,revision, then how about Documentation/devicetree/bindings/revision.txt? For the ATAGs, Documentation/devicetree/bindings/arm/atag.txt? Regards, Tony Hm... now I'm thinking into which DT field should I put atags and revision. In previous emails you wrote to use linux,atags, now arm,atags? And put them into root node? Or other? In arch/arm/boot/compressed/atags_to_fdt.c code I see that most atag properties are converted into /chosen node in DT... So what do you prefer for revision and what for atags? Some mentioned examples: /revision This one. This is a top level h/w property. /chosen/revision /linux,revision /chosen/linux,revision ... /atags /chosen/atags /linux,atags /chosen/linux,atags This one. ATAGs are a Linux data struct. Rob Ok, and how read that property /chosen/linux,atags in function setup_machine_fdt() from file arch/arm/kernel/devtree.c ? of_get_flat_dt_prop() cannot be used unless somebody get me offset to node /chosen... Any idea? /arm,atags /chosen/arm,atags ... -- Pali Rohár pali.ro...@gmail.com -- Pali Rohár pali.ro...@gmail.com signature.asc Description: This is a digitally signed message part.
Re: [PATCH] clocksource: Allow toggling between runtime and persistent clocksource for idle
* Thomas Gleixner t...@linutronix.de [150706 08:48]:
On Mon, 6 Jul 2015, Tony Lindgren wrote:
* Thomas Gleixner t...@linutronix.de [150706 07:20]:
On Mon, 6 Jul 2015, Tony Lindgren wrote:
The timekeeping accuracy issue certainly needs some thinking, and
also the resolution between the clocksources can be different.. In the
test case I have the slow timer is always on and of a lower resolution
than the ARM global timer being used during runtime.
Got some handy timer test in mind you want me to run to provide data
on the accuracy?
John Stultz might have something.
+/**
+ * clocksource_pm_enter - change to a persistent clocksource before
idle
+ *
+ * Changes system to use a persistent clocksource for idle. Intended to
+ * be called from CPUidle from the last active CPU.
+ */
+int clocksource_pm_enter(void)
+{
+ bool oneshot = tick_oneshot_mode_active();
+ struct clocksource *best;
+
+ if (WARN_ONCE(!mutex_trylock(clocksource_mutex),
+ Unable to get clocksource_mutex))
+ return -EINTR;
This trylock serves which purpose?
Well we don't want to start changing clocksource if something is
running like you pointed out.
Well yes, but
I really cannot see how this is proper serialized.
We need to allow this only from the last cpu before hitting idle.
And I cannot see anything which does so.
cpu0 cpu1
is_idle
go_idle()
clocksource_pm_enter()
lock(cs_mutex);
wakeup()
clocksource_pm_exit()
trylock fails
...
unlock(cs_mutex);
-- Crap!
OK you're right, this only works with cpuidle and using
drivers/cpuidle/coupled.c.
@@ -1086,7 +1086,18 @@ int timekeeping_notify(struct clocksource *clock)
if (tk-tkr_mono.clock == clock)
return 0;
- stop_machine(change_clocksource, clock, NULL);
+
+ /*
+* We may want to toggle between a fast and a persistent
+* clocksource from CPUidle on the last active CPU and can't
+* use stop_machine at that point.
+*/
+ if (cpumask_test_cpu(smp_processor_id(), cpu_online_mask)
Can you please explain how this code gets called from an offline cpu?
Last cpu getting idled..
That does not make any sense at all. How is idle related to the online
mask? An idle cpu is still online.
Oops yeah that's a bogus test, cpu off != offlined.
+ !rcu_is_watching())
So pick some random combination of conditions and define that it is
correct, right? How on earth does !rcu_watching() tell that this is
the last running cpu.
We have called rcu_idle_enter() from cpuidle_idle_call(). Do you have
some better test in mind when the last cpu is about hit idle?
The cpuidle code should know that. And if it does not know, it better
should keep track of that information and based on it provide the
proper serialization, so the call into the timekeeping code is not a
subject to guess work and race conditions.
OK I agree. Based on your comments this clearly needs to be limited to
cpuidle. And thanks for your comments.
Regards,
Tony
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] clocksource: Allow toggling between runtime and persistent clocksource for idle
On Mon, Jul 6, 2015 at 8:46 AM, Thomas Gleixner t...@linutronix.de wrote: On Mon, 6 Jul 2015, Tony Lindgren wrote: * Thomas Gleixner t...@linutronix.de [150706 07:20]: On Mon, 6 Jul 2015, Tony Lindgren wrote: The timekeeping accuracy issue certainly needs some thinking, and also the resolution between the clocksources can be different.. In the test case I have the slow timer is always on and of a lower resolution than the ARM global timer being used during runtime. Got some handy timer test in mind you want me to run to provide data on the accuracy? John Stultz might have something. You can turn on ntp stats in your ntp.conf and chart the loopstats data w/ gnuplot: set terminal png set output loopstat.png plot /var/log/ntpstats/loopstats.dateoftest using 2:3 with linespoints I also have the drift-log.py and graph-log.py scripts I use here: https://github.com/johnstultz-work/timetests But those aren't really ready for mass consumption, as they're probably not very cross-distro compatible. thanks -john -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v4] clk: change clk_ops' -determine_rate() prototype
Clock rates are stored in an unsigned long field, but -determine_rate() (which returns a rounded rate from a requested one) returns a long value (errors are reported using negative error codes), which can lead to long overflow if the clock rate exceed 2Ghz. Change -determine_rate() prototype to return 0 or an error code, and pass a pointer to a clk_rate_request structure containing the expected target rate and the rate constraints imposed by clk users. The clk_rate_request structure might be extended in the future to contain other kind of constraints like the rounding policy, the maximum clock inaccuracy or other things that are not yet supported by the CCF (power consumption constraints ?). Signed-off-by: Boris Brezillon boris.brezil...@free-electrons.com CC: Jonathan Corbet cor...@lwn.net CC: Tony Lindgren t...@atomide.com CC: Ralf Baechle r...@linux-mips.org CC: Emilio López emi...@elopez.com.ar CC: Maxime Ripard maxime.rip...@free-electrons.com CC: Tero Kristo t-kri...@ti.com CC: Peter De Schrijver pdeschrij...@nvidia.com CC: Prashant Gaikwad pgaik...@nvidia.com CC: Stephen Warren swar...@wwwdotorg.org CC: Thierry Reding thierry.red...@gmail.com CC: Alexandre Courbot gnu...@gmail.com CC: linux-...@vger.kernel.org CC: linux-ker...@vger.kernel.org CC: linux-arm-ker...@lists.infradead.org CC: linux-omap@vger.kernel.org CC: linux-m...@linux-mips.org CC: linux-te...@vger.kernel.org --- changes since v3: - modify clk-emc driver to match the new prototype - fix __clk_round_rate negative error code return - remove unused variable in clk-hi3620.c - rebased on 4.2-rc1 Changes since v2: - drop the -round_rate() prototype changes - introduce a clk_rate_request struct to avoid any changes on the prototype in the future Changes since v1: - fix an 'uninitialized variable' bug reported by Heiko - rebased on clk-next --- Documentation/clk.txt | 8 +- arch/arm/mach-omap2/dpll3xxx.c | 29 +++--- arch/arm/mach-omap2/dpll44xx.c | 30 +++--- arch/mips/alchemy/common/clock.c| 61 + drivers/clk/at91/clk-programmable.c | 25 ++--- drivers/clk/at91/clk-usb.c | 28 +++--- drivers/clk/bcm/clk-kona.c | 34 --- drivers/clk/clk-composite.c | 48 +- drivers/clk/clk.c | 176 drivers/clk/hisilicon/clk-hi3620.c | 41 - drivers/clk/mmp/clk-mix.c | 18 ++-- drivers/clk/qcom/clk-pll.c | 16 ++-- drivers/clk/qcom/clk-rcg.c | 44 - drivers/clk/qcom/clk-rcg2.c | 78 drivers/clk/sunxi/clk-factors.c | 21 ++--- drivers/clk/sunxi/clk-sun6i-ar100.c | 21 ++--- drivers/clk/sunxi/clk-sunxi.c | 20 ++-- drivers/clk/tegra/clk-emc.c | 28 +++--- include/linux/clk-provider.h| 49 ++ include/linux/clk/ti.h | 16 +--- 20 files changed, 393 insertions(+), 398 deletions(-) diff --git a/Documentation/clk.txt b/Documentation/clk.txt index f463bdc..5c4bc4d 100644 --- a/Documentation/clk.txt +++ b/Documentation/clk.txt @@ -71,12 +71,8 @@ the operations defined in clk.h: long(*round_rate)(struct clk_hw *hw, unsigned long rate, unsigned long *parent_rate); - long(*determine_rate)(struct clk_hw *hw, - unsigned long rate, - unsigned long min_rate, - unsigned long max_rate, - unsigned long *best_parent_rate, - struct clk_hw **best_parent_clk); + int (*determine_rate)(struct clk_hw *hw, + struct clk_rate_request *req); int (*set_parent)(struct clk_hw *hw, u8 index); u8 (*get_parent)(struct clk_hw *hw); int (*set_rate)(struct clk_hw *hw, diff --git a/arch/arm/mach-omap2/dpll3xxx.c b/arch/arm/mach-omap2/dpll3xxx.c index 44e57ec..cd27457 100644 --- a/arch/arm/mach-omap2/dpll3xxx.c +++ b/arch/arm/mach-omap2/dpll3xxx.c @@ -462,43 +462,38 @@ void omap3_noncore_dpll_disable(struct clk_hw *hw) /** * omap3_noncore_dpll_determine_rate - determine rate for a DPLL * @hw: pointer to the clock to determine rate for - * @rate: target rate for the DPLL - * @best_parent_rate: pointer for returning best parent rate - * @best_parent_clk: pointer for returning best parent clock + * @req: target rate request * * Determines which DPLL mode to use for reaching a desired target rate. * Checks whether the DPLL shall be in bypass or locked mode, and if * locked, calculates the M,N values for the DPLL via round-rate. - * Returns a positive clock rate with success, negative
Re: [PATCH] clocksource: Allow toggling between runtime and persistent clocksource for idle
On Mon, 6 Jul 2015, John Stultz wrote: On Mon, Jul 6, 2015 at 12:12 AM, Tony Lindgren t...@atomide.com wrote: Some persistent clocksources can be on a slow external bus. For shorter latencies for RT use, let's allow toggling the clocksource during idle between a faster non-persistent runtime clocksource and a slower persistent clocksource. So yea, as Thomas mentioned, this will cause problems for timekeeping accuracy, since we end up resetting the ntp state when we change clocksource (additionally you gain a bit of error each time you switch clocksources). So you'll most likely see trouble w/ ntpd steering the clock. I'm not sure its quite clear in the description as to the need here. Could you expand a bit as to the rational for why? I assume it has to do with you have a high-res clocksource that is good for fine-grained clock_gettime() calls, but wraps quickly, making it poor for long idle times. So you're trying to swap to a less fine grained clocksource that won't wrap so fast? The persistent-clock-like name muddies things further, since the persistent-clock is used for suspend, while it looks like this is just for idle times. Though that are idle states where the cpu is powered off so the fast clock source is powered off as well We all know how well that works from the x86/TSC horror. It's just the same thing again with a different arch prefix. Thanks, tglx -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RESEND] [PATCH v2 1/2] arm: devtree: Set system_rev from DT revision
On Mon, Jul 6, 2015 at 11:20 AM, Pali Rohár pali.ro...@gmail.com wrote: On Monday 06 July 2015 17:22:58 Rob Herring wrote: On Mon, Jul 6, 2015 at 8:12 AM, Pali Rohár pali.ro...@gmail.com wrote: On Monday 06 July 2015 14:31:27 Tony Lindgren wrote: * Pali Rohár pali.ro...@gmail.com [150706 05:25]: into which file should I put documentation about new DT properties? If it's Linux generic like linux,revision, then how about Documentation/devicetree/bindings/revision.txt? For the ATAGs, Documentation/devicetree/bindings/arm/atag.txt? Regards, Tony Hm... now I'm thinking into which DT field should I put atags and revision. In previous emails you wrote to use linux,atags, now arm,atags? And put them into root node? Or other? In arch/arm/boot/compressed/atags_to_fdt.c code I see that most atag properties are converted into /chosen node in DT... So what do you prefer for revision and what for atags? Some mentioned examples: /revision This one. This is a top level h/w property. /chosen/revision /linux,revision /chosen/linux,revision ... /atags /chosen/atags /linux,atags /chosen/linux,atags This one. ATAGs are a Linux data struct. Rob Ok, and how read that property /chosen/linux,atags in function setup_machine_fdt() from file arch/arm/kernel/devtree.c ? of_get_flat_dt_prop() cannot be used unless somebody get me offset to node /chosen... Why can't you get the offset yourself? However, why does this need to be early? It is only used to populate /proc, right? Rob -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/5] usb: dwc3: ep0: use _roundup_ to calculate the transfer size
On Wed, Jun 10, 2015 at 02:48:48PM +0530, Kishon Vijay Abraham I wrote: No functional change. Used _roundup_ macro to calculate the transfer size aligned to maxpacket in dwc3_ep0_complete_data. It also makes it similar to how transfer size is calculated in __dwc3_ep0_do_control_data. Signed-off-by: Kishon Vijay Abraham I kis...@ti.com doesn't apply, can you rebase on testing/next ? -- balbi signature.asc Description: Digital signature
Re: [PATCH] thermal: consistently use int for temperatures
Am Montag, 6. Juli 2015, 09:19:49 schrieb Sascha Hauer: The thermal code uses int, long and unsigned long for temperatures in different places. Using an unsigned type limits the thermal framework to positive temperatures without need. Also several drivers currently will report temperatures near UINT_MAX for temperatures below 0°C. This will probably immediately shut the machine down due to overtemperature if started below 0°C. 'long' is 64bit on several architectures. This is not needed since INT_MAX °mC is above the melting point of all known materials. Consistently use a plain 'int' for temperatures throughout the thermal code and the drivers. This only changes the places in the drivers where the temperature is passed around as pointer, when drivers internally use another type this is not changed. Signed-off-by: Sascha Hauer s.ha...@pengutronix.de Cc: Zhang Rui rui.zh...@intel.com Cc: Eduardo Valentin edubez...@gmail.com Cc: linux...@vger.kernel.org Cc: linux-ker...@vger.kernel.org Cc: Jean Delvare jdelv...@suse.de Cc: Peter Feuerer pe...@piie.net Cc: Heiko Stuebner he...@sntech.de Cc: Lukasz Majewski l.majew...@samsung.com Cc: Stephen Warren swar...@wwwdotorg.org Cc: Thierry Reding thierry.red...@gmail.com Cc: linux-a...@vger.kernel.org Cc: platform-driver-...@vger.kernel.org Cc: linux-arm-ker...@lists.infradead.org Cc: linux-omap@vger.kernel.org Cc: linux-samsung-...@vger.kernel.org Cc: Guenter Roeck li...@roeck-us.net Cc: Rafael J. Wysocki r...@rjwysocki.net Cc: Maxime Ripard maxime.rip...@free-electrons.com Cc: Darren Hart dvh...@infradead.org Cc: lm-sens...@lm-sensors.org --- For drivers/thermal/rockchip_thermal.c | 10 Reviewed-by: Heiko Stuebner he...@sntech.de -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
rx51-battery.ko incompatiblity: board code vs DT
Hello, now I found out that rx51-battery.ko driver register sysnode /sys/class/power_supply/rx51-battery/ when booting with legacy board code. But when booting DT kernel it register sysnode with different name /sys/class/power_supply/n900-battery/ Sysfs node for DT kernel comes from Nokia N900 DTS file: arch/arm/boot/dts/omap3-n900.dts I would propose change which change DTS to rx51-battery to have it compatible with naming which is for legacy board code. It is just because to have compatibility and same naming scheme and also to make existing programs to work without needing patching them. What do you think? -- Pali Rohár pali.ro...@gmail.com signature.asc Description: This is a digitally signed message part.
Re: [PATCH] thermal: consistently use int for temperatures
On Mon, Jul 06, 2015 at 09:19:49AM +0200, Sascha Hauer wrote: The thermal code uses int, long and unsigned long for temperatures in different places. Using an unsigned type limits the thermal framework to positive temperatures without need. Also several drivers currently will report temperatures near UINT_MAX for temperatures below 0°C. This will probably immediately shut the machine down due to overtemperature if started below 0°C. 'long' is 64bit on several architectures. This is not needed since INT_MAX °mC is above the melting point of all known materials. Consistently use a plain 'int' for temperatures throughout the thermal code and the drivers. This only changes the places in the drivers where the temperature is passed around as pointer, when drivers internally use another type this is not changed. Signed-off-by: Sascha Hauer s.ha...@pengutronix.de ... drivers/platform/x86/acerhdf.c | 9 drivers/platform/x86/intel_mid_thermal.c | 9 For these two: Reviewed-by: Darren Hart dvh...@linux.intel.com -- Darren Hart Intel Open Source Technology Center -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] base: power: wakeirq: don't leak dev-power.wakeirq
On Monday, July 06, 2015 01:01:18 PM Felipe Balbi wrote:
on a first call to dev_pm_attach_wake_irq(), if it
fails, it will leave dev-power.wakeirq set to a
dangling pointer. Instead, let's clear it to make
sure a subsequent call to dev_pm_attach_wake_irq()
has chance to succeed.
Cc: Tony Lindgren tml...@atomide.com
Signed-off-by: Felipe Balbi ba...@ti.com
---
drivers/base/power/wakeirq.c | 9 -
1 file changed, 8 insertions(+), 1 deletion(-)
diff --git a/drivers/base/power/wakeirq.c b/drivers/base/power/wakeirq.c
index 7470004ca810..394d250a1ad8 100644
--- a/drivers/base/power/wakeirq.c
+++ b/drivers/base/power/wakeirq.c
@@ -50,9 +50,16 @@ static int dev_pm_attach_wake_irq(struct device *dev, int
irq,
err = device_wakeup_attach_irq(dev, wirq);
if (err)
- return err;
+ goto err_cleanup;
return 0;
+
+err_cleanup:
+ spin_lock_irqsave(dev-power.lock, flags);
+ dev-power.wakeirq = NULL;
+ spin_unlock_irqrestore(dev-power.lock, flags);
+
+ return err;
}
Too many labels for me and the fact that acquiring of the lock again in the
error
patch doesn't look good.
However, we can do the entire device_wakeup_attach_irq() under the lock (after
removing the locking from it), because we're its only caller.
So what about the below instead (build-tested only)?
Rafael
---
drivers/base/power/wakeirq.c | 12 +---
drivers/base/power/wakeup.c | 31 ++-
2 files changed, 15 insertions(+), 28 deletions(-)
Index: linux-pm/drivers/base/power/wakeirq.c
===
--- linux-pm.orig/drivers/base/power/wakeirq.c
+++ linux-pm/drivers/base/power/wakeirq.c
@@ -45,14 +45,12 @@ static int dev_pm_attach_wake_irq(struct
return -EEXIST;
}
- dev-power.wakeirq = wirq;
- spin_unlock_irqrestore(dev-power.lock, flags);
-
err = device_wakeup_attach_irq(dev, wirq);
- if (err)
- return err;
+ if (!err)
+ dev-power.wakeirq = wirq;
- return 0;
+ spin_unlock_irqrestore(dev-power.lock, flags);
+ return err;
}
/**
@@ -105,10 +103,10 @@ void dev_pm_clear_wake_irq(struct device
return;
spin_lock_irqsave(dev-power.lock, flags);
+ device_wakeup_detach_irq(dev);
dev-power.wakeirq = NULL;
spin_unlock_irqrestore(dev-power.lock, flags);
- device_wakeup_detach_irq(dev);
if (wirq-dedicated_irq)
free_irq(wirq-irq, wirq);
kfree(wirq);
Index: linux-pm/drivers/base/power/wakeup.c
===
--- linux-pm.orig/drivers/base/power/wakeup.c
+++ linux-pm/drivers/base/power/wakeup.c
@@ -281,32 +281,25 @@ EXPORT_SYMBOL_GPL(device_wakeup_enable);
* Attach a device wakeirq to the wakeup source so the device
* wake IRQ can be configured automatically for suspend and
* resume.
+ *
+ * Call under the device's power.lock lock.
*/
int device_wakeup_attach_irq(struct device *dev,
struct wake_irq *wakeirq)
{
struct wakeup_source *ws;
- int ret = 0;
- spin_lock_irq(dev-power.lock);
ws = dev-power.wakeup;
if (!ws) {
dev_err(dev, forgot to call call device_init_wakeup?\n);
- ret = -EINVAL;
- goto unlock;
+ return -EINVAL;
}
- if (ws-wakeirq) {
- ret = -EEXIST;
- goto unlock;
- }
+ if (ws-wakeirq)
+ return -EEXIST;
ws-wakeirq = wakeirq;
-
-unlock:
- spin_unlock_irq(dev-power.lock);
-
- return ret;
+ return 0;
}
/**
@@ -314,20 +307,16 @@ unlock:
* @dev: Device to handle
*
* Removes a device wakeirq from the wakeup source.
+ *
+ * Call under the device's power.lock lock.
*/
void device_wakeup_detach_irq(struct device *dev)
{
struct wakeup_source *ws;
- spin_lock_irq(dev-power.lock);
ws = dev-power.wakeup;
- if (!ws)
- goto unlock;
-
- ws-wakeirq = NULL;
-
-unlock:
- spin_unlock_irq(dev-power.lock);
+ if (ws)
+ ws-wakeirq = NULL;
}
/**
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] base: power: wakeirq: don't leak dev-power.wakeirq
Hi On Mon, Jul 6, 2015 at 8:09 PM, Felipe Balbi ba...@ti.com wrote: On Mon, Jul 06, 2015 at 08:06:17PM +0200, Michael Trimarchi wrote: Hi On Jul 6, 2015 8:01 PM, Felipe Balbi ba...@ti.com wrote: on a first call to dev_pm_attach_wake_irq(), if it fails, it will leave dev-power.wakeirq set to a dangling pointer. Instead, let's clear it to make sure a subsequent call to dev_pm_attach_wake_irq() has chance to succeed. Cc: Tony Lindgren tml...@atomide.com Signed-off-by: Felipe Balbi ba...@ti.com --- drivers/base/power/wakeirq.c | 9 - 1 file changed, 8 insertions(+), 1 deletion(-) diff --git a/drivers/base/power/wakeirq.c b/drivers/base/power/wakeirq.c index 7470004ca810..394d250a1ad8 100644 --- a/drivers/base/power/wakeirq.c +++ b/drivers/base/power/wakeirq.c @@ -50,9 +50,16 @@ static int dev_pm_attach_wake_irq(struct device *dev, int irq, err = device_wakeup_attach_irq(dev, wirq); if (err) - return err; + goto err_cleanup; return 0; + +err_cleanup: + spin_lock_irqsave(dev-power.lock, flags); + dev-power.wakeirq = NULL; + spin_unlock_irqrestore(dev-power.lock, flags); + Why here and not in the fuction that return the error? because the field was set here, why would I clear it elsewhere ? Clear now and even more from the other patch proposal. Michael -- balbi -- | Michael Nazzareno Trimarchi Amarula Solutions BV | | COO - Founder Cruquiuskade 47 | | +31(0)851119172 Amsterdam 1018 AM NL | | [`as] http://www.amarulasolutions.com | -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v4] clk: change clk_ops' -determine_rate() prototype
Hi Stephen,
On Mon, 6 Jul 2015 14:32:10 -0700
Stephen Boyd sb...@codeaurora.org wrote:
On 07/06, Boris Brezillon wrote:
Clock rates are stored in an unsigned long field, but -determine_rate()
(which returns a rounded rate from a requested one) returns a long
value (errors are reported using negative error codes), which can lead
to long overflow if the clock rate exceed 2Ghz.
Change -determine_rate() prototype to return 0 or an error code, and pass
a pointer to a clk_rate_request structure containing the expected target
rate and the rate constraints imposed by clk users.
The clk_rate_request structure might be extended in the future to contain
other kind of constraints like the rounding policy, the maximum clock
inaccuracy or other things that are not yet supported by the CCF
(power consumption constraints ?).
Signed-off-by: Boris Brezillon boris.brezil...@free-electrons.com
Which files did you compile?
drivers/clk/mmp/clk-mix.c: In function ‘mmp_clk_mix_determine_rate’:
drivers/clk/mmp/clk-mix.c:221:13: error: ‘rate’ undeclared (first use in this
function)
Hm, I only compile tested the multi_v5 and multi_v7 defconfigs, and
obviously it was a bad idea (just thought all the impacted platforms
were already converted to multiplatform support).
[...]
-long omap3_noncore_dpll_determine_rate(struct clk_hw *hw, unsigned long
rate,
- unsigned long min_rate,
- unsigned long max_rate,
- unsigned long *best_parent_rate,
- struct clk_hw **best_parent_clk)
+int omap3_noncore_dpll_determine_rate(struct clk_hw *hw,
+ struct clk_rate_request *req)
{
struct clk_hw_omap *clk = to_clk_hw_omap(hw);
struct dpll_data *dd;
- if (!hw || !rate)
+ if (!hw || !req || !req-rate)
Why do we need to check for req? It shouldn't be NULL.
We don't, I'll remove this test.
[...]
-long omap4_dpll_regm4xen_determine_rate(struct clk_hw *hw, unsigned long
rate,
- unsigned long min_rate,
- unsigned long max_rate,
- unsigned long *best_parent_rate,
- struct clk_hw **best_parent_clk)
+int omap4_dpll_regm4xen_determine_rate(struct clk_hw *hw,
+ struct clk_rate_request *req)
{
struct clk_hw_omap *clk = to_clk_hw_omap(hw);
struct dpll_data *dd;
- if (!hw || !rate)
+ if (!hw || !req || !req-rate)
Same comment here. And why would we care about hw being NULL
either for that matter.
Yes, but I'm not sure this removal should be done in the same patch.
Let me know if you think otherwise.
-static long mmc_clk_determine_rate(struct clk_hw *hw, unsigned long rate,
- unsigned long min_rate,
- unsigned long max_rate,
- unsigned long *best_parent_rate,
- struct clk_hw **best_parent_p)
+static int mmc_clk_determine_rate(struct clk_hw *hw,
+ struct clk_rate_request *req)
{
struct clk_mmc *mclk = to_mmc(hw);
- unsigned long best = 0;
- if ((rate = 1300) (mclk-id == HI3620_MMC_CIUCLK1)) {
- rate = 1300;
- best = 2600;
- } else if (rate = 2600) {
- rate = 2500;
- best = 18000;
- } else if (rate = 5200) {
- rate = 5000;
- best = 36000;
- } else if (rate = 1) {
- rate = 1;
- best = 72000;
+ req-best_parent_hw = __clk_get_hw(__clk_get_parent(hw-clk));
+
Where did this come from? We weren't setting the best_parent_p
pointer before.
It comes from a previous version where I was not assigning the
-best_parent_hw field to the current parent in the core code.
I fixed it in the meantime, but forgot to remove this assignment.
-static long
-clk_pll_determine_rate(struct clk_hw *hw, unsigned long rate,
- unsigned long min_rate, unsigned long max_rate,
- unsigned long *p_rate, struct clk_hw **p)
+static int
+clk_pll_determine_rate(struct clk_hw *hw, struct clk_rate_request *req)
{
+ struct clk *parent = __clk_get_parent(hw-clk);
struct clk_pll *pll = to_clk_pll(hw);
const struct pll_freq_tbl *f;
- f = find_freq(pll-freq_tbl, rate);
+ req-best_parent_hw = __clk_get_hw(parent);
+ req-best_parent_rate = __clk_get_rate(parent);
+
+ f = find_freq(pll-freq_tbl, req-rate);
if (!f)
- return clk_pll_recalc_rate(hw, *p_rate);
+ req-rate = clk_pll_recalc_rate(hw, req-best_parent_rate);
+ else
+ req-rate = f-freq;
return f-freq;
return 0?
Re: [PATCH 0/3] omap_hsmmc: Fix card enumeration failure on
On Tuesday 16 June 2015 04:07 PM, Vignesh R wrote: Hi, When using omap_hsmmc driver, if sd-card repeatedly plug unplugged multiple times quickly, card enumeration stops after few iterations. This can be easily reproduced on DRA74X EVM which uses omap_hsmmc driver. This patch series addresses the above problem. The first patch fixes irq handler to report all DTOs to mmc-core. Second patch adds handling for BADA, DEB and CEB interrupts. The last patch introduces driver specific card detect irq handler to cleanup pending requests before card removal. Tested on DRA74X amd DRA72X and AM437X-GP EVMs, by repeated intense plug/unplug iterations. Gentle ping... -- Regards Vignesh -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 0/5] Add support for PWMSS on DRA7
On Wednesday 03 June 2015 05:21 PM, Vignesh R wrote: Hi, This patch series adds support for PWMSS on DRA7. The IP is same as that present in AM33XX and AM43XX. The first patch changes clock domain in which PWMSS is present (l4per2_7xx_clkdm) to SW_WKUP. This is because legacy IPs like PWM does'nt support HW_AUTO prorperly. Hence, switch clock domain to SW_WKUP. This is based on the input from the hardware team. The rest of the patches add hwmod and dt entries and enable PWMSS on DRA7 based SoCs. Gentle ping... -- Regards Vignesh -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] thermal: consistently use int for temperatures
The thermal code uses int, long and unsigned long for temperatures
in different places.
Using an unsigned type limits the thermal framework to positive
temperatures without need. Also several drivers currently will report
temperatures near UINT_MAX for temperatures below 0°C. This will probably
immediately shut the machine down due to overtemperature if started below
0°C.
'long' is 64bit on several architectures. This is not needed since INT_MAX °mC
is above the melting point of all known materials.
Consistently use a plain 'int' for temperatures throughout the thermal code and
the drivers. This only changes the places in the drivers where the temperature
is passed around as pointer, when drivers internally use another type this is
not changed.
Signed-off-by: Sascha Hauer s.ha...@pengutronix.de
Cc: Zhang Rui rui.zh...@intel.com
Cc: Eduardo Valentin edubez...@gmail.com
Cc: linux...@vger.kernel.org
Cc: linux-ker...@vger.kernel.org
Cc: Jean Delvare jdelv...@suse.de
Cc: Peter Feuerer pe...@piie.net
Cc: Heiko Stuebner he...@sntech.de
Cc: Lukasz Majewski l.majew...@samsung.com
Cc: Stephen Warren swar...@wwwdotorg.org
Cc: Thierry Reding thierry.red...@gmail.com
Cc: linux-a...@vger.kernel.org
Cc: platform-driver-...@vger.kernel.org
Cc: linux-arm-ker...@lists.infradead.org
Cc: linux-omap@vger.kernel.org
Cc: linux-samsung-...@vger.kernel.org
Cc: Guenter Roeck li...@roeck-us.net
Cc: Rafael J. Wysocki r...@rjwysocki.net
Cc: Maxime Ripard maxime.rip...@free-electrons.com
Cc: Darren Hart dvh...@infradead.org
Cc: lm-sens...@lm-sensors.org
---
drivers/acpi/thermal.c | 12 +-
drivers/hwmon/lm75.c | 2 +-
drivers/hwmon/ntc_thermistor.c | 2 +-
drivers/hwmon/tmp102.c | 2 +-
drivers/input/touchscreen/sun4i-ts.c | 8 +++
drivers/platform/x86/acerhdf.c | 9
drivers/platform/x86/intel_mid_thermal.c | 9
drivers/power/power_supply_core.c | 2 +-
drivers/thermal/armada_thermal.c | 2 +-
drivers/thermal/db8500_thermal.c | 7 +++---
drivers/thermal/dove_thermal.c | 2 +-
drivers/thermal/fair_share.c | 2 +-
drivers/thermal/gov_bang_bang.c| 5 ++--
drivers/thermal/hisi_thermal.c | 4 ++--
drivers/thermal/imx_thermal.c | 27 +++---
drivers/thermal/int340x_thermal/int3400_thermal.c | 2 +-
.../thermal/int340x_thermal/int340x_thermal_zone.c | 10
.../thermal/int340x_thermal/int340x_thermal_zone.h | 8 +++
.../int340x_thermal/processor_thermal_device.c | 4 ++--
drivers/thermal/intel_quark_dts_thermal.c | 13 +--
drivers/thermal/intel_soc_dts_iosf.c | 8 +++
drivers/thermal/kirkwood_thermal.c | 2 +-
drivers/thermal/of-thermal.c | 14 +--
drivers/thermal/power_allocator.c | 16 ++---
drivers/thermal/qcom-spmi-temp-alarm.c | 2 +-
drivers/thermal/rcar_thermal.c | 7 +++---
drivers/thermal/rockchip_thermal.c | 10
drivers/thermal/samsung/exynos_tmu.c | 23 +-
drivers/thermal/spear_thermal.c| 2 +-
drivers/thermal/st/st_thermal.c| 5 ++--
drivers/thermal/step_wise.c| 4 ++--
drivers/thermal/tegra_soctherm.c | 4 ++--
drivers/thermal/thermal_core.c | 26 ++---
drivers/thermal/thermal_hwmon.c| 10
drivers/thermal/ti-soc-thermal/ti-thermal-common.c | 10
drivers/thermal/x86_pkg_temp_thermal.c | 10
include/linux/thermal.h| 26 +
37 files changed, 148 insertions(+), 163 deletions(-)
diff --git a/drivers/acpi/thermal.c b/drivers/acpi/thermal.c
index 6d4e44e..e66ad25 100644
--- a/drivers/acpi/thermal.c
+++ b/drivers/acpi/thermal.c
@@ -529,8 +529,7 @@ static void acpi_thermal_check(void *data)
/* sys I/F for generic thermal sysfs support */
-static int thermal_get_temp(struct thermal_zone_device *thermal,
- unsigned long *temp)
+static int thermal_get_temp(struct thermal_zone_device *thermal, int *temp)
{
struct acpi_thermal *tz = thermal-devdata;
int result;
@@ -637,7 +636,7 @@ static int thermal_get_trip_type(struct thermal_zone_device
*thermal,
}
static int thermal_get_trip_temp(struct thermal_zone_device *thermal,
-int trip, unsigned long *temp)
+int trip, int *temp)
{
struct acpi_thermal *tz = thermal-devdata;
int i;
@@ -690,7 +689,8 @@ static int thermal_get_trip_temp(struct thermal_zone_device
*thermal,
[PATCH] pinctrl: single: dra7: remove PCS_QUIRK_SHARED_IRQ
On DRA7 there is one pinctrl domain (dra7_pmx_core) and
PRCM wake-up IRQ is not shared, so remove quirk.
Cc: Nishanth Menon n...@ti.com
Cc: Tony Lindgren t...@atomide.com
Fixes: 31320beaa3d3 ('pinctrl: single: Add DRA7 pinctrl compatibility')
Signed-off-by: Grygorii Strashko grygorii.stras...@ti.com
---
drivers/pinctrl/pinctrl-single.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/drivers/pinctrl/pinctrl-single.c b/drivers/pinctrl/pinctrl-single.c
index 0b8d480..9b24b343 100644
--- a/drivers/pinctrl/pinctrl-single.c
+++ b/drivers/pinctrl/pinctrl-single.c
@@ -1983,7 +1983,6 @@ static const struct pcs_soc_data pinctrl_single_omap_wkup
= {
};
static const struct pcs_soc_data pinctrl_single_dra7 = {
- .flags = PCS_QUIRK_SHARED_IRQ,
.irq_enable_mask = (1 24), /* WAKEUPENABLE */
.irq_status_mask = (1 25), /* WAKEUPEVENT */
};
--
2.4.5
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] clocksource: Allow toggling between runtime and persistent clocksource for idle
Hi,
* Thomas Gleixner t...@linutronix.de [150706 07:20]:
On Mon, 6 Jul 2015, Tony Lindgren wrote:
Some persistent clocksources can be on a slow external bus. For shorter
latencies for RT use, let's allow toggling the clocksource during idle
between a faster non-persistent runtime clocksource and a slower persistent
clocksource.
I really cannot follow that RT argument here. The whole switchover
causes latencies itself and whats worse is, that this breaks
timekeeping accuracy because there is no way to switch clocksources
atomically without loss.
It would be during deeper idle states.. But yeah the RT use would be
better replaced in the description with with lower runtime timer
latency.
The timekeeping accuracy issue certainly needs some thinking, and
also the resolution between the clocksources can be different.. In the
test case I have the slow timer is always on and of a lower resolution
than the ARM global timer being used during runtime.
Got some handy timer test in mind you want me to run to provide data
on the accuracy?
---
include/linuxt-email-lkml-omap/clocksource.h | 2 ++
Interesting file name.
Heh that needs to go back to sed land :)
extern int timekeeping_notify(struct clocksource *clock);
+extern int clocksource_pm_enter(void);
+extern void clocksource_pm_exit(void);
Unfortunately you are not providing the call site, so I cannot see
from which context this is going to be called.
I fear its from the guts of the idle code probably with interrupts
disabled etc , right?
Yes from the last cpu active in cpuidle. Here's the related snippet
in my case:
--- a/arch/arm/mach-omap2/cpuidle44xx.c
+++ b/arch/arm/mach-omap2/cpuidle44xx.c
@@ -111,6 +111,7 @@ static int omap_enter_idle_coupled(struct cpuidle_device
*dev,
(cx-mpu_logic_state == PWRDM_POWER_OFF);
tick_broadcast_enter();
+ clocksource_pm_enter();
/*
* Call idle CPU PM enter notifier chain so that
@@ -167,6 +168,7 @@ static int omap_enter_idle_coupled(struct cpuidle_device
*dev,
if (dev-cpu == 0 mpuss_can_lose_context)
cpu_cluster_pm_exit();
+ clocksource_pm_exit();
tick_broadcast_exit();
fail:
+/**
+ * clocksource_pm_enter - change to a persistent clocksource before idle
+ *
+ * Changes system to use a persistent clocksource for idle. Intended to
+ * be called from CPUidle from the last active CPU.
+ */
+int clocksource_pm_enter(void)
+{
+ bool oneshot = tick_oneshot_mode_active();
+ struct clocksource *best;
+
+ if (WARN_ONCE(!mutex_trylock(clocksource_mutex),
+ Unable to get clocksource_mutex))
+ return -EINTR;
This trylock serves which purpose?
Well we don't want to start changing clocksource if something is
running like you pointed out.
+ best = clocksource_find_best(oneshot, true, false);
+ if (best) {
+ if (curr_clocksource != best
+ !timekeeping_notify(best)) {
+ runtime_clocksource = curr_clocksource;
+ curr_clocksource = best;
+ }
+ }
+ mutex_unlock(clocksource_mutex);
+
+ return !!best;
+}
+
+/**
+ * clocksource_pm_exit - change to a runtime clocksrouce after idle
+ *
+ * Changes system to use the best clocksource for runtime. Intended to
+ * be called after waking up from CPUidle on the first active CPU.
+ */
+void clocksource_pm_exit(void)
+{
+ if (WARN_ONCE(!mutex_trylock(clocksource_mutex),
+ Unable to get clocksource_mutex))
+ return;
+
+ if (runtime_clocksource) {
+ if (curr_clocksource != runtime_clocksource
+ !timekeeping_notify(runtime_clocksource)) {
+ curr_clocksource = runtime_clocksource;
+ runtime_clocksource = NULL;
+ }
+ }
+ mutex_unlock(clocksource_mutex);
+}
I really cannot see how this is proper serialized.
We need to allow this only from the last cpu before hitting idle.
#ifdef CONFIG_SYSFS
/**
* sysfs_show_current_clocksources - sysfs interface for current
clocksource
diff --git a/kernel/time/timekeeping.c b/kernel/time/timekeeping.c
index bca3667..0379260 100644
--- a/kernel/time/timekeeping.c
+++ b/kernel/time/timekeeping.c
@@ -1086,7 +1086,18 @@ int timekeeping_notify(struct clocksource *clock)
if (tk-tkr_mono.clock == clock)
return 0;
- stop_machine(change_clocksource, clock, NULL);
+
+ /*
+* We may want to toggle between a fast and a persistent
+* clocksource from CPUidle on the last active CPU and can't
+* use stop_machine at that point.
+*/
+ if (cpumask_test_cpu(smp_processor_id(), cpu_online_mask)
Can you please explain how this code gets called from an offline cpu?
Last cpu getting idled..
+ !rcu_is_watching())
So
Re: [RESEND] [PATCH v2 1/2] arm: devtree: Set system_rev from DT revision
On Mon, Jul 6, 2015 at 7:31 AM, Tony Lindgren t...@atomide.com wrote: * Pali Rohár pali.ro...@gmail.com [150706 05:25]: into which file should I put documentation about new DT properties? If it's Linux generic like linux,revision, then how about Just revision at the top level please. I'd prefer a string still, but either is fine. Rob -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 0/2] extcon: fixes for v4.2-rc1
Hi, First patch fixes kernel hang and incorrect states when extcon_get/set_cable_state() is used. Second patch fixes extcon_cable_get_state() users from getting old state after notifier callback. cheers, -roger Roger Quadros (2): extcon: fix hang and extcon_get/set_cable_state(). extcon: Fix extcon_cable_get_state() from getting old state after notification drivers/extcon/extcon.c | 50 - 1 file changed, 37 insertions(+), 13 deletions(-) -- 2.1.4 -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] gpio: omap: prevent module from being unloaded while in use
On 06/30/2015 04:52 PM, Alexandre Courbot wrote:
On Fri, Jun 26, 2015 at 12:13 AM, Grygorii Strashko
grygorii.stras...@ti.com wrote:
OMAP GPIO driver allowed to be built as loadable module, but it
doesn't set owner field in GPIO chip structure. As result,
module_get/put() API is not working and it's possible to unload
OMAP driver while in use:
omap_gpio 48051000.gpio: REMOVING GPIOCHIP WITH GPIOS STILL REQUESTED
Hence, add missing configuration.
Isn't this also fixed by your other patch gpiolib: assign chip owner
to dev-driver-owner if not set?
Nevertheless,
Acked-by: Alexandre Courbot acour...@nvidia.com
For inclusion into -rc if the other patch is for the next cycle.
Yes. I've sent this one for -rc as it's 100% fix and was not sure about
destiny of patch gpiolib: assign chip owner.. :)
Cc: Tony Lindgren t...@atomide.com
Fixes: cac089f9026e ('gpio: omap: Allow building as a loadable module')
Signed-off-by: Grygorii Strashko grygorii.stras...@ti.com
---
Hi Linus,
Seems this one is for 4.2-rc.
drivers/gpio/gpio-omap.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/gpio/gpio-omap.c b/drivers/gpio/gpio-omap.c
index a0ad803..61a731f 100644
--- a/drivers/gpio/gpio-omap.c
+++ b/drivers/gpio/gpio-omap.c
@@ -1187,6 +1187,7 @@ static int omap_gpio_probe(struct platform_device
*pdev)
bank-irq = res-start;
bank-dev = dev;
bank-chip.dev = dev;
+ bank-chip.owner = THIS_MODULE;
bank-dbck_flag = pdata-dbck_flag;
bank-stride = pdata-bank_stride;
bank-width = pdata-bank_width;
--
2.4.4
--
regards,
-grygorii
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] pinctrl: single: dra7: remove PCS_QUIRK_SHARED_IRQ
* Grygorii Strashko grygorii.stras...@ti.com [150706 08:14]:
On DRA7 there is one pinctrl domain (dra7_pmx_core) and
PRCM wake-up IRQ is not shared, so remove quirk.
Cc: Nishanth Menon n...@ti.com
Cc: Tony Lindgren t...@atomide.com
Fixes: 31320beaa3d3 ('pinctrl: single: Add DRA7 pinctrl compatibility')
Signed-off-by: Grygorii Strashko grygorii.stras...@ti.com
---
drivers/pinctrl/pinctrl-single.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/drivers/pinctrl/pinctrl-single.c
b/drivers/pinctrl/pinctrl-single.c
index 0b8d480..9b24b343 100644
--- a/drivers/pinctrl/pinctrl-single.c
+++ b/drivers/pinctrl/pinctrl-single.c
@@ -1983,7 +1983,6 @@ static const struct pcs_soc_data
pinctrl_single_omap_wkup = {
};
static const struct pcs_soc_data pinctrl_single_dra7 = {
- .flags = PCS_QUIRK_SHARED_IRQ,
.irq_enable_mask = (1 24), /* WAKEUPENABLE */
.irq_status_mask = (1 25), /* WAKEUPEVENT */
};
Tero, care to take a look at this one and ack if OK?
Regards,
Tony
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] clocksource: Allow toggling between runtime and persistent clocksource for idle
On Mon, 6 Jul 2015, Tony Lindgren wrote:
Some persistent clocksources can be on a slow external bus. For shorter
latencies for RT use, let's allow toggling the clocksource during idle
between a faster non-persistent runtime clocksource and a slower persistent
clocksource.
I really cannot follow that RT argument here. The whole switchover
causes latencies itself and whats worse is, that this breaks
timekeeping accuracy because there is no way to switch clocksources
atomically without loss.
---
include/linuxt-email-lkml-omap/clocksource.h | 2 ++
Interesting file name.
extern int timekeeping_notify(struct clocksource *clock);
+extern int clocksource_pm_enter(void);
+extern void clocksource_pm_exit(void);
Unfortunately you are not providing the call site, so I cannot see
from which context this is going to be called.
I fear its from the guts of the idle code probably with interrupts
disabled etc , right?
+/**
+ * clocksource_pm_enter - change to a persistent clocksource before idle
+ *
+ * Changes system to use a persistent clocksource for idle. Intended to
+ * be called from CPUidle from the last active CPU.
+ */
+int clocksource_pm_enter(void)
+{
+ bool oneshot = tick_oneshot_mode_active();
+ struct clocksource *best;
+
+ if (WARN_ONCE(!mutex_trylock(clocksource_mutex),
+ Unable to get clocksource_mutex))
+ return -EINTR;
This trylock serves which purpose?
+
+ best = clocksource_find_best(oneshot, true, false);
+ if (best) {
+ if (curr_clocksource != best
+ !timekeeping_notify(best)) {
+ runtime_clocksource = curr_clocksource;
+ curr_clocksource = best;
+ }
+ }
+ mutex_unlock(clocksource_mutex);
+
+ return !!best;
+}
+
+/**
+ * clocksource_pm_exit - change to a runtime clocksrouce after idle
+ *
+ * Changes system to use the best clocksource for runtime. Intended to
+ * be called after waking up from CPUidle on the first active CPU.
+ */
+void clocksource_pm_exit(void)
+{
+ if (WARN_ONCE(!mutex_trylock(clocksource_mutex),
+ Unable to get clocksource_mutex))
+ return;
+
+ if (runtime_clocksource) {
+ if (curr_clocksource != runtime_clocksource
+ !timekeeping_notify(runtime_clocksource)) {
+ curr_clocksource = runtime_clocksource;
+ runtime_clocksource = NULL;
+ }
+ }
+ mutex_unlock(clocksource_mutex);
+}
I really cannot see how this is proper serialized.
#ifdef CONFIG_SYSFS
/**
* sysfs_show_current_clocksources - sysfs interface for current clocksource
diff --git a/kernel/time/timekeeping.c b/kernel/time/timekeeping.c
index bca3667..0379260 100644
--- a/kernel/time/timekeeping.c
+++ b/kernel/time/timekeeping.c
@@ -1086,7 +1086,18 @@ int timekeeping_notify(struct clocksource *clock)
if (tk-tkr_mono.clock == clock)
return 0;
- stop_machine(change_clocksource, clock, NULL);
+
+ /*
+ * We may want to toggle between a fast and a persistent
+ * clocksource from CPUidle on the last active CPU and can't
+ * use stop_machine at that point.
+ */
+ if (cpumask_test_cpu(smp_processor_id(), cpu_online_mask)
Can you please explain how this code gets called from an offline cpu?
+ !rcu_is_watching())
So pick some random combination of conditions and define that it is
correct, right? How on earth does !rcu_watching() tell that this is
the last running cpu.
+ change_clocksource(clock);
+ else
+ stop_machine(change_clocksource, clock, NULL);
This patch definitely earns a place in my ugly code museum under the
category 'Does not explode in my face, so it must be correct'.
Thanks,
tglx
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] pinctrl: single: ensure pcs irq will not be forced threaded
The PSC IRQ is requested using request_irq() API and as result it can
be forced to be threaded IRQ in RT-Kernel if PCS_QUIRK_HAS_SHARED_IRQ
is enabled for pinctrl domain.
As result, following 'possible irq lock inversion dependency' report
can be seen:
=
[ INFO: possible irq lock inversion dependency detected ]
3.14.43-rt42-00360-g96ff499-dirty #24 Not tainted
-
irq/369-pinctrl/927 just changed the state of lock:
(pcs-lock){+.}, at: [c0375b54] pcs_irq_handle+0x48/0x9c
but this lock was taken by another, HARDIRQ-safe lock in the past:
(irq_desc_lock_class){-.}
and interrupts could create inverse lock ordering between them.
other info that might help us debug this:
Possible interrupt unsafe locking scenario:
CPU0CPU1
lock(pcs-lock);
local_irq_disable();
lock(irq_desc_lock_class);
lock(pcs-lock);
Interrupt
lock(irq_desc_lock_class);
*** DEADLOCK ***
no locks held by irq/369-pinctrl/927.
the shortest dependencies between 2nd lock and 1st lock:
- (irq_desc_lock_class){-.} ops: 58724 {
IN-HARDIRQ-W at:
[c0090040] lock_acquire+0x9c/0x158
[c07065c8] _raw_spin_lock+0x48/0x58
[c009edac] handle_fasteoi_irq+0x24/0x15c
[c009abb0] generic_handle_irq+0x3c/0x4c
[c000f83c] handle_IRQ+0x50/0xa0
[c0008674] gic_handle_irq+0x3c/0x6c
[c0707a04] __irq_svc+0x44/0x8c
[c000fc44] arch_cpu_idle+0x40/0x4c
[c009aadc] cpu_startup_entry+0x270/0x2e0
[c06fcbf8] rest_init+0xd4/0xe4
[c0a44bfc] start_kernel+0x3d0/0x3dc
[80008084] 0x80008084
INITIAL USE at:
[c0090040] lock_acquire+0x9c/0x158
[c070674c] _raw_spin_lock_irqsave+0x54/0x68
[c009aff8] __irq_get_desc_lock+0x64/0xa4
[c009e38c] irq_set_chip+0x30/0x78
[c009ec30] irq_set_chip_and_handler_name+0x24/0x3c
[c036ca10] gic_irq_domain_map+0x48/0xb4
[c00a0a80] irq_domain_associate+0x84/0x1d4
[c00a1154] irq_create_mapping+0x80/0x11c
[c00a1270] irq_create_of_mapping+0x80/0x120
[c05cdaa8] irq_of_parse_and_map+0x34/0x3c
[c0a4ea24] omap_dm_timer_init_one+0x90/0x30c
[c0a4eef0] omap5_realtime_timer_init+0x8c/0x48c
[c0a486b0] time_init+0x28/0x38
[c0a44a6c] start_kernel+0x240/0x3dc
[80008084] 0x80008084
}
... key at: [c1049ce0] irq_desc_lock_class+0x0/0x8
... acquired at:
[c07065c8] _raw_spin_lock+0x48/0x58
[c0375a90] pcs_irq_unmask+0x58/0xa0
[c009ea48] irq_enable+0x38/0x48
[c009ead0] irq_startup+0x78/0x7c
[c009d440] __setup_irq+0x4a8/0x4f4
[c009d5dc] request_threaded_irq+0xb8/0x138
[c0415a5c] omap_8250_startup+0x4c/0x148
[c041276c] serial8250_startup+0x24/0x30
[c040d0ec] uart_startup.part.9+0x5c/0x1b4
[c040dbcc] uart_open+0xf4/0x16c
[c03f0540] tty_open+0x170/0x61c
[c0157028] chrdev_open+0xbc/0x1b4
[c0150494] do_dentry_open+0x1e8/0x2bc
[c0150a84] finish_open+0x44/0x5c
[c0160d50] do_last.isra.47+0x710/0xca0
[c01613a4] path_openat+0xc4/0x640
[c0162904] do_filp_open+0x3c/0x98
[c0151bdc] do_sys_open+0x114/0x1d8
[c0151cc8] SyS_open+0x28/0x2c
[c0a44d70] kernel_init_freeable+0x168/0x1e4
[c06fcc24] kernel_init+0x1c/0xf8
[c000eee8] ret_from_fork+0x14/0x20
- (pcs-lock){+.} ops: 65 {
HARDIRQ-ON-W at:
[c0090040] lock_acquire+0x9c/0x158
[c07065c8] _raw_spin_lock+0x48/0x58
[c0375b54] pcs_irq_handle+0x48/0x9c
[c0375c5c] pcs_irq_handler+0x1c/0x28
[c009c458] irq_forced_thread_fn+0x30/0x74
[c009c784] irq_thread+0x158/0x1c4
[c0063fc4] kthread+0xd4/0xe8
[c000eee8] ret_from_fork+0x14/0x20
INITIAL USE at:
[c0090040] lock_acquire+0x9c/0x158
[c070674c] _raw_spin_lock_irqsave+0x54/0x68
[c0375344] pcs_enable+0x7c/0xe8
[c0372a44] pinmux_enable_setting+0x178/0x220
[c036fecc] pinctrl_select_state+0x110/0x194
[c04732dc] pinctrl_bind_pins+0x7c/0x108
[c045853c] driver_probe_device+0x70/0x254
[c0458810] __driver_attach+0x9c/0xa0
[c045674c] bus_for_each_dev+0x78/0xac
[c0458030] driver_attach+0x2c/0x30
Re: [PATCH] pinctrl: single: ensure pcs irq will not be forced threaded
* Grygorii Strashko grygorii.stras...@ti.com [150706 08:16]:
The PSC IRQ is requested using request_irq() API and as result it can
be forced to be threaded IRQ in RT-Kernel if PCS_QUIRK_HAS_SHARED_IRQ
is enabled for pinctrl domain.
As result, following 'possible irq lock inversion dependency' report
can be seen:
...
To fix it use IRQF_NO_THREAD to ensure that pcs irq will not be forced
threaded.
Cc: Tony Lindgren t...@atomide.com
Cc: Sebastian Andrzej Siewior bige...@linutronix.de
Signed-off-by: Grygorii Strashko grygorii.stras...@ti.com
---
drivers/pinctrl/pinctrl-single.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/pinctrl/pinctrl-single.c
b/drivers/pinctrl/pinctrl-single.c
index b2de09d..0b8d480 100644
--- a/drivers/pinctrl/pinctrl-single.c
+++ b/drivers/pinctrl/pinctrl-single.c
@@ -1760,7 +1760,8 @@ static int pcs_irq_init_chained_handler(struct
pcs_device *pcs,
int res;
res = request_irq(pcs_soc-irq, pcs_irq_handler,
- IRQF_SHARED | IRQF_NO_SUSPEND,
+ IRQF_SHARED | IRQF_NO_SUSPEND |
+ IRQF_NO_THREAD,
name, pcs_soc);
if (res) {
pcs_soc-irq = -1;
Looks OK to me. The only case this would be a problem if a system has
a huge number of wake-up events as the list of status registers to
check could grow to the number of GPIO pins in theory. Anyways,
feel free to add:
Acked-by: Tony Lindgren t...@atomide.com
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RESEND] [PATCH v2 1/2] arm: devtree: Set system_rev from DT revision
* Rob Herring robherri...@gmail.com [150706 08:23]: On Mon, Jul 6, 2015 at 7:31 AM, Tony Lindgren t...@atomide.com wrote: * Pali Rohár pali.ro...@gmail.com [150706 05:25]: into which file should I put documentation about new DT properties? If it's Linux generic like linux,revision, then how about Just revision at the top level please. I'd prefer a string still, but either is fine. OK works for me thanks. Tony -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RESEND] [PATCH v2 1/2] arm: devtree: Set system_rev from DT revision
On Mon, Jul 6, 2015 at 8:12 AM, Pali Rohár pali.ro...@gmail.com wrote: On Monday 06 July 2015 14:31:27 Tony Lindgren wrote: * Pali Rohár pali.ro...@gmail.com [150706 05:25]: into which file should I put documentation about new DT properties? If it's Linux generic like linux,revision, then how about Documentation/devicetree/bindings/revision.txt? For the ATAGs, Documentation/devicetree/bindings/arm/atag.txt? Regards, Tony Hm... now I'm thinking into which DT field should I put atags and revision. In previous emails you wrote to use linux,atags, now arm,atags? And put them into root node? Or other? In arch/arm/boot/compressed/atags_to_fdt.c code I see that most atag properties are converted into /chosen node in DT... So what do you prefer for revision and what for atags? Some mentioned examples: /revision This one. This is a top level h/w property. /chosen/revision /linux,revision /chosen/linux,revision ... /atags /chosen/atags /linux,atags /chosen/linux,atags This one. ATAGs are a Linux data struct. Rob /arm,atags /chosen/arm,atags ... -- Pali Rohár pali.ro...@gmail.com -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
