Samsung S3C6410 / SmartQ / 2D acceleration / Xorg

Samsung S3C6410 / SmartQ / 2D acceleration / Xorg

[Maurus Cuelenaere]

Hi Harald, I also have a working 2.6.31 port to the SmartQ Q7 at 
http://gitorious.org/mcuelenaere-smartq-kernel/mcuelenaere-smartq-kernel 
(this was based on the patch SmartDevices gave to the Mer team, see 
http://gitorious.org/mer-smartq/mer-smartq-kernel )
>> >  I have a fairly decent SmartQ5/7 config and mach-smartq init file.  Much of
>> >  this work (that I can test) can be back ported to the smdk6410 (that I can't
>> >  test.:-)
> So you're hacking on the SmartQ devices?  I recently discovered that they exist and I was
> very intrigued in buying one.
>
> Maybe you can tell me if you or anyone else in the community that is hacking on
> those devices have yet figured out
>
> 1) where the testpads/connector for the serial console is
> 2) where the testpads/connector for the JTAG console is
At least for the Q7, I can confirm there are RX, TX, 3V and GND pins on 
the board itself (haven't tested them, but I'm pretty sure those are the 
UART pins). Don't know about JTAG. I've done some documentation at 
http://wiki.maemo.org/Mer/Status/SmartQ7 wrt the hardware internals of 
the Q7. Regards, Maurus Cuelenaere

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20090911/3259d32f/attachment-0001.htm>

Samsung S3C6410 mainline merge coordination

[Harald Welte]

Hi Ben,
Hi linux-arm-kernel list members,

as indicated before, Samsungs SoC Linux developers are currently working
on getting more of their work ready for (and submitted to) mainline.

At the end of this mail, I have included a list of current TODO items.  They
are written with the following question im mind:  "What do we need to do in
order to get the existing code (or new features) from samsung's 2.6.28 into
mainline and then submitted."

We're actively looking for feedback.  you can find Samsungs current code
in the 2.6.28-samsung branch of
git://git.kernel.org/pub/scm/linux/kernel/git/kki_ap/linux-2.6-samsung.git
in case you want to review and give feedback.

We also need your feedback in which areas there might be overlap. Let's say you
already have a touchscreen driver on top of your ADC layer, then obviously
there is no need for Samsungs team to duplicate that work.

Currently the plan is as follows:

== core arch/arm support for 6410 ==

=== DMA ===
* check if mainline driver supports all features of samsung driver
** if not, add missing features to mainline driver, test and submit

=== HR-TIMER ===
* port/merge/test + submit mainline

=== plat-s3c/clock.c ===
* submit clk->owner bugfix mainline

=== plat-s3c/gpio.c ===
* off-by-one error, send fix mainline

=== suspend-to-ram ===
* port to mainline and test, submit mainline


== drivers ==

=== IDE ===
* mainline API change
* Samsung needs to avoid touching generic code
* if we change generic code, make sure change is only when executed on
  s3c SoC, rather than a compile-time define

=== keypad ===
* move s3c-keypad.h into s3c-keypad.c
* define number of rows/columns in platform_data
* make delay depend on platform_data rather than compiletime
* move key_base into struct s3c_keypad
* use standard kernel debug messages
* get rid of TRUE/FALSE
* move keypad_timer, is_timer_on and keypad_clock into s3c_keypad
* submit mainlien

=== adc / touchscreen ===
* move plat-s3c24xx/adc.c to plat-s3c/adc.c
* update it with 6410 specific ADC extensions (12bit, faster clock, ...)
* port existing s3c_ts driver to use s3c_adc_register()
** has anyone been doing wokr on this already? ben?
* introduce new 'inverted' property in toucscreen platform_data
** the purpose is to support machines that have the (0,0) coordinate not
   in the top left corner but a different location of the screen
** use it for runtime checking, remove CONFIG_TOUCHSCREEN_NEW

=== video / multimedia ===
* needs a lot of thought
* support standard mainlien architecture wherever possible
** 2D accelerated framebuffer
** DRI/DRM/TTM/KMS
** V4L

