Re: FEATURES - is it good enough
On Wed, Dec 02, 2009 at 08:06:16 +0200, Menon, Nishanth wrote: Alexander Shishkin said the following on 12/01/2009 05:42 PM: On Fri, Nov 20, 2009 at 02:09:01 -0600, Nishanth Menon wrote: Aguirre, Sergio had written, on 11/20/2009 01:43 PM, the following: -Original Message- From: Menon, Nishanth Sent: Friday, November 20, 2009 1:24 PM To: Kevin Hilman Cc: Shilimkar, Santosh; Aguirre, Sergio; Pandita, Vikram; linux-omap@vger.kernel.org Subject: Re: FEATURES - is it good enough Kevin Hilman had written, on 11/20/2009 12:35 PM, the following: Shilimkar, Santosh santosh.shilim...@ti.com writes: [...] Probably not something ot be attached in this patch, but... I'm a bit curious about something: Why touching omap3_features in OMAP4? Isn't there a omap4_features? Or even better, an omap_features? This is_feature suppose to take care of Errata's also, is it? It's not a bug it's a feature. :) Bug. Santosh pointed out internally to h/w discussion which clearly shows this as a h/w limitation. (thanks santosh) This is errata more than a feature. We better differentiate in this regard I agree, I have a hard time calling this empty fifo read fault a feature. We need a similar thing for errata. Agreed. This is a classic example why we need a common errata handling mechanism scalable across silicon variants on an IP basis. two problems in front of us: a) what do we want to do with 8250 workaround needed for omap3630 and omap4? can we go ahead with features marking it clearly as a misuse of features for the time being IMHO, That for the time being will stay forever if we don't do something now. Most of the big problems are raised because someone says ok, lets have this for the time being. But that time never comes. See that crazy CaMeL-Casing hanging around in /drivers/dsp/bridge/ for a while as an example. When that will ever be fixed? I bet someone said some time: ok, lets fix it later :-) On the other hand. What's the big motivation to have this as a feature? Who else than the serial driver cares about the feature awareness? please see [1] and [2]. this wont be the first time I published something previously that got ignored and got re-discussed. note: The [1] proposal sounds interesting to me, but it's not a very trivial matter. BTW, to be fair, DSPBridge already has plans to get fixed anyways.. Options I can think which were discussed: a) introduce omap3_features omap3_errata: negative: wont read like if I use omap3_has_errata() for OMAP4 code. b) introduce omap_features and omap_errata: negative: how do you link this to IP based usage across silicon (e.g. I2C). How about omap_has_errata(module, errata)? Or even something more generic? hmm.. just throwing more ideas up in the air: Call method: omap_ip_has_errata(u32 ip, u32 rev, u8 check_type, u8 erratum) where, ip = I2C, GPMC, MMC, etc.. rev = revision number check_type = GT, LT, NE, EQ erratum = erratum type omap_cpu_has_errata(u32 cpu_id, u32 rev, u8 check_type, u16 erratum) where, cpu_id = 15xx, 16xx etc ( can this be a function pointer to cpu_is..() functions? if so, how do we register this) rev = chip revision number Is there a use case when a caller would be interested in an erratum of a cpu other than the one it is currently running on? Otherwise it could be omap_this_cpu_has_errata(). And the same for IPs. check_type = GT, LT, NE, EQ Is this meant to compare cpu ids or revision numbers? I'm not sure I follow the idea here. erratum = erratum type Registration/Initialization: ?? Perhaps, statically compiled in tables of per-cpu/rev erratas/features. This has to be better than runtime detection and at least as good as making assumptions based on cpu_is_omap(). maybe this could be extended to features also.. Aren't features and erratas semantically the same thing? Maybe, the same interface could be used. Regards, -- Alex -- 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: Peripheral Power Management
I'm not talking about full chip off in suspend ,,but I'm talking about tern off some modules while they aren't in use however the cpu is running in normal mode not in idle On Wed, Dec 2, 2009 at 11:29 AM, tarek attia tarek.m.at...@gmail.com wrote: Hi All, I know that CPU have power management through CPUFREQ,,but what about the peripherals like (DVI-D) does it have a power management for it as well??,,and the rest of peripherals also ? Appreciate your response, Best Regards, tarek -- 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] PM: Prevent direct cpufreq scaling during initialization
It is seen that the OMAP specific cpufreq initialization code tries to scale the MPU frequency to the highest possible without taking care of the voltage level. On power on reset the power IC does not provide the necessary voltage for the highest available MPU frequency (that would satisfy all Si families). This potentially is an window of opportunity for things to go wrong. Signed-off-by: Romit Dasgupta ro...@ti.com --- diff --git a/arch/arm/plat-omap/cpu-omap.c b/arch/arm/plat-omap/cpu-omap.c index 449b6b6..f94df20 100644 --- a/arch/arm/plat-omap/cpu-omap.c +++ b/arch/arm/plat-omap/cpu-omap.c @@ -149,8 +149,6 @@ static int __init omap_cpu_init(struct cpufreq_policy *policy) VERY_HI_RATE) / 1000; } - clk_set_rate(mpu_clk, policy-cpuinfo.max_freq * 1000); - policy-min = policy-cpuinfo.min_freq; policy-max = policy-cpuinfo.max_freq; policy-cur = omap_getspeed(0); -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 01/20] DSPBRIDGE: driver version 0.1
On Mon, Nov 30, 2009 at 11:54 PM, Omar Ramirez Luna omar.rami...@ti.com wrote: Prior to any further modification set the driver version to be 0.1 It should be the other way around; *after* the modifications have been merged, the version 0.1 would be released. Moreover, it would be nice to get some acknowledgement from Nokia developers that the branch is indeed correct. -- Felipe Contreras -- 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: SR1: VDD autocomp is not active
Hi, all! It seems discussion went off-list somehow, so I won't delete some quoting. On Wed, Dec 2, 2009 at 2:38 PM, Premi, Sanjeev pr...@ti.com wrote: -Original Message- From: Sergey Lapin [mailto:slapi...@gmail.com] Sent: Wednesday, December 02, 2009 1:54 AM To: Premi, Sanjeev Subject: Re: SR1: VDD autocomp is not active I did notice an earlier mail where you mentioned about using an older kernel version. have to back-ported patches specific to silicon identification on this kernel/ I use PM branch of linux-omap git. I just need to make my patches less disgusting by properly porting these. Actually now I think I could do this work even without appropriate tree, since amount of patches is not that big and API is not too different. These patches are not required to make board basically run. It appears that efuse data required for SmartReflex to work may not be available on this silicon... leading to these messages. Right now, I am away from source code, will be able to verify in the morning. Thanks, looking forward for your reply. You should try this with an ES3.1 silicon. If sr_enable() fails, we might see this issue. It seems I only have ES2.1 silicon, so what should I do - disable SR functionality at all - somehow set values the other way? It seems SR is possible on this silicon, only efuse data are absent, so is there a way I could somehow fake these (with some known working values), so the stuff works? Thanks a lot, S. S. -- 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: SR1: VDD autocomp is not active
-Original Message- From: Sergey Lapin [mailto:slapi...@gmail.com] Sent: Wednesday, December 02, 2009 5:35 PM To: Premi, Sanjeev Cc: linux-omap@vger.kernel.org Subject: Re: SR1: VDD autocomp is not active Hi, all! It seems discussion went off-list somehow, so I won't delete some quoting. On Wed, Dec 2, 2009 at 2:38 PM, Premi, Sanjeev pr...@ti.com wrote: -Original Message- From: Sergey Lapin [mailto:slapi...@gmail.com] Sent: Wednesday, December 02, 2009 1:54 AM To: Premi, Sanjeev Subject: Re: SR1: VDD autocomp is not active I did notice an earlier mail where you mentioned about using an older kernel version. have to back-ported patches specific to silicon identification on this kernel/ I use PM branch of linux-omap git. I just need to make my patches less disgusting by properly porting these. Actually now I think I could do this work even without appropriate tree, since amount of patches is not that big and API is not too different. These patches are not required to make board basically run. It appears that efuse data required for SmartReflex to work may not be available on this silicon... leading to these messages. Right now, I am away from source code, will be able to verify in the morning. Thanks, looking forward for your reply. You should try this with an ES3.1 silicon. If sr_enable() fails, we might see this issue. It seems I only have ES2.1 silicon, so what should I do - disable SR functionality at all [sp] Yes. It will be a good starting point. - somehow set values the other way? [sp] It will be difficult for you to ascertain these values. It seems SR is possible on this silicon, only efuse data are absent, so is there a way I could somehow fake these (with some known working values), so the stuff works? [sp] The code will allow you to do so; but without right values kernel execution can go haywire. Best regards, Sanjeev Thanks a lot, S. S. -- 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: SR1: VDD autocomp is not active
On Wed, Dec 2, 2009 at 3:19 PM, Premi, Sanjeev pr...@ti.com wrote: -Original Message- From: Sergey Lapin [mailto:slapi...@gmail.com] Sent: Wednesday, December 02, 2009 5:35 PM To: Premi, Sanjeev Cc: linux-omap@vger.kernel.org Subject: Re: SR1: VDD autocomp is not active Hi, all! It seems discussion went off-list somehow, so I won't delete some quoting. On Wed, Dec 2, 2009 at 2:38 PM, Premi, Sanjeev pr...@ti.com wrote: -Original Message- From: Sergey Lapin [mailto:slapi...@gmail.com] Sent: Wednesday, December 02, 2009 1:54 AM To: Premi, Sanjeev Subject: Re: SR1: VDD autocomp is not active I did notice an earlier mail where you mentioned about using an older kernel version. have to back-ported patches specific to silicon identification on this kernel/ I use PM branch of linux-omap git. I just need to make my patches less disgusting by properly porting these. Actually now I think I could do this work even without appropriate tree, since amount of patches is not that big and API is not too different. These patches are not required to make board basically run. It appears that efuse data required for SmartReflex to work may not be available on this silicon... leading to these messages. Right now, I am away from source code, will be able to verify in the morning. Thanks, looking forward for your reply. You should try this with an ES3.1 silicon. If sr_enable() fails, we might see this issue. It seems I only have ES2.1 silicon, so what should I do - disable SR functionality at all [sp] Yes. It will be a good starting point. - somehow set values the other way? [sp] It will be difficult for you to ascertain these values. It seems SR is possible on this silicon, only efuse data are absent, so is there a way I could somehow fake these (with some known working values), so the stuff works? [sp] The code will allow you to do so; but without right values kernel execution can go haywire. Is it possible somehow to identify right silicon revision before ordering? I mean by part number or something? Also, is there some safe numbers somebody knows about, or is there some way of generating them? S. -- 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] mfd: twl4030: clarify the return value for read and write
We should be checking if all the messages were tranferred or not. Currently we
return success even if none of messages were transferred successfully.
Signed-off-by: Amit Kucheria amit.kuche...@verdurent.com
---
drivers/mfd/twl4030-core.c | 21 +
1 files changed, 13 insertions(+), 8 deletions(-)
diff --git a/drivers/mfd/twl4030-core.c b/drivers/mfd/twl4030-core.c
index cf462b9..6ace378 100644
--- a/drivers/mfd/twl4030-core.c
+++ b/drivers/mfd/twl4030-core.c
@@ -298,10 +298,12 @@ int twl4030_i2c_write(u8 mod_no, u8 *value, u8 reg,
unsigned num_bytes)
ret = i2c_transfer(twl-client-adapter, twl-xfer_msg, 1);
mutex_unlock(twl-xfer_lock);
- /* i2cTransfer returns num messages.translate it pls.. */
- if (ret = 0)
- ret = 0;
- return ret;
+ /* i2c_transfer returns number of messages transferred */
+ if (ret != 1) {
+ pr_err(%s: twl4030_i2c_write failed to transfer all
messages\n, DRIVER_NAME);
+ return ret;
+ } else
+ return 0;
}
EXPORT_SYMBOL(twl4030_i2c_write);
@@ -350,10 +352,13 @@ int twl4030_i2c_read(u8 mod_no, u8 *value, u8 reg,
unsigned num_bytes)
ret = i2c_transfer(twl-client-adapter, twl-xfer_msg, 2);
mutex_unlock(twl-xfer_lock);
- /* i2cTransfer returns num messages.translate it pls.. */
- if (ret = 0)
- ret = 0;
- return ret;
+ /* i2c_transfer returns number of messages transferred */
+ if (ret != 2) {
+ pr_err(%s: twl4030_i2c_read failed to transfer all
messages\n, DRIVER_NAME);
+ return ret;
+ }
+ else
+ return 0;
}
EXPORT_SYMBOL(twl4030_i2c_read);
--
1.6.3.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: SR1: VDD autocomp is not active
[sp] The code will allow you to do so; but without right values kernel execution can go haywire. Is it possible somehow to identify right silicon revision before ordering? I mean by part number or something? Sorry for my ignorance, I've found answer on first question (answer is to read errata properly). Also, is there some safe numbers somebody knows about, or is there some way of generating them? I still persist with this question, though. -- 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] mfd: twl4030: clarify the return value for read and write
Hi,
On Wed, Dec 02, 2009 at 02:31:18PM +0100, ext Amit Kucheria wrote:
@@ -298,10 +298,12 @@ int twl4030_i2c_write(u8 mod_no, u8 *value, u8 reg,
unsigned num_bytes)
ret = i2c_transfer(twl-client-adapter, twl-xfer_msg, 1);
mutex_unlock(twl-xfer_lock);
- /* i2cTransfer returns num messages.translate it pls.. */
- if (ret = 0)
- ret = 0;
- return ret;
+ /* i2c_transfer returns number of messages transferred */
+ if (ret != 1) {
+ pr_err(%s: twl4030_i2c_write failed to transfer all
messages\n, DRIVER_NAME);
this line is over 80-chars
+ return ret;
+ } else
you should have {} here as well.
+ return 0;
}
EXPORT_SYMBOL(twl4030_i2c_write);
@@ -350,10 +352,13 @@ int twl4030_i2c_read(u8 mod_no, u8 *value, u8 reg,
unsigned num_bytes)
ret = i2c_transfer(twl-client-adapter, twl-xfer_msg, 2);
mutex_unlock(twl-xfer_lock);
- /* i2cTransfer returns num messages.translate it pls.. */
- if (ret = 0)
- ret = 0;
- return ret;
+ /* i2c_transfer returns number of messages transferred */
+ if (ret != 2) {
+ pr_err(%s: twl4030_i2c_read failed to transfer all
messages\n, DRIVER_NAME);
over 80-chars
+ return ret;
+ }
+ else
} else {
+ return 0;
}
--
balbi
--
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: [PATCHv3 1/3] OMAP UART: Add omap-serial driver support.
On Wed, Nov 25, 2009 at 12:18 AM, Kevin Hilman khil...@deeprootsystems.com wrote: Govindraj.R govindraj.r...@ti.com writes: From 4756e3743c7acd2de1030b2bd432c1b19f0b9ff5 Mon Sep 17 00:00:00 2001 From: Govindraj R govindraj.r...@ti.com Date: Fri, 13 Nov 2009 12:01:54 +0530 Subject: [PATCH] OMAP UART: Add omap-serial driver support. This patch adds support for OMAP3430-HIGH SPEED UART Controller. It adds support for the following features: 1. It supports Interrupt mode and DMA mode of operation. 2. Supports Hardware flow control and sofware flow control. 3. Debug Console support on all UARTs. Signed-off-by: Govindraj R govindraj.r...@ti.com Some general comments. This should summarize how this is different from the 8250 driver on which it was based, as it's clear that it was based on 8250 but not clear at all what the changes are. At first glance, you've dropped several features from the 8250 driver which we currently use. Namely, the ability for platform code to override some of the defaults: - change irq_flags - serial_in function - optional ioremapping (omap_hwmod layer will have done ioremap already) Agree. uart_port_info [should be renamed to omap_uart_port_info] should grow with fields like irqflags, membase and mapbase feilds. adding these would need rework on the patch: http://patchwork.kernel.org/patch/62555/ Should I work on top of above patch? Serial in function might not be necessary for omap-serial driver, this function was added to handle RX reading by checking if DR bit set in LSR reg. This is taken care in omap-serial driver. --- Regards, Govindraj.R These are now hard-coded in the new driver which makes it significantly less flexible. In a few minutes I will be posting a set of patches to convert the mach-omap2/serial.c to use omap_hwmod/omap_device. This replaces your PATCH 2/3, so please use with any subsequent updates. --- arch/arm/plat-omap/include/plat/omap-serial.h | 115 +++ drivers/serial/Kconfig | 23 + drivers/serial/Makefile | 1 + drivers/serial/omap-serial.c | 1330 + include/linux/serial_core.h | 3 + 5 files changed, 1472 insertions(+), 0 deletions(-) create mode 100644 arch/arm/plat-omap/include/plat/omap-serial.h create mode 100644 drivers/serial/omap-serial.c -- 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
[PATCHv2] mfd: twl4030: clarify the return value for read and write
Infact, we can just return -1 so that caller knows for sure that all messages
were not tranferred. Please consider fixed patch instead.
We should be checking if all the messages were tranferred or not. And return
-1 for failure. Currently we return success (0) even if none of messages were
transferred successfully.
Signed-off-by: Amit Kucheria amit.kuche...@verdurent.com
---
drivers/mfd/twl4030-core.c | 25 +
1 files changed, 17 insertions(+), 8 deletions(-)
diff --git a/drivers/mfd/twl4030-core.c b/drivers/mfd/twl4030-core.c
index 56f1de5..8f9ba79 100644
--- a/drivers/mfd/twl4030-core.c
+++ b/drivers/mfd/twl4030-core.c
@@ -292,10 +292,14 @@ int twl4030_i2c_write(u8 mod_no, u8 *value, u8 reg,
unsigned num_bytes)
ret = i2c_transfer(twl-client-adapter, twl-xfer_msg, 1);
mutex_unlock(twl-xfer_lock);
- /* i2cTransfer returns num messages.translate it pls.. */
- if (ret = 0)
- ret = 0;
- return ret;
+ /* i2c_transfer returns number of messages transferred */
+ if (ret != 1) {
+ pr_err(%s: i2c_write failed to transfer all messages\n,
+ DRIVER_NAME);
+ return -1;
+ } else {
+ return 0;
+ }
}
EXPORT_SYMBOL(twl4030_i2c_write);
@@ -344,10 +348,15 @@ int twl4030_i2c_read(u8 mod_no, u8 *value, u8 reg,
unsigned num_bytes)
ret = i2c_transfer(twl-client-adapter, twl-xfer_msg, 2);
mutex_unlock(twl-xfer_lock);
- /* i2cTransfer returns num messages.translate it pls.. */
- if (ret = 0)
- ret = 0;
- return ret;
+ /* i2c_transfer returns number of messages transferred */
+ if (ret != 2) {
+ pr_err(%s: i2c_read failed to transfer all messages\n,
+ DRIVER_NAME);
+ return -1;
+ }
+ else {
+ return 0;
+ }
}
EXPORT_SYMBOL(twl4030_i2c_read);
--
1.6.3.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: SR1: VDD autocomp is not active
On Wed, Dec 2, 2009 at 4:33 PM, Sergey Lapin slapi...@gmail.com wrote: [sp] The code will allow you to do so; but without right values kernel execution can go haywire. Is it possible somehow to identify right silicon revision before ordering? I mean by part number or something? Sorry for my ignorance, I've found answer on first question (answer is to read errata properly). Also, is there some safe numbers somebody knows about, or is there some way of generating them? I still persist with this question, though. Resume: kernel seems to hang wit SRF disabled and PM enabled. As I have advantage of saving lots of power with PM. disabling SRF seems not to be an option. So it either have to be left as is or numbers should be provided (possibly for even better tasty power saving!) Thanks a lot for your help, S. -- 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-v6 0/4] OMAP: Adding flash support to SDP, ZOOM2 and LDP boards
From 8bc97108cf9c78216f1ea5407ccbd900e6b63dc2 Mon Sep 17 00:00:00 2001 From: Vimal Singh vimalsi...@ti.com Date: Thu, 19 Nov 2009 19:28:11 +0530 This patch series adds flash support for NAND (in sdp, zoom and ldp), OneNAND and NOR (in sdp) Tested on Zoom2 and 3430SDP Vimal Singh (4): [PATCH-v6 1/4] OMAP2/3: Add support for flash on SDP boards [PATCH-v6 2/4] OMAP3: Add support for NAND on ZOOM/LDP boards [PATCH-v6 3/4] OMAP: Zoom2: Enable NAND and JFFS2 support in defconfig [PATCH-v6 4/4] OMAP: 3430SDP: Enable NAND in defconfig I am going to re-post this patch series again and this time I have divided this into 3 (for more convenience in reviewing) . Something like this: 1st series: This patch series will introduce generic gpmc-nand.c for nand device related gpmc init. 2nd series: This patch series will introduce 'board-sdp-flash.c', for flash devices init on SDP boards. And will give an example of using 'gpmc-nand.c' and 'board-sdp-flash.c' by adding flash support to 3430SDP board. 3rd: This series introduces 'board-zoom-flash.c' for NAND init in ZOOM boards. Other patches will add NAND support for ZOOM2, ZOOM3 and LDP. Tony, Is it ok with you? -- Regards, Vimal Singh -- 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: SR1: VDD autocomp is not active
-Original Message- From: Sergey Lapin [mailto:slapi...@gmail.com] Sent: Wednesday, December 02, 2009 7:04 PM To: Premi, Sanjeev Cc: linux-omap@vger.kernel.org Subject: Re: SR1: VDD autocomp is not active [sp] The code will allow you to do so; but without right values kernel execution can go haywire. Is it possible somehow to identify right silicon revision before ordering? I mean by part number or something? Sorry for my ignorance, I've found answer on first question (answer is to read errata properly). Also, is there some safe numbers somebody knows about, or is there some way of generating them? I still persist with this question, though. [sp] These numbers are based on silicon characterization process. There is no other way to generate them. The numbers can change between silicon lots. Best regards, Sanjeev -- 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: [PATCHv2] mfd: twl4030: clarify the return value for read and write
Amit Kucheria wrote:
Infact, we can just return -1 so that caller knows for sure that all messages
were not tranferred. Please consider fixed patch instead.
We should be checking if all the messages were tranferred or not. And return
-1 for failure. Currently we return success (0) even if none of messages were
transferred successfully.
Signed-off-by: Amit Kucheria amit.kuche...@verdurent.com
---
drivers/mfd/twl4030-core.c | 25 +
1 files changed, 17 insertions(+), 8 deletions(-)
diff --git a/drivers/mfd/twl4030-core.c b/drivers/mfd/twl4030-core.c
index 56f1de5..8f9ba79 100644
--- a/drivers/mfd/twl4030-core.c
+++ b/drivers/mfd/twl4030-core.c
@@ -292,10 +292,14 @@ int twl4030_i2c_write(u8 mod_no, u8 *value, u8 reg,
unsigned num_bytes)
ret = i2c_transfer(twl-client-adapter, twl-xfer_msg, 1);
mutex_unlock(twl-xfer_lock);
- /* i2cTransfer returns num messages.translate it pls.. */
- if (ret = 0)
- ret = 0;
- return ret;
+ /* i2c_transfer returns number of messages transferred */
+ if (ret != 1) {
+ pr_err(%s: i2c_write failed to transfer all messages\n,
+ DRIVER_NAME);
+ return -1;
+ } else {
+ return 0;
+ }
}
EXPORT_SYMBOL(twl4030_i2c_write);
@@ -344,10 +348,15 @@ int twl4030_i2c_read(u8 mod_no, u8 *value, u8 reg,
unsigned num_bytes)
ret = i2c_transfer(twl-client-adapter, twl-xfer_msg, 2);
mutex_unlock(twl-xfer_lock);
- /* i2cTransfer returns num messages.translate it pls.. */
- if (ret = 0)
- ret = 0;
- return ret;
+ /* i2c_transfer returns number of messages transferred */
+ if (ret != 2) {
+ pr_err(%s: i2c_read failed to transfer all messages\n,
+ DRIVER_NAME);
+ return -1;
+ }
+ else {
+ return 0;
+ }
The else clause should be on the same line as the brace closing the if clause.
like you did above
So says Documentation/CodingStyle.
- Anand
--
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: Preventing OMAP3 serial driver to take control of all UARTs
On Mon, Nov 30, 2009 at 12:40 PM, Tony Lindgren t...@atomide.com wrote: * Grant Likely grant.lik...@secretlab.ca [091130 09:01]: http://www.elinux.org/Device_Trees I expect to have my prototype ready for review mid-January, and most of the common code should be either merged or queued up in linux-next by that time. While device tree is a nice solution to some of the problems, it still leaves all the issues we already have with buggy and and outdated bootloaders. So we still need to properly initialize the devices in the kernel. Yes, buggy firmware is still a problem. However, if the required configuration is described in the device tree data, then for some things the driver can handle setting up the device and the amount of board-specific code can be reduced. Just for reference, most of the omap bootloader bugs seem to be related to not muxing the pins right or using wrong timings for GPMC. And then things that mostly change during the board development are the GPIO pins, but those can be easily rewritten in the board-*.c files based on the omap_rev. But at least the device tree is a standard model, while the earlier omap tag approach was non-standard. Peter, maybe you've already thought through all this.. But would it be possible to do lightweight device tree that we just use to populate the platform data? This is completely possible. Just having the device tree available doesn't force the kernel to use it for everything. I've found it useful to start small and add things as I need them. Most important thing to remember is to follow the documented established device tree conventions so that common code can understand it. Oh, and speaking of GPIOs, there is a binding for describing GPIO pin connections in the device tree: Documentation/powerpc/dts-bindings/gpio/gpio.txt Cheers, g. -- Grant Likely, B.Sc., P.Eng. Secret Lab Technologies Ltd. -- 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] PM: Prevent direct cpufreq scaling during initialization
On Wed, Dec 2, 2009 at 1:12 PM, Romit Dasgupta ro...@ti.com wrote: It is seen that the OMAP specific cpufreq initialization code tries to scale the MPU frequency to the highest possible without taking care of the voltage level. On power on reset the power IC does not provide the necessary voltage for the highest available MPU frequency (that would satisfy all Si families). This potentially is an window of opportunity for things to go wrong. Signed-off-by: Romit Dasgupta ro...@ti.com --- diff --git a/arch/arm/plat-omap/cpu-omap.c b/arch/arm/plat-omap/cpu-omap.c index 449b6b6..f94df20 100644 --- a/arch/arm/plat-omap/cpu-omap.c +++ b/arch/arm/plat-omap/cpu-omap.c @@ -149,8 +149,6 @@ static int __init omap_cpu_init(struct cpufreq_policy *policy) VERY_HI_RATE) / 1000; } - clk_set_rate(mpu_clk, policy-cpuinfo.max_freq * 1000); - policy-min = policy-cpuinfo.min_freq; policy-max = policy-cpuinfo.max_freq; policy-cur = omap_getspeed(0); This patch leads to hang with current PM branch, SRF and CPU IDLE enabled on OMAP3525 rev C. -- 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: Preventing OMAP3 serial driver to take control of all UARTs
On Wed, Dec 02, 2009 at 08:07:21AM -0700, Grant Likely wrote: Oh, and speaking of GPIOs, there is a binding for describing GPIO pin connections in the device tree: Documentation/powerpc/dts-bindings/gpio/gpio.txt That binding is more about documenting a bank of GPIO pins, while chips like OMAP will need something a bit more flexible. Given the flexibility and complexity of configuring the pins on mobile-oriented SoCs where each function can come out a variety of different pins, and many pins can 3 or 4 functions associated with them (selected by software config), it will definitely bring a new level of complexity to the device tree descriptions. I'm definitely not saying that it is impossible, but it might take a little work to hash out a binding that everyone will be happy with. -Olof -- 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] OMAP3: SDRC: Comment out SDRC AC timing and MR changes in CORE DVFS SRAM code
On Wed, Dec 02, 2009 at 08:12:34AM +0200, Menon, Nishanth wrote: why not make this a #ifdef instead if we need it some other time, a #if 0 and it's intention might not be readable without doing a git annotate in a few months time.. Just remove the code. The old implementation is still there in git and can be brought back if need be. It's the purpose of having revision control in the first place. -Olof -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH v2 01/20] DSPBRIDGE: driver version 0.1
From: Felipe Contreras [mailto:felipe.contre...@gmail.com] On Mon, Nov 30, 2009 at 11:54 PM, Omar Ramirez Luna omar.rami...@ti.com wrote: Prior to any further modification set the driver version to be 0.1 It should be the other way around; *after* the modifications have been merged,the version 0.1 would be released. Nope, version 0.2 will be once modifications are merged and branch is rebased to 2.6.32rc7 Moreover, it would be nice to get some acknowledgement from Nokia developers that the branch is indeed correct. It would be nice to get them but they are not needed. As always any bug reports are welcomed. -- Felipe Contreras Regards, Omar -- 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: Preventing OMAP3 serial driver to take control of all UARTs
On Wed, Dec 2, 2009 at 8:53 AM, Olof Johansson o...@lixom.net wrote: On Wed, Dec 02, 2009 at 08:07:21AM -0700, Grant Likely wrote: Oh, and speaking of GPIOs, there is a binding for describing GPIO pin connections in the device tree: Documentation/powerpc/dts-bindings/gpio/gpio.txt That binding is more about documenting a bank of GPIO pins, while chips like OMAP will need something a bit more flexible. Given the flexibility and complexity of configuring the pins on mobile-oriented SoCs where each function can come out a variety of different pins, and many pins can 3 or 4 functions associated with them (selected by software config), it will definitely bring a new level of complexity to the device tree descriptions. Ah, you're talking about pin muxing configuration, right? Yes, that GPIO binding deals with controllers, not pin mux. Pin mux is very much an SoC specific thing that isn't mapped easily to a generic binding. On the 5200, I haven't attempted to describe pin-mux in the device tree at all, and have either expected firmware to set it up correctly, or fixed it up in the platform code. I'm definitely not saying that it is impossible, but it might take a little work to hash out a binding that everyone will be happy with. Right. g. -- Grant Likely, B.Sc., P.Eng. Secret Lab Technologies Ltd. -- 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: Preventing OMAP3 serial driver to take control of all UARTs
On Wed, Dec 02, 2009 at 09:04:49AM -0700, Grant Likely wrote: Ah, you're talking about pin muxing configuration, right? Yes, that GPIO binding deals with controllers, not pin mux. Pin mux is very much an SoC specific thing that isn't mapped easily to a generic binding. Yep. On the 5200, I haven't attempted to describe pin-mux in the device tree at all, and have either expected firmware to set it up correctly, or fixed it up in the platform code. Yeah. And it's one of the things Tony commented on that firmware tends to get wrong, seems like people aren't doing complete mux configs in u-boot, etc. So, if it needs to be fixed up in platform code, there will (likely) be need for board-specific code there anyway. A bummer, since the device tree would otherwise make it real easy to bring up new boards without kernel code changes. -Olof -- 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] OMAP3: SDRC: Comment out SDRC AC timing and MR changes in CORE DVFS SRAM code
Hello Olof, Nishanth, thanks for the comments, On Wed, 2 Dec 2009, Olof Johansson wrote: On Wed, Dec 02, 2009 at 08:12:34AM +0200, Menon, Nishanth wrote: why not make this a #ifdef instead if we need it some other time, a #if 0 and it's intention might not be readable without doing a git annotate in a few months time.. Just remove the code. The old implementation is still there in git and can be brought back if need be. It's the purpose of having revision control in the first place. I'm leaning towards Nishanth's suggestion and making it a Kconfig option. That way, users who know that other system initiators will be inactive at CORE DVFS time will be able to use optimal SDRC timings in CORE DVFS. The other issue with removing it completely is that I'm holding out the (admittedly slim) hope that someone else will be enticed into helping out with this issue, and so I'd reason that since very few people will look at older revisions, removing it will drastically reduce the chances that others will help. - Paul -- 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] power_supply: Add driver for TWL4030/TPS65950 BCI charger
-Original Message-
From: Grazvydas Ignotas [mailto:nota...@gmail.com]
Sent: Monday, November 30, 2009 3:33 PM
To: Madhusudhan
Cc: linux-ker...@vger.kernel.org; Anton Vorontsov; linux-
o...@vger.kernel.org
Subject: Re: [PATCH] power_supply: Add driver for TWL4030/TPS65950 BCI
charger
On Mon, Nov 30, 2009 at 8:45 PM, Madhusudhan madhu...@ti.com wrote:
-Original Message-
From: Grazvydas Ignotas [mailto:nota...@gmail.com]
Sent: Friday, November 27, 2009 8:44 AM
To: linux-ker...@vger.kernel.org
Cc: Anton Vorontsov; Madhusudhan Chikkature; linux-
o...@vger.kernel.org;
Grazvydas Ignotas
Subject: [PATCH] power_supply: Add driver for TWL4030/TPS65950 BCI
charger
TWL4030/TPS65950 is a multi-function device with integrated charger,
which allows charging from AC or USB. This driver enables the
charger and provides several monitoring functions.
Signed-off-by: Grazvydas Ignotas nota...@gmail.com
---
For this driver to work, TWL4030-core needs to be patched to use
correct macros so that it registers twl4030_bci platform_device.
I'll send patches for this later.
drivers/power/Kconfig |7 +
drivers/power/Makefile |1 +
drivers/power/twl4030_charger.c | 499
Is the file name changed from twl4030_bci_battery.c to twl4030_charger.c
because it mainly supports voltage monitoring only while charging? If yes,
potentially we can add support for monitoring also in discharge state. Do
we intend to change the file name then?
Does the hardware support any monitoring in discharge state? I'm
unable to get any readings, only frozen values (that never update)
from what it had when it was charging. Here is TI confirmation that at
least temperature monitoring won't work while discharging:
http://e2e.ti.com/forums/p/8202/31818.aspx#31818
For this reason I consider BCI a charger.
In the discharge path BCI might not update the registers. It is worth
experiment to try and use MADC conversion to get the values. A driver for
madc is being currently discussed. See the patch:
http://patchwork.kernel.org/patch/62746/
We can try this once the madc driver is accepted in mainline and submit an
update patch to the BCI driver. As a first step I agree that the current BCI
patch should go upstream.
Reviewed-by: Madhusudhan Chikkature madhu...@ti.com
Thanks,
Madhu
Also adding the tested-on info could be helpful here.
ok
snip
+ case POWER_SUPPLY_PROP_VOLTAGE_NOW:
+ /* charging must be active for meaningful result */
+ if (!is_charging) {
How about putting a kern_info here?
That would potentially flood dmesg, will just return -EINVAL like
Anton suggests.
+ val-intval = 0;
+ break;
+ }
+ ret = twl4030_get_voltage(voltage_reg);
+ if (ret 0)
+ return ret;
+ val-intval = ret;
+ break;
+ case POWER_SUPPLY_PROP_CURRENT_NOW:
+ if (!is_charging) {
+ val-intval = 0;
Ditto
+ break;
+ }
+ /* current measurement is shared between AC and USB */
+ ret = twl4030_charger_get_current();
+ if (ret 0)
+ return ret;
+ val-intval = ret;
+ break;
+ case POWER_SUPPLY_PROP_ONLINE:
Does this indicate the source of charging like USB or AC??
There are 2 charging devices registered now, AC and USB, each returns
it's state. This is what most other drivers do.
I'll send v2 later, it will also have more accurate voltage formulas I
got from TI.
--
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: Preventing OMAP3 serial driver to take control of all UARTs
On Wed, Dec 2, 2009 at 9:16 AM, Olof Johansson o...@lixom.net wrote: On Wed, Dec 02, 2009 at 09:04:49AM -0700, Grant Likely wrote: Ah, you're talking about pin muxing configuration, right? Yes, that GPIO binding deals with controllers, not pin mux. Pin mux is very much an SoC specific thing that isn't mapped easily to a generic binding. Yep. On the 5200, I haven't attempted to describe pin-mux in the device tree at all, and have either expected firmware to set it up correctly, or fixed it up in the platform code. Yeah. And it's one of the things Tony commented on that firmware tends to get wrong, seems like people aren't doing complete mux configs in u-boot, etc. So, if it needs to be fixed up in platform code, there will (likely) be need for board-specific code there anyway. A bummer, since the device tree would otherwise make it real easy to bring up new boards without kernel code changes. I didn't create a binding on the 5200 because I actually see very little buggy firmware in that regard (partially because I kept telling people to go fix their firmware). :-) If it ends up being the norm that the kernel has to fix it for a given SoC, then I would create an SoC-specific binding for pin mux configuration in the device tree so that some degree of common code can still fix it up. It should be feasible for board-specific code to be the exception, not the rule. Cheers, g. -- Grant Likely, B.Sc., P.Eng. Secret Lab Technologies Ltd. -- 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] power_supply: Add driver for TWL4030/TPS65950 BCI charger
Hi,
On Fri, Nov 27, 2009 at 03:44:20PM +0100, ext Grazvydas Ignotas wrote:
diff --git a/drivers/power/Makefile b/drivers/power/Makefile
index b96f29d..9cea9b5 100644
--- a/drivers/power/Makefile
+++ b/drivers/power/Makefile
@@ -29,3 +29,4 @@ obj-$(CONFIG_BATTERY_BQ27x00) += bq27x00_battery.o
obj-$(CONFIG_BATTERY_DA9030) += da9030_battery.o
obj-$(CONFIG_BATTERY_MAX17040) += max17040_battery.o
obj-$(CONFIG_CHARGER_PCF50633) += pcf50633-charger.o
+obj-$(CONFIG_CHARGER_TWL4030) += twl4030_charger.o
diff --git a/drivers/power/twl4030_charger.c b/drivers/power/twl4030_charger.c
new file mode 100644
index 000..604dd56
--- /dev/null
+++ b/drivers/power/twl4030_charger.c
@@ -0,0 +1,499 @@
+/*
+ * TWL4030/TPS65950 BCI (Battery Charger Interface) driver
+ *
+ * Copyright (C) 2009 Gražvydas Ignotas nota...@gmail.com
+ *
+ * based on twl4030_bci_battery.c by TI
+ * Copyright (C) 2008 Texas Instruments, Inc.
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ */
+
+#include linux/init.h
+#include linux/module.h
+#include linux/platform_device.h
+#include linux/interrupt.h
+#include linux/i2c/twl4030.h
+#include linux/power_supply.h
+
+#define REG_BCIMSTATEC 0x02
please prepend these defines with e.g. TWL4030_BCI_
this would look like:
#define TWL4030_BCI_MSTATEC 0x02
+#define REG_BCIICHG0x08
+#define REG_BCIVAC 0x0a
+#define REG_BCIVBUS0x0c
+#define REG_BCIMFSTS4 0x10
+#define REG_BCICTL10x23
+
+#define REG_BOOT_BCI 0x07
+#define REG_STS_HW_CONDITIONS 0x0f
+
+#define BCIAUTOWEN 0x20
+#define CONFIG_DONE0x10
+#define CVENAC 0x04
+#define BCIAUTOUSB 0x02
+#define BCIAUTOAC 0x01
+#define BCIMSTAT_MASK 0x3F
+#define STS_VBUS 0x80
+#define STS_CHG0x02
+#define STS_USB_ID 0x04
+#define CGAIN 0x20
+#define USBFASTMCHG0x04
+
+#define STATEC_USB 0x10
+#define STATEC_AC 0x20
+#define STATEC_STATUS_MASK 0x0f
+#define STATEC_QUICK1 0x02
+#define STATEC_QUICK7 0x07
+#define STATEC_COMPLETE1 0x0b
+#define STATEC_COMPLETE4 0x0e
+
+#define BCI_DELAY 100
100ms ??? that's too quick for battery monitoring. Imagine that you'll
have 10 i2c transfers per-second forever with this one. Don't you think
you're waking up omap for nothing ??
something like 1 second when doing heavy operation should be enough and
5 to 10 seconds in idle is good enough as well.
+static struct twl4030_bci_device_info twl4030_bci = {
this should be allocated on probe() time.
+/*
+ * called by TWL4030 USB transceiver driver on USB_PRES interrupt.
+ */
+int twl4030charger_usb_en(int enable)
+{
+ if (twl4030_bci.started)
+ schedule_delayed_work(twl4030_bci.bat_work,
+ msecs_to_jiffies(BCI_DELAY));
I don't like the way you did this. I would expect twl4030-usb to kick
the charger detection based on the VBUS irq. You have to consider the
possibility of boards which won't use BCI module and will have some
bq24xxx chip dealing with that like RX51. So instead of implementing
this here and forcing people to have this driver enabled on e.g. RX51,
you should implement the charger_enable_usb() logic in twl4030-usb
itself. /me thinks
+static int __devinit twl4030_bci_probe(struct platform_device *pdev)
+{
+ int irq;
+ int ret;
+
+ twl4030_charger_enable_ac(true);
+ twl4030_charger_enable_usb(true);
+
+ irq = platform_get_irq(pdev, 0);
+
+ /* CHG_PRES irq */
+ ret = request_irq(irq, twl4030_charger_interrupt,
+ 0, pdev-name, twl4030_bci);
how about using request_threaded_irq() ?? then you avoid having that
workqueue.
--
balbi
--
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: Problems using DSS2 on OMAP3 EVM / Angstrom with rotation
snip The xorg boot log appears reasonably sane until a crash - 640x480 is what the xf86 omapfb driver picks up, so I assume something else is the problem. I'll try to poke at the omapfb source some to see if something is being passed around wrong - I'd appreciate any suggestions on where to look. === ... (II) LoadModule: omapfb (II) Loading /usr/lib/xorg/modules/drivers//omapfb_drv.so (II) Module omapfb: vendor=X.Org Foundation compiled for 1.6.1, module version = 0.1.1 ABI class: X.Org Video Driver, version 5.0 (II) omapfb: Driver for OMAP framebuffer (omapfb) and external LCD controllers: omap1/2/3, S1D13745, HWA742 (WW) Falling back to old probe method for OMAPFB (II) Running in FRAMEBUFFER Mode (WW) Error opening /sys/devices/platform/omapfb/ctrl/name: No such file or direc tory (WW) Can't autodetect LCD controller, assuming internal (II) LCD controller: internal (II) omapfb(0): VideoRAM: 1920KiB (SDRAM) (--) omapfb(0): Depth 16, (==) framebuffer bpp 16 (==) omapfb(0): RGB weight 565 (==) omapfb(0): Default visual is TrueColor (--) omapfb(0): Virtual size is 640x480 (pitch 640) (**) omapfb(0): Built-in mode current (==) omapfb(0): DPI set to (96, 96) (II) Loading sub module fb (II) LoadModule: fb (II) Loading /usr/lib/xorg/modules//libfb.so (II) Module fb: vendor=X.Org Foundation compiled for 1.6.1, module version = 1.0.0 ABI class: X.Org ANSI C Emulation, version 0.4 (II) omapfb(0): DPMS enabled (II) omapfb(0): Video plane capabilities: (II) omapfb(0): Video plane supports the following image formats: (II) omapfb(0): XVideo extension initialized (==) RandR enabled (II) Initializing built-in extension Generic Event Extension (II) Initializing built-in extension SHAPE (II) Initializing built-in extension MIT-SHM (II) Initializing built-in extension XInputExtension (II) Initializing built-in extension XTEST (II) Initializing built-in extension BIG-REQUESTS (II) Initializing built-in extension SYNC (II) Initializing built-in extension XKEYBOARD (II) Initializing built-in extension XC-MISC (II) Initializing built-in extension XINERAMA (II) Initializing built-in extension XFIXES (II) Initializing built-in extension RENDER (II) Initializing built-in extension RANDR (II) Initializing built-in extension COMPOSITE (II) Initializing built-in extension DAMAGE Backtrace: 0: Xorg(xorg_backtrace+0x28) [0xd2540] Fatal server error: Caught signal 11. Server aborting === Does your xorg.conf enable GLX? You may want to try disabling it. ~sanjeev Thanks for all the suggestions, but nothing seems to have worked so far. It looks like X picks up all sorts of configuration settings automatically, since xorg.conf is essentially full of 'default internal device' options. What I can't figure out is how it decides on the requested resolution. The defaults, with omapfb.rotate=1 in bootargs, result in omapfb selecting a virtual resolution of 640x480, but Xorg on boot still tries, based on dmesg, to get a 480x640 overlay somehow (at least that's what my interpretation of the situation is). I've tried adding a screen subsection to xorg.confg, with virtual 640 480 - no effect. I've tried adding in a modeline for 640x480, no effect. I tried rebuilding Angstrom with a few extra lines in /conf/machine/omap3evm.conf (MACHINE_DISPLAY_WIDTH_PIXELS=640, etc), with no effect. Does anyone know exactly how Xorg autoconfigures the default panel in this sort of a situation? My current guess is that it's getting 480x640 from some panel driver somewhere, but I haven't been able to find the source. For compleness, I've attached the Xorg log, xorg.conf, and the kernel log when I try to boot up Xorg (just Xorg, no gpe anything). Thanks, Eino-Ville Talvala Stanford University dmesg: omapdss OVERLAY: check_overlay 0: (0,0 480x640 - 640x480) disp (480x640) omapdss MANAGER: omap_dss_mgr_apply(lcd) omapdss OVERLAY: check_overlay 0: (0,0 480x640 - 640x480) disp (480x640) omapdss MANAGER: configure_overlay(0) omapdss DISPC: dispc_setup_plane 0, pa 7100, sw 2048, 0,0, 480x640 - 640x48 0, ilace 0, cmode 40, rot 1, mir 0 omapdss MANAGER error: dispc_setup_plane failed for ovl 0 omapdss DISPC: dispc_enable_plane 0, 0 omapdss MANAGER error: configure_overlay 0 failed omapdss DISPC: GO LCD omapdss MANAGER: omap_dss_mgr_apply(lcd) _XSERVTransSocketOpenCOTSServer: Unable to open socket for inet6 _XSERVTransOpen: transport open failed for inet6/omap3evm:0 _XSERVTransMakeAllCOTSServerListeners: failed to open listener for inet6 (WW) Failed to open protocol names file /usr/lib/xorg/protocol.txt X.Org X Server 1.6.1 Release Date: 2009-4-14 X Protocol Version 11, Revision 0 Build Operating System: Linux 2.6.24-24-generic i686 Current Operating System: Linux omap3evm 2.6.32-rc7-07318-g8979e82 #320 Wed Nov 25 15:02:04 PST 2009 armv7l Build Date: 02 December 2009 02:23:08AM Before reporting problems, check
Re: [PATCH] power_supply: Add driver for TWL4030/TPS65950 BCI charger
On Wed, Dec 2, 2009 at 7:33 PM, Felipe Balbi felipe.ba...@nokia.com wrote:
Hi,
On Fri, Nov 27, 2009 at 03:44:20PM +0100, ext Grazvydas Ignotas wrote:
diff --git a/drivers/power/Makefile b/drivers/power/Makefile
index b96f29d..9cea9b5 100644
--- a/drivers/power/Makefile
+++ b/drivers/power/Makefile
@@ -29,3 +29,4 @@ obj-$(CONFIG_BATTERY_BQ27x00) += bq27x00_battery.o
obj-$(CONFIG_BATTERY_DA9030) += da9030_battery.o
obj-$(CONFIG_BATTERY_MAX17040) += max17040_battery.o
obj-$(CONFIG_CHARGER_PCF50633) += pcf50633-charger.o
+obj-$(CONFIG_CHARGER_TWL4030) += twl4030_charger.o
diff --git a/drivers/power/twl4030_charger.c
b/drivers/power/twl4030_charger.c
new file mode 100644
index 000..604dd56
--- /dev/null
+++ b/drivers/power/twl4030_charger.c
@@ -0,0 +1,499 @@
+/*
+ * TWL4030/TPS65950 BCI (Battery Charger Interface) driver
+ *
+ * Copyright (C) 2009 Gražvydas Ignotas nota...@gmail.com
+ *
+ * based on twl4030_bci_battery.c by TI
+ * Copyright (C) 2008 Texas Instruments, Inc.
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ */
+
+#include linux/init.h
+#include linux/module.h
+#include linux/platform_device.h
+#include linux/interrupt.h
+#include linux/i2c/twl4030.h
+#include linux/power_supply.h
+
+#define REG_BCIMSTATEC 0x02
please prepend these defines with e.g. TWL4030_BCI_
this would look like:
#define TWL4030_BCI_MSTATEC 0x02
ok
snip
+
+#define BCI_DELAY 100
100ms ??? that's too quick for battery monitoring. Imagine that you'll have
10 i2c transfers per-second forever with this one. Don't you think you're
waking up omap for nothing ??
The work item doesn't queue itself, so this is only used once after
every interrupt. The delay itself is needed because charge state
machine needs some time to switch states and is not yet in expected
state at the time VBUS/AC detect interrupt kicks.
something like 1 second when doing heavy operation should be enough and 5 to
10 seconds in idle is good enough as well.
+static struct twl4030_bci_device_info twl4030_bci = {
this should be allocated on probe() time.
I need to access it from twl4030charger_usb_en().. Could only leave
delayed_work global and allocate everything else in probe() if you
prefer that.
+/*
+ * called by TWL4030 USB transceiver driver on USB_PRES interrupt.
+ */
+int twl4030charger_usb_en(int enable)
+{
+ if (twl4030_bci.started)
+ schedule_delayed_work(twl4030_bci.bat_work,
+ msecs_to_jiffies(BCI_DELAY));
I don't like the way you did this. I would expect twl4030-usb to kick the
charger detection based on the VBUS irq. You have to consider the
possibility of boards which won't use BCI module and will have some bq24xxx
chip dealing with that like RX51. So instead of implementing this here and
forcing people to have this driver enabled on e.g. RX51, you should
implement the charger_enable_usb() logic in twl4030-usb itself. /me thinks
I don't think charging is twl4030-usb's business, also notifying
power_supply core about charge state changes that I do here.
What about just returning early from twl4030charger_usb_en() if this
driver is not started? TWL4030-core requires twl4030_bci_platform_data
to be present to even register this driver, so it won't start on RX51.
RX51 can also choose not to compile this driver in, then
twl4030charger_usb_en() call won't even be done fom twl4030-usb.
+static int __devinit twl4030_bci_probe(struct platform_device *pdev)
+{
+ int irq;
+ int ret;
+
+ twl4030_charger_enable_ac(true);
+ twl4030_charger_enable_usb(true);
+
+ irq = platform_get_irq(pdev, 0);
+
+ /* CHG_PRES irq */
+ ret = request_irq(irq, twl4030_charger_interrupt,
+ 0, pdev-name, twl4030_bci);
how about using request_threaded_irq() ?? then you avoid having that
workqueue.
I need to do some delayed processing after VBUS/AC detect interrupts
kick, delayed_work looked perfect for this. Also note that I can't get
USB_PRES interrupt (taken by twl4030-usb), only a callback from
twl4030-usb.
--
balbi
--
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] power_supply: Add driver for TWL4030/TPS65950 BCI charger
On Mon, Nov 30, 2009 at 8:58 PM, Anton Vorontsov
avoront...@ru.mvista.com wrote:
On Mon, Nov 30, 2009 at 12:45:20PM -0600, Madhusudhan wrote:
[...]
+ case POWER_SUPPLY_PROP_VOLTAGE_NOW:
+ /* charging must be active for meaningful result */
+ if (!is_charging) {
How about putting a kern_info here?
It might be better to return -EINVAL.
That causes lots of warnings from power_supply core (driver failed to
report XXX property), Not sure what to do here, I'd prefer to keep
returning 0.
Thanks!
--
Anton Vorontsov
email: cbouatmai...@gmail.com
irc://irc.freenode.net/bd2
--
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] power_supply: Add driver for TWL4030/TPS65950 BCI charger
Hi,
On Wed, Dec 02, 2009 at 09:34:00PM +0100, ext Grazvydas Ignotas wrote:
+#define BCI_DELAY 100
100ms ??? that's too quick for battery monitoring. Imagine that you'll have
10 i2c transfers per-second forever with this one. Don't you think you're
waking up omap for nothing ??
The work item doesn't queue itself, so this is only used once after
every interrupt. The delay itself is needed because charge state
machine needs some time to switch states and is not yet in expected
state at the time VBUS/AC detect interrupt kicks.
ok got it... not so bad then ;-)
+static struct twl4030_bci_device_info twl4030_bci = {
this should be allocated on probe() time.
I need to access it from twl4030charger_usb_en().. Could only leave
delayed_work global and allocate everything else in probe() if you
prefer that.
well, you could keep only a global static pointer and after allocating
that in probe, make the global static pointer, point to it... Anyways,
I think twl4030charger_usb_en() should change its prototype to something
like
twl4030charger_usb_en(struct twl4030_bci *bci, int enable);
you could leave userland to decide whether to start charging, specially
in usb charging case where we still need to know if we where enumerated
with 100mA or 500mA configuration. How are you differing between those
currently ?
I don't like the way you did this. I would expect twl4030-usb to kick the
charger detection based on the VBUS irq. You have to consider the
possibility of boards which won't use BCI module and will have some bq24xxx
chip dealing with that like RX51. So instead of implementing this here and
forcing people to have this driver enabled on e.g. RX51, you should
implement the charger_enable_usb() logic in twl4030-usb itself. /me thinks
I don't think charging is twl4030-usb's business, also notifying
power_supply core about charge state changes that I do here.
I was talking about the charger detection. The start of charge you could
leave to userland to handle, no ?
What about just returning early from twl4030charger_usb_en() if this
driver is not started? TWL4030-core requires twl4030_bci_platform_data
to be present to even register this driver, so it won't start on RX51.
RX51 can also choose not to compile this driver in, then
twl4030charger_usb_en() call won't even be done fom twl4030-usb.
still we need to detect the charger...
how about using request_threaded_irq() ?? then you avoid having that
workqueue.
I need to do some delayed processing after VBUS/AC detect interrupts
kick, delayed_work looked perfect for this. Also note that I can't get
USB_PRES interrupt (taken by twl4030-usb), only a callback from
twl4030-usb.
or you let userland to handle a bit more of this logic (??)
--
balbi
--
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: Problems using DSS2 on OMAP3 EVM / Angstrom with rotation
Op 2 dec 2009, om 21:02 heeft Eino-Ville Talvala het volgende geschreven: snip The xorg boot log appears reasonably sane until a crash - 640x480 is what the xf86 omapfb driver picks up, so I assume something else is the problem. I'll try to poke at the omapfb source some to see if something is being passed around wrong - I'd appreciate any suggestions on where to look. === ... (II) LoadModule: omapfb (II) Loading /usr/lib/xorg/modules/drivers//omapfb_drv.so (II) Module omapfb: vendor=X.Org Foundation compiled for 1.6.1, module version = 0.1.1 ABI class: X.Org Video Driver, version 5.0 (II) omapfb: Driver for OMAP framebuffer (omapfb) and external LCD controllers: omap1/2/3, S1D13745, HWA742 (WW) Falling back to old probe method for OMAPFB (II) Running in FRAMEBUFFER Mode (WW) Error opening /sys/devices/platform/omapfb/ctrl/name: No such file or direc tory (WW) Can't autodetect LCD controller, assuming internal (II) LCD controller: internal (II) omapfb(0): VideoRAM: 1920KiB (SDRAM) (--) omapfb(0): Depth 16, (==) framebuffer bpp 16 (==) omapfb(0): RGB weight 565 (==) omapfb(0): Default visual is TrueColor (--) omapfb(0): Virtual size is 640x480 (pitch 640) (**) omapfb(0): Built-in mode current (==) omapfb(0): DPI set to (96, 96) (II) Loading sub module fb (II) LoadModule: fb (II) Loading /usr/lib/xorg/modules//libfb.so (II) Module fb: vendor=X.Org Foundation compiled for 1.6.1, module version = 1.0.0 ABI class: X.Org ANSI C Emulation, version 0.4 (II) omapfb(0): DPMS enabled (II) omapfb(0): Video plane capabilities: (II) omapfb(0): Video plane supports the following image formats: (II) omapfb(0): XVideo extension initialized (==) RandR enabled (II) Initializing built-in extension Generic Event Extension (II) Initializing built-in extension SHAPE (II) Initializing built-in extension MIT-SHM (II) Initializing built-in extension XInputExtension (II) Initializing built-in extension XTEST (II) Initializing built-in extension BIG-REQUESTS (II) Initializing built-in extension SYNC (II) Initializing built-in extension XKEYBOARD (II) Initializing built-in extension XC-MISC (II) Initializing built-in extension XINERAMA (II) Initializing built-in extension XFIXES (II) Initializing built-in extension RENDER (II) Initializing built-in extension RANDR (II) Initializing built-in extension COMPOSITE (II) Initializing built-in extension DAMAGE Backtrace: 0: Xorg(xorg_backtrace+0x28) [0xd2540] Fatal server error: Caught signal 11. Server aborting === Does your xorg.conf enable GLX? You may want to try disabling it. ~sanjeev Thanks for all the suggestions, but nothing seems to have worked so far. It looks like X picks up all sorts of configuration settings automatically, since xorg.conf is essentially full of 'default internal device' options. What I can't figure out is how it decides on the requested resolution. The defaults, with omapfb.rotate=1 in bootargs, result in omapfb selecting a virtual resolution of 640x480, but Xorg on boot still tries, based on dmesg, to get a 480x640 overlay somehow (at least that's what my interpretation of the situation is). I've tried adding a screen subsection to xorg.confg, with virtual 640 480 - no effect. I've tried adding in a modeline for 640x480, no effect. I tried rebuilding Angstrom with a few extra lines in /conf/machine/omap3evm.conf (MACHINE_DISPLAY_WIDTH_PIXELS=640, etc), with no effect. Does anyone know exactly how Xorg autoconfigures the default panel in this sort of a situation? My current guess is that it's getting 480x640 from some panel driver somewhere, but I haven't been able to find the source. For compleness, I've attached the Xorg log, xorg.conf, and the kernel log when I try to boot up Xorg (just Xorg, no gpe anything). check the settings for fb0, fb1 and fb2 with fbset. regards, Koen -- 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] power_supply: Add driver for TWL4030/TPS65950 BCI charger
On Wed, Dec 02, 2009 at 10:38:31PM +0200, Grazvydas Ignotas wrote:
On Mon, Nov 30, 2009 at 8:58 PM, Anton Vorontsov
avoront...@ru.mvista.com wrote:
On Mon, Nov 30, 2009 at 12:45:20PM -0600, Madhusudhan wrote:
[...]
+ case POWER_SUPPLY_PROP_VOLTAGE_NOW:
+ /* charging must be active for meaningful result */
+ if (!is_charging) {
How about putting a kern_info here?
It might be better to return -EINVAL.
That causes lots of warnings from power_supply core (driver failed to
report XXX property), Not sure what to do here, I'd prefer to keep
returning 0.
Lying to userspace is a bad idea.
How about this patch + changing the driver to return -ENODATA?
From 0fe4c834b551c4d4454d57acaf75645675d199ee Mon Sep 17 00:00:00 2001
From: Anton Vorontsov avoront...@ru.mvista.com
Date: Thu, 3 Dec 2009 00:24:51 +0300
Subject: [PATCH] power_supply_sysfs: Handle -ENODATA in a special way
There are cases when some device can not report any meaningful value,
e.g. TWL4030 charger can report voltage only when charging is
active.
In these cases drivers will return -ENODATA, and we shouldn't flood
kernel log with error messages.
Signed-off-by: Anton Vorontsov avoront...@ru.mvista.com
---
drivers/power/power_supply_sysfs.c |5 -
1 files changed, 4 insertions(+), 1 deletions(-)
diff --git a/drivers/power/power_supply_sysfs.c
b/drivers/power/power_supply_sysfs.c
index 0814439..c790e0c 100644
--- a/drivers/power/power_supply_sysfs.c
+++ b/drivers/power/power_supply_sysfs.c
@@ -65,7 +65,10 @@ static ssize_t power_supply_show_property(struct device *dev,
ret = psy-get_property(psy, off, value);
if (ret 0) {
- if (ret != -ENODEV)
+ if (ret == -ENODATA)
+ dev_dbg(dev, driver has no data for `%s' property\n,
+ attr-attr.name);
+ else if (ret != -ENODEV)
dev_err(dev, driver failed to report `%s' property\n,
attr-attr.name);
return ret;
--
1.6.3.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] power_supply: Add driver for TWL4030/TPS65950 BCI charger
On Wed, Dec 2, 2009 at 10:49 PM, Felipe Balbi felipe.ba...@nokia.com wrote:
Hi,
On Wed, Dec 02, 2009 at 09:34:00PM +0100, ext Grazvydas Ignotas wrote:
+#define BCI_DELAY 100
100ms ??? that's too quick for battery monitoring. Imagine that you'll
have
10 i2c transfers per-second forever with this one. Don't you think you're
waking up omap for nothing ??
The work item doesn't queue itself, so this is only used once after
every interrupt. The delay itself is needed because charge state
machine needs some time to switch states and is not yet in expected
state at the time VBUS/AC detect interrupt kicks.
ok got it... not so bad then ;-)
+static struct twl4030_bci_device_info twl4030_bci = {
this should be allocated on probe() time.
I need to access it from twl4030charger_usb_en().. Could only leave
delayed_work global and allocate everything else in probe() if you
prefer that.
well, you could keep only a global static pointer and after allocating that
in probe, make the global static pointer, point to it... Anyways, I think
twl4030charger_usb_en() should change its prototype to something like
twl4030charger_usb_en(struct twl4030_bci *bci, int enable);
This function is called by twl4030-usb, where will it get this bci pointer from?
you could leave userland to decide whether to start charging, specially in
usb charging case where we still need to know if we where enumerated with
100mA or 500mA configuration.
From what I saw in other drivers they are setup to start charging
automatically as soon as they see VBUS. Maybe Anton can give more
details here.
How are you differing between those currently?
Not handled at all at the moment (uses BCI defaults).
I don't like the way you did this. I would expect twl4030-usb to kick the
charger detection based on the VBUS irq. You have to consider the
possibility of boards which won't use BCI module and will have some
bq24xxx
chip dealing with that like RX51. So instead of implementing this here
and
forcing people to have this driver enabled on e.g. RX51, you should
implement the charger_enable_usb() logic in twl4030-usb itself. /me
thinks
I don't think charging is twl4030-usb's business, also notifying
power_supply core about charge state changes that I do here.
I was talking about the charger detection.
The USB_PRES interrupt belongs to twl4030-usb, so it gets it's
detection as before and does not need this driver, where is the
problem? This driver only registers CHG_PRES, which is AC charger
detect interrupt.
The start of charge you could leave to userland to handle, no ?
Maybe, I wonder if there is standard way to do that.
Anton?
What about just returning early from twl4030charger_usb_en() if this
driver is not started? TWL4030-core requires twl4030_bci_platform_data
to be present to even register this driver, so it won't start on RX51.
RX51 can also choose not to compile this driver in, then
twl4030charger_usb_en() call won't even be done fom twl4030-usb.
still we need to detect the charger...
how about using request_threaded_irq() ?? then you avoid having that
workqueue.
I need to do some delayed processing after VBUS/AC detect interrupts
kick, delayed_work looked perfect for this. Also note that I can't get
USB_PRES interrupt (taken by twl4030-usb), only a callback from
twl4030-usb.
or you let userland to handle a bit more of this logic (??)
Still need to autostart AC charging, who would plug AC adapter and
want to fiddle with the GUI to start charging instead it having it go
automatically? Agree about USB userspace switch though..
--
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] power_supply: Add driver for TWL4030/TPS65950 BCI charger
On Wed, Dec 2, 2009 at 11:27 PM, Anton Vorontsov
avoront...@ru.mvista.com wrote:
On Wed, Dec 02, 2009 at 10:38:31PM +0200, Grazvydas Ignotas wrote:
On Mon, Nov 30, 2009 at 8:58 PM, Anton Vorontsov
avoront...@ru.mvista.com wrote:
On Mon, Nov 30, 2009 at 12:45:20PM -0600, Madhusudhan wrote:
[...]
+ case POWER_SUPPLY_PROP_VOLTAGE_NOW:
+ /* charging must be active for meaningful result */
+ if (!is_charging) {
How about putting a kern_info here?
It might be better to return -EINVAL.
That causes lots of warnings from power_supply core (driver failed to
report XXX property), Not sure what to do here, I'd prefer to keep
returning 0.
Lying to userspace is a bad idea.
How about this patch + changing the driver to return -ENODATA?
This is fine for me, thanks.
From 0fe4c834b551c4d4454d57acaf75645675d199ee Mon Sep 17 00:00:00 2001
From: Anton Vorontsov avoront...@ru.mvista.com
Date: Thu, 3 Dec 2009 00:24:51 +0300
Subject: [PATCH] power_supply_sysfs: Handle -ENODATA in a special way
There are cases when some device can not report any meaningful value,
e.g. TWL4030 charger can report voltage only when charging is
active.
In these cases drivers will return -ENODATA, and we shouldn't flood
kernel log with error messages.
Signed-off-by: Anton Vorontsov avoront...@ru.mvista.com
---
drivers/power/power_supply_sysfs.c | 5 -
1 files changed, 4 insertions(+), 1 deletions(-)
diff --git a/drivers/power/power_supply_sysfs.c
b/drivers/power/power_supply_sysfs.c
index 0814439..c790e0c 100644
--- a/drivers/power/power_supply_sysfs.c
+++ b/drivers/power/power_supply_sysfs.c
@@ -65,7 +65,10 @@ static ssize_t power_supply_show_property(struct device
*dev,
ret = psy-get_property(psy, off, value);
if (ret 0) {
- if (ret != -ENODEV)
+ if (ret == -ENODATA)
+ dev_dbg(dev, driver has no data for `%s' property\n,
+ attr-attr.name);
+ else if (ret != -ENODEV)
dev_err(dev, driver failed to report `%s' property\n,
attr-attr.name);
return ret;
--
1.6.3.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] power_supply: Add driver for TWL4030/TPS65950 BCI charger
On Wed, Dec 02, 2009 at 11:29:10PM +0200, Grazvydas Ignotas wrote: [...] From what I saw in other drivers they are setup to start charging automatically as soon as they see VBUS. Yes. I see nothing wrong here. How are you differing between those currently? Not handled at all at the moment (uses BCI defaults). [...] Agree about USB userspace switch though.. Yes, so far we don't have any writable properties in power supply class, though the feature is in demand by various drivers. Somebody should step up and implement it. ;-) But for the start, I like this driver the way it is. As for the default USB VBUS current value, it could be Kconfig option (something alike to USB_GADGET_VBUS_DRAW) and/or module parameter, or hw default, or hardcoded for now. Either will work. -- Anton Vorontsov email: cbouatmai...@gmail.com irc://irc.freenode.net/bd2 -- 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: Problems using DSS2 on OMAP3 EVM / Angstrom with rotation
On 12/2/2009 12:52 PM, Koen Kooi wrote: Op 2 dec 2009, om 21:02 heeft Eino-Ville Talvala het volgende geschreven: snip The xorg boot log appears reasonably sane until a crash - 640x480 is what the xf86 omapfb driver picks up, so I assume something else is the problem. I'll try to poke at the omapfb source some to see if something is being passed around wrong - I'd appreciate any suggestions on where to look. === ... (II) LoadModule: omapfb (II) Loading /usr/lib/xorg/modules/drivers//omapfb_drv.so (II) Module omapfb: vendor=X.Org Foundation compiled for 1.6.1, module version = 0.1.1 ABI class: X.Org Video Driver, version 5.0 (II) omapfb: Driver for OMAP framebuffer (omapfb) and external LCD controllers: omap1/2/3, S1D13745, HWA742 (WW) Falling back to old probe method for OMAPFB (II) Running in FRAMEBUFFER Mode (WW) Error opening /sys/devices/platform/omapfb/ctrl/name: No such file or direc tory (WW) Can't autodetect LCD controller, assuming internal (II) LCD controller: internal (II) omapfb(0): VideoRAM: 1920KiB (SDRAM) (--) omapfb(0): Depth 16, (==) framebuffer bpp 16 (==) omapfb(0): RGB weight 565 (==) omapfb(0): Default visual is TrueColor (--) omapfb(0): Virtual size is 640x480 (pitch 640) (**) omapfb(0): Built-in mode current (==) omapfb(0): DPI set to (96, 96) (II) Loading sub module fb (II) LoadModule: fb (II) Loading /usr/lib/xorg/modules//libfb.so (II) Module fb: vendor=X.Org Foundation compiled for 1.6.1, module version = 1.0.0 ABI class: X.Org ANSI C Emulation, version 0.4 (II) omapfb(0): DPMS enabled (II) omapfb(0): Video plane capabilities: (II) omapfb(0): Video plane supports the following image formats: (II) omapfb(0): XVideo extension initialized (==) RandR enabled (II) Initializing built-in extension Generic Event Extension (II) Initializing built-in extension SHAPE (II) Initializing built-in extension MIT-SHM (II) Initializing built-in extension XInputExtension (II) Initializing built-in extension XTEST (II) Initializing built-in extension BIG-REQUESTS (II) Initializing built-in extension SYNC (II) Initializing built-in extension XKEYBOARD (II) Initializing built-in extension XC-MISC (II) Initializing built-in extension XINERAMA (II) Initializing built-in extension XFIXES (II) Initializing built-in extension RENDER (II) Initializing built-in extension RANDR (II) Initializing built-in extension COMPOSITE (II) Initializing built-in extension DAMAGE Backtrace: 0: Xorg(xorg_backtrace+0x28) [0xd2540] Fatal server error: Caught signal 11. Server aborting === Does your xorg.conf enable GLX? You may want to try disabling it. ~sanjeev Thanks for all the suggestions, but nothing seems to have worked so far. It looks like X picks up all sorts of configuration settings automatically, since xorg.conf is essentially full of 'default internal device' options. What I can't figure out is how it decides on the requested resolution. The defaults, with omapfb.rotate=1 in bootargs, result in omapfb selecting a virtual resolution of 640x480, but Xorg on boot still tries, based on dmesg, to get a 480x640 overlay somehow (at least that's what my interpretation of the situation is). I've tried adding a screen subsection to xorg.confg, with virtual 640 480 - no effect. I've tried adding in a modeline for 640x480, no effect. I tried rebuilding Angstrom with a few extra lines in /conf/machine/omap3evm.conf (MACHINE_DISPLAY_WIDTH_PIXELS=640, etc), with no effect. Does anyone know exactly how Xorg autoconfigures the default panel in this sort of a situation? My current guess is that it's getting 480x640 from some panel driver somewhere, but I haven't been able to find the source. For compleness, I've attached the Xorg log, xorg.conf, and the kernel log when I try to boot up Xorg (just Xorg, no gpe anything). check the settings for fb0, fb1 and fb2 with fbset. regards, Koen r...@omap3evm:~# fbset -fb /dev/fb0 mode 640x480-59 # D: 19.200 MHz, H: 28.614 kHz, V: 59.243 Hz geometry 640 480 640 480 16 timings 52083 1 28 1 1 2 1 accel false rgba 5/11,6/5,5/0,0/0 endmode r...@omap3evm:~# fbset -fb /dev/fb1 mode 640x480-59 # D: 19.200 MHz, H: 28.614 kHz, V: 59.243 Hz geometry 640 480 640 480 16 timings 52083 1 28 1 1 2 1 accel false rgba 5/11,6/5,5/0,0/0 endmode r...@omap3evm:~# fbset -fb /dev/fb2 mode 0x0-0 # D: 0.000 MHz, H: 0.000 kHz, V: 0.000 Hz geometry 0 0 0 0 0 timings 0 0 0 0 0 0 0 accel false rgba 0/0,0/0,0/0,0/0 endmode FB2 is suspicious, since that's what Xorg uses, I believe. Attempting to set it to something like fb0 and fb1 with: fbset -fb /dev/fb2 -g 640 480 640 480 16 -t 52083 1 28 1 1 2 1 made no difference to Xorg, however. I tried upping the amount of memory allocated to fb2 (I'd forgotten to
[RFT/RFC/PATCH 00/10] several cleanup patches
on the following we have section mismatch fixes, compile fix to board-nokia770.c, compile fix to sossi.c, compile fix to hwa742.c, compile fix to tahvo-usb.c and a few cleanups to cbus driver. It's compile tested only as I don't have 770s or n8x0 with the development jig available right now, so please, if you have any of those boards dusting around, test the following patches. Felipe Balbi (10): arm: omap1: clock: fix section mismatch arm: omap: n770: make it build again video: omap: sossi: make it build again video: omap: hwa742: make it build again cbus: tahvo-usb: make it build again cbus: switch to kzalloc cbus: move EXPORT_SYMBOL close to its exported symbols cbus: separate into several MODULE_AUTHOR entries cbus: move to platform_driver cbus: add platform_data to pass gpios arch/arm/mach-omap1/board-nokia770.c | 18 +++- arch/arm/mach-omap1/clock.c|2 +- arch/arm/mach-omap2/board-n8x0.c | 17 +++ arch/arm/plat-omap/include/plat/cbus.h | 31 + drivers/cbus/cbus.c| 77 ++-- drivers/cbus/tahvo-usb.c | 12 +++--- drivers/video/omap/hwa742.c|1 + drivers/video/omap/sossi.c |1 + 8 files changed, 118 insertions(+), 41 deletions(-) create mode 100644 arch/arm/plat-omap/include/plat/cbus.h -- 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
[RFT/RFC/PATCH 03/10] video: omap: sossi: make it build again
add missing linux/interrupt.h Signed-off-by: Felipe Balbi felipe.ba...@nokia.com --- drivers/video/omap/sossi.c |1 + 1 files changed, 1 insertions(+), 0 deletions(-) diff --git a/drivers/video/omap/sossi.c b/drivers/video/omap/sossi.c index 354cbbb..8fb7c70 100644 --- a/drivers/video/omap/sossi.c +++ b/drivers/video/omap/sossi.c @@ -23,6 +23,7 @@ #include linux/clk.h #include linux/irq.h #include linux/io.h +#include linux/interrupt.h #include plat/dma.h -- 1.6.6.rc0 -- 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
[RFT/RFC/PATCH 02/10] arm: omap: n770: make it build again
there's no plat/omapfb.h it's now under linux/omapfb.h Signed-off-by: Felipe Balbi felipe.ba...@nokia.com --- arch/arm/mach-omap1/board-nokia770.c |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/arch/arm/mach-omap1/board-nokia770.c b/arch/arm/mach-omap1/board-nokia770.c index af4d719..db9a1de 100644 --- a/arch/arm/mach-omap1/board-nokia770.c +++ b/arch/arm/mach-omap1/board-nokia770.c @@ -20,6 +20,7 @@ #include linux/spi/ads7846.h #include linux/workqueue.h #include linux/delay.h +#include linux/omapfb.h #include mach/hardware.h #include asm/mach-types.h @@ -33,7 +34,6 @@ #include plat/keypad.h #include plat/common.h #include plat/dsp_common.h -#include plat/omapfb.h #include plat/hwa742.h #include plat/lcd_mipid.h #include plat/mmc.h -- 1.6.6.rc0 -- 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
[RFT/RFC/PATCH 01/10] arm: omap1: clock: fix section mismatch
omap1_clk_functions was only used by
omap1_clk_init() which sits in __init
section, so make omap1_clock_functions
be __initdata to avoid the section mismatch.
Signed-off-by: Felipe Balbi felipe.ba...@nokia.com
---
arch/arm/mach-omap1/clock.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/arch/arm/mach-omap1/clock.c b/arch/arm/mach-omap1/clock.c
index 42cbe20..d28ace2 100644
--- a/arch/arm/mach-omap1/clock.c
+++ b/arch/arm/mach-omap1/clock.c
@@ -744,7 +744,7 @@ static void __init omap1_clk_disable_unused(struct clk *clk)
#define omap1_clk_disable_unused NULL
#endif
-static struct clk_functions omap1_clk_functions = {
+static struct clk_functions omap1_clk_functions __initdata = {
.clk_enable = omap1_clk_enable,
.clk_disable= omap1_clk_disable,
.clk_round_rate = omap1_clk_round_rate,
--
1.6.6.rc0
--
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
[RFT/RFC/PATCH 05/10] cbus: tahvo-usb: make it build again
plenty of legacy code sitting there. Make it build
again. Later patches will come to clean that up.
Signed-off-by: Felipe Balbi felipe.ba...@nokia.com
---
drivers/cbus/tahvo-usb.c | 12 ++--
1 files changed, 6 insertions(+), 6 deletions(-)
diff --git a/drivers/cbus/tahvo-usb.c b/drivers/cbus/tahvo-usb.c
index c08f08d..9f8bbcc 100644
--- a/drivers/cbus/tahvo-usb.c
+++ b/drivers/cbus/tahvo-usb.c
@@ -114,8 +114,8 @@ static struct platform_device *tahvo_otg_dev;
static irqreturn_t omap_otg_irq(int irq, void *arg)
{
- struct platform_device *otg_dev = (struct platform_device *) arg;
- struct tahvo_usb *tu = (struct tahvo_usb *) otg_dev-dev.driver_data;
+ struct platform_device *otg_dev = arg;
+ struct tahvo_usb *tu = platform_get_drvdata(otg_dev);
u16 otg_irq;
otg_irq = omap_readw(OTG_IRQ_SRC);
@@ -227,7 +227,7 @@ struct device_driver omap_otg_driver = {
static ssize_t vbus_state_show(struct device *device,
struct device_attribute *attr, char *buf)
{
- struct tahvo_usb *tu = (struct tahvo_usb*) device-driver_data;
+ struct tahvo_usb *tu = dev_get_drvdata(device);
return sprintf(buf, %d\n, tu-vbus_state);
}
static DEVICE_ATTR(vbus_state, 0444, vbus_state_show, NULL);
@@ -590,7 +590,7 @@ static void tahvo_usb_vbus_interrupt(unsigned long arg)
static ssize_t otg_mode_show(struct device *device,
struct device_attribute *attr, char *buf)
{
- struct tahvo_usb *tu = (struct tahvo_usb*) device-driver_data;
+ struct tahvo_usb *tu = dev_get_drvdata(device);
switch (tu-tahvo_mode) {
case TAHVO_MODE_HOST:
return sprintf(buf, host\n);
@@ -604,7 +604,7 @@ static ssize_t otg_mode_store(struct device *device,
struct device_attribute *attr,
const char *buf, size_t count)
{
- struct tahvo_usb *tu = (struct tahvo_usb*) device-driver_data;
+ struct tahvo_usb *tu = dev_get_drvdata(device);
int r;
r = strlen(buf);
@@ -706,7 +706,7 @@ static int tahvo_usb_probe(struct device *dev)
return ret;
}
- dev-driver_data = tu;
+ dev_set_drvdata(dev, tu);
/* Act upon current vbus state once at startup. A vbus state irq may or
* may not be generated in addition to this. */
--
1.6.6.rc0
--
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
[RFT/RFC/PATCH 04/10] video: omap: hwa742: make it build again
add missing linux/interrupt.h Signed-off-by: Felipe Balbi felipe.ba...@nokia.com --- drivers/video/omap/hwa742.c |1 + 1 files changed, 1 insertions(+), 0 deletions(-) diff --git a/drivers/video/omap/hwa742.c b/drivers/video/omap/hwa742.c index 170d171..0016f77 100644 --- a/drivers/video/omap/hwa742.c +++ b/drivers/video/omap/hwa742.c @@ -25,6 +25,7 @@ #include linux/fb.h #include linux/delay.h #include linux/clk.h +#include linux/interrupt.h #include plat/dma.h #include plat/hwa742.h -- 1.6.6.rc0 -- 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
[RFT/RFC/PATCH 06/10] cbus: switch to kzalloc
change kmalloc() + memset() to kzalloc(), no functional changes. Signed-off-by: Felipe Balbi felipe.ba...@nokia.com --- drivers/cbus/cbus.c |4 +--- 1 files changed, 1 insertions(+), 3 deletions(-) diff --git a/drivers/cbus/cbus.c b/drivers/cbus/cbus.c index c80cede..0bcc211 100644 --- a/drivers/cbus/cbus.c +++ b/drivers/cbus/cbus.c @@ -224,12 +224,10 @@ int __init cbus_bus_init(void) struct cbus_host *chost; int ret; - chost = kmalloc(sizeof (*chost), GFP_KERNEL); + chost = kzalloc(sizeof (*chost), GFP_KERNEL); if (chost == NULL) return -ENOMEM; - memset(chost, 0, sizeof (*chost)); - spin_lock_init(chost-lock); /* REVISIT: Pass these from board-*.c files in platform_data */ -- 1.6.6.rc0 -- 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
[RFT/RFC/PATCH 09/10] cbus: move to platform_driver
also add the platform_device to 770 and n8x0 board files.
Signed-off-by: Felipe Balbi felipe.ba...@nokia.com
---
arch/arm/mach-omap1/board-nokia770.c |6 ++
arch/arm/mach-omap2/board-n8x0.c |7 +++
drivers/cbus/cbus.c | 34 +-
3 files changed, 46 insertions(+), 1 deletions(-)
diff --git a/arch/arm/mach-omap1/board-nokia770.c
b/arch/arm/mach-omap1/board-nokia770.c
index db9a1de..a8debf3 100644
--- a/arch/arm/mach-omap1/board-nokia770.c
+++ b/arch/arm/mach-omap1/board-nokia770.c
@@ -97,8 +97,14 @@ static struct platform_device nokia770_kp_device = {
.resource = nokia770_kp_resources,
};
+static struct platform_device nokia770_cbus_device = {
+ .name = cbus,
+ .id = -1,
+};
+
static struct platform_device *nokia770_devices[] __initdata = {
nokia770_kp_device,
+ nokia770_cbus_device,
};
static void mipid_shutdown(struct mipid_platform_data *pdata)
diff --git a/arch/arm/mach-omap2/board-n8x0.c b/arch/arm/mach-omap2/board-n8x0.c
index 764ab1e..22eda61 100644
--- a/arch/arm/mach-omap2/board-n8x0.c
+++ b/arch/arm/mach-omap2/board-n8x0.c
@@ -77,6 +77,11 @@ static struct mtd_partition onenand_partitions[] = {
},
};
+static struct platform_device n8x0_cbus_device = {
+ .name = cbus,
+ .id = -1,
+};
+
static struct omap_onenand_platform_data board_onenand_data = {
.cs = 0,
.gpio_irq = 26,
@@ -111,6 +116,8 @@ static void __init n8x0_init_irq(void)
static void __init n8x0_init_machine(void)
{
+ platform_device_register(n8x0_cbus_device);
+
/* FIXME: add n810 spi devices */
spi_register_board_info(n800_spi_board_info,
ARRAY_SIZE(n800_spi_board_info));
diff --git a/drivers/cbus/cbus.c b/drivers/cbus/cbus.c
index 145e760..a35941e 100644
--- a/drivers/cbus/cbus.c
+++ b/drivers/cbus/cbus.c
@@ -29,6 +29,7 @@
#include linux/delay.h
#include linux/spinlock.h
#include linux/gpio.h
+#include linux/platform_device.h
#include asm/io.h
#include asm/mach-types.h
@@ -222,7 +223,7 @@ int cbus_write_reg(struct cbus_host *host, int dev, int
reg, u16 val)
}
EXPORT_SYMBOL(cbus_write_reg);
-static int __init cbus_bus_init(void)
+static int __init cbus_bus_probe(struct platform_device *pdev)
{
struct cbus_host *chost;
int ret;
@@ -275,6 +276,8 @@ static int __init cbus_bus_init(void)
gpio_set_value(chost-clk_gpio, 1);
gpio_set_value(chost-clk_gpio, 0);
+ platform_set_drvdata(pdev, chost);
+
cbus_host = chost;
return 0;
@@ -284,13 +287,42 @@ exit2:
gpio_free(chost-clk_gpio);
exit1:
kfree(chost);
+
return ret;
}
+static void __exit cbus_bus_remove(struct platform_device *pdev)
+{
+ struct cbus_host*chost = platform_get_drvdata(pdev);
+
+ gpio_free(chost-dat_gpio);
+ gpio_free(chost-clk_gpio);
+ kfree(chost);
+}
+
+static struct platform_driver cbus_driver = {
+ .remove = __exit_p(cbus_bus_remove),
+ .driver = {
+ .name = cbus,
+ },
+};
+
+static int __init cbus_bus_init(void)
+{
+ return platform_driver_probe(cbus_driver, cbus_bus_probe);
+}
+
subsys_initcall(cbus_bus_init);
+static void __exit cbus_bus_exit(void)
+{
+ platform_driver_unregister(cbus_driver);
+}
+module_exit(cbus_bus_exit);
+
MODULE_DESCRIPTION(CBUS serial protocol);
MODULE_LICENSE(GPL);
MODULE_AUTHOR(Juha Yrjölä);
MODULE_AUTHOR(David Weinehall);
MODULE_AUTHOR(Mikko Ylinen);
+
--
1.6.6.rc0
--
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
[RFT/RFC/PATCH 07/10] cbus: move EXPORT_SYMBOL close to its exported symbols
while there, also add a missing static to cbus_bus_init().
Signed-off-by: Felipe Balbi felipe.ba...@nokia.com
---
drivers/cbus/cbus.c |9 -
1 files changed, 4 insertions(+), 5 deletions(-)
diff --git a/drivers/cbus/cbus.c b/drivers/cbus/cbus.c
index 0bcc211..d73d0c9 100644
--- a/drivers/cbus/cbus.c
+++ b/drivers/cbus/cbus.c
@@ -38,6 +38,7 @@
#include cbus.h
struct cbus_host *cbus_host = NULL;
+EXPORT_SYMBOL(cbus_host);
#ifdef CONFIG_ARCH_OMAP1
/* We use our own MPUIO functions to get closer to 1MHz bus speed */
@@ -210,6 +211,7 @@ int cbus_read_reg(struct cbus_host *host, int dev, int reg)
{
return cbus_host ? cbus_transfer(host, dev, reg, -1) : -ENODEV;
}
+EXPORT_SYMBOL(cbus_read_reg);
/*
* Write to a given register of the device
@@ -218,8 +220,9 @@ int cbus_write_reg(struct cbus_host *host, int dev, int
reg, u16 val)
{
return cbus_host ? cbus_transfer(host, dev, reg, (int)val) : -ENODEV;
}
+EXPORT_SYMBOL(cbus_write_reg);
-int __init cbus_bus_init(void)
+static int __init cbus_bus_init(void)
{
struct cbus_host *chost;
int ret;
@@ -286,10 +289,6 @@ exit1:
subsys_initcall(cbus_bus_init);
-EXPORT_SYMBOL(cbus_host);
-EXPORT_SYMBOL(cbus_read_reg);
-EXPORT_SYMBOL(cbus_write_reg);
-
MODULE_DESCRIPTION(CBUS serial protocol);
MODULE_LICENSE(GPL);
MODULE_AUTHOR(Juha Yrjölä, David Weinehall, and Mikko Ylinen);
--
1.6.6.rc0
--
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
[RFT/RFC/PATCH 10/10] cbus: add platform_data to pass gpios
also add the platform_data to the related
board files.
Signed-off-by: Felipe Balbi felipe.ba...@nokia.com
---
arch/arm/mach-omap1/board-nokia770.c | 10 ++
arch/arm/mach-omap2/board-n8x0.c | 10 ++
arch/arm/plat-omap/include/plat/cbus.h | 31 +++
drivers/cbus/cbus.c| 30 +-
4 files changed, 56 insertions(+), 25 deletions(-)
create mode 100644 arch/arm/plat-omap/include/plat/cbus.h
diff --git a/arch/arm/mach-omap1/board-nokia770.c
b/arch/arm/mach-omap1/board-nokia770.c
index a8debf3..95a3a82 100644
--- a/arch/arm/mach-omap1/board-nokia770.c
+++ b/arch/arm/mach-omap1/board-nokia770.c
@@ -38,6 +38,7 @@
#include plat/lcd_mipid.h
#include plat/mmc.h
#include plat/clock.h
+#include plat/cbus.h
#define ADS7846_PENDOWN_GPIO 15
@@ -97,9 +98,18 @@ static struct platform_device nokia770_kp_device = {
.resource = nokia770_kp_resources,
};
+static struct cbus_host_platform_data nokia770_cbus_data = {
+ .clk_gpio = OMAP_MPUIO(11),
+ .dat_gpio = OMAP_MPUIO(10),
+ .sel_gpio = OMAP_MPUIO(9),
+};
+
static struct platform_device nokia770_cbus_device = {
.name = cbus,
.id = -1,
+ .dev= {
+ .platform_data = nokia770_cbus_data,
+ },
};
static struct platform_device *nokia770_devices[] __initdata = {
diff --git a/arch/arm/mach-omap2/board-n8x0.c b/arch/arm/mach-omap2/board-n8x0.c
index 22eda61..e8198b5 100644
--- a/arch/arm/mach-omap2/board-n8x0.c
+++ b/arch/arm/mach-omap2/board-n8x0.c
@@ -29,6 +29,7 @@
#include plat/mcspi.h
#include plat/onenand.h
#include plat/serial.h
+#include plat/cbus.h
static struct omap2_mcspi_device_config p54spi_mcspi_config = {
.turbo_mode = 0,
@@ -77,9 +78,18 @@ static struct mtd_partition onenand_partitions[] = {
},
};
+static struct cbus_host_platform_data n8x0_cbus_data = {
+ .clk_gpio = 66,
+ .dat_gpio = 65,
+ .sel_gpio = 64,
+};
+
static struct platform_device n8x0_cbus_device = {
.name = cbus,
.id = -1,
+ .dev= {
+ .platform_data = n8x0_cbus_data,
+ },
};
static struct omap_onenand_platform_data board_onenand_data = {
diff --git a/arch/arm/plat-omap/include/plat/cbus.h
b/arch/arm/plat-omap/include/plat/cbus.h
new file mode 100644
index 000..d938e23
--- /dev/null
+++ b/arch/arm/plat-omap/include/plat/cbus.h
@@ -0,0 +1,31 @@
+/*
+ * cbus.h - CBUS platform_data definition
+ *
+ * Copyright (C) 2004 - 2009 Nokia Corporation
+ *
+ * Written by Felipe Balbi felipe.ba...@nokia.com
+ *
+ * This file is subject to the terms and conditions of the GNU General
+ * Public License. See the file COPYING in the main directory of this
+ * archive for more details.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, write to the Free Software
+ * Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA
+ */
+
+#ifndef __PLAT_CBUS_H
+#define __PLAT_CBUS_H
+
+struct cbus_host_platform_data {
+ int dat_gpio;
+ int clk_gpio;
+ int sel_gpio;
+};
+
+#endif /* __PLAT_CBUS_H */
diff --git a/drivers/cbus/cbus.c b/drivers/cbus/cbus.c
index a35941e..00c3c32 100644
--- a/drivers/cbus/cbus.c
+++ b/drivers/cbus/cbus.c
@@ -35,6 +35,7 @@
#include asm/mach-types.h
#include plat/board.h
+#include plat/cbus.h
#include cbus.h
@@ -226,6 +227,7 @@ EXPORT_SYMBOL(cbus_write_reg);
static int __init cbus_bus_probe(struct platform_device *pdev)
{
struct cbus_host *chost;
+ struct cbus_host_platform_data *pdata = pdev-dev.platform_data;
int ret;
chost = kzalloc(sizeof (*chost), GFP_KERNEL);
@@ -234,31 +236,9 @@ static int __init cbus_bus_probe(struct platform_device
*pdev)
spin_lock_init(chost-lock);
- /* REVISIT: Pass these from board-*.c files in platform_data */
- if (machine_is_nokia770()) {
- chost-clk_gpio = OMAP_MPUIO(11);
- chost-dat_gpio = OMAP_MPUIO(10);
- chost-sel_gpio = OMAP_MPUIO(9);
- } else if (machine_is_nokia_n800() || machine_is_nokia_n810() ||
- machine_is_nokia_n810_wimax()) {
- chost-clk_gpio = 66;
- chost-dat_gpio = 65;
- chost-sel_gpio = 64;
- } else {
- printk(KERN_ERR cbus: Unsupported board\n);
- ret = -ENODEV;
- goto exit1;
- }
-
-#ifdef CONFIG_ARCH_OMAP1
- if (!OMAP_GPIO_IS_MPUIO(chost-clk_gpio) ||
-
[RFT/RFC/PATCH 08/10] cbus: separate into several MODULE_AUTHOR entries
will look cleaner on modinfo. Signed-off-by: Felipe Balbi felipe.ba...@nokia.com --- drivers/cbus/cbus.c |4 +++- 1 files changed, 3 insertions(+), 1 deletions(-) diff --git a/drivers/cbus/cbus.c b/drivers/cbus/cbus.c index d73d0c9..145e760 100644 --- a/drivers/cbus/cbus.c +++ b/drivers/cbus/cbus.c @@ -291,4 +291,6 @@ subsys_initcall(cbus_bus_init); MODULE_DESCRIPTION(CBUS serial protocol); MODULE_LICENSE(GPL); -MODULE_AUTHOR(Juha Yrjölä, David Weinehall, and Mikko Ylinen); +MODULE_AUTHOR(Juha Yrjölä); +MODULE_AUTHOR(David Weinehall); +MODULE_AUTHOR(Mikko Ylinen); -- 1.6.6.rc0 -- 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] power_supply: Add driver for TWL4030/TPS65950 BCI charger
Hi, On Wed, Dec 02, 2009 at 10:54:42PM +0100, ext Anton Vorontsov wrote: As for the default USB VBUS current value, it could be Kconfig option (something alike to USB_GADGET_VBUS_DRAW) and/or module parameter, or hw default, or hardcoded for now. Either will work. cannot be Kconfig, it's mandated by usb battery charging spec 1.x to be 100mA for 100ms, then if you don't enumerate, you have to cut charging. -- Anton Vorontsov email: cbouatmai...@gmail.com irc://irc.freenode.net/bd2 -- balbi -- 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: [RFT/RFC/PATCH 00/10] several cleanup patches
On Wed, Dec 02, 2009 at 11:28:22PM +0100, Balbi Felipe (Nokia-D/Helsinki) wrote: on the following we have section mismatch fixes, compile fix to board-nokia770.c, compile fix to sossi.c, compile fix to hwa742.c, compile fix to tahvo-usb.c and a few cleanups to cbus driver. It's compile tested only as I don't have 770s or n8x0 with the development jig available right now, so please, if you have any of those boards dusting around, test the following patches. drop these... there was a missing hunk on one of the patches that broke n8x0 compilation... sending againg in a while. -- balbi -- 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
[RFT/RFC/PATCH 00/10] cleanups, compile fix, cbus
on the following we have section mismatch fixes, compile fix to board-nokia770.c, compile fix to sossi.c, compile fix to hwa742.c, compile fix to tahvo-usb.c and a few cleanups to cbus driver. It's compile tested only as I don't have 770s or n8x0 with the development jig available right now, so please, if you have any of those boards dusting around, test the following patches. (looks like everything is compiling fine now) Felipe Balbi (10): arm: omap1: clock: fix section mismatch arm: omap: n770: make it build again video: omap: sossi: make it build again video: omap: hwa742: make it build again cbus: tahvo-usb: make it build again cbus: switch to kzalloc cbus: move EXPORT_SYMBOL close to its exported symbols cbus: separate into several MODULE_AUTHOR entries cbus: move to platform_driver cbus: add platform_data to pass gpios arch/arm/mach-omap1/board-nokia770.c | 18 +++- arch/arm/mach-omap1/clock.c|2 +- arch/arm/mach-omap2/board-n8x0.c | 18 +++ arch/arm/plat-omap/include/plat/cbus.h | 31 + drivers/cbus/cbus.c| 77 ++-- drivers/cbus/tahvo-usb.c | 12 +++--- drivers/video/omap/hwa742.c|1 + drivers/video/omap/sossi.c |1 + 8 files changed, 119 insertions(+), 41 deletions(-) create mode 100644 arch/arm/plat-omap/include/plat/cbus.h -- 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
[RFT/RFC/PATCH 02/10] arm: omap: n770: make it build again
there's no plat/omapfb.h it's now under linux/omapfb.h Signed-off-by: Felipe Balbi felipe.ba...@nokia.com --- arch/arm/mach-omap1/board-nokia770.c |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/arch/arm/mach-omap1/board-nokia770.c b/arch/arm/mach-omap1/board-nokia770.c index af4d719..db9a1de 100644 --- a/arch/arm/mach-omap1/board-nokia770.c +++ b/arch/arm/mach-omap1/board-nokia770.c @@ -20,6 +20,7 @@ #include linux/spi/ads7846.h #include linux/workqueue.h #include linux/delay.h +#include linux/omapfb.h #include mach/hardware.h #include asm/mach-types.h @@ -33,7 +34,6 @@ #include plat/keypad.h #include plat/common.h #include plat/dsp_common.h -#include plat/omapfb.h #include plat/hwa742.h #include plat/lcd_mipid.h #include plat/mmc.h -- 1.6.6.rc0 -- 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
[RFT/RFC/PATCH 01/10] arm: omap1: clock: fix section mismatch
omap1_clk_functions was only used by
omap1_clk_init() which sits in __init
section, so make omap1_clock_functions
be __initdata to avoid the section mismatch.
Signed-off-by: Felipe Balbi felipe.ba...@nokia.com
---
arch/arm/mach-omap1/clock.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/arch/arm/mach-omap1/clock.c b/arch/arm/mach-omap1/clock.c
index 42cbe20..d28ace2 100644
--- a/arch/arm/mach-omap1/clock.c
+++ b/arch/arm/mach-omap1/clock.c
@@ -744,7 +744,7 @@ static void __init omap1_clk_disable_unused(struct clk *clk)
#define omap1_clk_disable_unused NULL
#endif
-static struct clk_functions omap1_clk_functions = {
+static struct clk_functions omap1_clk_functions __initdata = {
.clk_enable = omap1_clk_enable,
.clk_disable= omap1_clk_disable,
.clk_round_rate = omap1_clk_round_rate,
--
1.6.6.rc0
--
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
[RFT/RFC/PATCH 03/10] video: omap: sossi: make it build again
add missing linux/interrupt.h Signed-off-by: Felipe Balbi felipe.ba...@nokia.com --- drivers/video/omap/sossi.c |1 + 1 files changed, 1 insertions(+), 0 deletions(-) diff --git a/drivers/video/omap/sossi.c b/drivers/video/omap/sossi.c index 354cbbb..8fb7c70 100644 --- a/drivers/video/omap/sossi.c +++ b/drivers/video/omap/sossi.c @@ -23,6 +23,7 @@ #include linux/clk.h #include linux/irq.h #include linux/io.h +#include linux/interrupt.h #include plat/dma.h -- 1.6.6.rc0 -- 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
[RFT/RFC/PATCH 04/10] video: omap: hwa742: make it build again
add missing linux/interrupt.h Signed-off-by: Felipe Balbi felipe.ba...@nokia.com --- drivers/video/omap/hwa742.c |1 + 1 files changed, 1 insertions(+), 0 deletions(-) diff --git a/drivers/video/omap/hwa742.c b/drivers/video/omap/hwa742.c index 170d171..0016f77 100644 --- a/drivers/video/omap/hwa742.c +++ b/drivers/video/omap/hwa742.c @@ -25,6 +25,7 @@ #include linux/fb.h #include linux/delay.h #include linux/clk.h +#include linux/interrupt.h #include plat/dma.h #include plat/hwa742.h -- 1.6.6.rc0 -- 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
[RFT/RFC/PATCH 06/10] cbus: switch to kzalloc
change kmalloc() + memset() to kzalloc(), no functional changes. Signed-off-by: Felipe Balbi felipe.ba...@nokia.com --- drivers/cbus/cbus.c |4 +--- 1 files changed, 1 insertions(+), 3 deletions(-) diff --git a/drivers/cbus/cbus.c b/drivers/cbus/cbus.c index c80cede..0bcc211 100644 --- a/drivers/cbus/cbus.c +++ b/drivers/cbus/cbus.c @@ -224,12 +224,10 @@ int __init cbus_bus_init(void) struct cbus_host *chost; int ret; - chost = kmalloc(sizeof (*chost), GFP_KERNEL); + chost = kzalloc(sizeof (*chost), GFP_KERNEL); if (chost == NULL) return -ENOMEM; - memset(chost, 0, sizeof (*chost)); - spin_lock_init(chost-lock); /* REVISIT: Pass these from board-*.c files in platform_data */ -- 1.6.6.rc0 -- 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
[RFT/RFC/PATCH 09/10] cbus: move to platform_driver
also add the platform_device to 770 and n8x0 board files.
Signed-off-by: Felipe Balbi felipe.ba...@nokia.com
---
arch/arm/mach-omap1/board-nokia770.c |6 ++
arch/arm/mach-omap2/board-n8x0.c |8
drivers/cbus/cbus.c | 34 +-
3 files changed, 47 insertions(+), 1 deletions(-)
diff --git a/arch/arm/mach-omap1/board-nokia770.c
b/arch/arm/mach-omap1/board-nokia770.c
index db9a1de..a8debf3 100644
--- a/arch/arm/mach-omap1/board-nokia770.c
+++ b/arch/arm/mach-omap1/board-nokia770.c
@@ -97,8 +97,14 @@ static struct platform_device nokia770_kp_device = {
.resource = nokia770_kp_resources,
};
+static struct platform_device nokia770_cbus_device = {
+ .name = cbus,
+ .id = -1,
+};
+
static struct platform_device *nokia770_devices[] __initdata = {
nokia770_kp_device,
+ nokia770_cbus_device,
};
static void mipid_shutdown(struct mipid_platform_data *pdata)
diff --git a/arch/arm/mach-omap2/board-n8x0.c b/arch/arm/mach-omap2/board-n8x0.c
index 764ab1e..068949a 100644
--- a/arch/arm/mach-omap2/board-n8x0.c
+++ b/arch/arm/mach-omap2/board-n8x0.c
@@ -17,6 +17,7 @@
#include linux/init.h
#include linux/io.h
#include linux/stddef.h
+#include linux/platform_device.h
#include linux/spi/spi.h
#include linux/usb/musb.h
@@ -77,6 +78,11 @@ static struct mtd_partition onenand_partitions[] = {
},
};
+static struct platform_device n8x0_cbus_device = {
+ .name = cbus,
+ .id = -1,
+};
+
static struct omap_onenand_platform_data board_onenand_data = {
.cs = 0,
.gpio_irq = 26,
@@ -111,6 +117,8 @@ static void __init n8x0_init_irq(void)
static void __init n8x0_init_machine(void)
{
+ platform_device_register(n8x0_cbus_device);
+
/* FIXME: add n810 spi devices */
spi_register_board_info(n800_spi_board_info,
ARRAY_SIZE(n800_spi_board_info));
diff --git a/drivers/cbus/cbus.c b/drivers/cbus/cbus.c
index 145e760..a35941e 100644
--- a/drivers/cbus/cbus.c
+++ b/drivers/cbus/cbus.c
@@ -29,6 +29,7 @@
#include linux/delay.h
#include linux/spinlock.h
#include linux/gpio.h
+#include linux/platform_device.h
#include asm/io.h
#include asm/mach-types.h
@@ -222,7 +223,7 @@ int cbus_write_reg(struct cbus_host *host, int dev, int
reg, u16 val)
}
EXPORT_SYMBOL(cbus_write_reg);
-static int __init cbus_bus_init(void)
+static int __init cbus_bus_probe(struct platform_device *pdev)
{
struct cbus_host *chost;
int ret;
@@ -275,6 +276,8 @@ static int __init cbus_bus_init(void)
gpio_set_value(chost-clk_gpio, 1);
gpio_set_value(chost-clk_gpio, 0);
+ platform_set_drvdata(pdev, chost);
+
cbus_host = chost;
return 0;
@@ -284,13 +287,42 @@ exit2:
gpio_free(chost-clk_gpio);
exit1:
kfree(chost);
+
return ret;
}
+static void __exit cbus_bus_remove(struct platform_device *pdev)
+{
+ struct cbus_host*chost = platform_get_drvdata(pdev);
+
+ gpio_free(chost-dat_gpio);
+ gpio_free(chost-clk_gpio);
+ kfree(chost);
+}
+
+static struct platform_driver cbus_driver = {
+ .remove = __exit_p(cbus_bus_remove),
+ .driver = {
+ .name = cbus,
+ },
+};
+
+static int __init cbus_bus_init(void)
+{
+ return platform_driver_probe(cbus_driver, cbus_bus_probe);
+}
+
subsys_initcall(cbus_bus_init);
+static void __exit cbus_bus_exit(void)
+{
+ platform_driver_unregister(cbus_driver);
+}
+module_exit(cbus_bus_exit);
+
MODULE_DESCRIPTION(CBUS serial protocol);
MODULE_LICENSE(GPL);
MODULE_AUTHOR(Juha Yrjölä);
MODULE_AUTHOR(David Weinehall);
MODULE_AUTHOR(Mikko Ylinen);
+
--
1.6.6.rc0
--
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
[RFT/RFC/PATCH 10/10] cbus: add platform_data to pass gpios
also add the platform_data to the related
board files.
Signed-off-by: Felipe Balbi felipe.ba...@nokia.com
---
arch/arm/mach-omap1/board-nokia770.c | 10 ++
arch/arm/mach-omap2/board-n8x0.c | 10 ++
arch/arm/plat-omap/include/plat/cbus.h | 31 +++
drivers/cbus/cbus.c| 30 +-
4 files changed, 56 insertions(+), 25 deletions(-)
create mode 100644 arch/arm/plat-omap/include/plat/cbus.h
diff --git a/arch/arm/mach-omap1/board-nokia770.c
b/arch/arm/mach-omap1/board-nokia770.c
index a8debf3..95a3a82 100644
--- a/arch/arm/mach-omap1/board-nokia770.c
+++ b/arch/arm/mach-omap1/board-nokia770.c
@@ -38,6 +38,7 @@
#include plat/lcd_mipid.h
#include plat/mmc.h
#include plat/clock.h
+#include plat/cbus.h
#define ADS7846_PENDOWN_GPIO 15
@@ -97,9 +98,18 @@ static struct platform_device nokia770_kp_device = {
.resource = nokia770_kp_resources,
};
+static struct cbus_host_platform_data nokia770_cbus_data = {
+ .clk_gpio = OMAP_MPUIO(11),
+ .dat_gpio = OMAP_MPUIO(10),
+ .sel_gpio = OMAP_MPUIO(9),
+};
+
static struct platform_device nokia770_cbus_device = {
.name = cbus,
.id = -1,
+ .dev= {
+ .platform_data = nokia770_cbus_data,
+ },
};
static struct platform_device *nokia770_devices[] __initdata = {
diff --git a/arch/arm/mach-omap2/board-n8x0.c b/arch/arm/mach-omap2/board-n8x0.c
index 068949a..84004bc 100644
--- a/arch/arm/mach-omap2/board-n8x0.c
+++ b/arch/arm/mach-omap2/board-n8x0.c
@@ -30,6 +30,7 @@
#include plat/mcspi.h
#include plat/onenand.h
#include plat/serial.h
+#include plat/cbus.h
static struct omap2_mcspi_device_config p54spi_mcspi_config = {
.turbo_mode = 0,
@@ -78,9 +79,18 @@ static struct mtd_partition onenand_partitions[] = {
},
};
+static struct cbus_host_platform_data n8x0_cbus_data = {
+ .clk_gpio = 66,
+ .dat_gpio = 65,
+ .sel_gpio = 64,
+};
+
static struct platform_device n8x0_cbus_device = {
.name = cbus,
.id = -1,
+ .dev= {
+ .platform_data = n8x0_cbus_data,
+ },
};
static struct omap_onenand_platform_data board_onenand_data = {
diff --git a/arch/arm/plat-omap/include/plat/cbus.h
b/arch/arm/plat-omap/include/plat/cbus.h
new file mode 100644
index 000..d938e23
--- /dev/null
+++ b/arch/arm/plat-omap/include/plat/cbus.h
@@ -0,0 +1,31 @@
+/*
+ * cbus.h - CBUS platform_data definition
+ *
+ * Copyright (C) 2004 - 2009 Nokia Corporation
+ *
+ * Written by Felipe Balbi felipe.ba...@nokia.com
+ *
+ * This file is subject to the terms and conditions of the GNU General
+ * Public License. See the file COPYING in the main directory of this
+ * archive for more details.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, write to the Free Software
+ * Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA
+ */
+
+#ifndef __PLAT_CBUS_H
+#define __PLAT_CBUS_H
+
+struct cbus_host_platform_data {
+ int dat_gpio;
+ int clk_gpio;
+ int sel_gpio;
+};
+
+#endif /* __PLAT_CBUS_H */
diff --git a/drivers/cbus/cbus.c b/drivers/cbus/cbus.c
index a35941e..00c3c32 100644
--- a/drivers/cbus/cbus.c
+++ b/drivers/cbus/cbus.c
@@ -35,6 +35,7 @@
#include asm/mach-types.h
#include plat/board.h
+#include plat/cbus.h
#include cbus.h
@@ -226,6 +227,7 @@ EXPORT_SYMBOL(cbus_write_reg);
static int __init cbus_bus_probe(struct platform_device *pdev)
{
struct cbus_host *chost;
+ struct cbus_host_platform_data *pdata = pdev-dev.platform_data;
int ret;
chost = kzalloc(sizeof (*chost), GFP_KERNEL);
@@ -234,31 +236,9 @@ static int __init cbus_bus_probe(struct platform_device
*pdev)
spin_lock_init(chost-lock);
- /* REVISIT: Pass these from board-*.c files in platform_data */
- if (machine_is_nokia770()) {
- chost-clk_gpio = OMAP_MPUIO(11);
- chost-dat_gpio = OMAP_MPUIO(10);
- chost-sel_gpio = OMAP_MPUIO(9);
- } else if (machine_is_nokia_n800() || machine_is_nokia_n810() ||
- machine_is_nokia_n810_wimax()) {
- chost-clk_gpio = 66;
- chost-dat_gpio = 65;
- chost-sel_gpio = 64;
- } else {
- printk(KERN_ERR cbus: Unsupported board\n);
- ret = -ENODEV;
- goto exit1;
- }
-
-#ifdef CONFIG_ARCH_OMAP1
- if (!OMAP_GPIO_IS_MPUIO(chost-clk_gpio) ||
-
RE: I2C broken on OMAP 2430SDP?
Hello Paul! Thank you for pointing this out. I think we are missing a patch here which was actually sent for up-stream but did not make through as I don't see it on my latest master branch. http://patchwork.kernel.org/patch/49514/ Can you please apply this and see if it helps, I don't have any 2430SDP platform to test. Regards Moiz Sonasath -Original Message- From: Paul Walmsley [mailto:p...@pwsan.com] Sent: Tuesday, December 01, 2009 10:01 AM To: linux-omap@vger.kernel.org Cc: Sonasath, Moiz Subject: I2C broken on OMAP 2430SDP? Hi, just wanted to mention that i2c-omap.c has some problems on the 2430SDP with the linux-omap kernel running Linux 2.6.32-rc8, commit 4355c41a635943d30e9396b95185314343dcb551. This shows up at boot: bio: create slab bio-0 at 0 6i2c_omap i2c_omap.1: bus 1 rev3.6 at 400 kHz 6i2c_omap i2c_omap.2: bus 2 rev3.6 at 2600 kHz 4i2c_omap i2c_omap.2: timeout waiting for bus ready 3twl4030: err -110 initializing gpio IMR 4i2c_omap i2c_omap.2: timeout waiting for bus ready 3twl4030: err -110 initializing gpio SIH_CTRL 4i2c_omap i2c_omap.2: timeout waiting for bus ready 3twl4030: err -110 initializing keypad IMR 4i2c_omap i2c_omap.2: timeout waiting for bus ready 3twl4030: err -110 initializing keypad SIH_CTRL 4i2c_omap i2c_omap.2: timeout waiting for bus ready 3twl4030: err -110 initializing bci IMR 4i2c_omap i2c_omap.2: timeout waiting for bus ready 3twl4030: err -110 initializing madc IMR 4i2c_omap i2c_omap.2: timeout waiting for bus ready 3twl4030: err -110 initializing power IMR 4i2c_omap i2c_omap.2: timeout waiting for bus ready 3twl4030: err -110 initializing power SIH_CTRL 4i2c_omap i2c_omap.2: timeout waiting for bus ready 3twl4030: err -110 initializing gpio ISR 4i2c_omap i2c_omap.2: timeout waiting for bus ready 3twl4030: err -110 initializing gpio ISR 4i2c_omap i2c_omap.2: timeout waiting for bus ready 3twl4030: err -110 initializing keypad ISR 4i2c_omap i2c_omap.2: timeout waiting for bus ready 3twl4030: err -110 initializing keypad ISR 4i2c_omap i2c_omap.2: timeout waiting for bus ready 3twl4030: err -110 initializing bci ISR 4i2c_omap i2c_omap.2: timeout waiting for bus ready 4i2c_omap i2c_omap.2: timeout waiting for bus ready 3twl4030: err -110 initializing bci ISR ... This is with omap_2430sdp_defconfig. - Paul -- 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
[RFT/RFC/PATCH 07/10] cbus: move EXPORT_SYMBOL close to its exported symbols
while there, also add a missing static to cbus_bus_init().
Signed-off-by: Felipe Balbi felipe.ba...@nokia.com
---
drivers/cbus/cbus.c |9 -
1 files changed, 4 insertions(+), 5 deletions(-)
diff --git a/drivers/cbus/cbus.c b/drivers/cbus/cbus.c
index 0bcc211..d73d0c9 100644
--- a/drivers/cbus/cbus.c
+++ b/drivers/cbus/cbus.c
@@ -38,6 +38,7 @@
#include cbus.h
struct cbus_host *cbus_host = NULL;
+EXPORT_SYMBOL(cbus_host);
#ifdef CONFIG_ARCH_OMAP1
/* We use our own MPUIO functions to get closer to 1MHz bus speed */
@@ -210,6 +211,7 @@ int cbus_read_reg(struct cbus_host *host, int dev, int reg)
{
return cbus_host ? cbus_transfer(host, dev, reg, -1) : -ENODEV;
}
+EXPORT_SYMBOL(cbus_read_reg);
/*
* Write to a given register of the device
@@ -218,8 +220,9 @@ int cbus_write_reg(struct cbus_host *host, int dev, int
reg, u16 val)
{
return cbus_host ? cbus_transfer(host, dev, reg, (int)val) : -ENODEV;
}
+EXPORT_SYMBOL(cbus_write_reg);
-int __init cbus_bus_init(void)
+static int __init cbus_bus_init(void)
{
struct cbus_host *chost;
int ret;
@@ -286,10 +289,6 @@ exit1:
subsys_initcall(cbus_bus_init);
-EXPORT_SYMBOL(cbus_host);
-EXPORT_SYMBOL(cbus_read_reg);
-EXPORT_SYMBOL(cbus_write_reg);
-
MODULE_DESCRIPTION(CBUS serial protocol);
MODULE_LICENSE(GPL);
MODULE_AUTHOR(Juha Yrjölä, David Weinehall, and Mikko Ylinen);
--
1.6.6.rc0
--
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
[RFT/RFC/PATCH 05/10] cbus: tahvo-usb: make it build again
plenty of legacy code sitting there. Make it build
again. Later patches will come to clean that up.
Signed-off-by: Felipe Balbi felipe.ba...@nokia.com
---
drivers/cbus/tahvo-usb.c | 12 ++--
1 files changed, 6 insertions(+), 6 deletions(-)
diff --git a/drivers/cbus/tahvo-usb.c b/drivers/cbus/tahvo-usb.c
index c08f08d..9f8bbcc 100644
--- a/drivers/cbus/tahvo-usb.c
+++ b/drivers/cbus/tahvo-usb.c
@@ -114,8 +114,8 @@ static struct platform_device *tahvo_otg_dev;
static irqreturn_t omap_otg_irq(int irq, void *arg)
{
- struct platform_device *otg_dev = (struct platform_device *) arg;
- struct tahvo_usb *tu = (struct tahvo_usb *) otg_dev-dev.driver_data;
+ struct platform_device *otg_dev = arg;
+ struct tahvo_usb *tu = platform_get_drvdata(otg_dev);
u16 otg_irq;
otg_irq = omap_readw(OTG_IRQ_SRC);
@@ -227,7 +227,7 @@ struct device_driver omap_otg_driver = {
static ssize_t vbus_state_show(struct device *device,
struct device_attribute *attr, char *buf)
{
- struct tahvo_usb *tu = (struct tahvo_usb*) device-driver_data;
+ struct tahvo_usb *tu = dev_get_drvdata(device);
return sprintf(buf, %d\n, tu-vbus_state);
}
static DEVICE_ATTR(vbus_state, 0444, vbus_state_show, NULL);
@@ -590,7 +590,7 @@ static void tahvo_usb_vbus_interrupt(unsigned long arg)
static ssize_t otg_mode_show(struct device *device,
struct device_attribute *attr, char *buf)
{
- struct tahvo_usb *tu = (struct tahvo_usb*) device-driver_data;
+ struct tahvo_usb *tu = dev_get_drvdata(device);
switch (tu-tahvo_mode) {
case TAHVO_MODE_HOST:
return sprintf(buf, host\n);
@@ -604,7 +604,7 @@ static ssize_t otg_mode_store(struct device *device,
struct device_attribute *attr,
const char *buf, size_t count)
{
- struct tahvo_usb *tu = (struct tahvo_usb*) device-driver_data;
+ struct tahvo_usb *tu = dev_get_drvdata(device);
int r;
r = strlen(buf);
@@ -706,7 +706,7 @@ static int tahvo_usb_probe(struct device *dev)
return ret;
}
- dev-driver_data = tu;
+ dev_set_drvdata(dev, tu);
/* Act upon current vbus state once at startup. A vbus state irq may or
* may not be generated in addition to this. */
--
1.6.6.rc0
--
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
[RFT/RFC/PATCH 08/10] cbus: separate into several MODULE_AUTHOR entries
will look cleaner on modinfo. Signed-off-by: Felipe Balbi felipe.ba...@nokia.com --- drivers/cbus/cbus.c |4 +++- 1 files changed, 3 insertions(+), 1 deletions(-) diff --git a/drivers/cbus/cbus.c b/drivers/cbus/cbus.c index d73d0c9..145e760 100644 --- a/drivers/cbus/cbus.c +++ b/drivers/cbus/cbus.c @@ -291,4 +291,6 @@ subsys_initcall(cbus_bus_init); MODULE_DESCRIPTION(CBUS serial protocol); MODULE_LICENSE(GPL); -MODULE_AUTHOR(Juha Yrjölä, David Weinehall, and Mikko Ylinen); +MODULE_AUTHOR(Juha Yrjölä); +MODULE_AUTHOR(David Weinehall); +MODULE_AUTHOR(Mikko Ylinen); -- 1.6.6.rc0 -- 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] power_supply: Add driver for TWL4030/TPS65950 BCI charger
On Thu, Dec 03, 2009 at 12:31:56AM +0200, Felipe Balbi wrote: Hi, On Wed, Dec 02, 2009 at 10:54:42PM +0100, ext Anton Vorontsov wrote: As for the default USB VBUS current value, it could be Kconfig option (something alike to USB_GADGET_VBUS_DRAW) and/or module parameter, or hw default, or hardcoded for now. Either will work. cannot be Kconfig, it's mandated by usb battery charging spec 1.x to be 100mA for 100ms, then if you don't enumerate, you have to cut charging. Oh, I thought TWL4030 does the USB stuff somewhat transparently so the checks in twl4030_charger_check_vbus() would be enough. Is there any TWL4030 reference manual available? If TWL4030 just draws the VBUS directly, then it might be a good idea to integrate the driver with OTG framework, as an example see commit 5bf2b994bfe11bfe86231050897b2d881ca544d9 Author: Philipp Zabel philipp.za...@gmail.com Date: Sun Jan 18 17:40:27 2009 +0100 pda_power: Add optional OTG transceiver and voltage regulator support Though, instead of just a boolean is_usb_online() stuff, you'll have to get the allowed current draw value and configure the charger appropriately. Will this work? -- Anton Vorontsov email: cbouatmai...@gmail.com irc://irc.freenode.net/bd2 -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 0/9] Omap mux changes for v2.6.33 merge window, v2
Hi all,
I've updated this series to only map GPIO pins to mux registers
if CONFIG_OMAP_MUX is not set. Those are needed for dynamic muxing
for off-idle.
I've also added omap36xx support, which I have not been able to
test. People with 36xx boards, please give it a try.
Also fixed several checkpatch.pl warnings.
Again big thanks for Benoit Cousson b-cous...@ti.com and
Paul Walmsley p...@pwsan.com for help in getting the mux
data generated!
Regards,
Tony
Here are some instructions on how to use:
To see what got muxed during init, edit the kernel
CMDLINE to have debug in it:
# dmesg | grep mux
mux: Setting signal i2c2_scl.i2c2_scl 0x0100 - 0x0100
mux: Setting signal i2c2_sda.i2c2_sda 0x0100 - 0x0100
mux: Setting signal i2c3_scl.i2c3_scl 0x0100 - 0x0100
mux: Setting signal i2c3_sda.i2c3_sda 0x0100 - 0x0100
mux: Setting signal gpmc_ncs3.gpio54 0x410c - 0x010c
...
Looks like the gpmc_ncs3.gpio54 muxing in the kernel
has a bug where we should have OMAP_WAKEUP_EN set for
board_smc91x_init for board-rx51? :)
To override bootloader mux settings, edit the kernel CMDLINE:
omap_mux=i2c2_scl.i2c2_scl=0x100,i2c2_sda.i2c2_sda=0x100
Note that this only changes the bootloader settings, not
what might be muxed from the board-*.c files.
With CONFIG_DEBUG_FS set:
# mount -t sysfs sys /sys
# mount -t debugfs debug /sys/kernel/debug
# ls /sys/kernel/debug/omap_mux/i2c
i2c2_scl i2c2_sda i2c3_scl i2c3_sda i2c4_scl i2c4_sda
# cat /sys/kernel/debug/omap_mux/i2c2_scl
name: i2c2_scl.i2c2_scl (0x480021be/0x18e = 0x0100), b af15, t NA
mode: OMAP_PIN_INPUT | OMAP_MUX_MODE0
signals: i2c2_scl | NA | NA | NA | gpio_168 | NA | NA | safe_mode
---
Mike Rapoport (1):
omap2: mux: intoduce omap_mux_{read,write}
Tony Lindgren (8):
omap: mux: Add new style pin multiplexing code for omap3
omap: mux: Add new style pin multiplexing data for 34xx
omap: mux: Add new style init functions to omap3 board-*.c files
omap: mux: Add debugfs support for new mux code
omap: Split i2c platform init for mach-omap1 and mach-omap2
omap: mux: Replace omap_cfg_reg() with new style signal or gpio functions
omap: mux: Remove old mux code for 34xx
omap: mux: Add 36xx CBP package support
Documentation/kernel-parameters.txt |5
arch/arm/mach-omap1/Makefile |3
arch/arm/mach-omap1/i2c.c| 33
arch/arm/mach-omap2/Kconfig | 24
arch/arm/mach-omap2/Makefile |6
arch/arm/mach-omap2/board-3430sdp.c | 15
arch/arm/mach-omap2/board-3630sdp.c | 14
arch/arm/mach-omap2/board-am3517evm.c| 11
arch/arm/mach-omap2/board-cm-t35.c | 14
arch/arm/mach-omap2/board-igep0020.c | 11
arch/arm/mach-omap2/board-ldp.c | 10
arch/arm/mach-omap2/board-omap3beagle.c | 21
arch/arm/mach-omap2/board-omap3evm.c | 21
arch/arm/mach-omap2/board-omap3pandora.c | 15
arch/arm/mach-omap2/board-overo.c| 14
arch/arm/mach-omap2/board-rx51-peripherals.c |7
arch/arm/mach-omap2/board-rx51.c | 16
arch/arm/mach-omap2/board-zoom2.c| 10
arch/arm/mach-omap2/board-zoom3.c| 10
arch/arm/mach-omap2/devices.c| 62 +
arch/arm/mach-omap2/i2c.c| 56 +
arch/arm/mach-omap2/io.c |1
arch/arm/mach-omap2/mux.c| 1061 +
arch/arm/mach-omap2/mux.h| 163 ++
arch/arm/mach-omap2/mux34xx.c| 2099 ++
arch/arm/mach-omap2/mux34xx.h| 398 +
arch/arm/mach-omap2/usb-ehci.c | 166 +-
arch/arm/plat-omap/i2c.c | 44 -
arch/arm/plat-omap/include/plat/common.h | 14
arch/arm/plat-omap/include/plat/i2c.h| 39
arch/arm/plat-omap/include/plat/mux.h| 226 ---
arch/arm/plat-omap/mux.c |8
32 files changed, 3850 insertions(+), 747 deletions(-)
create mode 100644 arch/arm/mach-omap1/i2c.c
create mode 100644 arch/arm/mach-omap2/i2c.c
create mode 100644 arch/arm/mach-omap2/mux.h
create mode 100644 arch/arm/mach-omap2/mux34xx.c
create mode 100644 arch/arm/mach-omap2/mux34xx.h
create mode 100644 arch/arm/plat-omap/include/plat/i2c.h
--
Signature
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 1/9] omap2: mux: intoduce omap_mux_{read,write}
From: Mike Rapoport m...@compulab.co.il
intoduce omap_mux_{read,write}
Signed-off-by: Mike Rapoport m...@compulab.co.il
Signed-off-by: Tony Lindgren t...@atomide.com
---
arch/arm/mach-omap2/mux.c | 44 ++--
1 files changed, 38 insertions(+), 6 deletions(-)
diff --git a/arch/arm/mach-omap2/mux.c b/arch/arm/mach-omap2/mux.c
index c18a94e..64250c5 100644
--- a/arch/arm/mach-omap2/mux.c
+++ b/arch/arm/mach-omap2/mux.c
@@ -35,7 +35,27 @@
#ifdef CONFIG_OMAP_MUX
+#define OMAP_MUX_BASE_OFFSET 0x30/* Offset from CTRL_BASE */
+#define OMAP_MUX_BASE_SZ 0x5ca
+
static struct omap_mux_cfg arch_mux_cfg;
+static void __iomem *mux_base;
+
+static inline u16 omap_mux_read(u16 reg)
+{
+ if (cpu_is_omap24xx())
+ return __raw_readb(mux_base + reg);
+ else
+ return __raw_readw(mux_base + reg);
+}
+
+static inline void omap_mux_write(u16 val, u16 reg)
+{
+ if (cpu_is_omap24xx())
+ __raw_writeb(val, mux_base + reg);
+ else
+ __raw_writew(val, mux_base + reg);
+}
/* NOTE: See mux.h for the enumeration */
@@ -581,10 +601,7 @@ static void __init_or_module omap2_cfg_debug(const struct
pin_config *cfg, u16 r
u16 orig;
u8 warn = 0, debug = 0;
- if (cpu_is_omap24xx())
- orig = omap_ctrl_readb(cfg-mux_reg);
- else
- orig = omap_ctrl_readw(cfg-mux_reg);
+ orig = omap_mux_read(cfg-mux_reg - OMAP_MUX_BASE_OFFSET);
#ifdef CONFIG_OMAP_MUX_DEBUG
debug = cfg-debug;
@@ -614,7 +631,7 @@ static int __init_or_module omap24xx_cfg_reg(const struct
pin_config *cfg)
if (cfg-pu_pd_val)
reg |= OMAP2_PULL_UP;
omap2_cfg_debug(cfg, reg);
- omap_ctrl_writeb(reg, cfg-mux_reg);
+ omap_mux_write(reg, cfg-mux_reg - OMAP_MUX_BASE_OFFSET);
spin_unlock_irqrestore(mux_spin_lock, flags);
return 0;
@@ -633,7 +650,7 @@ static int __init_or_module omap34xx_cfg_reg(const struct
pin_config *cfg)
spin_lock_irqsave(mux_spin_lock, flags);
reg |= cfg-mux_val;
omap2_cfg_debug(cfg, reg);
- omap_ctrl_writew(reg, cfg-mux_reg);
+ omap_mux_write(reg, cfg-mux_reg - OMAP_MUX_BASE_OFFSET);
spin_unlock_irqrestore(mux_spin_lock, flags);
return 0;
@@ -644,6 +661,21 @@ static int __init_or_module omap34xx_cfg_reg(const struct
pin_config *cfg)
int __init omap2_mux_init(void)
{
+ u32 mux_pbase;
+
+ if (cpu_is_omap2420())
+ mux_pbase = OMAP2420_CTRL_BASE + OMAP_MUX_BASE_OFFSET;
+ else if (cpu_is_omap2430())
+ mux_pbase = OMAP243X_CTRL_BASE + OMAP_MUX_BASE_OFFSET;
+ else if (cpu_is_omap34xx())
+ mux_pbase = OMAP343X_CTRL_BASE + OMAP_MUX_BASE_OFFSET;
+
+ mux_base = ioremap(mux_pbase, OMAP_MUX_BASE_SZ);
+ if (!mux_base) {
+ printk(KERN_ERR mux: Could not ioremap\n);
+ return -ENODEV;
+ }
+
if (cpu_is_omap24xx()) {
arch_mux_cfg.pins = omap24xx_pins;
arch_mux_cfg.size = OMAP24XX_PINS_SZ;
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 2/9] omap: mux: Add new style pin multiplexing code for omap3
Initially only for 34xx. This code allows us to:
- Make the code more generic as the omap internal signal
names can stay the same across omap generations for some
devices
- Map mux registers to GPIO registers that is needed for
dynamic muxing of pins during off-idle
- Override bootloader mux values via kernel cmdline using
omap_mux=some.signa1=0x1234,some.signal2=0x1234
- View and set the mux registers via debugfs if
CONFIG_DEBUG_FS is enabled
Cc: Mike Rapoport m...@compulab.co.il
Cc: Benoit Cousson b-cous...@ti.com
Signed-off-by: Paul Walmsley p...@pwsan.com
Signed-off-by: Tony Lindgren t...@atomide.com
---
Documentation/kernel-parameters.txt |5
arch/arm/mach-omap2/mux.c | 444 +++
arch/arm/mach-omap2/mux.h | 160 +
arch/arm/plat-omap/mux.c|8 -
4 files changed, 611 insertions(+), 6 deletions(-)
create mode 100644 arch/arm/mach-omap2/mux.h
diff --git a/Documentation/kernel-parameters.txt
b/Documentation/kernel-parameters.txt
index 9107b38..24a0d84 100644
--- a/Documentation/kernel-parameters.txt
+++ b/Documentation/kernel-parameters.txt
@@ -1772,6 +1772,11 @@ and is between 256 and 4096 characters. It is defined in
the file
waiting for the ACK, so if this is set too high
interrupts *may* be lost!
+ omap_mux= [OMAP] Override bootloader pin multiplexing.
+ Format: mux_mode0.mode_name=value...
+ For example, to override I2C bus2:
+ omap_mux=i2c2_scl.i2c2_scl=0x100,i2c2_sda.i2c2_sda=0x100
+
opl3= [HW,OSS]
Format: io
diff --git a/arch/arm/mach-omap2/mux.c b/arch/arm/mach-omap2/mux.c
index 64250c5..b082b50 100644
--- a/arch/arm/mach-omap2/mux.c
+++ b/arch/arm/mach-omap2/mux.c
@@ -27,18 +27,23 @@
#include linux/init.h
#include linux/io.h
#include linux/spinlock.h
+#include linux/list.h
#include asm/system.h
#include plat/control.h
#include plat/mux.h
-#ifdef CONFIG_OMAP_MUX
+#include mux.h
#define OMAP_MUX_BASE_OFFSET 0x30/* Offset from CTRL_BASE */
#define OMAP_MUX_BASE_SZ 0x5ca
-static struct omap_mux_cfg arch_mux_cfg;
+struct omap_mux_entry {
+ struct omap_mux mux;
+ struct list_headnode;
+};
+
static void __iomem *mux_base;
static inline u16 omap_mux_read(u16 reg)
@@ -57,6 +62,10 @@ static inline void omap_mux_write(u16 val, u16 reg)
__raw_writew(val, mux_base + reg);
}
+#ifdef CONFIG_OMAP_MUX
+
+static struct omap_mux_cfg arch_mux_cfg;
+
/* NOTE: See mux.h for the enumeration */
#ifdef CONFIG_ARCH_OMAP24XX
@@ -667,8 +676,8 @@ int __init omap2_mux_init(void)
mux_pbase = OMAP2420_CTRL_BASE + OMAP_MUX_BASE_OFFSET;
else if (cpu_is_omap2430())
mux_pbase = OMAP243X_CTRL_BASE + OMAP_MUX_BASE_OFFSET;
- else if (cpu_is_omap34xx())
- mux_pbase = OMAP343X_CTRL_BASE + OMAP_MUX_BASE_OFFSET;
+ else
+ return -ENODEV;
mux_base = ioremap(mux_pbase, OMAP_MUX_BASE_SZ);
if (!mux_base) {
@@ -689,4 +698,431 @@ int __init omap2_mux_init(void)
return omap_mux_register(arch_mux_cfg);
}
+#endif /* CONFIG_OMAP_MUX */
+
+/**/
+
+#ifdef CONFIG_ARCH_OMAP34XX
+
+static LIST_HEAD(muxmodes);
+static DEFINE_MUTEX(muxmode_mutex);
+
+#ifdef CONFIG_OMAP_MUX
+
+static char *omap_mux_options;
+
+int __init omap_mux_init_gpio(int gpio, int val)
+{
+ struct omap_mux_entry *e;
+ int found = 0;
+
+ if (!gpio)
+ return -EINVAL;
+
+ list_for_each_entry(e, muxmodes, node) {
+ struct omap_mux *m = e-mux;
+ if (gpio == m-gpio) {
+ u16 old_mode;
+ u16 mux_mode;
+
+ old_mode = omap_mux_read(m-reg_offset);
+ mux_mode = val ~(OMAP_MUX_NR_MODES - 1);
+ mux_mode |= OMAP_MUX_MODE4;
+ printk(KERN_DEBUG mux: Setting signal
+ %s.gpio%i 0x%04x - 0x%04x\n,
+ m-muxnames[0], gpio, old_mode, mux_mode);
+ omap_mux_write(mux_mode, m-reg_offset);
+ found++;
+ }
+ }
+
+ if (found == 1)
+ return 0;
+
+ if (found 1) {
+ printk(KERN_ERR mux: Multiple gpio paths for gpio%i\n, gpio);
+ return -EINVAL;
+ }
+
+ printk(KERN_ERR mux: Could not set gpio%i\n, gpio);
+
+ return -ENODEV;
+}
+
+int __init omap_mux_init_signal(char *muxname, int val)
+{
+ struct omap_mux_entry *e;
+ char *m0_name = NULL, *mode_name = NULL;
+ int found = 0;
+
+ mode_name = strchr(muxname, '.');
+ if (mode_name) {
+
[PATCH 4/9] omap: mux: Add new style init functions to omap3 board-*.c files
Add new style mux init functions to omap3 board-*.c files
So far Beagle has been confirmed to be a CBB package,
and CM-T35 a CUS package.
Signed-off-by: Tony Lindgren t...@atomide.com
---
arch/arm/mach-omap2/Kconfig | 10 ++
arch/arm/mach-omap2/board-3430sdp.c | 10 ++
arch/arm/mach-omap2/board-am3517evm.c| 11 +++
arch/arm/mach-omap2/board-cm-t35.c | 10 ++
arch/arm/mach-omap2/board-igep0020.c | 10 ++
arch/arm/mach-omap2/board-ldp.c | 10 ++
arch/arm/mach-omap2/board-omap3beagle.c | 10 ++
arch/arm/mach-omap2/board-omap3evm.c | 10 ++
arch/arm/mach-omap2/board-omap3pandora.c | 10 ++
arch/arm/mach-omap2/board-overo.c|9 +
arch/arm/mach-omap2/board-rx51.c | 11 +++
arch/arm/mach-omap2/board-zoom2.c| 10 ++
12 files changed, 121 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-omap2/Kconfig b/arch/arm/mach-omap2/Kconfig
index c324d52..c10789c 100644
--- a/arch/arm/mach-omap2/Kconfig
+++ b/arch/arm/mach-omap2/Kconfig
@@ -61,14 +61,17 @@ config MACH_OMAP_2430SDP
config MACH_OMAP3_BEAGLE
bool OMAP3 BEAGLE board
depends on ARCH_OMAP3 ARCH_OMAP34XX
+ select OMAP_PACKAGE_CBB
config MACH_OMAP_LDP
bool OMAP3 LDP board
depends on ARCH_OMAP3 ARCH_OMAP34XX
+ select OMAP_PACKAGE_CBB
config MACH_OVERO
bool Gumstix Overo board
depends on ARCH_OMAP3 ARCH_OMAP34XX
+ select OMAP_PACKAGE_CBB
config MACH_OMAP3EVM
bool OMAP 3530 EVM board
@@ -77,14 +80,17 @@ config MACH_OMAP3EVM
config MACH_OMAP3517EVM
bool OMAP3517/ AM3517 EVM board
depends on ARCH_OMAP3 ARCH_OMAP34XX
+ select OMAP_PACKAGE_CBB
config MACH_OMAP3_PANDORA
bool OMAP3 Pandora
depends on ARCH_OMAP3 ARCH_OMAP34XX
+ select OMAP_PACKAGE_CBB
config MACH_OMAP_3430SDP
bool OMAP 3430 SDP board
depends on ARCH_OMAP3 ARCH_OMAP34XX
+ select OMAP_PACKAGE_CBB
config MACH_NOKIA_N800
bool
@@ -105,10 +111,12 @@ config MACH_NOKIA_N8X0
config MACH_NOKIA_RX51
bool Nokia RX-51 board
depends on ARCH_OMAP3 ARCH_OMAP34XX
+ select OMAP_PACKAGE_CBB
config MACH_OMAP_ZOOM2
bool OMAP3 Zoom2 board
depends on ARCH_OMAP3 ARCH_OMAP34XX
+ select OMAP_PACKAGE_CBB
config MACH_OMAP_ZOOM3
bool OMAP3630 Zoom3 board
@@ -117,10 +125,12 @@ config MACH_OMAP_ZOOM3
config MACH_CM_T35
bool CompuLab CM-T35 module
depends on ARCH_OMAP3 ARCH_OMAP34XX
+ select OMAP_PACKAGE_CUS
config MACH_IGEP0020
bool IGEP0020
depends on ARCH_OMAP3 ARCH_OMAP34XX
+ select OMAP_PACKAGE_CBB
config MACH_OMAP_3630SDP
bool OMAP3630 SDP board
diff --git a/arch/arm/mach-omap2/board-3430sdp.c
b/arch/arm/mach-omap2/board-3430sdp.c
index 5bda9fd..e5d9118 100644
--- a/arch/arm/mach-omap2/board-3430sdp.c
+++ b/arch/arm/mach-omap2/board-3430sdp.c
@@ -42,6 +42,7 @@
#include plat/control.h
#include plat/gpmc-smc91x.h
+#include mux.h
#include sdram-qimonda-hyb18m512160af-6.h
#include mmc-twl4030.h
@@ -640,8 +641,17 @@ static struct ehci_hcd_omap_platform_data ehci_pdata
__initconst = {
.reset_gpio_port[2] = -EINVAL
};
+#ifdef CONFIG_OMAP_MUX
+static struct omap_board_mux board_mux[] __initdata = {
+ { .reg_offset = OMAP_MUX_TERMINATOR },
+};
+#else
+#define board_mux NULL
+#endif
+
static void __init omap_3430sdp_init(void)
{
+ omap3_mux_init(board_mux, OMAP_PACKAGE_CBB);
omap3430_i2c_init();
platform_add_devices(sdp3430_devices, ARRAY_SIZE(sdp3430_devices));
if (omap_rev() OMAP3430_REV_ES1_0)
diff --git a/arch/arm/mach-omap2/board-am3517evm.c
b/arch/arm/mach-omap2/board-am3517evm.c
index 415a13d..b4e6eca 100644
--- a/arch/arm/mach-omap2/board-am3517evm.c
+++ b/arch/arm/mach-omap2/board-am3517evm.c
@@ -30,6 +30,8 @@
#include plat/common.h
#include plat/usb.h
+#include mux.h
+
/*
* Board initialization
*/
@@ -60,8 +62,17 @@ static struct ehci_hcd_omap_platform_data ehci_pdata
__initdata = {
.reset_gpio_port[2] = -EINVAL
};
+#ifdef CONFIG_OMAP_MUX
+static struct omap_board_mux board_mux[] __initdata = {
+ { .reg_offset = OMAP_MUX_TERMINATOR },
+};
+#else
+#define board_mux NULL
+#endif
+
static void __init am3517_evm_init(void)
{
+ omap3_mux_init(board_mux, OMAP_PACKAGE_CBB);
platform_add_devices(am3517_evm_devices,
ARRAY_SIZE(am3517_evm_devices));
diff --git a/arch/arm/mach-omap2/board-cm-t35.c
b/arch/arm/mach-omap2/board-cm-t35.c
index 22c4529..84321f6 100644
--- a/arch/arm/mach-omap2/board-cm-t35.c
+++ b/arch/arm/mach-omap2/board-cm-t35.c
@@ -45,6 +45,7 @@
#include mach/hardware.h
+#include mux.h
#include sdram-micron-mt46h32m32lf-6.h
#include mmc-twl4030.h
@@ -482,8 +483,17 @@ static void
[PATCH 5/9] omap: mux: Add debugfs support for new mux code
Add debugfs support for new mux code
Signed-off-by: Tony Lindgren t...@atomide.com
---
arch/arm/mach-omap2/mux.c | 227 +
1 files changed, 227 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-omap2/mux.c b/arch/arm/mach-omap2/mux.c
index b082b50..d968433 100644
--- a/arch/arm/mach-omap2/mux.c
+++ b/arch/arm/mach-omap2/mux.c
@@ -28,6 +28,10 @@
#include linux/io.h
#include linux/spinlock.h
#include linux/list.h
+#include linux/ctype.h
+#include linux/debugfs.h
+#include linux/seq_file.h
+#include linux/uaccess.h
#include asm/system.h
@@ -44,6 +48,7 @@ struct omap_mux_entry {
struct list_headnode;
};
+static unsigned long mux_phys;
static void __iomem *mux_base;
static inline u16 omap_mux_read(u16 reg)
@@ -807,6 +812,225 @@ int __init omap_mux_init_signal(char *muxname, int val)
return -ENODEV;
}
+#ifdef CONFIG_DEBUG_FS
+
+#define OMAP_MUX_MAX_NR_FLAGS 10
+#define OMAP_MUX_TEST_FLAG(val, mask) \
+ if (((val) (mask)) == (mask)) { \
+ i++;\
+ flags[i] = #mask; \
+ }
+
+/* REVISIT: Add checking for non-optimal mux settings */
+static inline void omap_mux_decode(struct seq_file *s, u16 val)
+{
+ char *flags[OMAP_MUX_MAX_NR_FLAGS];
+ char mode[14];
+ int i = -1;
+
+ sprintf(mode, OMAP_MUX_MODE%d, val 0x7);
+ i++;
+ flags[i] = mode;
+
+ OMAP_MUX_TEST_FLAG(val, OMAP_PIN_OFF_WAKEUPENABLE);
+ if (val OMAP_OFF_EN) {
+ if (!(val OMAP_OFFOUT_EN)) {
+ if (!(val OMAP_OFF_PULL_UP)) {
+ OMAP_MUX_TEST_FLAG(val,
+ OMAP_PIN_OFF_INPUT_PULLDOWN);
+ } else {
+ OMAP_MUX_TEST_FLAG(val,
+ OMAP_PIN_OFF_INPUT_PULLUP);
+ }
+ } else {
+ if (!(val OMAP_OFFOUT_VAL)) {
+ OMAP_MUX_TEST_FLAG(val,
+ OMAP_PIN_OFF_OUTPUT_LOW);
+ } else {
+ OMAP_MUX_TEST_FLAG(val,
+ OMAP_PIN_OFF_OUTPUT_HIGH);
+ }
+ }
+ }
+
+ if (val OMAP_INPUT_EN) {
+ if (val OMAP_PULL_ENA) {
+ if (!(val OMAP_PULL_UP)) {
+ OMAP_MUX_TEST_FLAG(val,
+ OMAP_PIN_INPUT_PULLDOWN);
+ } else {
+ OMAP_MUX_TEST_FLAG(val, OMAP_PIN_INPUT_PULLUP);
+ }
+ } else {
+ OMAP_MUX_TEST_FLAG(val, OMAP_PIN_INPUT);
+ }
+ } else {
+ i++;
+ flags[i] = OMAP_PIN_OUTPUT;
+ }
+
+ do {
+ seq_printf(s, %s, flags[i]);
+ if (i 0)
+ seq_printf(s, | );
+ } while (i-- 0);
+}
+
+#define OMAP_MUX_DEFNAME_LEN 16
+
+static int omap_mux_dbg_board_show(struct seq_file *s, void *unused)
+{
+ struct omap_mux_entry *e;
+
+ list_for_each_entry(e, muxmodes, node) {
+ struct omap_mux *m = e-mux;
+ char m0_def[OMAP_MUX_DEFNAME_LEN];
+ char *m0_name = m-muxnames[0];
+ u16 val;
+ int i, mode;
+
+ if (!m0_name)
+ continue;
+
+ for (i = 0; i OMAP_MUX_DEFNAME_LEN; i++) {
+ if (m0_name[i] == '\0') {
+ m0_def[i] = m0_name[i];
+ break;
+ }
+ m0_def[i] = toupper(m0_name[i]);
+ }
+ val = omap_mux_read(m-reg_offset);
+ mode = val OMAP_MUX_MODE7;
+
+ seq_printf(s, OMAP%i_MUX(%s, ,
+ cpu_is_omap34xx() ? 3 : 0, m0_def);
+ omap_mux_decode(s, val);
+ seq_printf(s, ),\n);
+ }
+
+ return 0;
+}
+
+static int omap_mux_dbg_board_open(struct inode *inode, struct file *file)
+{
+ return single_open(file, omap_mux_dbg_board_show, inode-i_private);
+}
+
+static const struct file_operations omap_mux_dbg_board_fops = {
+ .open = omap_mux_dbg_board_open,
+ .read = seq_read,
+ .llseek = seq_lseek,
+ .release= single_release,
+};
+
+static int omap_mux_dbg_signal_show(struct seq_file *s, void *unused)
+{
+ struct omap_mux *m = s-private;
+ const char *none = NA;
+ u16 val;
+ int mode;
+
+ val = omap_mux_read(m-reg_offset);
+ mode = val OMAP_MUX_MODE7;
+
+ seq_printf(s, name:
[PATCH 6/9] omap: Split i2c platform init for mach-omap1 and mach-omap2
Otherwise we cannot limit new mux code to mach-omap2.
The same signal names should eventually work for other
omaps under mach-omap2.
Note that these pins don't need to be OMAP_PIN_INPUT_PULLUP,
just OMAP_PIN_INPUT is enough.
Cc: Jarkko Nikula jhnik...@gmail.com
Signed-off-by: Tony Lindgren t...@atomide.com
---
arch/arm/mach-omap1/Makefile |3 ++
arch/arm/mach-omap1/i2c.c| 33 ++
arch/arm/mach-omap2/Makefile |3 ++
arch/arm/mach-omap2/i2c.c| 56 ++
arch/arm/plat-omap/i2c.c | 44 +---
arch/arm/plat-omap/include/plat/common.h | 14 +---
arch/arm/plat-omap/include/plat/i2c.h| 39 +
7 files changed, 137 insertions(+), 55 deletions(-)
create mode 100644 arch/arm/mach-omap1/i2c.c
create mode 100644 arch/arm/mach-omap2/i2c.c
create mode 100644 arch/arm/plat-omap/include/plat/i2c.h
diff --git a/arch/arm/mach-omap1/Makefile b/arch/arm/mach-omap1/Makefile
index 87e539a..51bc195 100644
--- a/arch/arm/mach-omap1/Makefile
+++ b/arch/arm/mach-omap1/Makefile
@@ -17,6 +17,9 @@ obj-$(CONFIG_PM) += pm.o sleep.o
obj-$(CONFIG_OMAP_MBOX_FWK)+= mailbox_mach.o
mailbox_mach-objs := mailbox.o
+i2c-omap-$(CONFIG_I2C_OMAP):= i2c.o
+obj-y += $(i2c-omap-m) $(i2c-omap-y)
+
led-y := leds.o
# Specific board support
diff --git a/arch/arm/mach-omap1/i2c.c b/arch/arm/mach-omap1/i2c.c
new file mode 100644
index 000..bc9d12b
--- /dev/null
+++ b/arch/arm/mach-omap1/i2c.c
@@ -0,0 +1,33 @@
+/*
+ * Helper module for board specific I2C bus registration
+ *
+ * Copyright (C) 2009 Nokia Corporation.
+ *
+ * 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.
+ *
+ * This program is distributed in the hope that it will be useful, but
+ * WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
+ * General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, write to the Free Software
+ * Foundation, Inc., 51 Franklin St, Fifth Floor, Boston, MA
+ * 02110-1301 USA
+ *
+ */
+
+#include plat/i2c.h
+#include plat/mux.h
+
+int __init omap_register_i2c_bus(int bus_id, u32 clkrate,
+ struct i2c_board_info const *info,
+ unsigned len)
+{
+ omap_cfg_reg(I2C_SDA);
+ omap_cfg_reg(I2C_SCL);
+
+ return omap_plat_register_i2c_bus(bus_id, clkrate, info, len);
+}
diff --git a/arch/arm/mach-omap2/Makefile b/arch/arm/mach-omap2/Makefile
index 3d0c35f..52ceeef 100644
--- a/arch/arm/mach-omap2/Makefile
+++ b/arch/arm/mach-omap2/Makefile
@@ -55,6 +55,9 @@ iommu-$(CONFIG_ARCH_OMAP3)+= omap3-iommu.o
obj-$(CONFIG_OMAP_IOMMU) += $(iommu-y)
+i2c-omap-$(CONFIG_I2C_OMAP):= i2c.o
+obj-y += $(i2c-omap-m) $(i2c-omap-y)
+
# Specific board support
obj-$(CONFIG_MACH_OMAP_GENERIC)+= board-generic.o
obj-$(CONFIG_MACH_OMAP_H4) += board-h4.o
diff --git a/arch/arm/mach-omap2/i2c.c b/arch/arm/mach-omap2/i2c.c
new file mode 100644
index 000..789ca8c
--- /dev/null
+++ b/arch/arm/mach-omap2/i2c.c
@@ -0,0 +1,56 @@
+/*
+ * Helper module for board specific I2C bus registration
+ *
+ * Copyright (C) 2009 Nokia Corporation.
+ *
+ * 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.
+ *
+ * This program is distributed in the hope that it will be useful, but
+ * WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
+ * General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, write to the Free Software
+ * Foundation, Inc., 51 Franklin St, Fifth Floor, Boston, MA
+ * 02110-1301 USA
+ *
+ */
+
+#include plat/cpu.h
+#include plat/i2c.h
+#include plat/mux.h
+
+#include mux.h
+
+int __init omap_register_i2c_bus(int bus_id, u32 clkrate,
+ struct i2c_board_info const *info,
+ unsigned len)
+{
+ if (cpu_is_omap24xx()) {
+ const int omap24xx_pins[][2] = {
+ { M19_24XX_I2C1_SCL, L15_24XX_I2C1_SDA },
+ { J15_24XX_I2C2_SCL, H19_24XX_I2C2_SDA },
+ };
+ int scl, sda;
+
+ scl = omap24xx_pins[bus_id - 1][0];
+ sda = omap24xx_pins[bus_id - 1][1];
+ omap_cfg_reg(sda);
+ omap_cfg_reg(scl);
+ }
+
+
[PATCH 7/9] omap: mux: Replace omap_cfg_reg() with new style signal or gpio functions
Replace omap_cfg_reg() with new style signal or gpio functions
Signed-off-by: Tony Lindgren t...@atomide.com
---
arch/arm/mach-omap2/board-3430sdp.c |4 -
arch/arm/mach-omap2/board-3630sdp.c |5 +
arch/arm/mach-omap2/board-cm-t35.c |3
arch/arm/mach-omap2/board-omap3beagle.c | 10 +-
arch/arm/mach-omap2/board-omap3evm.c | 10 +-
arch/arm/mach-omap2/board-omap3pandora.c |4 -
arch/arm/mach-omap2/board-overo.c|4 -
arch/arm/mach-omap2/board-rx51-peripherals.c |7 +
arch/arm/mach-omap2/board-rx51.c |4 -
arch/arm/mach-omap2/devices.c| 62 +++---
arch/arm/mach-omap2/usb-ehci.c | 166 +-
11 files changed, 177 insertions(+), 102 deletions(-)
diff --git a/arch/arm/mach-omap2/board-3430sdp.c
b/arch/arm/mach-omap2/board-3430sdp.c
index e5d9118..ded3e87 100644
--- a/arch/arm/mach-omap2/board-3430sdp.c
+++ b/arch/arm/mach-omap2/board-3430sdp.c
@@ -626,7 +626,9 @@ static inline void board_smc91x_init(void)
static void enable_board_wakeup_source(void)
{
- omap_cfg_reg(AF26_34XX_SYS_NIRQ); /* T2 interrupt line (keypad) */
+ /* T2 interrupt line (keypad) */
+ omap_mux_init_signal(sys_nirq,
+ OMAP_WAKEUP_EN | OMAP_PIN_INPUT_PULLUP);
}
static struct ehci_hcd_omap_platform_data ehci_pdata __initconst = {
diff --git a/arch/arm/mach-omap2/board-3630sdp.c
b/arch/arm/mach-omap2/board-3630sdp.c
index 348b70b..e6cbc27 100755
--- a/arch/arm/mach-omap2/board-3630sdp.c
+++ b/arch/arm/mach-omap2/board-3630sdp.c
@@ -23,6 +23,7 @@
#include mach/board-zoom.h
+#include mux.h
#include sdram-hynix-h8mbx00u0mer-0em.h
#if defined(CONFIG_SMC91X) || defined(CONFIG_SMC91X_MODULE)
@@ -48,7 +49,9 @@ static inline void board_smc91x_init(void)
static void enable_board_wakeup_source(void)
{
- omap_cfg_reg(AF26_34XX_SYS_NIRQ); /* T2 interrupt line (keypad) */
+ /* T2 interrupt line (keypad) */
+ omap_mux_init_signal(sys_nirq,
+ OMAP_WAKEUP_EN | OMAP_PIN_INPUT_PULLUP);
}
static struct ehci_hcd_omap_platform_data ehci_pdata __initconst = {
diff --git a/arch/arm/mach-omap2/board-cm-t35.c
b/arch/arm/mach-omap2/board-cm-t35.c
index 84321f6..10a5955 100644
--- a/arch/arm/mach-omap2/board-cm-t35.c
+++ b/arch/arm/mach-omap2/board-cm-t35.c
@@ -503,7 +503,8 @@ static void __init cm_t35_init(void)
usb_musb_init();
- omap_cfg_reg(AF26_34XX_SYS_NIRQ);
+ omap_mux_init_signal(sys_nirq,
+ OMAP_WAKEUP_EN | OMAP_PIN_INPUT_PULLUP);
}
MACHINE_START(CM_T35, Compulab CM-T35)
diff --git a/arch/arm/mach-omap2/board-omap3beagle.c
b/arch/arm/mach-omap2/board-omap3beagle.c
index e669dbb..9e606b1 100644
--- a/arch/arm/mach-omap2/board-omap3beagle.c
+++ b/arch/arm/mach-omap2/board-omap3beagle.c
@@ -141,10 +141,10 @@ static int beagle_twl_gpio_setup(struct device *dev,
unsigned gpio, unsigned ngpio)
{
if (system_rev = 0x20 system_rev = 0x34301000) {
- omap_cfg_reg(AG9_34XX_GPIO23);
+ omap_mux_init_gpio(23, OMAP_PIN_INPUT);
mmc[0].gpio_wp = 23;
} else {
- omap_cfg_reg(AH8_34XX_GPIO29);
+ omap_mux_init_gpio(29, OMAP_PIN_INPUT);
}
/* gpio + 0 is mmc0_cd (input/IRQ) */
mmc[0].gpio_cd = gpio + 0;
@@ -439,7 +439,7 @@ static void __init omap3_beagle_init(void)
ARRAY_SIZE(omap3_beagle_devices));
omap_serial_init();
- omap_cfg_reg(J25_34XX_GPIO170);
+ omap_mux_init_gpio(170, OMAP_PIN_INPUT);
gpio_request(170, DVI_nPD);
/* REVISIT leave DVI powered down until it's needed ... */
gpio_direction_output(170, true);
@@ -449,8 +449,8 @@ static void __init omap3_beagle_init(void)
omap3beagle_flash_init();
/* Ensure SDRC pins are mux'd for self-refresh */
- omap_cfg_reg(H16_34XX_SDRC_CKE0);
- omap_cfg_reg(H17_34XX_SDRC_CKE1);
+ omap_mux_init_signal(sdrc_cke0, OMAP_PIN_OUTPUT);
+ omap_mux_init_signal(sdrc_cke1, OMAP_PIN_OUTPUT);
}
static void __init omap3_beagle_map_io(void)
diff --git a/arch/arm/mach-omap2/board-omap3evm.c
b/arch/arm/mach-omap2/board-omap3evm.c
index ad174ae..0457f61 100644
--- a/arch/arm/mach-omap2/board-omap3evm.c
+++ b/arch/arm/mach-omap2/board-omap3evm.c
@@ -224,7 +224,7 @@ static int omap3evm_twl_gpio_setup(struct device *dev,
unsigned gpio, unsigned ngpio)
{
/* gpio + 0 is mmc0_cd (input/IRQ) */
- omap_cfg_reg(L8_34XX_GPIO63);
+ omap_mux_init_gpio(63, OMAP_PIN_INPUT);
mmc[0].gpio_cd = gpio + 0;
twl4030_mmc_init(mmc);
@@ -450,24 +450,24 @@ static void __init omap3_evm_init(void)
#endif
if (get_omap3_evm_rev() = OMAP3EVM_BOARD_GEN_2) {
/* enable EHCI VBUS using GPIO22 */
- omap_cfg_reg(AF9_34XX_GPIO22);
+ omap_mux_init_gpio(22,
[PATCH 8/9] omap: mux: Remove old mux code for 34xx
Remove old mux code for 34xx
Signed-off-by: Tony Lindgren t...@atomide.com
---
arch/arm/mach-omap2/board-3430sdp.c |1
arch/arm/mach-omap2/board-cm-t35.c |1
arch/arm/mach-omap2/board-igep0020.c |1
arch/arm/mach-omap2/board-omap3beagle.c |1
arch/arm/mach-omap2/board-omap3evm.c |1
arch/arm/mach-omap2/board-omap3pandora.c |1
arch/arm/mach-omap2/board-overo.c|1
arch/arm/mach-omap2/board-rx51.c |1
arch/arm/mach-omap2/io.c |1
arch/arm/mach-omap2/mux.c| 368 +-
arch/arm/plat-omap/include/plat/mux.h| 226 --
11 files changed, 14 insertions(+), 589 deletions(-)
diff --git a/arch/arm/mach-omap2/board-3430sdp.c
b/arch/arm/mach-omap2/board-3430sdp.c
index ded3e87..4cfb7b6 100644
--- a/arch/arm/mach-omap2/board-3430sdp.c
+++ b/arch/arm/mach-omap2/board-3430sdp.c
@@ -31,7 +31,6 @@
#include asm/mach/map.h
#include plat/mcspi.h
-#include plat/mux.h
#include plat/board.h
#include plat/usb.h
#include plat/common.h
diff --git a/arch/arm/mach-omap2/board-cm-t35.c
b/arch/arm/mach-omap2/board-cm-t35.c
index 10a5955..507c922 100644
--- a/arch/arm/mach-omap2/board-cm-t35.c
+++ b/arch/arm/mach-omap2/board-cm-t35.c
@@ -38,7 +38,6 @@
#include plat/board.h
#include plat/common.h
-#include plat/mux.h
#include plat/nand.h
#include plat/gpmc.h
#include plat/usb.h
diff --git a/arch/arm/mach-omap2/board-igep0020.c
b/arch/arm/mach-omap2/board-igep0020.c
index 7e3217a..44239e3 100644
--- a/arch/arm/mach-omap2/board-igep0020.c
+++ b/arch/arm/mach-omap2/board-igep0020.c
@@ -27,7 +27,6 @@
#include plat/board.h
#include plat/common.h
#include plat/gpmc.h
-#include plat/mux.h
#include plat/usb.h
#include mux.h
diff --git a/arch/arm/mach-omap2/board-omap3beagle.c
b/arch/arm/mach-omap2/board-omap3beagle.c
index 9e606b1..6ada802 100644
--- a/arch/arm/mach-omap2/board-omap3beagle.c
+++ b/arch/arm/mach-omap2/board-omap3beagle.c
@@ -41,7 +41,6 @@
#include plat/common.h
#include plat/gpmc.h
#include plat/nand.h
-#include plat/mux.h
#include plat/usb.h
#include plat/timer-gp.h
diff --git a/arch/arm/mach-omap2/board-omap3evm.c
b/arch/arm/mach-omap2/board-omap3evm.c
index 0457f61..18913e9 100644
--- a/arch/arm/mach-omap2/board-omap3evm.c
+++ b/arch/arm/mach-omap2/board-omap3evm.c
@@ -38,7 +38,6 @@
#include asm/mach/map.h
#include plat/board.h
-#include plat/mux.h
#include plat/usb.h
#include plat/common.h
#include plat/mcspi.h
diff --git a/arch/arm/mach-omap2/board-omap3pandora.c
b/arch/arm/mach-omap2/board-omap3pandora.c
index bca5ad9..c1cc99c 100644
--- a/arch/arm/mach-omap2/board-omap3pandora.c
+++ b/arch/arm/mach-omap2/board-omap3pandora.c
@@ -40,7 +40,6 @@
#include mach/hardware.h
#include plat/mcspi.h
#include plat/usb.h
-#include plat/mux.h
#include mux.h
#include sdram-micron-mt46h32m32lf-6.h
diff --git a/arch/arm/mach-omap2/board-overo.c
b/arch/arm/mach-omap2/board-overo.c
index 1ebde4c..5b78a87 100644
--- a/arch/arm/mach-omap2/board-overo.c
+++ b/arch/arm/mach-omap2/board-overo.c
@@ -44,7 +44,6 @@
#include plat/gpmc.h
#include mach/hardware.h
#include plat/nand.h
-#include plat/mux.h
#include plat/usb.h
#include mux.h
diff --git a/arch/arm/mach-omap2/board-rx51.c b/arch/arm/mach-omap2/board-rx51.c
index fd71c00..67bb347 100644
--- a/arch/arm/mach-omap2/board-rx51.c
+++ b/arch/arm/mach-omap2/board-rx51.c
@@ -23,7 +23,6 @@
#include asm/mach/map.h
#include plat/mcspi.h
-#include plat/mux.h
#include plat/board.h
#include plat/common.h
#include plat/dma.h
diff --git a/arch/arm/mach-omap2/io.c b/arch/arm/mach-omap2/io.c
index 6a4d8e4..b632ea0 100644
--- a/arch/arm/mach-omap2/io.c
+++ b/arch/arm/mach-omap2/io.c
@@ -34,6 +34,7 @@
#include plat/gpmc.h
#include plat/serial.h
#include plat/vram.h
+#include plat/mux.h
#ifndef CONFIG_ARCH_OMAP4 /* FIXME: Remove this once clkdev is ready */
#include clock.h
diff --git a/arch/arm/mach-omap2/mux.c b/arch/arm/mach-omap2/mux.c
index d968433..e071b3f 100644
--- a/arch/arm/mach-omap2/mux.c
+++ b/arch/arm/mach-omap2/mux.c
@@ -67,13 +67,12 @@ static inline void omap_mux_write(u16 val, u16 reg)
__raw_writew(val, mux_base + reg);
}
-#ifdef CONFIG_OMAP_MUX
+#if defined(CONFIG_ARCH_OMAP24XX) defined(CONFIG_OMAP_MUX)
static struct omap_mux_cfg arch_mux_cfg;
/* NOTE: See mux.h for the enumeration */
-#ifdef CONFIG_ARCH_OMAP24XX
static struct pin_config __initdata_or_module omap24xx_pins[] = {
/*
* description mux mux pullpulldebug
@@ -283,333 +282,8 @@ MUX_CFG_24XX(AF19_2430_GPIO_85, 0x0113, 3, 0,
0, 1)
#define OMAP24XX_PINS_SZ ARRAY_SIZE(omap24xx_pins)
-#else
-#define omap24xx_pins NULL
-#define OMAP24XX_PINS_SZ 0
-#endif /* CONFIG_ARCH_OMAP24XX */
-
-#ifdef CONFIG_ARCH_OMAP34XX
-static struct pin_config __initdata_or_module omap34xx_pins[] = {
-/*
- *
[PATCH 9/9] omap: mux: Add 36xx CBP package support
Add 36xx CBP package support
Cc: Benoit Cousson b-cous...@ti.com
Signed-off-by: Paul Walmsley p...@pwsan.com
Signed-off-by: Tony Lindgren t...@atomide.com
---
arch/arm/mach-omap2/Kconfig |5
arch/arm/mach-omap2/board-3630sdp.c |9 +
arch/arm/mach-omap2/board-zoom3.c | 10 +
arch/arm/mach-omap2/mux.h |1
arch/arm/mach-omap2/mux34xx.c | 520 +++
arch/arm/mach-omap2/mux34xx.h | 42 +++
6 files changed, 587 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-omap2/Kconfig b/arch/arm/mach-omap2/Kconfig
index c10789c..5a61b74 100644
--- a/arch/arm/mach-omap2/Kconfig
+++ b/arch/arm/mach-omap2/Kconfig
@@ -33,6 +33,9 @@ config OMAP_PACKAGE_CBB
config OMAP_PACKAGE_CUS
bool
+config OMAP_PACKAGE_CBP
+ bool
+
comment OMAP Board Type
depends on ARCH_OMAP2 || ARCH_OMAP3 || ARCH_OMAP4
@@ -121,6 +124,7 @@ config MACH_OMAP_ZOOM2
config MACH_OMAP_ZOOM3
bool OMAP3630 Zoom3 board
depends on ARCH_OMAP3 ARCH_OMAP34XX
+ select OMAP_PACKAGE_CBP
config MACH_CM_T35
bool CompuLab CM-T35 module
@@ -135,6 +139,7 @@ config MACH_IGEP0020
config MACH_OMAP_3630SDP
bool OMAP3630 SDP board
depends on ARCH_OMAP3 ARCH_OMAP34XX
+ select OMAP_PACKAGE_CBP
config MACH_OMAP_4430SDP
bool OMAP 4430 SDP board
diff --git a/arch/arm/mach-omap2/board-3630sdp.c
b/arch/arm/mach-omap2/board-3630sdp.c
index e6cbc27..7390596 100755
--- a/arch/arm/mach-omap2/board-3630sdp.c
+++ b/arch/arm/mach-omap2/board-3630sdp.c
@@ -85,8 +85,17 @@ static void __init omap_sdp_init_irq(void)
omap_gpio_init();
}
+#ifdef CONFIG_OMAP_MUX
+static struct omap_board_mux board_mux[] __initdata = {
+ { .reg_offset = OMAP_MUX_TERMINATOR },
+};
+#else
+#define board_mux NULL
+#endif
+
static void __init omap_sdp_init(void)
{
+ omap3_mux_init(board_mux, OMAP_PACKAGE_CBP);
zoom_peripherals_init();
board_smc91x_init();
enable_board_wakeup_source();
diff --git a/arch/arm/mach-omap2/board-zoom3.c
b/arch/arm/mach-omap2/board-zoom3.c
index 8d965a6..a9fe918 100644
--- a/arch/arm/mach-omap2/board-zoom3.c
+++ b/arch/arm/mach-omap2/board-zoom3.c
@@ -21,6 +21,7 @@
#include plat/common.h
#include plat/board.h
+#include mux.h
#include sdram-hynix-h8mbx00u0mer-0em.h
static void __init omap_zoom_map_io(void)
@@ -42,8 +43,17 @@ static void __init omap_zoom_init_irq(void)
omap_gpio_init();
}
+#ifdef CONFIG_OMAP_MUX
+static struct omap_board_mux board_mux[] __initdata = {
+ { .reg_offset = OMAP_MUX_TERMINATOR },
+};
+#else
+#define board_mux NULL
+#endif
+
static void __init omap_zoom_init(void)
{
+ omap3_mux_init(board_mux, OMAP_PACKAGE_CBP);
zoom_peripherals_init();
zoom_debugboard_init();
}
diff --git a/arch/arm/mach-omap2/mux.h b/arch/arm/mach-omap2/mux.h
index a6bd58f..d8b4d5a 100644
--- a/arch/arm/mach-omap2/mux.h
+++ b/arch/arm/mach-omap2/mux.h
@@ -56,6 +56,7 @@
/* Flags for omap_mux_init */
#define OMAP_PACKAGE_MASK 0x
+#define OMAP_PACKAGE_CBP 4 /* 515-pin 0.40 0.50 */
#define OMAP_PACKAGE_CUS 3 /* 423-pin 0.65 */
#define OMAP_PACKAGE_CBB 2 /* 515-pin 0.40 0.50 */
#define OMAP_PACKAGE_CBC 1 /* 515-pin 0.50 0.65 */
diff --git a/arch/arm/mach-omap2/mux34xx.c b/arch/arm/mach-omap2/mux34xx.c
index 116d5b2..68e0a59 100644
--- a/arch/arm/mach-omap2/mux34xx.c
+++ b/arch/arm/mach-omap2/mux34xx.c
@@ -1549,6 +1549,522 @@ struct omap_ball __initdata omap3_cbb_ball[] = {
#define omap3_cbb_ball NULL
#endif
+/*
+ * Signals different on 36XX CBP package comapared to 34XX CBC package
+ */
+#if defined(CONFIG_OMAP_MUX) defined(CONFIG_OMAP_PACKAGE_CBP)
+struct omap_mux __initdata omap36xx_cbp_subset[] = {
+ _OMAP3_MUXENTRY(CAM_D0, 99,
+ cam_d0, NULL, csi2_dx2, NULL,
+ gpio_99, NULL, NULL, safe_mode),
+ _OMAP3_MUXENTRY(CAM_D1, 100,
+ cam_d1, NULL, csi2_dy2, NULL,
+ gpio_100, NULL, NULL, safe_mode),
+ _OMAP3_MUXENTRY(CAM_D10, 109,
+ cam_d10, ssi2_wake, NULL, NULL,
+ gpio_109, hw_dbg8, NULL, safe_mode),
+ _OMAP3_MUXENTRY(CAM_D2, 101,
+ cam_d2, ssi2_rdy_tx, NULL, NULL,
+ gpio_101, hw_dbg4, NULL, safe_mode),
+ _OMAP3_MUXENTRY(CAM_D3, 102,
+ cam_d3, ssi2_dat_rx, NULL, NULL,
+ gpio_102, hw_dbg5, NULL, safe_mode),
+ _OMAP3_MUXENTRY(CAM_D4, 103,
+ cam_d4, ssi2_flag_rx, NULL, NULL,
+ gpio_103, hw_dbg6, NULL, safe_mode),
+ _OMAP3_MUXENTRY(CAM_D5, 104,
+ cam_d5, ssi2_rdy_rx, NULL, NULL,
+ gpio_104, hw_dbg7, NULL, safe_mode),
+ _OMAP3_MUXENTRY(CAM_HS, 94,
+ cam_hs, ssi2_dat_tx, NULL, NULL,
+ gpio_94, hw_dbg0, NULL,
[APPLIED] [PATCH v3] arm: omap: Add omap3_defconfig
This patch has been applied to the linux-omap by youw fwiendly patch wobot. Branch in linux-omap: for-next Initial commit ID (Likely to change): 9a01609e1885b827b979d6d9dd86f43208a9e5fc PatchWorks http://patchwork.kernel.org/patch/64031/ Git (Likely to change, and takes a while to get mirrored) http://git.kernel.org/?p=linux/kernel/git/tmlind/linux-omap-2.6.git;a=commit;h=9a01609e1885b827b979d6d9dd86f43208a9e5fc -- 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: Preventing OMAP3 serial driver to take control of all UARTs
* Grant Likely grant.lik...@secretlab.ca [091202 09:24]: On Wed, Dec 2, 2009 at 9:16 AM, Olof Johansson o...@lixom.net wrote: On Wed, Dec 02, 2009 at 09:04:49AM -0700, Grant Likely wrote: Ah, you're talking about pin muxing configuration, right? Yes, that GPIO binding deals with controllers, not pin mux. Pin mux is very much an SoC specific thing that isn't mapped easily to a generic binding. Yep. On the 5200, I haven't attempted to describe pin-mux in the device tree at all, and have either expected firmware to set it up correctly, or fixed it up in the platform code. Yeah. And it's one of the things Tony commented on that firmware tends to get wrong, seems like people aren't doing complete mux configs in u-boot, etc. So, if it needs to be fixed up in platform code, there will (likely) be need for board-specific code there anyway. A bummer, since the device tree would otherwise make it real easy to bring up new boards without kernel code changes. I didn't create a binding on the 5200 because I actually see very little buggy firmware in that regard (partially because I kept telling people to go fix their firmware). :-) If it ends up being the norm that the kernel has to fix it for a given SoC, then I would create an SoC-specific binding for pin mux configuration in the device tree so that some degree of common code can still fix it up. It should be feasible for board-specific code to be the exception, not the rule. The problem with pin multiplexing is that development boards such as Beagle don't know the desired configuration in the bootloader. There are pins available for connecting external hardware, such as I2C, SPI, or whatever to the 16-bit GPMC bus. Also, the bootloaders tend not to care about pin multiplexing for power management. We now have kernel cmdline override for pin multiplexing, but that does not help with adding platform_data for custom I2C or SPI devices. Just something to keep in mind, I still think we can benefit from the open firmware support in various ways :) 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: Preventing OMAP3 serial driver to take control of all UARTs
* Grant Likely grant.lik...@secretlab.ca [091202 07:06]: On Mon, Nov 30, 2009 at 12:40 PM, Tony Lindgren t...@atomide.com wrote: * Grant Likely grant.lik...@secretlab.ca [091130 09:01]: snip maybe you've already thought through all this.. But would it be possible to do lightweight device tree that we just use to populate the platform data? This is completely possible. Just having the device tree available doesn't force the kernel to use it for everything. I've found it useful to start small and add things as I need them. Most important thing to remember is to follow the documented established device tree conventions so that common code can understand it. OK, sounds good to me. 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: SR1: VDD autocomp is not active
Premi, Sanjeev said the following on 12/02/2009 04:23 PM: -Original Message- From: Sergey Lapin [mailto:slapi...@gmail.com] Sent: Wednesday, December 02, 2009 7:04 PM To: Premi, Sanjeev Cc: linux-omap@vger.kernel.org Subject: Re: SR1: VDD autocomp is not active [sp] The code will allow you to do so; but without right values kernel execution can go haywire. Actually the entire silicon can go haywire due to bad voltages. :( yep kernel can go crazy as a result.. Is it possible somehow to identify right silicon revision before ordering? I mean by part number or something? Sorry for my ignorance, I've found answer on first question (answer is to read errata properly). Also, is there some safe numbers somebody knows about, or is there some way of generating them? I still persist with this question, though. [sp] These numbers are based on silicon characterization process. There is no other way to generate them. The numbers can change between silicon lots. Actually can change even between silicons themselves. This is part of EFUSE values which we write on to each of the silicon. If the chip does not have SR NVALUES EFUSED, two options: a) Get a new chip which has SR enabled (or a platform such as zoom2 with 3430 ES3.1 silicon) b) Disable smartreflex :( Regards, Nishanth Menon PS: NOT recommended: you could choose to play around with my original patch for SR http://marc.info/?l=linux-omapm=125623250803526w=2 esp looking at the script involved. but I would not recommend to use it on a production system. -- 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: Preventing OMAP3 serial driver to take control of all UARTs
On Thu, Dec 03, 2009 at 02:00:52AM +0100, ext Tony Lindgren wrote: * Grant Likely grant.lik...@secretlab.ca [091202 07:06]: On Mon, Nov 30, 2009 at 12:40 PM, Tony Lindgren t...@atomide.com wrote: * Grant Likely grant.lik...@secretlab.ca [091130 09:01]: snip maybe you've already thought through all this.. But would it be possible to do lightweight device tree that we just use to populate the platform data? This is completely possible. Just having the device tree available doesn't force the kernel to use it for everything. I've found it useful to start small and add things as I need them. Most important thing to remember is to follow the documented established device tree conventions so that common code can understand it. OK, sounds good to me. Hi, This device tree stuff sounds like very cool way of doing things. Hope it is ready soon :) Meanwhile, would it be OK to implement something to get the serial driver taking control of the all the UARTs? Any comments on adding new function to mach-omap2/serial.c: omap_serial_init_port(int port) that could be used from board files instead of omap_serial_init()? Thanks, MW -- 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 v3 0/4] OMAP: McBSP: Use register cache
On Tue, 1 Dec 2009 04:10:07 +0100 Janusz Krzysztofik jkrzy...@tis.icnet.pl wrote: Change the way McBSP registers are maintained: store values written to the device in a cache in order to make use of those cached values when convenient. This could help for developing the McBSP context save/restore features, as well as solve the problem of possible register corruption experienced on OMAP1510 based Amstrad Delta board, at least. Janusz Krzysztofik (4): OMAP: McBSP: Use macros for all register read/write operations OMAP: McBSP: Prepare register read/write macros API for caching OMAP: McBSP: Introduce caching in register write operations OMAP: McBSP: Use cache when modifying individual register bits arch/arm/plat-omap/include/plat/mcbsp.h |5 arch/arm/plat-omap/mcbsp.c | 397 --- 2 files changed, 198 insertions(+), 204 deletions(-) Looks good to me and audio works fine with the Beagle. One minor comment to the patch 3. -- Jarkko -- 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 v3 3/4] OMAP: McBSP: Introduce caching in register write operations
On Tue, 1 Dec 2009 04:15:50 +0100 Janusz Krzysztofik jkrzy...@tis.icnet.pl wrote: #define MCBSP_WRITE(mcbsp, reg, val) \ - omap_mcbsp_write(mcbsp-io_base, OMAP_MCBSP_REG_##reg, val) + omap_mcbsp_write(mcbsp-io_base, OMAP_MCBSP_REG_##reg, \ + mcbsp-reg_cache[OMAP_MCBSP_REG_##reg / OMAP_MCBSP_REG_DRR1] \ + = val) +#define MCBSP_READ_CACHE(mcbsp, reg) \ + (mcbsp-reg_cache[OMAP_MCBSP_REG_##reg / OMAP_MCBSP_REG_DRR1]) These divisions by DDR1 are confusing. Use rather sizeof: reg_cache[OMAP_MCBSP_REG_##reg / sizeof(*mcbsp-reg_cache)] -- Jarkko -- 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
