Samsung S3C6410 mainline merge coordination

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

[Nelson Castillo]

> * port existing s3c_ts driver to use s3c_adc_register()
> ** has anyone been doing wokr on this already? ben?

(jumping in)

I worked on this starting from some work done by other members of this
list. This is the ported version of the driver. It depends on the
touchscreen filters developed by Andy Green and enhanced by me while
working at Openmoko. I've already applied most of Andrew Morton's
feedback (a lot) to the TS filters but I haven't submitted them again
for upstream review (A filter still needs to be modified and I know
how to do it but I haven't finished this change).

http://nelson-patches.googlecode.com/svn/trunk/openmoko/kernel/ts-with-s3c-adc/s3c2410_ts.c
http://nelson-patches.googlecode.com/svn/trunk/openmoko/kernel/ts-with-s3c-adc/

One problem here is that we need to find a way to do this in a cleaner way:

http://nelson-patches.googlecode.com/svn/trunk/openmoko/kernel/ts-with-s3c-adc/s3c-adc-add-delay.patch

Nelson.-

Samsung S3C6410 mainline merge coordination

[Mark Brown]

On Wed, Sep 02, 2009 at 12:17:19PM +0900, Harald Welte wrote:

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

Merge any changes in with the mainline drivers - there's relatively
little difference from the s3c24xx IPs.  There's a reasonable chance
I'll get round to this myself for the 64xx series since I have one which
I'm using for some of my development.

Samsung S3C6410 mainline merge coordination

[Harald Welte]

On Wed, Sep 02, 2009 at 05:43:14PM +0800, tommy.hong wrote:

> does it support X kdrive 2D accelerate ?

X / kdrive is not part of the linux kernel.  Therefore, it is unrelated
to the Linux kernel code that we are working on.
-- 
- 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 mainline merge coordination

[Harald Welte]

Hi Mark,

On Wed, Sep 02, 2009 at 11:05:01AM +0100, Mark Brown wrote:
 
> > === Sound ===
> > * needs further investigation, there are many different drivers/versions/options
> 
> Merge any changes in with the mainline drivers - there's relatively
> little difference from the s3c24xx IPs.  There's a reasonable chance
> I'll get round to this myself for the 64xx series since I have one which
> I'm using for some of my development.

please note there are something like four different versions of the audio IP
core in Samsung SoCs.  I myself am not familiar with the detailed technical
differences.  So in any case we'll try to submit the current code in a way
that will not create conflicts or issues with code that is pending further
down the road for s5pc100. or s5pc110.

Apparently there are also features like operating the SoC codec in slave mode
as well as different clock configurations wich mainline is missing.

Jaswinder (you know him from previous mails) today stated he will look into
this.  We have just not defined yet in detail what features will be submitted
and what are the priorities.

If you (Mark) would want to work on this, pleaes coordinate with Jaswinder so
there is no duplication of work.  I believe the most current driver source is
the one in the 2.6.29-samsung branch - but that one already has the s5pc stuff,
which will have to be removed for mainline right now.

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 mainline merge coordination

[Harald Welte]

Hi Nelson,

On Wed, Sep 02, 2009 at 04:51:56AM -0500, Nelson Castillo wrote:
> > * port existing s3c_ts driver to use s3c_adc_register()
> > ** has anyone been doing wokr on this already? ben?
> 
> (jumping in)
> 
> I worked on this starting from some work done by other members of this
> list. This is the ported version of the driver. It depends on the
> touchscreen filters developed by Andy Green and enhanced by me while
> working at Openmoko. I've already applied most of Andrew Morton's
> feedback (a lot) to the TS filters but I haven't submitted them again
> for upstream review (A filter still needs to be modified and I know
> how to do it but I haven't finished this change).

Hi, thanks for your feedback.  I think it is somewhat "dangerous" to create a
dependency from s3c2410_ts (which schould be renamed to s3c_ts by now) to the
ts_filter work.

I'd personally prefer to decouple those two, i.e. first submit the s3c_ts based
on adc.c without ts_filter, and then add the ts_filter core (plus support
for s3c_ts) later on.

I suppose you don't mind, so we'll go ahead with this and submit s3c_ts this
way.

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 mainline merge coordination

[Peter Korsgaard]

>>>>> "David" == David F Carlson <dave@chronolytics.com> writes:

Hi,

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

What are you missing from the generic pwm-backlight driver? That's what
I'm using on the hmt.

-- 
Bye, Peter Korsgaard

Samsung S3C6410 mainline merge coordination

[Peter Korsgaard]

>>>>> "Harald" == Harald Welte <laforge@gnumonks.org> writes:

Hi,

 Harald> === NAND ===
 Harald> * mainline currently uses same driver for s3c24xx and s3c64xx
 Harald> ** samsung uses a new driver for 2450, 6400, 6410 (and later)
 Harald> * does it make sense to extend the mainline driver with new SoC support
 Harald>   or should we rather split the mainline driver?

The nand controllers in the different variants are afaik very similar,
that's why I added 64xx support to s3c2410.c. What would a split gain
us?

-- 
Bye, Peter Korsgaard

Samsung S3C6410 mainline merge coordination

[jassi brar]

On Wed, Sep 2, 2009 at 9:11 PM, Harald Welte<laforge@gnumonks.org> wrote:
> On Wed, Sep 02, 2009 at 11:05:01AM +0100, Mark Brown wrote:
>> > === Sound ===
>> > * needs further investigation, there are many different drivers/versions/options
>>
>> Merge any changes in with the mainline drivers - there's relatively
>> little difference from the s3c24xx IPs. ?There's a reasonable chance
>> I'll get round to this myself for the 64xx series since I have one which
>> I'm using for some of my development.
>
> Apparently there are also features like operating the SoC codec in slave mode
> as well as different clock configurations wich mainline is missing.

Yes, none of mainline SMDK supports SoC-Slave mode or sourcing I2S IP with
various possible clocks(PCLK, EPLL, CDCLK) etc yet. Samsung tree has
implemented
and fully tested these features for 6410, 6440 and C100.

My idea is to submit only "better enabled" I2S driver with Slave support.
Clock sourcing related patch maybe later added when the EPLL etc clock
support has been submitted.

An issue though.
In the long run, I see I2S drivers segregated by the I2S spec version
they implement....
S3C2410 has I2S-2.0, S3C6410 has I2S-3.2 and I2S-4.0, S5P6440 has
I2S-4.0, S5PC100 has
I2S-3.2 and I2S-5.1 and so on. That is, we have something like
samsung-i2s_v20.c, samsung-i2s_v32.c,
samsung-i2s_v40.c, samsung-i2s_v51.c.
SoC specific register addresses and other peculiarities maybe
differentiated by defines in coresp. header files.
Let Samsung come with as many SoCs as it wishes, I2S support will
simply end up in header files. Also, that we
can do away with using s3c24xx stuff in 64xx and S5Pxxxx code.
For now, I haven't implemented h/w mixing and 5.1 channel support so
v32 and v40 are just the same.
Whereas, mainline s3c-i2s approach currently concentrates on
extracting common code in one file(s3c-i2s-v2.c) or so do i think.

I sincerely seek to discuss this issue.

Samsung S3C6410 mainline merge coordination

[Mark Brown]

On Wed, Sep 02, 2009 at 09:11:58PM +0900, Harald Welte wrote:
> On Wed, Sep 02, 2009 at 11:05:01AM +0100, Mark Brown wrote:

> > Merge any changes in with the mainline drivers - there's relatively
> > little difference from the s3c24xx IPs.  There's a reasonable chance
> > I'll get round to this myself for the 64xx series since I have one which
> > I'm using for some of my development.

> please note there are something like four different versions of the audio IP
> core in Samsung SoCs.  I myself am not familiar with the detailed technical

Yes, there's at least four IIS blocks I'm aware of - but there's a lot
of shared stuff in the devices I've seen and the programming models
haven't varied radically between them.  A lot of the time it's been more
at the level of slightly incompatible register maps than anything else.
Some of the SoCs have a mix'n'match of IP versions too which makes it
harder to find a clean break to flip over at.

I'm open to other suggestions but I'd need to see some sort of
persuasive argument that the platform support should be forked -
obviously, having two different sets of drivers makes for more
maintinance work which would be unfortunate.

> Apparently there are also features like operating the SoC codec in slave mode
> as well as different clock configurations wich mainline is missing.

Yes, the current drivers aren't entirely complete.  Most of what's
needed is relatively minor, and much of it is largely outside the audio
driver itself like the selection of alternate chip internal clock
sources which is more an issue in the clock API.

> If you (Mark) would want to work on this, pleaes coordinate with Jaswinder so
> there is no duplication of work.  I believe the most current driver source is
> the one in the 2.6.29-samsung branch - but that one already has the s5pc stuff,
> which will have to be removed for mainline right now.

The easiest thing will just be if he monitors alsa-devel; any work will
be visible there.  I don't envisage doing anything massively substantial
myself in the immediate future.

I think the major thing here is to bring the Samsung code up to current
kernel versions and start contributing to mainline as soon as possible -
the problem here is divergent development.  There's other people with an
interest in mainline support for audio on these processors too and the
more rapidly things converge on a single tree the better.

Samsung S3C6410 mainline merge coordination

[Mark Brown]

On Wed, Sep 02, 2009 at 10:44:35PM +0900, jassi brar wrote:

> Yes, none of mainline SMDK supports SoC-Slave mode or sourcing I2S IP with
> various possible clocks(PCLK, EPLL, CDCLK) etc yet. Samsung tree has
> implemented
> and fully tested these features for 6410, 6440 and C100.

There's existing users in mainline with the S3C24xx working as slave,
including some for which I have hardware so I'm fairly confident that
that should work.

I've also had reports that the S3C64xx works as slave in mainline, the
code certainly claims that it should work.  At the minute it's limited
to only one of the external clock sources and one of the internal clock
sources, though (I'd need to go and look to see which).

> My idea is to submit only "better enabled" I2S driver with Slave support.

In general it's much better (and certainly standard practice within
Linux) to enhance and refactor existing drivers incrementally rather
than provide entirely new drivers.  The idea is to avoid confusion
between the variants and issues that can come from replacing one set of
problems with another.

Sometimes a flag day is unavoidable but it's best to at least explore
other options first.

> In the long run, I see I2S drivers segregated by the I2S spec version
> they implement....
> S3C2410 has I2S-2.0, S3C6410 has I2S-3.2 and I2S-4.0, S5P6440 has
> I2S-4.0, S5PC100 has
> I2S-3.2 and I2S-5.1 and so on. That is, we have something like
> samsung-i2s_v20.c, samsung-i2s_v32.c,
> samsung-i2s_v40.c, samsung-i2s_v51.c.

It really depends on how much difference there is between the blocks at
what point it becomes worth forking a new driver - in many cases the
newer blocks are close to register compatible with the older ones so
a forked driver would have more in common with the original driver than
the differences.  Where that is the case it makes sense to try to keep
things together but if conditional code begins to dominate some or all
of the driver then that suggests forking the relevant bits.

One example of what may end up making most sense is that we get a driver
per variant but also a core which factors out all the bits that stay the
same between different variants (possibly multiple versions thereof).

> SoC specific register addresses and other peculiarities maybe
> differentiated by defines in coresp. header files.
> Let Samsung come with as many SoCs as it wishes, I2S support will
> simply end up in header files. Also, that we

Build time stuff like this does greatly increase the number of
configurations that need to be compiled in order to achieve build
coverage which is a bit of a problem, not just for testing but also for
things like distro kernels.  There's limitations due to the underlying
arch/arm stuff but we'd want to at least track what that can do and not
introduce any new limits in the audio drivers.

> Whereas, mainline s3c-i2s approach currently concentrates on
> extracting common code in one file(s3c-i2s-v2.c) or so do i think.

Pretty much since for the v2-v4 range the differences are mostly in the
addition of new features and compatibility is fairly strong.  Like I
say, if it gets to be more trouble than it's worth to maintain things
like this that's the time to start splitting out separate drivers.

Samsung S3C6410 mainline merge coordination

[Nelson Castillo]

On Wed, Sep 2, 2009 at 7:15 AM, Harald Welte<laforge@gnumonks.org> wrote:
> Hi Nelson,
>
> On Wed, Sep 02, 2009 at 04:51:56AM -0500, Nelson Castillo wrote:
>> > * port existing s3c_ts driver to use s3c_adc_register()
>> > ** has anyone been doing wokr on this already? ben?
>>
>> (jumping in)
>>
>> I worked on this starting from some work done by other members of this
>> list. This is the ported version of the driver. It depends on the
>> touchscreen filters developed by Andy Green and enhanced by me while
>> working at Openmoko. I've already applied most of Andrew Morton's
>> feedback (a lot) to the TS filters but I haven't submitted them again
>> for upstream review (A filter still needs to be modified and I know
>> how to do it but I haven't finished this change).
>
> Hi, thanks for your feedback. ?I think it is somewhat "dangerous" to create a
> dependency from s3c2410_ts (which schould be renamed to s3c_ts by now) to the
> ts_filter work.
>
> I'd personally prefer to decouple those two, i.e. first submit the s3c_ts based
> on adc.c without ts_filter, and then add the ts_filter core (plus support
> for s3c_ts) later on.
>
> I suppose you don't mind, so we'll go ahead with this and submit s3c_ts this
> way.

How could I mind? :-) This is the right way to go. I guess you could
make the driver send data with noise or restore the basic averaging in
previous versions of the driver.

TS filters have been rather controversial and they would slow down
s3c_ts merging. The filters should be submitted separately.

Samsung S3C6410 mainline merge coordination

[Ben Dooks]

On Wed, Sep 02, 2009 at 12:17:19PM +0900, Harald Welte wrote:
> 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.

Whilst this looks like an improvement in the process, will this stick once
they decide to shuffle the development team(s) and/or the management after
effort has been put in to sort this out.
 
> 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.

I really don't have the time at the moment to go on a fishing trip into
another vendor kernel tree. There are good reasons why we try to avoid
this on public lists:

1) Everyone would end up trying to get you to review their tree which would
   limit the people reviewing the changes. Posting patches to the proper
   list ensures that they are widely reviewed and that the review process
   is public and archive

2) It avoids an automatic assumption that any changes in these trees is
   going to be noticed by the mainatiner.

