| Age | Commit message (Collapse) | Author |
|---|
|
This patch fixes a bug where the TS might stop working after suspend/resume.
This patch is under upstream review and it seems it will change a lot.
Signed-off-by: Vasily Khoruzhick <anarsoul@gmail.com>
Signed-off-by: Nelson Castillo <arhuaco@freaks-unidos.net>
|
|
|
|
Add the ts and the relevant files.
Signed-off-by: Nelson Castillo <arhuaco@freaks-unidos.net>
|
|
Add filter source code and add it to the defconfig.
Signed-off-by: Nelson Castillo <arhuaco@freaks-unidos.net>
|
|
Without this patch we cannot make the s3c2410/s3c2440 touchscreen
driver work. This will be done in a different way in upstream kernel.
We specify the delay value (S3C2410_ADCDLY).
Signed-off-by: Vasily Khoruzhick <anarsoul@gmail.com>
Signed-off-by: Nelson Castillo <arhuaco@freaks-unidos.net>
|
|
|
|
|
|
This adds support for platform_battery driver which allows to specify a set
of power supply properties and callbacks to acquire them. It is needed to
support dumb batteries where all the information about their status can
only be obtained by platform-specific actions such as specific ADC
measurements, some guessimation etc.
Signed-off-by: Paul Fertser <fercerpav@gmail.com>
|
|
|
|
Signed-off-by: Nelson Castillo <arhuaco@freaks-unidos.net>
|
|
... and remove unused reset pin resource.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
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>
|
|
|
|
In some cases it is desirable to completly disable low-level messages. For
example if you have no uart available for a serial console.
With this patch it is possible to disable low-level messages by setting
CONFIG_S3C_LOWLEVEL_UART_PORT to less then zero.
Signed-off-by: Lars-Peter Clausen <lars@metafoo.de>
|
|
This is nonportable and wastes a lot of memory and thus should be replaced with
a prober solution asap.
|
|
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.
|
|
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>
|
|
The gta02 uses the glamo mfd driver which requires 9 board irqs.
Signed-off-by: Lars-Peter Clausen <lars@metafoo.de>
|
|
Some boards have a need for a set of extra IRQ numbers, for example some
multifunction devices which do irq demultiplexing require them.
This patch adds S3C2410_BOARD_NR_IRQS which specifies the number of extra board
IRQs. Board specific code would use S3C2410_BOARD_IRQ_START to get the number of
it's first irq.
Since it is possible to support a multiple boards with a single kernel and
there is no easy way to set a CONFIG option to multiple values and only use the
maximum each board which needs board IRQs has do be explicitly added to irqs.h
Signed-off-by: Lars-Peter Clausen <lars@metafoo.de>
|
|
|
|
|
|
Early verions off uboot used for the gta02 flashed the nand with ecc information
incompatible to s3c2442 hardware ecc. Disable hardware error correction by
default, unless the bootloader explicitly enables it.
Signed-off-by: Lars-Peter Clausen <lars@metafoo.de>
|
|
|
|
|
|
|
|
|
|
On hardware revision 5 and earlier the leds found on the gta02 are missing a
resistor and reading their gpio pin status will always return 0. So we have to
shadow the led states in software. This is done by "hijacking" the gpio accessor
functions for bank B.
Signed-off-by: Lars-Peter Clausen <lars@metafoo.de>
|
|
The gta02 has three leds which are connected though gpio pins and thus can get
supported by using the generic leds-gpio driver.
Signed-off-by: Lars-Peter Clausen <lars@metafoo.de>
|
|
The gta02 has two buttons which are connected to gpio pins and thus can get
supported by using the generic gpio-keys driver.
Signed-off-by: Lars-Peter Clausen <lars@metafoo.de>
|
|
not registered.
|
|
|
|
cleanups
|
|
This patch adds a backlight driver controling the pcf50633 led converter.
Signed-off-by: Lars-Peter Clausen <lars@metafoo.de>
|
|
As those constans are alread bitfields it's wrong
Those constants are already bitfields.
|
|
Currently the pcf50633-regulator driver data is set to the pcf50633 core
structure, but the pcf50633-regulator remove handler assumes that it is set to
the regulator device. This patch fixes the issue by accessing the pcf506533
core structure through its parent device and setting the driver data to the
regulator device.
Signed-off-by: Lars-Peter Clausen <lars@metafoo.de>
|
|
Platform devices allocated with platform_device_alloc should use
platform_device_add_data to set the platform data, because kfree will be called
on the platform_data when the device is released.
Signed-off-by: Lars-Peter Clausen <lars@metafoo.de>
|
|
Currently the child devices were not freed if the irq could not be requested.
This patch restructures the function, that in case of an error all previously
allocated resources are freed.
Signed-off-by: Lars-Peter Clausen <lars@metafoo.de>
|
|
Since platform_device_add_data copies the passed data, the allocated
subdev_pdata is never freed. A simple fix would be to either free subdev_pdata
or put it onto the stack. But since the pcf50633 child devices can rely on
beeing children of the pcf50633 core device it's much more elegant to get access
to pcf50633 core structure through that link. This allows to get completly rid
of pcf5033_subdev_pdata.
Signed-off-by: Lars-Peter Clausen <lars@metafoo.de>
|
|
Signed-off-by: Arnaud Patard <arnaud.patard@rtp-net.org>
Signed-off-by: Paul Fertser <fercerpav@gmail.com>
|
|
When not using the i2c suspend/resume callbacks the i2c client resumed
before the i2c master.
Signed-off-by: Lars-Peter Clausen <lars@metafoo.de>
Signed-off-by: Paul Fertser <fercerpav@gmail.com>
|
|
On gta02 hardware revision A5 it can actually bring the system down
during normal operating conditions so we disable it.
Signed-off-by: Paul Fertser <fercerpav@gmail.com>
|
|
Current scheme is fragile and is likely to go off sync, especially on
batfull->adapter charging automatic MBC transition.
Query the status bit every time we need it instead.
We need to export another function to query for USB presence because
we can't read anything from PCF50633 (via I2C) inside irq context and
that is needed by usb gadgets.
Signed-off-by: Paul Fertser <fercerpav@gmail.com>
|
|
If chgmod == BATFULL, setting chgena has no effect. Datasheet says we
need to set resume instead but when autoresume is used resume doesn't
work. Clear and set chgena instead.
This enables a user to force charging by re-plugging USB even when the
charger entered Battery Full mode, might be handy before a long trip.
Signed-off-by: Paul Fertser <fercerpav@gmail.com>
|
