Age | Commit message (Collapse) | Author |
|
The camera driver reduced all IO drivers from their reset defaults of
6 mA to only 2 mA, which caused severe signal distortion at higher
speeds. This patch sets them to 8 mA and also removes apparently
useless repetitions of the setting.
Note that the correct setting of the I2C pullups still needs to be
verified.
Signed-off-by: Werner Almesberger <werner@openmoko.org>
|
|
- provide clean sysfs to control RGB channel directly.
They are looked like the following:
channel_mode
channel_pwm
channel_cur
- add platform data to export RGB channel accordingly.
Signed-off-by: Matt Hsu <matt_hsu@openmoko.org>
|
|
A few dirty hacks to make the camera driver work:
- because V4L no longer guarantees that minor numbers provided by the
client are actually used, the preview/codec selection mechanism falls
apart. We work around this by defaulting to preview when we don't
know better.
- power up the camera in platform code, not cleanly via power control
device.
Signed-off-by: Werner Almesberger <werner@openmoko.org>
|
|
Add Samsung S3C camera subsystem to kernel configuration and build process.
Original code is from Samsung's BSP.
Signed-off-by: Werner Almesberger <werner@openmoko.org>
|
|
This patch makes the Samsung S5K4BA driver work in 2.6.29 and also solves
a few minor issues, such as trailing whitespace.
Signed-off-by: Werner Almesberger <werner@openmoko.org>
|
|
This is the original Samsung S5K4BA camera driver code from the 2.6.21
BSP. The changes that are needed to make this work in 2.6.29 are in
the next patch.
Signed-off-by: Werner Almesberger <werner@openmoko.org>
|
|
Update the camera interface driver from 2.6.21 to 2.6.29 and fix some
trivial issues. There are still a few ugly spots, marked with "@@@".
Only tested on S3C6410.
Signed-off-by: Werner Almesberger <werner@openmoko.org>
|
|
This is the original Samsung S3C camera driver code from the 2.6.21 BSP.
The changes that are needed to make this work in 2.6.29 are in the next
patch.
Signed-off-by: Werner Almesberger <werner@openmoko.org>
|
|
Reported-by: Neil Brown <neilb@suse.de>
Signed-off-by: Andy Green <andy@openmoko.com>
|
|
Signed-off-by: Andy Green <andy@openmoko.com>
|
|
X-Git-Url: http://git.openmoko.org/?p=kernel.git;a=commitdiff_plain;h=522c644d34461fcd65a94cce1fcac9dc0d6cd828
ohci_s3c2410: Implement PM resume functionality
It was observed that that s3c2410_hc's root hub was not autoresumed when the
system was suspended with the root hub itself autosuspended.
As an effect of this, it was observed that the bluetooth module wouldn't get
detected at the hc's roothub ports when powered up after resume. And when
'lsusb' was executed, the roothub got out of autosuspend by force with a
'roothub lost power, resetting' message.
This patch brings the hcd roothub out of resume at global resume thereby
avoiding the issue.
Signed-off-by: Balaji Rao <balajirrao@openmoko.org>
|
|
X-Git-Url: http://git.openmoko.org/?p=kernel.git;a=commitdiff_plain;h=f4fd6631973dbc67a5f4708014e81ca6e610ca05
pcf50633_charger_detection_fix.patch
Fix PCF50633 charger detection code.
Signed-off-by: Balaji Rao <balajirrao@openmoko.org>
|
|
> |> on current andy-tracking / OM_3D7K build.
> |>
> |> I didn't see this before, it seems to related to SPI bitbang, did we
> |> break something?
Here is the patch. I've not tested it, but it's most likely the fix, as
I had seen a similar thing in spi_s3c24xx_gpio.
|
|
The PCF50633 stores a month value of 1-12, but the kernel wants 0-11.
Signed-off-by: Rask Ingemann Lambertsen <rask@sygehus.dk>
|
|
GTA03 project is dropped, long live Openmoko 3d7k project.
This name was literally generated by picking the first character
of the next four car license plates to pass by I am told.
The should catch all GTA03 instances except the machine name.
I registered a new machine name since the 3d7k is different
from original GTA03, the machine number is 2120.
Signed-off-by: Andy Green <andy@openmoko.com>
|
|
Some registers where not set properly, or at the right time (thanks to Balaji
for his patch).
Weak locking could lead to corruption when using sysfs to switch state from
multiple threads or processes. The state transitions are now all atomic.
The driver attribute 'last_state' was used for same purpose of 'normal_state'.
Kept only 'normal_state' and used it in 'init_regs' instead of custom qvga
parameter.
This patch should fix bug #2235.
Signed-off-by: Nicolas Dufresne <nicolas.dufresne@gmail.com>
|
|
spigpio_info.
X-Git-Url: http://git.openmoko.org/?p=kernel.git;a=commitdiff_plain;h=740c6704e830829d8539a6cc34346ff1980cd9ee
Get rid of board_info information in glamo and s3c24xx_gpio spigpio_info.
The board info does not belong there and has been removed. In
spi_s3c24xx_gpio, board_info has been removed in mainline.
Signed-off-by: Balaji Rao <balajirrao@openmoko.org>
|
|
This removes the unstable operation by increasing break timing from
170us to 230us, the datasheet minimum was 190us.
Signed-off-by: Andy Green <andy@openmoko.com>
|
|
X-Git-Url: http://git.openmoko.org/?p=kernel.git;a=commitdiff_plain;h=c94ea3d685fa6e9b24d62adb11a7ad6087b9edf5
fix_gta03_fiq_stuff.patch
Signed-off-by: Balaji Rao <balajirrao@openmoko.org>
|
|
X-Git-Url: http://git.openmoko.org/?p=kernel.git;a=commitdiff_plain;h=5689ad9b0ded29adec4be64df53e488c648b9831
lis302dl_use_s3c24xx_gpio_spi_bitbang.patch
Change lis302dl driver to use generic spi code. This requires that we define a
s3c24xx_gpio spi bitbang based controller in mach-gta02.c.
Signed-off-by: Balaji Rao <balajirrao@openmoko.org>
|
|
X-Git-Url: http://git.openmoko.org/?p=kernel.git;a=commitdiff_plain;h=f8fbb07854e3aff64dce9fe6ef6a8dc0e0f762b5
spi_supoport_non_blocking_sync_transfers.patch
A mew option is added to spi_bitbang_info to specify if the
transfers off it will be non blocking.
A new function - spi_non_blocking_transfer is added to the SPI core.
Signed-off-by: Balaji Rao <balajirrao@openmoko.org>
|
|
Hi Andy,
Here's the fix for the qvga-normal bug we observed the other day
here - when the screen is powered up again after a blanking, in
qvga-normal mode, we see a WSOD(kind of!)
|
|
Signed-off-by: Andy Green <andy@openmoko.com>
|
|
Signed-off-by: Balaji Rao <balajirrao@openmoko.org>
|
|
Introduce a new generic HDQ gpio based bitbang driver
Signed-off-by: Balaji Rao <balajirrao@openmoko.org>
|
|
Since the pwm code in mach-2410 can be reused for 6410, move it to plat-s3c.
Signed-off-by: Balaji Rao <balajirrao@openmoko.org>
|
|
This patch moves the bulk transfer action outside of
interrupt context, along with the STOP transmission action
for multiblock transfers.
It's prompted by
https://docs.openmoko.org/trac/ticket/2180
But it can impact throughput to SD card, so it's for testing
currently.
Signed-off-by: Andy Green <andy@openmoko.com>
|
|
It looks like I made a mistake in the original pan implementation that
is now getting exercised. The following fixes pan again.
Cheers,
Sean
|
|
pending-tracking-hist top was claen-ledtrig-netdev-unused-va / 126536fc6ed26323103f941e7cf81e4b0ceaab7a ... parent commitmessage:
From: Andy Green <andy@openmoko.com>
claen-ledtrig-netdev-unused-var-warn.patch
Signed-off-by: Andy Green <andy@openmoko.com>
|
|
pending-tracking-hist top was MERGE-via-pending-tracking-hist-1234930404 / 4a23c8aeedd5fb86009d290a41fc299e3965d8ec ... parent commitmessage:
From: merge <null@invalid>
MERGE-pending-tracking-patchset-edits
|
|
Signed-off-by: Michael Trimarchi <michael@panicking.kicks-ass.org>
|
|
Reported-by: Mickey Lauer <mickey@openmoko.org>
Signed-off-by: Andy Green <andy@openmoko.com>
|
|
|
|
-do the parameter check of setting operating mode.
-add device haeder file.
Signed-off-by: Matt Hsu <matt_hsu@openmoko.org>
|
|
The following two features are added as platform data.
- externel reset
- operating mode
Signed-off-by: Matt Hsu <matt_hsu@openmoko.org>
|
|
Hi.
The recent patch to fix a USB current limit violation when turning the
device off triggered a bug in setting the battery charge current limit. We
now get a charge current limit of 0 mA on the GTA02 when plugging in the
wall charger (just as when setting 1000 mA in /sys/class/[...]/chg_curlim).
This patch fixes it (and a comment typo). Tested on a GTA02 with a wall
charger.
Signed-off-by: Rask Ingemann Lambertsen <rask@sygehus.dk>
|
|
Move the regulator handling stuff away from s3cmci.c to mach-gta01.c.
Signed-off-by: Balaji Rao <balajirrao@openmoko.org>
|
|
Signed-off-by: Andy Green <andy@openmoko.com>
|
|
Signed-off-by: Andy Green <andy@openmoko.com>
|
|
Signed-off-by: Andy Green <andy@openmoko.com>
|
|
hes-tracking-MERGE-via-master-MERGE-via-master-hist-1232625318-1233879011-1233879414-1233879505
pending-tracking-hist top was MERGE-via-stable-tracking-MERGE-via-mokopatches-tracking-MERGE-via-master-MERGE-via-master-hist-1232625318-1233879011-1233879414-1233879505 / 1c405b6ccee468298e7ccbfd9a3a3f4d123207b0 ... parent commitmessage:
From: merge <null@invalid>
MERGE-via-stable-tracking-hist-MERGE-via-mokopatches-tracking-MERGE-via-master-MERGE-via-master-hist-1232625318-1233879011-1233879414
stable-tracking-hist top was MERGE-via-mokopatches-tracking-MERGE-via-master-MERGE-via-master-hist-1232625318-1233879011-1233879414 / 71be0a45396066b1f8f27f8f4f87937247a129e1 ... parent commitmessage:
From: merge <null@invalid>
MERGE-via-mokopatches-tracking-hist-MERGE-via-master-MERGE-via-master-hist-1232625318-1233879011
mokopatches-tracking-hist top was MERGE-via-master-MERGE-via-master-hist-1232625318-1233879011 / 1be1b01373f572a02c6f1f99863c8c11ed2f9f5b ... parent commitmessage:
From: merge <null@invalid>
MERGE-via-master-MERGE-via-master-hist-1232625318
master top was MERGE-via-master-hist-1232625318 / dd4b117123ae66451695810017eb72fbdfc05df5 ... parent commitmessage:
From: merge <null@invalid>
MERGE-master-patchset-edits
|
|
Cedric noticed that when he turned his GTA02 OFF while hooked to
a "dumb" USB charger that should only be asked for 100mA, suddenly
much more current was demanded.
When PMU enters PMU standmy when we go OFF, its USB current limit
is reset to the variant default of 500mA. Since we previously had
the charging current limit fixed at 1A, it meant we immediately
charge at 500mA.
This patch makes the charging limit follow the USB current limit,
so that even when we go off, no more than the last authorized amount
of current will be taken, even if the USB current limit is later
broken by the variant default.
Reported-by: Cedric Berger <cedric.berger74@gmail.com>
Signed-off-by: Andy Green <andy@openmoko.com>
|
|
We need to clear down the wakeup source reg if we woke from
threshold.
Reported-by: Simon Kagstrom <simon.kagstrom@gmail.com>
Signed-off-by: Andy Green <andy@openmoko.com>
|
|
We shouldn't be resetting the highpass filter every sample.
It should be disabled if we don't use it or allowed to
work across multiple samples if we do.
Was this hiding some other problem?
Signed-off-by: Andy Green <andy@openmoko.com>
|
|
Level interrupts solve the sticky loss of service from accels issue.
But currently, we get two service actions per one interrupt, leading to
information getting read and sent to the input subsystem twice.
This patch makes the ISR confirm with the lis302dl status register
that there is fresh data before accepting it, it works around the
issue and allows use of the other information in the status reg by
another patch.
Signed-off-by: Andy Green <andy@openmoko.com>
|
|
People on bug
https://docs.openmoko.org/trac/ticket/2217
experiencing problems with default emmory settings on Glamo
reported that changing reg 0x200 <- 0xef0 as in 2.6.24 made
the problem not reproducible any more.
However this changes three bitfields, two are to do with
waitstates before sampling read and write cycles off the
bus, and the last is to do with which PLL provides the clock
to the memory interface unit logic. The old settings has
all three of these very conservative, 3 waitstates and using
the 50MHz PLL instead of the 90MHz one; the new default
setting has all of these at their fastest of 0 wait states
and the 90MHz PLL.
This patch adds some more granular tests to the same
glamo3362.slow_memory=
parameter to see if we can find some middle ground. For
example the issue may be the waitstates and not the PLL
source, in which case even users with the bad Glamo
behaviour can have the advantage of the faster PLL / bus
bandwidth.
0 90MHz PLL, no wait states (default)
1 50MHz PLL, 3 wait states
2 50MHz PLL, 2 wait states
3 50MHz PLL, 1 wait state
4 50MHz PLL, no wait states
5 90MHz PLL, 3 wait states
6 90MHz PLL, 2 wait states
7 90MHz PLL, 1 wait state
Signed-off-by: Andy Green <andy@openmoko.com>
|
|
This patch adds setting and clearing of the "pending" flag of the
RTC alarm. The semantics follow the UEFI specification 2.2 available
at http://www.uefi.org/specs/, i.e., the "pending" flag is cleared
by disabling the alarm, but not by any other condition (such as the
passing of time, a successful wakeup, or setting of a new alarm.)
Signed-off-by: Werner Almesberger <werner@openmoko.org>
|
|
Signed-off-by: Andy Green <andy@openmoko.com>
|
|
Signed-off-by: Andy Green <andy@openmoko.com>
|
|
Signed-off-by: Andy Green <andy@openmoko.com>
|