3) The number of different bases means there is a risk of contaminating
   trees or ending up with many different trees using disc space.

4) It avoids the posiblity of being contaminated by accident.

5) It is contra to the whole Linux development process (see #1)

> 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

I belive that this has been in for a while, or are you talking about
a different fix?
 
> === plat-s3c/gpio.c ===
> * off-by-one error, send fix mainline

I think this has been fixed, although if not, why hasn't this been
submitted already?
 
> === suspend-to-ram ===
> * port to mainline and test, submit mainline

I belive suspend-to-ram works for all the current in-kernel devices,
so shouldn't need any more work. If there are specific problems, please
report them so we can look at sorting them out.
 
> == 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

I belive this patch has already been submitted to the list, but not
sorted out.

> * 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?

I have been keeping Arnaud's drviver up to date with mainline for Simtec,
but as such we've not tried submitting this as there is at least one more
driver out there (see touchscreen filters which has been already posted
to this thread).

> * 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

I thought tslib should take care of ensuring the proper calibration of
the touchscreen, such as inversions and any other problems and thus
baking values in the driver is of no real use?
 
> === video / multimedia ===
> * needs a lot of thought
> * support standard mainlien architecture wherever possible
> ** 2D accelerated framebuffer
> ** DRI/DRM/TTM/KMS
> ** V4L

I am not reallhy sure if there is any current support for using
hardware blocks for decoding video data. I think that having some
form of framework for doing these as well as allowing blocks to be
chained togehter would be useful.

Again this is something that needs to be taken up with the relevant
community (assuming there is one) to come to a good solution.
 
> === 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

I don't see why this is being mentioned here, it isn't really part of
the requirements to get the s3c64xx/s5pc range of devices working.
 
> === SD/MMC ===
> * mainline uses existing SDHCI driver, not HSMMC

Yes, this block is basically an SDHCI system with some changes from
Samsung for the clocks. It was certainly typical of the previous
methodology to write a completely new driver where there was an
existing in kernel driver that could be modified to cover this.

As such, time was spent by myself and several others with Pierre
decoupling the SDHCI driver and adding the appropriate callbacks
to allow functions such as clock choice to be managed by the
appropriate bus glue.

> * fix mainline s3c-sdhci clock related bugs, submit mainline

It would be nice to have timely and accurate bug reports about
these issues as soon as they are detected. Finding out about
these later in a long list does not fill me with wonder and joy
about the whole process.

As far as I have been aware, I have not seen any issues with the
clocks on the s3c6410 or s3c6400 boards. I don't have anything
after this to test with.

> * add ADMA support and submit mainline

I am sure I have asked several times about the seemingly random
ADMA errors that appear on the S3C6410 (I belive the S3C6400 is
SDMA only) and what (if anything) can be done about them, which
is why the driver currently has the ADMA support disabled (and
a number of extra SDHCI debugging facilities to show state when
ADMA fails).

> * test / make sure it's feature complete: 1...n patches

I would hope this would go without saying.

> * what about 8bit MMC? add as separate patch

I belive that there is support in the MMC/SD core for this, but not
yet in the SDHCI driver. I have yet to come across any 8bit SD cards
out in the wild, so have not looked closer at this.

> * what about MMC highspeed? add as separate patch

I belive the SDHCI driver and the MMC/SD core should support high-speed
cards and do the neccessary setup for the SDHCI controller. If there is
anything else needed, then an update may be needed to the glue file.

> * fast boot for movinand? add as separate patch

As a footnote to this section, I have asked about the correct setup
data for the extended controll registers which control the clock
feedbacks in the system. Having tried several of the published
Samsung kernels (and I have no love for fishing around inside these
to try and find the correct settings from an #ifdef nightmare in
some cases) I have yet to find settings that allow for error free
operation on the SMDK6410...
 
> === 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?

It depends, this would better be discussed in a seperate mail about what
features in the newer devices could do with seperate support. Really this
and the comments below belong on the MTD list where the issues can be
thorougly discussed with all the developers involved with the NAND
subsytem.

> * 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?

I belive the newer devices have a battery flat indicator, an improved tick
interrupt control, but basically this is the same block that has been in all
the Samsing based devices.
 
> === 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

This needs to be taken up with the relevant maintainers. I do see there
is a lack of support for slave side SPI, but there is currently nobody
using it.
 
> === 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

How about the one that is already in mainline? I spent a lot of time working
on that driver and ensuring it was fit to submit. I'll rehash the issues
that where had when doing this;

1) No driver of any of the Samsung or my drivers would work on my SMDK6410,
   and I was told there where no more boards of a newer revision available
   to try and work out why this happened. It seems to be some form of
   hardware problem, but whether this the board or the actual sillicon on
   it was never determined.

2) All of the Samsung drivers so far have been badly documented and seem
   to have problems of their own. The first variants ignored alignment
   issues, made assumptions about when you can transfer data.

As a note, this is another case of asking questions about the hardware
and not getting a lot of useful information back. Posting a new driver
to the list as 'feedback' is hardly my idea of documentation as well as
ignoring the usual ettiquete of trying to provide patches for an extant
driver.

It seems quite clear from reading the documentation that the PIO mode
of operation simply does not work and that I need to either sort out
the upper layer's use of unaligned buffers or add bounce-buffers to
the s3c-hsotg.c driver.
 
> === 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

Hmm.
 
> === 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

The ASoC system (and please, do not continue to try to add old style
ALSA driver) then it is simply core support for the master blocks and
then the board mapping files that link the CODEC and the master together.

I belive Mark Brown has already done a lot of work towards supporting the
SMDK6410's audio routing.


As a final note, myself and Simtec (my employer, if anyone didn't already
realise) have been supporting the Samsung SoC line for a long time at ours
or a 3rd party's expense. It is still sad to see that it requires third
party intervention (you) to try and get them to do things properly.

-- 
Ben

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

Samsung S3C6410 mainline merge coordination

[Mark Brown]

On Wed, Sep 02, 2009 at 12:17:19PM +0900, Harald Welte wrote:

> === 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

Didn't notice this before...  it might be worth bringing it forward
since the PMICs tend to cross a wide range of kernel subsystems.  This
means that it's often easiest to merge over several release cycles which
can lead to long delays.  Getting at least the MFD core part of the
driver merged sooner should help with that a lot since by the time it
becomes a priority the shared part may already be in mainline.

Samsung S3C6410 mainline merge coordination

[Ben Dooks]

On Wed, Sep 02, 2009 at 10:44:35PM +0900, jassi brar wrote:
> On Wed, Sep 2, 2009 at 9:11 PM, Harald Welte<laforge@gnumonks.org> wrote:
> > On Wed, Sep 02, 2009 at 11:05:01AM +0100, Mark Brown wrote:
> >> > === Sound ===
> >> > * needs further investigation, there are many different drivers/versions/options
> >>
> >> Merge any changes in with the mainline drivers - there's relatively
> >> little difference from the s3c24xx IPs. ?There's a reasonable chance
> >> I'll get round to this myself for the 64xx series since I have one which
> >> I'm using for some of my development.
> >
> > Apparently there are also features like operating the SoC codec in slave mode
> > as well as different clock configurations wich mainline is missing.
> 
> Yes, none of mainline SMDK supports SoC-Slave mode or sourcing I2S IP with
> various possible clocks(PCLK, EPLL, CDCLK) etc yet. Samsung tree has
> implemented
> and fully tested these features for 6410, 6440 and C100.
> 
> My idea is to submit only "better enabled" I2S driver with Slave support.
> Clock sourcing related patch maybe later added when the EPLL etc clock
> support has been submitted.

Nope, the extant driver can do slave mode, all you need to do is write
the correct codec<>dai driver and it will do it. 

-- 
Ben

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

Samsung S3C6410 mainline merge coordination

[Ben Dooks]

On Wed, Sep 02, 2009 at 09:01:59PM +0900, Harald Welte wrote:
> On Wed, Sep 02, 2009 at 05:43:14PM +0800, tommy.hong wrote:
> 
> > does it support X kdrive 2D accelerate ?
> 
> X / kdrive is not part of the linux kernel.  Therefore, it is unrelated
> to the Linux kernel code that we are working on.

Unfortunately it seems that pretty much no-one uses the fb driver
acceleration, I'm not even sure if it has even been exported outside
the kernel, so isn't really a lot of use.

-- 
Ben

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

Samsung S3C6410 mainline merge coordination

[Ben Dooks]

On Wed, Sep 02, 2009 at 08:03:30AM -0400, David F. Carlson wrote:
> 
> 
> 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.

I'm not sure what you are complaining about here (not helped by your mail
client's inability to wrap to something readable on a terminal - i.e. 76
characters per line).

Most GPIO setup is done in the bootloader, but there is more that sometimes
needs to be done in either the board file or occasionally the driver. The
drivers that need help with this, get passed a callback function with the
platform data to do the necessary setup (see the sdhci callbacks, i2c, etc).

I belive we've got this pretty much under control.

> 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 belive Peter Korsgaard's patch has already been merged to move the s3c24xx
pwm code into the s3c.
 
> 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.

Not desperately interested at the moment, thought needs to be put into
these drivers and they can generally live on their own.

> 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.  :-)

