RE: Requirement for DSI video mode support
Hi, Tomi Valkeinen wrote: Hi, On Mon, 2010-09-20 at 22:18 +0200, ext Jorge Bustamante wrote: Hi, We (TI) have been working on a DSI video mode driver for OMAP4 and I I hope it's also for OMAP3? am aware that other people are working with similar drivers. We had to tweak the code to make the drivers work with current code but we would like to make it the correct way, that is, introducing a proper functionality instead of inserting tweaks in the present command mode driver. Therefore, there is an initiative from us to modify current dss/dsi code to support DSI video mode. We have collected a list of requirements and ideas (with the help of ppl copied) from our experience working with these drivers, but it would be great if you can discuss/comment further on this. Requirements: - A better way of exposing VC's to a panel driver, since most panels use more than one VC. Currently the design supports only one per panel. Perhaps a VC resource pool could be created. Hmm, why would most panels use more than one VC? I haven't seen a single one =). Command mode panels will work fine with a single VC, I don't think video mode can run by using only one VC. Also, for command mode, there isn't a restriction to use a single VC. If you configure one VC to have slave port as source and the other as video port, the need to switch the VC source between L4 and VP would go away. The most optimal way would be to use one VC for each peripheral, but I don't think the usecase of connecting 4 panels to the same DSI lanes would ever be needed. Nevertheless, it should be possible to use multiple VCs in one driver. I've implemented a driver for a buffer chip that used all 4 channels. So did you connect more than one panel to DSI? I am curious about how it works [snip] - If we want a user to switch between modes, we may need to have a While I don't see any reason to forbid changing modes, I don't see any real reason to implement switching between the modes either. If it comes for free, sure, but if it means lots of implementation, I'd rather leave it out. Or do you have some use cases where switching modes is important? There isn't any use case where we would use a panel for video mode and command mode at different points in time. But if the panel supports both video and command mode there should be some option (compile time/ boot time) to choose which mode is to be used. I guess its more for the sake of completeness of the panels capabilities. Regards, Archit -- 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: Requirement for DSI video mode support
On Wed, 2010-10-27 at 08:34 +0200, ext Taneja, Archit wrote: Hi, Tomi Valkeinen wrote: Hi, On Mon, 2010-09-20 at 22:18 +0200, ext Jorge Bustamante wrote: Hi, We (TI) have been working on a DSI video mode driver for OMAP4 and I I hope it's also for OMAP3? am aware that other people are working with similar drivers. We had to tweak the code to make the drivers work with current code but we would like to make it the correct way, that is, introducing a proper functionality instead of inserting tweaks in the present command mode driver. Therefore, there is an initiative from us to modify current dss/dsi code to support DSI video mode. We have collected a list of requirements and ideas (with the help of ppl copied) from our experience working with these drivers, but it would be great if you can discuss/comment further on this. Requirements: - A better way of exposing VC's to a panel driver, since most panels use more than one VC. Currently the design supports only one per panel. Perhaps a VC resource pool could be created. Hmm, why would most panels use more than one VC? I haven't seen a single one =). Command mode panels will work fine with a single VC, I don't think video mode can run by using only one VC. Okay, I think we're talking about different VCs =). It's rather confusing in the TRM. A VC (in DSI packet sense) refers to the channel ID sent in the packet, and a VC (in OMAP DSS register sense) refers to a set of configurations used to send DSI packets. I think we need to come up with terms that clearly make the distinction between these, because they really don't have anything in common. (I'd like to hear the rationale for naming OMAP's config registers as VCs... =). Also, for command mode, there isn't a restriction to use a single VC. If you configure one VC to have slave port as source and the other as video port, the need to switch the VC source between L4 and VP would go away. This was what I had at some point. However, I was unsure how transmissions are synchronized in that case. If there's transmission going on from VP via, say, VC0, and I send a message from L4 via VC1, what happens? Does VC1 wait until VC0 is done? Or does it send the packet between VC0's packets? But I agree, different VCs for L4 and VP usage would make some things a bit simpler. The most optimal way would be to use one VC for each peripheral, but I don't think the usecase of connecting 4 panels to the same DSI lanes would ever be needed. Yes, that is quite unlikely. But it's difficult to say what kind of devices one needs to connect (see below), but it could be that we may come up with some kind of rules that fit to all cases. For example, is there ever need to have to OMAP VCs configured as VP at the same time? If not, we know that there will always be 3 OMAP VCs free for L4 use. Etc. (I didn't think this really, just throwing ideas =). Nevertheless, it should be possible to use multiple VCs in one driver. I've implemented a driver for a buffer chip that used all 4 channels. So did you connect more than one panel to DSI? I am curious about how it works The chip had it's own framebuffer memory, and you could connect two displays to the chip. The virtual channel mapping was something like this: 0 - routed to first panel 1 - routed to second panel 2 - buffer chip config 3 - buffer chip framebuffer config [snip] - If we want a user to switch between modes, we may need to have a While I don't see any reason to forbid changing modes, I don't see any real reason to implement switching between the modes either. If it comes for free, sure, but if it means lots of implementation, I'd rather leave it out. Or do you have some use cases where switching modes is important? There isn't any use case where we would use a panel for video mode and command mode at different points in time. But if the panel supports both video and command mode there should be some option (compile time/ boot time) to choose which mode is to be used. I guess its more for the sake of completeness of the panels capabilities. I agree. Tomi -- 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 4/5] omap: mailbox: fix detection for previously supported chips
On Wed, Oct 27, 2010 at 8:06 AM, Varadarajan, Charulatha ch...@ti.com wrote:
Fix the mailbox detection for OMAP3630 and 2430, also minor
cleanup on conditional ifdef's that could affect it.
Given that 2430 has an iva too include it, as the same steps
for omap3 apply.
Signed-off-by: Omar Ramirez Luna omar.rami...@ti.com
---
arch/arm/mach-omap2/mailbox.c | 16 ++--
1 files changed, 10 insertions(+), 6 deletions(-)
diff --git a/arch/arm/mach-omap2/mailbox.c
b/arch/arm/mach-omap2/mailbox.c
index 61f2149..b8fd120 100644
--- a/arch/arm/mach-omap2/mailbox.c
+++ b/arch/arm/mach-omap2/mailbox.c
@@ -277,7 +277,7 @@ static struct omap_mbox_ops omap2_mbox_ops = {
/* FIXME: the following structs should be filled
automatically by the user id */
-#if defined(CONFIG_ARCH_OMAP3430) || defined(CONFIG_ARCH_OMAP2420)
+#if defined(CONFIG_ARCH_OMAP3) || defined(CONFIG_ARCH_OMAP2)
/* DSP */
static struct omap_mbox2_priv omap2_mbox_dsp_priv = {
.tx_fifo = {
@@ -302,7 +302,7 @@ struct omap_mbox mbox_dsp_info = {
};
#endif
-#if defined(CONFIG_ARCH_OMAP3430)
+#if defined(CONFIG_ARCH_OMAP3)
struct omap_mbox *omap3_mboxes[] = { mbox_dsp_info, NULL };
#endif
@@ -390,15 +390,19 @@ static int __devinit
omap2_mbox_probe(struct platform_device *pdev)
if (false)
;
-#if defined(CONFIG_ARCH_OMAP3430)
- else if (cpu_is_omap3430()) {
+#if defined(CONFIG_ARCH_OMAP3)
+ else if (cpu_is_omap34xx()) {
Use cpu_is_* check only. No need to have #if CONFIG_ARCH_* checks.
Some people conditionally compile only for one architecture, like in
consumer devices. There's no point in wasting space for that.
--
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: [PATCH v3 5/5] OMAP: I2C: Convert i2c driver to use PM runtime api's
On Thu, Oct 07, 2010 at 10:37:03AM -0700, Kevin Hilman wrote: Ben Dooks ben-...@fluff.org writes: [...] As such, I should really go and read up all about this new runtime-pm and hwmod stuff before further commentign on the changes. ping From the drivers perspective, you don't neet to know anything about omap_hwmod. You can think of this change as simply using the runtime PM API instead of the clock API for enabling and idling the device. With your ack (on this patch only) we'd like to merge this along with the rest of the series for 2.6.37. Acked-by: Ben Dooks ben-li...@fluff.org please post via your tree. -- Ben Q: What's a light-year? A: One-third less calories than a regular year. -- 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: Requirement for DSI video mode support
Hi, Command mode panels will work fine with a single VC, I don't think video mode can run by using only one VC. Okay, I think we're talking about different VCs =). It's rather confusing in the TRM. A VC (in DSI packet sense) refers to the channel ID sent in the packet, and a VC (in OMAP DSS register sense) refers to a set of configurations used to send DSI packets. I think we need to come up with terms that clearly make the distinction between these, because they really don't have anything in common. (I'd like to hear the rationale for naming OMAP's config registers as VCs... =). Yeah, it took me a while to figure out the difference from the TRM too. As far as the driver is concerned, I think there was a dest_per member for each set of VC configurations, that really made things clear. Its not in the present kernel, but it would be nice to get it back. The present approach always correlates VC0 configuration to VC_ID 0, 1 to 1 and so on. That confused me for a while again :| Also, for command mode, there isn't a restriction to use a single VC. If you configure one VC to have slave port as source and the other as video port, the need to switch the VC source between L4 and VP would go away. This was what I had at some point. However, I was unsure how transmissions are synchronized in that case. If there's transmission going on from VP via, say, VC0, and I send a message from L4 via VC1, what happens? Does VC1 wait until VC0 is done? Or does it send the packet between VC0's packets? I don't know how things works internally, but I am sure the 2 VC configuration works for a handful of phones :) Is this a thing that should be explained in the DSI specification, or is this something that should be taken care of while implementing DSI hardware? I'll try to find out. But I agree, different VCs for L4 and VP usage would make some things a bit simpler. The most optimal way would be to use one VC for each peripheral, but I don't think the usecase of connecting 4 panels to the same DSI lanes would ever be needed. Yes, that is quite unlikely. But it's difficult to say what kind of devices one needs to connect (see below), but it could be that we may come up with some kind of rules that fit to all cases. For example, is there ever need to have to OMAP VCs configured as VP at the same time? If not, we know that there will always be 3 OMAP VCs free for L4 use. Etc. (I didn't think this really, just throwing ideas =). Yes it would be good to more of such rules. I don't think the one above is valid for OMAP4 though. One of the DSI blocks has 2 video ports as input. One VC can be configured in Video mode + Video Port and the other can be Command mode + Video port, and command mode and video port can run together. We haven't tried it out yet (and don't want to either :)) Nevertheless, it should be possible to use multiple VCs in one driver. I've implemented a driver for a buffer chip that used all 4 channels. So did you connect more than one panel to DSI? I am curious about how it works The chip had it's own framebuffer memory, and you could connect two displays to the chip. The virtual channel mapping was something like this: 0 - routed to first panel 1 - routed to second panel 2 - buffer chip config 3 - buffer chip framebuffer config That's interesting, slightly out of topic question: How would a buffer chip / LVDS bridge chip fit in the DSS2 fw. Should it be in the panel driver or have its own driver? Asking out of curiosity. Regards, Archit-- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/8] staging: tidspbridge - remove req_addr from proc_map
On Tue, Oct 26, 2010 at 11:39 PM, Guzman Lugo, Fernando
fernando.l...@ti.com wrote:
fernando.l...@ti.com wrote:
fernando.l...@ti.com wrote:
On Tue, Oct 26, 2010 at 3:51 AM, Fernando Guzman Lugo
x0095...@ti.com wrote:
The device address is assigned by tidspbridge no need for
that parameter anymore.
Signed-off-by: Fernando Guzman Lugo x0095...@ti.com
This would break the API with user-space, right?
Yes, user-space needs to be changed accordingly.
Wouldn't it make sense to avoid stuffing so many changes at once
including ABI breakage?
Does user-space really _needs_ to be changed? Can't you
just ignore
that argument?
Actually, I had a previous version of that patch where I
only Ignored
that paramteter. But after thinking again and seeing How
the long time
ago depreacted function are still there I Removed the parameter in
order to force apps to make the change.
Again, can we concentrate on first getting this thing to work?
If to make it work for 37 the iommu migration patch will be revert
These set of patches will have to wait until the patches are merged
Again. So the dspbridge would be fix first a then the patches would
Be merged.
I couldn't parse this correctly, but yes, I think.
We can think on breaking things again later.
You can ignore that argument at API level, so all users of
the API not
need to have change (in that momment). That should be Only few line
change.
Yes, that's what I'm proposing.
I meant userspace api or library level:
Example:
Dsp_proc_map(proc, mpu_addr, req_addr, *dsp_addr, attr) {
...
struct proc_map args = {
.map_addr = mpu_addr;
/* ignore req_addr */
.dsp_addr = dsp_addr;
.attr = attr;
}
ret = ioctl(handle, PROCMAP_CMD, args)
...
}
Yes, but this has to be done on every library/app that is using the dsp.
It's much easier to do it on kernel side.
Besides, at least on gst-dsp we want it to work for _all_ bridge
versions, so it would be:
@@ -829,7 +829,9 @@ struct map_mem {
void *proc_handle;
void *mpu_addr;
unsigned long size;
+#if DSP_API = 3
void *req_addr;
+#endif
void **ret_map_addr;
unsigned long attr;
};
@@ -838,7 +840,9 @@ bool dsp_map(int handle,
void *proc_handle,
void *mpu_addr,
unsigned long size,
void *req_addr,
void *ret_map_addr,
unsigned long attr)
{
@@ -846,7 +850,9 @@ bool dsp_map(int handle,
.proc_handle = proc_handle,
.mpu_addr = mpu_addr,
.size = size,
+#if DSP_API = 3
.req_addr = req_addr,
+#endif
.ret_map_addr = ret_map_addr,
.attr = attr,
};
But then if we are breaking the API already, wouldn't it make sense to
use the DMA direction too? (probably on the 'attr' field)
That's why it's a good idea to discuss API breakage, and not do it
willi-nillii. Otherwise we would have #if DSP_API = 4, and so on.
But it's a bit pointless to be discussing about this at this point
while people are still struggling to get this working and don't know
which branch to use.
Look, you sent patches that broke the bridge (even after manually
applying all the dependency patches), since Omar wasn't there as
gatekeeper and Greg immediately merge them we now have a bridge that
is further broken. And now you want to break it even more arguing that
you want to force people to use the new API, but how do you expect
people to migrate to this new API if they can't even run this?
Besides, if you want to break API you should at least mention that
clearly in the patch.
I think this change should be delayed, preferably
after we have
a working tidspbridge.
The issue you were seeing must be fixed with patch 2/8, and
Having all
the dependencies tidspbridge has to be working Properly.
Yes, which might not happen at .37. If we revert the
iommu stuff, we
might have a chance at having a working bridge on .37.
But havi that merged in tidspbridge make more pressure to
merged The
dependencies, if not maybe that wont have event for .38.
Those patches have been there for a while and there's no sign
of when they'll be merged. Also, remember that the fact that
the patches have been sent doesn't guarantee they would be on
this, or even the next cycle.
Besides, the rule followed here is: it's ready when it's
ready. In the meantime the driver should work, and we can do
that rather easily.
I don't have much experience in this kind of situacion if it is
believed it is the best solution then ok for me.
But That is just my opinion if you all are agree revert is the best
Option I am ok, but I looks like more work reverting and rebaseing
specially because it is a big change.
git makes this easy.
Till we
How to add an expansion board on IGEP v2 board.
Hello all, I would ask some technical questions, maybe someone can help me. I would add support for a new expansion board for IGEP v2 board, The expansion board comes with a EEPROM, the EEPROM is used to identify the expansion board, my idea is create a new file for expansion board ( board-igep0020-expansion.c ) and * on board-igep0020.c - Add extern void __init igep2_expansion_init(void); - Call igep2_expansion_init on igep2_init() * on board-igep0020-expansion.c - Create igep2_expansion_init, inside this funciton - Add e2prom device and read board id - If board ID exists then init all expansion devices I'm in the right way ? Comments ? Thanks in advance, Enric -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 4/5] omap: mailbox: fix detection for previously supported chips
On Wed, Oct 27, 2010 at 10:28 AM, Felipe Contreras felipe.contre...@gmail.com wrote: On Wed, Oct 27, 2010 at 8:06 AM, Varadarajan, Charulatha ch...@ti.com wrote: Use cpu_is_* check only. No need to have #if CONFIG_ARCH_* checks. Some people conditionally compile only for one architecture, like in consumer devices. There's no point in wasting space for that. And cpu_is_* calls become constants in such cases, allowing compiler to optimize away unneeded 'if' blocks, not to mention cpu_is_* allows multi-omap support. cpu_is_* is the way to go. -- 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] PERF(kernel): Cleanup power events V2
On Wednesday, October 27, 2010, Thomas Renninger wrote:
On Tuesday 26 October 2010 08:57:01 pm Rafael J. Wysocki wrote:
On Tuesday, October 26, 2010, Thomas Renninger wrote:
Ok, that's at least generic. Needs the review of Rafael, to determine
whether this state value is all we want to know when we enter suspend.
He already gave an acked-by on this generic one here:
Re: [PATCH 3/4] perf: add calls to suspend trace point
Oh now, that was on the X86 specific part which depends on this one.
One should expect that he's fine with the generic part as well then,
but I agree that he should definitely have a look at this and sign it off.
What patch exactly do you mean? I'm not quite sure from your comment above.
Eh, Jean's patch, sorry about that.
Needs a tiny change to use PWR_EVENT_EXIT instead of 0 with
my new patch series:
No problem with that as far as I'm concerned.
Thanks,
Rafael
Signed-off-by: Jean Pihet j-pi...@ti.com
CC: Thomas Renninger tr...@suse.de
Acked-by: Rafael J. Wysocki r...@sisk.pl
---
kernel/power/suspend.c |3 +++
1 files changed, 3 insertions(+), 0 deletions(-)
diff --git a/kernel/power/suspend.c b/kernel/power/suspend.c
index 7335952..10cad5c 100644
--- a/kernel/power/suspend.c
+++ b/kernel/power/suspend.c
@@ -22,6 +22,7 @@
#include linux/mm.h
#include linux/slab.h
#include linux/suspend.h
+#include trace/events/power.h
#include power.h
@@ -164,7 +165,9 @@ static int suspend_enter(suspend_state_t state)
error = sysdev_suspend(PMSG_SUSPEND);
if (!error) {
if (!suspend_test(TEST_CORE) pm_check_wakeup_events()) {
+ trace_machine_suspend(state);
error = suspend_ops-enter(state);
+ trace_machine_suspend(0);
events_check_enabled = false;
}
sysdev_resume();
--
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 4/5] omap: mailbox: fix detection for previously supported chips
On Wed, Oct 27, 2010 at 12:00 PM, Grazvydas Ignotas nota...@gmail.com wrote: On Wed, Oct 27, 2010 at 10:28 AM, Felipe Contreras felipe.contre...@gmail.com wrote: On Wed, Oct 27, 2010 at 8:06 AM, Varadarajan, Charulatha ch...@ti.com wrote: Use cpu_is_* check only. No need to have #if CONFIG_ARCH_* checks. Some people conditionally compile only for one architecture, like in consumer devices. There's no point in wasting space for that. And cpu_is_* calls become constants in such cases, allowing compiler to optimize away unneeded 'if' blocks, not to mention cpu_is_* allows multi-omap support. cpu_is_* is the way to go. The problem is not the cpu_is_* calls, the problem is what is inside them (e.g. omap3_mboxes). If CONFIG_ARCH_OMAP3 is not defined, then compilation would be broken, unless you always include all the arrays. Multi-omap support is already there, because it means CONFIG_ARCH_OMAP3, CONFIG_ARCH_OMAP2, etc. -- 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
[Question] which type of DMA taken by musb of beagle-xM(DM3730)?
Hi, I want to know which type of DMA is taken by musb of DM3730, INVENTRA_DMA, TI_CPPI_DMA or others? thanks, -- Lei Ming -- 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: [linux-pm] [PATCH] PERF(kernel): Cleanup power events V2
On Wednesday, October 27, 2010, Mathieu Desnoyers wrote:
* Rafael J. Wysocki (r...@sisk.pl) wrote:
On Tuesday, October 26, 2010, Mathieu Desnoyers wrote:
* Alan Stern (st...@rowland.harvard.edu) wrote:
On Tue, 26 Oct 2010, Mathieu Desnoyers wrote:
* Peter Zijlstra (pet...@infradead.org) wrote:
On Tue, 2010-10-26 at 11:56 -0500, Pierre Tardy wrote:
+ trace_runtime_pm_usage(dev,
atomic_read(dev-power.usage_count)+1);
atomic_inc(dev-power.usage_count);
That's terribly racy..
Looking at the original code, it looks racy even without considering
the
tracepoint:
int __pm_runtime_get(struct device *dev, bool sync)
{
int retval;
+ trace_runtime_pm_usage(dev,
atomic_read(dev-power.usage_count)+1);
atomic_inc(dev-power.usage_count);
retval = sync ? pm_runtime_resume(dev) :
pm_request_resume(dev);
There is no implied memory barrier after atomic_inc. So either all
these
inc/dec are protected with mutexes or spinlocks, in which case one
might wonder
why atomic operations are used at all, or it's a racy mess. (I vote
for the
second option)
I don't understand. What's the problem? The inc/dec are atomic
because they are not protected by spinlocks, but everything else is
(aside from the tracepoint, which is new).
kref should certainly be used there.
What for?
kref has the following get:
atomic_inc(kref-refcount);
smp_mb__after_atomic_inc();
What seems to be missing in __pm_runtime_get() and
pm_runtime_get_noresume() is
the memory barrier after the atomic increment. The atomic increment is
free to
be reordered into the following spinlock (within pm_request_resume or
pm_request
resume execution) because taking a spinlock only acts as a memory barrier
with
acquire semantic, not a full memory barrier.
So AFAIU, the failure scenario would be as follows (sorry for the 80+
columns):
initial conditions: usage_count = 1
CPU A CPU B
1) __pm_runtime_get() (sync = true)
2) atomic_inc(usage_count) (not committed to memory yet)
3) pm_runtime_resume()
4) spin_lock_irqsave(dev-power.lock, flags);
5) retval = __pm_request_resume(dev);
If sync = true this is
retval = __pm_runtime_resume(dev);
which drops and reacquires the spinlock.
Let's see. Upon entry in __pm_runtime_resume, the following condition holds
(remember, the initial condition is that usage_count == 1):
dev-power.runtime_status == RPM_ACTIVE
so retval is set to 1, which goto directly to out, without setting parent.
So there does not seem to be any spinlock reacquire on this path, or am I
misunderstanding how the runtime_status works ?
No, you're not I think, the above is correct. I was referring to the scenario
in which the device was RPM_SUSPENDED initially.
In the meantime it sets
-power.runtime_status so that __pm_runtime_idle() will fail if run at this
point.
runtime_status will be left at RPM_ACTIVE, which is the appropriate value
expected by __pm_runtime_idle.
6) (execute the body of __pm_request_resume and return)
7)
__pm_runtime_put() (sync = true)
8) if
(atomic_dec_and_test(dev-power.usage_count))
(still see
usage_count == 1 before decrement,
thus
decrement to 0)
9)
pm_runtime_idle()
10) spin_unlock_irqrestore(dev-power.lock, flags)
11)
spin_lock_irq(dev-power.lock);
12)retval =
__pm_runtime_idle(dev);
Moreover, __pm_runtime_idle() checks -power.usage_count under the spinlock,
so it will see it's been incremented in the meantime and it will back off.
This is a subtle but important point. Yes, my scenario seems to be dealt with
by
the extra usage_count check while the spinlock is held.
How about adding a comment under this atomic_inc() stating that the memory
barriers are implicitely dealt with by the following spinlock release and the
extra check while spinlock is held ?
Commenting memory barriers is important, but commenting why memory barriers
are
not needed due to a subtle corner-case looks even more important.
Well, given that this discussion is taking place at all, I admit that it would
be good to document this somehow. :-)
I'll take care of that.
(hrm, but more below
Add new omap_dss_device after dss_device_registration
Hello all, Can I add a new omap_dss_device after dss_device registration ? Something like add_new_omap_dss_device(lcd_device) or similar ? On IGEP v2 we register only igep2_dvi_device as dss_device, We want to add a new dss_device (igep2_lcd_device) after dss registration. Is it possible ? For example we want to do something like this : step 1: register IGEP v2 dss_devices (dvi) step 2: detect if IGEP expansion board is detected. step 3: if it's detected add new dss_devices (lcd) Thanks in advance, Enric -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/5] omap: mailbox: initial hwmod support for omap3
On Wed, Oct 27, 2010 at 12:07 AM, Varadarajan, Charulatha ch...@ti.com wrote: HWMOD support for omap3. Use hwmod. ok ... This patch series breaks OMAP4 support. indeed, I'll try to exercise a sanity use case with omap4 and its hwmod data OMAP2 support is broken with this patch and the same is fixed in the next patch. Hence patch 2 should be ordered before patch 1. Agree --- a/arch/arm/mach-omap2/mailbox.c +++ b/arch/arm/mach-omap2/mailbox.c @@ -15,6 +15,7 @@ #include linux/platform_device.h #include linux/io.h #include plat/mailbox.h +#include plat/omap_hwmod.h Is this required? I do not see this file using any hwmod info. might have been kept with the rebase, I'll check again 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: Requirement for DSI video mode support
On Wed, 2010-10-27 at 10:17 +0200, ext Taneja, Archit wrote: Hi, Command mode panels will work fine with a single VC, I don't think video mode can run by using only one VC. Okay, I think we're talking about different VCs =). It's rather confusing in the TRM. A VC (in DSI packet sense) refers to the channel ID sent in the packet, and a VC (in OMAP DSS register sense) refers to a set of configurations used to send DSI packets. I think we need to come up with terms that clearly make the distinction between these, because they really don't have anything in common. (I'd like to hear the rationale for naming OMAP's config registers as VCs... =). Yeah, it took me a while to figure out the difference from the TRM too. As far as the driver is concerned, I think there was a dest_per member for each set of VC configurations, that really made things clear. There was, yes. But that wasn't perfect either. You can use one OMAP VC register set to send packets to any peripheral by using different virtual channel ID. Its not in the present kernel, but it would be nice to get it back. The present approach always correlates VC0 configuration to VC_ID 0, 1 to 1 and so on. That confused me for a while again :| Also, for command mode, there isn't a restriction to use a single VC. If you configure one VC to have slave port as source and the other as video port, the need to switch the VC source between L4 and VP would go away. This was what I had at some point. However, I was unsure how transmissions are synchronized in that case. If there's transmission going on from VP via, say, VC0, and I send a message from L4 via VC1, what happens? Does VC1 wait until VC0 is done? Or does it send the packet between VC0's packets? I don't know how things works internally, but I am sure the 2 VC configuration works for a handful of phones :) Is this a thing that should be explained in the DSI specification, or is this something that should be taken care of while implementing DSI hardware? I'll try to find out. It's DSI implementation spesific. It's about how OMAP HW handles the transmissions. I would guess that multiple OMAP VCs can send packets at the same time (but one packet on the DSI lines at one time, of course). But I'm not sure. But I agree, different VCs for L4 and VP usage would make some things a bit simpler. The most optimal way would be to use one VC for each peripheral, but I don't think the usecase of connecting 4 panels to the same DSI lanes would ever be needed. Yes, that is quite unlikely. But it's difficult to say what kind of devices one needs to connect (see below), but it could be that we may come up with some kind of rules that fit to all cases. For example, is there ever need to have to OMAP VCs configured as VP at the same time? If not, we know that there will always be 3 OMAP VCs free for L4 use. Etc. (I didn't think this really, just throwing ideas =). Yes it would be good to more of such rules. I don't think the one above is valid for OMAP4 though. One of the DSI blocks has 2 video ports as input. One VC can be configured in Video mode + Video Port and the other can be Command mode + Video port, and command mode and video port can run together. We haven't tried it out yet (and don't want to either :)) Nevertheless, it should be possible to use multiple VCs in one driver. I've implemented a driver for a buffer chip that used all 4 channels. So did you connect more than one panel to DSI? I am curious about how it works The chip had it's own framebuffer memory, and you could connect two displays to the chip. The virtual channel mapping was something like this: 0 - routed to first panel 1 - routed to second panel 2 - buffer chip config 3 - buffer chip framebuffer config That's interesting, slightly out of topic question: How would a buffer chip / LVDS bridge chip fit in the DSS2 fw. Should it be in the panel driver or have its own driver? Asking out of curiosity. In a perfect world we would have separate panel drivers for the panels, and driver for the buffer chip. And they could be connected as you want. But my implementation was a combined buffer chip/panel driver, handling everything. The DSS architecture isn't flexible enough (yet =). Tomi -- 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: [linux-pm] [PATCH] PERF(kernel): Cleanup power events V2
* Rafael J. Wysocki (r...@sisk.pl) wrote:
On Wednesday, October 27, 2010, Mathieu Desnoyers wrote:
* Rafael J. Wysocki (r...@sisk.pl) wrote:
On Tuesday, October 26, 2010, Mathieu Desnoyers wrote:
* Alan Stern (st...@rowland.harvard.edu) wrote:
On Tue, 26 Oct 2010, Mathieu Desnoyers wrote:
* Peter Zijlstra (pet...@infradead.org) wrote:
On Tue, 2010-10-26 at 11:56 -0500, Pierre Tardy wrote:
+ trace_runtime_pm_usage(dev,
atomic_read(dev-power.usage_count)+1);
atomic_inc(dev-power.usage_count);
That's terribly racy..
Looking at the original code, it looks racy even without
considering the
tracepoint:
int __pm_runtime_get(struct device *dev, bool sync)
{
int retval;
+ trace_runtime_pm_usage(dev,
atomic_read(dev-power.usage_count)+1);
atomic_inc(dev-power.usage_count);
retval = sync ? pm_runtime_resume(dev) :
pm_request_resume(dev);
There is no implied memory barrier after atomic_inc. So either
all these
inc/dec are protected with mutexes or spinlocks, in which case one
might wonder
why atomic operations are used at all, or it's a racy mess. (I vote
for the
second option)
I don't understand. What's the problem? The inc/dec are atomic
because they are not protected by spinlocks, but everything else is
(aside from the tracepoint, which is new).
kref should certainly be used there.
What for?
kref has the following get:
atomic_inc(kref-refcount);
smp_mb__after_atomic_inc();
What seems to be missing in __pm_runtime_get() and
pm_runtime_get_noresume() is
the memory barrier after the atomic increment. The atomic increment is
free to
be reordered into the following spinlock (within pm_request_resume or
pm_request
resume execution) because taking a spinlock only acts as a memory
barrier with
acquire semantic, not a full memory barrier.
So AFAIU, the failure scenario would be as follows (sorry for the 80+
columns):
initial conditions: usage_count = 1
CPU A CPU B
1) __pm_runtime_get() (sync = true)
2) atomic_inc(usage_count) (not committed to memory yet)
3) pm_runtime_resume()
4) spin_lock_irqsave(dev-power.lock, flags);
5) retval = __pm_request_resume(dev);
If sync = true this is
retval = __pm_runtime_resume(dev);
which drops and reacquires the spinlock.
Let's see. Upon entry in __pm_runtime_resume, the following condition holds
(remember, the initial condition is that usage_count == 1):
dev-power.runtime_status == RPM_ACTIVE
so retval is set to 1, which goto directly to out, without setting
parent.
So there does not seem to be any spinlock reacquire on this path, or am I
misunderstanding how the runtime_status works ?
No, you're not I think, the above is correct. I was referring to the scenario
in which the device was RPM_SUSPENDED initially.
Good to know I'm not losing it. ;-)
In the meantime it sets
-power.runtime_status so that __pm_runtime_idle() will fail if run at
this
point.
runtime_status will be left at RPM_ACTIVE, which is the appropriate value
expected by __pm_runtime_idle.
6) (execute the body of __pm_request_resume and return)
7)
__pm_runtime_put() (sync = true)
8) if
(atomic_dec_and_test(dev-power.usage_count))
(still
see usage_count == 1 before decrement,
thus
decrement to 0)
9)
pm_runtime_idle()
10) spin_unlock_irqrestore(dev-power.lock, flags)
11)
spin_lock_irq(dev-power.lock);
12)retval =
__pm_runtime_idle(dev);
Moreover, __pm_runtime_idle() checks -power.usage_count under the
spinlock,
so it will see it's been incremented in the meantime and it will back off.
This is a subtle but important point. Yes, my scenario seems to be dealt
with by
the extra usage_count check while the spinlock is held.
How about adding a comment under this atomic_inc() stating that the memory
barriers are implicitely dealt with by the following spinlock release and
the
extra check while spinlock is held ?
Commenting memory barriers is important, but commenting why memory barriers
are
not needed due to a
RE: [PATCH v3 01/13] OMAP: DMA: Replace read/write macros with functions
-Original Message-
From: G, Manjunath Kondaiah
Sent: Tuesday, October 26, 2010 10:55 PM
[..]
[...]
diff --git a/arch/arm/plat-omap/dma.c
b/arch/arm/plat-omap/dma.c index
f5c5b8d..77241e2 100644
--- a/arch/arm/plat-omap/dma.c
+++ b/arch/arm/plat-omap/dma.c
@@ -40,6 +40,147 @@
[...]
+static u16 reg_map_omap2[] = {
+ [REVISION] = 0x00,
+ [GCR2] = 0x78,
+ [IRQSTATUS_L0] = 0x08,
+ [IRQSTATUS_L1] = 0x0c,
[..]
+ /* OMAP4 specific registers */
+ [CDP] = 0xd0,
+ [CNDP] = 0xd4,
+ [CCDN] = 0xd8,
+};
+
dumb question: any reason why a struct wont do?
struct reg_map_omap2 {
u16 revision;
...
...
}
This approach is as per i2c driver as suggested by kevin.
http://www.spinics.net/lists/linux-omap/msg36446.html
Thanks for pointing this out. I2c has what 18 registers while dma has over 40
registers :( patch 11 [1] now I understand this step - this merges
together at later patchset - it starts to make sense now. It becomes reg_map.
Thanks - looks like a good change in the eventual code.
[...]
+static inline void dma_write(u32 val, int reg, int lch) {
+ if (cpu_class_is_omap1()) {
+ if (reg OMAP1_CH_COMMON_START)
+ __raw_writew(val, dma_base +
+ (reg_map_omap1[reg] + 0x40 * lch));
+ else
+ __raw_writew(val, dma_base +
reg_map_omap1[reg]);
+ } else {
+ if (reg OMAP2_CH_COMMON_START)
+ __raw_writel(val, dma_base +
+ (reg_map_omap2[reg] + 0x60 * lch));
+ else
+ __raw_writel(val, dma_base +
reg_map_omap2[reg]);
+ }
+}
Eventual code looks like this:
62 static inline void dma_write(u32 val, int reg, int lch)
63 {
64 if (d-dev_caps IS_WORD_16) {
65 if (reg = CH_COMMON_START)
66 __raw_writew(val, dma_base +
67 (reg_map[reg] + 0x40 * lch));
68 else
69 __raw_writew(val, dma_base + reg_map[reg]);
70 } else {
71 if (reg CH_COMMON_START)
72 __raw_writel(val, dma_base +
73 (reg_map[reg] + 0x60 * lch));
74 else
75 __raw_writel(val, dma_base + reg_map[reg]);
76 }
77 }
I don't really see how inline will really help here!
+
+static inline u32 dma_read(int reg, int lch) {
+ u32 val;
+
+ if (cpu_class_is_omap1()) {
+ if (reg OMAP1_CH_COMMON_START)
+ val = __raw_readw(dma_base +
+ (reg_map_omap1[reg]
+ 0x40 * lch));
+ else
+ val = __raw_readw(dma_base +
reg_map_omap1[reg]);
+ } else {
+ if (reg OMAP2_CH_COMMON_START)
+ val = __raw_readl(dma_base +
+ (reg_map_omap2[reg]
+ 0x60 * lch));
+ else
+ val = __raw_readl(dma_base +
reg_map_omap2[reg]);
+ }
+ return val;
+}
What is the benefit of using inline function here? would'nt
we increase code size? cant we use a function pointer
initialized to class1 or rest?
Quote from CodingStyle (15):
A reasonable rule of thumb is to not put inline at functions
that have more than 3 lines of code in them. An exception to
this rule are the cases where a parameter is known to be a
compiletime constant, and as a result of this constantness
you *know* the compiler will be able to optimize most of your
function away at compile time. For a good example of this
later case, see the kmalloc() inline function.
is the expectation that cpu_class_is_omap1 compile time
constant hence the actual compiled in code is smaller
-candidate for inline?
Detailed discussion and alignment can be found at:
http://www.spinics.net/lists/linux-omap/thrd6.html
Better link:
http://marc.info/?t=12826480236r=1w=2
Search for:
[PATCH v2 07/11] OMAP2/3/4: DMA: HWMOD: Device registration
http://marc.info/?l=linux-omapm=128464661906497w=2
my question is slightly different here - debate of suggestion to use inline
is based on the size of code involved, the discussion in the thread
discussed around 3 lines of code, which made sense, unfortunately, the
thread does not answer my question unfortunately for *this* specific patch
- OR do you wish to point me to some specific link which answers this?
#ifdef CONFIG_ARCH_OMAP15XX
/* Returns 1 if the DMA module is in OMAP1510-compatible mode, 0
if (cpu_class_is_omap1()) {
RE: Requirement for DSI video mode support
Hi, Please see [YQ]. Regards, Youcef Texas Instruments France SA, 821 Avenue Jack Kilby, 06270 Villeneuve Loubet. 036 420 040 R.C.S Antibes. Capital de EUR 753.920 -Original Message- From: Tomi Valkeinen [mailto:tomi.valkei...@nokia.com] Sent: Wednesday, October 27, 2010 2:18 PM To: Taneja, Archit Cc: ext Jorge Bustamante; linux-omap@vger.kernel.org; Iovescu, Magdalena; Menon, Nishanth; Qassid, Youcef; Aguirre, Alberto Subject: RE: Requirement for DSI video mode support On Wed, 2010-10-27 at 10:17 +0200, ext Taneja, Archit wrote: Hi, Command mode panels will work fine with a single VC, I don't think video mode can run by using only one VC. Okay, I think we're talking about different VCs =). It's rather confusing in the TRM. A VC (in DSI packet sense) refers to the channel ID sent in the packet, and a VC (in OMAP DSS register sense) refers to a set of configurations used to send DSI packets. I think we need to come up with terms that clearly make the distinction between these, because they really don't have anything in common. (I'd like to hear the rationale for naming OMAP's config registers as VCs... =). Yeah, it took me a while to figure out the difference from the TRM too. As far as the driver is concerned, I think there was a dest_per member for each set of VC configurations, that really made things clear. There was, yes. But that wasn't perfect either. You can use one OMAP VC register set to send packets to any peripheral by using different virtual channel ID. [YQ]: Command Mode will work fine with any OMAP VC register as you can control the VC ID field (generally set to 0). But you cannot control the VC for synchronization packets that are generated and sent automatically by the DSI is in Video Mode. Its not in the present kernel, but it would be nice to get it back. The present approach always correlates VC0 configuration to VC_ID 0, 1 to 1 and so on. That confused me for a while again :| Also, for command mode, there isn't a restriction to use a single VC. If you configure one VC to have slave port as source and the other as video port, the need to switch the VC source between L4 and VP would go away. This was what I had at some point. However, I was unsure how transmissions are synchronized in that case. If there's transmission going on from VP via, say, VC0, and I send a message from L4 via VC1, what happens? Does VC1 wait until VC0 is done? Or does it send the packet between VC0's packets? I don't know how things works internally, but I am sure the 2 VC configuration works for a handful of phones :) Is this a thing that should be explained in the DSI specification, or is this something that should be taken care of while implementing DSI hardware? I'll try to find out. It's DSI implementation spesific. It's about how OMAP HW handles the transmissions. I would guess that multiple OMAP VCs can send packets at the same time (but one packet on the DSI lines at one time, of course). But I'm not sure. [YQ] While using OCP (L3/L4) and Video Port interfaces for Command Mode you have several possibilities on OMAP4. You can choose the arbitration scheme. While the DSI is used in Video Mode, the packets you want to send via the OCP interface are transmitted during the blanking time. It is the interleaved mode. You have to respect some timing constraint for this feature. This is my understanding. I still have to validate these on silicon. But I agree, different VCs for L4 and VP usage would make some things a bit simpler. The most optimal way would be to use one VC for each peripheral, but I don't think the usecase of connecting 4 panels to the same DSI lanes would ever be needed. Yes, that is quite unlikely. But it's difficult to say what kind of devices one needs to connect (see below), but it could be that we may come up with some kind of rules that fit to all cases. For example, is there ever need to have to OMAP VCs configured as VP at the same time? If not, we know that there will always be 3 OMAP VCs free for L4 use. Etc. (I didn't think this really, just throwing ideas =). Yes it would be good to more of such rules. I don't think the one above is valid for OMAP4 though. One of the DSI blocks has 2 video ports as input. One VC can be configured in Video mode + Video Port and the other can be Command mode + Video port, and command mode and video port can run together. We haven't tried it out yet (and don't want to either :)) Nevertheless, it should be possible to use multiple VCs in one driver. I've implemented a driver for a buffer chip that used all 4 channels. So did you connect more than one panel to DSI? I am curious about how it works The chip had it's own framebuffer memory, and you could connect two displays to the chip. The virtual channel mapping was something like this: 0 - routed to first panel 1 - routed to second panel 2 -
[PATCH v2] OMAP4: Extend clock database.
This patch extends the OMAP4 clock data to include
various x2 clock nodes as the clock framework
skips a *2 whie calculating the dpll locked frequency.
The clock databse extensions are autogenerated using
the scripts maintained by Benoit Cousson.
Signed-off-by: Benoit Cousson b-cous...@ti.com
Signed-off-by: Thara Gopinath th...@ti.com
---
arch/arm/mach-omap2/clock44xx_data.c | 427 --
1 files changed, 248 insertions(+), 179 deletions(-)
diff --git a/arch/arm/mach-omap2/clock44xx_data.c
b/arch/arm/mach-omap2/clock44xx_data.c
index 1599836..94896af 100644
--- a/arch/arm/mach-omap2/clock44xx_data.c
+++ b/arch/arm/mach-omap2/clock44xx_data.c
@@ -17,10 +17,6 @@
* 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.
- *
- * XXX Some of the ES1 clocks have been removed/changed; once support
- * is added for discriminating clocks by ES level, these should be added back
- * in.
*/
#include linux/kernel.h
@@ -265,11 +261,63 @@ static struct clk dpll_abe_ck = {
.set_rate = omap3_noncore_dpll_set_rate,
};
+static struct clk dpll_abe_x2_ck = {
+ .name = dpll_abe_x2_ck,
+ .parent = dpll_abe_ck,
+ .ops= clkops_null,
+ .recalc = omap3_clkoutx2_recalc,
+};
+
+static const struct clksel_rate div31_1to31_rates[] = {
+ { .div = 1, .val = 1, .flags = RATE_IN_4430 },
+ { .div = 2, .val = 2, .flags = RATE_IN_4430 },
+ { .div = 3, .val = 3, .flags = RATE_IN_4430 },
+ { .div = 4, .val = 4, .flags = RATE_IN_4430 },
+ { .div = 5, .val = 5, .flags = RATE_IN_4430 },
+ { .div = 6, .val = 6, .flags = RATE_IN_4430 },
+ { .div = 7, .val = 7, .flags = RATE_IN_4430 },
+ { .div = 8, .val = 8, .flags = RATE_IN_4430 },
+ { .div = 9, .val = 9, .flags = RATE_IN_4430 },
+ { .div = 10, .val = 10, .flags = RATE_IN_4430 },
+ { .div = 11, .val = 11, .flags = RATE_IN_4430 },
+ { .div = 12, .val = 12, .flags = RATE_IN_4430 },
+ { .div = 13, .val = 13, .flags = RATE_IN_4430 },
+ { .div = 14, .val = 14, .flags = RATE_IN_4430 },
+ { .div = 15, .val = 15, .flags = RATE_IN_4430 },
+ { .div = 16, .val = 16, .flags = RATE_IN_4430 },
+ { .div = 17, .val = 17, .flags = RATE_IN_4430 },
+ { .div = 18, .val = 18, .flags = RATE_IN_4430 },
+ { .div = 19, .val = 19, .flags = RATE_IN_4430 },
+ { .div = 20, .val = 20, .flags = RATE_IN_4430 },
+ { .div = 21, .val = 21, .flags = RATE_IN_4430 },
+ { .div = 22, .val = 22, .flags = RATE_IN_4430 },
+ { .div = 23, .val = 23, .flags = RATE_IN_4430 },
+ { .div = 24, .val = 24, .flags = RATE_IN_4430 },
+ { .div = 25, .val = 25, .flags = RATE_IN_4430 },
+ { .div = 26, .val = 26, .flags = RATE_IN_4430 },
+ { .div = 27, .val = 27, .flags = RATE_IN_4430 },
+ { .div = 28, .val = 28, .flags = RATE_IN_4430 },
+ { .div = 29, .val = 29, .flags = RATE_IN_4430 },
+ { .div = 30, .val = 30, .flags = RATE_IN_4430 },
+ { .div = 31, .val = 31, .flags = RATE_IN_4430 },
+ { .div = 0 },
+};
+
+static const struct clksel dpll_abe_m2x2_div[] = {
+ { .parent = dpll_abe_x2_ck, .rates = div31_1to31_rates },
+ { .parent = NULL },
+};
+
static struct clk dpll_abe_m2x2_ck = {
.name = dpll_abe_m2x2_ck,
- .parent = dpll_abe_ck,
+ .parent = dpll_abe_x2_ck,
+ .clksel = dpll_abe_m2x2_div,
+ .clksel_reg = OMAP4430_CM_DIV_M2_DPLL_ABE,
+ .clksel_mask= OMAP4430_DPLL_CLKOUT_DIV_MASK,
.ops= clkops_null,
- .recalc = followparent_recalc,
+ .recalc = omap2_clksel_recalc,
+ .round_rate = omap2_clksel_round_rate,
+ .set_rate = omap2_clksel_set_rate,
};
static struct clk abe_24m_fclk = {
@@ -326,50 +374,10 @@ static struct clk aess_fclk = {
.set_rate = omap2_clksel_set_rate,
};
-static const struct clksel_rate div31_1to31_rates[] = {
- { .div = 1, .val = 1, .flags = RATE_IN_4430 },
- { .div = 2, .val = 2, .flags = RATE_IN_4430 },
- { .div = 3, .val = 3, .flags = RATE_IN_4430 },
- { .div = 4, .val = 4, .flags = RATE_IN_4430 },
- { .div = 5, .val = 5, .flags = RATE_IN_4430 },
- { .div = 6, .val = 6, .flags = RATE_IN_4430 },
- { .div = 7, .val = 7, .flags = RATE_IN_4430 },
- { .div = 8, .val = 8, .flags = RATE_IN_4430 },
- { .div = 9, .val = 9, .flags = RATE_IN_4430 },
- { .div = 10, .val = 10, .flags = RATE_IN_4430 },
- { .div = 11, .val = 11, .flags = RATE_IN_4430 },
- { .div = 12, .val = 12, .flags = RATE_IN_4430 },
- { .div = 13, .val = 13, .flags = RATE_IN_4430 },
- { .div = 14, .val = 14, .flags = RATE_IN_4430 },
- { .div = 15, .val = 15, .flags =
Re: [Question] which type of DMA taken by musb of beagle-xM(DM3730)?
On Wed, Oct 27, 2010 at 5:54 AM, Ming Lei tom.leim...@gmail.com wrote: I want to know which type of DMA is taken by musb of DM3730, INVENTRA_DMA, TI_CPPI_DMA or others? Inventra DMA. An updated version compared to the OMAP34xx/35xx. - No major change to the programming model - The simultaneous TX-RX DMA hang bug is gone with this one. - 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: [Question] which type of DMA taken by musb of beagle-xM(DM3730)?
Hi Gadiyar, Thanks for your reply. 2010/10/27 Gadiyar, Anand gadi...@ti.com: On Wed, Oct 27, 2010 at 5:54 AM, Ming Lei tom.leim...@gmail.com wrote: I want to know which type of DMA is taken by musb of DM3730, INVENTRA_DMA, TI_CPPI_DMA or others? Inventra DMA. An updated version compared to the OMAP34xx/35xx. - No major change to the programming model - The simultaneous TX-RX DMA hang bug is gone with this one. I find one issue about the dma transfer if Inventra DMA is used, seems always 2 bytes less than required length, is it caused by unaligned destination address? See the log captured in g_ether context: .. musb_g_rx 765: == ep1out, rxcsr 0003 (dma) dec241c0 dma_channel_program 165: ep1-Rx pkt_sz 512, dma_addr 0x9ecc7802 length 70, mode 0 configure_channel 130: dec57068, pkt_sz 512, addr 0x9ecc7802, len 70, mode 0 dma_controller_irq 302: ch dec57068, 0x9ecc7802 - 0x9ecc7846 (68 / 70) = reconfig 0 musb_g_rx 765: == ep1out, rxcsr 2003 (dma) dec241c0 musb_g_rx 808: RXCSR1 0003, dma off, 0003, len 68, req dec241c0 musb_g_giveback 143: ep1out done request dec241c0, 68/1536 musb_gadget_queue 1146: == to ep1out request=dec241c0 musb_interrupt 1594: ** IRQ peripheral usb0008 tx rx0002 musb_stage0_irq 462: == Power=f0, DevCtl=99, int_usb=0x8 musb_g_rx 765: == ep1out, rxcsr 0003 (dma) dec244c0 dma_channel_program 165: ep1-Rx pkt_sz 512, dma_addr 0x9ecc7002 length 341, mode 0 configure_channel 130: dec57068, pkt_sz 512, addr 0x9ecc7002, len 341, mode 0 dma_controller_irq 302: ch dec57068, 0x9ecc7002 - 0x9ecc7155 (339 / 341) = reconfig 0 .. thanks, -- Lei Ming -- 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: [linux-pm] [PATCH] PERF(kernel): Cleanup power events V2
On Wednesday, October 27, 2010, Mathieu Desnoyers wrote: * Rafael J. Wysocki (r...@sisk.pl) wrote: ... Hrm, then why export pm_runtime_get_noresume() at all ? Basically, the PM core needs it for some obscure stuff. Beyond that people really should use it with care (preferably avoid using it at all). I don't feel comfortable with some of the pm_runtime_get_noresume() callers. So if you don't want to resume the device immediately after increasing its usage_count (in which case it's better to use pm_runtime_get_sync()), you should do something like this: 1) pm_runtime_get_noresume(dev); 1a) pm_runtime_barrier(dev); // That takes care of all pending requests etc. 2) ... 3) pm_runtime_put_noidle(dev); [The meaning of pm_runtime_barrier() is that all of the runtime PM activity started before the barrier has been completed when it returns.] There's one place in the PM core where that really is necessary, but I wouldn't recommend anyone doing anything like it in a driver. grep -r pm_runtime_get_noresume drivers/hands out very interesting info. e.g.: drivers/usb/core/drivers.c: usb_autopm_get_interface_async() pm_runtime_get_noresume(intf-dev); s = ACCESS_ONCE(intf-dev.power.runtime_status); if (s == RPM_SUSPENDING || s == RPM_SUSPENDED) status = pm_request_resume(intf-dev); How is this supposed to work ? If the ACCESS_ONCE can be reordered before the atomic_inc(), then I fear the device can be suspended even after the check. My point is that a get/put semantic should imply memory barriers, especially if these are exported APIs. Well, IMO adding a memory barrier to pm_runtime_get_noresume() wouldn't really change a lot (it still would be racy with respect to some other runtime PM helper funtions). That said I guess we should put a handle with care sticker on it. Thanks, Rafael -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH v4 3/9] OMAP3: PM: Adding smartreflex device file.
Thara,
-Original Message-
From: linux-omap-ow...@vger.kernel.org
[mailto:linux-omap-ow...@vger.kernel.org] On Behalf Of Gopinath, Thara
Sent: Wednesday, October 27, 2010 9:41 PM
To: linux-omap@vger.kernel.org
Cc: p...@pwsan.com; khil...@deeprootsystems.com; Cousson,
Benoit; Sripathy, Vishwanath; Sawant, Anand; Gopinath, Thara
Subject: [PATCH v4 3/9] OMAP3: PM: Adding smartreflex device file.
This patch adds support for device registration of various
smartreflex module present in the system. This patch introduces
the platform data for smartreflex devices which include
the efused and test n-target vaules, module enable/disable
pointers and a parameter to indicate whether smartreflex
autocompensation needs to be enabled on init or not.
Currently auocompensation is enabled on init by default
for OMAP3430 ES3.1 chip.
Signed-off-by: Thara Gopinath th...@ti.com
---
arch/arm/mach-omap2/Makefile|2 +-
arch/arm/mach-omap2/sr_device.c | 177
+++
2 files changed, 178 insertions(+), 1 deletions(-)
create mode 100644 arch/arm/mach-omap2/sr_device.c
snip
+
+static int sr_dev_init(struct omap_hwmod *oh, void *user)
Since *user is unused, you may rename it to *unused
+{
+ struct omap_sr_data *sr_data;
+ struct omap_sr_dev_data *sr_dev_data;
+ struct omap_device *od;
+ char *name = smartreflex;
+ static int i;
+
+ sr_data = kzalloc(sizeof(struct omap_sr_data), GFP_KERNEL);
+ if (!sr_data) {
+ pr_err(%s: Unable to allocate memory for %s
sr_data.Error!\n,
+ __func__, oh-name);
+ return -ENOMEM;
+ }
+
+ sr_dev_data = (struct omap_sr_dev_data *)oh-dev_attr;
+ if (unlikely(!sr_dev_data)) {
+ pr_err(%s: dev atrribute is NULL\n, __func__);
+ goto exit;
+ }
+
+ /*
+ * OMAP3430 ES3.1 chips by default come with Efuse burnt
+ * with parameters required for full functionality of
+ * smartreflex AVS feature like ntarget values , sennenable
+ * and senpenable. So enable the SR AVS feature during boot up
+ * itself if it is a OMAP3430 ES3.1 chip.
+ */
+ sr_data-enable_on_init = false;
+ if (cpu_is_omap343x())
+ if (omap_rev() == OMAP3430_REV_ES3_1)
+ sr_data-enable_on_init = true;
+
+ sr_data-voltdm =
omap_voltage_domain_lookup(sr_dev_data-vdd_name);
+ if (IS_ERR(sr_data-voltdm)) {
+ pr_err(%s: Unable to get voltage domain
pointer for VDD %s\n,
+ __func__, sr_dev_data-vdd_name);
+ goto exit;
+ }
+
+ sr_dev_data-volts_supported = omap_voltage_get_volttable(
+ sr_data-voltdm, sr_dev_data-volt_data);
+ if (!sr_dev_data-volts_supported) {
+ pr_warning(%s: No Voltage table registerd fo VDD%d.
+ Something really wrong\n\n, __func__, i + 1);
+ goto exit;
+ }
+
+ sr_set_nvalues(sr_dev_data, sr_data);
+
+ od = omap_device_build(name, i, oh, sr_data, sizeof(*sr_data),
+omap_sr_latency,
+ARRAY_SIZE(omap_sr_latency), 0);
Patch 4 should come before patch 3 in the series. Otherwise, this
would fail during a git-bisect.
+ if (IS_ERR(od))
+ pr_warning(%s: Could not build omap_device for
%s: %s.\n\n,
+ __func__, name, oh-name);
Return error.
+exit:
+ i++;
+ kfree(sr_data);
+ return 0;
+}
+
+static int __init omap_devinit_smartreflex(void)
+{
+ return omap_hwmod_for_each_by_class(smartreflex,
sr_dev_init, NULL);
+}
+device_initcall(omap_devinit_smartreflex);
--
1.7.0.4
--
To unsubscribe from this list: send the line unsubscribe
linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH v4 2/9] OMAP3: PM: Adding smartreflex driver support.
Thara,
-Original Message-
From: linux-omap-ow...@vger.kernel.org
[mailto:linux-omap-ow...@vger.kernel.org] On Behalf Of Thara Gopinath
Sent: Wednesday, October 27, 2010 9:41 PM
To: linux-omap@vger.kernel.org
Cc: p...@pwsan.com; khil...@deeprootsystems.com; Cousson,
Benoit; Sripathy, Vishwanath; Sawant, Anand; Gopinath, Thara
Subject: [PATCH v4 2/9] OMAP3: PM: Adding smartreflex driver support.
SmartReflex modules do adaptive voltage control for real-time
voltage adjustments. With Smartreflex the power supply voltage
can be adapted to the silicon performance(manufacturing process,
temperature induced performance, age induced performance etc).
There are differnet classes of smartreflex implementation.
Class-0: Manufacturing Test Calibration
Class-1: Boot-Time Software Calibration
Class-2: Continuous Software Calibration
Class-3: Continuous Hardware Calibration
Class-4: Fully Integrated Power Management
OMAP3 has two smartreflex modules one associated with VDD MPU and the
other associated with VDD CORE.
This patch adds support for smartreflex driver. The driver
is designed
for Class-1 , Class-2 and Class-3 support and is a platform driver.
Smartreflex driver can be enabled through a Kconfig option
SmartReflex support under System type-TI OMAP
implementations menu.
Smartreflex autocompensation feature can be enabled runtime through
a debug fs option.
To enable smartreflex autocompensation feature
echo 1 /debug/voltage/vdd_X/smartreflex/autocomp
To disable smartreflex autocompensation feature
echo 0 /debug/voltage/vdd_X/smartreflex/autocomp
where X can be mpu, core , iva etc.
This patch contains code originally in linux omap pm branch.
Major contributors to this driver are
Lesly A M, Rajendra Nayak, Kalle Jokiniemi, Paul Walmsley,
Nishant Menon, Kevin Hilman.
Signed-off-by: Thara Gopinath th...@ti.com
---
arch/arm/mach-omap2/Makefile |1 +
arch/arm/mach-omap2/smartreflex.c | 975
+
arch/arm/plat-omap/Kconfig| 36 +
arch/arm/plat-omap/include/plat/smartreflex.h | 271 +++
4 files changed, 1283 insertions(+), 0 deletions(-)
create mode 100644 arch/arm/mach-omap2/smartreflex.c
create mode 100644 arch/arm/plat-omap/include/plat/smartreflex.h
snip
+static int __init omap_sr_probe(struct platform_device *pdev)
+{
+ struct omap_sr *sr_info = kzalloc(sizeof(struct
omap_sr), GFP_KERNEL);
+ struct omap_device *odev = to_omap_device(pdev);
Patch3 should be ordered before patch2 in your series. Otherwise,
this would fail during a git-bisect.
+ struct omap_sr_data *pdata = pdev-dev.platform_data;
+ struct resource *mem, *irq;
+ struct dentry *vdd_dbg_dir, *dbg_dir;
+ int ret = 0;
+
+ if (!sr_info) {
+ dev_err(pdev-dev, %s: unable to allocate sr_info\n,
+ __func__);
+ return -ENOMEM;
+ }
+
+ if (!pdata) {
+ dev_err(pdev-dev, %s: platform data
missing\n, __func__);
+ return -EINVAL;
+ }
+
+ mem = platform_get_resource(pdev, IORESOURCE_MEM, 0);
+ if (!mem) {
+ dev_err(pdev-dev, %s: no mem resource\n, __func__);
+ ret = -ENODEV;
+ goto err_free_devinfo;
+ }
+
+ irq = platform_get_resource(pdev, IORESOURCE_IRQ, 0);
+
+ pm_runtime_enable(pdev-dev);
+
+ sr_info-pdev = pdev;
+ sr_info-srid = pdev-id;
+ sr_info-voltdm = pdata-voltdm;
+ sr_info-autocomp_active = false;
+ sr_info-ip_type = odev-hwmods[0]-class-rev;
I am not sure if it is okay to get hwmods-info in the driver.
To avoid too many indirections, it can be obtained before
omap_device_build() of the device and passed to the driver.
+ sr_info-base = ioremap(mem-start, resource_size(mem));
+ if (!sr_info-base) {
+ dev_err(pdev-dev, %s: ioremap fail\n, __func__);
+ ret = -ENOMEM;
+ goto err_release_region;
+ }
snip
-V Charulatha--
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
