Re: OMAP:DSS: possible bug in WAITFOR_VSYNC ioctl
Hiremath, Vaibhav hvaib...@ti.com writes:
-Original Message-
From: Ville Syrjälä [mailto:ville.syrj...@nokia.com]
Sent: Wednesday, November 24, 2010 10:01 PM
To: Hiremath, Vaibhav
Cc: Tomi Valkeinen; linux-omap@vger.kernel.org
Subject: Re: OMAP:DSS: possible bug in WAITFOR_VSYNC ioctl
On Wed, Nov 24, 2010 at 03:39:44PM +0530, ext Hiremath, Vaibhav wrote:
-Original Message-
From: Tomi Valkeinen [mailto:tomi.valkei...@nokia.com]
Sent: Wednesday, November 24, 2010 2:28 PM
To: Hiremath, Vaibhav
Cc: linux-omap@vger.kernel.org
Subject: Re: OMAP:DSS: possible bug in WAITFOR_VSYNC ioctl
On Tue, 2010-11-23 at 23:46 +0530, ext Hiremath, Vaibhav wrote:
Hi,
snip
Changing it to WAITFORGO would alter the behaviour. Sometimes it would
not wait at all, sometimes it could wait for multiple vsyncs.
[Hiremath, Vaibhav] I am quite not sure, whether it makes sense from
application point of view to wait for vsync if config is not changed. What
could be the use-case for such requirement, where application won't change
anything but still would like to wait on vsync?
And as far as wait on multiple vsync is concerned, it does make sense to
coat WAITFORVSYNC ioctl makes sure that your change got applied to HW.
I am not aware of other architectures, but I believe this is something
OMAP specific stuff. And for other platforms, WAITFORVSYNC means changes
applied to HW (why does apps care about whether it is vsync or anything
else?).
WAITFORVSYNC waits for the next vsync (or actually vblank in many
cases).
[Hiremath, Vaibhav] Please note that this doesn't include VFP
(vertical front porch), since you are going to get VSYNC only after
VFP.
That's it. I don't see any point in trying to shoehorn
other functionality into it.
If you want to standardise WAITFORGO type of stuff then just add
another standard ioctl for it.
[Hiremath, Vaibhav] I still believe we should not only look at the
name of IOCTL (WAITFORVSYNC) and define what it should do, it may
change based on your platform/HW to get the desired functionality
out of it.
It is impossible to know what every user expects from it. A user may
very well be using WAITFORVSYNC for timing purposes. If it then were
to sometimes wait more than one vsync, it would be useless.
In OMAP there is chance of miss-match between user application and
Display HW if user uses FBIO_WAITFORVSYNC ioctl in multi-buffer
use-case.
while (1) {
Update/Create the next buffer
FBIO_PAN
FBIO_WAITFORVSYNC //assuming HW-SW stay in sync (which is not)
}
There is definitely an issue with above use-case which has been
un-doubtfully conformed now.
The bug could still be argued to be in the application.
At least in case of OMAP, WAITFORVSYNC is useless in multiple
buffering use-case, application has to use WAITFORGO.
Why does it take so long for the changes to reach the hardware? Once
written to the registers, the values are latched at the next vsync, so
the delay is higher up the stack. Is there any way it could be
eliminated? This would not only fix the bug under discussion here,
but also reduce the latency of page flipping.
As far as WAITFORGO is concerned, I think GO bit concept is
something OMAP notion/term and doesn't make sense to standardize
it. Atleast I am not aware of any other architecture having GO bit.
Naming is minor detail. Feel free to suggest a better one.
--
Måns Rullgård
m...@mansr.com
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 1/4] drivers: hwspinlock: add generic framework
On Fri, Nov 26, 2010 at 6:59 AM, Olof Johansson o...@lixom.net wrote:
+#define pr_fmt(fmt) %s: fmt, __func__
Not used.
Yes, it is, check out how the pr_* macros are implemented:
#define pr_info(fmt, ...) \
printk(KERN_INFO pr_fmt(fmt), ##__VA_ARGS__)
I use it to ensure that the function name is printed with any pr_*
macro, without having to explicitly specify the __func__ param every
time.
+int __hwspin_trylock(struct hwspinlock *hwlock, int mode, unsigned long
*flags)
+{
+ int ret;
+
+ if (unlikely(!hwlock)) {
+ pr_err(invalid hwlock\n);
These kind of errors can get very spammy for buggy drivers.
Yeah, but that's the purpose - I want to catch such egregious drivers
who try to crash the kernel.
It's likely
more useful to either do a WARN_ON(), and/or move them under a debug
config option.
Why would you prefer to compile out reporting of such extremely buggy behavior ?
+ return -EINVAL;
+ }
+ if (unlikely(mode == HWLOCK_IRQSTATE flags == NULL)) {
+ pr_err(invalid flags pointer (null)\n);
+ return -EINVAL;
+ }
+
+ /*
+ * This spin_lock{_irq, _irqsave} serves three purposes:
+ *
+ * 1. Disable preemption, in order to minimize the period of time
+ * in which the hwspinlock is taken. This is important in order
+ * to minimize the possible polling on the hardware interconnect
+ * by a remote user of this lock.
+ * 2. Make the hwspinlock SMP-safe (so we can take it from
+ * additional contexts on the local host).
+ * 3. Ensure that in_atomic/might_sleep checks catch potential
+ * problems with hwspinlock usage (e.g. scheduler checks like
+ * 'scheduling while atomic' etc.)
+ */
+ if (mode == HWLOCK_IRQSTATE)
+ ret = spin_trylock_irqsave(hwlock-lock, *flags);
+ else if (mode == HWLOCK_IRQ)
+ ret = spin_trylock_irq(hwlock-lock);
+ else
+ ret = spin_trylock(hwlock-lock);
+
+ /* is lock already taken by another context on the local cpu ? */
+ if (!ret)
+ return -EBUSY;
+
+ /* try to take the hwspinlock device */
+ ret = hwlock-ops-trylock(hwlock);
+
+ /* if hwlock is already taken, undo spin_trylock_* and exit */
+ if (!ret) {
+ if (mode == HWLOCK_IRQSTATE)
+ spin_unlock_irqrestore(hwlock-lock, *flags);
+ else if (mode == HWLOCK_IRQ)
+ spin_unlock_irq(hwlock-lock);
+ else
+ spin_unlock(hwlock-lock);
+
+ return -EBUSY;
+ }
+
+ /*
+ * We can be sure the other core's memory operations
+ * are observable to us only _after_ we successfully take
+ * the hwspinlock, so we must make sure that subsequent memory
+ * operations will not be reordered before we actually took the
+ * hwspinlock.
+ *
+ * Note: the implicit memory barrier of the spinlock above is too
+ * early, so we need this additional explicit memory barrier.
+ */
+ mb();
rmb() should be sufficient here.
It's not.
We need to make sure that our writes, too, will not be reordered
before that barrier. Otherwise, we might end up changing protected
shared memory during the critical section of the remote processor
(before we acquire the lock we must not read from, or write to, the
protected shared memory).
I guess I need to add a comment about this.
+int __hwspin_unlock(struct hwspinlock *hwlock, int mode, unsigned long
*flags)
+{
+ if (unlikely(!hwlock)) {
+ pr_err(invalid hwlock\n);
+ return -EINVAL;
+ }
+ if (unlikely(mode == HWLOCK_IRQSTATE flags == NULL)) {
+ pr_err(invalid flags pointer (null)\n);
+ return -EINVAL;
+ }
+
+ /*
+ * We must make sure that memory operations, done before unlocking
+ * the hwspinlock, will not be reordered after the lock is released.
+ *
+ * That's the purpose of this explicit memory barrier.
+ *
+ * Note: the memory barrier induced by the spin_unlock below is too
+ * late; the other core is going to access memory soon after it will
+ * take the hwspinlock, and by then we want to be sure our memory
+ * operations are already observable.
+ */
+ mb();
wmb() should be sufficient here.
No - here, too, we need to make sure that also our read operations
will not be reordered after the barrier. Otherwise, we might end up
reading memory that has already been changed by a remote processor
that is just about to acquire the lock.
+
+ hwlock-ops-unlock(hwlock);
+
+ /* Undo the spin_trylock{_irq, _irqsave} called while locking */
+ if (mode == HWLOCK_IRQSTATE)
+ spin_unlock_irqrestore(hwlock-lock, *flags);
+ else if (mode == HWLOCK_IRQ)
+
Re: [RFC/PATCH v6 03/12] [alsa-devel] media: Entities, pads and links
Laurent Pinchart wrote: On Thursday 25 November 2010 10:38:05 Clemens Ladisch wrote: MEDIA_ENTITY_TYPE_NODE_ALSA_PCM MEDIA_ENTITY_TYPE_NODE_ALSA_MIDI MEDIA_ENTITY_TYPE_SUBDEV_ALSA_CONTROL I agree about PCM and MIDI, but I'm not sure about controls. If controls are part of an entity, the entity will be reported through the media controller API. If information about that entity can be queried through existing APIs (ALSA, V4L, ...) those APIs should be used. At the moment, ALSA has no API for topology information. I can certainly imagine a graph with 100 controls, but maybe several controls can be part of the same node ? There is indeed no strict 1:1 relation; e.g., volume and mute are often part of the same node. So it looks we need some kind of separate ALSA node, which can be associated with mixer controls and/or other information. ALSA already has is a method to query arbitrary (TLV) metadata for mixer controls; the entity/control relationship can be stored in the control. I think we will need a new ioctl in the media controller API to report advanced information about an entity. This could be used to report controls implemented by an ALSA element if ALSA doesn't provide a way to do that directly. This advanced information would always be specific to the entity type, so maybe this should be part of that subsystem's API. Otherwise, the media_entity would need a callback, or store a pointer to some memory block (which assumes that the information is always constant). Furthermore, topology information is also needed for entities not associated with a mixer control, such as microphones, speakers, jacks/ connectors, and effect units. These entities are defined in the USB and HD audio specifications, but are not yet handled by ALSA. Agreed, we will need to add new entity types and subtypes for those. The reason they're not part of this submission is that I wanted real use cases instead of coming up with a made-up list of entities I think would be useful. The reason that I'm always mentioning the USB and HD audio specs is that those already define entities that should cover practically all of the audio needs. (And, of course, we want to be able to report those entities without having to do too many conversions.) I'll see if I can draw up the ALSA-specific media stuff over the weekend. Regards, Clemens -- 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 1/4] drivers: hwspinlock: add generic framework
On Fri, Nov 26, 2010 at 10:53:10AM +0200, Ohad Ben-Cohen wrote:
+int __hwspin_trylock(struct hwspinlock *hwlock, int mode, unsigned long
*flags)
+{
+ int ret;
+
+ if (unlikely(!hwlock)) {
+ pr_err(invalid hwlock\n);
These kind of errors can get very spammy for buggy drivers.
Yeah, but that's the purpose - I want to catch such egregious drivers
who try to crash the kernel.
That can be better - because you get a backtrace, and it causes people
to report the problem rather than just ignore it. It may also prevent
the driver author releasing his code (as it won't work on their
initial testing.)
It's likely
more useful to either do a WARN_ON(), and/or move them under a debug
config option.
Why would you prefer to compile out reporting of such extremely buggy
behavior ?
If it's extremely buggy behaviour then the drivers deserve to crash.
Such stuff should cause them not to get out the door. A simple printk
with an error return can just be ignored.
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH 2/2] enabled vdda_dac regulator support tvout on rx51
+#if defined(CONFIG_FB_OMAP2) || defined(CONFIG_FB_OMAP2_MODULE)
The ifdefs here aren't really saving much...
In the same file board-rx51-peripheral.c,Under these rx51_display_device is
defined as extern and also in board-rx51-video.c the under same #defines
Complete display functionality is implemented
currently so used not to break compilation when #defines are not enabled .
.dev_name is preferred, though I'm not sure if we'll ever get round to
phasing out plain dev.
It is difficult to modify currently.
From: ext Mark Brown [broo...@opensource.wolfsonmicro.com]
Sent: Thursday, November 25, 2010 6:11 PM
To: Bhavanarayana Srikar.1 (EXT-Elektrobit/Helsinki)
Cc: t...@atomide.com; li...@arm.linux.org.uk; linux-omap@vger.kernel.org
Subject: Re: [PATCH 2/2] enabled vdda_dac regulator support tvout on rx51
On Thu, Nov 25, 2010 at 05:52:23PM +0200, Srikar wrote:
+static struct regulator_consumer_supply rx51_vdac_supply[] = {
+ {
+#if defined(CONFIG_FB_OMAP2) || defined(CONFIG_FB_OMAP2_MODULE)
The ifdefs here aren't really saving much...
+ .supply = vdda_dac,
+ .dev= rx51_display_device.dev,
dev_name is preferred, though I'm not sure if we'll ever get round to
phasing out plain dev.
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 2/2] enabled vdda_dac regulator support tvout on rx51
On 11/25/2010 06:11 PM, ext Mark Brown wrote:
On Thu, Nov 25, 2010 at 05:52:23PM +0200, Srikar wrote:
+static struct regulator_consumer_supply rx51_vdac_supply[] = {
+{
+#if defined(CONFIG_FB_OMAP2) || defined(CONFIG_FB_OMAP2_MODULE)
The ifdefs here aren't really saving much...
Currently rx51_display_device is defined under same
ifdefs(CONFIG_FB_OMAP2,CONFIG_FB_OMAP2_MODULE)
as extern and also in board-rx51-video.c display devices are under same
ifdefs,So used to not
break compilation when CONFIG_FB_OMAP2,CONFIG_FB_OMAP2_MODULE not defined.
+.supply = vdda_dac,
+.dev= rx51_display_device.dev,
dev_name is preferred, though I'm not sure if we'll ever get round to
phasing out plain dev.
Currently difficult to use .dev_name .
--
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 1/4] drivers: hwspinlock: add generic framework
On Fri, Nov 26, 2010 at 11:18 AM, Russell King - ARM Linux
li...@arm.linux.org.uk wrote:
On Fri, Nov 26, 2010 at 10:53:10AM +0200, Ohad Ben-Cohen wrote:
+int __hwspin_trylock(struct hwspinlock *hwlock, int mode, unsigned long
*flags)
+{
+ int ret;
+
+ if (unlikely(!hwlock)) {
+ pr_err(invalid hwlock\n);
These kind of errors can get very spammy for buggy drivers.
Yeah, but that's the purpose - I want to catch such egregious drivers
who try to crash the kernel.
That can be better - because you get a backtrace, and it causes people
to report the problem rather than just ignore it. It may also prevent
the driver author releasing his code (as it won't work on their
initial testing.)
...
If it's extremely buggy behaviour then the drivers deserve to crash.
Such stuff should cause them not to get out the door. A simple printk
with an error return can just be ignored.
I like this approach too, but recently we had a few privilege
escalation exploits which involved NULL dereference kernel bugs
(process context mapped address 0 despite a positive mmap_min_addr).
Since we can't rely on the oops to always happen, I decided not to
omit the NULL checks.
--
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] OMAP: DSS2: Clean up DISPC color mode validation checks
Hi, On Thu, 2010-11-25 at 17:58 +0530, ext Archit Taneja wrote: The supported set of color modes varies for different DISPC pipelines(plane) and omap version. This makes the checks for validation of a color mode more complicated as new omap versions are added. A dss_feature function is created which tells if a color_mode is supported for a plane on the current omap revision. Signed-off-by: Archit Taneja arc...@ti.com --- drivers/video/omap2/dss/dispc.c| 53 +++- drivers/video/omap2/dss/dss_features.c |7 drivers/video/omap2/dss/dss_features.h |2 + 3 files changed, 14 insertions(+), 48 deletions(-) Looks good to me, thanks! 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 v2 1/4] drivers: hwspinlock: add generic framework
On Fri, Nov 26, 2010 at 12:16:39PM +0200, Ohad Ben-Cohen wrote:
On Fri, Nov 26, 2010 at 11:18 AM, Russell King - ARM Linux
li...@arm.linux.org.uk wrote:
On Fri, Nov 26, 2010 at 10:53:10AM +0200, Ohad Ben-Cohen wrote:
+int __hwspin_trylock(struct hwspinlock *hwlock, int mode, unsigned
long *flags)
+{
+ int ret;
+
+ if (unlikely(!hwlock)) {
+ pr_err(invalid hwlock\n);
These kind of errors can get very spammy for buggy drivers.
Yeah, but that's the purpose - I want to catch such egregious drivers
who try to crash the kernel.
That can be better - because you get a backtrace, and it causes people
to report the problem rather than just ignore it. It may also prevent
the driver author releasing his code (as it won't work on their
initial testing.)
...
If it's extremely buggy behaviour then the drivers deserve to crash.
Such stuff should cause them not to get out the door. A simple printk
with an error return can just be ignored.
I like this approach too, but recently we had a few privilege
escalation exploits which involved NULL dereference kernel bugs
(process context mapped address 0 despite a positive mmap_min_addr).
That's not a concern on ARM. The prevention of having a user page mapped
at virtual address 0 does not rely on mmap_min_addr - in fact, we can't
use this as it's tuneable to enforce this requirement.
It's highly illegal on ARM - as ARM CPUs without vector remap place the
hardware vectors at virtual address 0, and as such allowing the user to
map a page there will take the system down. So we have this code in the
mmap path:
#define arch_mmap_check(addr, len, flags) \
(((flags) MAP_FIXED (addr) FIRST_USER_ADDRESS) ? -EINVAL : 0)
which prevents any attempt what so ever, irrespective of the mmap_min_addr
setting, to create a userspace induced mapping at address 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
[PATCH] OMAP3_IVA_MASK should use OMAP3_IVA_SHIFT instead of OMAP3_SGX_SHIFT
Signed-off-by: Arno Steffen arno.stef...@googlemail.com --- arch/arm/mach-omap2/control.h |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/arch/arm/mach-omap2/control.h b/arch/arm/mach-omap2/control.h index b6c6b7c..5325297 100644 --- a/arch/arm/mach-omap2/control.h +++ b/arch/arm/mach-omap2/control.h @@ -309,7 +309,7 @@ #defineFEAT_SGX_NONE 2 #define OMAP3_IVA_SHIFT12 -#define OMAP3_IVA_MASK (1 OMAP3_SGX_SHIFT) +#define OMAP3_IVA_MASK (1 OMAP3_IVA_SHIFT) #defineFEAT_IVA0 #defineFEAT_IVA_NONE 1 -- 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
RE: OMAP:DSS: possible bug in WAITFOR_VSYNC ioctl
-Original Message-
From: linux-omap-ow...@vger.kernel.org [mailto:linux-omap-
ow...@vger.kernel.org] On Behalf Of Måns Rullgård
Sent: Friday, November 26, 2010 2:09 PM
To: linux-omap@vger.kernel.org
Subject: Re: OMAP:DSS: possible bug in WAITFOR_VSYNC ioctl
Hiremath, Vaibhav hvaib...@ti.com writes:
-Original Message-
From: Ville Syrjälä [mailto:ville.syrj...@nokia.com]
Sent: Wednesday, November 24, 2010 10:01 PM
To: Hiremath, Vaibhav
Cc: Tomi Valkeinen; linux-omap@vger.kernel.org
Subject: Re: OMAP:DSS: possible bug in WAITFOR_VSYNC ioctl
On Wed, Nov 24, 2010 at 03:39:44PM +0530, ext Hiremath, Vaibhav wrote:
-Original Message-
From: Tomi Valkeinen [mailto:tomi.valkei...@nokia.com]
Sent: Wednesday, November 24, 2010 2:28 PM
To: Hiremath, Vaibhav
Cc: linux-omap@vger.kernel.org
Subject: Re: OMAP:DSS: possible bug in WAITFOR_VSYNC ioctl
On Tue, 2010-11-23 at 23:46 +0530, ext Hiremath, Vaibhav wrote:
Hi,
snip
snip...
If you want to standardise WAITFORGO type of stuff then just add
another standard ioctl for it.
[Hiremath, Vaibhav] I still believe we should not only look at the
name of IOCTL (WAITFORVSYNC) and define what it should do, it may
change based on your platform/HW to get the desired functionality
out of it.
It is impossible to know what every user expects from it. A user may
very well be using WAITFORVSYNC for timing purposes. If it then were
to sometimes wait more than one vsync, it would be useless.
[Hiremath, Vaibhav] I completely understand and agree with your statement here,
but I think the finding and recommendation which I am talking about does
address this.
Let's consider 2 Options/use-cases -
1) Application expecting correct number of VSYNC interrupts -
Here application wants to use WAITFORVSYNC ioctl to get correct number of VSYNC
interrupt and do some operation (not related to buffer data or no Fbdev config
change). Then WAITFORGO will work exactly same as WAITFORVSYNC.
Let me state one more time WAITFORGO makes sure that the configuration change
gets applied to actual HW. If application is changing some configuration of
HW, does it makes sense to return without making sure that whether it has been
consumed by HW or not.
2) Application does update the buffer and synchronizes with HW on WAIFORVSYNC -
As I mentioned this is un-doubtfully conformed that it has valid bug where
there is chance of software going out of sync with actual HW.
In OMAP there is chance of miss-match between user application and
Display HW if user uses FBIO_WAITFORVSYNC ioctl in multi-buffer
use-case.
while (1) {
Update/Create the next buffer
FBIO_PAN
FBIO_WAITFORVSYNC //assuming HW-SW stay in sync (which is not)
}
There is definitely an issue with above use-case which has been
un-doubtfully conformed now.
The bug could still be argued to be in the application.
[Hiremath, Vaibhav] No, you can not. Please refer to the wiki page
(http://processors.wiki.ti.com/index.php/OMAP35x_Linux_-_DSS_FAQ) which
explains OMAP HW issue I am talking about.
Actually with the same context I was referring to some of other devices like
S3C, etc... and I believe they handle double-buffering in different way. In
case of S3C, HW does support 2 sets of separate configuration to handle double
buffering. Spec doesn't talk about any shadow register, when HW latches it,
etc... But I believe it makes sense that, it must be getting latched on next
vsync.
At least in case of OMAP, WAITFORVSYNC is useless in multiple
buffering use-case, application has to use WAITFORGO.
Why does it take so long for the changes to reach the hardware?
[Hiremath, Vaibhav] It doesn't take time to reach HW. What if application
writes exactly during this period (VFP - VSYNC), could it be delay due to extra
time for image creation, or anything.
Once
written to the registers, the values are latched at the next vsync, so
the delay is higher up the stack. Is there any way it could be
eliminated? This would not only fix the bug under discussion here,
but also reduce the latency of page flipping.
[Hiremath, Vaibhav] Mat,
Exactly same thing I am bringing out here, OMAP3 DSS doesn't fall under this.
In case of OMAP3, the latching doesn't happen on VSYNC, it happens on VFP
(Vertical front porch). There is time gap between VFP and VSYNC; this is what I
am referring to.
If application changes/writes during this period (after VFP and before VSYNC)
you are going out of sync, that's where the tearing effect is observed.
As far as WAITFORGO is concerned, I think GO bit concept is
something OMAP notion/term and doesn't make sense to standardize
it. Atleast I am not aware of any other architecture having GO bit.
Naming is minor detail. Feel free to suggest a better one.
[Hiremath, Vaibhav] If I fail to convince on this, then I think the only left
option is to make
RE: OMAP:DSS: possible bug in WAITFOR_VSYNC ioctl
-Original Message- From: Hiremath, Vaibhav Sent: Friday, November 26, 2010 5:34 PM To: 'Måns Rullgård'; linux-omap@vger.kernel.org Subject: RE: OMAP:DSS: possible bug in WAITFOR_VSYNC ioctl -Original Message- From: linux-omap-ow...@vger.kernel.org [mailto:linux-omap- ow...@vger.kernel.org] On Behalf Of Måns Rullgård Sent: Friday, November 26, 2010 2:09 PM To: linux-omap@vger.kernel.org Subject: Re: OMAP:DSS: possible bug in WAITFOR_VSYNC ioctl Hiremath, Vaibhav hvaib...@ti.com writes: -Original Message- From: Ville Syrjälä [mailto:ville.syrj...@nokia.com] Sent: Wednesday, November 24, 2010 10:01 PM To: Hiremath, Vaibhav Cc: Tomi Valkeinen; linux-omap@vger.kernel.org Subject: Re: OMAP:DSS: possible bug in WAITFOR_VSYNC ioctl On Wed, Nov 24, 2010 at 03:39:44PM +0530, ext Hiremath, Vaibhav wrote: -Original Message- From: Tomi Valkeinen [mailto:tomi.valkei...@nokia.com] Sent: Wednesday, November 24, 2010 2:28 PM To: Hiremath, Vaibhav Cc: linux-omap@vger.kernel.org Subject: Re: OMAP:DSS: possible bug in WAITFOR_VSYNC ioctl On Tue, 2010-11-23 at 23:46 +0530, ext Hiremath, Vaibhav wrote: Hi, snip snip.. As far as WAITFORGO is concerned, I think GO bit concept is something OMAP notion/term and doesn't make sense to standardize it. Atleast I am not aware of any other architecture having GO bit. Naming is minor detail. Feel free to suggest a better one. [Hiremath, Vaibhav] If I fail to convince on this, then I think the only left option is to make WAITFORGO ioctl generic. And put a disclaimer on WAITFORVSYNC, it must not be used in panning use-case. [Hiremath, Vaibhav] Also let me bring another point here, If I understand correctly most of the application libraries (DirectFB, X, etc..) does use FBIO_WAITFORVSYNC to synchronize with HW, and manage ping pong mechanism. With this finding, in case of OMAP3 we have to use OMAPFB_WAITFORGO (breaking standard applications). Thanks, Vaibhav -- Måns Rullgård m...@mansr.com -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html -- 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: OMAP:DSS: possible bug in WAITFOR_VSYNC ioctl
On Fri, Nov 26, 2010 at 05:38:11PM +0530, ext Hiremath, Vaibhav wrote: -Original Message- From: Hiremath, Vaibhav Sent: Friday, November 26, 2010 5:34 PM To: 'Måns Rullgård'; linux-omap@vger.kernel.org Subject: RE: OMAP:DSS: possible bug in WAITFOR_VSYNC ioctl -Original Message- From: linux-omap-ow...@vger.kernel.org [mailto:linux-omap- ow...@vger.kernel.org] On Behalf Of Måns Rullgård Sent: Friday, November 26, 2010 2:09 PM To: linux-omap@vger.kernel.org Subject: Re: OMAP:DSS: possible bug in WAITFOR_VSYNC ioctl Hiremath, Vaibhav hvaib...@ti.com writes: -Original Message- From: Ville Syrjälä [mailto:ville.syrj...@nokia.com] Sent: Wednesday, November 24, 2010 10:01 PM To: Hiremath, Vaibhav Cc: Tomi Valkeinen; linux-omap@vger.kernel.org Subject: Re: OMAP:DSS: possible bug in WAITFOR_VSYNC ioctl On Wed, Nov 24, 2010 at 03:39:44PM +0530, ext Hiremath, Vaibhav wrote: -Original Message- From: Tomi Valkeinen [mailto:tomi.valkei...@nokia.com] Sent: Wednesday, November 24, 2010 2:28 PM To: Hiremath, Vaibhav Cc: linux-omap@vger.kernel.org Subject: Re: OMAP:DSS: possible bug in WAITFOR_VSYNC ioctl On Tue, 2010-11-23 at 23:46 +0530, ext Hiremath, Vaibhav wrote: Hi, snip snip.. As far as WAITFORGO is concerned, I think GO bit concept is something OMAP notion/term and doesn't make sense to standardize it. Atleast I am not aware of any other architecture having GO bit. Naming is minor detail. Feel free to suggest a better one. [Hiremath, Vaibhav] If I fail to convince on this, then I think the only left option is to make WAITFORGO ioctl generic. And put a disclaimer on WAITFORVSYNC, it must not be used in panning use-case. [Hiremath, Vaibhav] Also let me bring another point here, If I understand correctly most of the application libraries (DirectFB, X, etc..) does use FBIO_WAITFORVSYNC to synchronize with HW, and manage ping pong mechanism. DirectFB uses it also for waiting for vsync. With this finding, in case of OMAP3 we have to use OMAPFB_WAITFORGO (breaking standard applications). Applications using the standard fbdev API won't work with manual update displays anyway. You need omapfb specific code to handle it so having another small difference is not a big deal. In DirectFB the that's trivial since there's already a simple omap gfxdriver where you could override the default flip functionality with WAITFORGO based stuff. Or, as I said, you could add another standard ioctl and fix up userspace to use it where appropriate and if the kernel driver supports it. -- Ville Syrjälä -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 2/2] enabled vdda_dac regulator support tvout on rx51
On Fri, Nov 26, 2010 at 11:56:35AM +0200, Srikar wrote:
On 11/25/2010 06:11 PM, ext Mark Brown wrote:
On Thu, Nov 25, 2010 at 05:52:23PM +0200, Srikar wrote:
+static struct regulator_consumer_supply rx51_vdac_supply[] = {
+ {
+#if defined(CONFIG_FB_OMAP2) || defined(CONFIG_FB_OMAP2_MODULE)
The ifdefs here aren't really saving much...
Currently rx51_display_device is defined under same
ifdefs(CONFIG_FB_OMAP2,CONFIG_FB_OMAP2_MODULE)
as extern and also in board-rx51-video.c display devices are under same
ifdefs,So used to not
break compilation when CONFIG_FB_OMAP2,CONFIG_FB_OMAP2_MODULE not defined.
If you convert to usign dev_name as is better practice anyway this
won't be an issue.
+ .supply = vdda_dac,
+ .dev= rx51_display_device.dev,
dev_name is preferred, though I'm not sure if we'll ever get round to
phasing out plain dev.
Currently difficult to use .dev_name .
because...
--
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: OMAP:DSS: possible bug in WAITFOR_VSYNC ioctl
-Original Message- From: Ville Syrjälä [mailto:ville.syrj...@nokia.com] Sent: Friday, November 26, 2010 6:26 PM To: Hiremath, Vaibhav Cc: Måns Rullgård; linux-omap@vger.kernel.org; linux-fb...@vger.kernel.org Subject: Re: OMAP:DSS: possible bug in WAITFOR_VSYNC ioctl On Fri, Nov 26, 2010 at 05:38:11PM +0530, ext Hiremath, Vaibhav wrote: -Original Message- From: Hiremath, Vaibhav Sent: Friday, November 26, 2010 5:34 PM To: 'Måns Rullgård'; linux-omap@vger.kernel.org Subject: RE: OMAP:DSS: possible bug in WAITFOR_VSYNC ioctl -Original Message- From: linux-omap-ow...@vger.kernel.org [mailto:linux-omap- ow...@vger.kernel.org] On Behalf Of Måns Rullgård Sent: Friday, November 26, 2010 2:09 PM To: linux-omap@vger.kernel.org Subject: Re: OMAP:DSS: possible bug in WAITFOR_VSYNC ioctl Hiremath, Vaibhav hvaib...@ti.com writes: -Original Message- From: Ville Syrjälä [mailto:ville.syrj...@nokia.com] Sent: Wednesday, November 24, 2010 10:01 PM To: Hiremath, Vaibhav Cc: Tomi Valkeinen; linux-omap@vger.kernel.org Subject: Re: OMAP:DSS: possible bug in WAITFOR_VSYNC ioctl On Wed, Nov 24, 2010 at 03:39:44PM +0530, ext Hiremath, Vaibhav wrote: -Original Message- From: Tomi Valkeinen [mailto:tomi.valkei...@nokia.com] Sent: Wednesday, November 24, 2010 2:28 PM To: Hiremath, Vaibhav Cc: linux-omap@vger.kernel.org Subject: Re: OMAP:DSS: possible bug in WAITFOR_VSYNC ioctl On Tue, 2010-11-23 at 23:46 +0530, ext Hiremath, Vaibhav wrote: Hi, snip snip.. As far as WAITFORGO is concerned, I think GO bit concept is something OMAP notion/term and doesn't make sense to standardize it. Atleast I am not aware of any other architecture having GO bit. Naming is minor detail. Feel free to suggest a better one. [Hiremath, Vaibhav] If I fail to convince on this, then I think the only left option is to make WAITFORGO ioctl generic. And put a disclaimer on WAITFORVSYNC, it must not be used in panning use-case. [Hiremath, Vaibhav] Also let me bring another point here, If I understand correctly most of the application libraries (DirectFB, X, etc..) does use FBIO_WAITFORVSYNC to synchronize with HW, and manage ping pong mechanism. DirectFB uses it also for waiting for vsync. [Hiremath, Vaibhav] Mat, I am not expert on DirectFb stuff; can you please help me to understand what the use-case is? What DirectFB does/expects on this? Thanks, Vaibhav With this finding, in case of OMAP3 we have to use OMAPFB_WAITFORGO (breaking standard applications). Applications using the standard fbdev API won't work with manual update displays anyway. You need omapfb specific code to handle it so having another small difference is not a big deal. In DirectFB the that's trivial since there's already a simple omap gfxdriver where you could override the default flip functionality with WAITFORGO based stuff. Or, as I said, you could add another standard ioctl and fix up userspace to use it where appropriate and if the kernel driver supports it. -- Ville Syrjälä -- 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: OMAP:DSS: possible bug in WAITFOR_VSYNC ioctl
On Fri, Nov 26, 2010 at 2:55 PM, Ville Syrjälä ville.syrj...@nokia.com wrote: On Fri, Nov 26, 2010 at 05:38:11PM +0530, ext Hiremath, Vaibhav wrote: With this finding, in case of OMAP3 we have to use OMAPFB_WAITFORGO (breaking standard applications). Applications using the standard fbdev API won't work with manual update displays anyway. You need omapfb specific code to handle it so having another small difference is not a big deal. In DirectFB the that's trivial since there's already a simple omap gfxdriver where you could override the default flip functionality with WAITFORGO based stuff. Or, as I said, you could add another standard ioctl and fix up userspace to use it where appropriate and if the kernel driver supports it. That sounds more appealing to me: there's no point in having omap-specific interfaces if they can be standard. -- 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: [RFC/PATCH v6 00/12] Media controller (core and V4L2)
Hi Mark, On Thursday 25 November 2010 15:28:04 Mark Brown wrote: On Thu, Nov 25, 2010 at 03:28:07AM +0100, Laurent Pinchart wrote: I want to emphasize that the media controller API does *not* replace the V4L, DVB or ALSA APIs. It complements them. Overall this looks relatively good and should be mappable onto the embedded audio stack. Thanks a lot for the review. I'd need to sit down and actually do that to go into too much specific detail but the only real issue I see is working out how the control aspects of this interact with the control in ALSA. The simplest thing would be to have the userspace API be read only for ALSA devices, I guess. That sounds good, especially for the first step. -- Regards, Laurent Pinchart -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC/PATCH v6 03/12] media: Entities, pads and links
Hi Mark, On Thursday 25 November 2010 16:49:52 Mark Brown wrote: On Thu, Nov 25, 2010 at 04:40:41PM +0100, Laurent Pinchart wrote: On Thursday 25 November 2010 14:36:50 Mark Brown wrote: On Thu, Nov 25, 2010 at 03:28:10AM +0100, Laurent Pinchart wrote: + MEDIA_LINK_FLAG_ACTIVE indicates that the link is active and can be + used to transfer media data. When two or more links target a sink pad, + only one of them can be active at a time. Is this supposed to reflect the current state (if the link is carrying data right now) or if it's possible for the link to carry data? It's supposed to reflect whether the link can carry data. Think of the active flag as a valve on a pipe. If the valve is open, the link is active. If the valve is closed, the link is inactive. This is unrelated to whether water actually flows through the pipe. This seems a confusing name, then - I'd expect an active link to be one which is actually carrying data rather than one which is available to carry data. How a more neutrally worded name such as connected (which is what ASoC uses currently)? In our current vocabulary connected refers to entities between which a link exist, regardless of the link state (valve opened or valve closed). I'm not totally happy with active either, but if we replace it with connected we need another word to replace current uses of connected. This also falls through into the power management stuff, we don't want to be powering things up unless they're actually doing something right now. Immutable links have no valve (in theory you could have an inactive immutable link, but that's not very useful, unless we define immutable as no user- controllable valve, in which case it might be better to rename it as read- only, or create separate immutable and read-only flags - just brainstorming here). That was what I was expecting immutable to mean - no user control. A link that's permanantly wired can have the data flow controlled through its inputs and outputs, even if it is not itself controllable. -- Regards, Laurent Pinchart -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC/PATCH v6 03/12] media: Entities, pads and links
On Fri, Nov 26, 2010 at 03:13:36PM +0100, Laurent Pinchart wrote: On Thursday 25 November 2010 16:49:52 Mark Brown wrote: On Thu, Nov 25, 2010 at 04:40:41PM +0100, Laurent Pinchart wrote: It's supposed to reflect whether the link can carry data. Think of the active flag as a valve on a pipe. If the valve is open, the link is active. If the valve is closed, the link is inactive. This is unrelated to whether water actually flows through the pipe. This seems a confusing name, then - I'd expect an active link to be one which is actually carrying data rather than one which is available to carry data. How a more neutrally worded name such as connected (which is what ASoC uses currently)? In our current vocabulary connected refers to entities between which a link exist, regardless of the link state (valve opened or valve closed). I'm not totally happy with active either, but if we replace it with connected we need another word to replace current uses of connected. Linked? -- 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/7] omap3630: nand: fix device size to work in polled mode
zoom3 and 3630-sdp having the x16 nand device. This patch configure gpmc as x16 and select the currect function in driver for polled mode (without prefetch enable) transfer. Signed-off-by: Sukumar Ghorai s-gho...@ti.com --- arch/arm/mach-omap2/board-flash.c |3 +++ 1 files changed, 3 insertions(+), 0 deletions(-) diff --git a/arch/arm/mach-omap2/board-flash.c b/arch/arm/mach-omap2/board-flash.c index fd38c05..001c605 100644 --- a/arch/arm/mach-omap2/board-flash.c +++ b/arch/arm/mach-omap2/board-flash.c @@ -145,6 +145,9 @@ __init board_nand_init(struct mtd_partition *nand_parts, u8 nr_parts, u8 cs) board_nand_data.parts = nand_parts; board_nand_data.nr_parts= nr_parts; + if (cpu_is_omap3630()) + board_nand_data.devsize = 1; + gpmc_nand_init(board_nand_data); } #else -- 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
[PATCH 2/7] omap3: nand: configurable transfer type per board
nand transfer type (sDMA, Polled, prefetch) can be select from board file,
enabling all transfer type in driver, by default.
this helps in multi-omap build and to select different transfer type for
different board.
Signed-off-by: Sukumar Ghorai s-gho...@ti.com
---
arch/arm/plat-omap/include/plat/nand.h |7 +++
drivers/mtd/nand/Kconfig | 17 --
drivers/mtd/nand/omap2.c | 92 +++
3 files changed, 40 insertions(+), 76 deletions(-)
diff --git a/arch/arm/plat-omap/include/plat/nand.h
b/arch/arm/plat-omap/include/plat/nand.h
index 6562cd0..78c0bdb 100644
--- a/arch/arm/plat-omap/include/plat/nand.h
+++ b/arch/arm/plat-omap/include/plat/nand.h
@@ -10,6 +10,12 @@
#include linux/mtd/partitions.h
+enum nand_io {
+ NAND_OMAP_PREFETCH_POLLED = 0, /* prefetch polled mode, default */
+ NAND_OMAP_POLLED, /* polled mode, without prefetch */
+ NAND_OMAP_PREFETCH_DMA /* prefetch enabled sDMA mode */
+};
+
struct omap_nand_platform_data {
unsigned intoptions;
int cs;
@@ -20,6 +26,7 @@ struct omap_nand_platform_data {
int (*nand_setup)(void);
int (*dev_ready)(struct omap_nand_platform_data *);
int dma_channel;
+ enum nand_ioxfer_type;
unsigned long phys_base;
int devsize;
};
diff --git a/drivers/mtd/nand/Kconfig b/drivers/mtd/nand/Kconfig
index 8229802..89bb297 100644
--- a/drivers/mtd/nand/Kconfig
+++ b/drivers/mtd/nand/Kconfig
@@ -105,23 +105,6 @@ config MTD_NAND_OMAP2
help
Support for NAND flash on Texas Instruments OMAP2 and OMAP3
platforms.
-config MTD_NAND_OMAP_PREFETCH
- bool GPMC prefetch support for NAND Flash device
- depends on MTD_NAND_OMAP2
- default y
- help
-The NAND device can be accessed for Read/Write using GPMC PREFETCH
engine
-to improve the performance.
-
-config MTD_NAND_OMAP_PREFETCH_DMA
- depends on MTD_NAND_OMAP_PREFETCH
- bool DMA mode
- default n
- help
-The GPMC PREFETCH engine can be configured eigther in MPU interrupt
mode
-or in DMA interrupt mode.
-Say y for DMA mode or MPU mode will be used
-
config MTD_NAND_IDS
tristate
diff --git a/drivers/mtd/nand/omap2.c b/drivers/mtd/nand/omap2.c
index 15682ec..6011e90 100644
--- a/drivers/mtd/nand/omap2.c
+++ b/drivers/mtd/nand/omap2.c
@@ -96,27 +96,6 @@
static const char *part_probes[] = { cmdlinepart, NULL };
#endif
-#ifdef CONFIG_MTD_NAND_OMAP_PREFETCH
-static int use_prefetch = 1;
-
-/* modprobe ... use_prefetch=0 etc */
-module_param(use_prefetch, bool, 0);
-MODULE_PARM_DESC(use_prefetch, enable/disable use of PREFETCH);
-
-#ifdef CONFIG_MTD_NAND_OMAP_PREFETCH_DMA
-static int use_dma = 1;
-
-/* modprobe ... use_dma=0 etc */
-module_param(use_dma, bool, 0);
-MODULE_PARM_DESC(use_dma, enable/disable use of DMA);
-#else
-static const int use_dma;
-#endif
-#else
-const int use_prefetch;
-static const int use_dma;
-#endif
-
struct omap_nand_info {
struct nand_hw_control controller;
struct omap_nand_platform_data *pdata;
@@ -324,7 +303,6 @@ static void omap_write_buf_pref(struct mtd_info *mtd,
}
}
-#ifdef CONFIG_MTD_NAND_OMAP_PREFETCH_DMA
/*
* omap_nand_dma_cb: callback on the completion of dma transfer
* @lch: logical channel
@@ -426,14 +404,6 @@ out_copy:
: omap_write_buf8(mtd, (u_char *) addr, len);
return 0;
}
-#else
-static void omap_nand_dma_cb(int lch, u16 ch_status, void *data) {}
-static inline int omap_nand_dma_transfer(struct mtd_info *mtd, void *addr,
- unsigned int len, int is_write)
-{
- return 0;
-}
-#endif
/**
* omap_read_buf_dma_pref - read data from NAND controller into buffer
@@ -842,28 +812,13 @@ static int __devinit omap_nand_probe(struct
platform_device *pdev)
info-nand.chip_delay = 50;
}
- if (use_prefetch) {
-
+ switch (pdata-xfer_type) {
+ case NAND_OMAP_PREFETCH_POLLED:
info-nand.read_buf = omap_read_buf_pref;
info-nand.write_buf = omap_write_buf_pref;
- if (use_dma) {
- err = omap_request_dma(OMAP24XX_DMA_GPMC, NAND,
- omap_nand_dma_cb, info-comp, info-dma_ch);
- if (err 0) {
- info-dma_ch = -1;
- printk(KERN_WARNING DMA request failed.
-Non-dma data transfer mode\n);
- } else {
- omap_set_dma_dest_burst_mode(info-dma_ch,
- OMAP_DMA_DATA_BURST_16);
-
[PATCH v6 0/7] nand prefetch-irq support and ecc layout chanage
The following set of patches applies on linux-2.6. The main motivations behind this patch series are - 1. support NAND I/O in irq mode. 2. support of different ECC schema. 3. also to make ecc layout as like in romcode ecc layout v6: configurable transfer type from board file; #define irq number used for nand-irq v5: http://www.mail-archive.com/linux-omap@vger.kernel.org/msg35860.html This address the input as to support the irq_chained in GPMC. And resend of http://www.mail-archive.com/linux-omap@vger.kernel.org/msg35848.html v4: http://www.mail-archive.com/linux-omap@vger.kernel.org/msg34882.html and resend of http://www.mail-archive.com/linux-omap@vger.kernel.org/msg32689.html v3: http://www.mail-archive.com/linux-omap@vger.kernel.org/msg32071.html Rebase on latest codebase and previous patch(posted). http://www.mail-archive.com/linux-omap@vger.kernel.org/msg31963.html v2: Rebase on latest codebase and previous patch(posted). http://www.mail-archive.com/linux-omap@vger.kernel.org/msg31471.html v1: http://www.mail-archive.com/linux-omap@vger.kernel.org/msg2.html Sukumar Ghorai (7): omap3630: nand: fix device size to work in polled mode omap3: nand: configurable transfer type per board omap: gpmc: enable irq mode in gpmc omap3: nand: prefetch in irq mode support omap3: nand: configurable fifo threshold to gain the throughput omap: nand: ecc layout select from board file omap: nand: making ecc layout as compatible with romcode ecc arch/arm/mach-omap2/board-2430sdp.c|1 + arch/arm/mach-omap2/board-3430sdp.c|1 + arch/arm/mach-omap2/board-3630sdp.c|1 + arch/arm/mach-omap2/board-4430sdp.c|2 + arch/arm/mach-omap2/board-am3517evm.c |2 + arch/arm/mach-omap2/board-apollon.c|1 + arch/arm/mach-omap2/board-cm-t35.c |1 + arch/arm/mach-omap2/board-devkit8000.c |1 + arch/arm/mach-omap2/board-flash.c |7 + arch/arm/mach-omap2/board-generic.c|2 + arch/arm/mach-omap2/board-h4.c |1 + arch/arm/mach-omap2/board-igep0020.c |1 + arch/arm/mach-omap2/board-ldp.c|1 + arch/arm/mach-omap2/board-n8x0.c |2 + arch/arm/mach-omap2/board-omap3beagle.c|1 + arch/arm/mach-omap2/board-omap3evm.c |2 + arch/arm/mach-omap2/board-omap3pandora.c |2 + arch/arm/mach-omap2/board-omap3stalker.c |1 + arch/arm/mach-omap2/board-omap3touchbook.c |1 + arch/arm/mach-omap2/board-omap4panda.c |2 + arch/arm/mach-omap2/board-overo.c |1 + arch/arm/mach-omap2/board-rx51.c |1 + arch/arm/mach-omap2/board-zoom2.c |2 + arch/arm/mach-omap2/board-zoom3.c |2 + arch/arm/mach-omap2/gpmc.c | 50 - arch/arm/mach-omap2/io.c |2 - arch/arm/plat-omap/include/plat/gpmc.h | 16 ++- arch/arm/plat-omap/include/plat/irqs.h |9 +- arch/arm/plat-omap/include/plat/nand.h | 11 + drivers/mtd/nand/Kconfig | 17 -- drivers/mtd/nand/omap2.c | 314 ++-- 31 files changed, 364 insertions(+), 94 deletions(-) -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v6 6/7] omap: nand: ecc layout select from board file
This patch makes it possible to select sw or hw (different layout options)
ecc scheme supported by omap nand driver. And hw ecc layout selected for
sdp and zoom boards, by default.
Signed-off-by: Vimal Singh vimalsi...@ti.com
Signed-off-by: Sukumar Ghorai s-gho...@ti.com
---
arch/arm/mach-omap2/board-flash.c |1 +
arch/arm/plat-omap/include/plat/gpmc.h |7 +++
arch/arm/plat-omap/include/plat/nand.h |2 ++
drivers/mtd/nand/omap2.c |5 +
4 files changed, 11 insertions(+), 4 deletions(-)
diff --git a/arch/arm/mach-omap2/board-flash.c
b/arch/arm/mach-omap2/board-flash.c
index 78abcd9..3340427 100644
--- a/arch/arm/mach-omap2/board-flash.c
+++ b/arch/arm/mach-omap2/board-flash.c
@@ -150,6 +150,7 @@ __init board_nand_init(struct mtd_partition *nand_parts, u8
nr_parts, u8 cs)
if (cpu_is_omap3630())
board_nand_data.devsize = 1;
+ board_nand_data.ecc_opt = OMAP_ECC_HAMMING_CODE_DIFF_LAYOUT;
board_nand_data.gpmc_irq = OMAP_GPMC_IRQ_BASE + cs;
gpmc_nand_init(board_nand_data);
}
diff --git a/arch/arm/plat-omap/include/plat/gpmc.h
b/arch/arm/plat-omap/include/plat/gpmc.h
index fb82335..ca6e8db 100644
--- a/arch/arm/plat-omap/include/plat/gpmc.h
+++ b/arch/arm/plat-omap/include/plat/gpmc.h
@@ -86,6 +86,13 @@
#define PREFETCH_FIFOTHRESHOLD_MAX 0x40
#define PREFETCH_FIFOTHRESHOLD(val)(val 8)
+enum omap_ecc {
+ OMAP_ECC_HAMMING_CODE_DIFF_LAYOUT = 0,
+ /* 1-bit s/w ecc and layout different from romcode */
+ OMAP_ECC_HAMMING_CODE_HW,/* 1-bit ecc, romcode layout */
+ OMAP_ECC_HAMMING_CODE_SW,/* 1-bit ecc, romcode layout */
+};
+
/*
* Note that all values in this struct are in nanoseconds, while
* the register values are in gpmc_fck cycles.
diff --git a/arch/arm/plat-omap/include/plat/nand.h
b/arch/arm/plat-omap/include/plat/nand.h
index ae5e053..d86d1ec 100644
--- a/arch/arm/plat-omap/include/plat/nand.h
+++ b/arch/arm/plat-omap/include/plat/nand.h
@@ -8,6 +8,7 @@
* published by the Free Software Foundation.
*/
+#include plat/gpmc.h
#include linux/mtd/partitions.h
enum nand_io {
@@ -31,6 +32,7 @@ struct omap_nand_platform_data {
enum nand_ioxfer_type;
unsigned long phys_base;
int devsize;
+ enum omap_ecc ecc_opt;
};
/* minimum size for IO mapping */
diff --git a/drivers/mtd/nand/omap2.c b/drivers/mtd/nand/omap2.c
index fea9f59..0937001 100644
--- a/drivers/mtd/nand/omap2.c
+++ b/drivers/mtd/nand/omap2.c
@@ -7,6 +7,7 @@
* it under the terms of the GNU General Public License version 2 as
* published by the Free Software Foundation.
*/
+#define CONFIG_MTD_NAND_OMAP_HWECC
#include linux/platform_device.h
#include linux/dma-mapping.h
@@ -618,8 +619,6 @@ static int omap_verify_buf(struct mtd_info *mtd, const
u_char * buf, int len)
return 0;
}
-#ifdef CONFIG_MTD_NAND_OMAP_HWECC
-
/**
* gen_true_ecc - This function will generate true ECC value
* @ecc_buf: buffer to store ecc code
@@ -839,8 +838,6 @@ static void omap_enable_hwecc(struct mtd_info *mtd, int
mode)
gpmc_enable_hwecc(info-gpmc_cs, mode, dev_width, info-nand.ecc.size);
}
-#endif
-
/**
* omap_wait - wait until the command is done
* @mtd: MTD device structure
--
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
[PATCH v6 5/7] omap3: nand: configurable fifo threshold to gain the throughput
Configure the FIFO THREASHOLD value different for read and write to keep busy
both filling and to drain out of FIFO at reading and writing.
Signed-off-by: Vimal Singh vimalsi...@ti.com
Signed-off-by: Sukumar Ghorai s-gho...@ti.com
---
arch/arm/mach-omap2/gpmc.c | 11 +++
arch/arm/plat-omap/include/plat/gpmc.h |5 -
drivers/mtd/nand/omap2.c | 24 +++-
3 files changed, 26 insertions(+), 14 deletions(-)
diff --git a/arch/arm/mach-omap2/gpmc.c b/arch/arm/mach-omap2/gpmc.c
index cfaf357..b26b1a5 100644
--- a/arch/arm/mach-omap2/gpmc.c
+++ b/arch/arm/mach-omap2/gpmc.c
@@ -59,7 +59,6 @@
#define GPMC_CHUNK_SHIFT 24 /* 16 MB */
#define GPMC_SECTION_SHIFT 28 /* 128 MB */
-#define PREFETCH_FIFOTHRESHOLD (0x40 8)
#define CS_NUM_SHIFT 24
#define ENABLE_PREFETCH(0x1 7)
#define DMA_MPU_MODE 2
@@ -595,15 +594,19 @@ EXPORT_SYMBOL(gpmc_nand_write);
/**
* gpmc_prefetch_enable - configures and starts prefetch transfer
* @cs: cs (chip select) number
+ * @fifo_th: fifo threshold to be used for read/ write
* @dma_mode: dma mode enable (1) or disable (0)
* @u32_count: number of bytes to be transferred
* @is_write: prefetch read(0) or write post(1) mode
*/
-int gpmc_prefetch_enable(int cs, int dma_mode,
+int gpmc_prefetch_enable(int cs, int fifo_th, int dma_mode,
unsigned int u32_count, int is_write)
{
- if (!(gpmc_read_reg(GPMC_PREFETCH_CONTROL))) {
+ if (fifo_th PREFETCH_FIFOTHRESHOLD_MAX) {
+ printk(KERN_ERR PREFETCH Fifo Threshold is not supported\n);
+ return -1;
+ } else if (!(gpmc_read_reg(GPMC_PREFETCH_CONTROL))) {
/* Set the amount of bytes to be prefetched */
gpmc_write_reg(GPMC_PREFETCH_CONFIG2, u32_count);
@@ -611,7 +614,7 @@ int gpmc_prefetch_enable(int cs, int dma_mode,
* enable the engine. Set which cs is has requested for.
*/
gpmc_write_reg(GPMC_PREFETCH_CONFIG1, ((cs CS_NUM_SHIFT) |
- PREFETCH_FIFOTHRESHOLD |
+ PREFETCH_FIFOTHRESHOLD(fifo_th) |
ENABLE_PREFETCH |
(dma_mode DMA_MPU_MODE) |
(0x1 is_write)));
diff --git a/arch/arm/plat-omap/include/plat/gpmc.h
b/arch/arm/plat-omap/include/plat/gpmc.h
index 054e704..fb82335 100644
--- a/arch/arm/plat-omap/include/plat/gpmc.h
+++ b/arch/arm/plat-omap/include/plat/gpmc.h
@@ -83,6 +83,9 @@
#define GPMC_IRQ_FIFOEVENTENABLE 0x01
#define GPMC_IRQ_COUNT_EVENT 0x02
+#define PREFETCH_FIFOTHRESHOLD_MAX 0x40
+#define PREFETCH_FIFOTHRESHOLD(val)(val 8)
+
/*
* Note that all values in this struct are in nanoseconds, while
* the register values are in gpmc_fck cycles.
@@ -133,7 +136,7 @@ extern int gpmc_cs_request(int cs, unsigned long size,
unsigned long *base);
extern void gpmc_cs_free(int cs);
extern int gpmc_cs_set_reserved(int cs, int reserved);
extern int gpmc_cs_reserved(int cs);
-extern int gpmc_prefetch_enable(int cs, int dma_mode,
+extern int gpmc_prefetch_enable(int cs, int fifo_th, int dma_mode,
unsigned int u32_count, int is_write);
extern int gpmc_prefetch_reset(int cs);
extern void omap3_gpmc_save_context(void);
diff --git a/drivers/mtd/nand/omap2.c b/drivers/mtd/nand/omap2.c
index c4bbbd0..fea9f59 100644
--- a/drivers/mtd/nand/omap2.c
+++ b/drivers/mtd/nand/omap2.c
@@ -243,7 +243,8 @@ static void omap_read_buf_pref(struct mtd_info *mtd, u_char
*buf, int len)
}
/* configure and start prefetch transfer */
- ret = gpmc_prefetch_enable(info-gpmc_cs, 0x0, len, 0x0);
+ ret = gpmc_prefetch_enable(info-gpmc_cs,
+ PREFETCH_FIFOTHRESHOLD_MAX, 0x0, len, 0x0);
if (ret) {
/* PFPW engine is busy, use cpu copy method */
if (info-nand.options NAND_BUSWIDTH_16)
@@ -287,7 +288,8 @@ static void omap_write_buf_pref(struct mtd_info *mtd,
}
/* configure and start prefetch transfer */
- ret = gpmc_prefetch_enable(info-gpmc_cs, 0x0, len, 0x1);
+ ret = gpmc_prefetch_enable(info-gpmc_cs,
+ PREFETCH_FIFOTHRESHOLD_MAX, 0x0, len, 0x1);
if (ret) {
/* PFPW engine is busy, use cpu copy method */
if (info-nand.options NAND_BUSWIDTH_16)
@@ -340,10 +342,11 @@ static inline int omap_nand_dma_transfer(struct mtd_info
*mtd, void *addr,
dma_addr_t dma_addr;
int ret;
- /* The fifo depth is 64 bytes. We have a sync at each frame and frame
-* length is 64 bytes.
+ /* The fifo depth is 64 bytes max.
+* But configure the FIFO-threahold to 32 to get a sync at each frame
+*
[PATCH v6 7/7] omap: nand: making ecc layout as compatible with romcode ecc
This patch overrides nand ecc layout and bad block descriptor (for 8-bit
device) to support hw ecc in romcode layout. So as to have in sync with ecc
layout throughout; i.e. x-loader, u-boot and kernel.
This patch also enables to use romcode ecc for spd and zoom, by default.
This enables to flash x-loader, u-boot, kernel, FS images from kernel itself
and compatiable with other tools.
Signed-off-by: Vimal Singh vimalsi...@ti.com
Signed-off-by: Sukumar Ghorai s-gho...@ti.com
---
drivers/mtd/nand/omap2.c | 34 ++
1 files changed, 34 insertions(+), 0 deletions(-)
diff --git a/drivers/mtd/nand/omap2.c b/drivers/mtd/nand/omap2.c
index 0937001..d4c508a 100644
--- a/drivers/mtd/nand/omap2.c
+++ b/drivers/mtd/nand/omap2.c
@@ -98,6 +98,20 @@
static const char *part_probes[] = { cmdlinepart, NULL };
#endif
+/* oob info generated runtime depending on ecc algorithm and layout selected */
+static struct nand_ecclayout omap_oobinfo;
+/* Define some generic bad / good block scan pattern which are used
+ * while scanning a device for factory marked good / bad blocks
+ */
+static uint8_t scan_ff_pattern[] = { 0xff };
+static struct nand_bbt_descr bb_descrip_flashbased = {
+ .options = NAND_BBT_SCANEMPTY | NAND_BBT_SCANALLPAGES,
+ .offs = 0,
+ .len = 1,
+ .pattern = scan_ff_pattern,
+};
+
+
struct omap_nand_info {
struct nand_hw_control controller;
struct omap_nand_platform_data *pdata;
@@ -907,6 +921,7 @@ static int __devinit omap_nand_probe(struct platform_device
*pdev)
struct omap_nand_info *info;
struct omap_nand_platform_data *pdata;
int err;
+ int i, offset;
pdata = pdev-dev.platform_data;
if (pdata == NULL) {
@@ -1051,6 +1066,25 @@ static int __devinit omap_nand_probe(struct
platform_device *pdev)
}
+ /* rom code layout */
+ if (pdata-ecc_opt != OMAP_ECC_HAMMING_CODE_DIFF_LAYOUT) {
+ offset = (info-nand.options NAND_BUSWIDTH_16) ? 2 : 1;
+ if (info-mtd.oobsize == 16) {
+ info-nand.badblock_pattern = bb_descrip_flashbased;
+ omap_oobinfo.eccbytes = 3;
+ } else
+ omap_oobinfo.eccbytes = 3 * 4;
+
+ for (i = 0; i omap_oobinfo.eccbytes; i++)
+ omap_oobinfo.eccpos[i] = i+offset;
+
+ omap_oobinfo.oobfree-offset = offset + omap_oobinfo.eccbytes;
+ omap_oobinfo.oobfree-length = info-mtd.oobsize -
+ (offset + omap_oobinfo.eccbytes);
+
+ info-nand.ecc.layout = omap_oobinfo;
+ }
+
#ifdef CONFIG_MTD_PARTITIONS
err = parse_mtd_partitions(info-mtd, part_probes, info-parts, 0);
if (err 0)
--
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
[PATCH v6 3/7] omap: gpmc: enable irq mode in gpmc
add support the irq mode in GPMC. gpmc_init() function move after omap_init_irq() as it has dependecy on irq. Signed-off-by: Sukumar Ghorai s-gho...@ti.com --- arch/arm/mach-omap2/board-2430sdp.c|1 + arch/arm/mach-omap2/board-3430sdp.c|1 + arch/arm/mach-omap2/board-3630sdp.c|1 + arch/arm/mach-omap2/board-4430sdp.c|2 + arch/arm/mach-omap2/board-am3517evm.c |2 + arch/arm/mach-omap2/board-apollon.c|1 + arch/arm/mach-omap2/board-cm-t35.c |1 + arch/arm/mach-omap2/board-devkit8000.c |1 + arch/arm/mach-omap2/board-generic.c|2 + arch/arm/mach-omap2/board-h4.c |1 + arch/arm/mach-omap2/board-igep0020.c |1 + arch/arm/mach-omap2/board-ldp.c|1 + arch/arm/mach-omap2/board-n8x0.c |2 + arch/arm/mach-omap2/board-omap3beagle.c|1 + arch/arm/mach-omap2/board-omap3evm.c |2 + arch/arm/mach-omap2/board-omap3pandora.c |2 + arch/arm/mach-omap2/board-omap3stalker.c |1 + arch/arm/mach-omap2/board-omap3touchbook.c |1 + arch/arm/mach-omap2/board-omap4panda.c |2 + arch/arm/mach-omap2/board-overo.c |1 + arch/arm/mach-omap2/board-rx51.c |1 + arch/arm/mach-omap2/board-zoom2.c |2 + arch/arm/mach-omap2/board-zoom3.c |2 + arch/arm/mach-omap2/gpmc.c | 39 ++- arch/arm/mach-omap2/io.c |2 - arch/arm/plat-omap/include/plat/gpmc.h |4 +++ arch/arm/plat-omap/include/plat/irqs.h |9 +- 27 files changed, 81 insertions(+), 5 deletions(-) diff --git a/arch/arm/mach-omap2/board-2430sdp.c b/arch/arm/mach-omap2/board-2430sdp.c index b527f8d..11c89dc 100644 --- a/arch/arm/mach-omap2/board-2430sdp.c +++ b/arch/arm/mach-omap2/board-2430sdp.c @@ -145,6 +145,7 @@ static void __init omap_2430sdp_init_irq(void) omap_board_config_size = ARRAY_SIZE(sdp2430_config); omap2_init_common_hw(NULL, NULL); omap_init_irq(); + gpmc_init(); omap_gpio_init(); } diff --git a/arch/arm/mach-omap2/board-3430sdp.c b/arch/arm/mach-omap2/board-3430sdp.c index 4e3742c..a040165 100644 --- a/arch/arm/mach-omap2/board-3430sdp.c +++ b/arch/arm/mach-omap2/board-3430sdp.c @@ -328,6 +328,7 @@ static void __init omap_3430sdp_init_irq(void) omap3_pm_init_cpuidle(omap3_cpuidle_params_table); omap2_init_common_hw(hyb18m512160af6_sdrc_params, NULL); omap_init_irq(); + gpmc_init(); omap_gpio_init(); } diff --git a/arch/arm/mach-omap2/board-3630sdp.c b/arch/arm/mach-omap2/board-3630sdp.c index bbcf580..17983ed 100644 --- a/arch/arm/mach-omap2/board-3630sdp.c +++ b/arch/arm/mach-omap2/board-3630sdp.c @@ -76,6 +76,7 @@ static void __init omap_sdp_init_irq(void) omap2_init_common_hw(h8mbx00u0mer0em_sdrc_params, h8mbx00u0mer0em_sdrc_params); omap_init_irq(); + gpmc_init(); omap_gpio_init(); } diff --git a/arch/arm/mach-omap2/board-4430sdp.c b/arch/arm/mach-omap2/board-4430sdp.c index df5a425..8d15604 100644 --- a/arch/arm/mach-omap2/board-4430sdp.c +++ b/arch/arm/mach-omap2/board-4430sdp.c @@ -34,6 +34,7 @@ #include plat/common.h #include plat/usb.h #include plat/mmc.h +#include plat/gpmc.h #include hsmmc.h #include timer-gp.h @@ -222,6 +223,7 @@ static void __init omap_4430sdp_init_irq(void) omap2_gp_clockevent_set_gptimer(1); #endif gic_init_irq(); + gpmc_init(); omap_gpio_init(); } diff --git a/arch/arm/mach-omap2/board-am3517evm.c b/arch/arm/mach-omap2/board-am3517evm.c index 0739950..460e3d1 100644 --- a/arch/arm/mach-omap2/board-am3517evm.c +++ b/arch/arm/mach-omap2/board-am3517evm.c @@ -35,6 +35,7 @@ #include plat/common.h #include plat/usb.h #include plat/display.h +#include plat/gpmc.h #include mux.h #include control.h @@ -392,6 +393,7 @@ static void __init am3517_evm_init_irq(void) omap2_init_common_hw(NULL, NULL); omap_init_irq(); + gpmc_init(); omap_gpio_init(); } diff --git a/arch/arm/mach-omap2/board-apollon.c b/arch/arm/mach-omap2/board-apollon.c index 2c6db1a..8264e7a 100644 --- a/arch/arm/mach-omap2/board-apollon.c +++ b/arch/arm/mach-omap2/board-apollon.c @@ -280,6 +280,7 @@ static void __init omap_apollon_init_irq(void) omap_board_config_size = ARRAY_SIZE(apollon_config); omap2_init_common_hw(NULL, NULL); omap_init_irq(); + gpmc_init(); omap_gpio_init(); apollon_init_smc91x(); } diff --git a/arch/arm/mach-omap2/board-cm-t35.c b/arch/arm/mach-omap2/board-cm-t35.c index 63f764e..7c9a834 100644 --- a/arch/arm/mach-omap2/board-cm-t35.c +++ b/arch/arm/mach-omap2/board-cm-t35.c @@ -686,6 +686,7 @@ static void __init cm_t35_init_irq(void) omap2_init_common_hw(mt46h32m32lf6_sdrc_params, mt46h32m32lf6_sdrc_params);
[PATCH v6 4/7] omap3: nand: prefetch in irq mode support
This patch enable prefetch-irq mode for nand transfer(read, write)
Signed-off-by: Vimal Singh vimalsi...@ti.com
Signed-off-by: Sukumar Ghorai s-gho...@ti.com
---
arch/arm/mach-omap2/board-flash.c |3 +
arch/arm/plat-omap/include/plat/nand.h |4 +-
drivers/mtd/nand/omap2.c | 169
3 files changed, 175 insertions(+), 1 deletions(-)
diff --git a/arch/arm/mach-omap2/board-flash.c
b/arch/arm/mach-omap2/board-flash.c
index 001c605..78abcd9 100644
--- a/arch/arm/mach-omap2/board-flash.c
+++ b/arch/arm/mach-omap2/board-flash.c
@@ -16,7 +16,9 @@
#include linux/platform_device.h
#include linux/mtd/physmap.h
#include linux/io.h
+#include plat/irqs.h
+#include plat/irqs.h
#include plat/gpmc.h
#include plat/nand.h
#include plat/onenand.h
@@ -148,6 +150,7 @@ __init board_nand_init(struct mtd_partition *nand_parts, u8
nr_parts, u8 cs)
if (cpu_is_omap3630())
board_nand_data.devsize = 1;
+ board_nand_data.gpmc_irq = OMAP_GPMC_IRQ_BASE + cs;
gpmc_nand_init(board_nand_data);
}
#else
diff --git a/arch/arm/plat-omap/include/plat/nand.h
b/arch/arm/plat-omap/include/plat/nand.h
index 78c0bdb..ae5e053 100644
--- a/arch/arm/plat-omap/include/plat/nand.h
+++ b/arch/arm/plat-omap/include/plat/nand.h
@@ -13,7 +13,8 @@
enum nand_io {
NAND_OMAP_PREFETCH_POLLED = 0, /* prefetch polled mode, default */
NAND_OMAP_POLLED, /* polled mode, without prefetch */
- NAND_OMAP_PREFETCH_DMA /* prefetch enabled sDMA mode */
+ NAND_OMAP_PREFETCH_DMA, /* prefetch enabled sDMA mode */
+ NAND_OMAP_PREFETCH_IRQ /* prefetch enabled irq mode */
};
struct omap_nand_platform_data {
@@ -26,6 +27,7 @@ struct omap_nand_platform_data {
int (*nand_setup)(void);
int (*dev_ready)(struct omap_nand_platform_data *);
int dma_channel;
+ int gpmc_irq;
enum nand_ioxfer_type;
unsigned long phys_base;
int devsize;
diff --git a/drivers/mtd/nand/omap2.c b/drivers/mtd/nand/omap2.c
index 6011e90..c4bbbd0 100644
--- a/drivers/mtd/nand/omap2.c
+++ b/drivers/mtd/nand/omap2.c
@@ -11,6 +11,7 @@
#include linux/platform_device.h
#include linux/dma-mapping.h
#include linux/delay.h
+#include linux/interrupt.h
#include linux/jiffies.h
#include linux/sched.h
#include linux/mtd/mtd.h
@@ -108,6 +109,13 @@ struct omap_nand_info {
unsigned long phys_base;
struct completion comp;
int dma_ch;
+ int gpmc_irq;
+ enum {
+ OMAP_NAND_IO_READ = 0, /* read */
+ OMAP_NAND_IO_WRITE, /* write */
+ } iomode;
+ u_char *buf;
+ int buf_len;
};
/**
@@ -436,6 +444,153 @@ static void omap_write_buf_dma_pref(struct mtd_info *mtd,
omap_nand_dma_transfer(mtd, (u_char *) buf, len, 0x1);
}
+/*
+ * omap_nand_irq - GMPC irq handler
+ * @this_irq: gpmc irq number
+ * @dev: omap_nand_info structure pointer is passed here
+ */
+static irqreturn_t omap_nand_irq(int this_irq, void *dev)
+{
+ struct omap_nand_info *info = (struct omap_nand_info *) dev;
+ u32 bytes;
+ u32 irq_stat;
+
+ irq_stat = gpmc_read_status(GPMC_GET_IRQ_STATUS);
+ bytes = gpmc_read_status(GPMC_PREFETCH_FIFO_CNT);
+ bytes = bytes 0xFFFC; /* io in multiple of 4 bytes */
+ if (info-iomode == OMAP_NAND_IO_WRITE) { /* checks for write io */
+ if (irq_stat 0x2)
+ goto done;
+
+ if (info-buf_len (info-buf_len bytes))
+ bytes = info-buf_len;
+ else if (!info-buf_len)
+ bytes = 0;
+ iowrite32_rep(info-nand.IO_ADDR_W,
+ (u32 *)info-buf, bytes 2);
+ info-buf = info-buf + bytes;
+ info-buf_len -= bytes;
+
+ } else {
+ ioread32_rep(info-nand.IO_ADDR_R,
+ (u32 *)info-buf, bytes 2);
+ info-buf = info-buf + bytes;
+
+ if (irq_stat 0x2)
+ goto done;
+ }
+ gpmc_cs_configure(info-gpmc_cs, GPMC_SET_IRQ_STATUS, irq_stat);
+ irq_stat = gpmc_read_status(GPMC_GET_IRQ_STATUS);
+
+ return IRQ_HANDLED;
+
+done:
+ complete(info-comp);
+ /* disable irq */
+ gpmc_cs_configure(info-gpmc_cs, GPMC_ENABLE_IRQ, 0);
+
+ /* clear status */
+ gpmc_cs_configure(info-gpmc_cs, GPMC_SET_IRQ_STATUS, irq_stat);
+ irq_stat = gpmc_read_status(GPMC_GET_IRQ_STATUS);
+
+ return IRQ_HANDLED;
+}
+
+/*
+ * omap_read_buf_irq_pref - read data from NAND
[PATCH] arm: plat-omap: counter_32k: use IS_ERR() instead of NULL check
clk_get() returns ERR_PTR() on error, not NULL. Signed-off-by: Vasiliy Kulikov seg...@openwall.com --- Cannot compile this driver, so it is not tested at all. arch/arm/plat-omap/counter_32k.c |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/arch/arm/plat-omap/counter_32k.c b/arch/arm/plat-omap/counter_32k.c index 155fe43..c1e0d00 100644 --- a/arch/arm/plat-omap/counter_32k.c +++ b/arch/arm/plat-omap/counter_32k.c @@ -164,7 +164,7 @@ static int __init omap_init_clocksource_32k(void) return -ENODEV; sync_32k_ick = clk_get(NULL, omap_32ksync_ick); - if (sync_32k_ick) + if (!IS_ERR(sync_32k_ick)) clk_enable(sync_32k_ick); clocksource_32k.mult = clocksource_hz2mult(32768, -- 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
Inventra Highspeed Dual Role Controller on TI OMAP 3503
Hi, Is the Inventra Highspeed Dual Role Controller silicon IP available on the TI OMAP 3503? The kernel config help documentation mentions only TI OMAP 353x and I'm not sure if that implies that it isn't present in the TI OMAP 3503 processor. Elvis Dowson -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 2/2] enabled vdda_dac regulator support tvout on rx51
* Mark Brown broo...@opensource.wolfsonmicro.com [101126 04:50]:
On Fri, Nov 26, 2010 at 11:56:35AM +0200, Srikar wrote:
On 11/25/2010 06:11 PM, ext Mark Brown wrote:
On Thu, Nov 25, 2010 at 05:52:23PM +0200, Srikar wrote:
+static struct regulator_consumer_supply rx51_vdac_supply[] = {
+{
+#if defined(CONFIG_FB_OMAP2) || defined(CONFIG_FB_OMAP2_MODULE)
The ifdefs here aren't really saving much...
By the way, all the board specific data should be __initdata eventually.
Now we're hogging memory for the regulators for all the boards compiled in..
Regards,
Tony
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH v6 0/7] nand prefetch-irq support and ecc layout chanage
Hello Grazvydas Charles, Would you please check this series in you setup and please update the status or any issue you observe? Regards, Ghorai -Original Message- From: Ghorai, Sukumar Sent: Friday, November 26, 2010 9:05 PM To: linux-omap@vger.kernel.org Cc: linux-...@lists.infradead.org; linux-arm-ker...@lists.infradead.org; Ghorai, Sukumar Subject: [PATCH v6 0/7] nand prefetch-irq support and ecc layout chanage The following set of patches applies on linux-2.6. The main motivations behind this patch series are - 1. support NAND I/O in irq mode. 2. support of different ECC schema. 3. also to make ecc layout as like in romcode ecc layout v6: configurable transfer type from board file; #define irq number used for nand-irq v5: http://www.mail-archive.com/linux-omap@vger.kernel.org/msg35860.html This address the input as to support the irq_chained in GPMC. And resend of http://www.mail-archive.com/linux-omap@vger.kernel.org/msg35848.html v4: http://www.mail-archive.com/linux-omap@vger.kernel.org/msg34882.html and resend of http://www.mail-archive.com/linux-omap@vger.kernel.org/msg32689.html v3: http://www.mail-archive.com/linux-omap@vger.kernel.org/msg32071.html Rebase on latest codebase and previous patch(posted). http://www.mail-archive.com/linux-omap@vger.kernel.org/msg31963.html v2: Rebase on latest codebase and previous patch(posted). http://www.mail-archive.com/linux-omap@vger.kernel.org/msg31471.html v1: http://www.mail-archive.com/linux-omap@vger.kernel.org/msg2.html Sukumar Ghorai (7): omap3630: nand: fix device size to work in polled mode omap3: nand: configurable transfer type per board omap: gpmc: enable irq mode in gpmc omap3: nand: prefetch in irq mode support omap3: nand: configurable fifo threshold to gain the throughput omap: nand: ecc layout select from board file omap: nand: making ecc layout as compatible with romcode ecc arch/arm/mach-omap2/board-2430sdp.c|1 + arch/arm/mach-omap2/board-3430sdp.c|1 + arch/arm/mach-omap2/board-3630sdp.c|1 + arch/arm/mach-omap2/board-4430sdp.c|2 + arch/arm/mach-omap2/board-am3517evm.c |2 + arch/arm/mach-omap2/board-apollon.c|1 + arch/arm/mach-omap2/board-cm-t35.c |1 + arch/arm/mach-omap2/board-devkit8000.c |1 + arch/arm/mach-omap2/board-flash.c |7 + arch/arm/mach-omap2/board-generic.c|2 + arch/arm/mach-omap2/board-h4.c |1 + arch/arm/mach-omap2/board-igep0020.c |1 + arch/arm/mach-omap2/board-ldp.c|1 + arch/arm/mach-omap2/board-n8x0.c |2 + arch/arm/mach-omap2/board-omap3beagle.c|1 + arch/arm/mach-omap2/board-omap3evm.c |2 + arch/arm/mach-omap2/board-omap3pandora.c |2 + arch/arm/mach-omap2/board-omap3stalker.c |1 + arch/arm/mach-omap2/board-omap3touchbook.c |1 + arch/arm/mach-omap2/board-omap4panda.c |2 + arch/arm/mach-omap2/board-overo.c |1 + arch/arm/mach-omap2/board-rx51.c |1 + arch/arm/mach-omap2/board-zoom2.c |2 + arch/arm/mach-omap2/board-zoom3.c |2 + arch/arm/mach-omap2/gpmc.c | 50 - arch/arm/mach-omap2/io.c |2 - arch/arm/plat-omap/include/plat/gpmc.h | 16 ++- arch/arm/plat-omap/include/plat/irqs.h |9 +- arch/arm/plat-omap/include/plat/nand.h | 11 + drivers/mtd/nand/Kconfig | 17 -- drivers/mtd/nand/omap2.c | 314 ++- - 31 files changed, 364 insertions(+), 94 deletions(-) -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 1/4] drivers: hwspinlock: add generic framework
On Fri, Nov 26, 2010 at 12:18:49AM -0700, Grant Likely wrote: On Thu, Nov 25, 2010 at 9:59 PM, Olof Johansson o...@lixom.net wrote: On Tue, Nov 23, 2010 at 05:38:57PM +0200, Ohad Ben-Cohen wrote: +#define pr_fmt(fmt) %s: fmt, __func__ Not used. pr_fmt() is a magic #define that changes the behaviour of the pr_*() macros. See include/linux/kernel.h D'oh, thanks. -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 1/4] drivers: hwspinlock: add generic framework
On Fri, Nov 26, 2010 at 12:45 PM, Russell King - ARM Linux
li...@arm.linux.org.uk wrote:
On Fri, Nov 26, 2010 at 12:16:39PM +0200, Ohad Ben-Cohen wrote:
On Fri, Nov 26, 2010 at 11:18 AM, Russell King - ARM Linux
li...@arm.linux.org.uk wrote:
On Fri, Nov 26, 2010 at 10:53:10AM +0200, Ohad Ben-Cohen wrote:
+int __hwspin_trylock(struct hwspinlock *hwlock, int mode, unsigned
long *flags)
+{
+ int ret;
+
+ if (unlikely(!hwlock)) {
+ pr_err(invalid hwlock\n);
These kind of errors can get very spammy for buggy drivers.
Yeah, but that's the purpose - I want to catch such egregious drivers
who try to crash the kernel.
That can be better - because you get a backtrace, and it causes people
to report the problem rather than just ignore it. It may also prevent
the driver author releasing his code (as it won't work on their
initial testing.)
...
If it's extremely buggy behaviour then the drivers deserve to crash.
Such stuff should cause them not to get out the door. A simple printk
with an error return can just be ignored.
I like this approach too, but recently we had a few privilege
escalation exploits which involved NULL dereference kernel bugs
(process context mapped address 0 despite a positive mmap_min_addr).
That's not a concern on ARM.
Good point, thanks. The problem is that we can't rely on that in a
generic interface.
I remember a recent discussion where you suggested to have a
conditional check that will be compiled out on architectures where we
can rely on NULL dereference to produce an oops; something like that
can be handy here.
But then there's the other (quite reasonable) claim that says we
shouldn't crash the machine because of a non fatal bug: if a crappy
driver messes up, the user (not the developer) will most probably
prefer the machine to keep running with degraded functionality rather
than boot.
... which gets us back to pr_err.
at virtual address 0 does not rely on mmap_min_addr - in fact, we can't
use this as it's tuneable to enforce this requirement.
It's highly illegal on ARM - as ARM CPUs without vector remap place the
hardware vectors at virtual address 0, and as such allowing the user to
map a page there will take the system down. So we have this code in the
mmap path:
#define arch_mmap_check(addr, len, flags) \
(((flags) MAP_FIXED (addr) FIRST_USER_ADDRESS) ? -EINVAL : 0)
which prevents any attempt what so ever, irrespective of the mmap_min_addr
setting, to create a userspace induced mapping at address 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 ver. 3] PM: add synchronous runtime interface for interrupt handlers
On Thursday, November 25, 2010, Alan Stern wrote:
This patch (as1431c) makes the synchronous runtime-PM interface
suitable for use in interrupt handlers. Subsystems can call the new
pm_runtime_irq_safe() function to tell the PM core that a device's
runtime_suspend and runtime_resume callbacks should be invoked with
interrupts disabled and the spinlock held. This permits the
pm_runtime_get_sync() and the new pm_runtime_put_sync_suspend()
routines to be called from within interrupt handlers.
When a device is declared irq-safe in this way, the PM core increments
the parent's usage count, so the parent will never be runtime
suspended. This prevents difficult situations in which an irq-safe
device can't resume because it is forced to wait for its non-irq-safe
parent.
Signed-off-by: Alan Stern st...@rowland.harvard.edu
Applied to suspend-2.6/linux-next.
Thanks,
Rafael
---
Index: usb-2.6/include/linux/pm.h
===
--- usb-2.6.orig/include/linux/pm.h
+++ usb-2.6/include/linux/pm.h
@@ -486,6 +486,7 @@ struct dev_pm_info {
unsigned intrun_wake:1;
unsigned intruntime_auto:1;
unsigned intno_callbacks:1;
+ unsigned intirq_safe:1;
unsigned intuse_autosuspend:1;
unsigned inttimer_autosuspends:1;
enum rpm_requestrequest;
Index: usb-2.6/include/linux/pm_runtime.h
===
--- usb-2.6.orig/include/linux/pm_runtime.h
+++ usb-2.6/include/linux/pm_runtime.h
@@ -40,6 +40,7 @@ extern int pm_generic_runtime_idle(struc
extern int pm_generic_runtime_suspend(struct device *dev);
extern int pm_generic_runtime_resume(struct device *dev);
extern void pm_runtime_no_callbacks(struct device *dev);
+extern void pm_runtime_irq_safe(struct device *dev);
extern void __pm_runtime_use_autosuspend(struct device *dev, bool use);
extern void pm_runtime_set_autosuspend_delay(struct device *dev, int delay);
extern unsigned long pm_runtime_autosuspend_expiration(struct device *dev);
@@ -123,6 +124,7 @@ static inline int pm_generic_runtime_idl
static inline int pm_generic_runtime_suspend(struct device *dev) { return 0;
}
static inline int pm_generic_runtime_resume(struct device *dev) { return 0; }
static inline void pm_runtime_no_callbacks(struct device *dev) {}
+static inline void pm_runtime_irq_safe(struct device *dev) {}
static inline void pm_runtime_mark_last_busy(struct device *dev) {}
static inline void __pm_runtime_use_autosuspend(struct device *dev,
@@ -195,6 +197,11 @@ static inline int pm_runtime_put_sync(st
return __pm_runtime_idle(dev, RPM_GET_PUT);
}
+static inline int pm_runtime_put_sync_suspend(struct device *dev)
+{
+ return __pm_runtime_suspend(dev, RPM_GET_PUT);
+}
+
static inline int pm_runtime_put_sync_autosuspend(struct device *dev)
{
return __pm_runtime_suspend(dev, RPM_GET_PUT | RPM_AUTO);
Index: usb-2.6/drivers/base/power/runtime.c
===
--- usb-2.6.orig/drivers/base/power/runtime.c
+++ usb-2.6/drivers/base/power/runtime.c
@@ -250,13 +250,16 @@ static int rpm_callback(int (*cb)(struct
if (!cb)
return -ENOSYS;
- spin_unlock_irq(dev-power.lock);
+ if (dev-power.irq_safe) {
+ retval = cb(dev);
+ } else {
+ spin_unlock_irq(dev-power.lock);
- retval = cb(dev);
+ retval = cb(dev);
- spin_lock_irq(dev-power.lock);
+ spin_lock_irq(dev-power.lock);
+ }
dev-power.runtime_error = retval;
-
return retval;
}
@@ -404,7 +407,7 @@ static int rpm_suspend(struct device *de
goto out;
}
- if (parent !parent-power.ignore_children) {
+ if (parent !parent-power.ignore_children !dev-power.irq_safe) {
spin_unlock_irq(dev-power.lock);
pm_request_idle(parent);
@@ -527,10 +530,13 @@ static int rpm_resume(struct device *dev
if (!parent dev-parent) {
/*
- * Increment the parent's resume counter and resume it if
- * necessary.
+ * Increment the parent's usage counter and resume it if
+ * necessary. Not needed if dev is irq-safe; then the
+ * parent is permanently resumed.
*/
parent = dev-parent;
+ if (dev-power.irq_safe)
+ goto skip_parent;
spin_unlock(dev-power.lock);
pm_runtime_get_noresume(parent);
@@ -553,6 +559,7 @@ static int rpm_resume(struct device *dev
goto out;
goto repeat;
}
+ skip_parent:
if (dev-power.no_callbacks)
goto no_callback; /* Assume success. */
@@ -584,7
Re: [PATCH v2 1/4] drivers: hwspinlock: add generic framework
On Sat, Nov 27, 2010 at 12:18:55AM +0200, Ohad Ben-Cohen wrote: But then there's the other (quite reasonable) claim that says we shouldn't crash the machine because of a non fatal bug: if a crappy driver messes up, the user (not the developer) will most probably prefer the machine to keep running with degraded functionality rather than boot. There's also the quite reasonable expectation that we shouldn't corrupt user data. With locking interfaces, if someone abuses them and they fail to work, then the risk is data corruption due to races. The safe thing in that case is to panic - terminate that thread before it does anything unsafe, thereby preventing data corruption. Yes, it may mean that something becomes unavailable, but that's better than corrupting data. Take a look at the kernel's own spinlock implementation. Do we do lots of checks in there for things like someone passing a NULL pointer to the spinlock, or do we get an oops instead? Also look at the list implementation. Do we check for NULL pointers there, or do we get an oops instead? Same for mutex. The same goes for lots of other infrastructure interfaces. -- 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] omap: zoom: wl1271 slot is MMC_CAP_POWER_OFF_CARD
This patch complements ed919b0 mmc: sdio: fix runtime PM anomalies by
introducing MMC_CAP_POWER_OFF_CARD by declaring MMC_CAP_POWER_OFF_CARD
on the ZOOM's wl1271 mmc slot.
This is required in order not to break runtime PM support for the wl1271
sdio driver.
Signed-off-by: Ohad Ben-Cohen o...@wizery.com
---
Quick summary:
After adding SDIO runtime PM support, we realized there are some
board/host/card setups that are incapable of powering off the card
after boot. For details, see:
http://thread.gmane.org/gmane.linux.kernel.mmc/4342/focus=4579
As a result, we added MMC_CAP_POWER_OFF_CARD which should be explicitly set
by setups that _do_ support powering off the card.
This ensures we don't break existing functionality: SDIO core will enable
runtime PM for cards only if that cap is set.
As a result, the card will be powered down after boot, and will only
be powered up again when a driver is loaded (and then it's up to the
driver whether power will be kept or not).
To complement that fix (which was just merged upstream), we need this
patch too in 2.6.37, otherwise wl1271_sdio will break.
Pandora/Beagle wl12xx users: you need a similar patch as well, as this one
only takes care of ZOOM (I don't have those other setups and preferred not to
send a patch without testing).
arch/arm/mach-omap2/board-zoom-peripherals.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/arch/arm/mach-omap2/board-zoom-peripherals.c
b/arch/arm/mach-omap2/board-zoom-peripherals.c
index 86c9b21..9db9203 100644
--- a/arch/arm/mach-omap2/board-zoom-peripherals.c
+++ b/arch/arm/mach-omap2/board-zoom-peripherals.c
@@ -216,7 +216,7 @@ static struct omap2_hsmmc_info mmc[] __initdata = {
{
.name = wl1271,
.mmc= 3,
- .caps = MMC_CAP_4_BIT_DATA,
+ .caps = MMC_CAP_4_BIT_DATA | MMC_CAP_POWER_OFF_CARD,
.gpio_wp= -EINVAL,
.gpio_cd= -EINVAL,
.nonremovable = true,
--
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
Re: [PATCH v2 1/4] drivers: hwspinlock: add generic framework
On Fri, 2010-11-26 at 09:34 +0200, Ohad Ben-Cohen wrote: On Thu, Nov 25, 2010 at 10:22 PM, David Brownell davi...@pacbell.net wrote: So there's no strong reason to think this is actually ggeneric. Function names no longer specify OMAP, but without other hardware under the interface, calling it generic reflects more optimism than reality. (That was the implication of my observations...) Well, it's not omap-specific anymore. You haven't (and evidently can't) show non-OMAP hardware under your calls, though ... so in a practical sense, it's still OMAP-specific code (since nothing else is working). (And for that matter, what non-OMAP code should try using these locks??) Your intent generic is fine, but you've not achieved it and thus I think you shouldn't imply that you have. Dropping the word generic should suffice; it _is_ a framework, and maybe the next person working with hardware spinlocks can finish generalizing (and add use cases). To find other hardware spinlocks, you might be able to look at fault tolerant multiprocessors. (For much the same reasons as the various ASMP chips care about HW spinlocks:... SMP can use pure software spinlocks, but when there are special hardware (or system) circumstances, they may not be sufficiently robust/ or reliable. (Consider just the impact of differeent memory and caching models, ARM vs DSP in the OMAP case. Non-Academic specs on fault tolerant computers may be hard to come by, unfortunately ... They're very specialized and often have lots of funky proprietary logic that vendors don't want reverse-engineered. Hardware voting is just the start. The software to make the fault tolerance robust/reliable gets to be very tricky ... and without it, why bother with expensive hardware mechanisms. The same issues come up with aerospace and some industrial systems, where reliability affects mission-readiness and, for industrial apps, safety. Ages ago I worked with one of those, where any spinlock failures integrated with CPU/OS fault detection; HW cwould yank (checkpointed) CPU boards off the bus so they could be recovered (some might continue later from checkpoints, etc.)... Is that HW supported by Linux today ? Not mainline, and unlikely any branch. Fault tolerant operating systems can't be as simple as Linux, and I think that trying to add fault tolerance to it would not only turn it into a very different animal, but would lose most developers. (The mantra I recall was No single Point Failures. Linux has lots of such failure modes, and removing them would be a multi-year effort, even just inside the kernel. (How would you recover from a bus failure? Fan failure? Power supply death? (All such hardware must be duplicated, with recovery supported by both hardware and software...) (Where recover includes keep running without losing data or other computations.) (Last I knew, Linux didn't even have much support for checkpoint and restore of kernel state ... hibernation is related, but seems to be constantly in flux. (Don't think it's aiming to tolerate CPU failures after a hibernation checkpoint either. (Heck ... on my Ubuntu, Network Manager isn't even competent to switch over cleanly from Ethernet to WLAN (and don't get me talking about other ways it's broken. LOTS of stupid fault handling, and that's arguably mission-critical for the whole system ... multiple single point failure modes. That's FAR from fault-tolerant. Any chance you can share a link or any other info about it ? I googled for sequoia systems fault tolerance and found some stuff that looked like it summarized some of the original hardware. I can't think, off the top of my head, of other kinds of system that need and use hardware spinlocks, but likely they do exist. (Mainframe tech might use them too, as part of the subset of fault-tolerant HW tech they build on. If you want to provide a generic framework you should find and support some (or Tom-Sawyer such support... :) I seem to recall some iterations of the real-time patches doing a lot of work to generalize spinlocks, since they needed multiple variants. It might be worth following in those footsteps. (Though I'm not sure they were thinking much about hardware support . Any chance you can point me at a specific discussion or patchset that you feel may be relevant ? Haven't looked at RT in a long time. Just look at the current RT patchset to see if it still has several spinlock variants. ISTR the raw spinlock stuff came from there not long ago. Much compile-time magic was involved in switching between variants. - Dave -- 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
