From: Daniel Walker <hidden> Date: 2011-01-20 20:33:20
This series adds basic Nexus One support which includes a booting
kernel, and functional MMC .
Most people won't be able to use this yet unfortunately because
you need a serial cable to get any output. However, it's a start.
Brian Swetland (1):
[ARM] msm: qsd8k memory base is at 0x20000000
Daniel Walker (6):
msm: qsd8x50: add uart platform data
msm: qsd8x50: add acpuclock code
msm: mahimahi: add mahimahi board file
msm: mahimahi: add in mmc support code
msm: mahimahi: add gpio pin muxing code
msm: mahimahi: initialize mmc at start up
arch/arm/mach-msm/Kconfig | 8 +-
arch/arm/mach-msm/Makefile | 5 +-
arch/arm/mach-msm/Makefile.boot | 5 +
arch/arm/mach-msm/acpuclock-qsd8x50.c | 457 ++++++++++++++++++++++++++++++++
arch/arm/mach-msm/board-mahimahi-mmc.c | 238 +++++++++++++++++
arch/arm/mach-msm/board-mahimahi.c | 52 +++-
arch/arm/mach-msm/board-mahimahi.h | 147 ++++++++++
arch/arm/mach-msm/devices-qsd8x50.c | 42 +++
arch/arm/mach-msm/include/mach/board.h | 1 +
9 files changed, 942 insertions(+), 13 deletions(-)
create mode 100644 arch/arm/mach-msm/acpuclock-qsd8x50.c
create mode 100644 arch/arm/mach-msm/board-mahimahi-mmc.c
create mode 100644 arch/arm/mach-msm/board-mahimahi.h
--
Sent by a consultant of the Qualcomm Innovation Center, Inc.
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum.
From: Daniel Walker <hidden> Date: 2011-01-20 20:33:25
This adds acpuclock-qsd8x50.c from Google. This provides control
over the cpu frequency for qsd8x50 SoCs.
Signed-off-by: Daniel Walker <redacted>
---
arch/arm/mach-msm/Makefile | 3 +-
arch/arm/mach-msm/acpuclock-qsd8x50.c | 457 ++++++++++++++++++++++++++++++++
arch/arm/mach-msm/board-mahimahi.c | 24 ++
arch/arm/mach-msm/include/mach/board.h | 1 +
4 files changed, 484 insertions(+), 1 deletions(-)
create mode 100644 arch/arm/mach-msm/acpuclock-qsd8x50.c
@@ -0,0 +1,457 @@+/*+*Copyright(c)2009Google,Inc.+*Copyright(c)2008QUALCOMMIncorporated.+*+*ThissoftwareislicensedunderthetermsoftheGNUGeneralPublic+*Licenseversion2,aspublishedbytheFreeSoftwareFoundation,and+*maybecopied,distributed,andmodifiedunderthoseterms.+*+*Thisprogramisdistributedinthehopethatitwillbeuseful,+*butWITHOUTANYWARRANTY;withouteventheimpliedwarrantyof+*MERCHANTABILITYorFITNESSFORAPARTICULARPURPOSE.Seethe+*GNUGeneralPublicLicenseformoredetails.+*+*/++#include<linux/kernel.h>+#include<linux/init.h>+#include<linux/io.h>+#include<linux/delay.h>+#include<linux/err.h>+#include<linux/mutex.h>+#include<linux/errno.h>+#include<linux/cpufreq.h>+#include<linux/regulator/consumer.h>++#include<mach/board.h>+#include<mach/msm_iomap.h>++#include"acpuclock.h"+#include"proc_comm.h"++#define SHOT_SWITCH 4+#define HOP_SWITCH 5+#define SIMPLE_SLEW 6+#define COMPLEX_SLEW 7++#define SPSS_CLK_CNTL_ADDR (MSM_CSR_BASE + 0x100)+#define SPSS_CLK_SEL_ADDR (MSM_CSR_BASE + 0x104)++/* Scorpion PLL registers */+#define SCPLL_CTL_ADDR (MSM_SCPLL_BASE + 0x4)+#define SCPLL_STATUS_ADDR (MSM_SCPLL_BASE + 0x18)+#define SCPLL_FSM_CTL_EXT_ADDR (MSM_SCPLL_BASE + 0x10)++structclkctl_acpu_speed{+unsignedacpu_khz;+unsignedclk_cfg;+unsignedclk_sel;+unsignedsc_l_value;+unsignedlpj;+intvdd;+};++/* clock sources */+#define CLK_TCXO 0 /* 19.2 MHz */+#define CLK_GLOBAL_PLL 1 /* 768 MHz */+#define CLK_MODEM_PLL 4 /* 245 MHz (UMTS) or 235.93 MHz (CDMA) */++#define CCTL(src, div) (((src) << 4) | (div - 1))++/* core sources */+#define SRC_RAW 0 /* clock from SPSS_CLK_CNTL */+#define SRC_SCPLL 1 /* output of scpll 128-998 MHZ */+#define SRC_AXI 2 /* 128 MHz */+#define SRC_PLL1 3 /* 768 MHz */++structclkctl_acpu_speedacpu_freq_tbl[]={+{19200,CCTL(CLK_TCXO,1),SRC_RAW,0,0,1050},+{128000,CCTL(CLK_TCXO,1),SRC_AXI,0,0,1050},+{245000,CCTL(CLK_MODEM_PLL,1),SRC_RAW,0,0,1050},+{256000,CCTL(CLK_GLOBAL_PLL,3),SRC_RAW,0,0,1050},+{384000,CCTL(CLK_TCXO,1),SRC_SCPLL,0x0A,0,1050},+{422400,CCTL(CLK_TCXO,1),SRC_SCPLL,0x0B,0,1050},+{460800,CCTL(CLK_TCXO,1),SRC_SCPLL,0x0C,0,1050},+{499200,CCTL(CLK_TCXO,1),SRC_SCPLL,0x0D,0,1075},+{537600,CCTL(CLK_TCXO,1),SRC_SCPLL,0x0E,0,1100},+{576000,CCTL(CLK_TCXO,1),SRC_SCPLL,0x0F,0,1100},+{614400,CCTL(CLK_TCXO,1),SRC_SCPLL,0x10,0,1125},+{652800,CCTL(CLK_TCXO,1),SRC_SCPLL,0x11,0,1150},+{691200,CCTL(CLK_TCXO,1),SRC_SCPLL,0x12,0,1175},+{729600,CCTL(CLK_TCXO,1),SRC_SCPLL,0x13,0,1200},+{768000,CCTL(CLK_TCXO,1),SRC_SCPLL,0x14,0,1200},+{806400,CCTL(CLK_TCXO,1),SRC_SCPLL,0x15,0,1225},+{844800,CCTL(CLK_TCXO,1),SRC_SCPLL,0x16,0,1250},+{883200,CCTL(CLK_TCXO,1),SRC_SCPLL,0x17,0,1275},+{921600,CCTL(CLK_TCXO,1),SRC_SCPLL,0x18,0,1275},+{960000,CCTL(CLK_TCXO,1),SRC_SCPLL,0x19,0,1275},+{998400,CCTL(CLK_TCXO,1),SRC_SCPLL,0x1A,0,1275},+{0},+};++/* select the standby clock that is used when switching scpll+*frequencies+*+*Currently:MPLL+*/+structclkctl_acpu_speed*acpu_stby=&acpu_freq_tbl[2];+#define IS_ACPU_STANDBY(x) (((x)->clk_cfg == acpu_stby->clk_cfg) && \+((x)->clk_sel==acpu_stby->clk_sel))++structclkctl_acpu_speed*acpu_mpll=&acpu_freq_tbl[2];++#ifdef CONFIG_CPU_FREQ_TABLE+staticstructcpufreq_frequency_tablefreq_table[ARRAY_SIZE(acpu_freq_tbl)];++staticvoid__initacpuclk_init_cpufreq_table(void)+{+inti;+intvdd;+for(i=0;acpu_freq_tbl[i].acpu_khz;i++){+freq_table[i].index=i;+freq_table[i].frequency=CPUFREQ_ENTRY_INVALID;++/* Skip speeds using the global pll */+if(acpu_freq_tbl[i].acpu_khz==256000||+acpu_freq_tbl[i].acpu_khz==19200)+continue;++vdd=acpu_freq_tbl[i].vdd;+/* Allow mpll and the first scpll speeds */+if(acpu_freq_tbl[i].acpu_khz==acpu_mpll->acpu_khz||+acpu_freq_tbl[i].acpu_khz==384000){+freq_table[i].frequency=acpu_freq_tbl[i].acpu_khz;+continue;+}++/* Take the fastest speed available at the specified VDD level */+if(vdd!=acpu_freq_tbl[i+1].vdd)+freq_table[i].frequency=acpu_freq_tbl[i].acpu_khz;+}++freq_table[i].index=i;+freq_table[i].frequency=CPUFREQ_TABLE_END;++cpufreq_frequency_table_get_attr(freq_table,smp_processor_id());+}+#else+#define acpuclk_init_cpufreq_table() do {} while (0);+#endif++structclock_state{+structclkctl_acpu_speed*current_speed;+structmutexlock;+uint32_tacpu_switch_time_us;+uint32_tmax_speed_delta_khz;+uint32_tvdd_switch_time_us;+unsignedlongpower_collapse_khz;+unsignedlongwait_for_irq_khz;+structregulator*regulator;+};++staticstructclock_statedrv_state={0};++staticDEFINE_SPINLOCK(acpu_lock);++#define PLLMODE_POWERDOWN 0+#define PLLMODE_BYPASS 1+#define PLLMODE_STANDBY 2+#define PLLMODE_FULL_CAL 4+#define PLLMODE_HALF_CAL 5+#define PLLMODE_STEP_CAL 6+#define PLLMODE_NORMAL 7+#define PLLMODE_MASK 7++staticvoidscpll_power_down(void)+{+uint32_tval;++/* Wait for any frequency switches to finish. */+while(readl(SCPLL_STATUS_ADDR)&0x1)+;++/* put the pll in standby mode */+val=readl(SCPLL_CTL_ADDR);+val=(val&(~PLLMODE_MASK))|PLLMODE_STANDBY;+writel(val,SCPLL_CTL_ADDR);+dmb();++/* wait to stabilize in standby mode */+udelay(10);++val=(val&(~PLLMODE_MASK))|PLLMODE_POWERDOWN;+writel(val,SCPLL_CTL_ADDR);+dmb();+}++staticvoidscpll_set_freq(uint32_tlval)+{+uint32_tval,ctl;++if(lval>33)+lval=33;+if(lval<10)+lval=10;++/* wait for any calibrations or frequency switches to finish */+while(readl(SCPLL_STATUS_ADDR)&0x3)+;++ctl=readl(SCPLL_CTL_ADDR);++if((ctl&PLLMODE_MASK)!=PLLMODE_NORMAL){+/* put the pll in standby mode */+writel((ctl&(~PLLMODE_MASK))|PLLMODE_STANDBY,SCPLL_CTL_ADDR);+dmb();++/* wait to stabilize in standby mode */+udelay(10);++/* switch to 384 MHz */+val=readl(SCPLL_FSM_CTL_EXT_ADDR);+val=(val&(~0x1FF))|(0x0A<<3)|SHOT_SWITCH;+writel(val,SCPLL_FSM_CTL_EXT_ADDR);+dmb();++ctl=readl(SCPLL_CTL_ADDR);+writel(ctl|PLLMODE_NORMAL,SCPLL_CTL_ADDR);+dmb();++/* wait for frequency switch to finish */+while(readl(SCPLL_STATUS_ADDR)&0x1)+;++/* completion bit is not reliable for SHOT switch */+udelay(25);+}++/* write the new L val and switch mode */+val=readl(SCPLL_FSM_CTL_EXT_ADDR);+val=(val&(~0x1FF))|(lval<<3)|HOP_SWITCH;+writel(val,SCPLL_FSM_CTL_EXT_ADDR);+dmb();++ctl=readl(SCPLL_CTL_ADDR);+writel(ctl|PLLMODE_NORMAL,SCPLL_CTL_ADDR);+dmb();++/* wait for frequency switch to finish */+while(readl(SCPLL_STATUS_ADDR)&0x1)+;+}++/* this is still a bit weird... */+staticvoidselect_clock(unsignedsrc,unsignedconfig)+{+uint32_tval;++if(src==SRC_RAW){+uint32_tsel=readl(SPSS_CLK_SEL_ADDR);+unsignedshift=(sel&1)?8:0;++/* set other clock source to the new configuration */+val=readl(SPSS_CLK_CNTL_ADDR);+val=(val&(~(0x7F<<shift)))|(config<<shift);+writel(val,SPSS_CLK_CNTL_ADDR);++/* switch to other clock source */+writel(sel^1,SPSS_CLK_SEL_ADDR);++dmb();/* necessary? */+}++/* switch to new source */+val=readl(SPSS_CLK_SEL_ADDR)&(~6);+writel(val|((src&3)<<1),SPSS_CLK_SEL_ADDR);+}++staticintacpuclk_set_vdd_level(intvdd)+{+if(!drv_state.regulator||IS_ERR(drv_state.regulator)){+drv_state.regulator=regulator_get(NULL,"acpu_vcore");+if(IS_ERR(drv_state.regulator)){+pr_info("acpuclk_set_vdd_level %d no regulator\n",vdd);+/* Assume that the PMIC supports scaling the processor+*toitsmaximumfrequency@itsdefaultvoltage.+*/+return0;+}+pr_info("acpuclk_set_vdd_level got regulator\n");+}+vdd*=1000;/* mV -> uV */+returnregulator_set_voltage(drv_state.regulator,vdd,vdd);+}++intacpuclk_set_rate(unsignedlongrate,intfor_power_collapse)+{+structclkctl_acpu_speed*cur,*next;+unsignedlongflags;++cur=drv_state.current_speed;++/* convert to KHz */+rate/=1000;++pr_debug("acpuclk_set_rate(%d,%d)\n",(int)rate,for_power_collapse);++if(rate==0||rate==cur->acpu_khz)+return0;++next=acpu_freq_tbl;+for(;;){+if(next->acpu_khz==rate)+break;+if(next->acpu_khz==0)+return-EINVAL;+next++;+}++if(!for_power_collapse){+mutex_lock(&drv_state.lock);+/* Increase VDD if needed. */+if(next->vdd>cur->vdd){+if(acpuclk_set_vdd_level(next->vdd)){+pr_err("acpuclock: Unable to increase ACPU VDD.\n");+mutex_unlock(&drv_state.lock);+return-EINVAL;+}+}+}++spin_lock_irqsave(&acpu_lock,flags);++pr_debug("sel=%d cfg=%02x lv=%02x -> sel=%d, cfg=%02x lv=%02x\n",+cur->clk_sel,cur->clk_cfg,cur->sc_l_value,+next->clk_sel,next->clk_cfg,next->sc_l_value);++if(next->clk_sel==SRC_SCPLL){+if(!IS_ACPU_STANDBY(cur))+select_clock(acpu_stby->clk_sel,acpu_stby->clk_cfg);+loops_per_jiffy=next->lpj;+scpll_set_freq(next->sc_l_value);+select_clock(SRC_SCPLL,0);+}else{+loops_per_jiffy=next->lpj;+if(cur->clk_sel==SRC_SCPLL){+select_clock(acpu_stby->clk_sel,acpu_stby->clk_cfg);+select_clock(next->clk_sel,next->clk_cfg);+scpll_power_down();+}else{+select_clock(next->clk_sel,next->clk_cfg);+}+}++drv_state.current_speed=next;++spin_unlock_irqrestore(&acpu_lock,flags);+if(!for_power_collapse){+/* Drop VDD level if we can. */+if(next->vdd<cur->vdd){+if(acpuclk_set_vdd_level(next->vdd))+pr_err("acpuclock: Unable to drop ACPU VDD.\n");+}+mutex_unlock(&drv_state.lock);+}++return0;+}++staticunsigned__initacpuclk_find_speed(void)+{+uint32_tsel,val;++sel=readl(SPSS_CLK_SEL_ADDR);+switch((sel&6)>>1){+case1:+val=readl(SCPLL_FSM_CTL_EXT_ADDR);+val=(val>>3)&0x3f;+returnval*38400;+case2:+return128000;+default:+pr_err("acpu_find_speed: failed\n");+BUG();+return0;+}+}++#define PCOM_MODEM_PLL 0+staticintpll_request(unsignedid,unsignedon)+{+on=!!on;+returnmsm_proc_comm(PCOM_CLKCTL_RPC_PLL_REQUEST,&id,&on);+}++staticvoid__initacpuclk_init(void)+{+structclkctl_acpu_speed*speed;+unsignedinit_khz;++init_khz=acpuclk_find_speed();++/* request the modem pll, and then drop it. We don't want to keep a+*reftoit,butwedowanttomakesurethatitisinitializedat+*thispoint.TheARM9willensurethattheMPLLisalwayson+*onceitisfullybooted,butitmaynotbeupbythetimeweget+*tohere.So,ourpll_requestforitwillblockuntilthempllis+*actuallyup.Wewantitupbecausewewillwanttouseitasa+*temporarystepduringfrequencyscaling.*/+pll_request(PCOM_MODEM_PLL,1);+pll_request(PCOM_MODEM_PLL,0);++if(!(readl(MSM_CLK_CTL_BASE+0x300)&1)){+pr_err("%s: MPLL IS NOT ON!!! RUN AWAY!!\n",__func__);+BUG();+}++/* Move to 768MHz for boot, which is a safe frequency+*forallversionsofScorpionatthemoment.+*/+speed=acpu_freq_tbl;+for(;;){+if(speed->acpu_khz==768000)+break;+if(speed->acpu_khz==0){+pr_err("acpuclk_init: cannot find 768MHz\n");+BUG();+}+speed++;+}++if(init_khz!=speed->acpu_khz){+/* Bootloader needs to have SCPLL operating, but we're+*goingtostepovertothestandbyclockandmakesure+*weselecttherightfrequencyonSCPLLandthen+*stepbacktoit,tomakesurewe'resanehere.+*/+select_clock(acpu_stby->clk_sel,acpu_stby->clk_cfg);+scpll_power_down();+scpll_set_freq(speed->sc_l_value);+select_clock(SRC_SCPLL,0);+}+drv_state.current_speed=speed;++for(speed=acpu_freq_tbl;speed->acpu_khz;speed++)+speed->lpj=cpufreq_scale(loops_per_jiffy,+init_khz,speed->acpu_khz);++loops_per_jiffy=drv_state.current_speed->lpj;+}++void__initmsm_acpu_clock_init(structmsm_acpu_clock_platform_data*clkdata)+{+spin_lock_init(&acpu_lock);+mutex_init(&drv_state.lock);++drv_state.acpu_switch_time_us=clkdata->acpu_switch_time_us;+drv_state.max_speed_delta_khz=clkdata->max_speed_delta_khz;+drv_state.vdd_switch_time_us=clkdata->vdd_switch_time_us;+drv_state.power_collapse_khz=clkdata->power_collapse_khz;+drv_state.wait_for_irq_khz=clkdata->wait_for_irq_khz;++if(clkdata->mpll_khz)+acpu_mpll->acpu_khz=clkdata->mpll_khz;++acpuclk_init();+acpuclk_init_cpufreq_table();+}
@@ -1,3 +1,8 @@zreladdr-y:=0x10008000params_phys-y:=0x10000100initrd_phys-y:=0x10800000++# for now, override for QSD8x50+zreladdr-$(CONFIG_ARCH_QSD8X50):=0x20008000+params_phys-$(CONFIG_ARCH_QSD8X50):=0x20000100+initrd_phys-$(CONFIG_ARCH_QSD8X50):=0x21000000
--
1.7.0.4
--
Sent by a consultant of the Qualcomm Innovation Center, Inc.
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum.
From: Daniel Walker <hidden> Date: 2011-01-20 20:33:28
This adds basic boot support for Nexus One (aka Mahimahi).
This code was taken from Google's tree, with slight modifications
and clean up.
Signed-off-by: Daniel Walker <redacted>
---
arch/arm/mach-msm/Kconfig | 8 ++-
arch/arm/mach-msm/Makefile | 1 +
arch/arm/mach-msm/board-mahimahi.c | 20 ++---
arch/arm/mach-msm/board-mahimahi.h | 147 ++++++++++++++++++++++++++++++++++++
4 files changed, 164 insertions(+), 12 deletions(-)
create mode 100644 arch/arm/mach-msm/board-mahimahi.h
From: Daniel Walker <hidden> Date: 2011-01-20 20:33:56
MMC should fully function at this point. This adds in the calls
to start the initialization.
Signed-off-by: Daniel Walker <redacted>
---
arch/arm/mach-msm/board-mahimahi.c | 8 ++++++++
1 files changed, 8 insertions(+), 0 deletions(-)
From: Daniel Walker <hidden> Date: 2011-01-20 20:33:57
Add in old style pin muxing code. This code is from Google's
tree. However, the other way to do this is to use gpiomux, but
it's currently not mature enough to have on/off configurations.
This code was taken from Google's tree, with slight modifications
and clean up.
Signed-off-by: Daniel Walker <redacted>
---
arch/arm/mach-msm/board-mahimahi-mmc.c | 32 ++++++++++++++++++++++++++++++++
1 files changed, 32 insertions(+), 0 deletions(-)
From: Daniel Walker <hidden> Date: 2011-01-20 20:34:25
This adds code to enable MMC on mahimahi.
This code was taken from Google's tree, with slight modifications
and clean up.
Signed-off-by: Daniel Walker <redacted>
---
arch/arm/mach-msm/Makefile | 1 +
arch/arm/mach-msm/board-mahimahi-mmc.c | 206 ++++++++++++++++++++++++++++++++
2 files changed, 207 insertions(+), 0 deletions(-)
create mode 100644 arch/arm/mach-msm/board-mahimahi-mmc.c
@@ -0,0 +1,206 @@+/* linux/arch/arm/mach-msm/board-mahimahi-mmc.c+*+*Copyright(C)2009Google,Inc.+*Copyright(C)2009HTCCorporation+*+*ThissoftwareislicensedunderthetermsoftheGNUGeneralPublic+*Licenseversion2,aspublishedbytheFreeSoftwareFoundation,and+*maybecopied,distributed,andmodifiedunderthoseterms.+*+*Thisprogramisdistributedinthehopethatitwillbeuseful,+*butWITHOUTANYWARRANTY;withouteventheimpliedwarrantyof+*MERCHANTABILITYorFITNESSFORAPARTICULARPURPOSE.Seethe+*GNUGeneralPublicLicenseformoredetails.+*+*/++#define pr_fmt(fmt) "%s: " fmt, __func__++#include<linux/delay.h>+#include<linux/debugfs.h>+#include<linux/err.h>+#include<linux/init.h>+#include<linux/kernel.h>+#include<linux/mmc/host.h>+#include<linux/mmc/sdio_ids.h>+#include<linux/platform_device.h>++#include<asm/gpio.h>+#include<asm/io.h>+#include<asm/mach-types.h>+#include<mach/mmc.h>++#include<mach/vreg.h>++#include"board-mahimahi.h"+#include"devices.h"+#include"proc_comm.h"++staticboolopt_disable_sdcard;+staticint__initmahimahi_disablesdcard_setup(char*str)+{+opt_disable_sdcard=(bool)simple_strtol(str,NULL,0);+return1;+}++__setup("board_mahimahi.disable_sdcard=",mahimahi_disablesdcard_setup);++staticstructmsm_mmc_gpiosdc1_gpio_cfg[]={+{62,"sdc1_clk"},+{63,"sdc1_cmd"},+{64,"sdc1_dat_3"},+{65,"sdc1_dat_2"},+{66,"sdc1_dat_1"},+{67,"sdc1_dat_0"},+};++staticstructvreg*sdslot_vreg;+staticuint32_tsdslot_vdd=0xffffffff;+staticuint32_tsdslot_vreg_enabled;++staticstruct{+intmask;+intlevel;+}mmc_vdd_table[]={+{MMC_VDD_165_195,1800},+{MMC_VDD_20_21,2050},+{MMC_VDD_21_22,2150},+{MMC_VDD_22_23,2250},+{MMC_VDD_23_24,2350},+{MMC_VDD_24_25,2450},+{MMC_VDD_25_26,2550},+{MMC_VDD_26_27,2650},+{MMC_VDD_27_28,2750},+{MMC_VDD_28_29,2850},+{MMC_VDD_29_30,2950},+};++staticuint32_tmahimahi_sdslot_switchvdd(structdevice*dev,unsignedintvdd)+{+inti;+intret;++if(vdd==sdslot_vdd)+return0;++sdslot_vdd=vdd;++if(vdd==0){+vreg_disable(sdslot_vreg);+sdslot_vreg_enabled=0;+return0;+}++if(!sdslot_vreg_enabled){+ret=vreg_enable(sdslot_vreg);+if(ret)+pr_err("Error enabling vreg (%d)\n",ret);+sdslot_vreg_enabled=1;+}++for(i=0;i<ARRAY_SIZE(mmc_vdd_table);i++){+if(mmc_vdd_table[i].mask!=(1<<vdd))+continue;+ret=vreg_set_level(sdslot_vreg,mmc_vdd_table[i].level);+if(ret)+pr_err("Error setting level (%d)\n",ret);+return0;+}++pr_err("Invalid VDD (%d) specified\n",vdd);+return0;+}++staticuint32_t+mahimahi_cdma_sdslot_switchvdd(structdevice*dev,unsignedintvdd)+{+if(!vdd==!sdslot_vdd)+return0;++/* In CDMA version, the vdd of sdslot is not configurable, and it is+*fixedin2.85Vbyhardwaredesign.+*/++sdslot_vdd=vdd?MMC_VDD_28_29:0;++if(vdd)+gpio_set_value(MAHIMAHI_CDMA_SD_2V85_EN,1);+else+gpio_set_value(MAHIMAHI_CDMA_SD_2V85_EN,0);++sdslot_vreg_enabled=!!vdd;++return0;+}++staticunsignedintmahimahi_sdslot_status_rev0(structdevice*dev)+{+return!gpio_get_value(MAHIMAHI_GPIO_SDMC_CD_REV0_N);+}++#define MAHIMAHI_MMC_VDD (MMC_VDD_165_195 | MMC_VDD_20_21 | \+MMC_VDD_21_22|MMC_VDD_22_23|\+MMC_VDD_23_24|MMC_VDD_24_25|\+MMC_VDD_25_26|MMC_VDD_26_27|\+MMC_VDD_27_28|MMC_VDD_28_29|\+MMC_VDD_29_30)++staticstructmsm_mmc_gpio_datasdc1_gpio=+.gpio=sdc1_gpio_cfg,+.size=ARRAY_SIZE(sdc1_gpio_cfg),+};++staticstructmsm_mmc_platform_datamahimahi_sdslot_data={+.ocr_mask=MAHIMAHI_MMC_VDD,+.translate_vdd=mahimahi_sdslot_switchvdd,+.gpio_data=&sdc1_gpio,+};++intmsm_add_sdcc(unsignedintcontroller,structmsm_mmc_platform_data*plat,+unsignedintstat_irq,unsignedlongstat_irq_flags);++int__initmahimahi_init_mmc(unsignedintsys_rev,unsigneddebug_uart)+{+uint32_tid;++if(debug_uart){+pr_info("%s: sdcard disabled due to debug uart\n",__func__);+gotodone;+}+if(opt_disable_sdcard){+pr_info("%s: sdcard disabled on cmdline\n",__func__);+gotodone;+}++sdslot_vreg_enabled=0;++if(is_cdma_version(sys_rev)){+/* In the CDMA version, sdslot is supplied by a gpio. */+intrc=gpio_request(MAHIMAHI_CDMA_SD_2V85_EN,"sdslot_en");+if(rc<0){+pr_err("%s: gpio_request(%d) failed: %d\n",__func__,+MAHIMAHI_CDMA_SD_2V85_EN,rc);+returnrc;+}+mahimahi_sdslot_data.translate_vdd=mahimahi_cdma_sdslot_switchvdd;+}else{+/* in UMTS version, sdslot is supplied by pmic */+sdslot_vreg=vreg_get(0,"gp6");+if(IS_ERR(sdslot_vreg))+returnPTR_ERR(sdslot_vreg);+}++if(system_rev>0)+msm_add_sdcc(2,&mahimahi_sdslot_data,0,0);+else{+mahimahi_sdslot_data.status=mahimahi_sdslot_status_rev0;+mahimahi_sdslot_data.register_status_notify=NULL;+set_irq_wake(MSM_GPIO_TO_INT(MAHIMAHI_GPIO_SDMC_CD_REV0_N),1);+msm_add_sdcc(2,&mahimahi_sdslot_data,+MSM_GPIO_TO_INT(MAHIMAHI_GPIO_SDMC_CD_REV0_N),+IORESOURCE_IRQ_LOWEDGE|IORESOURCE_IRQ_HIGHEDGE);+}++done:+return0;+}
--
1.7.0.4
--
Sent by a consultant of the Qualcomm Innovation Center, Inc.
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum.
You are not the author of any of these patches. Where are the author
attributions for the team that actually wrote this code?
--Dima
On Thu, Jan 20, 2011 at 12:32 PM, Daniel Walker [off-list ref] wrote:
This series adds basic Nexus One support which includes a booting
kernel, and functional MMC .
Most people won't be able to use this yet unfortunately because
you need a serial cable to get any output. However, it's a start.
Brian Swetland (1):
?[ARM] msm: qsd8k memory base is at 0x20000000
Daniel Walker (6):
?msm: qsd8x50: add uart platform data
?msm: qsd8x50: add acpuclock code
?msm: mahimahi: add mahimahi board file
?msm: mahimahi: add in mmc support code
?msm: mahimahi: add gpio pin muxing code
?msm: mahimahi: initialize mmc at start up
?arch/arm/mach-msm/Kconfig ? ? ? ? ? ? ?| ? ?8 +-
?arch/arm/mach-msm/Makefile ? ? ? ? ? ? | ? ?5 +-
?arch/arm/mach-msm/Makefile.boot ? ? ? ?| ? ?5 +
?arch/arm/mach-msm/acpuclock-qsd8x50.c ?| ?457 ++++++++++++++++++++++++++++++++
?arch/arm/mach-msm/board-mahimahi-mmc.c | ?238 +++++++++++++++++
?arch/arm/mach-msm/board-mahimahi.c ? ? | ? 52 +++-
?arch/arm/mach-msm/board-mahimahi.h ? ? | ?147 ++++++++++
?arch/arm/mach-msm/devices-qsd8x50.c ? ?| ? 42 +++
?arch/arm/mach-msm/include/mach/board.h | ? ?1 +
?9 files changed, 942 insertions(+), 13 deletions(-)
?create mode 100644 arch/arm/mach-msm/acpuclock-qsd8x50.c
?create mode 100644 arch/arm/mach-msm/board-mahimahi-mmc.c
?create mode 100644 arch/arm/mach-msm/board-mahimahi.h
--
Sent by a consultant of the Qualcomm Innovation Center, Inc.
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo at vger.kernel.org
More majordomo info at ?http://vger.kernel.org/majordomo-info.html
Please read the FAQ at ?http://www.tux.org/lkml/
From: Daniel Walker <hidden> Date: 2011-01-21 00:56:01
On Thu, 2011-01-20 at 16:42 -0800, Dima Zavin wrote:
You are not the author of any of these patches. Where are the author
attributions for the team that actually wrote this code?
In the commit text.. The author field is used to denote who authored the
commit, which in this case is me. The code holds Google copyrights which
means all or parts are actually owned by Google ..
Daniel
--
Sent by an consultant of the Qualcomm Innovation Center, Inc.
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora
Forum.
From: Joe Perches <joe@perches.com> Date: 2011-01-21 01:41:27
On Thu, 2011-01-20 at 16:55 -0800, Daniel Walker wrote:
On Thu, 2011-01-20 at 16:42 -0800, Dima Zavin wrote:
quoted
You are not the author of any of these patches. Where are the author
attributions for the team that actually wrote this code?
In the commit text.. The author field is used to denote who authored the
commit, which in this case is me.
You have that wrong.
Author and Committer are different git fields.
http://www.kernel.org/pub/software/scm/git/docs/user-manual.html
* an author: The name of the person responsible for this change,
together with its date.
* a committer: The name of the person who actually created the
commit, with the date it was done. This may be different from
the author, for example, if the author was someone who wrote a
patch and emailed it to the person who used it to create the
commit.
From: Daniel Walker <hidden> Date: 2011-01-21 01:58:44
On Thu, 2011-01-20 at 17:41 -0800, Joe Perches wrote:
On Thu, 2011-01-20 at 16:55 -0800, Daniel Walker wrote:
quoted
On Thu, 2011-01-20 at 16:42 -0800, Dima Zavin wrote:
quoted
You are not the author of any of these patches. Where are the author
attributions for the team that actually wrote this code?
In the commit text.. The author field is used to denote who authored the
commit, which in this case is me.
You have that wrong.
Author and Committer are different git fields.
http://www.kernel.org/pub/software/scm/git/docs/user-manual.html
* an author: The name of the person responsible for this change,
together with its date.
* a committer: The name of the person who actually created the
commit, with the date it was done. This may be different from
the author, for example, if the author was someone who wrote a
patch and emailed it to the person who used it to create the
commit.
I'm not even sure how to make these different, but in this case it
doesn't matter because the "committer" as you defined it above is more
than one person ..
Daniel
--
Sent by an consultant of the Qualcomm Innovation Center, Inc.
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora
Forum.
You did not write ANY code for the mahimahi (Nexus One) board. You
took patches from the android.git.kernel.org git server, squashed some
together, and then slapped your name on them as the author. I
appreciate your effort to send this code upstream and do whatever
minor cleanups, but I still maintain that you are not the author of
this code.
--Dima
On Thu, Jan 20, 2011 at 5:58 PM, Daniel Walker [off-list ref] wrote:
On Thu, 2011-01-20 at 17:41 -0800, Joe Perches wrote:
quoted
On Thu, 2011-01-20 at 16:55 -0800, Daniel Walker wrote:
quoted
On Thu, 2011-01-20 at 16:42 -0800, Dima Zavin wrote:
quoted
You are not the author of any of these patches. Where are the author
attributions for the team that actually wrote this code?
In the commit text.. The author field is used to denote who authored the
commit, which in this case is me.
You have that wrong.
Author and Committer are different git fields.
http://www.kernel.org/pub/software/scm/git/docs/user-manual.html
? ? ? * an author: The name of the person responsible for this change,
? ? ? ? together with its date.
? ? ? * a committer: The name of the person who actually created the
? ? ? ? commit, with the date it was done. This may be different from
? ? ? ? the author, for example, if the author was someone who wrote a
? ? ? ? patch and emailed it to the person who used it to create the
? ? ? ? commit.
I'm not even sure how to make these different, but in this case it
doesn't matter because the "committer" as you defined it above is more
than one person ..
Daniel
--
Sent by an consultant of the Qualcomm Innovation Center, Inc.
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora
Forum.
From: Daniel Walker <hidden> Date: 2011-01-21 15:47:42
On Thu, 2011-01-20 at 18:13 -0800, Dima Zavin wrote:
You did not write ANY code for the mahimahi (Nexus One) board. You
took patches from the android.git.kernel.org git server, squashed some
together, and then slapped your name on them as the author. I
appreciate your effort to send this code upstream and do whatever
minor cleanups, but I still maintain that you are not the author of
this code.
I'm not claiming I wrote it all, clearly the copyrights indicate that.
Daniel
--
Sent by an consultant of the Qualcomm Innovation Center, Inc.
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora
Forum.
From: Joe Perches <joe@perches.com> Date: 2011-01-21 02:25:34
On Thu, 2011-01-20 at 17:58 -0800, Daniel Walker wrote:
On Thu, 2011-01-20 at 17:41 -0800, Joe Perches wrote:
quoted
On Thu, 2011-01-20 at 16:55 -0800, Daniel Walker wrote:
quoted
On Thu, 2011-01-20 at 16:42 -0800, Dima Zavin wrote:
quoted
You are not the author of any of these patches. Where are the author
attributions for the team that actually wrote this code?
In the commit text.. The author field is used to denote who authored the
commit, which in this case is me.
You have that wrong.
Author and Committer are different git fields.
http://www.kernel.org/pub/software/scm/git/docs/user-manual.html
* an author: The name of the person responsible for this change,
together with its date.
* a committer: The name of the person who actually created the
commit, with the date it was done. This may be different from
the author, for example, if the author was someone who wrote a
patch and emailed it to the person who used it to create the
commit.
I'm not even sure how to make these different, but in this case it
doesn't matter because the "committer" as you defined it above is more
than one person ..
Not really, no.
The authors may be different, but the first git
committer of the patch is different.
The committer is the person that does a git commit
either directly with git commit or git am.
If a git tree is pulled by someone else, the initial
committer name remains on the commit.
You should keep the original patch author names and
add your own "Signed-off-by:" and not claim authorship
of the patches themselves.
cheers, Joe
The authors may be different, but the first git
committer of the patch is different.
The committer is the person that does a git commit
either directly with git commit or git am.
You should keep the original patch author names and
add your own "Signed-off-by:" and not claim authorship
of the patches themselves.
For example, many people send me patches for the ext4 tree.
Even if I get the patches from somewhere else, say the SuSE RPM, I will try to determine the author, and use that as the author field in the patches. If I put a
From: The Original Author <redacted>
in the patch before I suck it in using git am, it will use the original author in the Author field. I will add my Signed-off-by, preserving the other Signed-off-by's, and my name will appear in the Committer field, which is as it should be.
-- Ted
From: Daniel Walker <hidden> Date: 2011-01-21 15:46:50
On Thu, 2011-01-20 at 18:25 -0800, Joe Perches wrote:
On Thu, 2011-01-20 at 17:58 -0800, Daniel Walker wrote:
quoted
On Thu, 2011-01-20 at 17:41 -0800, Joe Perches wrote:
quoted
On Thu, 2011-01-20 at 16:55 -0800, Daniel Walker wrote:
quoted
On Thu, 2011-01-20 at 16:42 -0800, Dima Zavin wrote:
quoted
You are not the author of any of these patches. Where are the author
attributions for the team that actually wrote this code?
In the commit text.. The author field is used to denote who authored the
commit, which in this case is me.
You have that wrong.
Author and Committer are different git fields.
http://www.kernel.org/pub/software/scm/git/docs/user-manual.html
* an author: The name of the person responsible for this change,
together with its date.
* a committer: The name of the person who actually created the
commit, with the date it was done. This may be different from
the author, for example, if the author was someone who wrote a
patch and emailed it to the person who used it to create the
commit.
I'm not even sure how to make these different, but in this case it
doesn't matter because the "committer" as you defined it above is more
than one person ..
Not really, no.
The authors may be different, but the first git
committer of the patch is different.
The committer is the person that does a git commit
either directly with git commit or git am.
If a git tree is pulled by someone else, the initial
committer name remains on the commit.
You should keep the original patch author names and
add your own "Signed-off-by:" and not claim authorship
of the patches themselves.
This isn't what's happening tho. In maintainer land if someone forwards
you a patch then you leave the original author on the patch. They wrote
the patch and your just forwarding it on up the ladder. This isn't the
case with these patches.. I crafted each of the commit I have authorship
on, no one forwarded those commits to me. I'm not taking authorship
credit for any thing I didn't create, although I an giving credit to the
place which gave me the raw material which was Google. From my
experience this is how it's done in Linux ..
Daniel
--
Sent by an consultant of the Qualcomm Innovation Center, Inc.
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora
Forum.
On Fri, 21 Jan 2011 07:46:41 -0800
Daniel Walker [off-list ref] wrote:
This isn't what's happening tho. In maintainer land if someone forwards
you a patch then you leave the original author on the patch. They wrote
the patch and your just forwarding it on up the ladder. This isn't the
case with these patches.. I crafted each of the commit I have authorship
on, no one forwarded those commits to me. I'm not taking authorship
credit for any thing I didn't create, although I an giving credit to the
place which gave me the raw material which was Google. From my
experience this is how it's done in Linux ..
I don't know why you're even trying to defend this, just admit you were
wrong and move on.
Trying to claim the author field for these patches for yourself is both
misleading and vain. You did not write the code and are therefore not
the author, trying to conflate the author and commit fields in this way
is so misguided I thought you must be trolling when I first saw this
thread.
This is not "how it's done in Linux" at all. In this case you're
trying to act like a maintainer by collecting patches and forwarding
them upstream, so you need to preserve authorship and the s-o-b chain.
If you want to take responsibility for the code going forward, great,
but don't pollute the logs with bogus author fields that imply you
wrote the stuff in the first place.
--
Jesse Barnes, Intel Open Source Technology Center
From: Daniel Walker <hidden> Date: 2011-01-21 17:56:12
On Fri, 2011-01-21 at 09:48 -0800, Jesse Barnes wrote:
On Fri, 21 Jan 2011 07:46:41 -0800
Daniel Walker [off-list ref] wrote:
quoted
This isn't what's happening tho. In maintainer land if someone forwards
you a patch then you leave the original author on the patch. They wrote
the patch and your just forwarding it on up the ladder. This isn't the
case with these patches.. I crafted each of the commit I have authorship
on, no one forwarded those commits to me. I'm not taking authorship
credit for any thing I didn't create, although I an giving credit to the
place which gave me the raw material which was Google. From my
experience this is how it's done in Linux ..
I don't know why you're even trying to defend this, just admit you were
wrong and move on.
Trying to claim the author field for these patches for yourself is both
misleading and vain. You did not write the code and are therefore not
the author, trying to conflate the author and commit fields in this way
is so misguided I thought you must be trolling when I first saw this
thread.
This is not "how it's done in Linux" at all. In this case you're
trying to act like a maintainer by collecting patches and forwarding
them upstream, so you need to preserve authorship and the s-o-b chain.
If you want to take responsibility for the code going forward, great,
but don't pollute the logs with bogus author fields that imply you
wrote the stuff in the first place.
I did create these commits. Do you think someone else created the
commits? There is no commit forwarding happening here.
Daniel
--
Sent by an consultant of the Qualcomm Innovation Center, Inc.
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora
Forum.
From: Christoph Hellwig <hch@infradead.org> Date: 2011-01-21 17:59:22
On Fri, Jan 21, 2011 at 09:56:09AM -0800, Daniel Walker wrote:
I did create these commits. Do you think someone else created the
commits? There is no commit forwarding happening here.
Creating a commit is easy. I think for cases like this it's a good
idea to at least write down a "Based on patches from ..." in the
commit message, and preferably also how it relates to their patches.
E.g. dropped android local crap, ported to $FOO kernel ABI, or just
rolled up totally confused local repository history.
On Fri, 21 Jan 2011 09:48:27 -0800
Jesse Barnes [off-list ref] wrote:
On Fri, 21 Jan 2011 07:46:41 -0800
Daniel Walker [off-list ref] wrote:
quoted
This isn't what's happening tho. In maintainer land if someone forwards
you a patch then you leave the original author on the patch. They wrote
the patch and your just forwarding it on up the ladder. This isn't the
case with these patches.. I crafted each of the commit I have authorship
on, no one forwarded those commits to me. I'm not taking authorship
credit for any thing I didn't create, although I an giving credit to the
place which gave me the raw material which was Google. From my
experience this is how it's done in Linux ..
I don't know why you're even trying to defend this, just admit you were
wrong and move on.
Trying to claim the author field for these patches for yourself is both
misleading and vain. You did not write the code and are therefore not
the author, trying to conflate the author and commit fields in this way
is so misguided I thought you must be trolling when I first saw this
thread.
This is not "how it's done in Linux" at all. In this case you're
trying to act like a maintainer by collecting patches and forwarding
them upstream, so you need to preserve authorship and the s-o-b chain.
If you want to take responsibility for the code going forward, great,
but don't pollute the logs with bogus author fields that imply you
wrote the stuff in the first place.
That said, if you did significant work on these before committing them,
then you're right and I'm wrong. It *is* fairly common for committers
to change things; and if the changes are significant enough, they claim
authorship and note the original author in the changelog.
So if that's the case here, I apologize, but I didn't see that
explained in any part of the thread I read.
--
Jesse Barnes, Intel Open Source Technology Center
From: Daniel Walker <hidden> Date: 2011-01-21 18:00:26
On Fri, 2011-01-21 at 09:56 -0800, Jesse Barnes wrote:
On Fri, 21 Jan 2011 09:48:27 -0800
Jesse Barnes [off-list ref] wrote:
quoted
On Fri, 21 Jan 2011 07:46:41 -0800
Daniel Walker [off-list ref] wrote:
quoted
This isn't what's happening tho. In maintainer land if someone forwards
you a patch then you leave the original author on the patch. They wrote
the patch and your just forwarding it on up the ladder. This isn't the
case with these patches.. I crafted each of the commit I have authorship
on, no one forwarded those commits to me. I'm not taking authorship
credit for any thing I didn't create, although I an giving credit to the
place which gave me the raw material which was Google. From my
experience this is how it's done in Linux ..
I don't know why you're even trying to defend this, just admit you were
wrong and move on.
Trying to claim the author field for these patches for yourself is both
misleading and vain. You did not write the code and are therefore not
the author, trying to conflate the author and commit fields in this way
is so misguided I thought you must be trolling when I first saw this
thread.
This is not "how it's done in Linux" at all. In this case you're
trying to act like a maintainer by collecting patches and forwarding
them upstream, so you need to preserve authorship and the s-o-b chain.
If you want to take responsibility for the code going forward, great,
but don't pollute the logs with bogus author fields that imply you
wrote the stuff in the first place.
That said, if you did significant work on these before committing them,
then you're right and I'm wrong. It *is* fairly common for committers
to change things; and if the changes are significant enough, they claim
authorship and note the original author in the changelog.
So if that's the case here, I apologize, but I didn't see that
explained in any part of the thread I read.
I did a significant amount of work to create the commits and series. I'm
sorry if that's not clear, but it is in fact true.
Daniel
--
Sent by an consultant of the Qualcomm Innovation Center, Inc.
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora
Forum.
On Fri, 21 Jan 2011 10:00:28 -0800
Daniel Walker [off-list ref] wrote:
On Fri, 2011-01-21 at 09:56 -0800, Jesse Barnes wrote:
quoted
On Fri, 21 Jan 2011 09:48:27 -0800
Jesse Barnes [off-list ref] wrote:
quoted
On Fri, 21 Jan 2011 07:46:41 -0800
Daniel Walker [off-list ref] wrote:
quoted
This isn't what's happening tho. In maintainer land if someone forwards
you a patch then you leave the original author on the patch. They wrote
the patch and your just forwarding it on up the ladder. This isn't the
case with these patches.. I crafted each of the commit I have authorship
on, no one forwarded those commits to me. I'm not taking authorship
credit for any thing I didn't create, although I an giving credit to the
place which gave me the raw material which was Google. From my
experience this is how it's done in Linux ..
I don't know why you're even trying to defend this, just admit you were
wrong and move on.
Trying to claim the author field for these patches for yourself is both
misleading and vain. You did not write the code and are therefore not
the author, trying to conflate the author and commit fields in this way
is so misguided I thought you must be trolling when I first saw this
thread.
This is not "how it's done in Linux" at all. In this case you're
trying to act like a maintainer by collecting patches and forwarding
them upstream, so you need to preserve authorship and the s-o-b chain.
If you want to take responsibility for the code going forward, great,
but don't pollute the logs with bogus author fields that imply you
wrote the stuff in the first place.
That said, if you did significant work on these before committing them,
then you're right and I'm wrong. It *is* fairly common for committers
to change things; and if the changes are significant enough, they claim
authorship and note the original author in the changelog.
So if that's the case here, I apologize, but I didn't see that
explained in any part of the thread I read.
I did a significant amount of work to create the commits and series. I'm
sorry if that's not clear, but it is in fact true.
Changes to the code or just reordering and merging commits? If the
former, then I think Christoph's comment applies, if the latter, I
think preserving authorship is still the right thing to do.
--
Jesse Barnes, Intel Open Source Technology Center
From: Daniel Walker <hidden> Date: 2011-01-21 18:18:01
On Fri, 2011-01-21 at 10:04 -0800, Jesse Barnes wrote:
On Fri, 21 Jan 2011 10:00:28 -0800
Daniel Walker [off-list ref] wrote:
quoted
On Fri, 2011-01-21 at 09:56 -0800, Jesse Barnes wrote:
quoted
On Fri, 21 Jan 2011 09:48:27 -0800
Jesse Barnes [off-list ref] wrote:
quoted
On Fri, 21 Jan 2011 07:46:41 -0800
Daniel Walker [off-list ref] wrote:
quoted
This isn't what's happening tho. In maintainer land if someone forwards
you a patch then you leave the original author on the patch. They wrote
the patch and your just forwarding it on up the ladder. This isn't the
case with these patches.. I crafted each of the commit I have authorship
on, no one forwarded those commits to me. I'm not taking authorship
credit for any thing I didn't create, although I an giving credit to the
place which gave me the raw material which was Google. From my
experience this is how it's done in Linux ..
I don't know why you're even trying to defend this, just admit you were
wrong and move on.
Trying to claim the author field for these patches for yourself is both
misleading and vain. You did not write the code and are therefore not
the author, trying to conflate the author and commit fields in this way
is so misguided I thought you must be trolling when I first saw this
thread.
This is not "how it's done in Linux" at all. In this case you're
trying to act like a maintainer by collecting patches and forwarding
them upstream, so you need to preserve authorship and the s-o-b chain.
If you want to take responsibility for the code going forward, great,
but don't pollute the logs with bogus author fields that imply you
wrote the stuff in the first place.
That said, if you did significant work on these before committing them,
then you're right and I'm wrong. It *is* fairly common for committers
to change things; and if the changes are significant enough, they claim
authorship and note the original author in the changelog.
So if that's the case here, I apologize, but I didn't see that
explained in any part of the thread I read.
I did a significant amount of work to create the commits and series. I'm
sorry if that's not clear, but it is in fact true.
Changes to the code or just reordering and merging commits? If the
former, then I think Christoph's comment applies, if the latter, I
think preserving authorship is still the right thing to do.
I changed both, switching to new kernel API's, clean ups, finding a
minimum set of code for this support, and debugging that and fixing
defects in the code. This wasn't a trivial amount of work to create the
series and commits.
Daniel
--
Sent by an consultant of the Qualcomm Innovation Center, Inc.
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora
Forum.
On Fri, 21 Jan 2011 10:18:02 -0800
Daniel Walker [off-list ref] wrote:
On Fri, 2011-01-21 at 10:04 -0800, Jesse Barnes wrote:
quoted
On Fri, 21 Jan 2011 10:00:28 -0800
Daniel Walker [off-list ref] wrote:
quoted
On Fri, 2011-01-21 at 09:56 -0800, Jesse Barnes wrote:
quoted
On Fri, 21 Jan 2011 09:48:27 -0800
Jesse Barnes [off-list ref] wrote:
quoted
On Fri, 21 Jan 2011 07:46:41 -0800
Daniel Walker [off-list ref] wrote:
quoted
This isn't what's happening tho. In maintainer land if someone forwards
you a patch then you leave the original author on the patch. They wrote
the patch and your just forwarding it on up the ladder. This isn't the
case with these patches.. I crafted each of the commit I have authorship
on, no one forwarded those commits to me. I'm not taking authorship
credit for any thing I didn't create, although I an giving credit to the
place which gave me the raw material which was Google. From my
experience this is how it's done in Linux ..
I don't know why you're even trying to defend this, just admit you were
wrong and move on.
Trying to claim the author field for these patches for yourself is both
misleading and vain. You did not write the code and are therefore not
the author, trying to conflate the author and commit fields in this way
is so misguided I thought you must be trolling when I first saw this
thread.
This is not "how it's done in Linux" at all. In this case you're
trying to act like a maintainer by collecting patches and forwarding
them upstream, so you need to preserve authorship and the s-o-b chain.
If you want to take responsibility for the code going forward, great,
but don't pollute the logs with bogus author fields that imply you
wrote the stuff in the first place.
That said, if you did significant work on these before committing them,
then you're right and I'm wrong. It *is* fairly common for committers
to change things; and if the changes are significant enough, they claim
authorship and note the original author in the changelog.
So if that's the case here, I apologize, but I didn't see that
explained in any part of the thread I read.
I did a significant amount of work to create the commits and series. I'm
sorry if that's not clear, but it is in fact true.
Changes to the code or just reordering and merging commits? If the
former, then I think Christoph's comment applies, if the latter, I
think preserving authorship is still the right thing to do.
I changed both, switching to new kernel API's, clean ups, finding a
minimum set of code for this support, and debugging that and fixing
defects in the code. This wasn't a trivial amount of work to create the
series and commits.
Ok, then I'm sorry for jumping the gun. The changelogs made the
changes sound more trivial ("slight modifications and cleanup"); and
those would only justify a small [] text near the s-o-b lines. But if
they're larger, maybe you should expand on the text and include the
original authorship like Christoph suggested (or use the original
author for patches where the changes really were trivial).
--
Jesse Barnes, Intel Open Source Technology Center
From: Daniel Walker <hidden> Date: 2011-01-21 18:35:07
On Fri, 2011-01-21 at 10:27 -0800, Jesse Barnes wrote:
Ok, then I'm sorry for jumping the gun. The changelogs made the
changes sound more trivial ("slight modifications and cleanup"); and
those would only justify a small [] text near the s-o-b lines. But if
they're larger, maybe you should expand on the text and include the
original authorship like Christoph suggested (or use the original
author for patches where the changes really were trivial).
yeah, I didn't really think about that line when I wrote it.. It should
just says "Base on code from Google." I was just trying to give them
some credit.
I've done changes like your suggesting
(923a081c72fa2dccb7ea7070bd8e0f4dc99ceff8) so I'm not a novice to this.
Daniel
--
Sent by an consultant of the Qualcomm Innovation Center, Inc.
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora
Forum.
Really though? Let's look at one of them:
[PATCH 3/7] msm: qsd8x50: add acpuclock code
Please tell me the amount of time it took you to "debug and fix
defects in the code" from the following:
http://android.git.kernel.org/?p=kernel/experimental.git;a=blob;f=arch/arm/mach-msm/acpuclock-qsd8x50.c;h=691acdeaad74c2f29927308b8110af7d4dd5070b;hb=refs/heads/android-msm-2.6.37-wip
That is basically a squash of 3 commits (one of which was another
squash of ~20 commits during a cleanup which has all the attributions
in the squash). This file's main authors was Brian, Arve, and myself,
with some contributions from Mike, Iliyan, and Haley from HTC. Doing a
quick-and-dirty grep through the history, the contributions break down
as:
2 Arve Hj?nnev?g [off-list ref]
6 Brian Swetland [off-list ref]
14 Dima Zavin [off-list ref]
2 Haley Teng [off-list ref]
1 Iliyan Malchev [off-list ref]
5 Mike Chan [off-list ref]
Your commit is a:
git checkout <branch> -- <file> ; git add ; git commit;
--Dima
On Fri, Jan 21, 2011 at 10:18 AM, Daniel Walker [off-list ref] wrote:
On Fri, 2011-01-21 at 10:04 -0800, Jesse Barnes wrote:
quoted
On Fri, 21 Jan 2011 10:00:28 -0800
Daniel Walker [off-list ref] wrote:
quoted
On Fri, 2011-01-21 at 09:56 -0800, Jesse Barnes wrote:
quoted
On Fri, 21 Jan 2011 09:48:27 -0800
Jesse Barnes [off-list ref] wrote:
quoted
On Fri, 21 Jan 2011 07:46:41 -0800
Daniel Walker [off-list ref] wrote:
quoted
This isn't what's happening tho. In maintainer land if someone forwards
you a patch then you leave the original author on the patch. They wrote
the patch and your just forwarding it on up the ladder. This isn't the
case with these patches.. I crafted each of the commit I have authorship
on, no one forwarded those commits to me. I'm not taking authorship
credit for any thing I didn't create, although I an giving credit to the
place which gave me the raw material which was Google. From my
experience this is how it's done in Linux ..
I don't know why you're even trying to defend this, just admit you were
wrong and move on.
Trying to claim the author field for these patches for yourself is both
misleading and vain. ?You did not write the code and are therefore not
the author, trying to conflate the author and commit fields in this way
is so misguided I thought you must be trolling when I first saw this
thread.
This is not "how it's done in Linux" at all. ?In this case you're
trying to act like a maintainer by collecting patches and forwarding
them upstream, so you need to preserve authorship and the s-o-b chain.
If you want to take responsibility for the code going forward, great,
but don't pollute the logs with bogus author fields that imply you
wrote the stuff in the first place.
That said, if you did significant work on these before committing them,
then you're right and I'm wrong. ?It *is* fairly common for committers
to change things; and if the changes are significant enough, they claim
authorship and note the original author in the changelog.
So if that's the case here, I apologize, but I didn't see that
explained in any part of the thread I read.
I did a significant amount of work to create the commits and series. I'm
sorry if that's not clear, but it is in fact true.
Changes to the code or just reordering and merging commits? ?If the
former, then I think Christoph's comment applies, if the latter, I
think preserving authorship is still the right thing to do.
I changed both, switching to new kernel API's, clean ups, finding a
minimum set of code for this support, and debugging that and fixing
defects in the code. This wasn't a trivial amount of work to create the
series and commits.
Daniel
--
Sent by an consultant of the Qualcomm Innovation Center, Inc.
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora
Forum.
From: Daniel Walker <hidden> Date: 2011-01-21 20:49:54
On Fri, 2011-01-21 at 12:44 -0800, Dima Zavin wrote:
Really though? Let's look at one of them:
2 Arve Hj?nnev?g [off-list ref]
6 Brian Swetland [off-list ref]
14 Dima Zavin [off-list ref]
2 Haley Teng [off-list ref]
1 Iliyan Malchev [off-list ref]
5 Mike Chan [off-list ref]
I'll add this list into the commit text ..
Daniel
--
Sent by an consultant of the Qualcomm Innovation Center, Inc.
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora
Forum.
From: Daniel Walker <hidden> Date: 2011-01-21 21:37:18
On Fri, 2011-01-21 at 13:01 -0800, Jesse Barnes wrote:
On Fri, 21 Jan 2011 12:49:55 -0800
Daniel Walker [off-list ref] wrote:
quoted
On Fri, 2011-01-21 at 12:44 -0800, Dima Zavin wrote:
quoted
Really though? Let's look at one of them:
quoted
2 Arve Hj?nnev?g [off-list ref]
6 Brian Swetland [off-list ref]
14 Dima Zavin [off-list ref]
2 Haley Teng [off-list ref]
1 Iliyan Malchev [off-list ref]
5 Mike Chan [off-list ref]
I'll add this list into the commit text ..
Sounds like a good example of a patch where you should preserve the
author field as well.
preserve it as who ?
Daniel
--
Sent by an consultant of the Qualcomm Innovation Center, Inc.
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora
Forum.
Sounds like a good example of a patch where you should preserve the
author field as well.
preserve it as who ?
My main point is that the authorship of this code is VERY easy to
ascertain. It is not like a lot of other vendor code that gets thrown
over the wall as a tarball. We really do our best to follow the right
practices, give the right credits, create legible well separated
commits, etc.
--Dima
From: David Woodhouse <dwmw2@infradead.org> Date: 2011-01-22 13:59:00
On Fri, 2011-01-21 at 13:42 -0800, Dima Zavin wrote:
My main point is that the authorship of this code is VERY easy to
ascertain. It is not like a lot of other vendor code that gets thrown
over the wall as a tarball. We really do our best to follow the right
practices, give the right credits, create legible well separated
commits, etc.
So your code was already submitted to Linus in a form that he'll accept,
and Daniel is just completely wasting his time?
--
David Woodhouse Open Source Technology Centre
David.Woodhouse at intel.com Intel Corporation
From: Joe Perches <joe@perches.com> Date: 2011-01-21 21:02:45
On Fri, 2011-01-21 at 12:49 -0800, Daniel Walker wrote:
On Fri, 2011-01-21 at 12:44 -0800, Dima Zavin wrote:
quoted
Really though? Let's look at one of them:
2 Arve Hj?nnev?g [off-list ref]
6 Brian Swetland [off-list ref]
14 Dima Zavin [off-list ref]
2 Haley Teng [off-list ref]
1 Iliyan Malchev [off-list ref]
5 Mike Chan [off-list ref]
I'll add this list into the commit text ..
I think it'd be better if you pull them into a
git repository, then use either:
git format-patch
git send-email
or
git request-pull
That way no author history is lost.
cheers, Joe
From: Daniel Walker <hidden> Date: 2011-01-21 21:37:14
On Fri, 2011-01-21 at 13:02 -0800, Joe Perches wrote:
On Fri, 2011-01-21 at 12:49 -0800, Daniel Walker wrote:
quoted
On Fri, 2011-01-21 at 12:44 -0800, Dima Zavin wrote:
quoted
Really though? Let's look at one of them:
2 Arve Hj?nnev?g [off-list ref]
6 Brian Swetland [off-list ref]
14 Dima Zavin [off-list ref]
2 Haley Teng [off-list ref]
1 Iliyan Malchev [off-list ref]
5 Mike Chan [off-list ref]
I'll add this list into the commit text ..
I think it'd be better if you pull them into a
git repository, then use either:
git format-patch
git send-email
or
git request-pull
That way no author history is lost.
The history isn't upstreamable ..
Daniel
--
Sent by an consultant of the Qualcomm Innovation Center, Inc.
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora
Forum.
From: Pekka Enberg <penberg@kernel.org> Date: 2011-01-22 11:18:56
Hi Daniel,
On Fri, Jan 21, 2011 at 11:24 PM, Daniel Walker [off-list ref] wrote:
On Fri, 2011-01-21 at 13:02 -0800, Joe Perches wrote:
quoted
On Fri, 2011-01-21 at 12:49 -0800, Daniel Walker wrote:
quoted
On Fri, 2011-01-21 at 12:44 -0800, Dima Zavin wrote:
quoted
Really though? Let's look at one of them:
? ? ? 2 Arve Hj?nnev?g [off-list ref]
? ? ? 6 Brian Swetland [off-list ref]
? ? ?14 Dima Zavin [off-list ref]
? ? ? 2 Haley Teng [off-list ref]
? ? ? 1 Iliyan Malchev [off-list ref]
? ? ? 5 Mike Chan [off-list ref]
I'll add this list into the commit text ..
I think it'd be better if you pull them into a
git repository, then use either:
? ? ? git format-patch
? ? ? git send-email
or
? ? ? git request-pull
That way no author history is lost.
The history isn't upstreamable ..
Why is that? I don't see any technical problem of upstreaming the
original patches even if they don't compile (as long as they're not
included in Makefiles or Kconfig files). There's no need to hide the
real history even if it looks ugly...
Pekka
From: Russell King - ARM Linux <hidden> Date: 2011-01-22 12:21:16
On Sat, Jan 22, 2011 at 01:18:54PM +0200, Pekka Enberg wrote:
Why is that? I don't see any technical problem of upstreaming the
original patches even if they don't compile (as long as they're not
included in Makefiles or Kconfig files). There's no need to hide the
real history even if it looks ugly...
I've asked Daniel in private whether he'd mind posting the original
set of patches which he based his work on to this thread.
I suspect that the situation is that there's many patches which he's
taken from the repository and consolidated them down into a nice set
of easy to review patches.
One of the problems of preserving the micro-detail of history right
from the early inception of support for a platform is that quite often
the early support is buggy or broken - it might not even compile. There
may be 20 or so patches on top of that which eventually get it to a
usable state.
Do we really want to put off people from reviewing patches because of
the size of micro-development that happened prior to getting to a point
where the result of that development is usable?
Tell me this: does a patch which cleanly adds support for board X get
reviewed by more, the same, or less people than a set of twenty patches
which goes about the same thing, adding code, removing previously added
code, changing it again.
I personally _hate_ patch sets which do that, and I tend to ignore them
(or maybe review the first twenty patches before taking a break... and
then never going back to them) because I quickly get tired reading all
that code - which means I'm not able to do an effective review. I
suspect most people suffer from reviewer tiredness when faced with large
patch sets changing the same code time and time again.
I personally believe that Daniel is doing the right thing here, except
he needs to preserve a better record of authorship. I even think it's
fine if he decides to drop people's sign-offs if he thinks the code has
changed significantly from the original authors - provided he's willing
to take responsibility for the submission of that code.
If you read what a sign-off means (the DCO) then it's clear that if the
code has changed significantly, the original sign-offs do not apply
anymore - the original sign-offs can't warrant that the modified code
is covered by appropriate licenses or even that the person who modified
their code has the rights to submit it.
Take a moment to think about that. If I took some of your code with
your sign-off, changed it significantly by including someone elses work
where there were no rights to submit that persons work into mainline,
and I kept your sign-off on that, would you be happy when someone starts
making accusations against you submitting their code?
The sign-offs make no representation of who was the author. In many
cases where companies are involved, the first sign-off is the person
who authorized the release of the code, not the person who wrote the
code, so it's a complete mistake to attribute authorship by whoever was
listed first in the Sign-off lines. Authorship may be jointly held by
the first 4 people listed, and attributing authorship to only the first
is just as bad as not attributing authorship at all.
Lastly, from the arguments being made over this, if they are supported,
I think that people are saying that the actions listed in DCO (b) are
no longer allowed, and so DCO (b) should be removed entirely as an
acceptable practice. IOW, what's being promoted as "you must do" (iow,
preserving all history) is completely contary to the allowances of
DCO (b).
Russell,
I completely agree with you that the entire history of the evolution
of the code is not interesting or useful to everyone on the list or in
linux kernel tree. I'm not advocating posting the original patches
(which as you rightfully point out are plentiful due to long
development cycle). It would be a waste of time.
I also like how Daniel has split up the board file additions into nice
small patches, and I already thanked him for doing this work.
All I ask is that if files are directly copied out of the tree with
only slight modifications or if they are copied and stripped down for
easier consumption, just say
Original Authors: <dude@co> if it's reasonable to gather who the
primary contributors are. If that is hard due to lots of commits and
squashes, even a Cc: to the people who wrote the code would have been
enough. Had any of that been done, I would have not said a word.
I still do appreciate Daniel's efforts and the way he is splitting up
the commits for public consumption, as they do logically make sense.
--Dima
On Sat, Jan 22, 2011 at 4:20 AM, Russell King - ARM Linux
[off-list ref] wrote:
On Sat, Jan 22, 2011 at 01:18:54PM +0200, Pekka Enberg wrote:
quoted
Why is that? I don't see any technical problem of upstreaming the
original patches even if they don't compile (as long as they're not
included in Makefiles or Kconfig files). There's no need to hide the
real history even if it looks ugly...
I've asked Daniel in private whether he'd mind posting the original
set of patches which he based his work on to this thread.
I suspect that the situation is that there's many patches which he's
taken from the repository and consolidated them down into a nice set
of easy to review patches.
One of the problems of preserving the micro-detail of history right
from the early inception of support for a platform is that quite often
the early support is buggy or broken - it might not even compile. ?There
may be 20 or so patches on top of that which eventually get it to a
usable state.
Do we really want to put off people from reviewing patches because of
the size of micro-development that happened prior to getting to a point
where the result of that development is usable?
Tell me this: does a patch which cleanly adds support for board X get
reviewed by more, the same, or less people than a set of twenty patches
which goes about the same thing, adding code, removing previously added
code, changing it again.
I personally _hate_ patch sets which do that, and I tend to ignore them
(or maybe review the first twenty patches before taking a break... and
then never going back to them) because I quickly get tired reading all
that code - which means I'm not able to do an effective review. ?I
suspect most people suffer from reviewer tiredness when faced with large
patch sets changing the same code time and time again.
I personally believe that Daniel is doing the right thing here, except
he needs to preserve a better record of authorship. ?I even think it's
fine if he decides to drop people's sign-offs if he thinks the code has
changed significantly from the original authors - provided he's willing
to take responsibility for the submission of that code.
If you read what a sign-off means (the DCO) then it's clear that if the
code has changed significantly, the original sign-offs do not apply
anymore - the original sign-offs can't warrant that the modified code
is covered by appropriate licenses or even that the person who modified
their code has the rights to submit it.
Take a moment to think about that. ?If I took some of your code with
your sign-off, changed it significantly by including someone elses work
where there were no rights to submit that persons work into mainline,
and I kept your sign-off on that, would you be happy when someone starts
making accusations against you submitting their code?
The sign-offs make no representation of who was the author. ?In many
cases where companies are involved, the first sign-off is the person
who authorized the release of the code, not the person who wrote the
code, so it's a complete mistake to attribute authorship by whoever was
listed first in the Sign-off lines. ?Authorship may be jointly held by
the first 4 people listed, and attributing authorship to only the first
is just as bad as not attributing authorship at all.
Lastly, from the arguments being made over this, if they are supported,
I think that people are saying that the actions listed in DCO (b) are
no longer allowed, and so DCO (b) should be removed entirely as an
acceptable practice. ?IOW, what's being promoted as "you must do" (iow,
preserving all history) is completely contary to the allowances of
DCO (b).
From: Russell King - ARM Linux <hidden> Date: 2011-01-22 18:49:37
On Sat, Jan 22, 2011 at 10:06:44AM -0800, Dima Zavin wrote:
All I ask is that if files are directly copied out of the tree with
only slight modifications or if they are copied and stripped down for
easier consumption, just say
Original Authors: <dude@co> if it's reasonable to gather who the
primary contributors are. If that is hard due to lots of commits and
squashes, even a Cc: to the people who wrote the code would have been
enough. Had any of that been done, I would have not said a word.
Well, having read what Thomas said in his mail:
Thomas said:
| Patch 3/7 is extracted from another large dump (37431502c4) in the
| android tree which has:
[diffstat summary cut]
| And if you look at the above 37431502c4 commit then you'll notice that
| the author is Dima Zavin [off-list ref], while in fact the whole
| commit is a conglomerate of commits from some other place with 16
| different authors, but there is no way to identify who wrote what.
I decided to investigate:
http://android.git.kernel.org/?p=kernel/msm.git;a=commit;h=37431502c4
| author Dima Zavin [off-list ref]
| committer Arve Hj?nnev?g [off-list ref]
|
| [ARM] msm: mahimahi: Update the memory map.
|
| - move framebuffer to SMI and mdp pmem to bank 2 of EBI
| - remove the gpu pmem regions since we now use the MMU
| - move the adsp region to bank 2, and make it bigger (41MB vs 32MB)
| - move ram console to SMI
|
| Change-Id: I88b4033e98374fc038609fbbb1c7e5cbed4f87c4
| Signed-off-by: Dima Zavin [off-list ref]
|
| [ARM] msm: mahimahi: Expand memory available to kernel to 219MB
|
| Change-Id: I59e69ce4209d16ce9804d3fa81814c9d0bda9a03
| Signed-off-by: Dima Zavin [off-list ref]
|
| [ARM] msm: mahimahi: Read bluetooth address from ATAG and export in sysfs.
|
| Signed-off-by: Nick Pelly [off-list ref]
... etc ...
Those change IDs are meaningless, they provide no way for external people
to trace the history of the original commits and work out who did what
in the resulting diff.
Maybe you could illustrate how to take that particular commit, which
Daniel apparantly based his 3/7 patch on, and identify who Daniel should
and should not give credit to using *just* the text in that commit and
no other information.
If you can't do that without reference to some other information, then I
don't think you have a leg to stand on when complaining to Daniel about
not giving credit, as you've made it impossible for that to happen.
While it is not fair _not_ to give credit to people who worked on a
particular piece of code, it is also not fair _to_ give credit to
people who didn't work on that same code. It erodes the value of
crediting the real authors.
I'd say that Daniel is doing a bloody good job, everything considered.
Maybe you could illustrate how to take that particular commit, which
Daniel apparantly based his 3/7 patch on, and identify who Daniel should
and should not give credit to using *just* the text in that commit and
no other information.
I'd add a:
"Based a on shitty codedump from a secrit Google repository, credited to
Dima Zavin [off-list ref]."
at the end of the commit line and Cc Dima to see if there's any
interested from his side to sort this out. But maybe that's just my
attitude, and a less colourful language would also do it.
From: Brian Swetland <hidden> Date: 2011-01-22 19:23:03
On Sat, Jan 22, 2011 at 4:20 AM, Russell King - ARM Linux
[off-list ref] wrote:
One of the problems of preserving the micro-detail of history right
from the early inception of support for a platform is that quite often
the early support is buggy or broken - it might not even compile. There
may be 20 or so patches on top of that which eventually get it to a
usable state.
Do we really want to put off people from reviewing patches because of
the size of micro-development that happened prior to getting to a point
where the result of that development is usable?
...
I personally believe that Daniel is doing the right thing here, except
he needs to preserve a better record of authorship. I even think it's
fine if he decides to drop people's sign-offs if he thinks the code has
changed significantly from the original authors - provided he's willing
to take responsibility for the submission of that code.
If you read what a sign-off means (the DCO) then it's clear that if the
code has changed significantly, the original sign-offs do not apply
anymore - the original sign-offs can't warrant that the modified code
is covered by appropriate licenses or even that the person who modified
their code has the rights to submit it.
I completely agree that it's not realistic that the entire development
history of this code be preserved as it goes upstream. Nobody needs
to see the 20-30 fiddly changes over a couple months of people from
three companies tinkering with subtleties of the SCPLL sequencing for
QSD8x50, when the end result is (hopefully) 200-300 lines of working
code.
I also will state that I have absolutely no problem with people
picking patches that we've made available, tidying things up, and
pushing them into mainline, particularly bits that have languished for
a while. At the same time, we're working to improving our process for
future work -- for example the Tegra2 development efforts, I believe,
have been a step forward as far as getting stuff upstream from the
start of a project.
All we ask is that some reasonable acknowledgement of original
authorship is maintained for non-trivial work. A 5-10 line patch that
deals with mechanical issues of board files or cleans stuff up is no
big deal. 100s of lines that represent some real work is something
else.
I'm in the same boat as Daniel much of the time, since we often do
spend some time toward the end of a development cycle collapsing a
bunch of patches from multiple developers at Google or closely-working
OEM partners down into a smaller set that hopefully makes a little bit
more sense.
What would be useful would be a reasonable convention for
acknowledging multiple authors, perhaps something along the lines of:
Author: Awesome Upstreamer [off-list ref] or Main Author [off-list ref]
Committer: Awesome Upstreamer [off-list ref]
Subject: arm: msm8k: acpu clock management
... summary of the patch ...
Original-Author: Joe Firmware Guy [off-list ref]
Original-Author: Kernel Droid [off-list ref]
Signed-off-by: ...
Though I'm not sure "Original-Author" is the best phrasing here... Or
perhaps just having the patch description end with "This patch is
based on original code by Joe Firmware Guy, Kernel Droid, etc is the
way to go. I do think that for work where there is one clear original
author, it's nice to leave them as the Author, but at the end of the
day, provided the code's heading in the right direction and the
contributors are acknowledged, that's a detail.
If there's some consensus on the way to do this, we can make sure to
use the same method when we're collapsing history on our own patchsets
(obviously the current model we're using can be messy and confusing)
to simplify things going forward.
Brian
From: Nicolas Pitre <nico@fluxnic.net> Date: 2011-01-22 19:49:36
On Sat, 22 Jan 2011, Brian Swetland wrote:
All we ask is that some reasonable acknowledgement of original
authorship is maintained for non-trivial work. A 5-10 line patch that
deals with mechanical issues of board files or cleans stuff up is no
big deal. 100s of lines that represent some real work is something
else.
So... What about http://article.gmane.org/gmane.linux.ports.arm.msm/167 ?
Is that good enough for you? If no, then could you please propose an
alternative? If that is indeed good enough, then could we please move on?
What would be useful would be a reasonable convention for
acknowledging multiple authors, perhaps something along the lines of:
Author: Awesome Upstreamer [off-list ref] or Main Author [off-list ref]
Committer: Awesome Upstreamer [off-list ref]
Subject: arm: msm8k: acpu clock management
... summary of the patch ...
Original-Author: Joe Firmware Guy [off-list ref]
Original-Author: Kernel Droid [off-list ref]
Signed-off-by: ...
Though I'm not sure "Original-Author" is the best phrasing here... Or
perhaps just having the patch description end with "This patch is
based on original code by Joe Firmware Guy, Kernel Droid, etc is the
way to go. I do think that for work where there is one clear original
author, it's nice to leave them as the Author, but at the end of the
day, provided the code's heading in the right direction and the
contributors are acknowledged, that's a detail.
I think a free form list of contributors in the commit log should be
fine, possibly adding them in CC to the patch submission as well.
There is a _huge_ value in the action of making code palatable for
mainline inclusion and actually pushing that code into mainline. If you
do it yourself next time instead of letting your code rot then no one
might be tempted to stump on your authorship.
Nicolas
From: Brian Swetland <hidden> Date: 2011-01-22 19:59:48
On Sat, Jan 22, 2011 at 11:49 AM, Nicolas Pitre [off-list ref] wrote:
On Sat, 22 Jan 2011, Brian Swetland wrote:
quoted
All we ask is that some reasonable acknowledgement of original
authorship is maintained for non-trivial work. ?A 5-10 line patch that
deals with mechanical issues of board files or cleans stuff up is no
big deal. ?100s of lines that represent some real work is something
else.
So... What about http://article.gmane.org/gmane.linux.ports.arm.msm/167 ?
Is that good enough for you? ?If no, then could you please propose an
alternative? ?If that is indeed good enough, then could we please move on?
Something like:
Based on code written by:
<list of names>
is absolutely fine by me. Including patch counts, etc, is not essential.
quoted
What would be useful would be a reasonable convention for
acknowledging multiple authors, perhaps something along the lines of:
Author: Awesome Upstreamer [off-list ref] ?or ?Main Author [off-list ref]
Committer: Awesome Upstreamer [off-list ref]
Subject: arm: msm8k: acpu clock management
... summary of the patch ...
Original-Author: Joe Firmware Guy [off-list ref]
Original-Author: Kernel Droid [off-list ref]
Signed-off-by: ...
Though I'm not sure "Original-Author" is the best phrasing here... ?Or
perhaps just having the patch description end with "This patch is
based on original code by Joe Firmware Guy, Kernel Droid, etc is the
way to go. ?I do think that for work where there is one clear original
author, it's nice to leave them as the Author, but at the end of the
day, provided the code's heading in the right direction and the
contributors are acknowledged, that's a detail.
I think a free form list of contributors in the commit log should be
fine, possibly adding them in CC to the patch submission as well.
That seems reasonable to me.
There is a _huge_ value in the action of making code palatable for
mainline inclusion and actually pushing that code into mainline. If you
do it yourself next time instead of letting your code rot then no one
might be tempted to stump on your authorship.
Certainly. As long as we're acknowledging both the contributions of
those who wrote the code and those who are doing the heavy lifting to
get it upstream, we're happy. We are, of course, working on doing
things better in the future -- the tegra2 efforts are a direct result
of our desire to get things right on a newer project.
Brian
From: Christoph Hellwig <hch@infradead.org> Date: 2011-01-22 20:53:11
On Sat, Jan 22, 2011 at 11:22:57AM -0800, Brian Swetland wrote:
What would be useful would be a reasonable convention for
acknowledging multiple authors, perhaps something along the lines of:
If you do a grep "Based on" in git-log output you'll see that this is a
pretty common and thus defacto standard for attributing substantial
modified patches.
From: Russell King - ARM Linux <hidden> Date: 2011-01-22 21:04:34
On Sat, Jan 22, 2011 at 11:22:57AM -0800, Brian Swetland wrote:
What would be useful would be a reasonable convention for
acknowledging multiple authors, perhaps something along the lines of:
I asked for the answer to a _specific_ example. If you can't answer
that example, then you *can't* expect Daniel to either, and it is
utterly unreasonable to demand it of him.
On Sat, 22 Jan 2011 21:04:05 +0000
Russell King - ARM Linux [off-list ref] wrote:
On Sat, Jan 22, 2011 at 11:22:57AM -0800, Brian Swetland wrote:
quoted
What would be useful would be a reasonable convention for
acknowledging multiple authors, perhaps something along the lines of:
I asked for the answer to a _specific_ example. If you can't answer
that example, then you *can't* expect Daniel to either, and it is
utterly unreasonable to demand it of him.
I've always just put it in the text. I'm not fond of it being in URLs
because some day they break and move, at least if the list of names is in
the git log it's ensuring the contributor data isn't going to get
completely lost.
Yeah
Based on blah by
name
name
name
name
name
isn't the most thrilling git commit message but it works and sometimes
you can even generate the list with grep
From: David Woodhouse <dwmw2@infradead.org> Date: 2011-01-23 02:38:40
On Sat, 2011-01-22 at 11:22 -0800, Brian Swetland wrote:
What would be useful would be a reasonable convention for
acknowledging multiple authors, perhaps something along the lines of:
Author: Awesome Upstreamer [off-list ref] or Main Author [off-list ref]
Committer: Awesome Upstreamer [off-list ref]
Subject: arm: msm8k: acpu clock management
... summary of the patch ...
Original-Author: Joe Firmware Guy [off-list ref]
Original-Author: Kernel Droid [off-list ref]
Signed-off-by: ...
Nah, sod that. If the original authors couldn't be bothered to do their
work properly in the first place so that it was upstreamable, then as
far as I'm concerned they don't deserve the credit.
We should do the bare minimum that's required by copyright law, which is
making sure that the code is permitted in the kernel under the GPL.
Since the GPL doesn't have, and doesn't *allow*, a clause like the BSD
advertising clause, we have no requirement to credit the original
authors.
If they wanted credit, they should have done the job right in the first
place. Or at least finished the job for themselves rather than forcing
someone else to clean up their mess.
--
David Woodhouse Open Source Technology Centre
David.Woodhouse at intel.com Intel Corporation
From: Christoph Hellwig <hch@infradead.org> Date: 2011-01-22 20:42:20
On Sat, Jan 22, 2011 at 12:20:18PM +0000, Russell King - ARM Linux wrote:
I've asked Daniel in private whether he'd mind posting the original
set of patches which he based his work on to this thread.
I suspect that the situation is that there's many patches which he's
taken from the repository and consolidated them down into a nice set
of easy to review patches.
One of the problems of preserving the micro-detail of history right
from the early inception of support for a platform is that quite often
the early support is buggy or broken - it might not even compile. There
may be 20 or so patches on top of that which eventually get it to a
usable state.
Do we really want to put off people from reviewing patches because of
the size of micro-development that happened prior to getting to a point
where the result of that development is usable?
No, not at all. And I'm really annoyed at all the pointless flaming
here as people obviously never had to massage a completely messy
repository into something submittable. That usually doesn't just
include making useful commits, but also updates to current APIs, bug
fixing, removing crap that should never make it's way upstream (and
Android had quite a lot of the latter last time I looked).
The only think that Daniel did wrong was to not attribute the original
authors in the commit message, and not explaining his own contribution.
From: Joe Perches <joe@perches.com> Date: 2011-01-21 21:17:44
On Fri, 2011-01-21 at 23:05 +0200, Pekka Enberg wrote:
Daniel doing something the
Android folks should have done themselves a long time ago?
I think it's more polite myself.
I agree that ideally the androiding googlers (googly androids?)
should submit it.
Dima? Are you doing anything useful right now?
cheers, Joe
On Fri, Jan 21, 2011 at 11:05:54PM +0200, Pekka Enberg wrote:
On Fri, Jan 21, 2011 at 10:49 PM, Daniel Walker [off-list ref] wrote:
quoted
I'll add this list into the commit text ..
So why is everyone bitching at Daniel when he's doing something the
Android folks should have done themselves a long time ago?
Two wrongs don't make a right. And it's not like not submitting
changes is wrong, although granted it's not ideal. (I'd say removing
attribution from a git commit is even worse. If you're doing the
equivalent of a cherry pick, you should preserve the Author field.
Even if you're doing some cleanup work, as the maintainer I generally
preserve the Author line, and will simply add the fact that I did some
cleanup to the commit body. The question is who did more work; the
person who originally submitted the code, or the person who did the
cleanup.)
- Ted