=== s5m8751 PMIC ===
* samsung has a mfd driver in their 2.6.28 based tree
* only on special development board, not on stock SMDK
* nonetheless, we want to submit mainline
* lower priority, since not on SMDK

=== SD/MMC ===
* mainline uses existing SDHCI driver, not HSMMC
* fix mainline s3c-sdhci clock related bugs, submit mainline
* add ADMA support and submit mainline
* test / make sure it's feature complete: 1...n patches
* what about 8bit MMC? add as separate patch
* what about MMC highspeed? add as separate patch
* fast boot for movinand? add as separate patch

=== NAND ===
* mainline currently uses same driver for s3c24xx and s3c64xx
** samsung uses a new driver for 2450, 6400, 6410 (and later)
* does it make sense to extend the mainline driver with new SoC support
  or should we rather split the mainline driver?
* mainline driver does not yet support 4kB page sizer with 8bit ECC
** requires core NAND stack changes 
** introduce new oobinfo structure / ioctl to keep kernel/userspace ABI stable!
* define oob layout just in core, use chip->ecc.layout reference in s3c driver

=== OneNAND ===
* mainline onenand code is for ROM interface, does not apply to s3c64xx
* more internal discussion before we know what to do for mainline

=== IRDA ===
* Samsung has a driver in its tree, but customer demand is close to zero
* low priority, driver should be merged/tested in current mainline, then
  submitted

=== RTC ===
* needs more investigation, some code is in samsung tree that is not mainline
* what does it do, why?  something alarm related?

=== SPI ===
* separate SPI slave mode changes from actual 64xx driver
* start with submitting the SPI master mode driver
* then discuss how to add slave to core Linux SPI system
* then finally add SPI slave code to s3c driver

=== USB Gadget ===
* there are two drivers inside Samsung, one developed by System LSI
  and one developed by DMC Lab (Kyungmin Park's team)
* discuss with Kyungmin Park's team, decide which driver should go ahead

=== USB OTG Host ===
* Samung's current driver has a OS abstraction layer and is only glued
  to Linux.  Reasoning was to have one driver that is chapter9 certified.
* However, Linux mianline doesn't accept this
* have to write new actual Linux driver

=== Watchdog ===
* Samsung uses 24xx driver on 6410, no harware change
* test existing mainline 24xx code on 6410
* then send Kconfig change patch to mainline

=== Sound ===
* needs further investigation, there are many different drivers/versions/options

-- 
- Harald Welte <laforge@gnumonks.org>           http://laforge.gnumonks.org/
============================================================================
"Privacy in residential applications is a desirable marketing option."
                                                  (ETSI EN 300 175-7 Ch. A6)

Samsung S3C6410 mainline merge coordination

[David F. Carlson]

According to Harald Welte:
> 
> === plat-s3c/gpio.c ===
> * off-by-one error, send fix mainline

I have added the bank-k and bank-l and submitted the patch to Ben.
> 
> === suspend-to-ram ===
> * port to mainline and test, submit mainline

Another s3c issue that needs to be addressed further is the number of special purpose pins for power management, audio/video codec, otg detect, etc. that vary from mach to mach.  Many of the drivers do not have a means to use the mach-specific gpios -- and yet most are required to useful function.

The mach I am using has a whole "kluge" driver to handle the mach-specific gpios.  Oi.  These will have to be knocked down one by one for a decent save-restore to work.
> 
> 
> === adc / touchscreen ===
I too have "ported" a touchscreen impl.  I didn't know others were working it...

I have ditched the 6410-adc stuff in favor of the "common" s3c api.  From my read the 12bit adc is supported as-is via a platdata:

static struct s3c_adc_mach_info s3c_adc_platform = {
   /* s3c6410 support 12-bit resolution */
   .delay   =  10000,
   .presc   =  49,
   .resolution =  12,
};


I am also working on a "canonical" PWM backlight driver using the pwm_bl lcd support and the 6410 pwm timer support in next-s3c.  It is mostly working and should be ready to push soon.

I have a fairly decent SmartQ5/7 config and mach-smartq init file.  Much of this work (that I can test) can be back ported to the smdk6410 (that I can't test. :-)

> === video / multimedia ===
> * needs a lot of thought
> * support standard mainlien architecture wherever possible
> ** 2D accelerated framebuffer
> ** DRI/DRM/TTM/KMS
> ** V4L

I have a "port" to next-s3c of the exiting sansumg-ap-2.6 media drivers.  They load.  It is a start anyway...  Another downside to these drivers is that their memory is statically allocated a boot-time.  I have asked Ben to consider taking this "port" into next-s3c as a basis for common work since it won't get better until people can work it.

I am not sure the g2d driver is particular useful for a accel X driver.  The fifo mechanism with polling might work better than an ioctl-like interrupt blit-only based one.  It seems kinda expensive to trap the the kernel for every 2d-op.  Kinda like MSWindows then.  :-)
> 
> 

David F. Carlson    Chronolytics, Inc.  Rochester, NY
mailto:dave at chronolytics.com            http://www.chronolytics.com

"The faster I go, the behinder I get." --Lewis Carroll

Samsung S3C6410 / SmartQ / 2D acceleration / Xorg

[Harald Welte]

Dear David,

> I have a fairly decent SmartQ5/7 config and mach-smartq init file.  Much of
> this work (that I can test) can be back ported to the smdk6410 (that I can't
> test. :-)

So you're hacking on the SmartQ devices?  I recently discovered that they exist and I was
very intrigued in buying one. 

Maybe you can tell me if you or anyone else in the community that is hacking on
those devices have yet figured out 

1) where the testpads/connector for the serial console is
2) where the testpads/connector for the JTAG console is