The best I can think of at the moment is that the kernel implements a way
to share the harware and that userspace libraries sort out the actuall
acceleration. There has been at least two attempts I know of to try and
export fbdev calls outside of the kernel and this seems to have fallen
rather flat.

-- 
Ben

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

Samsung S3C6410 mainline merge coordination

[Ben Dooks]

On Wed, Sep 02, 2009 at 09:11:58PM +0900, Harald Welte wrote:
> Hi Mark,
> 
> On Wed, Sep 02, 2009 at 11:05:01AM +0100, Mark Brown wrote:
>  
> > > === Sound ===
> > > * needs further investigation, there are many different drivers/versions/options
> > 
> > Merge any changes in with the mainline drivers - there's relatively
> > little difference from the s3c24xx IPs.  There's a reasonable chance
> > I'll get round to this myself for the 64xx series since I have one which
> > I'm using for some of my development.
> 
> please note there are something like four different versions of the audio IP
> core in Samsung SoCs.  I myself am not familiar with the detailed technical
> differences.  So in any case we'll try to submit the current code in a way
> that will not create conflicts or issues with code that is pending further
> down the road for s5pc100. or s5pc110.

There's pretty good support for the style that was first in the s3c2412,
which I belive was the last of the two-channel I2S blocks.
 
> Apparently there are also features like operating the SoC codec in slave mode
> as well as different clock configurations wich mainline is missing.

I've run an WM8530 in slave mode on an S3C6410, so it was working last
time I tried it. It was one of the test cases to check the code out before
it was submitted.

What we don't yet have in the mainline is any of the 'V40' which are for
5.1 style I2S links (multiple tx paths).

-- 
Ben

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

Samsung S3C6410 mainline merge coordination

[David F. Carlson]

Sorry about my long line formatting...

According to Ben Dooks:
> 
> > === video / multimedia ===
> > * needs a lot of thought
> > * support standard mainlien architecture wherever possible
> > ** 2D accelerated framebuffer
> > ** DRI/DRM/TTM/KMS
> > ** V4L
> 
> I am not really sure if there is any current support for using
> hardware blocks for decoding video data. I think that having some
> form of framework for doing these as well as allowing blocks to be
> chained togehter would be useful.
> 
> Again this is something that needs to be taken up with the relevant
> community (assuming there is one) to come to a good solution.
>  

I have source to a mplayer which uses the MFC/PP as the video codec for the 
four video encodings it supports.  A hd video with MFC decode utilizes ~30% of 
the 6410 and without the HW assist utilizes all the CPU and still drops 
frames.  This is all within Xwin using the fbdev.

This MFC/PP driver pair is useful to users now.  I am sorry they are not 
good enough for the next-s3c.

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 mainline merge coordination

[Harald Welte]

On Wed, Sep 02, 2009 at 08:10:26PM +0100, Ben Dooks wrote:
> On Wed, Sep 02, 2009 at 09:01:59PM +0900, Harald Welte wrote:
> > On Wed, Sep 02, 2009 at 05:43:14PM +0800, tommy.hong wrote:
> > 
> > > does it support X kdrive 2D accelerate ?
> > 
> > X / kdrive is not part of the linux kernel.  Therefore, it is unrelated
> > to the Linux kernel code that we are working on.
> 
> Unfortunately it seems that pretty much no-one uses the fb driver
> acceleration, I'm not even sure if it has even been exported outside
> the kernel, so isn't really a lot of use.

having cursor acceleration and things like bitblit for srolling is a real
pleasure if you ever happen to work for more than 5 minutes on the framebuffer
console, especially on a system that already has a quite high load at that time.

It sort-of is a standard feature, and at least in the x86/PCI/AGP world, I
am not awaer that any framebuffer driver would not support it.  That's why I
had it on my todo list.

-- 
- 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

[Harald Welte]

Hi Peter,

On Wed, Sep 02, 2009 at 02:49:00PM +0200, Peter Korsgaard wrote:
 
>  Harald> === NAND ===
>  Harald> * mainline currently uses same driver for s3c24xx and s3c64xx
>  Harald> ** samsung uses a new driver for 2450, 6400, 6410 (and later)
>  Harald> * does it make sense to extend the mainline driver with new SoC support
>  Harald>   or should we rather split the mainline driver?
> 
> The nand controllers in the different variants are afaik very similar,
> that's why I added 64xx support to s3c2410.c. What would a split gain
> us?

That's the question the respective developers at Samsung should respond to (see
Cc) Why do you think a split of the nand driver is required? Please comment.

-- 
- 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

[Harald Welte]

Hi Ben,

thanks for your response.

On Wed, Sep 02, 2009 at 05:12:53PM +0100, Ben Dooks wrote:

> > as indicated before, Samsungs SoC Linux developers are currently working
> > on getting more of their work ready for (and submitted to) mainline.
> 
> Whilst this looks like an improvement in the process, will this stick once
> they decide to shuffle the development team(s) and/or the management after
> effort has been put in to sort this out.

Yes, this is definitely the plan!  In fact, one request that I repeatedly get
is "If we submit a driver, can we put an alias/group e-mail address in as the
maintainer for that driver, since then we add/remove developers from/to that
group".  From this example you can see there is difference.

Of course the higher-end SoC's are not only targetting mobile phones or
navigation devices, but are also aiming at mid's or even netbooks - just like
all the ARM SoC vendors are currently doing.  Going for the netbook market
means you need to support not only one distribution but many distros.  Doing
that almost inevitably means that you have to take your code mainline.

Also, there is a strong customer interest in having Samsungs code mainline. Be
assured that those (long-time, over many products) customer is going to pay
close attention that this is not a one-shot effort but continuous.

Right now, the Samsung Linux team has agreed that all of their new development
(mostly for the C110, as that is highest priority here now) will follow mainline
and pull mainline at least every -rcX version and will not stop at any particular
kernel release.

Sure, this does not mean that the code itself will be 100% what the linux
community wants, but it is definitely a change compared to working on old/stable
kernel versions first and then [if at all] trying to bring this forward.

> > 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.
> 
> I really don't have the time at the moment to go on a fishing trip into
> another vendor kernel tree. There are good reasons why we try to avoid
> this on public lists:

Well if you don't have the time, then don't do it.  I still think it is a 
big improvement that anyone who is interested can now actually on a day-by-day
basis follow what Samsung is doing internally.  This is not much different,
let's say, from any other tree on git.kernel.org.

Sure, this is just the first step, and none of the code in that tree is
supposed to be magically picked up by the kernel guys or supposed to be ready
for a merge.

Samsung will make per-feature patch submissions.  It just takes time.  So in
case anyone is interested having an early look can do it.  Or maybe somebody
actually wants to help.  Community, right?

> 2) It avoids an automatic assumption that any changes in these trees is
>    going to be noticed by the mainatiner.

That is not an assumption I or Samsung have.

> 3) The number of different bases means there is a risk of contaminating
>    trees or ending up with many different trees using disc space.

We have not added a tree, we simply released more existing (but not public)
trees to the public.  I'm sure you can see that is an improvement.

> 4) It avoids the posiblity of being contaminated by accident.

sorry?

> 5) It is contra to the whole Linux development process (see #1)

I think, once again, you are exaggerating.  Would you rather want those
branches that were samsung internal again be closed off?  Do you think that
is better?

> > === plat-s3c/clock.c ===
> > * submit clk->owner bugfix mainline
> 
> I belive that this has been in for a while, or are you talking about
> a different fix?

there are three or four fixes that we're preparing right now.  Preparing since
I need to walk an entire team through every step of the process of creating
per-feature patches, using git, and last but not least we need to send proper
mail to the mailing list.  This is why something simple like that can take
a number of days.  Still, today should be when you receive those.

> > === plat-s3c/gpio.c ===
> > * off-by-one error, send fix mainline
> 
> I think this has been fixed, although if not, why hasn't this been
> submitted already?

Because Samsung was not working on/with mainline before.  Now they have decided
and are learning, but the learning process is ongoing and not finished.

> > === suspend-to-ram ===
> > * port to mainline and test, submit mainline
> 
> I belive suspend-to-ram works for all the current in-kernel devices,
> so shouldn't need any more work. If there are specific problems, please
> report them so we can look at sorting them out.

Ok, it's just a large portion of code that samsung has in its tree and not
in mainline, so I made the assumption it was lacking.  I'll ask them to test
mainline and report back.

> > === adc / touchscreen ===
> > * move plat-s3c24xx/adc.c to plat-s3c/adc.c
> 
> I belive this patch has already been submitted to the list, but not
> sorted out.

Is there any particular reason?  I have looked at the register level
description of 2410,2440,2443 and 6410... they're 99.9% compatible, so it
should definitely move out of there.  I also think the s5pc1xx stuff does
again have the same IP core for ADC/TS.

> > * 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?
> 
> I have been keeping Arnaud's drviver up to date with mainline for Simtec,
> but as such we've not tried submitting this as there is at least one more
> driver out there (see touchscreen filters which has been already posted
> to this thread).

Yes, and as Nelson has pointed out, the ts_filters are more controversial
and should go in separate.  Can you please get your touchscreen driver
scheduled for merge?  If you have known issues, I can help with them, if
I have the code and know about the issues.

> > * 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
> 
> I thought tslib should take care of ensuring the proper calibration of
> the touchscreen, such as inversions and any other problems and thus
> baking values in the driver is of no real use?

I was not sure if a complete inversion is actually covered by tslib.  Probably
best to test it. 

> > === video / multimedia ===
> > * needs a lot of thought
> > * support standard mainlien architecture wherever possible
> > ** 2D accelerated framebuffer
> > ** DRI/DRM/TTM/KMS
> > ** V4L
> 
> I am not reallhy sure if there is any current support for using
> hardware blocks for decoding video data. I think that having some
> form of framework for doing these as well as allowing blocks to be
> chained togehter would be useful.
> 
> Again this is something that needs to be taken up with the relevant
> community (assuming there is one) to come to a good solution.

This is relatively difficult, I've been facing the same issues (lack of
infrastructure) in my work for other companies.  On the other hand,
those companies typically don't have the Linux experience to be able
to come up with a good generic architecture for it.

In any case, I only wanted to state "we know there is a problem, and we
are thinking about it, but it is lower priority right now"

> > === s5m8751 PMIC ===
> 
> I don't see why this is being mentioned here, it isn't really part of
> the requirements to get the s3c64xx/s5pc range of devices working.

you can assume that a number of devices will probably buy SoC+PMIC from
the same company, that's why I think it would be beneficial for even for
the s3c/s5c code to have this in mainline.

> Yes, this block is basically an SDHCI system with some changes from
> Samsung for the clocks. It was certainly typical of the previous
> methodology to write a completely new driver where there was an
> existing in kernel driver that could be modified to cover this.
 
Yes, I realize that history.

> > * fix mainline s3c-sdhci clock related bugs, submit mainline
> 
> It would be nice to have timely and accurate bug reports about
> these issues as soon as they are detected. Finding out about
> these later in a long list does not fill me with wonder and joy
> about the whole process.

yes, that will automatically be the case when the Samsung guys work
with something closer to mainline.

> As far as I have been aware, I have not seen any issues with the
> clocks on the s3c6410 or s3c6400 boards. I don't have anything
> after this to test with.

those are ADMA related.

> > * add ADMA support and submit mainline
> 
> I am sure I have asked several times about the seemingly random
> ADMA errors that appear on the S3C6410 (I belive the S3C6400 is
> SDMA only) and what (if anything) can be done about them, which
> is why the driver currently has the ADMA support disabled (and
> a number of extra SDHCI debugging facilities to show state when
> ADMA fails).

this has only been resolved two days agon and the patches are likely
submitted later today.

> > * test / make sure it's feature complete: 1...n patches
> 
> I would hope this would go without saying.

For _you_ this goes without saying.  For _me_ it does.  But have you
ever worked inside / with a company that has never done anything like
this before?  Then you have to make those kind of things explicit.

