May 2013 - kernelnewbies@kernelnewbies.org - Kernelnewbies Mailing Lists

Bootloader sequence with time prefix
by Dhyan May 24, 2013

May 24, 2013

Dear all, Is there any uboot config option in to print boot sequence with time prefixes similar to kernel option CONFIG_PRINTK ? Thanks & Regards Dhyan

3 6

Re: [I2C] informations + advice about messages handling
by anish singh May 24, 2013

May 24, 2013

On Fri, May 24, 2013 at 1:14 PM, Jean Delvare <khali(a)linux-fr.org> wrote: > Hi Anish, Mylène, > > On Fri, 24 May 2013 12:52:40 +0530, anish singh wrote: >> On Fri, May 24, 2013 at 12:41 PM, Mylene Josserand >> <Mylene.Josserand(a)navocap.com> wrote: >> > I have read that this function "i2c_smbus_write_byte_data" uses >> > "i2c_smbus_xfer" which uses "i2c_lock_adapter". >> > In this function, there is a mutex so I thought that it will handle it >> > but it says "Get exclusive access to an I2C bus segment". What is >> > exactly an I2C segment ? Is it the device we are talking about ? Or is >> > it the use of the i2c bus ? >> Don't know what you are referring here. > > In the most simple case, your I2C bus has a single segment so "segment" > or "bus" mean the same thing. > > It only starts mattering when I2C bus multiplexing comes into play. > Then your bus is split into segments, with one segment (trunk) between > the master (controller) and the multiplexer, and one or more segments > (branches) hanging off the multiplexer. > > Take look at > https://i2c.wiki.kernel.org/index.php/I2C_bus_multiplexing > for a sample topology. > > But anyway the comment in front of i2c_lock_adapter() is somewhat > misleading. If you read the code you'll see that it always locks the > whole bus tree, because it uses the root segment's mutex. > >> > I will certainly have to create an i2c driver and I would like to know >> > if this "collision" handling (if it is handled) is done in old kernel >> > (2.6.32) or is it handled only in new kernel versions ? >> AFAIK collision handling and detection was not supported till now >> in linux kernel until recently but I think this patch is doing that. >> I may be wrong but I didn't see collision handling in earlier linux >> kernels. >> http://thread.gmane.org/gmane.linux.kernel/1410276 > > This is for a specific case. The general case is handled by the > per-adapter mutex for years now. 2.6.32 should be just fine in this > respect. I may be mis-understanding here but when two client wants to communicate with same master and at the same time how does that happen? In the thread I mentioned client pulls the line low indicating that it wants to own the bus and waits for some time and then checks if the line is still low or not.If it is still low then it owns the bus and start transaction and if clients see otherwise it releases the bus and tries again after some time.How is that handled in the previous kernel? > >> > If you have any documentation on how the i2c messages are handled in >> > case of different devices uses, it will help me a lot ! I will search in >> > the kernel documentation but there is many files about i2c. >> > And if you know a good i2c driver that I can use as an example to design >> > mine, it will be great ! > > Best is to look at a driver for a device which is similar in > functionality to yours. > > -- > Jean Delvare

1 0

Re: [I2C] informations + advice about messages handling
by Mylene Josserand May 24, 2013

May 24, 2013

