Re: Fragmentation of Samsung SoC code (was INPUT][KEYBOARD] Add new keypad driver for s3c series SoCs)

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



2009/9/7 Harald Welte <laforge@xxxxxxxxxxxx>:
> 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.

It's already sent by Joonyoung,

>
>> >> 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

It's because we don't get same base code. LSI works on s3c6410, but we
s3c6410, s5pc100 and s5pc110.
we trying to post the patches related with s3c6410 but it takes long
time to merge to Ben's git.
at that we start the s5pc1xx series works.

Anyway. please let me know which the next patch. touchscreen? or others?

Than we can compare the devices sources and discuss internally and then post it.

>
> 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.

That's reason to send our codes. Now you focus on the s3c6410 but we
already know the s5pc1xx series.
Please consider it at this work. why does it work twice.

>
> 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.
>

with -> without

> 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.
>

I think no problem to send several patch or drivers parallel. If so we
can get more feedbacks.

Thank you,
Kyungmin Park
--
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

[Index of Archives]     [Linux Media Devel]     [Linux USB Devel]     [Video for Linux]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]     [Linux Wireless Networking]     [Linux Omap]

  Powered by Linux