>Ben Dooks wrote:
>
>On Mon, May 31, 2010 at 11:08:51AM +0200, Pawel Osciak wrote:
>> FRAMESEL1 bitfield starts on 13th bit, not on 14th.
>
>is this true for all variants that have FRAMESEL1?
That's at least the case for all the chips I have docs for:
6400, 6410, S5PC100 and V210...
Best regards
On Tue, Jun 01, 2010 at 02:13:18PM +0900, MyungJoo Ham wrote:
> On Tue, Jun 1, 2010 at 11:03 AM, Ben Dooks wrote:
> >
> > On Tue, Jun 01, 2010 at 10:36:04AM +0900, Kukjin Kim wrote:
> >> From: Jongpill Lee
> >>
> >> This patch adds suspend-to-ram support for S5PV210.
> >>
> >> Signed-off-by: Jong
On Tue, Jun 1, 2010 at 11:03 AM, Ben Dooks wrote:
>
> On Tue, Jun 01, 2010 at 10:36:04AM +0900, Kukjin Kim wrote:
>> From: Jongpill Lee
>>
>> This patch adds suspend-to-ram support for S5PV210.
>>
>> Signed-off-by: Jongpill Lee
>> Signed-off-by: Kukjin Kim
>> ---
>> Changes since v1:
>>
>> 1. F
On Tue, Jun 1, 2010 at 1:16 PM, Ben Dooks wrote:
> On Tue, Jun 01, 2010 at 12:23:39PM +0900, Kyungmin Park wrote:
>> On Tue, Jun 1, 2010 at 11:03 AM, Ben Dooks wrote:
>> >
>> > On Tue, Jun 01, 2010 at 10:36:04AM +0900, Kukjin Kim wrote:
>> >> From: Jongpill Lee
>> >>
>> >> This patch adds suspen
On Mon, May 31, 2010 at 11:08:51AM +0200, Pawel Osciak wrote:
> FRAMESEL1 bitfield starts on 13th bit, not on 14th.
is this true for all variants that have FRAMESEL1?
> Signed-off-by: Pawel Osciak
> Signed-off-by: Kyungmin Park
> ---
> arch/arm/plat-samsung/include/plat/regs-fb.h | 10 +
On Tue, Jun 01, 2010 at 12:23:39PM +0900, Kyungmin Park wrote:
> On Tue, Jun 1, 2010 at 11:03 AM, Ben Dooks wrote:
> >
> > On Tue, Jun 01, 2010 at 10:36:04AM +0900, Kukjin Kim wrote:
> >> From: Jongpill Lee
> >>
> >> This patch adds suspend-to-ram support for S5PV210.
> >>
> >> Signed-off-by: Jon
On Tue, Jun 1, 2010 at 11:03 AM, Ben Dooks wrote:
>
> On Tue, Jun 01, 2010 at 10:36:04AM +0900, Kukjin Kim wrote:
>> From: Jongpill Lee
>>
>> This patch adds suspend-to-ram support for S5PV210.
>>
>> Signed-off-by: Jongpill Lee
>> Signed-off-by: Kukjin Kim
>> ---
>> Changes since v1:
>>
>> 1. F
On Tue, Jun 01, 2010 at 11:04:52AM +0900, Kukjin Kim wrote:
> From: Banajit Goswami
>
> This patch adds support for Watchdog timer for Samsung S5PC100.
>
> Signed-off-by: Banajit Goswami
> Signed-off-by: Kukjin Kim
> ---
> arch/arm/mach-s5pc100/Kconfig|2 ++
> arch/arm/mach-s5
From: Banajit Goswami
This patch adds support for Watchdog timer for Samsung S5PC100.
Signed-off-by: Banajit Goswami
Signed-off-by: Kukjin Kim
---
arch/arm/mach-s5pc100/Kconfig|2 ++
arch/arm/mach-s5pc100/include/mach/map.h |3 +++
arch/arm/mach-s5pc100/mach-smdkc100.c
On Tue, Jun 01, 2010 at 10:36:04AM +0900, Kukjin Kim wrote:
> From: Jongpill Lee
>
> This patch adds suspend-to-ram support for S5PV210.
>
> Signed-off-by: Jongpill Lee
> Signed-off-by: Kukjin Kim
> ---
> Changes since v1:
>
> 1. Fixed comments as per comments from Ben Dooks
> 2. Removed red
From: Jongpill Lee
This patch adds suspend-to-ram support for S5PV210.
Signed-off-by: Jongpill Lee
Signed-off-by: Kukjin Kim
---
Changes since v1:
1. Fixed comments as per comments from Ben Dooks
2. Removed redunt #if defined(CONFIG_PM)
3. Removed redunt including header files
4. Removed and
The crypto engine uses the DMACH_SECURITY_[RT]X channels, who seem to be
hardcoded to SDMA-only in hardware, so add support for SDMA to the S3C64XX
DMA core.
Only DMACH_SECURITY_[RT]X are using SDMA, other channels are unaffected and
will continue to use standard DMA.
Signed-off-by: Maurus Cuelen
Hi,
I'm currently trying to develop a driver for the Samsung crypto engine
available
in S3C64XX and S5PC100 SoC's (the only SoC's I could find datasheets for).
However, I'm running into problems in both DMA and FIFO mode: when using
DMA,
the RX transfer seems to be pushing (len-4) bytes to the FI
When a DMA channel is freed, its pending requests should be flushed and the
channel should be halted. This patch ensures that happens.
Signed-off-by: Maurus Cuelenaere
---
arch/arm/mach-s3c64xx/dma.c |3 ++-
1 files changed, 2 insertions(+), 1 deletions(-)
diff --git a/arch/arm/mach-s3c64xx
The crypto engine uses the DMACH_SECURITY_[RT]X channels, who seem to be
hardcoded to SDMA-only in hardware, so add support for SDMA to the S3C64XX
DMA core.
Only DMACH_SECURITY_[RT]X are using SDMA, other channels are unaffected and
will continue to use standard DMA.
Signed-off-by: Maurus Cuelen
This adds the clock definition bits for SDMA.
Signed-off-by: Maurus Cuelenaere
---
arch/arm/mach-s3c64xx/clock.c | 12
1 files changed, 12 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-s3c64xx/clock.c b/arch/arm/mach-s3c64xx/clock.c
index 7a4138b..d3e11a1 100644
--- a/
The first two patches add support for SDMA to the DMA core, which the crypto
engine needs to support DMA.
The third one implements behaviour that seems to be forgotten, namely stopping
and flushing pending requests on freeing a DMA channel.
Maurus Cuelenaere (3):
ARM: S3C64XX: Add SDMA clocks
On Mon, May 31, 2010 at 11:08:55AM +0200, Pawel Osciak wrote:
> Add VSYNC interrupt support and an ioctl that allows waiting for it.
> Interrupts are turned on only when needed.
>
> Signed-off-by: Pawel Osciak
> Signed-off-by: Kyungmin Park
> ---
> arch/arm/plat-samsung/include/plat/regs-fb.h |
Hi,
There is cfg_eint field in struct s3c_gpio_cfg at
arch/arm/plat-samsung/include/plat/gpio-cfg.h. I don't know the usage of
cfg_eint. It isn't used anywhere or just assigned. Does it need really?
struct s3c_gpio_cfg {
unsigned intcfg_eint;
s3c_gpio_pull_t (*get_pull)(str
On Sun, May 30, 2010 at 02:04:39PM +0900, Jassi Brar wrote:
> I believe on most implementations, if not all, sizeof char, short and
> int are resp
> 1, 2 and 4 bytes. whereas long denotes the native capacity of the arch.
This is very common for interoperability with code making the assumption
tha
The following problems were found in the above situation:
sfb->windows[win] was being assigned at the end of s3c_fb_probe_win only.
This resulted in passing a NULL to s3c_fb_release_win if probe_win returned
early and a memory leak.
dma_free_writecombine does not allow its third argument to be NU
Supports all bpp modes.
The PRTCON register is used to disable in-hardware updates of registers
that store start and end addresses of framebuffer memory. This prevents
display corruption in case we do not make it before VSYNC with updating
them atomically. With this feature there is no need to wai
Add VSYNC interrupt support and an ioctl that allows waiting for it.
Interrupts are turned on only when needed.
Signed-off-by: Pawel Osciak
Signed-off-by: Kyungmin Park
---
arch/arm/plat-samsung/include/plat/regs-fb.h |1 +
drivers/video/s3c-fb.c | 171 +++
Hello,
This series is rebased onto Ben Dook's framebuffer branch available at:
git://git.fluff.org/bjdooks/linux.git dev/s3c-fb
The main changes are the addition of an ability to wait for VSYNC and
display panning.
The first patch attempts to fix some NULL pointer dereferences in case
of a faile
FRAMESEL1 bitfield starts on 13th bit, not on 14th.
Signed-off-by: Pawel Osciak
Signed-off-by: Kyungmin Park
---
arch/arm/plat-samsung/include/plat/regs-fb.h | 10 +-
1 files changed, 5 insertions(+), 5 deletions(-)
diff --git a/arch/arm/plat-samsung/include/plat/regs-fb.h
b/arch/ar
Add framebuffer device name initialization calls for S3C2443, S3C64xx
and S5P machines.
Signed-off-by: Pawel Osciak
Signed-off-by: Kyungmin Park
---
arch/arm/mach-s3c2443/s3c2443.c |2 +
arch/arm/mach-s3c64xx/s3c6400.c |3 ++
arch/arm/mach-s3c64xx/s3c6410.c
S5PC100 and S5PV210 framebuffer devices differ slightly in terms of
available registers and their driver data structures have to be separate.
Signed-off-by: Pawel Osciak
Signed-off-by: Kyungmin Park
---
drivers/video/s3c-fb.c | 37 ++---
1 files changed, 34 ins
From: Boojin Kim
This patch fixes bug on eint type set function, s5p_irq_eint_set_type().
In the IRQ_TYPE_EDGE_FALLING case, S5P_EXTINT_FALLEDGE is right
instead of S5P_EXTINT_RISEEDGE
Signed-off-by: Boojin Kim
Signed-off-by: Kukjin Kim
---
arch/arm/plat-s5p/irq-eint.c |2 +-
1 files chan
28 matches
Mail list logo