Le 24/05/2013 11:07, Jean Delvare a écrit : > On Fri, 24 May 2013 10:54:11 +0200, Mylene Josserand wrote: >> Ah okay ! And if there are not SMBus compliant, what function I will >> have to use ? > > i2c_transfer() Okay, logic name ;) >> What is it doing if I use this function and that my device is not SMbus >> compliant ? > > This would make no sense. Your device understands only specific message > formats, which should be documented in its datasheet. You have to use > exactly that in your driver. If the message format matches SMBus, you > can use the SMBus API, otherwise you must use i2c_transfer() instead. Very interesting ! Right now, my company uses the "i2c_smbus_read/write_byte_data" functions to talk to devices through an application. On the datasheet of these devices, I search but did not seem to be SMBus compliant. As it was a software which was using these functions, we thought that a driver (that I would write) should be better. And here I am ! I prefer to understand well the mechanism before coding anything and it is interesting ! >> I have some difficulties to understand the differences >> between SMbus and I2C :( > > SMBus is a subset of I2C. With I2C you can have messages of any length > and any format, with no attached semantics. SMBus restricts the > possibilities to a few standardized messages formats with semantics. If > you'd just tell us what your device is, we would be able to tell you if > SMBus will work or if I2C will be needed. Thanks for the explanation. No problem, we have 2 devices used without drivers : - an odometer PIC18F24201 : In the datasheet, there is a SMBus select bit but I don't know if it is SMBus compliant. - an audio codec tlv320aic3204 : There is a driver for this device but for some reasons, we did not use it. Did not find a "SMBus compliant" in its datasheet. >> (...) >> In my case, I have 2 segments but if I understand, the bus will not be >> used at the same time. > > I can't comment on that without knowing the exact topology. In > particular, do you have two independent segments each with its own > controller, or are they interconnected in some way? I2C/SMBus is very > simple with basic topologies but can become difficult with complex ones. Yes of course, I understand. For that, I will ask to our "hardware guy". >> (...) >> Okay. So the mutex blocks the I2C bus. And is it locking the bus at the >> beginning of a message (so when a START is send) and unlocking it after >> the STOP ? > > Yes. > >> So a complete message will be sent to a same device (the one which >> address is in the data frame) ? A device can not receive a beginning of >> one message (so with his address) and the end of another message >> destined to another device [because of "collision"], for example ? > > No, this cannot happen. Thanks a lot for your help ! -- Mylène JOSSERAND

1 0

Re: [I2C] informations + advice about messages handling
by Mylene Josserand May 24, 2013

May 24, 2013

Thanks, both of you, for your answers ! It helps me a lot to understand it ! Le 24/05/2013 09:22, anish singh a écrit : > On Fri, May 24, 2013 at 12:41 PM, Mylene Josserand > <Mylene.Josserand(a)navocap.com> wrote: >> Hi all, >> >> >> I am learning how i2c is working and I read that, to write in an i2c >> register, I need to use the function "i2c_smbus_write_byte_data". > Only in case your device is smbus compliant. Ah okay ! And if there are not SMBus compliant, what function I will have to use ? What is it doing if I use this function and that my device is not SMbus compliant ? I have some difficulties to understand the differences between SMbus and I2C :( Le 24/05/2013 09:44, Jean Delvare a écrit : > Hi Anish, Mylène, > > On Fri, 24 May 2013 12:52:40 +0530, anish singh wrote: >> On Fri, May 24, 2013 at 12:41 PM, Mylene Josserand >> <Mylene.Josserand(a)navocap.com> wrote: >>> I have read that this function "i2c_smbus_write_byte_data" uses >>> "i2c_smbus_xfer" which uses "i2c_lock_adapter". >>> In this function, there is a mutex so I thought that it will handle it >>> but it says "Get exclusive access to an I2C bus segment". What is >>> exactly an I2C segment ? Is it the device we are talking about ? Or is >>> it the use of the i2c bus ? >> Don't know what you are referring here. > > In the most simple case, your I2C bus has a single segment so "segment" > or "bus" mean the same thing. > > It only starts mattering when I2C bus multiplexing comes into play. > Then your bus is split into segments, with one segment (trunk) between > the master (controller) and the multiplexer, and one or more segments > (branches) hanging off the multiplexer. > > Take look at > https://i2c.wiki.kernel.org/index.php/I2C_bus_multiplexing > for a sample topology. > > But anyway the comment in front of i2c_lock_adapter() is somewhat > misleading. If you read the code you'll see that it always locks the > whole bus tree, because it uses the root segment's mutex. Thanks ! I understand now. In my case, I have 2 segments but if I understand, the bus will not be used at the same time. >>> I will certainly have to create an i2c driver and I would like to know >>> if this "collision" handling (if it is handled) is done in old kernel >>> (2.6.32) or is it handled only in new kernel versions ? >> AFAIK collision handling and detection was not supported till now >> in linux kernel until recently but I think this patch is doing that. >> I may be wrong but I didn't see collision handling in earlier linux >> kernels. >> http://thread.gmane.org/gmane.linux.kernel/1410276 > > This is for a specific case. The general case is handled by the > per-adapter mutex for years now. 2.6.32 should be just fine in this > respect. Okay. So the mutex blocks the I2C bus. And is it locking the bus at the beginning of a message (so when a START is send) and unlocking it after the STOP ? So a complete message will be sent to a same device (the one which address is in the data frame) ? A device can not receive a beginning of one message (so with his address) and the end of another message destined to another device [because of "collision"], for example ? >>> If you have any documentation on how the i2c messages are handled in >>> case of different devices uses, it will help me a lot ! I will search in >>> the kernel documentation but there is many files about i2c. >>> And if you know a good i2c driver that I can use as an example to design >>> mine, it will be great ! > > Best is to look at a driver for a device which is similar in > functionality to yours. I will search that, thanks for the advice. -- Mylène JOSSERAND

1 0

[I2C] informations + advice about messages handling
by Mylene Josserand May 24, 2013

May 24, 2013

Hi all, I am learning how i2c is working and I read that, to write in an i2c register, I need to use the function "i2c_smbus_write_byte_data". I wanted to know how the message are handled by using this function. If I use this function to talk with 2 different i2d devices, how it will handle "message collision" ? should I have to add a kind of mutex on the access of the i2c bus ? Is it possible that the message destined for one device is sent to another one ? Or a "mix" of messages is impossible ? I have read that this function "i2c_smbus_write_byte_data" uses "i2c_smbus_xfer" which uses "i2c_lock_adapter". In this function, there is a mutex so I thought that it will handle it but it says "Get exclusive access to an I2C bus segment". What is exactly an I2C segment ? Is it the device we are talking about ? Or is it the use of the i2c bus ? I will certainly have to create an i2c driver and I would like to know if this "collision" handling (if it is handled) is done in old kernel (2.6.32) or is it handled only in new kernel versions ? If you have any documentation on how the i2c messages are handled in case of different devices uses, it will help me a lot ! I will search in the kernel documentation but there is many files about i2c. And if you know a good i2c driver that I can use as an example to design mine, it will be great ! Thank you in advance, -- Mylène JOSSERAND

2 1

android old source code
by Ben Wu May 23, 2013

May 23, 2013

Dear All: I now new to android development, and found andorid4.2 source code is too large, I want study older verison SDK about android such as 1.5 or 1.6. where can i download it ? many thanks

1 0

Reference material for x86-64 assembly on Linux
by amit mehta May 22, 2013

May 22, 2013

Folks, Can you please suggest me some nice books or tutorials that concentrates more on the x86_64 assembly programming using GNU assembler. Unfortunately, I haven't done any assembly programming for the last seven years, but my current job requires me to analyse kernel crashes and a lot of them (probably due to widespread use of x86-64 architecture) originate on x86-64 machines and quite often disassembling is the last resort to inspect the function parameters, stack frames etc. There seem to tons of books, tutorials, assemblers available over the internet, but I'm looking for something that can give me jumpstart on x86_64 assembly, specially in Linux environment. Recently, While browsing, I've found these two: 1: x86_64 ABI (System V Application Binary Interface, AMD64 Architecture Processor Supplement) - 2: x86-64 Machine-Level Programming - Randal and David Appreciate a lot, If you can recommend me your favourite text book on x86-64 assembly or any such reference material. Thanks, -Amit

4 3

Soft CPU Affinity
by Arlie Stephens May 22, 2013

May 22, 2013

Hi Folks, I'm totally failing to come up with the right terms to google, so I'm hoping the collective wisdom of this list can help me once again.... What I'm trying to understand is how the linux kernel decides where to run things, in the absence of calls to explicitly set cpu affinity. Here's the scenario - - 16 core system (not a huge number; not small either) - hard irq that's been assigned to a particular cpu by irqbalance. Let's say it's running on cpu 8. - the hard irq triggers (probably) some kind of softirq activity, which runs ... where? ... [by the looks of it preferentially on cpus 8 and 9] - this results in some task(s) becoming ready to run, which run ... where?... [by the looks of it, preferentially on cpus 8-11] There are NUMA considerations - cpus 0-7 are on one socket, with cpus 8-15 on another. AFAIK, 8 and 9 or 8 and 10 are no "closer" together than 8 and 15. Due to BIOS issues, the kernel does not have a fully accurate picture of the NUMA layout, but it appears to know where the cores are. What I'm looking for is explanations of the design and/or implementation affecting this. It makes sense to me that the kernel would run the soft irq on cpu 8, but why cpu 9? And why wouldn't the user space processes be running on the same cpu where they'd previously been? The system I'm looking at is running an elderly kernel ... RHEL 6.1, aka 2.6.32. But explanations of how this worked/works in any version of linux would be a step forward. Thanks for any pointers, and my apologies for using the list's collective wisdom in place of google, but none of the terms I've tried have given me anything very useful. -- Arlie (Arlie Stephens arlie(a)worldash.org)

1 0

Analyzing Kernel call traces.
by Shraddha Kamat May 18, 2013

May 18, 2013

Any good tutorial for analyzing kernel call traces ? I want to know what is the meaning of everything that appears in the call trace and get to the exact cause of the problem. Thanks for the noble cause of sharing knowledge. Regards, Shraddha

2 1

select call takes more time than the given timeout
by devendra.aaru May 17, 2013

May 17, 2013

Hello, The Select system call has given the timeout of 100 msec and but its expired after 115 msecs. I have no fds to read, and just wanted to use select as the timer to timeout and so some stuff after the timeout happen. code: #include <stdio.h> #include <sys/stat.h> #include <sys/types.h> #include <sys/select.h> main() { int ret; struct timeout tv; tv.tv_sec = 0; tv.tv_usec = 100000; while (1) { ret = select(5, 0, 0, 0, &tv); if (ret == 0) { struct timeval t; gettimeofday(&t, 0); printf("sec = %d-usec = %d\n", t.tv_sec, t.tv_usec); } } } my kernel is older, 2.6.23. thanks,

2 1