It is a learning curve, and you cannot expect them to complete that curve in a
second or a day.  This is where people like us can help.

> > * what about 8bit MMC? add as separate patch
> 
> I belive that there is support in the MMC/SD core for this, but not
> yet in the SDHCI driver. I have yet to come across any 8bit SD cards
> out in the wild, so have not looked closer at this.

I think 8bit is really specifically about MMC, not SD.

> > * what about MMC highspeed? add as separate patch
> 
> I belive the SDHCI driver and the MMC/SD core should support high-speed
> cards and do the neccessary setup for the SDHCI controller. If there is
> anything else needed, then an update may be needed to the glue file.

SD Highspeed is independent of MMC highspeed.  The current driver only
supports SD highspeed.

> > * fast boot for movinand? add as separate patch
> 
> As a footnote to this section, I have asked about the correct setup
> data for the extended controll registers which control the clock
> feedbacks in the system. Having tried several of the published
> Samsung kernels (and I have no love for fishing around inside these
> to try and find the correct settings from an #ifdef nightmare in
> some cases) I have yet to find settings that allow for error free
> operation on the SMDK6410...

Can you be more specific about which registers those are?  I'm sure Thomas
would be able to help you, as he has been working on the sdhci-s3c related
fixes over the last few days.

> > === 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?
> 
> It depends, this would better be discussed in a seperate mail about what
> features in the newer devices could do with seperate support. Really this
> and the comments below belong on the MTD list where the issues can be
> thorougly discussed with all the developers involved with the NAND
> subsytem.

of course.  This will likely follow, and i've already posted one initial mail
to linux-mtd yesterday.  Nonetheless I thought it was of interest to you
and other members of linux-arm-kernel to see what is happening and what is
on Samsung's agenda now.

> > * needs more investigation, some code is in samsung tree that is not mainline
> > * what does it do, why?  something alarm related?
> 
> I belive the newer devices have a battery flat indicator, an improved tick
> interrupt control, but basically this is the same block that has been in all
> the Samsing based devices.

thanks, as indicated, we'll investigate further.
> 
> > === 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
> 
> This needs to be taken up with the relevant maintainers. I do see there
> is a lack of support for slave side SPI, but there is currently nobody
> using it.

Right now we (specifically jassi) is planning to rip the slave support out
of Samsungs current code and submit that.  slave support is likely a
more complex issue for later and that should not block the spi master support
from going in.

> > === 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
> 
> How about the one that is already in mainline? I spent a lot of time working
> on that driver and ensuring it was fit to submit. 

I did not realize there was one, my apologies.

> 2) All of the Samsung drivers so far have been badly documented 

Sorry, how well are drivers typically documented in the kernel?  I think
this is not something specific to Samsung, if you're fair about it.

> and seem to have problems of their own. The first variants ignored alignment
> issues, made assumptions about when you can transfer data.

which is a result from lack of understanding the Linux USB api's and their
requirements.  Not everyone is born with the years of experience that you
and others in this field share.

Yes, this is why we have a community development process, and now that Samsung
starts to participate they will also be able to benefit from the review cycles
that will enable more experienced developers to point those things out to them,
_plus_ Samsungs internal developers actually will have permission/time to
address those comments in the code and resubmit - since otherwise the code
does not get mainline, which is a specific customer demand :)

> As a note, this is another case of asking questions about the hardware
> and not getting a lot of useful information back. 

Yes, in a typical semiconductor veondor (any of them) you will never have
actual developers interact with customer.  You always have at least some
management, customer support or the FAE in between.  This is why it is
seriously discouraged for such a developer to interact with somebody like you.

Once again, nothing specific to Samsung at all.  It's the culture of that
industry, and they're as much into it as we are into the Linux culture.  You
might have worked in your culture for a decade or more, and they have in
theirs.

This is different now, but even with the permsision to interact with the
mainline linux developers, it will probably still take some time for every
developer to actually make that kind of change.

> Posting a new driver to the list as 'feedback' is hardly my idea of
> documentation as well as ignoring the usual ettiquete of trying to provide
> patches for an extant driver.

As indicated, the 'new driver' was developed by a completlely independend
part of Samsung, and the System LSI guys didn't even know there was a
different driver until I told them that somebody else from Samsung had
submitted one.   Yes, this is funny - but also very common in corporations
of that size.  

I still remember a friend of mine being hired by Siemens to recommend a PPC
bootloader to them, where he then recommnded to use one that was released by a
different Siemens department as open source.

> It seems quite clear from reading the documentation that the PIO mode
> of operation simply does not work and that I need to either sort out
> the upper layer's use of unaligned buffers or add bounce-buffers to
> the s3c-hsotg.c driver.

I think the driver submitted by Marek + Kyungmin to this list a couple of
months ago claimed to do exactly the opposite:  Support PIO but no DMA.

I'll put this down as something to investigate at Samsung internally.

> > === 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
> 
> Hmm.

Do you see any other option or what is this supposed to mean?

> As a final note, myself and Simtec (my employer, if anyone didn't already
> realise) have been supporting the Samsung SoC line for a long time at ours
> or a 3rd party's expense. 

Yes, I'm sorry for that, but as you know this is a reality as long as the
respective semiconductor vendors do not understand the Linux development
model.  Samsung System LSI is by far not the only silicon company who
is still in that situation or was until two weeks ago.

> It is still sad to see that it requires third party intervention (you) to try
> and get them to do things properly.

I do not think it is sad at all.  Which company (or more specifically
semiconductor manufacturer) have you ever seen to magically have all this
knowledge and skill about open source development model, the linux kernel
community, it's culture and rules, ...?

To the best of my knowledge, even for companies like Intel and AMD it was
a process over many years that involved hiring people who have this kind
of background and who can help them first understanding and then learning
this process.  Alternative is to partner with a company who does, see e.g.
the x86_64 work done by SuSE(Andi Kleen) for AMD.

So rather to the opposite, I think it affords my (and hopefully others')
respect that they have finally made a [r&d management] choice to change.   Yes,
this would have been better and easier four years ago.  But we can't change the
past, can we?

Let's rather focus on what we can do from now on, in this new situation.

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 mainline merge coordination

[Joonyoung Shim]

On 9/2/2009 10:44 PM, jassi brar wrote:
> On Wed, Sep 2, 2009 at 9:11 PM, Harald Welte<laforge@gnumonks.org> wrote:
>> On Wed, Sep 02, 2009 at 11:05:01AM +0100, Mark Brown wrote:
>>>> === Sound ===
>>>> * needs further investigation, there are many different drivers/versions/options
>>> Merge any changes in with the mainline drivers - there's relatively
>>> little difference from the s3c24xx IPs. ?here's a reasonable chance
>>> I'll get round to this myself for the 64xx series since I have one which
>>> I'm using for some of my development.
>> Apparently there are also features like operating the SoC codec in slave mode
>> as well as different clock configurations wich mainline is missing.
> 
> Yes, none of mainline SMDK supports SoC-Slave mode or sourcing I2S IP with
> various possible clocks(PCLK, EPLL, CDCLK) etc yet. Samsung tree has
> implemented
> and fully tested these features for 6410, 6440 and C100.
> 
> My idea is to submit only "better enabled" I2S driver with Slave support.
> Clock sourcing related patch maybe later added when the EPLL etc clock
> support has been submitted.
> 
> An issue though.
> In the long run, I see I2S drivers segregated by the I2S spec version
> they implement....
> S3C2410 has I2S-2.0, S3C6410 has I2S-3.2 and I2S-4.0, S5P6440 has
> I2S-4.0, S5PC100 has
> I2S-3.2 and I2S-5.1 and so on. That is, we have something like
> samsung-i2s_v20.c, samsung-i2s_v32.c,
> samsung-i2s_v40.c, samsung-i2s_v51.c.

I wonder what mean the numbers(2.0, 3.2, 4.0, 5.1). Does it mean I2S 
version simply? If it is version, what is the differences of each I2S
version?

> SoC specific register addresses and other peculiarities maybe
> differentiated by defines in coresp. header files.
> Let Samsung come with as many SoCs as it wishes, I2S support will
> simply end up in header files. Also, that we
> can do away with using s3c24xx stuff in 64xx and S5Pxxxx code.
> For now, I haven't implemented h/w mixing and 5.1 channel support so
> v32 and v40 are just the same.
> Whereas, mainline s3c-i2s approach currently concentrates on
> extracting common code in one file(s3c-i2s-v2.c) or so do i think.
> 
> I sincerely seek to discuss this issue.
> 
> _______________________________________________
> linux-arm-kernel mailing list
> linux-arm-kernel at lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
> 

Samsung S3C6410 mainline merge coordination

[jassi brar]

On Wed, Sep 2, 2009 at 11:47 PM, Mark Brown<broonie@sirena.org.uk> wrote:
> On Wed, Sep 02, 2009 at 10:44:35PM +0900, jassi brar wrote:
>
>> Yes, none of mainline SMDK supports SoC-Slave mode or sourcing I2S IP with
>> various possible clocks(PCLK, EPLL, CDCLK) etc yet. Samsung tree has
>> implemented
>> and fully tested these features for 6410, 6440 and C100.
>
> There's existing users in mainline with the S3C24xx working as slave,
> including some for which I have hardware so I'm fairly confident that
> that should work.
>
> I've also had reports that the S3C64xx works as slave in mainline, the
> code certainly claims that it should work.

Ofcourse, i can see Neo1973 implement SoC-Slave mode. There is no
reason why some users won't have 6410 running in Slave mode too at
their end.
I recently released one small but essential patch to you to make
wm8580 generate proper clocks -- essential when wm8580 is I2S master
-- that made me doubt if Slave support is even implemented/tested on
SMDKs in mainline.

My plan was to submit something like smdk_wm8580.c (smdks have wm8580
as the main I2S codec) which can be make menuconfig'ed for
SoC-Master/Slave and source clock support.
Plus, some logical re-arrangement of i2s.c code.
How about that?

>> My idea is to submit only "better enabled" I2S driver with Slave support.
> In general it's much better (and certainly standard practice within
> Linux) to enhance and refactor existing drivers incrementally rather
> than provide entirely new drivers.
I didn't exactly mean .c files.

>?The idea is to avoid confusion
> between the variants and issues that can come from replacing one
>set of problems with another.
got it.


>> In the long run, I see I2S drivers segregated by the I2S spec version
>> they implement....
>> S3C2410 has I2S-2.0, S3C6410 has I2S-3.2 and I2S-4.0, S5P6440 has
>> I2S-4.0, S5PC100 has
>> I2S-3.2 and I2S-5.1 and so on. That is, we have something like
>> samsung-i2s_v20.c, samsung-i2s_v32.c,
>> samsung-i2s_v40.c, samsung-i2s_v51.c.
>
> It really depends on how much difference there is between the blocks at
> what point it becomes worth forking a new driver - in many cases the
> newer blocks are close to register compatible with the older ones so
> a forked driver would have more in common with the original driver than
> the differences. ?Where that is the case it makes sense to try to keep
> things together but if conditional code begins to dominate some or
> all of the driver then that suggests forking the relevant bits.
Ofcourse, we shudn't keep 95% identical _v20, _v32, _v40 and _v50.c
For the time being, when our driver doesn't make use of any spec
differentiator, all SoCs can be served with a single file.
But as we implement more and more support to 40 (5.1channel)and 50(5.1
channel + channel mixing) versions, we will need segregation.
Ofcourse, intersection cud always be separated out, as does PXA.
But as i  said - In the long run.
As a starter we cud do by converting Samsung's I2S code 24xx(and even
s3c) agnostic?

Samsung S3C6410 mainline merge coordination

[Harald Welte]

Hi Ben and others,

