ADC in newer kernel

Got my first mini2440 week ago. In original was one test adc line that
couldn't work when touchscreen is used. This is ok for me, need one sample
of one adc for interval of 10 to 30 second and touchscreen would be used
rarely. 
In kernel that compiled - 2.6.32.11 - there is no /dev/adc. Source code
says: 
mach-mini2440.c:
/*  &s3c_device_adc,*/ /* ADC doesn't like living with touchscreen ! */

And in newest stable kernel 2.6.34 there is not even this commented line
and in changelog says:
    ARM: MINI2440: Remove commented out devices from device array
    
    There's no point in having these in until there is proper support for
    them, so remove as they only confuse the device changing script.
    
    Signed-off-by: Ben Dooks <ben-linux@fluff.org>

What can I do? Comment out that line and hope that it would work, or deal
with direct access to ADC register. In later, would it be suffice to save
current register values, take one sample of adc, and restore registers?

That is not good news.  And Ben is one of the chief development guys.  Even
though the touchscreen uses only 4 of the ADC inputs it appears there are
issues with using the other four.

I don't understand why those other 4 lines could not be accessed, in a
timely manner, especially while there is no touchscreen activity.

There are about 3 threads on ADC related topics going at the moment.  I'll
talk to our ARM9 hardware experts and see if I can extract some useful
information.

The option I am looking at is an external high-speed ADC attached to the
SPI interface.

Related to this, try to use devmem2 to access related memory registers but
it seems that it always return 0x0 for read any of ADC, GPIO and some
random registers. It is stated that devmem2 can read&write any memory
location on ARM boards. Is there limitations on mini2440.

It works. Problem is wrong register address in s3c2440 user manual for ADC
(0x5800000, should be 0x58000000). Now when reading values I got right
values for AIN0 (potentiometer) and some random values for other 3 AINs
(disconnected), but in one of 5-7 readings returned value is 0x0 no matter
what pin is measured.

Has the wrong register address in the s3c2440 user manual worked its way
into driver software?  Or are you suggesting just to be careful if writing
your driver?

the other 3 AINs . . . if the input is left floating then you will get
random values.  Either tie it low or high with, say a 100K or 1M resistor
or enable pull-ups.

The last line?  Are you referring to AINs 4, 5, 6 and 7 which are the
touchscreen inputs?

I hasn't been dealing with driver yet. devmem2 is program for accessing
physical memory from user space. I'll check AIN1-3 in Tuesday, when I would
have access to DC voltage power source.
Sorry for my English, what I mean in last line is that every 5th to 7th
reading any of AIN0-3 gives me 0x0 as result and that looks like an
problem.

I must say, that the touchscreen in my 2.6.33 kernel tree only works, if I
put &s3c_device_adc to the device initializers list and add the original
friendlyarm mini2440 adc driver.

I don't know why it is commented out and marked as not usable by default.
It works fine for me with enabled adc device but the Y-axis is negated (if
I try to move the cursor to top with the touchscreen in Y-direction, it
moves to the bottom and vice versa). But I am sure that it's only a little
part that I have to edit to get it working right ;)

Have all changes for the mini2440 86made by buserror and FriendlyArm
2.6.32.2 worked their way back into the kernel tree?

no they have no  worked "back" into the kernel tree because:

1. "embedded device kernel" & "kernel vanilla" are actually two beasts,
with the vanilla kernel people gradually rolling in the "embedded
community" changes (of which mini2440 is not part)

2. The dirty hacks that have been applied randomly.


The way the " embedded kernel" people work, is that when you want to
support a board:

1. you register to support the board.
2. you follow the rules for kernel development..... (no random dirty
uncommented patches)
3. you keep all your  Shit in your board initialization file related to
YOUR BOARD ONLY, if your "dev.c" is radically different then you make one
for your board.

4. you DO NOT randomly hack other developers code and expect it to be
introduced into the kernel without peer review, and then it  MUST NOT BREAK
any other boards.


