query regarding the bp24257 battery charger driver
Hi all, I posted the following question to the linux-pm mailing list without a response (I suspect I might possibly have been adding noise to the ML with an off topic question). I hope, someone might be able to shed some light.. I'm working a on a embedded device with the 4.4 branch of the kernel. One of the devices on the board is a BQ24250 charger which is supported by the BQ24257 driver. One thing I've noticed is that the device has a charge enable pin which is not supported by the driver. I'm wondering if this is so because: 1. The original author didn't need to control this line 2. Charge enable functionality doesn't belong in this driver 3. Some other reason Could someone let me know please? Thanks Dushara ___ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
Re: CMA question
Hello, Am 28.02.17 um 11:04 schrieb Thomas Petazzoni: > Hello, > > On Sun, 26 Feb 2017 18:14:42 +0100, Johannes Thoma wrote: > >> As you pointed out the solution would be to allocate the memory earlier in >> the >> boot process, by modifying the driver. I will try that in the next few days >> and >> let you know the result. > > The whole point of CMA is that allocating earlier in the boot process > should not be necessary. CMA guarantees that the memory reserved for > the CMA pool is "movable", i.e it can be discarded when a CMA > allocation is done. > Yes it is moveable, but it takes rather long until it is moved (up to 20 Seconds). To test this I've implemented a loop that restarts from beginning of the CMA area as long as alloc_contig_range() returns -EBUSY (something similar to https://www.mail-archive.com/kernelnewbies@kernelnewbies.org/msg16956.html ). The result (on my system, which is an ARM based IMX-6 SOC) is that after some while it always succeeds but it takes some time. > So if a CMA allocation fails, I would rather suggest that the size of > your CMA pool is not large enough. Check your Device Tree and/or kernel > command (you can specify the size of the CMA pool on both if I remember > correctly). > We use kernel command line to set the CMA size, so I will try as you suggested. Thanks a lot, - Johannes ___ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
Re: want to be a kernel developer
On Fri, Feb 24, 2017 at 1:59 PM, sourav mondal wrote: > hi, > I want to be a kernel developer.I don't really know much about linux kernel. > can anyone suggests me some good books that can help to learn more about the > kernel development? > Books alone won't help. You will need hands on experience. Give http://eudyptula-challenge.org a try. Regards [Himanshu Chauhan] ___ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
Re: CMA question
Hello, On Sun, 26 Feb 2017 18:14:42 +0100, Johannes Thoma wrote: > As you pointed out the solution would be to allocate the memory earlier in the > boot process, by modifying the driver. I will try that in the next few days > and > let you know the result. The whole point of CMA is that allocating earlier in the boot process should not be necessary. CMA guarantees that the memory reserved for the CMA pool is "movable", i.e it can be discarded when a CMA allocation is done. So if a CMA allocation fails, I would rather suggest that the size of your CMA pool is not large enough. Check your Device Tree and/or kernel command (you can specify the size of the CMA pool on both if I remember correctly). Best regarsd, Thomas -- Thomas Petazzoni, CTO, Free Electrons Embedded Linux and Kernel engineering http://free-electrons.com ___ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
Re: staging-testing branch
On Tue, Feb 28, 2017 at 06:26:57AM +0100, Greg KH wrote: > On Tue, Feb 28, 2017 at 11:37:37AM +1100, Tobin C. Harding wrote: > > Greg > > > > Thanks for your unfathomable patience dealing with kernel newbies. I > > have a small suggestion, in a most humble manner. > > > > It seems that when patches don't apply the response is not > > automated, if it is possible within your system to automate checking > > if a patch actually applies would it be beneficial to point the patch > > submitter towards tracking remote branches (i.e are they basing their > > patches on on your staging-testing branch). > > Normally my response is automated, and staging-testing doesn't get > abused like it currently is right now. But we are in the middle of both > the merge window, and the Outreachy intern application process, so it's > a mess. Normally during the merge window I do not touch any patches, so > things back up for 2 weeks. But due to Outreachy happening right now, > that's not very fair to the applicants, so I'm queueing up patches in > staging-testing at the moment to give them a chance to get things > accepted. > > And because I'm taking Outreachy patches, I'm taking all other staging > patches as well, to keep from playing favorites with just that limited > group. > > So, it's messy, and not normal (happens only once a year or so). So you > can just wait another week to do any staging patches, or just live with > the mess for a few more days until my "normal" branches open up :) > > Hope this helps, > > greg k-h Woops, Julia already told me to stop doing small patches until the merge window closed. I must be a slow learner. thanks, Tobin. ___ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
