| Age | Commit message (Collapse) | Author |
|---|
|
|
|
glamo_cmd_mode is only used in glamofb.c and glamo_cmd_write is not used at all.
|
|
|
|
|
|
Conflicts:
drivers/gpio/Makefile
|
|
Author: Thomas White <taw@bitwiz.org.uk>
Date: Thu Nov 26 11:55:33 2009 +0300
Subject: mfd: glamo: Enable FIFO stage for the LCD engine's memory access
By avoiding conflicts of memory access inside Glamo, this doubles the
speed of internal memory access.
Signed-off-by: Thomas White <taw@bitwiz.org.uk>
Signed-off-by: Paul Fertser <fercerpav@gmail.com>
|
|
glamo-core didn't ioremap() some areas, so don't try to read them.
Signed-off-by: Thomas White <taw@bitwiz.org.uk>
|
|
|
|
Instead of staying in drivers/mfd/glamo, the glamo subdrivers have been moved
to the appropriate directories.
Additionally, config options were renamed as follows:
* MFD_GLAMO stays the same
* MFD_GLAMO_MCI becomes MMC_GLAMO
* MFD_GLAMO_GPIO becomes GPIO_GLAMO
* MFD_GLAMO_FB becomes FB_GLAMO
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Calls mmc_host_disable instead of mmc_host_lazy_disable if an error occurs,
thus avoiding to schedule a delayed work that would end up using free'd objects.
|
|
A custom timer was used to suspend the mmc host when idle.
MMC core now provides a generic way to do that.
|
|
|
|
host->irq_works is always true, so, the IRQ polling function in glamo-mci.c never gets called.
Furthermore, according to Lars, it was only here for very early prototypes of the glamo chip.
So, there should be no issue in dropping it.
|
|
|
|
|
|
|
|
|
|
|
|
Right now in 2.6.34 the legacy powermanagement callbacks are broken, so we work
around it by switching to dev_pm_ops.
|
|
This patch changes the pcf50633 core code to use mfd cells to register child
devices instead of calling platform_device_{alloc,add} for each child.
Signed-off-by: Lars-Peter Clausen <lars@metafoo.de>
|
|
|
|
This allows the modules to be auto-loaded by udev.
Patch from ThibG.
|
|
Conflicts:
drivers/power/Kconfig
drivers/power/Makefile
|
|
|
|
|
|
'glamo-2.6.34', 'om-misc-2.6.34' and 'om-s3c-2.6.34' into om-gta02-2.6.34
|
|
|
|
This driver can be used for dumb batteries when all knowledge about
their state belongs to the platform that does necessary ADC readings,
conversions, guessimations etc.
Signed-off-by: Paul Fertser <fercerpav@gmail.com>
|
|
|
|
|
|
This reduces the code clutter a bit and will ease an the migration to genirq.
|
|
Use a threaded irq instead of normal irq and a workqueue.
|
|
|
|
|
|
This patch adds a backlight driver controling the pcf50633 led converter.
Signed-off-by: Lars-Peter Clausen <lars@metafoo.de>
|
|
Currently it's not guaranteed that request struct is not already freed when
reading from it. Fix this by moving synced request related fields from the
pcf50633_adc_request struct to its own struct and store it on the functions
stack.
Signed-off-by: Lars-Peter Clausen <lars@metafoo.de>
|
|
|
|
This patch adds a flag to the s3c2410_nand platform data, which configures
whether hardware ecc is used for that chip.
Currently hardware ecc is used if it was compiled into the kernel. But if you
want to build a kernel which runs on multiple devices you might have a
configuration where you have devices which require hw ecc as well as devices
which want software ecc.
Signed-off-by: Lars-Peter Clausen <lars@metafoo.de>
|
|
This is a patch that seems to make the USB hangs on the S3C2440 go away. At
least a good amount of ping torture didn't make them come back so far.
The issue is that, if there are several back-to-back packets,
sometimes no interrupt is generated for one of them. This
seems to be caused by the mysterious dual packet mode, which
the USB hardware enters automatically if the endpoint size is
half that of the FIFO. (On the 2440, this is the normal
situation for bulk data endpoints.)
There is also a timing factor in this. I think what happens is
that the USB hardware automatically sends an acknowledgement
if there is only one packet in the FIFO (the FIFO has space
for two). If another packet arrives before the host has
retrieved and acknowledged the previous one, no interrupt is
generated for that second one.
However, there may be an indication. There is one undocumented
bit (none of the 244x manuals document it), OUT_CRS1_REG[1],
that seems to be set suspiciously often when this condition
occurs. There is also CLR_DATA_TOGGLE, OUT_CRS1_REG[7], which
may have a function related to this. (The Samsung manual is
rather terse on that, as usual.)
This needs to be examined further. For now, the patch seems to do the
trick.
Note that this is not a clean solution by any means, because we
might potentially get stuck in that interrupt for quite a while.
|
|
|