On Wed, Sep 02, 2009 at 08:16:26PM +0100, Ben Dooks wrote:
> > 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.
> 
> I'm not sure what you are complaining about here 

I would also be interested in learning more details about this.  Right now
I don't understand what David is referring to, sorry.

> Most GPIO setup is done in the bootloader, but there is more that sometimes
> needs to be done in either the board file or occasionally the driver. The
> drivers that need help with this, get passed a callback function with the
> platform data to do the necessary setup (see the sdhci callbacks, i2c, etc).

yes.  Though honestly speaking, I have my doubts if this is the best solution.
On the OMAP keypad driver e.g. they simply pass an array of GPIO numbers into
the driver, where the driver then simply makes gpiolib calls to reconfigure
the GPIO's.  No special SoC specific API, no custom callbacks that every
board will have to provide or at least assign.

What do you think about this approach vs. the current one?  Would you prefer
that (and would like patches for it), or rather keep the current code?

> > 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 belive Peter Korsgaard's patch has already been merged to move the s3c24xx
> pwm code into the s3c.

It's not yet in mainline, but if you believe it has been merged, then it should
be a matter of time, right?

Which brings us to the next question: where and how should s3c/s5p related
code be (re)based on?  Right now Samsung is working with 2.6.31-rc8 mainline
(and will keep syncing) both for their submit-missing-6410 work, as well as
for their current s5pc110 related development.

I've seen that s3c-next already contains s5pc100 code.  When is that supposed
to appear in mainline?  I would really want to avoid too many different trees
around.  

I think it is possible to rebase/merge the s5pc1xx code that samsung uses for
their development once now.  But I think the amount of extra work required to
continuously sync with a separately developed s5pc1xx tree/branch is too
much of a burden that they can take at this point.

Can we somehow work on a model where Samsung accepts contributions into
their tree?  As I understand s5pc1xx is still very fast moving ahead all the
time and even Samsung does not consider their code as being finished by any
means.

I think the dualism of Samsung's code and Ben Dooks + mainline code has been a
big resource waste in the past.  I'm looking for ways how this can be avoided
for future code, where everyone works on one codebase, even before something is
finished and considered ready for mainline.

In any case, a very clear statement about which tree is supposed to be the
master for what would already help.  the bjdooks tree has many branches, some
of them are months old so I am somewhat puzzled on what their status might be.

> > 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.
> 
> Not desperately interested at the moment, thought needs to be put into
> these drivers and they can generally live on their own.

I agree.

> > 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.  :-)
> 
> The best I can think of at the moment is that the kernel implements a way
> to share the harware and that userspace libraries sort out the actuall
> acceleration. There has been at least two attempts I know of to try and
> export fbdev calls outside of the kernel and this seems to have fallen
> rather flat.

I agree that the current Samsung vide/media driver architecture is far from
being in line with those few standards that exist in the Linux graphics world.

Also, the hardware (which only works on phyiscal memory, i.e. physically
contiguous blocks) makes it hard to fit into Xorg that obviously deals with
virtual memory.

Furthermore, the Linux/FOSS graphics world is lacking any shared/common
infrastructure for things such as hardware video codecs.  In any case, I
personally think a lot of this should live outside the kernel, except
the framebuffer and v4l support.

So yes, this needs a lot of thought and work, and I would rather want to see
the less controversial 6410 bugfixes and drivers as well as the core support
for the s5pc100 go in soon rather than spending months and months working on
fancy jpeg accelerators...

-- 
- 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

[Bill Gatliff]

Harald Welte wrote:
> Of course the higher-end SoC's are not only targetting mobile phones or
> navigation devices, but are also aiming at mid's or even netbooks - just like
> all the ARM SoC vendors are currently doing.  Going for the netbook market
> means you need to support not only one distribution but many distros.  Doing
> that almost inevitably means that you have to take your code mainline.
>   

Keep in mind that solid mainline kernel support gives you a huge 
advantage in the catalog chip market, too.  Atmel leads the way there, 
but TI has apparently "seen the light" in the last year or so, observing 
what they are doing with their OMAP35xx chips in particular.  I think 
it's wise for Samsung to push hard in this direction as well.  I'm glad 
to see this announcement.


b.g.

-- 
Bill Gatliff
bgat at billgatliff.com

Samsung S3C6410 mainline merge coordination

[Nelson Castillo]

On Wed, Sep 2, 2009 at 6:18 PM, Harald Welte<laforge@gnumonks.org> wrote:
(cut)
>> > === adc / touchscreen ===
>> > * move plat-s3c24xx/adc.c to plat-s3c/adc.c
>>
>> I belive this patch has already been submitted to the list, but not
>> sorted out.
>
> Is there any particular reason? ?I have looked at the register level
> description of 2410,2440,2443 and 6410... they're 99.9% compatible, so it
> should definitely move out of there. ?I also think the s5pc1xx stuff does
> again have the same IP core for ADC/TS.
>
>> > * 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?
>>
>> I have been keeping Arnaud's drviver up to date with mainline for Simtec,
>> but as such we've not tried submitting this as there is at least one more
>> driver out there (see touchscreen filters which has been already posted
>> to this thread).
>
> Yes, and as Nelson has pointed out, the ts_filters are more controversial
> and should go in separate. ?Can you please get your touchscreen driver
> scheduled for merge? ?If you have known issues, I can help with them, if
> I have the code and know about the issues.

Filtering is not actually merged in the same TS driver. We could
replace it with some basic averaging with little effort. We improved
interrupt handling and avoided jittering with pen-down/pen-up events.
I know it works but I'm sure some cleanup might be needed (perhaps
beyond my knowledge) to make it suitable for upstream.

If it helps I can send a simplified version of the driver that does
not depend on filtering.
Since we don't know Ben's version of the driver then I guess it's Ben's call.

Regards.

Samsung S3C6410 mainline merge coordination

[Harald Welte]

Hi Tommy,

On Thu, Sep 03, 2009 at 10:19:42AM +0800, tommy.hong wrote:
 
> Some guy finish s3c6410 X driver which use g2d driver!
> http://wiki.maemo.org/Mer/Hardware/SmartQ5/XAA

thanks, that's indeed very interesting.  In fact, the entire SmartQ devices
sound interesting, I have to see if I can get hold of one either in Korea
or Germany.

by the way, as a friendly note: Please do not full-quote when responding to
e-mails. 

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 mainline merge coordination

[Harald Welte]

On Wed, Sep 02, 2009 at 10:38:30PM -0500, Nelson Castillo wrote:

> If it helps I can send a simplified version of the driver that does
> not depend on filtering.

I would like to see that one and see it go forward.

> Since we don't know Ben's version of the driver then I guess it's Ben's call.

Yes, indeed. 

Ben: Is your code visible in some public git tree somwhere?  This
would help others to have a look at it.

-- 
- 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

[Daniel Silverstone]

On Thu, Sep 03, 2009 at 07:26:41AM +0900, Harald Welte wrote:
> > > > does it support X kdrive 2D accelerate ?
> > > X / kdrive is not part of the linux kernel.  Therefore, it is unrelated
> > > to the Linux kernel code that we are working on.
> > Unfortunately it seems that pretty much no-one uses the fb driver
> > acceleration, I'm not even sure if it has even been exported outside
> > the kernel, so isn't really a lot of use.
> having cursor acceleration and things like bitblit for srolling is a real
> pleasure if you ever happen to work for more than 5 minutes on the framebuffer
> console, especially on a system that already has a quite high load at that time.
> It sort-of is a standard feature, and at least in the x86/PCI/AGP world, I
> am not awaer that any framebuffer driver would not support it.  That's why I
> had it on my todo list.

