Future of S3C6410 platform

Future of S3C6410 platform

[Tomasz Figa]

List,

I am writing to ask what is the planned future for the (now obsolete?) S3C6410 
platform. Is there any ongoing work on bringing more feature-complete support 
for it?

The platform is really far behind its newer friends and here is what bothers 
me most:
- missing basic features as NOHZ support
- buggy drivers (in mainline!, s3c-fb requesting irq before fully initializing 
driver data, same goes for the adc driver)
- totally broken usb gadget driver - I could not get it to work on my platform 
in any way (Samsung GT-i5700 phone; I am getting a Tiny6410 soon, so I will 
check whether it is not a board specific issue) without rewriting control 
endpoint handling code, not even mentioning about DMA support, which I still 
cannot get to work
- poor OneNAND support (mostly in terms of performance)
- no power domain support
- no support for advanced features of the chip (ie. functionality provided by 
old, and really _bad_, s3c modules)

I have already added NOHZ support, fixed fb and adc bugs, refactored control 
endpoint handling in udc driver (no DMA yet), done some improvement to OneNAND 
driver (still a big work in progress though, this is a topic for another 
message) and implemented power domain management + other minor changes/fixes. 

All of this is available in my tree at 
git://github.com/tom3q/spica-2.6.38.git, but I am going to prepare patches 
containing all the changes a bit later, after I rebase all my work to latest 
Linux sources, as I worked mostly on Android 2.6.38 sources.

Best regards,
Tomasz Figa

Future of S3C6410 platform

[Arnd Bergmann]

On Monday 04 July 2011 21:14:19 Tomasz Figa wrote:
> I am writing to ask what is the planned future for the (now obsolete?) S3C6410 
> platform. Is there any ongoing work on bringing more feature-complete support 
> for it?

I guess you should ask the maintainer directly, now on Cc. I wouldn't call
s3c6410 obsolete, we have much much older platforms that are still supported
well. Of course, many people are overworked and need to set priorities,
so it's understandable if there are fewer patches to improve the less
current platforms.

> The platform is really far behind its newer friends and here is what bothers 
> me most:
> - missing basic features as NOHZ support
> - buggy drivers (in mainline!, s3c-fb requesting irq before fully initializing 
> driver data, same goes for the adc driver)
> - totally broken usb gadget driver - I could not get it to work on my platform 
> in any way (Samsung GT-i5700 phone; I am getting a Tiny6410 soon, so I will 
> check whether it is not a board specific issue) without rewriting control 
> endpoint handling code, not even mentioning about DMA support, which I still 
> cannot get to work
> - poor OneNAND support (mostly in terms of performance)
> - no power domain support
> - no support for advanced features of the chip (ie. functionality provided by 
> old, and really _bad_, s3c modules)
> 
> I have already added NOHZ support, fixed fb and adc bugs, refactored control 
> endpoint handling in udc driver (no DMA yet), done some improvement to OneNAND 
> driver (still a big work in progress though, this is a topic for another 
> message) and implemented power domain management + other minor changes/fixes. 

In general, patches that fix bugs are always welcome, and so are patches
that add functionality and device drivers. Even device drivers that are
not good enough for inclusion can often get merged into the drivers/staging
directory, if there is hope that the quality of the code is improving
over time.

> All of this is available in my tree at 
> git://github.com/tom3q/spica-2.6.38.git, but I am going to prepare patches 
> containing all the changes a bit later, after I rebase all my work to latest 
> Linux sources, as I worked mostly on Android 2.6.38 sources.

Yes, that is a necessary step for getting your code contributions into
the mainline kernel. You should also read Documentation/SubmittingPatches
carefully, to avoid a frustrating experience from the first submission of
a large patch set.

I would recommend that you have your patches reviewed in private by a person
you know first, and then post them on the mailing list for a broader review.

	Arnd

Future of S3C6410 platform

[Ben Dooks]

On Mon, Jul 04, 2011 at 10:39:41PM +0200, Arnd Bergmann wrote:
> On Monday 04 July 2011 21:14:19 Tomasz Figa wrote:
> > I am writing to ask what is the planned future for the (now obsolete?) S3C6410 
> > platform. Is there any ongoing work on bringing more feature-complete support 
> > for it?
> 
> I guess you should ask the maintainer directly, now on Cc. I wouldn't call
> s3c6410 obsolete, we have much much older platforms that are still supported
> well. Of course, many people are overworked and need to set priorities,
> so it's understandable if there are fewer patches to improve the less
> current platforms.

We've still got shipping products with these chips, they're actively used
and still being manufactured.
 
> > The platform is really far behind its newer friends and here is what bothers 
> > me most:
> > - missing basic features as NOHZ support

hardly a basic feature.

> > - buggy drivers (in mainline!, s3c-fb requesting irq before fully initializing 
> > driver data, same goes for the adc driver)

never seen any bug reports for these items.

