Wrappers only hurt readability, use native kernel functions instead
(udelay, mdelay).
Also remove useless defines.
Signed-off-by: Felipe Contreras felipe.contre...@gmail.com
---
arch/arm/plat-omap/include/dspbridge/util.h | 33 ---
drivers/dsp/bridge/wmd/_tiomap_pwr.h
HW_MBOX_IsFull has many convoluted macros and is used only once. Clean
it up so it's easier to see what it's actually doing.
Signed-off-by: Felipe Contreras felipe.contre...@gmail.com
---
drivers/dsp/bridge/hw/hw_mbox.c| 25 -
drivers/dsp/bridge/hw/hw_mbox.h|
Hans Verkuil wrote:
Hi Adam,
Sorry for the late reply, it's been very busy.
Same here :)
On Wednesday 18 February 2009 01:30:52 Adam Baker wrote:
(linux-omap included in distribution as lots of omap systems include
cameras so this could be relevant there.)
Background
A number of the
From: ext Felipe Contreras felipe.contre...@gmail.com
Subject: [PATCH v2 1/4] dsp-bridge: remove unnecessary comments in util.h
Date: Sun, 22 Feb 2009 10:32:21 +0100
For starters util.h should not exist, but for now I'm cleaning it up to
remove the 'history log' which is tracked by git anyway,
On Sunday 22 February 2009 12:17:58 Hans de Goede wrote:
Hans Verkuil wrote:
Cons: Would require polling to support the case of a camera being
turned toward / away from the user while streaming.
Polling applies only to the bits that tell the orientation of the
camera. See below for a
Hans Verkuil wrote:
On Sunday 22 February 2009 12:17:58 Hans de Goede wrote:
snipped a large part we agree upon (hurray!)
Agreed, but it still is something which should be avoided if possible,
implementing polling also means adding a lot of IMHO unneeded code on the
userspace side.
I
On Fri, Feb 20, 2009 at 3:23 PM, Gadiyar, Anand gadi...@ti.com wrote:
Don't worry, you're not the only one TIred here...
Grrr. I'm in no mood to take any TI puns right now. That was unwarranted.
Was it? I agree with Felipe (Balbi) there's more people tired of this
stuff. I don't know which way
On Sun, Feb 22, 2009 at 7:21 PM, Felipe Contreras
felipe.contre...@gmail.com wrote:
On Fri, Feb 20, 2009 at 3:23 PM, Gadiyar, Anand gadi...@ti.com wrote:
Don't worry, you're not the only one TIred here...
Grrr. I'm in no mood to take any TI puns right now. That was unwarranted.
Was it? I
Hi
This Dirk's patch is not needed anymore since Tony pushed my RFC patches
for command line option i2c_bus=bus_id,clkrate in.
Note this revert removes also worth OMAP I2C help text change so would
you Dirk like to bring it back by sending it to linux-i2c list?
I tested this by hooking older
This is manual revert for commit bae4b6a716ccf3247a1991d3c20b5e58ddd52890.
CONFIG_I2C2_OMAP_BEAGLE is not needed anymore since additional busses can be
registered on the command line by the commit
ea9fcdaff4e9a6830833f3351eb44f6025df60e4.
This change makes drivers/i2c/busses/Kconfig sync with the
This is for mainline and generated on top of Koen's patch
board-omap3beagle: set i2c-3 to 100kH
commit e6b6f3462951153bc89e0247e562680759f5ad32
--
Jarkko
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo
There is no CONFIG_I2C2_OMAP_BEAGLE in mainline and it is under removal
in linux-omap also so remove this dead code now.
Signed-off-by: Jarkko Nikula jarkko.nik...@nokia.com
---
arch/arm/mach-omap2/board-omap3beagle.c |3 ---
1 files changed, 0 insertions(+), 3 deletions(-)
diff --git
Hi,
not trying to keep the thread alive, but...
On Sun, Feb 22, 2009 at 09:29:30PM +0530, Anand Gadiyar wrote:
Then I suggest you read up the history. You __are__ misinterpreting
this. He did not submit any patches. He had a list of some tens of
drivers that he was planning to send to
On Sun, Feb 22, 2009 at 10:20 PM, Felipe Balbi m...@felipebalbi.com wrote:
Hi,
not trying to keep the thread alive, but...
On Sun, Feb 22, 2009 at 09:29:30PM +0530, Anand Gadiyar wrote:
Then I suggest you read up the history. You __are__ misinterpreting
this. He did not submit any patches.
On Sun, Feb 22, 2009 at 10:34:03PM +0530, Anand Gadiyar wrote:
I must have missed the patchset, or I wasn't on the CC list. Anyway,
let's end this here and figure out how to get the driver functional,
cleaned-up and in mainline. I'm willing to help out in any way I can.
I've got hardware if
kilg...@banach.math.auburn.edu wrote:
snip
Hans and Adam,
I am not sure how it fits into the above discussion, but perhaps it is
relevant to point out that flags can be toggled. Here is what I mean:
Suppose that we have two flags 01 and 10 (i.e. 2), and 01 signifies
VFLIP and 10
On Sun, 22 Feb 2009, Hans de Goede wrote:
kilg...@banach.math.auburn.edu wrote:
snip
Hans and Adam,
I am not sure how it fits into the above discussion, but perhaps it is
relevant to point out that flags can be toggled. Here is what I mean:
Suppose that we have two flags 01 and 10
On Sat, Feb 21, 2009 at 11:33:43AM +0100, Koen Kooi wrote:
Don't forget to use the proper API for it:
http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=blob;f=include/sound/jack.h;hb=master
Yes, please, but note that there's an ASoC wrapper for that in sound/soc
in -next
On Sunday 22 February 2009, Hans de Goede wrote:
We want to be able to differentiate between a cam which has its sensor
mounted upside down, and a cam which can be pivotted and happens to be
upside down at the moment, in case of any upside down mounted sensor, we
will always want to
On Friday 20 February 2009, Aaro Koskinen wrote:
Hello,
Two fixes for twl4030-madc:
- The first one converts the ioctl to unlocked one.
- The second one should return the conversion status to user quicker,
both in OK and timeout cases. There's also fix for the timeout case
(currently
kilg...@banach.math.auburn.edu wrote:
On Sun, 22 Feb 2009, Hans de Goede wrote:
kilg...@banach.math.auburn.edu wrote:
snip
Hans and Adam,
I am not sure how it fits into the above discussion, but perhaps it
is relevant to point out that flags can be toggled. Here is what I mean:
On Sun, 22 Feb 2009, Hans de Goede wrote:
big snip
Yes that is what we are talking about, the camera having a gravity switch
(usually nothing as advanced as a gyroscope). Also the bits we are talking
about are in a struct which communicates information one way, from the camera
to
Trent Piepho wrote:
On Sun, 22 Feb 2009, Hans de Goede wrote:
Yes that is what we are talking about, the camera having a gravity switch
(usually nothing as advanced as a gyroscope). Also the bits we are talking
about are in a struct which communicates information one way, from the camera
to
On Sun, 22 Feb 2009, Hans de Goede wrote:
Yes that is what we are talking about, the camera having a gravity switch
(usually nothing as advanced as a gyroscope). Also the bits we are talking
about are in a struct which communicates information one way, from the camera
to userspace, so there is
On Sunday 22 February 2009 23:54:42 Hans de Goede wrote:
Trent Piepho wrote:
On Sun, 22 Feb 2009, Hans de Goede wrote:
Yes that is what we are talking about, the camera having a gravity
switch (usually nothing as advanced as a gyroscope). Also the bits we
are talking about are in a struct
Trent Piepho wrote:
On Sun, 22 Feb 2009, Hans de Goede wrote:
Trent Piepho wrote:
On Sun, 22 Feb 2009, Hans de Goede wrote:
Yes that is what we are talking about, the camera having a gravity switch
(usually nothing as advanced as a gyroscope). Also the bits we are talking
about are in a
Hello Russell,
On Sat, 14 Feb 2009, Russell King - ARM Linux wrote:
However, looking a little deeper, there's more issues in the reparenting
area. I don't think this code has been tested at all... In
_omap2_clksel_get_src_field, there is this:
for (clkr = clks-rates; clkr-div;
On Mon, 23 Feb 2009, Hans Verkuil wrote:
On Sunday 22 February 2009 23:54:42 Hans de Goede wrote:
Trent Piepho wrote:
On Sun, 22 Feb 2009, Hans de Goede wrote:
Yes that is what we are talking about, the camera having a gravity
switch (usually nothing as advanced as a gyroscope). Also
On Mon, 23 Feb 2009, Hans de Goede wrote:
Trent Piepho wrote:
On Sun, 22 Feb 2009, Hans de Goede wrote:
Trent Piepho wrote:
On Sun, 22 Feb 2009, Hans de Goede wrote:
Yes that is what we are talking about, the camera having a gravity switch
(usually nothing as advanced as a gyroscope).
Hi,
On Sat, Feb 21, 2009 at 11:30 AM, David Brownell davi...@pacbell.net wrote:
On Tuesday 03 February 2009, Kim Kyuwon wrote:
USB should be suspended with interrupt disabled[1].
That text means that the sysdev.suspend() method is
called with IRQs disabled ... just like suspend_late()
Hi,
On Sat, Feb 21, 2009 at 6:11 AM, David Brownell davi...@pacbell.net wrote:
On Friday 20 February 2009, Kim Kyuwon wrote:
+static void omap_hsmmc_init(struct mmc_omap_host *host)
+{
+ u32 hctl, capa, value;
+
+ /* Only MMC1 supports 3.0V */
+ if (host-id ==
On Sunday 22 February 2009, Kim Kyuwon wrote:
Hi,
On Sat, Feb 21, 2009 at 11:30 AM, David Brownell davi...@pacbell.net wrote:
On Tuesday 03 February 2009, Kim Kyuwon wrote:
USB should be suspended with interrupt disabled[1].
That text means that the sysdev.suspend() method is
called
I'm interested in bringing headset detection feature for audio. The
detection is done through TWL GPIO_2. How can I configure a GPIO pin
to generate an interrupt? Is there any API? Could you please point
out another driver using that functionality so I can use as reference?
In the setup()
On Sunday 22 February 2009, Lopez Cruz, Misael wrote:
In the particular case of ALSA SoC, could the machine/board driver
be a better place to handle all GPIO/IRQ configuration? That driver
also contains only board specific code.
It'd be best of the ASoC stuff could sit with all the other
On Monday 23 February 2009 00:56:40 Trent Piepho wrote:
On Mon, 23 Feb 2009, Hans Verkuil wrote:
On Sunday 22 February 2009 23:54:42 Hans de Goede wrote:
Trent Piepho wrote:
On Sun, 22 Feb 2009, Hans de Goede wrote:
Yes that is what we are talking about, the camera having a gravity
ext Kim Kyuwon wrote:
Hi,
On Sat, Feb 21, 2009 at 6:11 AM, David Brownell davi...@pacbell.net wrote:
On Friday 20 February 2009, Kim Kyuwon wrote:
+static void omap_hsmmc_init(struct mmc_omap_host *host)
+{
+ u32 hctl, capa, value;
+
+ /* Only MMC1 supports 3.0V */
+
36 matches
Mail list logo
