| Age | Commit message (Collapse) | Author |
|---|
|
Use the regulator framework to provide optional support for DVFS in
the S3C64XX cpufreq driver. When a software controllable regulator
is configured the driver will use it to lower the supply voltage when
running at a lower frequency, giving improved power saving.
When regulator support is disabled or no regulator can be obtained
for VDDARM the driver will fall back to scaling only the frequency.
Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
|
|
This patch provides initial support for CPU frequency scaling on the
Samsung S3C64XX series processors. Currently only S3C6410 processors
are supported, though addition of another data table with supported
clock rates should be sufficient to enable support for further CPUs.
Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
|
|
Add support for reconfiguring the clock for the ARM core, enabling
CPUfreq support. Currently only the divider for ARMCLK may be changed,
ARMPLL is left static.
Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
|
|
Stroe the CPU ID to system_rev and use it to detect the CPU architecture.
Even though s3c64xx has almost same IPs, some IPs such as OneNAND are different.
Signed-off-by: Kyungmin Park <kyungmin.park@samsung.com>
Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
|
|
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=d9235e3a8bdcef02865eed27c0d6012d253f11e7
om3d7k: Add support for s3c_ohci device.
Adds s3c_ohci support to om3d7k.
Signed-off-by: Balaji Rao <balajirrao@openmoko.org>
|
|
X-Git-Url: http://git.openmoko.org/?p=kernel.git;a=commitdiff_plain;h=b55b8e56a4a7e43b7243be48f77a326236a37c68
USB: Change s3c2410_ohci into s3c_ohci and change gta02 to use it
Signed-off-by: Balaji Rao <balajirrao@openmoko.org>
|
|
Give the regulator supplies names corresponding to the names their
supplies are given in the schematic, making it easier to tie the
software up with the schematic.
Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
|
|
At least one of the speaker options should disable the speaker.
Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
|
|
Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
|
|
Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
|
|
http://lists.openmoko.org/pipermail/openmoko-kernel/2009-March/009387.html
)
Change accelerometers to use ABS events rather than REL events.
[Obviously if this patch is accepted we need to tell developers about
it. I have a number of other improvements to the accelerometers I
hope to deliver over the next couple of weeks. They will have minimal
or zero disruption to current code. ]
REL events should be used when there is no absolute reference, and
only changes are meaningful. The classic example is a "mouse" where
the absolute position of the device is not measurable and not
particularly meaning, but change in position from one time to the next
is interesting.
With REL events, a value of '0' is not reported, as 'not change' is
not interesting.
With REL events, the expectation is that successive values will be
eventually summed (possibly with acceleration and clipping
adjustments) to get a usable value.
ABS events should be used when there is an absolute references against
which things that be measured.
With ABS events, the 'current value' is meaningful and can be read
(EVIOCGABS).
With ABS events, the value '0' is very meaningful and is reported.
However if consecutive values are the same, the value is only reported
once.
ABS events can be used as-is or compared with previous events to get
some measure of change.
An obvious example is a touchscreen where each measure in
independently meaningful.
Acceleration is an absolute value as it is measuring against a frame
of reference. '0' acceleration is just as meaningful as any other
value, and finding the 'current' acceleration is each direction is a
potentially useful thing to do.
The Freerunner accelerometers currently report REL events. This is
wrong. So this patch changes them to report ABS events.
With this patch, the min/max/level/fuzz values are left at zero. It
might be useful to make use of these in a subsequent patch.
min/max/level can be used to calibrate the accelerometers if accuracy
is important.
fuzz could possibly be used in conjunction with the 'threshold' sysfs
value to get less frequent, lower-precision reports.
This may well break some applications that read accelerometer data.
This cannot be helped, but it is quite easy to write code that copes
with the incorrect EV_REL events as well as the more correct and
useful EV_ABS events.
Signed-off-by: NeilBrown <neilb@suse.de>
|
|
Signed-off-by: Andy Green <andy@openmoko.com>
|
|
Signed-off-by: Andy Green <andy@openmoko.com>
|
|
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>
|
|
Signed-off-by: Matt Hsu <matt_hsu@openmoko.org>
|
|
for 3d7k.
By parsing kernel command, 3d7k can probe two different LCM driver accordingly.
The default attached LCM device is l1k002, if you wanna to use jbt6k74, you don't
need to re-compile the kernel. Just add one option om_3d7k_lcm=jbt6k74 in
boot/append-OM_3D7K in rootfs.
Signed-off-by: Matt Hsu <matt_hsu@openmoko.org>
|
|
Signed-off-by: Matt Hsu <matt_hsu@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>
|
|
Signed-off-by: Matt Hsu <matt_hsu@openmoko.org>
|
|
LED INT is connected to EXT group6_9, the handling of EXT group1~group9
is not yet implemented. Besides, we don't need this IRQ now.
Signed-off-by: Matt Hsu <matt_hsu@openmoko.org>
|
|
Subject: [PATCH] fix-alsa-bt-dai-registration-missing
|
|
Subject: [PATCH] Typo in I2C device registration
Signed-off-by: Tim Niemeyer <reddog@redlap.wired.rednet.mastersword.de>
|
|
These are the Samsung S3C camera interface register definitions directly
from the 2.6.21 BSP. The only changes to the original code are the removal
of trailing whitespace and the change of location.
Signed-off-by: Werner Almesberger <werner@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>
|
|
Enable V4L and camera driver in 3D7K default configuration.
Signed-off-by: Werner Almesberger <werner@openmoko.org>
|
|
This patch adds the camera interface driver and the corresponding
configuration option to the 3D7K machine.
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>
|
|
These are te I2C IDs for all the Samsung S5K series cameras. This code
is directly from Samsung's BSP.
Signed-off-by: Werner Almesberger <werner@openmoko.org>
|
|
Add Samsung S3C camera interface driver.
Original code is from Samsung's BSP and was written for 2.6.21.
Only tested on S3C6410.
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>
|
|
Add camera interface clock to S3C6410.
Signed-off-by: Werner Almesberger <werner@openmoko.org>
|
|
Add doubled HCLK to S3C64xx.
Signed-off-by: Werner Almesberger <werner@openmoko.org>
|
|
Note: this patch is already on the way upstream but is currently missing
in the Openmoko kernel.
Some of the rate selection logic in s3c64xx_setrate_clksrc uses what
appears to be parent clock selection logic. This patch corrects it.
I also added a check for overly large dividers to prevent them
from changing unrelated clocks.
Signed-off-by: Werner Almesberger <werner@openmoko.org>
|
|
Signed-off-by: Andy Green <andy@openmoko.com>
|
|
Signed-off-by: Andy Green <andy@openmoko.com>
|
|
This one is specially for Candy Chou :-)
Signed-off-by: Andy Green <andy@openmoko.com>
|
|
Signed-off-by: Andy Green <andy@openmoko.com>
|
|
Signed-off-by: Andy Green <andy@openmoko.com>
|
|
|
|
The code is borrowed from gta02.
Signed-off-by: Matt Hsu <matt_hsu@openmoko.org>
|
|
Signed-off-by: Andy Green <andy@openmoko.com>
|
|
Reported-by: Neil Brown <neilb@suse.de>
Signed-off-by: Andy Green <andy@openmoko.com>
|
|
This patch provides initial support for CPU frequency scaling on the
Samsung S3C64XX series processors. Currently only S3C6410 processors
are supported, though addition of another data table with supported
clock rates should be sufficient to enable support for further CPUs.
Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
|
|
Add support for reconfiguring the clock for the ARM core, enabling
CPUfreq support. Currently only the divider for ARMCLK may be changed,
ARMPLL is left static.
Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
|
|
Stroe the CPU ID to system_rev and use it to detect the CPU architecture.
Even though s3c64xx has almost same IPs, some IPs such as OneNAND are different.
Signed-off-by: Kyungmin Park <kyungmin.park@samsung.com>
Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
|