Simtec produced a set of patches to expose the Linux Kernel FB acceleration
primitives to userland, only to be told that it was unlikely they'd be accepted
due to them having never been exposed before.  (Yes, it was a case of 'We have
always done it this way, why would we want to change?')

Basically the expectation appears to be that userland wishing to use
acceleration features of a framebuffer device (such as the multiple planes,
hardware cursor support, hardware bitblt etc which an SoC or graphics chip
might implement) is expected to do it for itself by knowing which bit of
physical memory to mmap() and fiddle, underneath and behind-the-back-of the
kernel.

If you're interested in the patches we produced then I can try to dig them up
for you.

Regards,

Daniel.

-- 
Daniel Silverstone                              http://www.simtec.co.uk/

Samsung S3C6410 mainline merge coordination

[Peter Korsgaard]

>>>>> "Harald" == Harald Welte <laforge@gnumonks.org> writes:

Hi,

 >> > 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 belive Peter Korsgaard's patch has already been merged to move the
 >> s3c24xx pwm code into the s3c.

 Harald> It's not yet in mainline, but if you believe it has been
 Harald> merged, then it should be a matter of time, right?

It's in s3c-next, so it should reach mainline in the upcoming merge
window.

 Harald> So yes, this needs a lot of thought and work, and I would
 Harald> rather want to see the less controversial 6410 bugfixes and
 Harald> drivers as well as the core support for the s5pc100 go in soon
 Harald> rather than spending months and months working on fancy jpeg
 Harald> accelerators...

Agreed.

-- 
Bye, Peter Korsgaard

Samsung S3C6410 mainline merge coordination

[Russell King - ARM Linux]

On Thu, Sep 03, 2009 at 10:51:42AM +0100, Daniel Silverstone wrote:
> Basically the expectation appears to be that userland wishing to use
> acceleration features of a framebuffer device (such as the multiple planes,
> hardware cursor support, hardware bitblt etc which an SoC or graphics chip
> might implement) is expected to do it for itself by knowing which bit of
> physical memory to mmap() and fiddle, underneath and behind-the-back-of the
> kernel.

Not quite.  The FB API provides a method to map the hardware registers
in a well defined way:

- read the fb_fix_screeninfo structure via the FBIOGET_FSCREENINFO ioctl.
  This gives you the size of the video memory (smem_len) and the size of
  the MMIO registers (mmio_len).  It also tells you what kind of device
  is there (accel).
- mmap using an offset of smem_len and a length of mmio_len.
  This gives you a mapping for the hardware registers independent of the
  actual physical address location.

There is protection built in here to prevent userspace having access to
the hardware registers while the kernel wants to access them - you can
only mmap the MMIO registers provided var.accel_flags is zero (in other
words, you've asked the kernel _not_ to use any hardware acceleration.)
To put it another way, your driver must not use hardware acceleration
for the FB console if var.accel_flags is zero.

So, really, there's no "fiddling behind the back of the kernel" if things
are done correctly, and there's no need to know where the registers
actually appear in the physical space - which was required in the old
days of mapping them via /dev/mem.

Yes, it's unfortunate that the acceleration functions themselves are not
available to userspace, but I don't think the situation is as bad as
you're making it out to be.

Samsung S3C6410 mainline merge coordination

[Daniel Silverstone]

On Thu, Sep 03, 2009 at 11:34:21AM +0100, Russell King - ARM Linux wrote:
> There is protection built in here to prevent userspace having access to
> the hardware registers while the kernel wants to access them - you can
> only mmap the MMIO registers provided var.accel_flags is zero (in other
> words, you've asked the kernel _not_ to use any hardware acceleration.)
> To put it another way, your driver must not use hardware acceleration
> for the FB console if var.accel_flags is zero.

Aah, I see.

> So, really, there's no "fiddling behind the back of the kernel" if things
> are done correctly, and there's no need to know where the registers
> actually appear in the physical space - which was required in the old
> days of mapping them via /dev/mem.

Right. I must have misunderstood my colleague who was talking about this.  I
shall withdraw that particular part of my complaint then :-)

> Yes, it's unfortunate that the acceleration functions themselves are not
> available to userspace, but I don't think the situation is as bad as
> you're making it out to be.

However, each app wishing to have accelerated access to a framebuffer needs to
reimplement the acceleration functions.  Admittedly there's things like
libdirectfb which abstracts that for most users.  However that's still two
implementations (one userland, one kernel) for the same feature.  I can see the
attraction of making userland able to take over acceleration because that way
the kernel doesn't have to have "generic" acceleration primitives for every
last odd feature a graphics controller might implement -- but by the same
token, when the features are already there and all that a program wants, it's a
pity it can't just use the kernel.  Still, this isn't really the right forum
for this discussion so I'll stop now.

Thanks for the clarification.

D.

-- 
Daniel Silverstone                              http://www.simtec.co.uk/

Samsung S3C6410 mainline merge coordination

[Mark Brown]

On Thu, Sep 03, 2009 at 10:56:08AM +0900, Harald Welte wrote:
> On Wed, Sep 02, 2009 at 08:16:26PM +0100, Ben Dooks wrote:

> > Most GPIO setup is done in the bootloader, but there is more that sometimes
> > needs to be done in either the board file or occasionally the driver. The
> > drivers that need help with this, get passed a callback function with the
> > platform data to do the necessary setup (see the sdhci callbacks, i2c, etc).

> yes.  Though honestly speaking, I have my doubts if this is the best solution.
> On the OMAP keypad driver e.g. they simply pass an array of GPIO numbers into
> the driver, where the driver then simply makes gpiolib calls to reconfigure
> the GPIO's.  No special SoC specific API, no custom callbacks that every
> board will have to provide or at least assign.

There's also the approach used by some other platforms like PXA and i.MX
where you have a big table of all the MFP assignments in the machine
driver which gets done statically at system startup.  With that scheme
the drivers don't get involved in the pin function assignment at all.

> Which brings us to the next question: where and how should s3c/s5p related
> code be (re)based on?  Right now Samsung is working with 2.6.31-rc8 mainline
> (and will keep syncing) both for their submit-missing-6410 work, as well as
> for their current s5pc110 related development.

I can't speak for Ben.  However...

In general if you track only Linus' current tree then you're going to be
working with stale code, particularly as the development cycle
progresses since you'll be missing all the development that's gone on
since the last merge window.

The specific tree will depend on the part of the kernel you're working
against, but almost all of them are regularly merged into Stephen
Rothwell's linux-next tree so that's a good place to look:

	git://git.kernel.org/pub/scm/linux/kernel/git/sfr/linux-next.git

(though that's not a good thing to actually base development on directly
unless you're happy doing a lot of git rebasing and dealing with the odd
bit of bleeding edge breakage.)

> Can we somehow work on a model where Samsung accepts contributions into
> their tree?  As I understand s5pc1xx is still very fast moving ahead all the
> time and even Samsung does not consider their code as being finished by any
> means.

> I think the dualism of Samsung's code and Ben Dooks + mainline code has been a
> big resource waste in the past.  I'm looking for ways how this can be avoided
> for future code, where everyone works on one codebase, even before something is
> finished and considered ready for mainline.

I suspect that the easiest thing to achieve here will be to deal with
the issue by merging the current areas of overlap (the ones that need
regular active merging) into mainline as fast as possible and then
continuing to develop in mainline rather than waiting until the code is
perfect and feature complete.  It's been the standard kernel workflow
for a long time and things like staging are pushing towards merging even
earlier.  If required things like dependencies on BROKEN can be used to
mask the code out of Kconfig so that users don't see things that don't
work yet.

Apart from the arch/arm code this also makes life an awful lot easier
when working on drivers in the rest of the tree - dependencies on
underlying out of tree code for the architecture have been a long term
source of fun with some of the ASoC platforms, preventing build tests
and causing confusion for users.

In many ways the fact that maintaining large out of tree patch sets is
painful is a feature of the development process, not a bug :)

Samsung S3C6410 mainline merge coordination

[Mark Brown]

On Thu, Sep 03, 2009 at 09:21:02AM +0900, Joonyoung Shim wrote:
> On 9/2/2009 10:44 PM, jassi brar wrote:

> > S3C2410 has I2S-2.0, S3C6410 has I2S-3.2 and I2S-4.0, S5P6440 has
> > I2S-4.0, S5PC100 has

> I wonder what mean the numbers(2.0, 3.2, 4.0, 5.1). Does it mean I2S 
> version simply? If it is version, what is the differences of each I2S
> version?

It's just the version numbers for the IP blocks.  The differences tend
to be in the addition of new features to the blocks, plus occasional
reorganisations of the register maps.  For example, the v4.0 block added
two extra data out lines for 5.1 audio support.  Since you work at
Samsung I suspect your best bet for documentation on what's going on is
to find an internal source - sadly the datasheets and other detailed
collateral are not public but I'd expect that they are available within
Samsung.

Samsung S3C6410 mainline merge coordination

[Mark Brown]

On Thu, Sep 03, 2009 at 09:38:48AM +0900, jassi brar wrote:

> I recently released one small but essential patch to you to make
> wm8580 generate proper clocks -- essential when wm8580 is I2S master
> -- that made me doubt if Slave support is even implemented/tested on
> SMDKs in mainline.

The change you submitted would only be required if the PLLs are in use,
and even then it only affects some PLL configurations.  

> My plan was to submit something like smdk_wm8580.c (smdks have wm8580
> as the main I2S codec) which can be make menuconfig'ed for
> SoC-Master/Slave and source clock support.

There shouldn't be any build time configuration for things like clock
mastering, the driver should just pick a good configuration and go.
Given the simplicity of the setup the actual board file should be pretty
much trivial anyway, all the real work is in the CPU support.

Also note that not all of the SMDKs are wired up the same way - for
example, the SMDK6410 connects both the DAIs on the WM8580 to the
processor but the SMDK6400 has only one of them connected (in at least
some revisions, there seem to be several floating around).

> Plus, some logical re-arrangement of i2s.c code.

Any fixes and enhancements you've got there would be great.

> >> My idea is to submit only "better enabled" I2S driver with Slave support.

> > In general it's much better (and certainly standard practice within
> > Linux) to enhance and refactor existing drivers incrementally rather
> > than provide entirely new drivers.

> I didn't exactly mean .c files.

OK - that sounds good.  When you said you're going to submit a '"better
enabled" I2S driver' it sounded like an entirely new driver rather than
enhancements to the existing driver.

> >> In the long run, I see I2S drivers segregated by the I2S spec version
> >> they implement....

> > the differences. ?Where that is the case it makes sense to try to keep
> > things together but if conditional code begins to dominate some or
> > all of the driver then that suggests forking the relevant bits.

> Ofcourse, we shudn't keep 95% identical _v20, _v32, _v40 and _v50.c
> For the time being, when our driver doesn't make use of any spec
> differentiator, all SoCs can be served with a single file.
> But as we implement more and more support to 40 (5.1channel)and 50(5.1
> channel + channel mixing) versions, we will need segregation.

As far as I remember from when I worked on 5.1 support in your old BSP
it may be possible to cover the v4.0 in the same driver - there was a
great deal of compatibility.  I've not seen the v5 datasheets so I can't
really comment about the level of changes there.

> As a starter we cud do by converting Samsung's I2S code 24xx(and even
> s3c) agnostic?

I'm not quite sure what you mean by this?

Samsung S3C6410 mainline merge coordination

[Joonyoung Shim]

On 9/3/2009 8:06 PM, Mark Brown wrote:
> On Thu, Sep 03, 2009 at 09:21:02AM +0900, Joonyoung Shim wrote:
>> On 9/2/2009 10:44 PM, jassi brar wrote:
> 
>>> S3C2410 has I2S-2.0, S3C6410 has I2S-3.2 and I2S-4.0, S5P6440 has
>>> I2S-4.0, S5PC100 has
> 
>> I wonder what mean the numbers(2.0, 3.2, 4.0, 5.1). Does it mean I2S 
>> version simply? If it is version, what is the differences of each I2S
>> version?
> 
> It's just the version numbers for the IP blocks.  The differences tend
> to be in the addition of new features to the blocks, plus occasional
> reorganisations of the register maps.  For example, the v4.0 block added
> two extra data out lines for 5.1 audio support.  Since you work at

I see. if we use the default feature only, i think the codes of mainline
can be reused because all I2S versions have basically the features of
I2S-2.0(S3C2410).

> Samsung I suspect your best bet for documentation on what's going on is
> to find an internal source - sadly the datasheets and other detailed
> collateral are not public but I'd expect that they are available within
> Samsung.
> 

Right. Unfortunately i am not on Samsung LSI linux team, but I do
a related work on other team.

Samsung S3C6410 mainline merge coordination

[jassi brar]

On Thu, Sep 3, 2009 at 9:14 PM, Mark Brown<broonie@sirena.org.uk> wrote:
> On Thu, Sep 03, 2009 at 09:38:48AM +0900, jassi brar wrote:
>
>> I recently released one small but essential patch to you to make
>> wm8580 generate proper clocks -- essential when wm8580 is I2S master
>> -- that made me doubt if Slave support is even implemented/tested on
>> SMDKs in mainline.
>
> The change you submitted would only be required if the PLLs are in use,
> and even then it only affects some PLL configurations.

If a machine has a dedicated OSC attached to MCLK of the I2S Codec
chip, most probably
the user want to use that while running in SoC-Slave mode -- why
bother SoC output even I2SCDCLK?
And the 12MHz OSC input doesn't do any good if not refined via the WM8580 PLLs.
So, on SMDK6410, I believe anyone who wants to run SoC-Slave mode will end up
making use of the WM8580 PLLs.
Btw, without the patch i measured error in LRCLK noticable for a
"customer demand"
 --- 41 instead of 44.1 the standard in mp3 playbacks.
Anyways.....


>> My plan was to submit something like smdk_wm8580.c (smdks have wm8580
>> as the main I2S codec) which can be make menuconfig'ed for
>> SoC-Master/Slave and source clock support.
>
> There shouldn't be any build time configuration for things like clock
> mastering, the driver should just pick a good configuration and go.
> Given the simplicity of the setup the actual board file should be pretty
> much trivial anyway, all the real work is in the CPU support.
I hope we agree the SoC-Master/Slave option should be selected in make
menuconfig.
Direction of LRCLK, BCLK thus gets decided there.

IMHO, source of MCLK - I2SCDCLK, PCLK, SCLK_Audio(with further
options) - is better
decided during compile-time too. Otherwise, put-get-put-setrate-'ing
different clocks, according
to the LRCLK needed, in runtime will add more complexity than
flexibility to the driver. Or so do i think.

>> >> In the long run, I see I2S drivers segregated by the I2S spec version
>> >> they implement....
>
>> > the differences. ?Where that is the case it makes sense to try to keep
>> > things together but if conditional code begins to dominate some or
>> > all of the driver then that suggests forking the relevant bits.
>
>> Ofcourse, we shudn't keep 95% identical _v20, _v32, _v40 and _v50.c
>> For the time being, when our driver doesn't make use of any spec
>> differentiator, all SoCs can be served with a single file.
>> But as we implement more and more support to 40 (5.1channel)and 50(5.1
>> channel + channel mixing) versions, we will need segregation.
>
> As far as I remember from when I worked on 5.1 support in your old BSP
> it may be possible to cover the v4.0 in the same driver - there was a
> great deal of compatibility. ?I've not seen the v5 datasheets so I can't
> really comment about the level of changes there.
Yes, state-machine code of v3.2 can run both v4 and v5 and 5.1channel
support of v4 can run that of v5 too. Now v5 has got an added feature
 - LowPowerAudioMode(LPAM) which wud rather take minor tweaks in even
the ALSA stack to run.
And I think we can no longer juggle and reuse the 24xx code.
Either we manage two classes of I2S drivers - simple 2channel Vs
sophisticated 5.1channel with h/w mixing and LPAM etc,
Or we restructure to drivers around "library" like functionality - like PXA.