if you take a look at various files the "hacks" have been applied but then
tied into existing product boards,  I.E by setting multiple board selected
configurations , and then some "interesting" uses of  "#if/ #ELSE /#endif",
they have applied the patches for the board.

Basically because they don't supply a "DIFF" for what they have done, it
cannot be easily applied to future improvements of the kernel.


so to recap

1. mini 2440 needs to join the  "embedded kernel" community
2. register support for this board (anyone can opt to support a board)
3.  diff files based on the  "Embedded kernel" MUST be produced then peer
reviewed, at which point they are rolled into the " embedded kernel diff"
files , which can be applied to a vanilla kernel.


If you are 'good' and 'well behaved' you can get changes rolled in to the
kernel , within about 2-3 weeks.  (I know  this  because i have done it, i
support a number of boards.)

Currently there are people rolling shit into micro2440  all over the place
, it requires  ONE co-ordinator, who takes all this and  deals with the
"embedded kernel" people

Bob,

Thank you for the explanation about how things should be done.  The only
reason I replied was I was aware that the kernel tree just might not have
changes in it that are required for proper mini2440 functionality.  IE the
<__initdata in struct xyz> issue.

I wasted plenty of time with inconsistencies been different kernel
versions.  I suppose it was a good learning experience.

Being quite new to this embedded Linux business I find making a choice
quite difficult . . . as there is lots to choose from!   

I have had the least trouble with FriendlyArm releases, but unknown to me
there could be problems with those versions as well.

So, the issue becomes how do "we" decide where the "benchmark" kernel
resides and how do "we" find someone with the abilities to maintain it?

we = community of interested users

Dave

The true way to find if a board is supported is to take a look in the
machine defs file.

Each and every serious attempt on supporting a board, ensures the board has
its own reference number, this then ties into the linux kernel to configure
various options related to peripheral allocation and hard I/O

The way that this board has been supported is:

1. they have "hacked" in their own board reference "1999" into a board that
has already been registered , so they have broken board support for the
existing kernel.
2. "someone" has then been into various "kernel"files and done two things
that are completely unacceptable:
1. removed the copyright messages (including author information), and added
in "friendly arm" registration information (the lcd driver file is one
example)
2. hacked various other code files without clearly labeling what and why
they have done it.

The most unacceptable of these is removing the  "licensing" information
from certain linux kernel files.

They DO NOT own this code and this is a blatant example of  source code
mis-appropriation, it is also a serious breach of the linux  source
license.

bob,

Think this should be a new thread, as this information would possibly make
life just a bit easier for others. 

Thank you for taking the time to explain the issues that you see on the, I
assume, 2.6.32.2 release from FriendlyArm (and probably older releases).

For a someone working on their own applications would you recommend that
one should grab a copy of 2.6.34 (stable from kernel.org) and work through
the issues that might remain with using it on the FriendlyArm hardware?

I assume this is where all kernel issues should be resolved:
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Then someone posted a link to:
http://blog.gmane.org/gmane.linux.kernel.samsung-soc

and I was left wondering, where is the real work done?

Is this not the "embedded community" you are talking about?  Or is there
some higher authority?

I have the impression that Russell King is the "top" ARM guy.  You are
suggesting that there needs to be a "top" mini2440 contributor to the
effort?

I'll "put on my manager's hat" (because I am just NOT there technically)
and suggest that you talk to Russell King and maybe Ben Dooks and try to
find out who is going to channel this stuff and report back.

I have no idea of how heavily you are involved in ARM and/or FriendlyArm
development, but you sound like someone who can ask the right questions.

Good luck,
Dave

Just update of my observations. AIN1-3 works ok. When reading results of
any AIN after some short time result register is set to 0 and after that to
some default value. When using program from user space there is slower
execution then execution from kernel space and this is probably reason why
randomly get 0 as result. When using kernel module for reading register
there is no wrong results.

