Re: [PATCH v4 2/6] input: touchscreen: ti_am335x_tsc: Remove udelay in interrupt handler
On Mon, Nov 17, 2014 at 09:57:05AM +0530, Vignesh R wrote:
My patches are based on v3.18rc2. I tested my patches on am335x-evm
using tslib.
No beaglebone + cape testing?
Please explain touch is broken? What is the behaviour of TSC?
With plain v3.17 plus your series, the cursor is almost never near the
pen. Mostly it jitters around the right hand edge.
My customer had already changed the step delay (I think by trial and
error, not sure) in order to get the cursor near the pen. I ported
this change onto your series (see patch, below), but still the pen up
event causes a huge cursor jump.
(Again, I did solve the pen up issue, but in a totally different
way. I never posted the fix, because I could not be sure that it would
work on a wide variety of boards.)
Which ADC channels are being used for TSC?
tscadc {
status = okay;
tsc {
ti,wires = 4;
ti,x-plate-resistance = 300;
ti,coordinate-readouts = 5;
ti,wire-config = 0x00 0x11 0x23 0x32;
};
adc {
ti,adc-channels = 5 6 7;
};
};
So for this particular design, your series really does not help, not
even a little. You did not test the series on many boards. I am
concerned that this series only works on the one board you did test,
and that it may break functionality on other people's boards.
Thanks,
Richard
---
diff --git a/drivers/input/touchscreen/ti_am335x_tsc.c
b/drivers/input/touchscreen/ti_am335x_tsc.c
index b84493f..77a4883 100644
--- a/drivers/input/touchscreen/ti_am335x_tsc.c
+++ b/drivers/input/touchscreen/ti_am335x_tsc.c
@@ -148,7 +148,7 @@ static void titsc_step_config(struct titsc *ts_dev)
end_step = first_step + tsc_steps;
for (i = end_step - ts_dev-coordinate_readouts; i end_step; i++) {
titsc_writel(ts_dev, REG_STEPCONFIG(i), config);
- titsc_writel(ts_dev, REG_STEPDELAY(i), STEPCONFIG_OPENDLY);
+ titsc_writel(ts_dev, REG_STEPDELAY(i), STEPCONFIG_OPENDLY |
STEPDELAY_SAMPLE(20));
}
config = 0;
@@ -172,7 +172,7 @@ static void titsc_step_config(struct titsc *ts_dev)
end_step = first_step + ts_dev-coordinate_readouts;
for (i = first_step; i end_step; i++) {
titsc_writel(ts_dev, REG_STEPCONFIG(i), config);
- titsc_writel(ts_dev, REG_STEPDELAY(i), STEPCONFIG_OPENDLY);
+ titsc_writel(ts_dev, REG_STEPDELAY(i), STEPCONFIG_OPENDLY |
STEPDELAY_SAMPLE(20));
}
/* Make CHARGECONFIG same as IDLECONFIG */
@@ -188,13 +188,13 @@ static void titsc_step_config(struct titsc *ts_dev)
STEPCONFIG_INP(ts_dev-inp_xp);
titsc_writel(ts_dev, REG_STEPCONFIG(end_step), config);
titsc_writel(ts_dev, REG_STEPDELAY(end_step),
- STEPCONFIG_OPENDLY);
+ STEPCONFIG_OPENDLY | STEPDELAY_SAMPLE(20));
end_step++;
config |= STEPCONFIG_INP(ts_dev-inp_yn);
titsc_writel(ts_dev, REG_STEPCONFIG(end_step), config);
titsc_writel(ts_dev, REG_STEPDELAY(end_step),
- STEPCONFIG_OPENDLY);
+ STEPCONFIG_OPENDLY | STEPDELAY_SAMPLE(20));
/* The steps end ... end - readouts * 2 + 2 and bit 0 for TS_Charge */
stepenable = 1;
--
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: [RFC] adp1653: Add device tree bindings for LED controller
On Sunday 16 November 2014 08:59:28 Pavel Machek wrote: For device tree people: Yes, I know I'll have to create file in documentation, but does the binding below look acceptable? I'll clean up driver code a bit more, remove the printks. Anything else obviously wrong? Signed-off-by: Pavel Machek pa...@ucw.cz Thanks, Pavel Hello, I think that this patch is probably not good and specially not for n900. adp1653 should be registered throw omap3 isp camera subsystem which does not have DT support yet. See n900 legacy board camera code in file board-rx51-camera.c. -- Pali Rohár pali.ro...@gmail.com signature.asc Description: This is a digitally signed message part.
Re: [PATCH v12 11/15] arm: omap1: Migrate debug_ll macros to use 8250.S
On 16/11/14 00:29, Aaro Koskinen wrote: Hi, On Fri, Oct 24, 2014 at 11:54:32AM +0100, Daniel Thompson wrote: +config DEBUG_OMAP1UART1 +bool Kernel low-level debugging via OMAP1 UART1 +depends on ARCH_OMAP1 +select DEBUG_UART_8250 +help + Say Y here if you want kernel low-level debugging support + on OMAP1 based platforms (expect OMAP730) on the UART1. [...] + on OMAP1 based platforms (expect OMAP730) on the UART2. [...] + on OMAP1 based platforms (expect OMAP730) on the UART3. ^^ Spelling again wrong. I think it was already corrected in v11? Sorry and, yes, you're right this was corrected in v11. I was travelling when I posted v11 so I guess I must have forgot to pull the right branches to my main machine. I will dig it and diff shortly to make sure I didn't miss anything else. Daniel. -- 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: [RFC] adp1653: Add device tree bindings for LED controller
Hi! On Mon 2014-11-17 09:43:19, Pali Rohár wrote: On Sunday 16 November 2014 08:59:28 Pavel Machek wrote: For device tree people: Yes, I know I'll have to create file in documentation, but does the binding below look acceptable? I'll clean up driver code a bit more, remove the printks. Anything else obviously wrong? I think that this patch is probably not good and specially not for n900. adp1653 should be registered throw omap3 isp camera subsystem which does not have DT support yet. Can you explain? adp1653 is independend device on i2c bus, and we have kernel driver for it (unlike rest of n900 camera system). Just now it is unusable due to lack of DT binding. It has two functions, LED light and a camera flash; yes, the second one should be integrated to the rest of camera system, but that is not yet merged. That should not prevent us from merging DT support for the flash, so that this part can be tested/maintained. See n900 legacy board camera code in file board-rx51-camera.c. I have seen that. Pavel -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html -- 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: [RFC] adp1653: Add device tree bindings for LED controller
On Monday 17 November 2014 11:05:19 Pavel Machek wrote: Hi! On Mon 2014-11-17 09:43:19, Pali Rohár wrote: On Sunday 16 November 2014 08:59:28 Pavel Machek wrote: For device tree people: Yes, I know I'll have to create file in documentation, but does the binding below look acceptable? I'll clean up driver code a bit more, remove the printks. Anything else obviously wrong? I think that this patch is probably not good and specially not for n900. adp1653 should be registered throw omap3 isp camera subsystem which does not have DT support yet. Can you explain? adp1653 is independend device on i2c bus, and we have kernel driver for it (unlike rest of n900 camera system). Just now it is unusable due to lack of DT binding. It has two functions, LED light and a camera flash; yes, the second one should be integrated to the rest of camera system, but that is not yet merged. That should not prevent us from merging DT support for the flash, so that this part can be tested/maintained. Ok. When ISP camera subsystem has DT support somebody will modify n900 DT to add camera flash from adp1653 to ISP... I believe it will not be hard. See n900 legacy board camera code in file board-rx51-camera.c. I have seen that. Pavel -- Pali Rohár pali.ro...@gmail.com signature.asc Description: This is a digitally signed message part.
Re: [RFC] adp1653: Add device tree bindings for LED controller
On Mon 2014-11-17 11:09:45, Pali Rohár wrote: On Monday 17 November 2014 11:05:19 Pavel Machek wrote: Hi! On Mon 2014-11-17 09:43:19, Pali Rohár wrote: On Sunday 16 November 2014 08:59:28 Pavel Machek wrote: For device tree people: Yes, I know I'll have to create file in documentation, but does the binding below look acceptable? I'll clean up driver code a bit more, remove the printks. Anything else obviously wrong? I think that this patch is probably not good and specially not for n900. adp1653 should be registered throw omap3 isp camera subsystem which does not have DT support yet. Can you explain? adp1653 is independend device on i2c bus, and we have kernel driver for it (unlike rest of n900 camera system). Just now it is unusable due to lack of DT binding. It has two functions, LED light and a camera flash; yes, the second one should be integrated to the rest of camera system, but that is not yet merged. That should not prevent us from merging DT support for the flash, so that this part can be tested/maintained. Ok. When ISP camera subsystem has DT support somebody will modify n900 DT to add camera flash from adp1653 to ISP... I believe it will not be hard. Exactly. And yes, I'd like to get complete camera support for n900 merged. But first step is make sure existing support does not break. Best regards, Pavel -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html -- 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 3/8] net: can: c_can: Add RAMINIT register information to driver data
On 11/14/2014 07:55 PM, Marc Kleine-Budde wrote:
On 11/07/2014 03:49 PM, Roger Quadros wrote:
Some platforms (e.g. TI) need special RAMINIT register handling.
Provide a way to store RAMINIT register description in driver data.
Signed-off-by: Roger Quadros rog...@ti.com
---
drivers/net/can/c_can/c_can.h | 6 ++
drivers/net/can/c_can/c_can_platform.c | 1 +
2 files changed, 7 insertions(+)
diff --git a/drivers/net/can/c_can/c_can.h b/drivers/net/can/c_can/c_can.h
index 26c975d..3c305a1 100644
--- a/drivers/net/can/c_can/c_can.h
+++ b/drivers/net/can/c_can/c_can.h
@@ -171,6 +171,12 @@ enum c_can_dev_id {
struct c_can_driver_data {
enum c_can_dev_id id;
+
+/* RAMINIT register description. Optional. */
+u8 num_can; /* Number of CAN instances on the SoC */
+u8 *raminit_start_bits; /* Array of START bit positions */
+u8 *raminit_done_bits; /* Array of DONE bit positions */
What do you think about making this a struct:
+struct raminit_bits {
+ u8 start;
+ u8 done;
+};
struct c_can_driver_data {
enum c_can_dev_id id;
+
+ /* RAMINIT register description. Optional. */
+ const struct raminit_bits *raminit_bits; /* Array of START/DONE bit
positions */
+ u8 raminit_num; /* Number of CAN instances on the SoC */
+ bool raminit_pulse; /* If set, sets and clears START bit (pulse)
*/
};
The driver data looks like this:
+static const struct raminit_bits dra7_raminit_bits[] = {
+ [0] = { .start = 3, .done = 1, },
+ [1] = { .start = 5, .done = 2, },
+};
+
+static const struct c_can_driver_data dra7_dcan_drvdata = {
+ .id = BOSCH_D_CAN,
+ .raminit_num = ARRAY_SIZE(dra7_raminit_bits),
+ .raminit_bits = dra7_raminit_bits,
+ .raminit_pulse = true,
+};
I'll send an updated series.
Looks better. Thanks.
cheers,
-roger
--
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 3/8] net: can: c_can: Add RAMINIT register information to driver data
On 11/17/2014 12:17 PM, Roger Quadros wrote: I'll send an updated series. Looks better. Thanks. Can you make a quick test with the new series on real hardware. Thanks, Marc -- Pengutronix e.K. | Marc Kleine-Budde | Industrial Linux Solutions| Phone: +49-231-2826-924 | Vertretung West/Dortmund | Fax: +49-5121-206917- | Amtsgericht Hildesheim, HRA 2686 | http://www.pengutronix.de | signature.asc Description: OpenPGP digital signature
Re: [PATCH v4 3/8] net: can: c_can: Add RAMINIT register information to driver data
On 11/17/2014 01:22 PM, Marc Kleine-Budde wrote: On 11/17/2014 12:17 PM, Roger Quadros wrote: I'll send an updated series. Looks better. Thanks. Can you make a quick test with the new series on real hardware. Yes. I'll let you know in a while and respond on the v8 thread. cheers, -roger -- 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/4] Touchscreen performance related fixes
Hi, On Thursday 13 November 2014 05:53 PM, Vignesh R wrote: Hi, On Wednesday 12 November 2014 06:30 PM, Johannes Pointner wrote: Hello Vignesh, I tried your patch version 3 on a customized board and had some behavior I couldn't explain. If I only use the touchscreen it works fine but if I also read values from the ADCs then I get a lot of pen_up events even if I am still touching the screen. For the test I read via # cat /sys/bus/iio/devices/iio\:device0/in_voltage5_raw values from the ADC in an busy loop as you explained in an email before. Did you also experience such behavior or do you know what causes it? Thanks for testing. I was able to fix this issue. Will post version 4 shortly. Were you able to test the v4 patch series on your board? Is the issue fixed? Regards Vignesh Without the patches the touchscreen works fine during the iio test. Thanks, Hannes 2014-11-06 8:42 GMT+01:00 Vignesh R vigne...@ti.com: On Monday 03 November 2014 11:39 PM, Richard Cochran wrote: On Mon, Oct 27, 2014 at 04:38:27PM +0530, Vignesh R wrote: This series of patches fix TSC defects related to lag in touchscreen performance and cursor jump at touch release. The lag was result of udelay in TSC interrupt handler. Cursor jump due to false pen-up event. The patches implement Advisory 1.0.31 in silicon errata of am335x-evm to avoid false pen-up events and remove udelay. That advisory has two workarounds. You have chosen the second one? Work around one. Hence 5 wire design is not broken. The text of the second workaround says it only works on 4 wire setups, so I wonder how 5 wire designs will be affected. The advisory says to use steps 1 to 4 for ADC and 5 to 16 for TSC (assuming 4 wire TSC and 4 channel ADC). No, it doesn't say that. (sprz360f.pdf) The pen up event detection happens immediately after charge step. Hence, interchanging ADC and TSC steps makes sure that sampling of touch co-ordinates and pen events are done one after the other. This workaround was suggested by internal hardware folks. Earlier ADC steps intervened between sampling of co-ordinates and pen event detection which is not desirable. Further the X co-ordinate must be the last one to be sampled just before charge step. The first two patches implement the required changes. FWIW, I implemented the first workaround and removed the udelay not too long ago. Like Sebastian, I saw the TSC unit hang after about 5 interrupts when running with the workaround. Did you test you patch for very long? Yes, I tested for about 20 interrupts and I didn't see any hang. This patch series does not just implement workaround but also does some minor changes, such as interchanging ADC and TSC steps etc, which makes TSC driver more robust. Let me know if you encounter any issues with my patch series. Regards Vignesh Thanks, Richard -- To unsubscribe from this list: send the line unsubscribe linux-iio in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html -- 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 -- 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 v9 0/7] Enable L2 cache support on Exynos4210/4x12 SoCs
This is an updated patchset, which intends to add support for L2 cache
on Exynos4 SoCs on boards running under secure firmware, which requires
certain initialization steps to be done with help of firmware, as
selected registers are writable only from secure mode.
First four patches extend existing support for secure write in L2C driver
to account for design of secure firmware running on Exynos. Namely:
1) direct read access to certain registers is needed on Exynos, because
secure firmware calls set several registers at once,
2) not all boards are running secure firmware, so .write_sec callback
needs to be installed in Exynos firmware ops initialization code,
3) write access to {DATA,TAG}_LATENCY_CTRL registers fron non-secure world
is not allowed and so must use l2c_write_sec as well,
4) on certain boards, default value of prefetch register is incorrect
and must be overridden at L2C initialization.
For boards running with firmware that provides access to individual
L2C registers this series should introduce no functional changes. However
since the driver is widely used on other platforms I'd like to kindly ask
any interested people for testing.
Further three patches add implementation of .write_sec and .configure
callbacks for Exynos secure firmware and necessary DT nodes to enable
L2 cache.
Changes in this version tested on Exynos4412-based TRATS2 and OdroidU3+
boards (both with secure firmware). There should be no functional change
for Exynos boards running without secure firmware. I do not have access
to affected non-Exynos boards, so I could not test on them.
Depends on:
- v3.18-rc3
Changelog:
Changes since v8:
(http://lkml.org/lkml/2014/11/13/263)
- Rebased onto vanilla v3.18-rc3 and added required includes, which were
previously added by other patches
- Added Acked-by tags for Exynos part
Changes since v7:
(https://lkml.org/lkml/2014/10/29/158)
- rebased onto arm-soc/for-next kernel tree (depends on patches merged to
v3.18-rc3 and arm-soc/samsung/pm2 branch)
- removed 'ARM: l2c: unify L2C-310 OF initialization error messages' patch
(no longer needed)
Changes since v6:
(https://lkml.org/lkml/2014/10/27/233)
- changed PL310 to L2C-310 prefix in error messages
- added patch shortening the error message about incorrect associativity
Changes since v5:
(https://lkml.org/lkml/2014/9/24/364)
- rebased onto v3.18-rc2
- added error message about missing properties values
Changes since v4:
(https://lkml.org/lkml/2014/8/26/461)
- rewrote the code accessing l2x0_saved_regs from assembly code
- added comment and reworked unconditional call to SMC_CMD_L2X0INVALL
Patch summary:
Tomasz Figa (7):
ARM: l2c: Refactor the driver to use commit-like interface
ARM: l2c: Add interface to ask hypervisor to configure L2C
ARM: l2c: Get outer cache .write_sec callback from mach_desc only if
not NULL
ARM: l2c: Add support for overriding prefetch settings
ARM: EXYNOS: Add .write_sec outer cache callback for L2C-310
ARM: EXYNOS: Add support for non-secure L2X0 resume
ARM: dts: exynos4: Add nodes for L2 cache controller
Documentation/devicetree/bindings/arm/l2cc.txt | 10 +
arch/arm/boot/dts/exynos4210.dtsi | 9 +
arch/arm/boot/dts/exynos4x12.dtsi | 14 ++
arch/arm/include/asm/outercache.h | 3 +
arch/arm/kernel/irq.c | 3 +-
arch/arm/mach-exynos/Makefile | 1 +
arch/arm/mach-exynos/firmware.c| 51 +
arch/arm/mach-exynos/sleep.S | 48 +
arch/arm/mach-exynos/smc.h | 4 +
arch/arm/mm/cache-l2x0.c | 270 -
10 files changed, 317 insertions(+), 96 deletions(-)
--
1.9.2
--
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 v9 4/7] ARM: l2c: Add support for overriding prefetch settings
From: Tomasz Figa t.f...@samsung.com
Firmware on certain boards (e.g. ODROID-U3) can leave incorrect L2C prefetch
settings configured in registers leading to crashes if L2C is enabled
without overriding them. This patch introduces bindings to enable
prefetch settings to be specified from DT and necessary support in the
driver.
Signed-off-by: Tomasz Figa t.f...@samsung.com
[mszyprow: rebased onto v3.18-rc1, added error message when prefetch related
dt property has been provided without any value]
Signed-off-by: Marek Szyprowski m.szyprow...@samsung.com
---
Documentation/devicetree/bindings/arm/l2cc.txt | 10 +
arch/arm/mm/cache-l2x0.c | 54 ++
2 files changed, 64 insertions(+)
diff --git a/Documentation/devicetree/bindings/arm/l2cc.txt
b/Documentation/devicetree/bindings/arm/l2cc.txt
index 292ef7ca3058..0dbabe9a6b0a 100644
--- a/Documentation/devicetree/bindings/arm/l2cc.txt
+++ b/Documentation/devicetree/bindings/arm/l2cc.txt
@@ -57,6 +57,16 @@ Optional properties:
- cache-id-part: cache id part number to be used if it is not present
on hardware
- wt-override: If present then L2 is forced to Write through mode
+- arm,double-linefill : Override double linefill enable setting. Enable if
+ non-zero, disable if zero.
+- arm,double-linefill-incr : Override double linefill on INCR read. Enable
+ if non-zero, disable if zero.
+- arm,double-linefill-wrap : Override double linefill on WRAP read. Enable
+ if non-zero, disable if zero.
+- arm,prefetch-drop : Override prefetch drop enable setting. Enable if
non-zero,
+ disable if zero.
+- arm,prefetch-offset : Override prefetch offset value. Valid values are
+ 0-7, 15, 23, and 31.
Example:
diff --git a/arch/arm/mm/cache-l2x0.c b/arch/arm/mm/cache-l2x0.c
index d214be207517..6f9d5a02d053 100644
--- a/arch/arm/mm/cache-l2x0.c
+++ b/arch/arm/mm/cache-l2x0.c
@@ -1169,6 +1169,8 @@ static void __init l2c310_of_parse(const struct
device_node *np,
u32 tag[3] = { 0, 0, 0 };
u32 filter[2] = { 0, 0 };
u32 assoc;
+ u32 prefetch;
+ u32 val;
int ret;
of_property_read_u32_array(np, arm,tag-latency, tag, ARRAY_SIZE(tag));
@@ -1214,6 +1216,58 @@ static void __init l2c310_of_parse(const struct
device_node *np,
assoc);
break;
}
+
+ prefetch = l2x0_saved_regs.prefetch_ctrl;
+
+ ret = of_property_read_u32(np, arm,double-linefill, val);
+ if (ret == 0) {
+ if (val)
+ prefetch |= L310_PREFETCH_CTRL_DBL_LINEFILL;
+ else
+ prefetch = ~L310_PREFETCH_CTRL_DBL_LINEFILL;
+ } else if (ret != -EINVAL) {
+ pr_err(L2C-310 OF arm,double-linefill property value is
missing\n);
+ }
+
+ ret = of_property_read_u32(np, arm,double-linefill-incr, val);
+ if (ret == 0) {
+ if (val)
+ prefetch |= L310_PREFETCH_CTRL_DBL_LINEFILL_INCR;
+ else
+ prefetch = ~L310_PREFETCH_CTRL_DBL_LINEFILL_INCR;
+ } else if (ret != -EINVAL) {
+ pr_err(L2C-310 OF arm,double-linefill-incr property value is
missing\n);
+ }
+
+ ret = of_property_read_u32(np, arm,double-linefill-wrap, val);
+ if (ret == 0) {
+ if (!val)
+ prefetch |= L310_PREFETCH_CTRL_DBL_LINEFILL_WRAP;
+ else
+ prefetch = ~L310_PREFETCH_CTRL_DBL_LINEFILL_WRAP;
+ } else if (ret != -EINVAL) {
+ pr_err(L2C-310 OF arm,double-linefill-wrap property value is
missing\n);
+ }
+
+ ret = of_property_read_u32(np, arm,prefetch-drop, val);
+ if (ret == 0) {
+ if (val)
+ prefetch |= L310_PREFETCH_CTRL_PREFETCH_DROP;
+ else
+ prefetch = ~L310_PREFETCH_CTRL_PREFETCH_DROP;
+ } else if (ret != -EINVAL) {
+ pr_err(L2C-310 OF arm,prefetch-drop property value is
missing\n);
+ }
+
+ ret = of_property_read_u32(np, arm,prefetch-offset, val);
+ if (ret == 0) {
+ prefetch = ~L310_PREFETCH_CTRL_OFFSET_MASK;
+ prefetch |= val L310_PREFETCH_CTRL_OFFSET_MASK;
+ } else if (ret != -EINVAL) {
+ pr_err(L2C-310 OF arm,prefetch-offset property value is
missing\n);
+ }
+
+ l2x0_saved_regs.prefetch_ctrl = prefetch;
}
static const struct l2c_init_data of_l2c310_data __initconst = {
--
1.9.2
--
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 v9 0/7] Enable L2 cache support on Exynos4210/4x12 SoCs
This is an updated patchset, which intends to add support for L2 cache
on Exynos4 SoCs on boards running under secure firmware, which requires
certain initialization steps to be done with help of firmware, as
selected registers are writable only from secure mode.
First four patches extend existing support for secure write in L2C driver
to account for design of secure firmware running on Exynos. Namely:
1) direct read access to certain registers is needed on Exynos, because
secure firmware calls set several registers at once,
2) not all boards are running secure firmware, so .write_sec callback
needs to be installed in Exynos firmware ops initialization code,
3) write access to {DATA,TAG}_LATENCY_CTRL registers fron non-secure world
is not allowed and so must use l2c_write_sec as well,
4) on certain boards, default value of prefetch register is incorrect
and must be overridden at L2C initialization.
For boards running with firmware that provides access to individual
L2C registers this series should introduce no functional changes. However
since the driver is widely used on other platforms I'd like to kindly ask
any interested people for testing.
Further three patches add implementation of .write_sec and .configure
callbacks for Exynos secure firmware and necessary DT nodes to enable
L2 cache.
Changes in this version tested on Exynos4412-based TRATS2 and OdroidU3+
boards (both with secure firmware). There should be no functional change
for Exynos boards running without secure firmware. I do not have access
to affected non-Exynos boards, so I could not test on them.
Depends on:
- v3.18-rc3
Changelog:
Changes since v8:
(http://lkml.org/lkml/2014/11/13/263)
- Rebased onto vanilla v3.18-rc3 and added required includes, which were
previously added by other patches
- Added Acked-by tags for Exynos part
Changes since v7:
(https://lkml.org/lkml/2014/10/29/158)
- rebased onto arm-soc/for-next kernel tree (depends on patches merged to
v3.18-rc3 and arm-soc/samsung/pm2 branch)
- removed 'ARM: l2c: unify L2C-310 OF initialization error messages' patch
(no longer needed)
Changes since v6:
(https://lkml.org/lkml/2014/10/27/233)
- changed PL310 to L2C-310 prefix in error messages
- added patch shortening the error message about incorrect associativity
Changes since v5:
(https://lkml.org/lkml/2014/9/24/364)
- rebased onto v3.18-rc2
- added error message about missing properties values
Changes since v4:
(https://lkml.org/lkml/2014/8/26/461)
- rewrote the code accessing l2x0_saved_regs from assembly code
- added comment and reworked unconditional call to SMC_CMD_L2X0INVALL
Patch summary:
Tomasz Figa (7):
ARM: l2c: Refactor the driver to use commit-like interface
ARM: l2c: Add interface to ask hypervisor to configure L2C
ARM: l2c: Get outer cache .write_sec callback from mach_desc only if
not NULL
ARM: l2c: Add support for overriding prefetch settings
ARM: EXYNOS: Add .write_sec outer cache callback for L2C-310
ARM: EXYNOS: Add support for non-secure L2X0 resume
ARM: dts: exynos4: Add nodes for L2 cache controller
Documentation/devicetree/bindings/arm/l2cc.txt | 10 +
arch/arm/boot/dts/exynos4210.dtsi | 9 +
arch/arm/boot/dts/exynos4x12.dtsi | 14 ++
arch/arm/include/asm/outercache.h | 3 +
arch/arm/kernel/irq.c | 3 +-
arch/arm/mach-exynos/Makefile | 1 +
arch/arm/mach-exynos/firmware.c| 51 +
arch/arm/mach-exynos/sleep.S | 48 +
arch/arm/mach-exynos/smc.h | 4 +
arch/arm/mm/cache-l2x0.c | 270 -
10 files changed, 317 insertions(+), 96 deletions(-)
--
1.9.2
--
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 v9 7/7] ARM: dts: exynos4: Add nodes for L2 cache controller
From: Tomasz Figa t.f...@samsung.com
This patch adds device tree nodes for L2 cache controller present on
Exynos4 SoCs.
Signed-off-by: Tomasz Figa t.f...@samsung.com
Signed-off-by: Marek Szyprowski m.szyprow...@samsung.com
Acked-by: Arnd Bergmann a...@arndb.de
Acked-by: Kukjin Kim kgene@samsung.com
---
arch/arm/boot/dts/exynos4210.dtsi | 9 +
arch/arm/boot/dts/exynos4x12.dtsi | 14 ++
2 files changed, 23 insertions(+)
diff --git a/arch/arm/boot/dts/exynos4210.dtsi
b/arch/arm/boot/dts/exynos4210.dtsi
index 807bb5bf91fc..8a182c43e314 100644
--- a/arch/arm/boot/dts/exynos4210.dtsi
+++ b/arch/arm/boot/dts/exynos4210.dtsi
@@ -64,6 +64,15 @@
reg = 0x10023CA0 0x20;
};
+ l2c: l2-cache-controller@10502000 {
+ compatible = arm,pl310-cache;
+ reg = 0x10502000 0x1000;
+ cache-unified;
+ cache-level = 2;
+ arm,tag-latency = 2 2 1;
+ arm,data-latency = 2 2 1;
+ };
+
gic: interrupt-controller@1049 {
cpu-offset = 0x8000;
};
diff --git a/arch/arm/boot/dts/exynos4x12.dtsi
b/arch/arm/boot/dts/exynos4x12.dtsi
index 861bb919f6d3..c7adfd60ad3a 100644
--- a/arch/arm/boot/dts/exynos4x12.dtsi
+++ b/arch/arm/boot/dts/exynos4x12.dtsi
@@ -54,6 +54,20 @@
reg = 0x10023CA0 0x20;
};
+ l2c: l2-cache-controller@10502000 {
+ compatible = arm,pl310-cache;
+ reg = 0x10502000 0x1000;
+ cache-unified;
+ cache-level = 2;
+ arm,tag-latency = 2 2 1;
+ arm,data-latency = 3 2 1;
+ arm,double-linefill = 1;
+ arm,double-linefill-incr = 0;
+ arm,double-linefill-wrap = 1;
+ arm,prefetch-drop = 1;
+ arm,prefetch-offset = 7;
+ };
+
clock: clock-controller@1003 {
compatible = samsung,exynos4412-clock;
reg = 0x1003 0x2;
--
1.9.2
--
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 v9 6/7] ARM: EXYNOS: Add support for non-secure L2X0 resume
From: Tomasz Figa t.f...@samsung.com On Exynos SoCs it is necessary to resume operation of L2C early in assembly code, because otherwise certain systems will crash. This patch adds necessary code to non-secure resume handler. Signed-off-by: Tomasz Figa t.f...@samsung.com [rewrote the code accessing l2x0_saved_regs, rebased onto v3.18-rc3] Sigend-off-by: Marek Szyprowski m.szyprow...@samsung.com Acked-by: Arnd Bergmann a...@arndb.de Acked-by: Kukjin Kim kgene@samsung.com --- arch/arm/mach-exynos/Makefile | 1 + arch/arm/mach-exynos/sleep.S | 48 +++ arch/arm/mach-exynos/smc.h| 4 3 files changed, 53 insertions(+) diff --git a/arch/arm/mach-exynos/Makefile b/arch/arm/mach-exynos/Makefile index 27ae6144679c..45bef21a3b66 100644 --- a/arch/arm/mach-exynos/Makefile +++ b/arch/arm/mach-exynos/Makefile @@ -21,6 +21,7 @@ CFLAGS_hotplug.o += -march=armv7-a plus_sec := $(call as-instr,.arch_extension sec,+sec) AFLAGS_exynos-smc.o:=-Wa,-march=armv7-a$(plus_sec) +AFLAGS_sleep.o :=-Wa,-march=armv7-a$(plus_sec) obj-$(CONFIG_EXYNOS5420_MCPM) += mcpm-exynos.o CFLAGS_mcpm-exynos.o += -march=armv7-a diff --git a/arch/arm/mach-exynos/sleep.S b/arch/arm/mach-exynos/sleep.S index 108a45f4bb62..5aa6b4de9274 100644 --- a/arch/arm/mach-exynos/sleep.S +++ b/arch/arm/mach-exynos/sleep.S @@ -16,6 +16,9 @@ */ #include linux/linkage.h +#include asm/asm-offsets.h +#include asm/hardware/cache-l2x0.h +#include smc.h #define CPU_MASK 0xff00 #define CPU_CORTEX_A9 0x410fc090 @@ -55,3 +58,48 @@ ENTRY(exynos_cpu_resume) #endif b cpu_resume ENDPROC(exynos_cpu_resume) + +#ifdef CONFIG_CACHE_L2X0 + adr r0, 1f + ldr r2, [r0] + add r0, r2, r0 + + /* Check that the address has been initialised. */ + ldr r1, [r0, #L2X0_R_PHY_BASE] + teq r1, #0 + beq skip_l2x0 + + /* Check if controller has been enabled. */ + ldr r2, [r1, #L2X0_CTRL] + tst r2, #0x1 + bne skip_l2x0 + + ldr r1, [r0, #L2X0_R_TAG_LATENCY] + ldr r2, [r0, #L2X0_R_DATA_LATENCY] + ldr r3, [r0, #L2X0_R_PREFETCH_CTRL] + mov r0, #SMC_CMD_L2X0SETUP1 + smc #0 + + /* Reload saved regs pointer because smc corrupts registers. */ + adr r0, 1f + ldr r2, [r0] + add r0, r2, r0 + + ldr r1, [r0, #L2X0_R_PWR_CTRL] + ldr r2, [r0, #L2X0_R_AUX_CTRL] + mov r0, #SMC_CMD_L2X0SETUP2 + smc #0 + + mov r0, #SMC_CMD_L2X0INVALL + smc #0 + + mov r1, #1 + mov r0, #SMC_CMD_L2X0CTRL + smc #0 +skip_l2x0: +#endif /* CONFIG_CACHE_L2X0 */ + +#ifdef CONFIG_CACHE_L2X0 + .align +1: .long l2x0_saved_regs - . +#endif /* CONFIG_CACHE_L2X0 */ diff --git a/arch/arm/mach-exynos/smc.h b/arch/arm/mach-exynos/smc.h index 13a1dc8ecbf2..f7b82f9c1e21 100644 --- a/arch/arm/mach-exynos/smc.h +++ b/arch/arm/mach-exynos/smc.h @@ -26,6 +26,10 @@ #define SMC_CMD_L2X0INVALL (-24) #define SMC_CMD_L2X0DEBUG (-25) +#ifndef __ASSEMBLY__ + extern void exynos_smc(u32 cmd, u32 arg1, u32 arg2, u32 arg3); +#endif /* __ASSEMBLY__ */ + #endif -- 1.9.2 -- 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 v9 3/7] ARM: l2c: Get outer cache .write_sec callback from mach_desc only if not NULL
From: Tomasz Figa t.f...@samsung.com
Certain platforms (i.e. Exynos) might need to set .write_sec callback
from firmware initialization which is happenning in .init_early callback
of machine descriptor. However current code will overwrite the pointer
with whatever is present in machine descriptor, even though it can be
already set earlier. This patch fixes this by making the assignment
conditional, depending on whether current .write_sec callback is NULL.
Signed-off-by: Tomasz Figa t.f...@samsung.com
Signed-off-by: Marek Szyprowski m.szyprow...@samsung.com
---
arch/arm/kernel/irq.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/arch/arm/kernel/irq.c b/arch/arm/kernel/irq.c
index 7c81ec428b9b..5acb8aef6f2d 100644
--- a/arch/arm/kernel/irq.c
+++ b/arch/arm/kernel/irq.c
@@ -108,7 +108,8 @@ void __init init_IRQ(void)
if (IS_ENABLED(CONFIG_OF) IS_ENABLED(CONFIG_CACHE_L2X0)
(machine_desc-l2c_aux_mask || machine_desc-l2c_aux_val)) {
- outer_cache.write_sec = machine_desc-l2c_write_sec;
+ if (!outer_cache.write_sec)
+ outer_cache.write_sec = machine_desc-l2c_write_sec;
ret = l2x0_of_init(machine_desc-l2c_aux_val,
machine_desc-l2c_aux_mask);
if (ret)
--
1.9.2
--
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 v9 2/7] ARM: l2c: Add interface to ask hypervisor to configure L2C
From: Tomasz Figa t.f...@samsung.com
Because certain secure hypervisor do not allow writes to individual L2C
registers, but rather expect set of parameters to be passed as argument
to secure monitor calls, there is a need to provide an interface for the
L2C driver to ask the firmware to configure the hardware according to
specified parameters. This patch adds such.
Signed-off-by: Tomasz Figa t.f...@samsung.com
Signed-off-by: Marek Szyprowski m.szyprow...@samsung.com
---
arch/arm/include/asm/outercache.h | 3 +++
arch/arm/mm/cache-l2x0.c | 6 ++
2 files changed, 9 insertions(+)
diff --git a/arch/arm/include/asm/outercache.h
b/arch/arm/include/asm/outercache.h
index 891a56b35bcf..563b92fc2f41 100644
--- a/arch/arm/include/asm/outercache.h
+++ b/arch/arm/include/asm/outercache.h
@@ -23,6 +23,8 @@
#include linux/types.h
+struct l2x0_regs;
+
struct outer_cache_fns {
void (*inv_range)(unsigned long, unsigned long);
void (*clean_range)(unsigned long, unsigned long);
@@ -36,6 +38,7 @@ struct outer_cache_fns {
/* This is an ARM L2C thing */
void (*write_sec)(unsigned long, unsigned);
+ void (*configure)(const struct l2x0_regs *);
};
extern struct outer_cache_fns outer_cache;
diff --git a/arch/arm/mm/cache-l2x0.c b/arch/arm/mm/cache-l2x0.c
index e5948c5adaa7..d214be207517 100644
--- a/arch/arm/mm/cache-l2x0.c
+++ b/arch/arm/mm/cache-l2x0.c
@@ -110,6 +110,11 @@ static inline void l2c_unlock(void __iomem *base, unsigned
num)
static void l2c_configure(void __iomem *base)
{
+ if (outer_cache.configure) {
+ outer_cache.configure(l2x0_saved_regs);
+ return;
+ }
+
if (l2x0_data-configure)
l2x0_data-configure(base);
@@ -910,6 +915,7 @@ static int __init __l2c_init(const struct l2c_init_data
*data,
fns = data-outer_cache;
fns.write_sec = outer_cache.write_sec;
+ fns.configure = outer_cache.configure;
if (data-fixup)
data-fixup(l2x0_base, cache_id, fns);
--
1.9.2
--
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 v9 1/7] ARM: l2c: Refactor the driver to use commit-like interface
From: Tomasz Figa t.f...@samsung.com
Certain implementations of secure hypervisors (namely the one found on
Samsung Exynos-based boards) do not provide access to individual L2C
registers. This makes the .write_sec()-based interface insufficient and
provoking ugly hacks.
This patch is first step to make the driver not rely on availability of
writes to individual registers. This is achieved by refactoring the
driver to use a commit-like operation scheme: all register values are
prepared first and stored in an instance of l2x0_regs struct and then a
single callback is responsible to flush those values to the hardware.
Signed-off-by: Tomasz Figa t.f...@samsung.com
Signed-off-by: Marek Szyprowski m.szyprow...@samsung.com
---
arch/arm/mm/cache-l2x0.c | 210 ++-
1 file changed, 115 insertions(+), 95 deletions(-)
diff --git a/arch/arm/mm/cache-l2x0.c b/arch/arm/mm/cache-l2x0.c
index 5e65ca8dea62..e5948c5adaa7 100644
--- a/arch/arm/mm/cache-l2x0.c
+++ b/arch/arm/mm/cache-l2x0.c
@@ -41,12 +41,14 @@ struct l2c_init_data {
void (*enable)(void __iomem *, u32, unsigned);
void (*fixup)(void __iomem *, u32, struct outer_cache_fns *);
void (*save)(void __iomem *);
+ void (*configure)(void __iomem *);
struct outer_cache_fns outer_cache;
};
#define CACHE_LINE_SIZE32
static void __iomem *l2x0_base;
+static const struct l2c_init_data *l2x0_data;
static DEFINE_RAW_SPINLOCK(l2x0_lock);
static u32 l2x0_way_mask; /* Bitmask of active ways */
static u32 l2x0_size;
@@ -106,6 +108,14 @@ static inline void l2c_unlock(void __iomem *base, unsigned
num)
}
}
+static void l2c_configure(void __iomem *base)
+{
+ if (l2x0_data-configure)
+ l2x0_data-configure(base);
+
+ l2c_write_sec(l2x0_saved_regs.aux_ctrl, base, L2X0_AUX_CTRL);
+}
+
/*
* Enable the L2 cache controller. This function must only be
* called when the cache controller is known to be disabled.
@@ -114,7 +124,12 @@ static void l2c_enable(void __iomem *base, u32 aux,
unsigned num_lock)
{
unsigned long flags;
- l2c_write_sec(aux, base, L2X0_AUX_CTRL);
+ /* Do not touch the controller if already enabled. */
+ if (readl_relaxed(base + L2X0_CTRL) L2X0_CTRL_EN)
+ return;
+
+ l2x0_saved_regs.aux_ctrl = aux;
+ l2c_configure(base);
l2c_unlock(base, num_lock);
@@ -208,6 +223,11 @@ static void l2c_save(void __iomem *base)
l2x0_saved_regs.aux_ctrl = readl_relaxed(l2x0_base + L2X0_AUX_CTRL);
}
+static void l2c_resume(void)
+{
+ l2c_enable(l2x0_base, l2x0_saved_regs.aux_ctrl, l2x0_data-num_lock);
+}
+
/*
* L2C-210 specific code.
*
@@ -288,14 +308,6 @@ static void l2c210_sync(void)
__l2c210_cache_sync(l2x0_base);
}
-static void l2c210_resume(void)
-{
- void __iomem *base = l2x0_base;
-
- if (!(readl_relaxed(base + L2X0_CTRL) L2X0_CTRL_EN))
- l2c_enable(base, l2x0_saved_regs.aux_ctrl, 1);
-}
-
static const struct l2c_init_data l2c210_data __initconst = {
.type = L2C-210,
.way_size_0 = SZ_8K,
@@ -309,7 +321,7 @@ static const struct l2c_init_data l2c210_data __initconst =
{
.flush_all = l2c210_flush_all,
.disable = l2c_disable,
.sync = l2c210_sync,
- .resume = l2c210_resume,
+ .resume = l2c_resume,
},
};
@@ -466,7 +478,7 @@ static const struct l2c_init_data l2c220_data = {
.flush_all = l2c220_flush_all,
.disable = l2c_disable,
.sync = l2c220_sync,
- .resume = l2c210_resume,
+ .resume = l2c_resume,
},
};
@@ -615,39 +627,29 @@ static void __init l2c310_save(void __iomem *base)
L310_POWER_CTRL);
}
-static void l2c310_resume(void)
+static void l2c310_configure(void __iomem *base)
{
- void __iomem *base = l2x0_base;
+ unsigned revision;
- if (!(readl_relaxed(base + L2X0_CTRL) L2X0_CTRL_EN)) {
- unsigned revision;
-
- /* restore pl310 setup */
- writel_relaxed(l2x0_saved_regs.tag_latency,
- base + L310_TAG_LATENCY_CTRL);
- writel_relaxed(l2x0_saved_regs.data_latency,
- base + L310_DATA_LATENCY_CTRL);
- writel_relaxed(l2x0_saved_regs.filter_end,
- base + L310_ADDR_FILTER_END);
- writel_relaxed(l2x0_saved_regs.filter_start,
- base + L310_ADDR_FILTER_START);
-
- revision = readl_relaxed(base + L2X0_CACHE_ID)
- L2X0_CACHE_ID_RTL_MASK;
-
- if (revision = L310_CACHE_ID_RTL_R2P0)
- l2c_write_sec(l2x0_saved_regs.prefetch_ctrl, base,
-
[PATCH v9 5/7] ARM: EXYNOS: Add .write_sec outer cache callback for L2C-310
From: Tomasz Figa t.f...@samsung.com
Exynos4 SoCs equipped with an L2C-310 cache controller and running under
secure firmware require certain registers of aforementioned IP to be
accessed only from secure mode. This means that SMC calls are required
for certain register writes. To handle this, an implementation of
.write_sec and .configure callbacks is provided by this patch.
Signed-off-by: Tomasz Figa t.f...@samsung.com
[added comment and reworked unconditional call to SMC_CMD_L2X0INVALL,
rebased onto v3.18-rc3]
Signed-off-by: Marek Szyprowski m.szyprow...@samsung.com
Acked-by: Arnd Bergmann a...@arndb.de
Acked-by: Kukjin Kim kgene@samsung.com
---
arch/arm/mach-exynos/firmware.c | 51 +
1 file changed, 51 insertions(+)
diff --git a/arch/arm/mach-exynos/firmware.c b/arch/arm/mach-exynos/firmware.c
index e8797bb78871..27ec360b5a87 100644
--- a/arch/arm/mach-exynos/firmware.c
+++ b/arch/arm/mach-exynos/firmware.c
@@ -14,7 +14,9 @@
#include linux/of.h
#include linux/of_address.h
+#include asm/cputype.h
#include asm/firmware.h
+#include asm/hardware/cache-l2x0.h
#include mach/map.h
@@ -75,6 +77,43 @@ static const struct firmware_ops exynos_firmware_ops = {
.cpu_boot = exynos_cpu_boot,
};
+static void exynos_l2_write_sec(unsigned long val, unsigned reg)
+{
+ static int l2cache_enabled;
+
+ switch (reg) {
+ case L2X0_CTRL:
+ if (val L2X0_CTRL_EN) {
+ /*
+* Before the cache can be enabled, due to firmware
+* design, SMC_CMD_L2X0INVALL must be called.
+*/
+ if (!l2cache_enabled) {
+ exynos_smc(SMC_CMD_L2X0INVALL, 0, 0, 0);
+ l2cache_enabled = 1;
+ }
+ } else {
+ l2cache_enabled = 0;
+ }
+ exynos_smc(SMC_CMD_L2X0CTRL, val, 0, 0);
+ break;
+
+ case L2X0_DEBUG_CTRL:
+ exynos_smc(SMC_CMD_L2X0DEBUG, val, 0, 0);
+ break;
+
+ default:
+ WARN_ONCE(1, %s: ignoring write to reg 0x%x\n, __func__, reg);
+ }
+}
+
+static void exynos_l2_configure(const struct l2x0_regs *regs)
+{
+ exynos_smc(SMC_CMD_L2X0SETUP1, regs-tag_latency, regs-data_latency,
+ regs-prefetch_ctrl);
+ exynos_smc(SMC_CMD_L2X0SETUP2, regs-pwr_ctrl, regs-aux_ctrl, 0);
+}
+
void __init exynos_firmware_init(void)
{
struct device_node *nd;
@@ -94,4 +133,16 @@ void __init exynos_firmware_init(void)
pr_info(Running under secure firmware.\n);
register_firmware_ops(exynos_firmware_ops);
+
+ /*
+* Exynos 4 SoCs (based on Cortex A9 and equipped with L2C-310),
+* running under secure firmware, require certain registers of L2
+* cache controller to be written in secure mode. Here .write_sec
+* callback is provided to perform necessary SMC calls.
+*/
+ if (IS_ENABLED(CONFIG_CACHE_L2X0)
+read_cpuid_part() == ARM_CPU_PART_CORTEX_A9) {
+ outer_cache.write_sec = exynos_l2_write_sec;
+ outer_cache.configure = exynos_l2_configure;
+ }
}
--
1.9.2
--
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 v8 0/8] can: c_can: Use syscon regmap for TI specific RAMINIT register
On 11/14/2014 08:09 PM, Marc Kleine-Budde wrote:
Picking up Roger's work:
Changes since v7:
- combined raminit start and done bit into a struct (3/8, 7/8, 8/8)
- constified struct c_can_driver_data (2/8, 7/8, 8/8)
- silenced compiler warning in c_can_hw_raminit_{wait,}_syscon (4/8)
- use platform_get_device_id in probe() instead of open coding it (2/8)
Thanks for saving me one more iteration :).
I've tested this to work on AM437x-evm and DRA7-evm.
Please pick patch 9 as well which I will send in response to this thread.
That one adds compatible id for am4372-d_can.
cheers,
-roger
--
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 v8 9/9] net: can: c_can: Add support for TI am4372 DCAN
AM4372 SoC has 2 DCAN modules. Add compatible id and
raminit driver data for it. The driver data is same as AM3352
but this gives us flexibility to add AM4372 specific quirks
if required later.
Signed-off-by: Roger Quadros rog...@ti.com
---
Documentation/devicetree/bindings/net/can/c_can.txt | 3 ++-
drivers/net/can/c_can/c_can_platform.c | 1 +
2 files changed, 3 insertions(+), 1 deletion(-)
diff --git a/Documentation/devicetree/bindings/net/can/c_can.txt
b/Documentation/devicetree/bindings/net/can/c_can.txt
index 6731730..5a1d8b0 100644
--- a/Documentation/devicetree/bindings/net/can/c_can.txt
+++ b/Documentation/devicetree/bindings/net/can/c_can.txt
@@ -4,7 +4,8 @@ Bosch C_CAN/D_CAN controller Device Tree Bindings
Required properties:
- compatible : Should be bosch,c_can for C_CAN controllers and
bosch,d_can for D_CAN controllers.
- Can be ti,dra7-d_can or ti,am3352-d_can.
+ Can be ti,dra7-d_can, ti,am3352-d_can or
+ ti,am4372-d_can.
- reg : physical base address and size of the C_CAN/D_CAN
registers map
- interrupts : property with a value describing the interrupt
diff --git a/drivers/net/can/c_can/c_can_platform.c
b/drivers/net/can/c_can/c_can_platform.c
index f4488e5..a4535d2 100644
--- a/drivers/net/can/c_can/c_can_platform.c
+++ b/drivers/net/can/c_can/c_can_platform.c
@@ -235,6 +235,7 @@ static const struct of_device_id c_can_of_table[] = {
{ .compatible = bosch,d_can, .data = d_can_drvdata },
{ .compatible = ti,dra7-d_can, .data = dra7_dcan_drvdata },
{ .compatible = ti,am3352-d_can, .data = am3352_dcan_drvdata },
+ { .compatible = ti,am4372-d_can, .data = am3352_dcan_drvdata },
{ /* sentinel */ },
};
MODULE_DEVICE_TABLE(of, c_can_of_table);
--
1.8.3.2
--
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 v8 9/9] net: can: c_can: Add support for TI am4372 DCAN
On 11/17/2014 01:09 PM, Roger Quadros wrote:
AM4372 SoC has 2 DCAN modules. Add compatible id and
raminit driver data for it. The driver data is same as AM3352
but this gives us flexibility to add AM4372 specific quirks
if required later.
Strictly speaking we don't need the hunk in
drivers/net/can/c_can/c_can_platform.c yet, iff the AM4372 dts(i) has
this compatible:
ti,am4372-d_can, ti,am3352-d_can
Signed-off-by: Roger Quadros rog...@ti.com
---
Documentation/devicetree/bindings/net/can/c_can.txt | 3 ++-
drivers/net/can/c_can/c_can_platform.c | 1 +
2 files changed, 3 insertions(+), 1 deletion(-)
diff --git a/Documentation/devicetree/bindings/net/can/c_can.txt
b/Documentation/devicetree/bindings/net/can/c_can.txt
index 6731730..5a1d8b0 100644
--- a/Documentation/devicetree/bindings/net/can/c_can.txt
+++ b/Documentation/devicetree/bindings/net/can/c_can.txt
@@ -4,7 +4,8 @@ Bosch C_CAN/D_CAN controller Device Tree Bindings
Required properties:
- compatible : Should be bosch,c_can for C_CAN controllers and
bosch,d_can for D_CAN controllers.
- Can be ti,dra7-d_can or ti,am3352-d_can.
+ Can be ti,dra7-d_can, ti,am3352-d_can or
+ ti,am4372-d_can.
- reg: physical base address and size of the
C_CAN/D_CAN
registers map
- interrupts : property with a value describing the interrupt
diff --git a/drivers/net/can/c_can/c_can_platform.c
b/drivers/net/can/c_can/c_can_platform.c
index f4488e5..a4535d2 100644
--- a/drivers/net/can/c_can/c_can_platform.c
+++ b/drivers/net/can/c_can/c_can_platform.c
@@ -235,6 +235,7 @@ static const struct of_device_id c_can_of_table[] = {
{ .compatible = bosch,d_can, .data = d_can_drvdata },
{ .compatible = ti,dra7-d_can, .data = dra7_dcan_drvdata },
{ .compatible = ti,am3352-d_can, .data = am3352_dcan_drvdata },
+ { .compatible = ti,am4372-d_can, .data = am3352_dcan_drvdata },
{ /* sentinel */ },
};
MODULE_DEVICE_TABLE(of, c_can_of_table);
Marc
--
Pengutronix e.K. | Marc Kleine-Budde |
Industrial Linux Solutions| Phone: +49-231-2826-924 |
Vertretung West/Dortmund | Fax: +49-5121-206917- |
Amtsgericht Hildesheim, HRA 2686 | http://www.pengutronix.de |
signature.asc
Description: OpenPGP digital signature
Re: [PATCH] ARM: dts: DRA7: Add node for RTC
Hello.
On 11/17/2014 7:45 AM, Lokesh Vutla wrote:
Add node for RTC.
Signed-off-by: Lokesh Vutla lokeshvu...@ti.com
[n...@ti.com: update with rtc crossbar number]
Signed-off-by: Nishanth Menon n...@ti.com
---
arch/arm/boot/dts/dra7.dtsi | 9 +
1 file changed, 9 insertions(+)
diff --git a/arch/arm/boot/dts/dra7.dtsi b/arch/arm/boot/dts/dra7.dtsi
index 9cc9843..f98f9f0 100644
--- a/arch/arm/boot/dts/dra7.dtsi
+++ b/arch/arm/boot/dts/dra7.dtsi
@@ -1075,6 +1075,15 @@
status = disabled;
};
+ rtc: rtcss@48838000 {
Please just name the node rtc@48838000, in accordance with ePAPR.
+ compatible = ti,am3352-rtc;
+ reg = 0x48838000 0x100;
+ interrupts = GIC_SPI 217 IRQ_TYPE_LEVEL_HIGH,
+GIC_SPI 217 IRQ_TYPE_LEVEL_HIGH;
2 similar interrupts?
[...]
WBR, Sergei
--
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 2/6] input: touchscreen: ti_am335x_tsc: Remove udelay in interrupt handler
On Monday 17 November 2014 01:53 PM, Richard Cochran wrote:
On Mon, Nov 17, 2014 at 09:57:05AM +0530, Vignesh R wrote:
My patches are based on v3.18rc2. I tested my patches on am335x-evm
using tslib.
No beaglebone + cape testing?
Please explain touch is broken? What is the behaviour of TSC?
With plain v3.17 plus your series, the cursor is almost never near the
pen. Mostly it jitters around the right hand edge.
My customer had already changed the step delay (I think by trial and
error, not sure) in order to get the cursor near the pen. I ported
this change onto your series (see patch, below), but still the pen up
event causes a huge cursor jump.
(Again, I did solve the pen up issue, but in a totally different
way. I never posted the fix, because I could not be sure that it would
work on a wide variety of boards.)
Which ADC channels are being used for TSC?
tscadc {
status = okay;
tsc {
ti,wires = 4;
ti,x-plate-resistance = 300;
ti,coordinate-readouts = 5;
ti,wire-config = 0x00 0x11 0x23 0x32;
};
What is the ti,charge-delay value you have tried?
Try setting it to 0xB000 and experiment.
adc {
ti,adc-channels = 5 6 7;
};
};
So for this particular design, your series really does not help, not
even a little. You did not test the series on many boards. I am
concerned that this series only works on the one board you did test,
and that it may break functionality on other people's boards.
I just have one am335x-evm available. I will search for a beaglebone
cape and test the patches. Let Sebastian, Johannes come back with their
results. If the series works on multiple boards then, I believe, this
series can go in.
Regards
Vignesh
Thanks,
Richard
---
diff --git a/drivers/input/touchscreen/ti_am335x_tsc.c
b/drivers/input/touchscreen/ti_am335x_tsc.c
index b84493f..77a4883 100644
--- a/drivers/input/touchscreen/ti_am335x_tsc.c
+++ b/drivers/input/touchscreen/ti_am335x_tsc.c
@@ -148,7 +148,7 @@ static void titsc_step_config(struct titsc *ts_dev)
end_step = first_step + tsc_steps;
for (i = end_step - ts_dev-coordinate_readouts; i end_step; i++) {
titsc_writel(ts_dev, REG_STEPCONFIG(i), config);
- titsc_writel(ts_dev, REG_STEPDELAY(i), STEPCONFIG_OPENDLY);
+ titsc_writel(ts_dev, REG_STEPDELAY(i), STEPCONFIG_OPENDLY |
STEPDELAY_SAMPLE(20));
}
config = 0;
@@ -172,7 +172,7 @@ static void titsc_step_config(struct titsc *ts_dev)
end_step = first_step + ts_dev-coordinate_readouts;
for (i = first_step; i end_step; i++) {
titsc_writel(ts_dev, REG_STEPCONFIG(i), config);
- titsc_writel(ts_dev, REG_STEPDELAY(i), STEPCONFIG_OPENDLY);
+ titsc_writel(ts_dev, REG_STEPDELAY(i), STEPCONFIG_OPENDLY |
STEPDELAY_SAMPLE(20));
}
/* Make CHARGECONFIG same as IDLECONFIG */
@@ -188,13 +188,13 @@ static void titsc_step_config(struct titsc *ts_dev)
STEPCONFIG_INP(ts_dev-inp_xp);
titsc_writel(ts_dev, REG_STEPCONFIG(end_step), config);
titsc_writel(ts_dev, REG_STEPDELAY(end_step),
- STEPCONFIG_OPENDLY);
+ STEPCONFIG_OPENDLY | STEPDELAY_SAMPLE(20));
end_step++;
config |= STEPCONFIG_INP(ts_dev-inp_yn);
titsc_writel(ts_dev, REG_STEPCONFIG(end_step), config);
titsc_writel(ts_dev, REG_STEPDELAY(end_step),
- STEPCONFIG_OPENDLY);
+ STEPCONFIG_OPENDLY | STEPDELAY_SAMPLE(20));
/* The steps end ... end - readouts * 2 + 2 and bit 0 for TS_Charge */
stepenable = 1;
--
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/4] Touchscreen performance related fixes
On Tuesday 04 November 2014 06:07 PM, Sebastian Andrzej Siewior wrote: On 11/04/2014 12:44 PM, Vignesh R wrote: I ran following commands $ evtest /dev/input/touchscreen0 (with heavy item on touchscreen) and $ cat /sys/bus/iio/devices/iio\:device0/scan_elements/in_voltage4_en (in a busy loop) I tried above experiment on my board but I didn't hit any problem even after running for close to 30 minutes. I was unable to reproduce failure Just to make sure: You had the touchscreen and iio command running in parallel and you saw evtest output while there was iio operation? The problem may be in configuring correct charge-delay value. Please run: $ ts_test /dev/null and let me know if pen events are being detected properly. Well I get the touch events but not while busy loop on iio interface is running (I get maybe one event every 5 seconds or so). After all, it is the same HW you have. Were you able to test the latest version (v4) of this patch series? Please let me know if the performance is satisfactory. Regards Vignesh Sebastian -- 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 -- 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 v8 9/9] net: can: c_can: Add support for TI am4372 DCAN
On 11/17/2014 02:12 PM, Marc Kleine-Budde wrote:
On 11/17/2014 01:09 PM, Roger Quadros wrote:
AM4372 SoC has 2 DCAN modules. Add compatible id and
raminit driver data for it. The driver data is same as AM3352
but this gives us flexibility to add AM4372 specific quirks
if required later.
Strictly speaking we don't need the hunk in
drivers/net/can/c_can/c_can_platform.c yet, iff the AM4372 dts(i) has
this compatible:
ti,am4372-d_can, ti,am3352-d_can
I tried with that, but checkpatch still gives this warning
WARNING: DT compatible string ti,am4372-d_can appears un-documented -- check
./Documentation/devicetree/bindings/
I guess we can just live with it. Please ignore this patch in that case.
cheers,
-roger
Signed-off-by: Roger Quadros rog...@ti.com
---
Documentation/devicetree/bindings/net/can/c_can.txt | 3 ++-
drivers/net/can/c_can/c_can_platform.c | 1 +
2 files changed, 3 insertions(+), 1 deletion(-)
diff --git a/Documentation/devicetree/bindings/net/can/c_can.txt
b/Documentation/devicetree/bindings/net/can/c_can.txt
index 6731730..5a1d8b0 100644
--- a/Documentation/devicetree/bindings/net/can/c_can.txt
+++ b/Documentation/devicetree/bindings/net/can/c_can.txt
@@ -4,7 +4,8 @@ Bosch C_CAN/D_CAN controller Device Tree Bindings
Required properties:
- compatible: Should be bosch,c_can for C_CAN controllers
and
bosch,d_can for D_CAN controllers.
- Can be ti,dra7-d_can or ti,am3352-d_can.
+ Can be ti,dra7-d_can, ti,am3352-d_can or
+ ti,am4372-d_can.
- reg : physical base address and size of the
C_CAN/D_CAN
registers map
- interrupts: property with a value describing the interrupt
diff --git a/drivers/net/can/c_can/c_can_platform.c
b/drivers/net/can/c_can/c_can_platform.c
index f4488e5..a4535d2 100644
--- a/drivers/net/can/c_can/c_can_platform.c
+++ b/drivers/net/can/c_can/c_can_platform.c
@@ -235,6 +235,7 @@ static const struct of_device_id c_can_of_table[] = {
{ .compatible = bosch,d_can, .data = d_can_drvdata },
{ .compatible = ti,dra7-d_can, .data = dra7_dcan_drvdata },
{ .compatible = ti,am3352-d_can, .data = am3352_dcan_drvdata },
+{ .compatible = ti,am4372-d_can, .data = am3352_dcan_drvdata },
{ /* sentinel */ },
};
MODULE_DEVICE_TABLE(of, c_can_of_table);
Marc
--
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: DRA7: Add node for RTC
Hi,
On Monday 17 November 2014 05:47 PM, Sergei Shtylyov wrote:
Hello.
On 11/17/2014 7:45 AM, Lokesh Vutla wrote:
Add node for RTC.
Signed-off-by: Lokesh Vutla lokeshvu...@ti.com
[n...@ti.com: update with rtc crossbar number]
Signed-off-by: Nishanth Menon n...@ti.com
---
arch/arm/boot/dts/dra7.dtsi | 9 +
1 file changed, 9 insertions(+)
diff --git a/arch/arm/boot/dts/dra7.dtsi b/arch/arm/boot/dts/dra7.dtsi
index 9cc9843..f98f9f0 100644
--- a/arch/arm/boot/dts/dra7.dtsi
+++ b/arch/arm/boot/dts/dra7.dtsi
@@ -1075,6 +1075,15 @@
status = disabled;
};
+rtc: rtcss@48838000 {
Please just name the node rtc@48838000, in accordance with ePAPR.
Okay. will update it.
+compatible = ti,am3352-rtc;
+reg = 0x48838000 0x100;
+interrupts = GIC_SPI 217 IRQ_TYPE_LEVEL_HIGH,
+ GIC_SPI 217 IRQ_TYPE_LEVEL_HIGH;
2 similar interrupts?
both rtc timer and rtc alarm uses same interrupt on DRA7 Soc.
Driver handles it accordingly.
So passing the same interrupt.
Thanks and regards,
Lokesh
[...]
WBR, Sergei
--
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 v5 06/10] ARM: dts: am4372: Add DCAN nodes
The SoC contains 2 DCAN modules. Add them.
Signed-off-by: Roger Quadros rog...@ti.com
---
arch/arm/boot/dts/am4372.dtsi | 22 ++
1 file changed, 22 insertions(+)
diff --git a/arch/arm/boot/dts/am4372.dtsi b/arch/arm/boot/dts/am4372.dtsi
index 899c57c..f0ff256 100644
--- a/arch/arm/boot/dts/am4372.dtsi
+++ b/arch/arm/boot/dts/am4372.dtsi
@@ -901,6 +901,28 @@
compatible = mmio-sram;
reg = 0x4030 0x4; /* 256k */
};
+
+ dcan0: can@481cc000 {
+ compatible = ti,am4372-d_can, ti,am3352-d_can;
+ ti,hwmods = d_can0;
+ clocks = dcan0_fck;
+ clock-names = fck;
+ reg = 0x481cc000 0x2000;
+ syscon-raminit = am43xx_control_module 0x644 0;
+ interrupts = GIC_SPI 52 IRQ_TYPE_LEVEL_HIGH;
+ status = disabled;
+ };
+
+ dcan1: can@481d {
+ compatible = ti,am4372-d_can, ti,am3352-d_can;
+ ti,hwmods = d_can1;
+ clocks = dcan1_fck;
+ clock-names = fck;
+ reg = 0x481d 0x2000;
+ syscon-raminit = am43xx_control_module 0x644 1;
+ interrupts = GIC_SPI 49 IRQ_TYPE_LEVEL_HIGH;
+ status = disabled;
+ };
};
};
--
1.8.3.2
--
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
ASoC: omap-mcbsp: Deletion of an unnecessary check before the function call kfree
From: Markus Elfring elfr...@users.sourceforge.net Date: Mon, 17 Nov 2014 14:05:27 +0100 The kfree() function tests whether its argument is NULL and then returns immediately. Thus the test around the call is not needed. This issue was detected by using the Coccinelle software. Signed-off-by: Markus Elfring elfr...@users.sourceforge.net --- sound/soc/omap/mcbsp.c | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-) diff --git a/sound/soc/omap/mcbsp.c b/sound/soc/omap/mcbsp.c index 86c7538..68a1252 100644 --- a/sound/soc/omap/mcbsp.c +++ b/sound/soc/omap/mcbsp.c @@ -621,8 +621,7 @@ void omap_mcbsp_free(struct omap_mcbsp *mcbsp) mcbsp-reg_cache = NULL; spin_unlock(mcbsp-lock); - if (reg_cache) - kfree(reg_cache); + kfree(reg_cache); } /* -- 2.1.3 -- 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 v8 9/9] net: can: c_can: Add support for TI am4372 DCAN
On 11/17/2014 02:31 PM, Roger Quadros wrote:
On 11/17/2014 02:12 PM, Marc Kleine-Budde wrote:
On 11/17/2014 01:09 PM, Roger Quadros wrote:
AM4372 SoC has 2 DCAN modules. Add compatible id and
raminit driver data for it. The driver data is same as AM3352
but this gives us flexibility to add AM4372 specific quirks
if required later.
Strictly speaking we don't need the hunk in
drivers/net/can/c_can/c_can_platform.c yet, iff the AM4372 dts(i) has
this compatible:
ti,am4372-d_can, ti,am3352-d_can
I tried with that, but checkpatch still gives this warning
WARNING: DT compatible string ti,am4372-d_can appears un-documented --
check ./Documentation/devicetree/bindings/
I guess we can just live with it. Please ignore this patch in that case.
Did you meant that we still need to add it in the binding documentation?
It is not usable by itself so won't it be a problem to exist in documentation?
cheers,
-roger
Signed-off-by: Roger Quadros rog...@ti.com
---
Documentation/devicetree/bindings/net/can/c_can.txt | 3 ++-
drivers/net/can/c_can/c_can_platform.c | 1 +
2 files changed, 3 insertions(+), 1 deletion(-)
diff --git a/Documentation/devicetree/bindings/net/can/c_can.txt
b/Documentation/devicetree/bindings/net/can/c_can.txt
index 6731730..5a1d8b0 100644
--- a/Documentation/devicetree/bindings/net/can/c_can.txt
+++ b/Documentation/devicetree/bindings/net/can/c_can.txt
@@ -4,7 +4,8 @@ Bosch C_CAN/D_CAN controller Device Tree Bindings
Required properties:
- compatible : Should be bosch,c_can for C_CAN controllers
and
bosch,d_can for D_CAN controllers.
- Can be ti,dra7-d_can or ti,am3352-d_can.
+ Can be ti,dra7-d_can, ti,am3352-d_can or
+ ti,am4372-d_can.
- reg : physical base address and size of the
C_CAN/D_CAN
registers map
- interrupts : property with a value describing the interrupt
diff --git a/drivers/net/can/c_can/c_can_platform.c
b/drivers/net/can/c_can/c_can_platform.c
index f4488e5..a4535d2 100644
--- a/drivers/net/can/c_can/c_can_platform.c
+++ b/drivers/net/can/c_can/c_can_platform.c
@@ -235,6 +235,7 @@ static const struct of_device_id c_can_of_table[] = {
{ .compatible = bosch,d_can, .data = d_can_drvdata },
{ .compatible = ti,dra7-d_can, .data = dra7_dcan_drvdata },
{ .compatible = ti,am3352-d_can, .data = am3352_dcan_drvdata },
+ { .compatible = ti,am4372-d_can, .data = am3352_dcan_drvdata },
{ /* sentinel */ },
};
MODULE_DEVICE_TABLE(of, c_can_of_table);
Marc
--
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 v12 11/15] arm: omap1: Migrate debug_ll macros to use 8250.S
On 17/11/14 09:07, Daniel Thompson wrote: On 16/11/14 00:29, Aaro Koskinen wrote: Hi, On Fri, Oct 24, 2014 at 11:54:32AM +0100, Daniel Thompson wrote: + config DEBUG_OMAP1UART1 + bool Kernel low-level debugging via OMAP1 UART1 + depends on ARCH_OMAP1 + select DEBUG_UART_8250 + help + Say Y here if you want kernel low-level debugging support + on OMAP1 based platforms (expect OMAP730) on the UART1. [...] + on OMAP1 based platforms (expect OMAP730) on the UART2. [...] + on OMAP1 based platforms (expect OMAP730) on the UART3. ^^ Spelling again wrong. I think it was already corrected in v11? Sorry and, yes, you're right this was corrected in v11. I was travelling when I posted v11 so I guess I must have forgot to pull the right branches to my main machine. I will dig it and diff shortly to make sure I didn't miss anything else. Just as well I did the diff. v12 was derived from v9 rather than v11 as it should have been, so apologies to Aaro and Paul Bolle for dropping changes they asked for. I will try to change how I keep track of things when I go travelling in future... Daniel. -- 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 v8 9/9] net: can: c_can: Add support for TI am4372 DCAN
On 11/17/2014 03:19 PM, Roger Quadros wrote: On 11/17/2014 02:31 PM, Roger Quadros wrote: On 11/17/2014 02:12 PM, Marc Kleine-Budde wrote: On 11/17/2014 01:09 PM, Roger Quadros wrote: AM4372 SoC has 2 DCAN modules. Add compatible id and raminit driver data for it. The driver data is same as AM3352 but this gives us flexibility to add AM4372 specific quirks if required later. Strictly speaking we don't need the hunk in drivers/net/can/c_can/c_can_platform.c yet, iff the AM4372 dts(i) has this compatible: ti,am4372-d_can, ti,am3352-d_can I tried with that, but checkpatch still gives this warning WARNING: DT compatible string ti,am4372-d_can appears un-documented -- check ./Documentation/devicetree/bindings/ I guess we can just live with it. Please ignore this patch in that case. Did you meant that we still need to add it in the binding documentation? It is not usable by itself so won't it be a problem to exist in documentation? I'll take patch 9 as is, since checkpatch is a bit more picky now :) Marc -- Pengutronix e.K. | Marc Kleine-Budde | Industrial Linux Solutions| Phone: +49-231-2826-924 | Vertretung West/Dortmund | Fax: +49-5121-206917- | Amtsgericht Hildesheim, HRA 2686 | http://www.pengutronix.de | signature.asc Description: OpenPGP digital signature
Re: [PATCH 2/2] i2c: omap: fix Too much work in one IRQ irq handling
submit write request to General Call Address. In that case ISR could not correctly handle RDR (or XRDY, ARDY, or that ever). Thats becase i2c-omap driver doesn't correctly handle i2c-controller's slave mode. right, Linux doesn't support being the slave. That's also a missing feature, not a bug. This is going to change. I sent out RFC patches for slave support [1] and will send V1 this week. This won't affect your driver, though, unless you implement the backend into it. Just to keep your heads up. [1] http://thread.gmane.org/gmane.linux.kernel/1783295 signature.asc Description: Digital signature
Re: i2c: omap: fix NACK and Arbitration Lost irq handling
On 11/15/2014 03:12 AM, Alexander Kochetkov wrote:
commit 1d7afc95946487945cc7f5019b41255b72224b70 (i2c: omap: ack IRQ in parts)
changed the interrupt handler to complete transfers without clearing
XRDY (AL case) and ARDY (NACK case) flags. XRDY or ARDY interrupt will be
fired again (in parallel with omap_i2c_xfer_msg). Interrupt handler will
complete transfers second time. As a result, NACK and AL transfers
terminates with transfer timeout and sometimes client code segfault.
The patch restore original logic of handling NACK and AL interrupts and
fix race between interrupt handler and omap_i2c_xfer_msg (for AL and
NACK case only).
Tested on Beagleboard XM C.
Seems you've got the same issue as I :) long time ago
https://lkml.org/lkml/2013/6/7/530
Signed-off-by: Alexander Kochetkov al.koc...@gmail.com
---
drivers/i2c/busses/i2c-omap.c |2 --
1 file changed, 2 deletions(-)
diff --git a/drivers/i2c/busses/i2c-omap.c b/drivers/i2c/busses/i2c-omap.c
index 90dcc2e..9af7095 100644
--- a/drivers/i2c/busses/i2c-omap.c
+++ b/drivers/i2c/busses/i2c-omap.c
@@ -926,14 +926,12 @@ omap_i2c_isr_thread(int this_irq, void *dev_id)
if (stat OMAP_I2C_STAT_NACK) {
err |= OMAP_I2C_STAT_NACK;
omap_i2c_ack_stat(dev, OMAP_I2C_STAT_NACK);
- break;
}
if (stat OMAP_I2C_STAT_AL) {
dev_err(dev-dev, Arbitration lost\n);
err |= OMAP_I2C_STAT_AL;
omap_i2c_ack_stat(dev, OMAP_I2C_STAT_AL);
- break;
}
/*
--
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 v13 5/9] arm: omap1: Migrate debug_ll macros to use 8250.S
The omap1's debug-macro.S is similar to the generic 8250 code. Compared to the 8520 code the omap1 macro automatically determines what UART to use based on breadcrumbs left by the bootloader and automatically copes with the eccentric register layout on OMAP7XX. This patch drops both these features and relies instead on the generic 8250 macros: 1. Dropping support for the bootloader breadcrumbs is identical to the way the migration was handled for OMAP2 (see 808b7e07464d...). 2. Support for OMAP7XX still exists but it must be configured by hand (DEBUG_OMAP7XXUART1/2/3) rather than handled at runtime. Signed-off-by: Daniel Thompson daniel.thomp...@linaro.org Cc: Russell King li...@arm.linux.org.uk Cc: linux-arm-ker...@lists.infradead.org Cc: Tony Lindgren t...@atomide.com Cc: Arnd Bergmann arnd.bergm...@linaro.org Cc: linux-omap@vger.kernel.org Tested-by: Aaro Koskinen aaro.koski...@iki.fi --- arch/arm/Kconfig.debug | 57 +- arch/arm/mach-omap1/include/mach/debug-macro.S | 101 - 2 files changed, 56 insertions(+), 102 deletions(-) delete mode 100644 arch/arm/mach-omap1/include/mach/debug-macro.S diff --git a/arch/arm/Kconfig.debug b/arch/arm/Kconfig.debug index 6dc39e69fe12..80e8ac50551e 100644 --- a/arch/arm/Kconfig.debug +++ b/arch/arm/Kconfig.debug @@ -495,6 +495,30 @@ choice Say Y here if you want kernel low-level debugging support on TI-NSPIRE CX models. + config DEBUG_OMAP1UART1 + bool Kernel low-level debugging via OMAP1 UART1 + depends on ARCH_OMAP1 + select DEBUG_UART_8250 + help + Say Y here if you want kernel low-level debugging support + on OMAP1 based platforms (except OMAP730) on the UART1. + + config DEBUG_OMAP1UART2 + bool Kernel low-level debugging via OMAP1 UART2 + depends on ARCH_OMAP1 + select DEBUG_UART_8250 + help + Say Y here if you want kernel low-level debugging support + on OMAP1 based platforms (except OMAP730) on the UART2. + + config DEBUG_OMAP1UART3 + bool Kernel low-level debugging via OMAP1 UART3 + depends on ARCH_OMAP1 + select DEBUG_UART_8250 + help + Say Y here if you want kernel low-level debugging support + on OMAP1 based platforms (except OMAP730) on the UART3. + config DEBUG_OMAP2UART1 bool OMAP2/3/4 UART1 (omap2/3 sdp boards and some omap3 boards) depends on ARCH_OMAP2PLUS @@ -537,6 +561,30 @@ choice depends on ARCH_OMAP2PLUS select DEBUG_OMAP2PLUS_UART + config DEBUG_OMAP7XXUART1 + bool Kernel low-level debugging via OMAP730 UART1 + depends on ARCH_OMAP730 + select DEBUG_UART_8250 + help + Say Y here if you want kernel low-level debugging support + on OMAP730 based platforms on the UART1. + + config DEBUG_OMAP7XXUART2 + bool Kernel low-level debugging via OMAP730 UART2 + depends on ARCH_OMAP730 + select DEBUG_UART_8250 + help + Say Y here if you want kernel low-level debugging support + on OMAP730 based platforms on the UART2. + + config DEBUG_OMAP7XXUART3 + bool Kernel low-level debugging via OMAP730 UART3 + depends on ARCH_OMAP730 + select DEBUG_UART_8250 + help + Say Y here if you want kernel low-level debugging support + on OMAP730 based platforms on the UART3. + config DEBUG_TI81XXUART1 bool Kernel low-level debugging messages via TI81XX UART1 (ti8148evm) depends on ARCH_OMAP2PLUS @@ -1163,6 +1211,9 @@ config DEBUG_UART_PHYS default 0xffc02000 if DEBUG_SOCFPGA_UART default 0xffd82340 if ARCH_IOP13XX default 0xfff36000 if DEBUG_HIGHBANK_UART + default 0xfffb if DEBUG_OMAP1UART1 || DEBUG_OMAP7XXUART1 + default 0xfffb0800 if DEBUG_OMAP1UART2 || DEBUG_OMAP7XXUART2 + default 0xfffb9800 if DEBUG_OMAP1UART3 || DEBUG_OMAP7XXUART3 default 0xfffe8600 if DEBUG_UART_BCM63XX default 0xf700 if ARCH_IOP33X depends on DEBUG_LL_UART_8250 || DEBUG_LL_UART_PL01X || \ @@ -1236,6 +1287,9 @@ config DEBUG_UART_VIRT default 0xfef0 if ARCH_IXP4XX !CPU_BIG_ENDIAN default 0xfef3 if ARCH_IXP4XX CPU_BIG_ENDIAN default 0xfef36000 if DEBUG_HIGHBANK_UART + default 0xfefb if DEBUG_OMAP1UART1 || DEBUG_OMAP7XXUART1 + default 0xfefb0800 if DEBUG_OMAP1UART2 || DEBUG_OMAP7XXUART2 + default 0xfefb9800 if DEBUG_OMAP1UART3 || DEBUG_OMAP7XXUART3 default 0xfefff700 if ARCH_IOP33X
Re: [RFC] adp1653: Add device tree bindings for LED controller
* Pavel Machek pa...@ucw.cz [141117 02:17]: On Mon 2014-11-17 11:09:45, Pali Rohár wrote: On Monday 17 November 2014 11:05:19 Pavel Machek wrote: Hi! On Mon 2014-11-17 09:43:19, Pali Rohár wrote: On Sunday 16 November 2014 08:59:28 Pavel Machek wrote: For device tree people: Yes, I know I'll have to create file in documentation, but does the binding below look acceptable? I'll clean up driver code a bit more, remove the printks. Anything else obviously wrong? I think that this patch is probably not good and specially not for n900. adp1653 should be registered throw omap3 isp camera subsystem which does not have DT support yet. Can you explain? adp1653 is independend device on i2c bus, and we have kernel driver for it (unlike rest of n900 camera system). Just now it is unusable due to lack of DT binding. It has two functions, LED light and a camera flash; yes, the second one should be integrated to the rest of camera system, but that is not yet merged. That should not prevent us from merging DT support for the flash, so that this part can be tested/maintained. Ok. When ISP camera subsystem has DT support somebody will modify n900 DT to add camera flash from adp1653 to ISP... I believe it will not be hard. Exactly. And yes, I'd like to get complete camera support for n900 merged. But first step is make sure existing support does not break. There's nothing stopping us from initializing the camera code from pdata-quirks.c for now to keep it working. Certainly the binding should be added to the driver, but that removes a dependency to the legacy booting mode if things are otherwise working. 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: [RFC] adp1653: Add device tree bindings for LED controller
Hi Pavel,
On Sun, Nov 16, 2014 at 08:59:28AM +0100, Pavel Machek wrote:
For device tree people: Yes, I know I'll have to create file in
documentation, but does the binding below look acceptable?
I'll clean up driver code a bit more, remove the printks. Anything
else obviously wrong?
Jacek Anaszewski is working on flash support for LED devices. I think it'd
be good to sync the DT bindings for the two, as the types of devices
supported by the LED API and the V4L2 flash API are quite similar.
Cc Jacek.
Signed-off-by: Pavel Machek pa...@ucw.cz
Thanks,
Pavel
diff --git a/arch/arm/boot/dts/omap3-n900.dts
b/arch/arm/boot/dts/omap3-n900.dts
index 739fcf2..ed0bfc1 100644
--- a/arch/arm/boot/dts/omap3-n900.dts
+++ b/arch/arm/boot/dts/omap3-n900.dts
@@ -553,6 +561,18 @@
ti,usb-charger-detection = isp1704;
};
+
+ adp1653: adp1653@30 {
+ compatible = ad,adp1653;
+ reg = 0x30;
+
+ max-flash-timeout-usec = 50;
+ max-flash-intensity-uA= 32;
+ max-torch-intensity-uA = 5;
+ max-indicator-intensity-uA = 17500;
+
+ gpios = gpio3 24 GPIO_ACTIVE_HIGH; /* Want 88 */
+ };
};
i2c3 {
diff --git a/drivers/media/i2c/adp1653.c b/drivers/media/i2c/adp1653.c
index 873fe19..e21ed02 100644
--- a/drivers/media/i2c/adp1653.c
+++ b/drivers/media/i2c/adp1653.c
@@ -8,6 +8,7 @@
* Contributors:
* Sakari Ailus sakari.ai...@iki.fi
* Tuukka Toivonen tuukka...@gmail.com
+ * Pavel Machek pa...@ucw.cz
*
* This program is free software; you can redistribute it and/or
* modify it under the terms of the GNU General Public License
@@ -34,9 +35,12 @@
#include linux/module.h
#include linux/i2c.h
#include linux/slab.h
+#include linux/of_gpio.h
#include media/adp1653.h
#include media/v4l2-device.h
+#include linux/gpio.h
+
#define TIMEOUT_MAX 82
#define TIMEOUT_STEP 54600
#define TIMEOUT_MIN (TIMEOUT_MAX - ADP1653_REG_CONFIG_TMR_SET_MAX \
@@ -308,7 +316,16 @@ __adp1653_set_power(struct adp1653_flash *flash, int on)
{
int ret;
- ret = flash-platform_data-power(flash-subdev, on);
+ if (flash-platform_data-power)
+ ret = flash-platform_data-power(flash-subdev, on);
+ else {
+ gpio_set_value(flash-platform_data-power_gpio, on);
+ if (on) {
+ /* Some delay is apparently required. */
+ udelay(20);
+ }
+ }
+
if (ret 0)
return ret;
@@ -316,8 +333,13 @@ __adp1653_set_power(struct adp1653_flash *flash, int on)
return 0;
ret = adp1653_init_device(flash);
- if (ret 0)
+ if (ret = 0)
+ return ret;
+
+ if (flash-platform_data-power)
flash-platform_data-power(flash-subdev, 0);
+ else
+ gpio_set_value(flash-platform_data-power_gpio, 0);
return ret;
}
@@ -407,21 +429,87 @@ static int adp1653_resume(struct device *dev)
#endif /* CONFIG_PM */
+
+
+
+
+
+
+
+
+
+
+
+
+
+static int adp1653_of_init(struct i2c_client *client, struct adp1653_flash
*flash,
+struct device_node *node)
+{
+ u32 val;
+ struct adp1653_platform_data *pd;
+ enum of_gpio_flags flags;
+ int gpio;
+
+ if (!node)
+ return -EINVAL;
+
+ printk(adp1653: no platform data\n);
+ pd = devm_kzalloc(client-dev, sizeof(*pd), GFP_KERNEL);
+ if (!pd)
+ return -ENOMEM;
+ flash-platform_data = pd;
+
+
+
+
+
+
+
+ if (of_property_read_u32(node, max-flash-timeout-usec, val)) return
-EINVAL;
+ pd-max_flash_timeout = val;
+ if (of_property_read_u32(node, max-flash-intensity-uA, val)) return
-EINVAL;
+ pd-max_flash_intensity = val/1000;
+ if (of_property_read_u32(node, max-torch-intensity-uA, val)) return
-EINVAL;
+ pd-max_torch_intensity = val/1000;
+ if (of_property_read_u32(node, max-indicator-intensity-uA, val))
return -EINVAL;
+ pd-max_indicator_intensity = val;
+
+ if (!of_find_property(node, gpios, NULL)) {
+ printk(No gpio node\n);
+ return -EINVAL;
+ }
+
+ gpio = of_get_gpio_flags(node, 0, flags);
+ if (gpio 0) {
+ printk(Error getting GPIO\n);
+ return -EINVAL;
+ }
+
+ pd-power_gpio = gpio;
+
+ return 0;
+}
+
+
static int adp1653_probe(struct i2c_client *client,
const struct i2c_device_id *devid)
{
struct adp1653_flash *flash;
int ret;
- /* we couldn't work without platform data */
- if (client-dev.platform_data == NULL)
- return -ENODEV;
+ printk(adp1653: probe\n);
flash =
Re: [RFC] adp1653: Add device tree bindings for LED controller
On Monday 17 November 2014 15:55:46 Tony Lindgren wrote: * Pavel Machek pa...@ucw.cz [141117 02:17]: On Mon 2014-11-17 11:09:45, Pali Rohár wrote: On Monday 17 November 2014 11:05:19 Pavel Machek wrote: Hi! On Mon 2014-11-17 09:43:19, Pali Rohár wrote: On Sunday 16 November 2014 08:59:28 Pavel Machek wrote: For device tree people: Yes, I know I'll have to create file in documentation, but does the binding below look acceptable? I'll clean up driver code a bit more, remove the printks. Anything else obviously wrong? I think that this patch is probably not good and specially not for n900. adp1653 should be registered throw omap3 isp camera subsystem which does not have DT support yet. Can you explain? adp1653 is independend device on i2c bus, and we have kernel driver for it (unlike rest of n900 camera system). Just now it is unusable due to lack of DT binding. It has two functions, LED light and a camera flash; yes, the second one should be integrated to the rest of camera system, but that is not yet merged. That should not prevent us from merging DT support for the flash, so that this part can be tested/maintained. Ok. When ISP camera subsystem has DT support somebody will modify n900 DT to add camera flash from adp1653 to ISP... I believe it will not be hard. Exactly. And yes, I'd like to get complete camera support for n900 merged. But first step is make sure existing support does not break. There's nothing stopping us from initializing the camera code from pdata-quirks.c for now to keep it working. Certainly the binding should be added to the driver, but that removes a dependency to the legacy booting mode if things are otherwise working. Regards, Tony Tony, legacy board code for n900 is not in mainline tree. And that omap3 camera subsystem for n900 is broken since 3.5 kernel... (both Front and Back camera on n900 show only green picture). -- Pali Rohár pali.ro...@gmail.com signature.asc Description: This is a digitally signed message part.
Re: [PATCH v9] ARM: omap: edma: add suspend resume hook
On Friday 14 November 2014 10:37 PM, Daniel Mack wrote: Hi Sekhar, On 11/14/2014 06:03 PM, Sekhar Nori wrote: I think I have asked this before, and I am still not sure why this call to pm_runtime_get_sync() is needed here. From my testing today, this does seem to be a a no-op and this call returns from rpm_resume() because of this check: else if (dev-power.disable_depth == 1 dev-power.is_suspended dev-power.runtime_status == RPM_ACTIVE) retval = 1; Yes. IIRC, it was in fact not needed. So, AFAICS, the net effect is an increment of dev-power.usage_count (which is already greater than 0) and its subsequent decrement at the end of the function. After removing this call I did not see any EDMA malfunction as well (can access MMC/SD just fine after suspend/resume cycle). So, any objections to merging this patch with the attached hunk applied? Looks good to me, we can still add it back later if it turns out to be needed. Okay, thanks for the confirmation. Regards, Sekhar -- 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: [RFC] adp1653: Add device tree bindings for LED controller
Hi Pali, On Mon, Nov 17, 2014 at 04:01:31PM +0100, Pali Rohár wrote: On Monday 17 November 2014 15:55:46 Tony Lindgren wrote: * Pavel Machek pa...@ucw.cz [141117 02:17]: On Mon 2014-11-17 11:09:45, Pali Rohár wrote: On Monday 17 November 2014 11:05:19 Pavel Machek wrote: Hi! On Mon 2014-11-17 09:43:19, Pali Rohár wrote: On Sunday 16 November 2014 08:59:28 Pavel Machek wrote: For device tree people: Yes, I know I'll have to create file in documentation, but does the binding below look acceptable? I'll clean up driver code a bit more, remove the printks. Anything else obviously wrong? I think that this patch is probably not good and specially not for n900. adp1653 should be registered throw omap3 isp camera subsystem which does not have DT support yet. Can you explain? adp1653 is independend device on i2c bus, and we have kernel driver for it (unlike rest of n900 camera system). Just now it is unusable due to lack of DT binding. It has two functions, LED light and a camera flash; yes, the second one should be integrated to the rest of camera system, but that is not yet merged. That should not prevent us from merging DT support for the flash, so that this part can be tested/maintained. Ok. When ISP camera subsystem has DT support somebody will modify n900 DT to add camera flash from adp1653 to ISP... I believe it will not be hard. Exactly. And yes, I'd like to get complete camera support for n900 merged. But first step is make sure existing support does not break. There's nothing stopping us from initializing the camera code from pdata-quirks.c for now to keep it working. Certainly the binding should be added to the driver, but that removes a dependency to the legacy booting mode if things are otherwise working. Regards, Tony Tony, legacy board code for n900 is not in mainline tree. And that omap3 camera subsystem for n900 is broken since 3.5 kernel... (both Front and Back camera on n900 show only green picture). Can you capture raw bayer images correctly? I assume green means YUV buffers that are all zero. Do you know more specifically which patch breaks it? -- Regards, Sakari Ailus e-mail: sakari.ai...@iki.fi XMPP: sai...@retiisi.org.uk -- 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: [RFC] adp1653: Add device tree bindings for LED controller
* Pali Rohár pali.ro...@gmail.com [141117 07:03]: On Monday 17 November 2014 15:55:46 Tony Lindgren wrote: There's nothing stopping us from initializing the camera code from pdata-quirks.c for now to keep it working. Certainly the binding should be added to the driver, but that removes a dependency to the legacy booting mode if things are otherwise working. Tony, legacy board code for n900 is not in mainline tree. And that omap3 camera subsystem for n900 is broken since 3.5 kernel... (both Front and Back camera on n900 show only green picture). I'm still seeing the legacy board code for n900 in mainline tree :) It's deprecated, but still there. Are you maybe talking about some other piece of platform_data that's no longer in the mainline kernel? No idea what might be wrong with the camera though. 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 v7.1 11/19] OMAPDSS: hdmi: Make hdmi_mode_has_audio() more user friedly
Hi Jyri,
On 14.11.2014 17:05, Jyri Sarha wrote:
On 11/14/2014 04:37 PM, Vladimir Zapolskiy wrote:
Hi Jyri,
On 12.11.2014 16:41, Jyri Sarha wrote:
Signed-off-by: Jyri Sarha jsa...@ti.com
---
drivers/video/fbdev/omap2/dss/hdmi.h |4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/video/fbdev/omap2/dss/hdmi.h
b/drivers/video/fbdev/omap2/dss/hdmi.h
index a6e08ff..6d129f2 100644
--- a/drivers/video/fbdev/omap2/dss/hdmi.h
+++ b/drivers/video/fbdev/omap2/dss/hdmi.h
@@ -345,9 +345,9 @@ void hdmi_wp_audio_config_format(struct hdmi_wp_data
*wp,
struct hdmi_audio_format *aud_fmt);
void hdmi_wp_audio_config_dma(struct hdmi_wp_data *wp,
struct hdmi_audio_dma *aud_dma);
-static inline bool hdmi_mode_has_audio(int mode)
+static inline bool hdmi_mode_has_audio(struct hdmi_config *cfg)
{
- return mode == HDMI_HDMI ? true : false;
+ return cfg-hdmi_dvi_mode == HDMI_HDMI ? true : false;
}
/* HDMI DRV data */
would it be possible for you to rearrange the changes preserving the
following sequence?
1) 13/19
2) 15/19
3) 11/19
4) 14/19
5) 16/19
Sure, I can do that. Everything should be fine in that order too.
Otherwise I'm worried that someone's git rebase may fail.
sorry again, I meant git-bisect, git rebase is fine.
But do not follow why. Did you notice that 10/19 removes the config
options that enable the pieces of code that are deleted in 13/19 and
15/19. IOW, the code that uses hdmi_mode_has_audio() (and would become
broken by 11/19) is already disabled by 10/19. Git-wise I see no problem
either.
Right, I was worried by changed hdmi_mode_has_audio() API and still
present source code, which uses the old API (it is fixed in the
following patches). If the code that uses hdmi_mode_has_audio() is
disabled by 10/19 and the kernel can be successfully compiled and
working on partial application of the changeset, then there should be no
problem with git-bisect, and probably no need to rearrange the commits.
I'll rearrange the patches if you still insist there is a problem with
current order, but I would like to understand why.
--
With best wishes,
Vladimir
--
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
USB OTG doesn't work in HOST mode on OMAP3 processor on 3.18-rc5
Hi all, I'm trying to use the USB OTG driver of OMAP3 processor in HOST mode when it's configured in dual role mode (CONFIG_USB_MUSB_DUAL_ROLE=y) The test case that I'm trying to solve is as follows. 1) Boot the board. 2) Put the USB ID pin to ground 3) Connect a pendrive. In such case doesn't work as expected and pendrive is never detected. Enabling debug information, I see that the phyter (twl4030) is constantly polling the STS_HW_CONDITIONS register, who reports: twl4030_usb 4807.i2c:twl@48:twl4030-usb: HW_CONDITIONS 0x54/84; link 1 The STS_HW_CONDITIONS register reports: Bit 2: STS_USB : 1: USB is plugged in. Bit 4: STS_WAKEUP1: Level status of WAKEUP1 pad (active high) = nSLEEP1 Bit 6: STS_WAKEUP3: Level status of WAKEUP3 pad (active high) = CLKREQ I guess that in this case the state machine is waiting for VBUS, and looks for bit 7 STS_VBUS (Level status of VBUS port), but this never occurs. Using an oscilloscope I checked VBUS level and I can confirm that it's a 0 level. My understand is that in this case the driver should enable VBUS but I didn't find where is the best place to do this and why is not doing this already. Any clue on this? Thanks in advance, Enric -- 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: [RFC] adp1653: Add device tree bindings for LED controller
On Monday 17 November 2014 16:04:07 Sakari Ailus wrote: Hi Pali, On Mon, Nov 17, 2014 at 04:01:31PM +0100, Pali Rohár wrote: On Monday 17 November 2014 15:55:46 Tony Lindgren wrote: * Pavel Machek pa...@ucw.cz [141117 02:17]: On Mon 2014-11-17 11:09:45, Pali Rohár wrote: On Monday 17 November 2014 11:05:19 Pavel Machek wrote: Hi! On Mon 2014-11-17 09:43:19, Pali Rohár wrote: On Sunday 16 November 2014 08:59:28 Pavel Machek wrote: For device tree people: Yes, I know I'll have to create file in documentation, but does the binding below look acceptable? I'll clean up driver code a bit more, remove the printks. Anything else obviously wrong? I think that this patch is probably not good and specially not for n900. adp1653 should be registered throw omap3 isp camera subsystem which does not have DT support yet. Can you explain? adp1653 is independend device on i2c bus, and we have kernel driver for it (unlike rest of n900 camera system). Just now it is unusable due to lack of DT binding. It has two functions, LED light and a camera flash; yes, the second one should be integrated to the rest of camera system, but that is not yet merged. That should not prevent us from merging DT support for the flash, so that this part can be tested/maintained. Ok. When ISP camera subsystem has DT support somebody will modify n900 DT to add camera flash from adp1653 to ISP... I believe it will not be hard. Exactly. And yes, I'd like to get complete camera support for n900 merged. But first step is make sure existing support does not break. There's nothing stopping us from initializing the camera code from pdata-quirks.c for now to keep it working. Certainly the binding should be added to the driver, but that removes a dependency to the legacy booting mode if things are otherwise working. Regards, Tony Tony, legacy board code for n900 is not in mainline tree. And that omap3 camera subsystem for n900 is broken since 3.5 kernel... (both Front and Back camera on n900 show only green picture). Can you capture raw bayer images correctly? I assume green means YUV buffers that are all zero. Do you know more specifically which patch breaks it? CCing freemangordon (Ivaylo Dimitrov). He tried to debug it months ago but without success. Should know more info about this problem. I think that commit which broke it was not bisected... -- Pali Rohár pali.ro...@gmail.com signature.asc Description: This is a digitally signed message part.
Re: [RFC] adp1653: Add device tree bindings for LED controller
On Monday 17 November 2014 16:06:17 Tony Lindgren wrote: * Pali Rohár pali.ro...@gmail.com [141117 07:03]: On Monday 17 November 2014 15:55:46 Tony Lindgren wrote: There's nothing stopping us from initializing the camera code from pdata-quirks.c for now to keep it working. Certainly the binding should be added to the driver, but that removes a dependency to the legacy booting mode if things are otherwise working. Tony, legacy board code for n900 is not in mainline tree. And that omap3 camera subsystem for n900 is broken since 3.5 kernel... (both Front and Back camera on n900 show only green picture). I'm still seeing the legacy board code for n900 in mainline tree :) It's deprecated, but still there. Yes, it is there because conversion from board code to DT is not complete yet... It is slow progress but you can watch it on page http://elinux.org/N900 (last two columns). Are you maybe talking about some other piece of platform_data that's no longer in the mainline kernel? Yes, about platform_data which were never in mainline kernel. Just only in other trees. That code is: camera subsystem (with all other devices), cellular modem, bluetooth, radio. No idea what might be wrong with the camera though. Regards, Tony -- Pali Rohár pali.ro...@gmail.com signature.asc Description: This is a digitally signed message part.
Re: [PATCH] ARM: dts: DRA7: Add node for RTC
On 11/17/2014 4:04 PM, Lokesh Vutla wrote:
On 11/17/2014 7:45 AM, Lokesh Vutla wrote:
Add node for RTC.
Signed-off-by: Lokesh Vutla lokeshvu...@ti.com
[n...@ti.com: update with rtc crossbar number]
Signed-off-by: Nishanth Menon n...@ti.com
---
arch/arm/boot/dts/dra7.dtsi | 9 +
1 file changed, 9 insertions(+)
diff --git a/arch/arm/boot/dts/dra7.dtsi b/arch/arm/boot/dts/dra7.dtsi
index 9cc9843..f98f9f0 100644
--- a/arch/arm/boot/dts/dra7.dtsi
+++ b/arch/arm/boot/dts/dra7.dtsi
@@ -1075,6 +1075,15 @@
status = disabled;
};
+rtc: rtcss@48838000 {
Please just name the node rtc@48838000, in accordance with ePAPR.
Okay. will update it.
+compatible = ti,am3352-rtc;
+reg = 0x48838000 0x100;
+interrupts = GIC_SPI 217 IRQ_TYPE_LEVEL_HIGH,
+ GIC_SPI 217 IRQ_TYPE_LEVEL_HIGH;
2 similar interrupts?
both rtc timer and rtc alarm uses same interrupt on DRA7 Soc.
Driver handles it accordingly.
So passing the same interrupt.
I think it would have been better if the driver just handled a single
interrupt.
Thanks and regards,
Lokesh
[...]
WBR, Sergei
--
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: Fail to enter retention
* Ran Shalit ransha...@gmail.com [141116 12:13]: Hello, I'm using OMAP3530 with custom board. I have enabled all power mode features as described in PSP wiki, but it still fails to enter any state different from state0. Works for me with pretty much all omap3 boards I have here with mainline kernel since v3.17 using omap2plus_defconfig. And the following script to idle uarts and enable off-idle (or retention). USB needs to be disconnected and EHCI probably still cannot be enabled. The next thing was trying to get the uart to sleep (though there might be also problems with other domains ?) . On trying to enable uart as wakeup source I get the following: echo enabled /sys/devices/platform/omap/omap_uart.2/power/wakeup cat /sys/devices/platform/omap/omap_uart.2/power/wakeup # disabled (?) echo 1 /sys/devices/platform/omap/omap_uart.2/sleep_timeout ~ # [ 85.006622] omap_device: omap_uart.2: new worst case deactivate latency 0: 61035 [ 85.559844] omap_device: omap_uart.2: new worst case activate latency 0: 61035 [ 982.415161] omap_device: omap_uart.2: new worst case deactivate latency 0: 91552 console hangs here Sounds like you need to enable the wake-up interrupt for the UART. See the interrupts-extended entry for many omap3-*.dts files: interrupts-extended = intc 74 omap3_pmx_core OMAP3_UART3_RX; If you get it working, care to update the instructions in the wiki too? Regards, Tony 8 -- #!/bin/bash uarts=$(find /sys/class/tty/tty[SO]*/device/power/ -type d) for uart in $uarts; do echo 3000 $uart/autosuspend_delay_ms 21 done uarts=$(find /sys/class/tty/ttyO*/power/ -type d 2/dev/null) for uart in $uarts; do echo enabled $uart/wakeup 21 echo auto $uart/control 21 done echo 1 /sys/kernel/debug/pm_debug/enable_off_mode -- 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] Fixes: 1d7afc9 i2c: omap: ack IRQ in parts
commit 1d7afc95946487945cc7f5019b41255b72224b70 (i2c: omap: ack IRQ in parts)
changed the interrupt handler to complete transfers without clearing
XRDY (AL case) and ARDY (NACK case) flags. XRDY or ARDY interrupts will be
fired again. As a result, ISR keep processing transfer after it was already
complete (from the driver code point of view).
A didn't see real impacts of the 1d7afc9, but it is really bad idea to
have ISR running on user data after transfer was complete.
It looks, what 1d7afc9 violate TI specs in what how AL and NACK should be
handled (see Note 1, sprugn4r, Figure 17-31 and Figure 17-32).
According to specs (if I understood correctly), in case of NACK and AL driver
must reset NACK, AL, ARDY, RDR, and RRDY (Master Receive Mode), and
NACK, AL, ARDY, and XDR (Master Transmitter Mode).
All that is done down the code under the if condition:
if (stat (OMAP_I2C_STAT_ARDY | OMAP_I2C_STAT_NACK | OMAP_I2C_STAT_AL)) ...
The patch restore pre 1d7afc9 logic of handling NACK and AL interrupts, so
no interrupts is fired after ISR informs the rest of driver what transfer
complete.
Note: instead of removing break under NACK case, we could just replace 'break'
with 'continue' and allow NACK transfer to finish using ARDY event. I found
that NACK and ARDY bits usually set together. That case confirm TI wiki:
http://processors.wiki.ti.com/index.php/I2C_Tips#Detecting_and_handling_NACK
In order if someone interested in the event traces for NACK and AL cases,
I sent them to mailing list.
Tested on Beagleboard XM C.
Signed-off-by: Alexander Kochetkov al.koc...@gmail.com
Cc: sta...@vger.kernel.org # v3.7+
---
drivers/i2c/busses/i2c-omap.c |2 --
1 file changed, 2 deletions(-)
diff --git a/drivers/i2c/busses/i2c-omap.c b/drivers/i2c/busses/i2c-omap.c
index 90dcc2e..9af7095 100644
--- a/drivers/i2c/busses/i2c-omap.c
+++ b/drivers/i2c/busses/i2c-omap.c
@@ -926,14 +926,12 @@ omap_i2c_isr_thread(int this_irq, void *dev_id)
if (stat OMAP_I2C_STAT_NACK) {
err |= OMAP_I2C_STAT_NACK;
omap_i2c_ack_stat(dev, OMAP_I2C_STAT_NACK);
- break;
}
if (stat OMAP_I2C_STAT_AL) {
dev_err(dev-dev, Arbitration lost\n);
err |= OMAP_I2C_STAT_AL;
omap_i2c_ack_stat(dev, OMAP_I2C_STAT_AL);
- break;
}
/*
--
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
Re: [PATCH] Fixes: 1d7afc9 i2c: omap: ack IRQ in parts
That's RESEND Previous one patch was: i2c: omap: fix NACK and Arbitration Lost irq handling http://www.spinics.net/lists/linux-i2c/msg17490.html I'll made more testing of current (linux/master) i2c driver (without my patch) and here I send test results. For traces I used custom patch attached to the e-mail. For simulating I2C bus conditions, I used simple MCU connected to Beagleboard using I2C bus. MCU can act as slave and as master, and Beagleboard can instruct MCU to setup special conditions on the bus. I used oscilloscope to control signals on wire. The results indicates what: 1. current i2c driver actually doesn't cause controller hang and client code segfaults. (my previous patch incorrectly blame that) 2. it looks, that current i2c, doesn't strictly follow TI specs (AM-DM37x Multimedia Device Silicon Revision 1.x - sprugn4r, Figure 17-31. HS I2C Master Transmitter Mode ... and Figure 17-32. HS I2C Master Receiver Mode ..., note 1) 3. current i2c driver keeps processing interrupts after it call omap_i2c_complete_cmd. 4. in NACK case current driver call omap_i2c_complete_cmd two times. The patch fixes 2, 3, 4. Here how spotted problems looks like. i2c controller initiate master write transfer to slave device what doesn't exist on the i2c bus. (isr thread keeps processing interrupts (ARDY) after it signaled transfer completion, and call complete second time) = [ 2481.152770] omap_i2c omap_i2c.2: addr: 0x0068, len: 4, flags: 0x0, stop: 1 [ 2481.152801] omap_i2c omap_i2c.2: Pre submit: STAT=0x0100; IE=0x601f; CON=0x8000 (omap_i2c_xfer_msg:584) [ 2481.152832] omap_i2c omap_i2c.2: Hard ISR: STAT=0x1110; IE=0x601f; CON=0x8602 (omap_i2c_isr:911) [ 2481.152862] omap_i2c omap_i2c.2: Post submit: STAT=0x1110; IE=0x601f; CON=0x8602 (omap_i2c_xfer_msg:586) [ 2481.152893] omap_i2c omap_i2c.2: Wait comlete: STAT=0x1110; IE=0x601f; CON=0x8602 (omap_i2c_xfer_msg:615) [ 2481.152923] omap_i2c omap_i2c.2: Thread ISR: STAT=0x1112; IE=0x601f; CON=0x8602 (omap_i2c_isr_thread:936) [ 2481.152954] omap_i2c omap_i2c.2: IRQ (ISR = 0x0012) [ 2481.152954] omap_i2c omap_i2c.2: Complete: STAT=0x0114; IE=0x601f; CON=0x8200 (omap_i2c_isr_thread:1055) [ 2481.152984] omap_i2c omap_i2c.2: Hard ISR: STAT=0x0114; IE=0x601f; CON=0x8200 (omap_i2c_isr:911) [ 2481.153015] omap_i2c omap_i2c.2: Thread ISR: STAT=0x0114; IE=0x601f; CON=0x8200 (omap_i2c_isr_thread:936) [ 2481.153015] omap_i2c omap_i2c.2: IRQ (ISR = 0x0014) [ 2481.153045] omap_i2c omap_i2c.2: Complete: STAT=0x0100; IE=0x601f; CON=0x8200 (omap_i2c_isr_thread:1055) [ 2481.153106] omap_i2c omap_i2c.2: Got comlete: STAT=0x0100; IE=0x601f; CON=0x8200 (omap_i2c_xfer_msg:618) [ 2481.153106] omap_i2c omap_i2c.2: Got NACK - send STP: STAT=0x0100; IE=0x601f; CON=0x8200 (omap_i2c_xfer_msg:642) i2c controller initiate master read transfer to slave device what doesn't exist on the i2c bus. (isr thread keeps processing interrupts (ARDY) after it signaled transfer completion, and call complete second time) = [ 3201.693603] omap_i2c omap_i2c.2: addr: 0x0068, len: 4, flags: 0x1, stop: 1 [ 3201.693603] omap_i2c omap_i2c.2: Pre submit: STAT=0x0100; IE=0x601f; CON=0x8000 (omap_i2c_xfer_msg:584) [ 3201.693634] omap_i2c omap_i2c.2: Post submit: STAT=0x0100; IE=0x601f; CON=0x8403 (omap_i2c_xfer_msg:586) [ 3201.693634] omap_i2c omap_i2c.2: Wait comlete: STAT=0x1100; IE=0x601f; CON=0x8402 (omap_i2c_xfer_msg:615) [ 3201.693756] omap_i2c omap_i2c.2: Hard ISR: STAT=0x0106; IE=0x601f; CON=0x8000 (omap_i2c_isr:911) [ 3201.693847] omap_i2c omap_i2c.2: Thread ISR: STAT=0x0106; IE=0x601f; CON=0x8000 (omap_i2c_isr_thread:936) [ 3201.693847] omap_i2c omap_i2c.2: IRQ (ISR = 0x0006) [ 3201.693878] omap_i2c omap_i2c.2: Complete: STAT=0x0104; IE=0x601f; CON=0x8000 (omap_i2c_isr_thread:1055) [ 3201.693908] omap_i2c omap_i2c.2: Hard ISR: STAT=0x0104; IE=0x601f; CON=0x8000 (omap_i2c_isr:911) [ 3201.693908] omap_i2c omap_i2c.2: Thread ISR: STAT=0x0104; IE=0x601f; CON=0x8000 (omap_i2c_isr_thread:936) [ 3201.693939] omap_i2c omap_i2c.2: IRQ (ISR = 0x0004) [ 3201.693939] omap_i2c omap_i2c.2: Complete: STAT=0x0100; IE=0x601f; CON=0x8000 (omap_i2c_isr_thread:1055) [ 3201.693969] omap_i2c omap_i2c.2: Got comlete: STAT=0x0100; IE=0x601f; CON=0x8000 (omap_i2c_xfer_msg:618) [ 3201.694000] omap_i2c omap_i2c.2: Got NACK - send STP: STAT=0x0100; IE=0x601f; CON=0x8000 (omap_i2c_xfer_msg:642) i2c controller initiate master write transfer to slave device and get NACK on the second data byte (address and first data bytes transmit successfully). (isr thread keeps processing interrupts (ARDY) after it signaled transfer completion, and call complete second time) = [ 3457.679901] omap_i2c omap_i2c.2: addr: 0x0058, len: 4, flags: 0x0, stop: 1 [ 3457.679931] omap_i2c omap_i2c.2: Pre submit: STAT=0x0100; IE=0x601f; CON=0x8000 (omap_i2c_xfer_msg:584) [ 3457.679962] omap_i2c omap_i2c.2: Hard ISR: STAT=0x0110;
Re: Fail to enter retention
Hi Tony, Thanks very much for suggestions, I am able to wakeup the uart (though it takes about 10 seconds till it wakeup). Anyway, after wakeup when I try to see the state I get: ~ # cat /dbg/pm_debug/count usbhost_pwrdm (ON),OFF:0,RET:0,INA:0,ON:1,RET-LOGIC-OFF:0,RET-MEMBANK1-OFF:0 sgx_pwrdm (OFF),OFF:1,RET:0,INA:0,ON:1,RET-LOGIC-OFF:0,RET-MEMBANK1-OFF:0 per_pwrdm (ON),OFF:0,RET:0,INA:0,ON:1,RET-LOGIC-OFF:0,RET-MEMBANK1-OFF:0 dss_pwrdm (ON),OFF:0,RET:3,INA:4,ON:7,RET-LOGIC-OFF:0,RET-MEMBANK1-OFF:0 cam_pwrdm (RET),OFF:0,RET:1,INA:0,ON:1,RET-LOGIC-OFF:0,RET-MEMBANK1-OFF:0 core_pwrdm (ON),OFF:0,RET:0,INA:0,ON:1,RET-LOGIC-OFF:0,RET-MEMBANK1-OFF:0,RET-MEMBANK2-OFF:0 neon_pwrdm (ON),OFF:0,RET:0,INA:0,ON:1,RET-LOGIC-OFF:0 mpu_pwrdm (ON),OFF:0,RET:0,INA:0,ON:1,RET-LOGIC-OFF:0,RET-MEMBANK1-OFF:0 iva2_pwrdm (RET),OFF:0,RET:1,INA:0,ON:1,RET-LOGIC-OFF:0,RET-MEMBANK1-OFF:0,RET-MEMBANK2-OFF:0,RET-MEMBANK3-OFF:0,RET-MEMBANK4-OFF:0 per_clkdm-per_pwrdm (11) usbhost_clkdm-usbhost_pwrdm (3) cam_clkdm-cam_pwrdm (0) dss_clkdm-dss_pwrdm (2) core_l4_clkdm-core_pwrdm (12) core_l3_clkdm-core_pwrdm (4) d2d_clkdm-core_pwrdm (0) sgx_clkdm-sgx_pwrdm (0) iva2_clkdm-iva2_pwrdm (0) neon_clkdm-neon_pwrdm (0) mpu_clkdm-mpu_pwrdm (0) prm_clkdm-wkup_pwrdm (0) cm_clkdm-core_pwrdm (0) ~ # cat /sys/devices/system/cpu/cpu0/cpuidle/state0/time 811807044 ~ # cat /sys/devices/system/cpu/cpu0/cpuidle/state2/time 0 ~ # cat /sys/devices/system/cpu/cpu0/cpuidle/state3/time 0 ~ # cat /sys/devices/system/cpu/cpu0/cpuidle/state4/time 0 ~ # cat /sys/devices/system/cpu/cpu0/cpuidle/state5/time 0 ~ # cat /sys/devices/system/cpu/cpu0/cpuidle/state6/time 0 Do you have any suggestion, how I can understnad why it did not get into retention and how to continue from this point ? Thanks very much, Ran On Mon, Nov 17, 2014 at 6:22 PM, Tony Lindgren t...@atomide.com wrote: * Ran Shalit ransha...@gmail.com [141116 12:13]: Hello, I'm using OMAP3530 with custom board. I have enabled all power mode features as described in PSP wiki, but it still fails to enter any state different from state0. Works for me with pretty much all omap3 boards I have here with mainline kernel since v3.17 using omap2plus_defconfig. And the following script to idle uarts and enable off-idle (or retention). USB needs to be disconnected and EHCI probably still cannot be enabled. The next thing was trying to get the uart to sleep (though there might be also problems with other domains ?) . On trying to enable uart as wakeup source I get the following: echo enabled /sys/devices/platform/omap/omap_uart.2/power/wakeup cat /sys/devices/platform/omap/omap_uart.2/power/wakeup # disabled (?) echo 1 /sys/devices/platform/omap/omap_uart.2/sleep_timeout ~ # [ 85.006622] omap_device: omap_uart.2: new worst case deactivate latency 0: 61035 [ 85.559844] omap_device: omap_uart.2: new worst case activate latency 0: 61035 [ 982.415161] omap_device: omap_uart.2: new worst case deactivate latency 0: 91552 console hangs here Sounds like you need to enable the wake-up interrupt for the UART. See the interrupts-extended entry for many omap3-*.dts files: interrupts-extended = intc 74 omap3_pmx_core OMAP3_UART3_RX; If you get it working, care to update the instructions in the wiki too? Regards, Tony 8 -- #!/bin/bash uarts=$(find /sys/class/tty/tty[SO]*/device/power/ -type d) for uart in $uarts; do echo 3000 $uart/autosuspend_delay_ms 21 done uarts=$(find /sys/class/tty/ttyO*/power/ -type d 2/dev/null) for uart in $uarts; do echo enabled $uart/wakeup 21 echo auto $uart/control 21 done echo 1 /sys/kernel/debug/pm_debug/enable_off_mode -- 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] Fixes: 1d7afc9 i2c: omap: ack IRQ in parts
Grygorii Strashko earlier reported solution for the issue. 17 нояб. 2014 г., в 17:41, Grygorii Strashko grygorii.stras...@ti.com написал(а): Seems you've got the same issue as I :) long time ago https://lkml.org/lkml/2013/6/7/530 -- 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 OTG doesn't work in HOST mode on OMAP3 processor on 3.18-rc5
* Enric Balletbo Serra eballe...@gmail.com [141117 07:15]: Hi all, I'm trying to use the USB OTG driver of OMAP3 processor in HOST mode when it's configured in dual role mode (CONFIG_USB_MUSB_DUAL_ROLE=y) The test case that I'm trying to solve is as follows. 1) Boot the board. 2) Put the USB ID pin to ground 3) Connect a pendrive. In such case doesn't work as expected and pendrive is never detected. Enabling debug information, I see that the phyter (twl4030) is constantly polling the STS_HW_CONDITIONS register, who reports: twl4030_usb 4807.i2c:twl@48:twl4030-usb: HW_CONDITIONS 0x54/84; link 1 The STS_HW_CONDITIONS register reports: Bit 2: STS_USB : 1: USB is plugged in. Bit 4: STS_WAKEUP1: Level status of WAKEUP1 pad (active high) = nSLEEP1 Bit 6: STS_WAKEUP3: Level status of WAKEUP3 pad (active high) = CLKREQ I guess that in this case the state machine is waiting for VBUS, and looks for bit 7 STS_VBUS (Level status of VBUS port), but this never occurs. Using an oscilloscope I checked VBUS level and I can confirm that it's a 0 level. My understand is that in this case the driver should enable VBUS but I didn't find where is the best place to do this and why is not doing this already. Any clue on this? Just tested v3.18-rc5 with beagleboard xm, and the host mode enumerates the devices, then may fail with insufficient bus power at least for the WLAN device I tried with. I noticed that this only works with CONFIG_USB_MUSB_HDRC and CONFIG_TWL4030_USB built into the kernel. No luck so far with them as loadable modules for some reason. Looks like also USB gadgets fail with MUSB as modules. And on the 37xx EVM, I've never had any luck getting any twl4030_usb interrupts for some reason. 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
Smartreflex - validation failed
Hello, Does anyone knows how to validate smartreflex operation? I am setting new fequency but I than see that the voltage in all points is still the same as following: It seems that smartreflex is not enabled in default, so I enable smartreflext as following: ~ # echo 1 /dbg/voltage/vdd_core/smartreflex/autocomp ~ # echo 1 /dbg/voltage/vdd_mpu/smartreflex/autocomp I than change the frequency but I always see the same voltage as following: ~ # echo 55 /sys/devices/system/cpu/cpu0/cpufreq/scaling_setspeed ~ # cat /dbg/voltage/vdd_core/smartreflex/autocomp 1 ~ # cat /sys/class/regulator/regulator.1/microvolts 180 ~ # cat /sys/class/regulator/regulator.2/microvolts 185 ~ # cat /sys/class/regulator/regulator.3/microvolts 180 ~ # cat /sys/class/regulator/regulator.4/microvolts 280 ~ # cat /sys/class/regulator/regulator.5/microvolts 180 ~ # cat /sys/class/regulator/regulator.6/microvolts 180 ~ # cat /sys/class/regulator/regulator.7/microvolts 280 ~ # cat /sys/class/regulator/regulator.1/microvolts 180 ~ # cat /sys/class/regulator/regulator.2/microvolts 185 ~ # cat /sys/class/regulator/regulator.3/microvolts 180 ~ # cat /sys/class/regulator/regulator.4/microvolts 280 ~ # cat /sys/class/regulator/regulator.5/microvolts 180 ~ # cat /sys/class/regulator/regulator.6/microvolts 180 ~ # cat /sys/class/regulator/regulator.7/microvolts 280 ~ # ~ # echo 50 /sys/devices/system/cpu/cpu0/cpufreq/scaling_setspeed ~ # cat /dbg/voltage/vdd_core/smartreflex/autocomp 1 ~ # cat /sys/class/regulator/regulator.1/microvolts 180 ~ # cat /sys/class/regulator/regulator.2/microvolts 185 ~ # cat /sys/class/regulator/regulator.3/microvolts 180 ~ # cat /sys/class/regulator/regulator.4/microvolts 280 ~ # cat /sys/class/regulator/regulator.5/microvolts 180 ~ # cat /sys/class/regulator/regulator.6/microvolts 180 ~ # cat /sys/class/regulator/regulator.7/microvolts 280 ~ # cat /sys/class/regulator/regulator.1/microvolts 180 ~ # cat /sys/class/regulator/regulator.2/microvolts 185 ~ # cat /sys/class/regulator/regulator.3/microvolts 180 ~ # cat /sys/class/regulator/regulator.4/microvolts 280 ~ # cat /sys/class/regulator/regulator.5/microvolts 180 ~ # cat /sys/class/regulator/regulator.6/microvolts 180 ~ # cat /sys/class/regulator/regulator.7/microvolts 280 ~ # Thanks for any suggestions, Ran -- 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: Fail to enter retention
* Ran Shalit ransha...@gmail.com [141117 09:14]: Hi Tony, Thanks very much for suggestions, I am able to wakeup the uart (though it takes about 10 seconds till it wakeup). The wake-up should happen within few hundred milliseconds at most. Sounds like you're waking on some timer event instead. Do you have any suggestion, how I can understnad why it did not get into retention and how to continue from this point ? You need to look if you have some devices blocking deeper idle states in cm_idlest*_core and cm_idlest_per registers. The device will automatically idle whatever it can if there are no blockers. I believe at least EHCI still is blocking, and MUSB if configured and cable connected. 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
[PATCH v2 2/2] ARM: dts: Add devicetree for NovaTech OrionLXm
This adds the NovaTech OrionLXm which is based on the AM335x SoC
http://www.novatechweb.com/substation-automation/orionlxm/
RAM: 512MiB
Flash: 4GB eMMC
Ethernet PHYs: 2x Micrel KSZ8041FTLI
USB ports are used internally by the expansion cards.
Internal micro SD slot is available.
Signed-off-by: George McCollister george.mccollis...@gmail.com
---
.../devicetree/bindings/arm/omap/omap.txt | 3 +
arch/arm/boot/dts/Makefile | 3 +-
arch/arm/boot/dts/am335x-lxm.dts | 362 +
3 files changed, 367 insertions(+), 1 deletion(-)
create mode 100644 arch/arm/boot/dts/am335x-lxm.dts
diff --git a/Documentation/devicetree/bindings/arm/omap/omap.txt
b/Documentation/devicetree/bindings/arm/omap/omap.txt
index ddd9bcd..4f6a82c 100644
--- a/Documentation/devicetree/bindings/arm/omap/omap.txt
+++ b/Documentation/devicetree/bindings/arm/omap/omap.txt
@@ -132,6 +132,9 @@ Boards:
- AM335X Bone : Low cost community board
compatible = ti,am335x-bone, ti,am33xx, ti,omap3
+- AM335X OrionLXm : Substation Automation Platform
+ compatible = novatech,am335x-lxm, ti,am33xx
+
- OMAP5 EVM : Evaluation Module
compatible = ti,omap5-evm, ti,omap5
diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile
index 38c89ca..454ee6c 100644
--- a/arch/arm/boot/dts/Makefile
+++ b/arch/arm/boot/dts/Makefile
@@ -331,7 +331,8 @@ dtb-$(CONFIG_SOC_AM33XX) += am335x-base0033.dtb \
am335x-evm.dtb \
am335x-evmsk.dtb \
am335x-nano.dtb \
- am335x-pepper.dtb
+ am335x-pepper.dtb \
+ am335x-lxm.dtb
dtb-$(CONFIG_ARCH_OMAP4) += omap4-duovero-parlor.dtb \
omap4-panda.dtb \
omap4-panda-a4.dtb \
diff --git a/arch/arm/boot/dts/am335x-lxm.dts b/arch/arm/boot/dts/am335x-lxm.dts
new file mode 100644
index 000..7266a00
--- /dev/null
+++ b/arch/arm/boot/dts/am335x-lxm.dts
@@ -0,0 +1,362 @@
+/*
+ * Copyright (C) 2014 NovaTech LLC - http://www.novatechweb.com
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ */
+/dts-v1/;
+
+#include am33xx.dtsi
+
+/ {
+ model = NovaTech OrionLXm;
+ compatible = novatech,am335x-lxm, ti,am33xx;
+
+ cpus {
+ cpu@0 {
+ cpu0-supply = vdd1_reg;
+ };
+ };
+
+ memory {
+ device_type = memory;
+ reg = 0x8000 0x2000; /* 512 MB */
+ };
+
+ /* Power supply provides a fixed 5V @2A */
+ vbat: fixedregulator@0 {
+ compatible = regulator-fixed;
+ regulator-name = vbat;
+ regulator-min-microvolt = 500;
+ regulator-max-microvolt = 500;
+ regulator-boot-on;
+ };
+
+ /* Power supply provides a fixed 3.3V @3A */
+ vmmcsd_fixed: fixedregulator@1 {
+ compatible = regulator-fixed;
+ regulator-name = vmmcsd_fixed;
+ regulator-min-microvolt = 330;
+ regulator-max-microvolt = 330;
+ regulator-boot-on;
+ };
+};
+
+am33xx_pinmux {
+ mmc1_pins: pinmux_mmc1_pins {
+ pinctrl-single,pins =
+ 0xf0 (PIN_INPUT_PULLUP | MUX_MODE0) /* mmc0_dat3 */
+ 0xf4 (PIN_INPUT_PULLUP | MUX_MODE0) /* mmc0_dat2 */
+ 0xf8 (PIN_INPUT_PULLUP | MUX_MODE0) /* mmc0_dat1 */
+ 0xfc (PIN_INPUT_PULLUP | MUX_MODE0) /* mmc0_dat0 */
+ 0x100 (PIN_INPUT_PULLUP | MUX_MODE0)/* mmc0_clk */
+ 0x104 (PIN_INPUT_PULLUP | MUX_MODE0)/* mmc0_cmd */
+ ;
+ };
+
+ i2c0_pins: pinmux_i2c0_pins {
+ pinctrl-single,pins =
+ 0x188 (PIN_INPUT | MUX_MODE0) /* i2c0_sda.i2c0_sda */
+ 0x18c (PIN_INPUT | MUX_MODE0) /* i2c0_scl.i2c0_scl */
+ ;
+ };
+
+ cpsw_default: cpsw_default {
+ pinctrl-single,pins =
+ /* Slave 1 */
+ 0x64 (PIN_INPUT_PULLDOWN | MUX_MODE7) /* rmii1_int */
+ 0x10c (PIN_INPUT_PULLDOWN | MUX_MODE1) /* rmii1_crs_dv
*/
+ 0x110 (PIN_INPUT_PULLDOWN | MUX_MODE1) /* rmii1_rxer */
+ 0x114 (PIN_OUTPUT_PULLDOWN | MUX_MODE1) /* rmii1_txen */
+ 0x124 (PIN_OUTPUT_PULLDOWN | MUX_MODE1) /* rmii1_td1 */
+ 0x128 (PIN_OUTPUT_PULLDOWN | MUX_MODE1) /* rmii1_td0 */
+ 0x13c (PIN_INPUT_PULLDOWN | MUX_MODE1) /* rmii1_rd1 */
+ 0x140 (PIN_INPUT_PULLDOWN | MUX_MODE1) /* rmii1_rd0 */
+ 0x144 (PIN_INPUT_PULLDOWN | MUX_MODE0) /* rmii1_refclk
*/
+
+ /* Slave 2 */
+
Re: [PATCH v2 2/2] ARM: dts: Add devicetree for NovaTech OrionLXm
On Mon, Nov 17, 2014 at 01:02:35PM -0600, George McCollister wrote:
This adds the NovaTech OrionLXm which is based on the AM335x SoC
http://www.novatechweb.com/substation-automation/orionlxm/
RAM: 512MiB
Flash: 4GB eMMC
Ethernet PHYs: 2x Micrel KSZ8041FTLI
USB ports are used internally by the expansion cards.
Internal micro SD slot is available.
Signed-off-by: George McCollister george.mccollis...@gmail.com
this looks might better to my eyes:
Reviewed-by: Felipe Balbi ba...@ti.com
---
.../devicetree/bindings/arm/omap/omap.txt | 3 +
arch/arm/boot/dts/Makefile | 3 +-
arch/arm/boot/dts/am335x-lxm.dts | 362
+
3 files changed, 367 insertions(+), 1 deletion(-)
create mode 100644 arch/arm/boot/dts/am335x-lxm.dts
diff --git a/Documentation/devicetree/bindings/arm/omap/omap.txt
b/Documentation/devicetree/bindings/arm/omap/omap.txt
index ddd9bcd..4f6a82c 100644
--- a/Documentation/devicetree/bindings/arm/omap/omap.txt
+++ b/Documentation/devicetree/bindings/arm/omap/omap.txt
@@ -132,6 +132,9 @@ Boards:
- AM335X Bone : Low cost community board
compatible = ti,am335x-bone, ti,am33xx, ti,omap3
+- AM335X OrionLXm : Substation Automation Platform
+ compatible = novatech,am335x-lxm, ti,am33xx
+
- OMAP5 EVM : Evaluation Module
compatible = ti,omap5-evm, ti,omap5
diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile
index 38c89ca..454ee6c 100644
--- a/arch/arm/boot/dts/Makefile
+++ b/arch/arm/boot/dts/Makefile
@@ -331,7 +331,8 @@ dtb-$(CONFIG_SOC_AM33XX) += am335x-base0033.dtb \
am335x-evm.dtb \
am335x-evmsk.dtb \
am335x-nano.dtb \
- am335x-pepper.dtb
+ am335x-pepper.dtb \
+ am335x-lxm.dtb
dtb-$(CONFIG_ARCH_OMAP4) += omap4-duovero-parlor.dtb \
omap4-panda.dtb \
omap4-panda-a4.dtb \
diff --git a/arch/arm/boot/dts/am335x-lxm.dts
b/arch/arm/boot/dts/am335x-lxm.dts
new file mode 100644
index 000..7266a00
--- /dev/null
+++ b/arch/arm/boot/dts/am335x-lxm.dts
@@ -0,0 +1,362 @@
+/*
+ * Copyright (C) 2014 NovaTech LLC - http://www.novatechweb.com
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ */
+/dts-v1/;
+
+#include am33xx.dtsi
+
+/ {
+ model = NovaTech OrionLXm;
+ compatible = novatech,am335x-lxm, ti,am33xx;
+
+ cpus {
+ cpu@0 {
+ cpu0-supply = vdd1_reg;
+ };
+ };
+
+ memory {
+ device_type = memory;
+ reg = 0x8000 0x2000; /* 512 MB */
+ };
+
+ /* Power supply provides a fixed 5V @2A */
+ vbat: fixedregulator@0 {
+ compatible = regulator-fixed;
+ regulator-name = vbat;
+ regulator-min-microvolt = 500;
+ regulator-max-microvolt = 500;
+ regulator-boot-on;
+ };
+
+ /* Power supply provides a fixed 3.3V @3A */
+ vmmcsd_fixed: fixedregulator@1 {
+ compatible = regulator-fixed;
+ regulator-name = vmmcsd_fixed;
+ regulator-min-microvolt = 330;
+ regulator-max-microvolt = 330;
+ regulator-boot-on;
+ };
+};
+
+am33xx_pinmux {
+ mmc1_pins: pinmux_mmc1_pins {
+ pinctrl-single,pins =
+ 0xf0 (PIN_INPUT_PULLUP | MUX_MODE0) /* mmc0_dat3 */
+ 0xf4 (PIN_INPUT_PULLUP | MUX_MODE0) /* mmc0_dat2 */
+ 0xf8 (PIN_INPUT_PULLUP | MUX_MODE0) /* mmc0_dat1 */
+ 0xfc (PIN_INPUT_PULLUP | MUX_MODE0) /* mmc0_dat0 */
+ 0x100 (PIN_INPUT_PULLUP | MUX_MODE0)/* mmc0_clk */
+ 0x104 (PIN_INPUT_PULLUP | MUX_MODE0)/* mmc0_cmd */
+ ;
+ };
+
+ i2c0_pins: pinmux_i2c0_pins {
+ pinctrl-single,pins =
+ 0x188 (PIN_INPUT | MUX_MODE0) /* i2c0_sda.i2c0_sda */
+ 0x18c (PIN_INPUT | MUX_MODE0) /* i2c0_scl.i2c0_scl */
+ ;
+ };
+
+ cpsw_default: cpsw_default {
+ pinctrl-single,pins =
+ /* Slave 1 */
+ 0x64 (PIN_INPUT_PULLDOWN | MUX_MODE7) /* rmii1_int */
+ 0x10c (PIN_INPUT_PULLDOWN | MUX_MODE1) /* rmii1_crs_dv
*/
+ 0x110 (PIN_INPUT_PULLDOWN | MUX_MODE1) /* rmii1_rxer */
+ 0x114 (PIN_OUTPUT_PULLDOWN | MUX_MODE1) /* rmii1_txen */
+ 0x124 (PIN_OUTPUT_PULLDOWN | MUX_MODE1) /* rmii1_td1 */
+ 0x128 (PIN_OUTPUT_PULLDOWN | MUX_MODE1) /* rmii1_td0 */
+ 0x13c (PIN_INPUT_PULLDOWN | MUX_MODE1) /* rmii1_rd1 */
+ 0x140 (PIN_INPUT_PULLDOWN | MUX_MODE1) /*
Re: ASoC: omap-mcbsp: Deletion of an unnecessary check before the function call kfree
On 11/17/2014 03:15 PM, SF Markus Elfring wrote: From: Markus Elfring elfr...@users.sourceforge.net Date: Mon, 17 Nov 2014 14:05:27 +0100 The kfree() function tests whether its argument is NULL and then returns immediately. Thus the test around the call is not needed. This issue was detected by using the Coccinelle software. Signed-off-by: Markus Elfring elfr...@users.sourceforge.net --- sound/soc/omap/mcbsp.c | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-) Acked-by: Jarkko Nikula jarkko.nik...@bitmer.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: Fail to enter retention
You need to look if you have some devices blocking deeper idle states in cm_idlest*_core and cm_idlest_per registers. The device will automatically idle whatever it can if there are no blockers. I believe at least EHCI still is blocking, and MUSB if configured and cable connected. I'll check the registers value, should I then try to modify this registers in order to get into retention ? I will still have to disable serial right ? Maybe some kernel process which run in background prevents retention ? Is there some simple way to debug this or do I need to modify these registers ? Thank you very much, Ran On Mon, Nov 17, 2014 at 8:09 PM, Tony Lindgren t...@atomide.com wrote: * Ran Shalit ransha...@gmail.com [141117 09:14]: Hi Tony, Thanks very much for suggestions, I am able to wakeup the uart (though it takes about 10 seconds till it wakeup). The wake-up should happen within few hundred milliseconds at most. Sounds like you're waking on some timer event instead. Do you have any suggestion, how I can understnad why it did not get into retention and how to continue from this point ? You need to look if you have some devices blocking deeper idle states in cm_idlest*_core and cm_idlest_per registers. The device will automatically idle whatever it can if there are no blockers. I believe at least EHCI still is blocking, and MUSB if configured and cable connected. 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: Fail to enter retention
* Ran Shalit ransha...@gmail.com [141117 11:48]: You need to look if you have some devices blocking deeper idle states in cm_idlest*_core and cm_idlest_per registers. The device will automatically idle whatever it can if there are no blockers. I believe at least EHCI still is blocking, and MUSB if configured and cable connected. I'll check the registers value, should I then try to modify this registers in order to get into retention ? No, those are read-only status registers. You need idle the drivers that show as blocking in those registers. I will still have to disable serial right ? Maybe some kernel process which run in background prevents retention ? Yes otherwise the UART bits will show as blocking in those registers. Is there some simple way to debug this or do I need to modify these registers ? Just printing them out in the idle loop most likely will give you the info you need. 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: Fail to enter retention
Hi Tony, Just printing the registers out in the idle loop most likely will give you the info you need. Probably a dumb question... But if I try to print them won't it automatically wakes up the serial (by the way should the serial wakeup be configured to RX pin only ?) Another thing I don't understand... Can it be that there is some ongoing kernel process that also prevent me for entering retention ? I think maybe I should try first to suspend (instead of trying to enter retention in idle) , maybe it might bring better result ? Thanks very much, Ran On Mon, Nov 17, 2014 at 10:38 PM, Tony Lindgren t...@atomide.com wrote: * Ran Shalit ransha...@gmail.com [141117 11:48]: You need to look if you have some devices blocking deeper idle states in cm_idlest*_core and cm_idlest_per registers. The device will automatically idle whatever it can if there are no blockers. I believe at least EHCI still is blocking, and MUSB if configured and cable connected. I'll check the registers value, should I then try to modify this registers in order to get into retention ? No, those are read-only status registers. You need idle the drivers that show as blocking in those registers. I will still have to disable serial right ? Maybe some kernel process which run in background prevents retention ? Yes otherwise the UART bits will show as blocking in those registers. Is there some simple way to debug this or do I need to modify these registers ? Just printing them out in the idle loop most likely will give you the info you need. 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: DRA7: Add node for RTC
Hi,
On Monday 17 November 2014 09:42 PM, Sergei Shtylyov wrote:
On 11/17/2014 4:04 PM, Lokesh Vutla wrote:
On 11/17/2014 7:45 AM, Lokesh Vutla wrote:
Add node for RTC.
Signed-off-by: Lokesh Vutla lokeshvu...@ti.com
[n...@ti.com: update with rtc crossbar number]
Signed-off-by: Nishanth Menon n...@ti.com
---
arch/arm/boot/dts/dra7.dtsi | 9 +
1 file changed, 9 insertions(+)
diff --git a/arch/arm/boot/dts/dra7.dtsi b/arch/arm/boot/dts/dra7.dtsi
index 9cc9843..f98f9f0 100644
--- a/arch/arm/boot/dts/dra7.dtsi
+++ b/arch/arm/boot/dts/dra7.dtsi
@@ -1075,6 +1075,15 @@
status = disabled;
};
+rtc: rtcss@48838000 {
Please just name the node rtc@48838000, in accordance with ePAPR.
Okay. will update it.
+compatible = ti,am3352-rtc;
+reg = 0x48838000 0x100;
+interrupts = GIC_SPI 217 IRQ_TYPE_LEVEL_HIGH,
+ GIC_SPI 217 IRQ_TYPE_LEVEL_HIGH;
2 similar interrupts?
both rtc timer and rtc alarm uses same interrupt on DRA7 Soc.
Driver handles it accordingly.
So passing the same interrupt.
I think it would have been better if the driver just handled a single
interrupt.
There are certain SoCs with RTC IP where timer and alarm uses different
interrupts.
Driver has to take care of that scenario also. So it expects two interrupts
from dt.
Thanks and regards,
Lokesh
Thanks and regards,
Lokesh
[...]
WBR, Sergei
--
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: N900 modem support in 3.18-rc1
On Sun 2014-11-16 13:29:50, Robert Jarzmik wrote: Pavel Machek pa...@ucw.cz writes: On Thu 2014-11-13 20:18:04, Aaro Koskinen wrote: Hi, On Thu, Nov 13, 2014 at 09:45:36AM -0800, Tony Lindgren wrote: * Pavel Machek pa...@ucw.cz [141113 08:23]: OTOH ofono seems pretty reasonable. So I played a bit, and result is python/pygtk gui which can receive an sms, initiate a call, and report missed call. If someone wants to play, source is at https://gitorious.org/tui/tui/source/b6141107e9341a1412720aed4b0d09143dfa2f4e:ofone Pavel, care to fill in the the following type patch with some instructions in the description now that you got it working? Could we even have some permanent instructions under Documentation/? Something like this? commit 375d8d9f17433ade6afae91d4f34e170f0af04c4 Author: Pavel pa...@ucw.cz Date: Sun Nov 16 11:10:59 2014 +0100 Add basic documentation for n900 testing. Signed-off-by: Pavel Machek pa...@ucw.cz diff --git a/Documentation/cellphones.txt b/Documentation/cellphones.txt new file mode 100644 index 000..d7e8e7a --- /dev/null +++ b/Documentation/cellphones.txt @@ -0,0 +1,90 @@ +Running Linux on Cellphones +=== + +At this moment (2014), there are no cellphones completely supported by +mainline kernel. Another problem is lack of hackable userspace to run +on cellphone, even when kernel support is available. Hi Pavel, There is the Mitac Mio A701. Very old but still it is there, with the kernel part maintained. Userspace was based on QTopia in 2008. I don't maintain that part anymore though. The GSM part relies on a simple ttyS device (modem has its internal flash), no real data at that time, or rather 2G only, but the 07.10 mux support was never included in Qtopia ... Thanks for the info. I added +Mainline has support for Mitac Mio A701, but that having only 64MiB +RAM, QTopia is the software to use there. Pavel -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html -- 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 v8 0/7] Enable L2 cache support on Exynos4210/4x12 SoCs
Hello, On 2014-11-14 15:51, Arnd Bergmann wrote: On Friday 14 November 2014 15:11:58 Marek Szyprowski wrote: I assume that after all comments from previous versions, no more changes are needed to this patchset and I would really like to have it queued to v3.19. Arnd, Olof: could you take this patchset thought arm-soc tree? It already contains all dependencies. Kukjin: could you ack this patchset? I'd rather see this merged through Russell's tree, as most of the patches are for core code, and only three are for the platform. Ok, I will upload v9 posted yesterday to Russell's patch system when http://www.arm.linux.org.uk/ gets back to life. For the exynos patches: Acked-by: Arnd Bergmann a...@arndb.de Best regards -- Marek Szyprowski, PhD Samsung RD Institute Poland -- 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