>> As a starter we cud do by converting Samsung's I2S code 24xx(and even
>> s3c) agnostic?
> I'm not quite sure what you mean by this?
I meant we can atleast make names of functions and datastructures 2410 neutral,
like changing from s3c24xx_i2s to samsung_i2s_v2 or somthing like that.
i.e, designing around IPs rather than SoCs.

Not just for I2S, rather for entire BSP, I believe an approach with
riddance from
the jargon of Samsung SoCs(s3c, s5p, 2410, 24xx, 2412, 64xx etc) and centered
around IPs rather than the SoCs wud server us better.
That way, just like SoC silicon, Linux bsp will also be a matter of simply
compiling a particular version of each device IP.

Samsung S3C6410 mainline merge coordination

[Mark Brown]

On Thu, Sep 03, 2009 at 10:39:07PM +0900, jassi brar wrote:
> On Thu, Sep 3, 2009 at 9:14 PM, Mark Brown<broonie@sirena.org.uk> wrote:

> > The change you submitted would only be required if the PLLs are in use,
> > and even then it only affects some PLL configurations.

> So, on SMDK6410, I believe anyone who wants to run SoC-Slave mode will end up
> making use of the WM8580 PLLs.

Historically the SMDK drivers in the BSPs have always run the CODEC as
slave; I've never been sure why.  I believe most of the other users are
using a crystal that directly generates the rates they need.

> > There shouldn't be any build time configuration for things like clock
> > mastering, the driver should just pick a good configuration and go.

> I hope we agree the SoC-Master/Slave option should be selected in make
> menuconfig.
> Direction of LRCLK, BCLK thus gets decided there.

The machine driver should just pick a suitable configuration and go with
it.  This isn't something which users should need to be concerned about
having to configure - it's way more detail than they need to know to get
audio working, it just makes support harder.  If someone is interested
in playing about with these options they can always go and edit the
source code but it's a very niche use case.

> IMHO, source of MCLK - I2SCDCLK, PCLK, SCLK_Audio(with further
> options) - is better
> decided during compile-time too. Otherwise, put-get-put-setrate-'ing
> different clocks, according
> to the LRCLK needed, in runtime will add more complexity than
> flexibility to the driver. Or so do i think.

If you're talking about the CPU DAI then all this stuff needs to be
decided at runtime - compile time selection causes lots of problems.  It
means that it's not possible to build kernels which will run on boards
with different configurations, nor is it possible to have a single
machine using multiple I2S ports with different configurations.

If you're talking about the machine driver then yes, this should just be
fixed in the source code as discussed above.

> Yes, state-machine code of v3.2 can run both v4 and v5 and 5.1channel
> support of v4 can run that of v5 too. Now v5 has got an added feature
>  - LowPowerAudioMode(LPAM) which wud rather take minor tweaks in even
> the ALSA stack to run.
> And I think we can no longer juggle and reuse the 24xx code.
> Either we manage two classes of I2S drivers - simple 2channel Vs
> sophisticated 5.1channel with h/w mixing and LPAM etc,

This sounds like there's a break at version 5, then.  Though it may also
be the case that you want to represent the new parts of the V5 block as
a separate driver, keeping the I2S-specific block isolated.  Like I say,
it's a bit hard to comment in detail about the v5 block without seeing
any information about it.

> Or we restructure to drivers around "library" like functionality - like PXA.

That sounds like it's worth looking into, but depending on how big the
differences are there may be no advantages.  Note that the library stuff
for PXA isn't about sharing the code between multiple devices, it's
about exporting the same device via two different APIs.

> >> As a starter we cud do by converting Samsung's I2S code 24xx(and even
> >> s3c) agnostic?
> > I'm not quite sure what you mean by this?

> I meant we can atleast make names of functions and datastructures 2410 neutral,
> like changing from s3c24xx_i2s to samsung_i2s_v2 or somthing like that.
> i.e, designing around IPs rather than SoCs.

I don't have any massive problem with doing this but if you wish to do
this be sure to ensure that big reformatting changes such as this are
isolated from all other changes.  Part of the reason nothing's ever been
changed is that changes like this are very disruptive relative to their
benefits.

Samsung S3C6410 mainline merge coordination

[jassi brar]

Brown<broonie@sirena.org.uk> wrote:
>
>> > The change you submitted would only be required if the PLLs are in use,
>> > and even then it only affects some PLL configurations.
>
>> So, on SMDK6410, I believe anyone who wants to run SoC-Slave mode will end up
>> making use of the WM8580 PLLs.
>
> Historically the SMDK drivers in the BSPs have always run the CODEC as
> slave; I've never been sure why. ?I believe most of the other users are
> using a crystal that directly generates the rates they need.
Yes, samsung BSPs have always implemented SoC-Master by dafault
perhaps because most I2S Codec Chips run as Slaves by default.
Now, we want to support as many configurations as there are.

>> I hope we agree the SoC-Master/Slave option should be selected in make
>> menuconfig.
>> Direction of LRCLK, BCLK thus gets decided there.
>
> The machine driver should just pick a suitable configuration and go with
> it. ?This isn't something which users should need to be concerned about
> having to configure - it's way more detail than they need to know to get
> audio working, it just makes support harder. ?If someone is interested
> in playing about with these options they can always go and edit the
> source code but it's a very niche use case.
I think the 'suitable' configuration is the one that the user(device
maker) wants.
Because i think platform designers already are pretty sure of what
mode they wanna run the SoC-I2S in - they won't run SoC in MASTER mode
if they have attached a good OSC to the CODEC.

Btw, what cud be the criteria of switch from SoC Master to SoC Slave
during runtime?
Or perhaps we are simply putting the same thing differently.

>> IMHO, source of MCLK - I2SCDCLK, PCLK, SCLK_Audio(with further
>> options) - is better
>> decided during compile-time too. Otherwise, put-get-put-setrate-'ing
>> different clocks, according
>> to the LRCLK needed, in runtime will add more complexity than
>> flexibility to the driver. Or so do i think.
>
> If you're talking about the CPU DAI then all this stuff needs to be
> decided at runtime - compile time selection causes lots of problems. ?It
> means that it's not possible to build kernels which will run on boards
> with different configurations, nor is it possible to have a single
> machine using multiple I2S ports with different configurations.
>
> If you're talking about the machine driver then yes, this should just be
> fixed in the source code as discussed above.
Yes, i am talking about machine driver.
Cpu-Dai driver shud be as generic and implement as many SoC features
as possible.
Machine driver should runtime configure Cpu_Dai and Codec_Dai as per
the Master/Slave and Clock sourcing options it "got from make
menuconfig".

>Like I say, it's a bit hard to comment in detail about the v5 block without seeing
> any information about it.
well.....i can only acknowledge your point :)

>> I meant we can atleast make names of functions and datastructures 2410 neutral,
>> like changing from s3c24xx_i2s to samsung_i2s_v2 or somthing like that.
>> i.e, designing around IPs rather than SoCs.
>
> I don't have any massive problem with doing this but if you wish to do
> this be sure to ensure that big reformatting changes such as this are
> isolated from all other changes. ?Part of the reason nothing's ever been
> changed is that changes like this are very disruptive relative to their
> benefits.
I think it's not a good enough reason that we don't see any problem.
The restructuring shud, and wud, only be started if people(esp Ben)
find it a better way.
I, for one, strongly believe that.
Ofcourse, it won't be a one-shot change but slowly we can submit
patches and design changes towards achieving that.

Samsung SoC ASOC drivers

[Harald Welte]

Hi Jassi,

On Thu, Sep 03, 2009 at 10:39:07PM +0900, jassi brar wrote:
> >> My plan was to submit something like smdk_wm8580.c (smdks have wm8580
> >> as the main I2S codec) which can be make menuconfig'ed for
> >> SoC-Master/Slave and source clock support.
> >
> > There shouldn't be any build time configuration for things like clock
> > mastering, the driver should just pick a good configuration and go.
> > Given the simplicity of the setup the actual board file should be pretty
> > much trivial anyway, all the real work is in the CPU support.
>
> I hope we agree the SoC-Master/Slave option should be selected in make
> menuconfig.  Direction of LRCLK, BCLK thus gets decided there.
> 
> IMHO, source of MCLK - I2SCDCLK, PCLK, SCLK_Audio(with further options) - is
> better decided during compile-time too. Otherwise, put-get-put-setrate-'ing
> different clocks, according to the LRCLK needed, in runtime will add more
> complexity than flexibility to the driver. Or so do i think.

I'm sorry to have to disagree.  The driver is compiled once into a kernel or
kernel module.  The resulting kernel module has to run on every board (mach-*)
that is out there, and at driver probe time it needs to sort out what clocking
to use and whether it's master or slave.  If there's no good way to do this
(semi)automatically, the respective configuration needs to be passed from the board level code by means of platform_data into the driver.

Yes, this will add complexity, no question.  But this is one of the differences
of working on "real" drivers for a general-purpose mainline kernel vs. working
on a driver that is only supposed to be used by one particular customer on one
particular board..

> > As far as I remember from when I worked on 5.1 support in your old BSP
> > it may be possible to cover the v4.0 in the same driver - there was a
> > great deal of compatibility. ?I've not seen the v5 datasheets so I can't
> > really comment about the level of changes there.
>
> Yes, state-machine code of v3.2 can run both v4 and v5 and 5.1channel
> support of v4 can run that of v5 too. Now v5 has got an added feature
>  - LowPowerAudioMode(LPAM) which wud rather take minor tweaks in even
> the ALSA stack to run.
> And I think we can no longer juggle and reuse the 24xx code.
> Either we manage two classes of I2S drivers - simple 2channel Vs
> sophisticated 5.1channel with h/w mixing and LPAM etc,
> Or we restructure to drivers around "library" like functionality - like PXA.

I'm personally not too much into any of those details.  Having two drivers
with one 2channel and one 5.1channel sounds a bit like the 5.1channel will
be a superset of the 2channel driver, i.e. it will (among many other things)
also implement those bits in the 2channel driver - which I believe would be
suboptimal.

> >> As a starter we cud do by converting Samsung's I2S code 24xx(and even
> >> s3c) agnostic?
> > I'm not quite sure what you mean by this?
> I meant we can atleast make names of functions and datastructures 2410 neutral,
> like changing from s3c24xx_i2s to samsung_i2s_v2 or somthing like that.
> i.e, designing around IPs rather than SoCs.
> 
> Not just for I2S, rather for entire BSP, I believe an approach with
> riddance from
> the jargon of Samsung SoCs(s3c, s5p, 2410, 24xx, 2412, 64xx etc) and centered
> around IPs rather than the SoCs wud server us better.

I like that approach, but two comments:

1) The problem is just that the samsung user manuals never specify the version
   of the IP cores, so for anyone outside samsung it is impossible to know
   those version numbers.  Maybe a publicly releaseable single page table
   listing all IP cores in the rows and have one column for every SoC would help

2) it would mean that we start with renaming many things across arch/arm code
   and in the drivers subdirectory, which is difficult to synchronize and will
   cause delays for any real development (i.e. becoming more feature-complete).

We really should focus on adding features and fixing bugs right now, rather than
thinking of the perfect solution which would hold back any real pogress.

-- 
- 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 SoC ASOC drivers

[jassi brar]

On Fri, Sep 4, 2009 at 10:27 AM, Harald Welte<laforge@gnumonks.org> wrote:
> Hi Jassi,
>>
>> I hope we agree the SoC-Master/Slave option should be selected in make
>> menuconfig. ?Direction of LRCLK, BCLK thus gets decided there.
>>
>> IMHO, source of MCLK - I2SCDCLK, PCLK, SCLK_Audio(with further options) - is
>> better decided during compile-time too. Otherwise, put-get-put-setrate-'ing
>> different clocks, according to the LRCLK needed, in runtime will add more
>> complexity than flexibility to the driver. Or so do i think.
>
> I'm sorry to have to disagree. ?The driver is compiled once into a kernel or
> kernel module. ?The resulting kernel module has to run on every board (mach-*)
> that is out there
Hmmm...  i didn't realize that scenario.
Esp for source clocks, which has to do with cpu_dai.

