Hi Kyungmin, On Mon, Sep 07, 2009 at 03:59:41PM +0900, Kyungmin Park wrote: > > System LSI's kernel tree is on git.kernel.org and updated every night, so you > > (or other interested parties) can stay up-to-date with what is happening. If > > you base your work on top of System LSI's tree, you would always follow their > > work. System LSI's tree is what is scheduled to be submitted to mainline. > > Even though it's working at Samsung SoCs. but it's not mean it fits > the mainline kernel. It's based on SMDK board and focused on SMDK. > > I mean it's not generic. Some codes are hard-coded and don't call > proper frameworks APIs. especially clocks Yes, I agree wity you. Some customers of those SoCs who use Linux also agree :) This is why the System LSI team needs your input based on your experience! They will merge your patches if you send them! They will learn as much from you, as they are from me when I provide feedback. > >> I will post the our works. > > > > I'm not sure if two different Samsung departments posting competing drivers to > > the mainline mailing lists will really help. You need to define which group > > will be the 'master' inside Samsung (the logical choice would be System LSI). > > It's simple. give a choice to customers if there are two versions. you > think it's some duplicated works it's better to others. Don't you think it is weird to see two different Samsung groups duplicating each others work, creating fragmentation and confusion? Each driver will have its own bugs and or problems, and right now neither your driver nor System LSI's driver is in mainline. So rather than continue to try to compete with each other, you need to work together. If you think your code is superior, why not submit your code as patches to System LSI, or even ask System LSI if you can either 1) get commit access to system lsi's git tree or 2) send pull requests to system LSI and ask them to pull from your tree. Everyone has limited resources. System LSI, your team, anyone in the community. The point is that everyone needs to work together. There needs to be a clear definition of the process, i.e. who will work on what, based on which tree. Hwo will submit what mainline, and who will maintain which driver after it has been merged in mainline.. The fragmentation between many different trees with each their own set of drivers (let's say so far: Ben dooks / mainline, your code, System LSI's code) is creating a complexity and maintenance nightmare that nobody can deal with in the long term. I understand that System LSI was probably the root cause of this problem due to their lack of understanding of this process. But this has changed now. It is not "they" vs. "you" vs. "us", it is all of us together. There is too much work to be done. There is 6400,6410,6440,6430,6442,c100,c110 and more products lining up in the future. Many drivers spanning various subsystems. Only if the resources are put together this task can be finished in any reasonable amount of time. The Linux-aware customer wants to grab one tree (preferrably mainline) that has all the drivers/features for all SoCs. He doesn't want to look at 5 different trees, test them, select what he wants and then manually go merging bits and pieces from each of them. > I don't hope just push their codes to mainline with these discussion. Sorry, I don't understand what you're saying here. System LSI is pushing their code for mainline, one patch at a time, like we are seeing with this keypad driver right now. This will generate feedback by the community (including you). System LSI then incorporates that feedback and re-submit an updated version of the driver - just like any other person who submits code to Linux mainline. Regards, -- - Harald Welte <laforge@xxxxxxxxxxxx> http://laforge.gnumonks.org/ ============================================================================ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6) -- To unsubscribe from this list: send the line "unsubscribe linux-input" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