> > - totally broken usb gadget driver - I could not get it to work on my platform 
> > in any way (Samsung GT-i5700 phone; I am getting a Tiny6410 soon, so I will 
> > check whether it is not a board specific issue) without rewriting control 
> > endpoint handling code, not even mentioning about DMA support, which I still 
> > cannot get to work
> > - poor OneNAND support (mostly in terms of performance)

I've not seen any s3c6410 systems with OnenNAND on.

The UDC driver actually works most of the time for me, there are a few
corner cases that require work on for cases where it does not handle
unexpected events from the hardware. Newer SoCs do not tend to produce
these cases due to different synthesis options, and thus not all are
dealt with.

> > - no power domain support

runtime pm should make this easier.

> > - no support for advanced features of the chip (ie. functionality provided by 
> > old, and really _bad_, s3c modules)

old? some of these IP blocks have not changed much since their original
s3c2400 incarnations. The blocks that have changed have been re-written
to deal with this.

You're really endearing yourself to me by calling s3c modules "really _bad_".
 
> > I have already added NOHZ support, fixed fb and adc bugs, refactored control 
> > endpoint handling in udc driver (no DMA yet), done some improvement to OneNAND 
> > driver (still a big work in progress though, this is a topic for another 
> > message) and implemented power domain management + other minor changes/fixes. 

the usb gadget driver already has some of the DMA support code in it,
but the s3c6410 compilation of that hardware does not do unaligned
buffers making it difficult to use for most of the current gadget
drivers.  My view is that bounce-buffers are probably not going to
help much, so it was never a priority.

Unfortunately there's not a lot I can do with this driver as I am at the
limit of the documenation I can currently get my hands on.

Some of this will probably be obsoleted soon anyway due to the massive
restructuring in arch/arm land.
 
> In general, patches that fix bugs are always welcome, and so are patches
> that add functionality and device drivers. Even device drivers that are
> not good enough for inclusion can often get merged into the drivers/staging
> directory, if there is hope that the quality of the code is improving
> over time.

drivers/staging is not in any 
 
> > All of this is available in my tree at 
> > git://github.com/tom3q/spica-2.6.38.git, but I am going to prepare patches 
> > containing all the changes a bit later, after I rebase all my work to latest 
> > Linux sources, as I worked mostly on Android 2.6.38 sources.

Is there a browsable list of changes that you've got?
 
> Yes, that is a necessary step for getting your code contributions into
> the mainline kernel. You should also read Documentation/SubmittingPatches
> carefully, to avoid a frustrating experience from the first submission of
> a large patch set.
> 
> I would recommend that you have your patches reviewed in private by a person
> you know first, and then post them on the mailing list for a broader review.
> 
> 	Arnd

-- 
Ben Dooks, ben at fluff.org, http://www.fluff.org/ben/

Large Hadron Colada: A large Pina Colada that makes the universe disappear.

Future of S3C6410 platform

[Tomasz Figa]

On Monday 04 of July 2011 22:39:22 Ben Dooks wrote:
> On Mon, Jul 04, 2011 at 10:39:41PM +0200, Arnd Bergmann wrote:
> > On Monday 04 July 2011 21:14:19 Tomasz Figa wrote:
> > > I am writing to ask what is the planned future for the (now
> > > obsolete?) S3C6410 platform. Is there any ongoing work on bringing
> > > more feature-complete support for it?
> > 
> > I guess you should ask the maintainer directly, now on Cc. I wouldn't
> > call s3c6410 obsolete, we have much much older platforms that are still
> > supported well. Of course, many people are overworked and need to set
> > priorities, so it's understandable if there are fewer patches to
> > improve the less current platforms.
> 
> We've still got shipping products with these chips, they're actively used
> and still being manufactured.

OK, that's good, as I'm really interested in feature-complete support for this 
platform.

> > > The platform is really far behind its newer friends and here is what
> > > bothers me most:
> > > - missing basic features as NOHZ support
> 
> hardly a basic feature.

For mobile phones running Android requiring high interactivity and power 
efficiency this paired with hrtimers (both depending on GENERIC_CLOCKEVENTS) 
becomes a must.

> > > - buggy drivers (in mainline!, s3c-fb requesting irq before fully
> > > initializing driver data, same goes for the adc driver)
> 
> never seen any bug reports for these items.

In this case all the boards based on s3c6410 supported by Linux don't suffer 
from a broken bootloader which leaves half of the hardware in a definitely not 
clean state.

For me (on GT-i5700) both fb and adc, after leaving the bootloader, end up 
with unhandled interrupts and calling request_irq leads to kernel crash 
because an interrupt fires before all driver data get initialized.

> > > - totally broken usb gadget driver - I could not get it to work on
> > > my platform in any way (Samsung GT-i5700 phone; I am getting a
> > > Tiny6410 soon, so I will check whether it is not a board specific
> > > issue) without rewriting control endpoint handling code, not even
> > > mentioning about DMA support, which I still cannot get to work
> > > - poor OneNAND support (mostly in terms of performance)
> 
> I've not seen any s3c6410 systems with OnenNAND on.