Anyways, I will have to consider such expert comments when i submit the code.


>> Yes, state-machine code of v3.2 can run both v4 and v5 and 5.1channel
>> support of v4 can run that of v5 too. Now v5 has got an added feature
>> ?- LowPowerAudioMode(LPAM) which wud rather take minor tweaks in even
>> the ALSA stack to run.
>> And I think we can no longer juggle and reuse the 24xx code.
>> Either we manage two classes of I2S drivers - simple 2channel Vs
>> sophisticated 5.1channel with h/w mixing and LPAM etc,
>> Or we restructure to drivers around "library" like functionality - like PXA.
>
> I'm personally not too much into any of those details. ?Having two drivers
> with one 2channel and one 5.1channel sounds a bit like the 5.1channel will
> be a superset of the 2channel driver, i.e. it will (among many other things)
> also implement those bits in the 2channel driver - which I believe would be
> suboptimal.
So do i think. I'd rather favor the second option.

>> >> As a starter we cud do by converting Samsung's I2S code 24xx(and even
>> >> s3c) agnostic?
>> > I'm not quite sure what you mean by this?
>> I meant we can atleast make names of functions and datastructures 2410 neutral,
>> like changing from s3c24xx_i2s to samsung_i2s_v2 or somthing like that.
>> i.e, designing around IPs rather than SoCs.
>>
>> Not just for I2S, rather for entire BSP, I believe an approach with
>> riddance from
>> the jargon of Samsung SoCs(s3c, s5p, 2410, 24xx, 2412, 64xx etc) and centered
>> around IPs rather than the SoCs wud server us better.
>
> I like that approach, but two comments:
>
> 1) The problem is just that the samsung user manuals never specify the version
> ? of the IP cores, so for anyone outside samsung it is impossible to know
> ? those version numbers. ?Maybe a publicly releaseable single page table
> ? listing all IP cores in the rows and have one column for every SoC would help
Yes, and the classification can be maintainer defined and maybe kept
in some Documentations/samsung-soc.txt  or something.

A similar IP based classification is already in place and a very
successful example -- ARM cpu.


> 2) it would mean that we start with renaming many things across arch/arm code
> ? and in the drivers subdirectory, which is difficult to synchronize and will
> ? cause delays for any real development (i.e. becoming more feature-complete).
> We really should focus on adding features and fixing bugs right now, rather than
> thinking of the perfect solution which would hold back any real pogress.
I share you concern. I don't intend to start submiting patches right away.
I am only trying to bring to notice one point to the maintainers and
if everybody agrees, that wud be taken up slowly and steadily.

Btw, I am already modifying Samsung 6410 I2S and SPI code to fit in
the existing mainline structure.

Samsung S3C6410 mainline merge coordination

[Pavel Machek]

Hi!

> > > > > does it support X kdrive 2D accelerate ?
> > > > X / kdrive is not part of the linux kernel.  Therefore, it is unrelated
> > > > to the Linux kernel code that we are working on.
> > > Unfortunately it seems that pretty much no-one uses the fb driver
> > > acceleration, I'm not even sure if it has even been exported outside
> > > the kernel, so isn't really a lot of use.
> > having cursor acceleration and things like bitblit for srolling is a real
> > pleasure if you ever happen to work for more than 5 minutes on the framebuffer
> > console, especially on a system that already has a quite high load at that time.
> > It sort-of is a standard feature, and at least in the x86/PCI/AGP world, I
> > am not awaer that any framebuffer driver would not support it.  That's why I
> > had it on my todo list.
> 
> Simtec produced a set of patches to expose the Linux Kernel FB acceleration
> primitives to userland, only to be told that it was unlikely they'd be accepted
> due to them having never been exposed before.  (Yes, it was a case of 'We have
> always done it this way, why would we want to change?')

If the performance is good enough that way (is it?), then the
interface makes sense. With all the work on kernel mode setting,
climaate probably changed; and even if not, people can be convinced
with good arguments.

-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html

Samsung S3C6410 mainline merge coordination

[Nelson Castillo]

On Wed, Sep 2, 2009 at 11:33 PM, Harald Welte<laforge@gnumonks.org> wrote:
> On Wed, Sep 02, 2009 at 10:38:30PM -0500, Nelson Castillo wrote:
>
>> If it helps I can send a simplified version of the driver that does
>> not depend on filtering.
>
> I would like to see that one and see it go forward.

Harald, I replaced the filter framework with a simple filter that is
in the same driver. It's not better than all the filters (it doesn't
mix information from X and Y) but I'm surprised with the results I'm
seeing. It filters the nasty noise most of the times in my tests.

http://nelson-patches.googlecode.com/svn/trunk/openmoko/kernel/ts-with-s3c-adc/s3c2410_ts_simple_filter.c

I tested with a GTA02 (andy-tracking branch / 2.6.29-rc3). Some
required patches I used are in the same directory.

s3c-adc-cleanup.patch and s3c-adc-control-remaining-conversions.patch
were already merged by Ben and are in the Linus tree.

I won't be able to further improve it in the next few days.... It
might be useful as a starting point.

Samsung S3C6410 mainline merge coordination

[Mark Brown]

On Fri, Sep 04, 2009 at 10:08:43AM +0900, jassi brar wrote:
> Brown<broonie@sirena.org.uk> wrote:

> > The machine driver should just pick a suitable configuration and go with
> > it. ?This isn't something which users should need to be concerned about

> I think the 'suitable' configuration is the one that the user(device
> maker) wants.

> Because i think platform designers already are pretty sure of what
> mode they wanna run the SoC-I2S in - they won't run SoC in MASTER mode
> if they have attached a good OSC to the CODEC.

Quite, this is one of the reasons why this shouldn't be exposed in
Kconfig - the choice of clock master will either not matter or will have
been fixed at hardware design time.

> Btw, what cud be the criteria of switch from SoC Master to SoC Slave
> during runtime?

Some systems with more complex audio will need to reclock the system at
runtime when moving between different use cases, often due to things
like making tradeoffs between power and quality.  This will almost
always be managed by the machine driver and certainly isn't going to be
an issue for any of the SMDKs that I've seen.

> Machine driver should runtime configure Cpu_Dai and Codec_Dai as per
> the Master/Slave and Clock sourcing options it "got from make
> menuconfig".

No, this is not something that should be offered as a configuration
option.  As I've said the machine driver should just pick a
configuration that works well on the hardware and go with that.
Presenting the configuration means that users need to understand the
various options that are being offered and come to a decision.  Since
the end result will be that either one of the options is clearly better
(in which case there is no reason to choose the other option) or there's
no difference (in which case why bother the user with the decision in
the first place) this at best achieves nothing but wasting a bit of
their time and at worst will confuse them.

If someone has modified the hardware then they will most likely want to
produce a new machine driver anyway.  If someone is interested in
evaluating the various configurations (probably with the view to
producing their own board) they can easily modify the source code.
With a Kconfig choice they're going to have to rebuild the kernel to
change configurations anyway.

Samsung S3C6410 mainline merge coordination

[jassi brar]

On Fri, Sep 4, 2009 at 10:41 PM, Mark Brown<broonie@sirena.org.uk> wrote:
> If someone has modified the hardware then they will most likely want to
> produce a new machine driver anyway. ?If someone is interested in
> evaluating the various configurations (probably with the view to
> producing their own board) they can easily modify the source code.
> With a Kconfig choice they're going to have to rebuild the kernel to
> change configurations anyway.

I am afraid we are not able communicate our ideas clear enough, maybe
b'coz am a bit slow
or maybe i am wrong altogether. Let us communicate in code.
Gimme some time to come up with code for 6410 and maybe then i cud
better understand ur feedback.
Btw, i am preparing patches against your sound-2.6 tree. Please tell
if that is improper.


Let us let this thread take its intended course -- Suggestions of
maintainers as to how
we, at Samsung, cud involve in mainline support for Samsung SoCs.

AUDIO:-
   As one of the maintainer of Samsung SoC audio part, please tell
which task shud be my priority towards
enabling better audio support for 6410(and other newer SoCs too) in mainline.

SPI:-
  Soon after audio, my plan is to submit the SPI driver with support
for DMA, Multi-CS, MODE-0,1,2,3
FullDuplex tested with MMC over SPI.

OTHERS:-
  Maintainers may pitch in here to list TODOs for other 6410 drivers.

Samsung S3C6410 mainline merge coordination

[Mark Brown]

On Fri, Sep 04, 2009 at 11:27:48PM +0900, jassi brar wrote:

> I am afraid we are not able communicate our ideas clear enough, maybe
> b'coz am a bit slow
> or maybe i am wrong altogether. Let us communicate in code.

OK.  The bottom line in terms of this subthread is that all the user
should see in Kconfig is "Enable audio support for $BOARD" - if
something else is happening it at least needs to be explained in detail
why it's required.

> Btw, i am preparing patches against your sound-2.6 tree. Please tell
> if that is improper.

Yes, that's the right tree to work on.  Use the most recent for-2.6.x
branch for anything except bugfixes destined for Linus' tree - those
should go on the branch with the appropriate version number.

> AUDIO:-
>    As one of the maintainer of Samsung SoC audio part, please tell
> which task shud be my priority towards
> enabling better audio support for 6410(and other newer SoCs too) in mainline.

I would suggest that the best thing would be to focus on adding support
for the IISv4 and AC'97 controllers.  I'd suggest doing the AC'97
controller first since that is the one I've seen the most demand for
from users and it's a fairly static standalone block.  I already
submitted changes to add the platform devices for it which are IIRC in
Ben's tree and hit 2.6.32.

I can take care of the machine drivers (or the bulk of the work on
completing them) for you if you like - for the WM8580 I wanted to have a
look at modernising the driver while I was looking at this anyway which
will affect the machine drivers.

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 / Xorgy

[David F. Carlson]

I am not sure about uio.  Sorry.

The main problem is the g2d fifo is 32 commands deep.  And some of the 
x11perf tests are running in our XAA s3c driver @ ~2e6 ops/sec.  That is is 
lot of interrupts for user or kernel context.  :-)   

Sometimes polling is better.  1/2 :-)  

We are 1 stupid bug away from a release of s3c Xwindows fbdev + XAA + 
Xvideo (using the samsung s3c-pp) and HW cursor with alpha blend.

I have not looked at the g3d but DRI is "next".  

Cheers

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
According to 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.
> 

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.

Samsung S3C6410 mainline merge coordination

[Harald Welte]

Hi Jin-Sung,

thanks for your fast response.

On Wed, Sep 02, 2009 at 11:55:57PM +0000, Jinsung Yang wrote:

> > > The nand controllers in the different variants are afaik very similar,
> > > that's why I added 64xx support to s3c2410.c. What would a split gain
> > > us?
> > 
> > That's the question the respective developers at Samsung should respond to
> > (see
> > Cc) Why do you think a split of the nand driver is required? Please
> > comment.
> > 
> Even though we have very similar nand flash controller for various SoCs, 
> there are new features such as 4 bit and 8 bit hardware ecc.
> Since our new SoCs have been growing gradually with backward compatibilities,
> we can use s3c2410.c nand driver, but that means we can use just simple read,
> write and erase, that's it.  Many customer and developers require 4/8 bit
> hardware ecc and 4 kb large page support.

If the new SoC's hardware is mostly backwards compatible, then we should
simply add the 4bit/8bit hardware ECC and large page support to the existing
driver, gradually growing its capabilities.

At runtime, the driver then checks which SoC is being used (e.g. by
using the platform_device name) and depending on that enables the code for
those new features.

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)