I've also seen that somebody has been working on an accelerated (EXA) xorg
driver for the 6410, using the samsung-provided 2d driver.  I want to try
that work and play with it, also as a basis to help me to decide what would be
a good way to go ahead for a more standard Linux grephics stack on the 6410 and
related devices.

> I have a "port" to next-s3c of the exiting sansumg-ap-2.6 media drivers.
> They load.  It is a start anyway...  Another downside to these drivers is
> that their memory is statically allocated a boot-time.  I have asked Ben to
> consider taking this "port" into next-s3c as a basis for common work since it
> won't get better until people can work it.

would you mind sharing those drivers or any other work you have in a git tree
that I can have public read access to?

Also, generally speaking, what git tree would you recommend for playing with
the SmartQ devices?

> I am not sure the g2d driver is particular useful for a accel X driver.  The
> fifo mechanism with polling might work better than an ioctl-like interrupt
> blit-only based one.  It seems kinda expensive to trap the the kernel for
> every 2d-op.  Kinda like MSWindows then.  :-)

yes, a regular userspace Xorg EXA driver makes probably much more sense.
If the polling turns out to waste too many cycles, we can still think of some
interrupt-to-userspace delivery mechanism where we don't need to busy-wait
in the Xorg driver.

Regards,
-- 
- Harald Welte <laforge@gnumonks.org>           http://laforge.gnumonks.org/
============================================================================
"Privacy in residential applications is a desirable marketing option."
                                                  (ETSI EN 300 175-7 Ch. A6)

Samsung S3C6410 / SmartQ / 2D acceleration / Xorg

[Ben Dooks]

On Thu, Sep 10, 2009 at 02:49:42PM +0900, Harald Welte wrote:
> Dear David,
> 
> > I have a fairly decent SmartQ5/7 config and mach-smartq init file.  Much of
> > this work (that I can test) can be back ported to the smdk6410 (that I can't
> > test. :-)
> 
> So you're hacking on the SmartQ devices?  I recently discovered that they exist and I was
> very intrigued in buying one. 

[snip]
 
> yes, a regular userspace Xorg EXA driver makes probably much more sense.
> If the polling turns out to waste too many cycles, we can still think of some
> interrupt-to-userspace delivery mechanism where we don't need to busy-wait
> in the Xorg driver.

does uio support wait-for-interrupt?

-- 
Ben

Q:      What's a light-year?
A:      One-third less calories than a regular year.