This is mostly the case on systems with S3C6410 PoP packages (such as the GT-
i5700 phone). By default OneNAND is handled by proprietary XSR driver 
(including a block mapping layer, called BML and a proprietary FTL called 
STL), about quality of which I will not judge here, but it performs far better 
than the stock OneNAND driver from mainline in terms of speed, but provides 
only a block interface, which makes it incompatible with modern flash 
filesystems like yaffs2 or ubifs.

> The UDC driver actually works most of the time for me, there are a few
> corner cases that require work on for cases where it does not handle
> unexpected events from the hardware. Newer SoCs do not tend to produce
> these cases due to different synthesis options, and thus not all are
> dealt with.

I will send a separate message regarding this topic, but this will happen once 
I receive the Tiny6410 board and check how it looks there.

> > > - no power domain support
> 
> runtime pm should make this easier.

I have already implemented sort of power domain management based on code for 
one from S5P SoCs (from one of Android kernel trees), which defines a voltage 
regulator (with constant voltage) for each power domain and sets of power 
supplies for each driver using each power domain. Runtime PM should get really 
useful on driver side, though.

> > > - no support for advanced features of the chip (ie. functionality
> > > provided by old, and really _bad_, s3c modules)
> 
> old? some of these IP blocks have not changed much since their original
> s3c2400 incarnations. The blocks that have changed have been re-written
> to deal with this.

Yes, I'm aware of that.

> You're really endearing yourself to me by calling s3c modules "really
> _bad_".

To make sure I'm being understood correctly, I'm talking about a set of kernel 
modules provided by Samsung for their original s3c kernels, adding support for 
all the "multimedia" IPs embedded in S3C6410.

> > > I have already added NOHZ support, fixed fb and adc bugs, refactored
> > > control endpoint handling in udc driver (no DMA yet), done some
> > > improvement to OneNAND driver (still a big work in progress though,
> > > this is a topic for another message) and implemented power domain
> > > management + other minor changes/fixes.
> 
> the usb gadget driver already has some of the DMA support code in it,
> but the s3c6410 compilation of that hardware does not do unaligned
> buffers making it difficult to use for most of the current gadget
> drivers.  My view is that bounce-buffers are probably not going to
> help much, so it was never a priority.
> 
> Unfortunately there's not a lot I can do with this driver as I am at the
> limit of the documenation I can currently get my hands on.

It seems like the only problematic gadget would be the ethernet one, at least 
only to this one Samsung had added bounce buffers in their s3c kernel for GT-
i5700, which contained their original USB Gadget driver with DMA (and some 
bugs) enabled. Maybe it really should be refactored to be more DMA friendly?

> Some of this will probably be obsoleted soon anyway due to the massive
> restructuring in arch/arm land.

What exactly do you mean?

> > > All of this is available in my tree at
> > > git://github.com/tom3q/spica-2.6.38.git, but I am going to prepare
> > > patches containing all the changes a bit later, after I rebase all
> > > my work to latest Linux sources, as I worked mostly on Android
> > > 2.6.38 sources.
> 
> Is there a browsable list of changes that you've got?

Nothing complete yet. You might get some idea by looking at 
https://github.com/tom3q/spica-2.6.38/wiki/Status .

Anyway, as written in my last message, I'm going to rebase my work (from 
2.6.38) to latest, clean Linux sources (without Android patches) and then 
format and send the patches here.

Best regards,
Tomasz Figa

Future of S3C6410 platform

[Russell King - ARM Linux]

On Tue, Jul 05, 2011 at 01:10:11AM +0200, Tomasz Figa wrote:
> For me (on GT-i5700) both fb and adc, after leaving the bootloader, end up 
> with unhandled interrupts and calling request_irq leads to kernel crash 
> because an interrupt fires before all driver data get initialized.

We really should have a debug mode for that so developers can find
that stuff really easily.  We already do this for IRQF_SHARED
interrupts, but not !IRQF_SHARED.  Thomas, any opinion?

Future of S3C6410 platform

[Tomasz Figa]

On Tuesday 05 of July 2011 00:25:15 Russell King - ARM Linux wrote:
> On Tue, Jul 05, 2011 at 01:10:11AM +0200, Tomasz Figa wrote:
> > For me (on GT-i5700) both fb and adc, after leaving the bootloader, end
> > up with unhandled interrupts and calling request_irq leads to kernel
> > crash because an interrupt fires before all driver data get
> > initialized.
> 
> We really should have a debug mode for that so developers can find
> that stuff really easily.  We already do this for IRQF_SHARED
> interrupts, but not !IRQF_SHARED.  Thomas, any opinion?

Would it be possible to simulate that in a realistic way? I mean, usually when 
an interrupt fires, the driver checks the detailed cause in hardware 
registers. If we would just simulate an interrupt, wouldn't it just end up 
with finding no interrupt cause, something which shouldn't happen normally 
with "exclusive" interrupts? This also implies that not all code paths would 
be tested with such test case.