Hi Davef,


1. People should not try to keep chasing the "latest" kernel, I know its
like christmas and everyone wants the latest stuff. But that also includes
the latest bugs.

2.  working on your own app, if it is not "cutting edge" drop back to 
2.6.26 or if you really need to use 2.6.32

3. The "issues" with FA hardware is that currently  everyone is doing their
own thing, the project needs to be in a stage where  :
A. Vanilla kernel +
B.  Arm Kernel mods +
C. FA mods via diff.

Currently it is too easy for people to slip in 'hacks". I can setup a site,
hack the kernel adding some hard to detect network changes giving me access
to all boards connected to the internet, then pass it off as a valid
kernel.
By ensuring  GIT and diffs are used everything becomes transparent, and
SECURE since the code base is already secure for linux.

Russell King , is the guy , but he is very very busy , so he and the other
arm guys have a strict way of working , if it is not followed then you are
ignored, it is not elitist, but a requirement to ensure things run
smoothly.

you do not need to talk to anyone, just follow the rules and you will be
automatically integrated into the system, I.E you  submit your patch
proposals, get sign off, and ...... that is it.

But I can  say straight off that the community  will not tolerate what I
have seen going on in the  currently released  FA code,

1. removal of linux copyright messages
2. Replacing other peoples code with " FA copyrights" and messages.
3. Hacking of current code base , rather than careful integration.

In the past I required a MAJOR change to the USB code for another arm board
support, potentially impacting every arm product on the market, and it was
quite a pleasant experience BUT I did follow the rules.

Yes you need a "co ordinator" for the board, it should be the company
making the board if they are truly committed, but personally I think it is
just a cash mining operation, that said anyone can step up.

first thing is to REGISTER A BOARD number (the key person), so that changes
to the kernel can be correctly isolated using  #if #else #endif.
This would take  less than 10 min. 

It would make it  into the kernel on the next release.
The script is automatic and takes the board registrations and generates the
required kernel files.

All that would be required is the addition of some "boot" code.

Second, clean up of all these stupid patches and irrelevant changes , if FA
want to put their name all over the Kernel, then that is a code patch they
issue as a DIFF on THEIR SITE, NOT by injecting a "fake" code base and
passing it off as a 2.6.32 kernel.
This is WHY i worry about the work JAY is doing , the code base "just
appeared" there is no branching or tracing back to the  "original" kernel,
jay seems to have good intentions but where did he obtain his code base?


I would have acted as a co-ordinator , but there are things going on with
FA that I will not be party to, or even have my "real" name associated
with.

bob,

Further searching around I found a very active Samsung community:
http://blog.gmane.org/gmane.linux.kernel.samsung-soc

while having a number of contributors the chief guy appears to be Ben
Dooks.

Again, thanks for making the process clear to people who would want to
"publish" their own kernel work. 

I now see a tool at http://www.angstrom-distribution.org/narcissus/ which
has the mini2440 in it.  Does this further pollute the pool?

Is community feedback needed to encourage FriendlyArm to go through the
process you describe?

Are all other manufacturer's dev board properly registered?

Dave

P.S.

Just did a search in machine registry and the mini2440 is machine number
1999 and the owner is <capbily>

As per your previous comment:
***
1. they have "hacked" in their own board reference "1999" into a board that
has already been registered , so they have broken board support for the
existing kernel.
***

Does no one supervise the machine registry? I guess these are done under
the goodwill of the manufacturer not to substitute significantly different
hardware once you have an number.  Do different peripherals require a
different board number?

Has capbily got an email address, so that we can "request" that he start
doing his job?

So, where are we right now?
What is the status of reading AIN0-AIN3?

I'm interested to, are there any news?

any news?

I need read 2 chanels, anything?

dear dm9

is it possible to get a copy of that source code please?

maybe you could send me a mail under AlmoNito@gmx.de

Thank you very much