* [PATCH 0/7] Nexus One Support
@ 2011-01-20 20:32 ` Daniel Walker
0 siblings, 0 replies; 157+ messages in thread
From: Daniel Walker @ 2011-01-20 20:32 UTC (permalink / raw)
To: linux-arm-kernel
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.
^ permalink raw reply [flat|nested] 157+ messages in thread
* [PATCH 1/7] msm: qsd8x50: add uart platform data
2011-01-20 20:32 ` Daniel Walker
@ 2011-01-20 20:32 ` Daniel Walker
-1 siblings, 0 replies; 157+ messages in thread
From: Daniel Walker @ 2011-01-20 20:32 UTC (permalink / raw)
To: linux-arm-msm; +Cc: linux-arm-kernel, linux-kernel, davidb, Daniel Walker
This enables the uart for QSD8x50.
Signed-off-by: Daniel Walker <dwalker@codeaurora.org>
---
arch/arm/mach-msm/devices-qsd8x50.c | 42 +++++++++++++++++++++++++++++++++++
1 files changed, 42 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-msm/devices-qsd8x50.c b/arch/arm/mach-msm/devices-qsd8x50.c
index b1a8f0f..24b2051 100644
--- a/arch/arm/mach-msm/devices-qsd8x50.c
+++ b/arch/arm/mach-msm/devices-qsd8x50.c
@@ -28,6 +28,32 @@
#include <mach/mmc.h>
+static struct resource resources_uart1[] = {
+ {
+ .start = INT_UART1,
+ .end = INT_UART1,
+ .flags = IORESOURCE_IRQ,
+ },
+ {
+ .start = MSM_UART1_PHYS,
+ .end = MSM_UART1_PHYS + MSM_UART1_SIZE - 1,
+ .flags = IORESOURCE_MEM,
+ },
+};
+
+static struct resource resources_uart2[] = {
+ {
+ .start = INT_UART2,
+ .end = INT_UART2,
+ .flags = IORESOURCE_IRQ,
+ },
+ {
+ .start = MSM_UART2_PHYS,
+ .end = MSM_UART2_PHYS + MSM_UART2_SIZE - 1,
+ .flags = IORESOURCE_MEM,
+ },
+};
+
static struct resource resources_uart3[] = {
{
.start = INT_UART3,
@@ -41,6 +67,20 @@ static struct resource resources_uart3[] = {
},
};
+struct platform_device msm_device_uart1 = {
+ .name = "msm_serial",
+ .id = 0,
+ .num_resources = ARRAY_SIZE(resources_uart1),
+ .resource = resources_uart1,
+};
+
+struct platform_device msm_device_uart2 = {
+ .name = "msm_serial",
+ .id = 1,
+ .num_resources = ARRAY_SIZE(resources_uart2),
+ .resource = resources_uart2,
+};
+
struct platform_device msm_device_uart3 = {
.name = "msm_serial",
.id = 2,
@@ -345,6 +385,8 @@ struct clk msm_clocks_8x50[] = {
CLK_PCOM("tsif_ref_clk", TSIF_REF_CLK, NULL, 0),
CLK_PCOM("tv_dac_clk", TV_DAC_CLK, NULL, 0),
CLK_PCOM("tv_enc_clk", TV_ENC_CLK, NULL, 0),
+ CLK_PCOM("uart_clk", UART1_CLK, &msm_device_uart1.dev, OFF),
+ CLK_PCOM("uart_clk", UART2_CLK, &msm_device_uart2.dev, OFF),
CLK_PCOM("uart_clk", UART3_CLK, &msm_device_uart3.dev, OFF),
CLK_PCOM("usb_hs_clk", USB_HS_CLK, NULL, OFF),
CLK_PCOM("usb_hs_pclk", USB_HS_P_CLK, NULL, OFF),
--
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.
^ permalink raw reply related [flat|nested] 157+ messages in thread* [PATCH 1/7] msm: qsd8x50: add uart platform data
@ 2011-01-20 20:32 ` Daniel Walker
0 siblings, 0 replies; 157+ messages in thread
From: Daniel Walker @ 2011-01-20 20:32 UTC (permalink / raw)
To: linux-arm-kernel
This enables the uart for QSD8x50.
Signed-off-by: Daniel Walker <dwalker@codeaurora.org>
---
arch/arm/mach-msm/devices-qsd8x50.c | 42 +++++++++++++++++++++++++++++++++++
1 files changed, 42 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-msm/devices-qsd8x50.c b/arch/arm/mach-msm/devices-qsd8x50.c
index b1a8f0f..24b2051 100644
--- a/arch/arm/mach-msm/devices-qsd8x50.c
+++ b/arch/arm/mach-msm/devices-qsd8x50.c
@@ -28,6 +28,32 @@
#include <mach/mmc.h>
+static struct resource resources_uart1[] = {
+ {
+ .start = INT_UART1,
+ .end = INT_UART1,
+ .flags = IORESOURCE_IRQ,
+ },
+ {
+ .start = MSM_UART1_PHYS,
+ .end = MSM_UART1_PHYS + MSM_UART1_SIZE - 1,
+ .flags = IORESOURCE_MEM,
+ },
+};
+
+static struct resource resources_uart2[] = {
+ {
+ .start = INT_UART2,
+ .end = INT_UART2,
+ .flags = IORESOURCE_IRQ,
+ },
+ {
+ .start = MSM_UART2_PHYS,
+ .end = MSM_UART2_PHYS + MSM_UART2_SIZE - 1,
+ .flags = IORESOURCE_MEM,
+ },
+};
+
static struct resource resources_uart3[] = {
{
.start = INT_UART3,
@@ -41,6 +67,20 @@ static struct resource resources_uart3[] = {
},
};
+struct platform_device msm_device_uart1 = {
+ .name = "msm_serial",
+ .id = 0,
+ .num_resources = ARRAY_SIZE(resources_uart1),
+ .resource = resources_uart1,
+};
+
+struct platform_device msm_device_uart2 = {
+ .name = "msm_serial",
+ .id = 1,
+ .num_resources = ARRAY_SIZE(resources_uart2),
+ .resource = resources_uart2,
+};
+
struct platform_device msm_device_uart3 = {
.name = "msm_serial",
.id = 2,
@@ -345,6 +385,8 @@ struct clk msm_clocks_8x50[] = {
CLK_PCOM("tsif_ref_clk", TSIF_REF_CLK, NULL, 0),
CLK_PCOM("tv_dac_clk", TV_DAC_CLK, NULL, 0),
CLK_PCOM("tv_enc_clk", TV_ENC_CLK, NULL, 0),
+ CLK_PCOM("uart_clk", UART1_CLK, &msm_device_uart1.dev, OFF),
+ CLK_PCOM("uart_clk", UART2_CLK, &msm_device_uart2.dev, OFF),
CLK_PCOM("uart_clk", UART3_CLK, &msm_device_uart3.dev, OFF),
CLK_PCOM("usb_hs_clk", USB_HS_CLK, NULL, OFF),
CLK_PCOM("usb_hs_pclk", USB_HS_P_CLK, NULL, OFF),
--
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.
^ permalink raw reply related [flat|nested] 157+ messages in thread
* [PATCH 2/7] [ARM] msm: qsd8k memory base is at 0x20000000
2011-01-20 20:32 ` Daniel Walker
@ 2011-01-20 20:32 ` Daniel Walker
-1 siblings, 0 replies; 157+ messages in thread
From: Daniel Walker @ 2011-01-20 20:32 UTC (permalink / raw)
To: linux-arm-msm
Cc: linux-arm-kernel, linux-kernel, davidb, Brian Swetland,
Haley Teng, Dima Zavin
From: Brian Swetland <swetland@google.com>
The memory layout is effective as of AMSS 3170+.
Signed-off-by: Haley Teng <haley_teng@htc.com>
Signed-off-by: Dima Zavin <dima@android.com>
---
arch/arm/mach-msm/Makefile.boot | 5 +++++
1 files changed, 5 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-msm/Makefile.boot b/arch/arm/mach-msm/Makefile.boot
index 24dfbf8..3266727 100644
--- a/arch/arm/mach-msm/Makefile.boot
+++ b/arch/arm/mach-msm/Makefile.boot
@@ -1,3 +1,8 @@
zreladdr-y := 0x10008000
params_phys-y := 0x10000100
initrd_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.
^ permalink raw reply related [flat|nested] 157+ messages in thread
* [PATCH 2/7] [ARM] msm: qsd8k memory base is at 0x20000000
@ 2011-01-20 20:32 ` Daniel Walker
0 siblings, 0 replies; 157+ messages in thread
From: Daniel Walker @ 2011-01-20 20:32 UTC (permalink / raw)
To: linux-arm-kernel
From: Brian Swetland <swetland@google.com>
The memory layout is effective as of AMSS 3170+.
Signed-off-by: Haley Teng <haley_teng@htc.com>
Signed-off-by: Dima Zavin <dima@android.com>
---
arch/arm/mach-msm/Makefile.boot | 5 +++++
1 files changed, 5 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-msm/Makefile.boot b/arch/arm/mach-msm/Makefile.boot
index 24dfbf8..3266727 100644
--- a/arch/arm/mach-msm/Makefile.boot
+++ b/arch/arm/mach-msm/Makefile.boot
@@ -1,3 +1,8 @@
zreladdr-y := 0x10008000
params_phys-y := 0x10000100
initrd_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.
^ permalink raw reply related [flat|nested] 157+ messages in thread
* [PATCH 3/7] msm: qsd8x50: add acpuclock code
2011-01-20 20:32 ` Daniel Walker
@ 2011-01-20 20:32 ` Daniel Walker
-1 siblings, 0 replies; 157+ messages in thread
From: Daniel Walker @ 2011-01-20 20:32 UTC (permalink / raw)
To: linux-arm-msm; +Cc: linux-arm-kernel, linux-kernel, davidb, Daniel Walker
This adds acpuclock-qsd8x50.c from Google. This provides control
over the cpu frequency for qsd8x50 SoCs.
Signed-off-by: Daniel Walker <dwalker@codeaurora.org>
---
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
diff --git a/arch/arm/mach-msm/Makefile b/arch/arm/mach-msm/Makefile
index 94195c1..9fd3a35 100644
--- a/arch/arm/mach-msm/Makefile
+++ b/arch/arm/mach-msm/Makefile
@@ -1,6 +1,5 @@
obj-y += io.o idle.o timer.o
ifndef CONFIG_ARCH_MSM8X60
-obj-y += acpuclock-arm11.o
obj-y += dma.o
endif
@@ -11,6 +10,8 @@ ifndef CONFIG_ARCH_MSM8X60
obj-y += irq.o
endif
endif
+obj-$(CONFIG_ARCH_MSM_ARM11) += acpuclock-arm11.o
+obj-$(CONFIG_ARCH_QSD8X50) += acpuclock-qsd8x50.o
obj-$(CONFIG_ARCH_MSM8X60) += clock-dummy.o iommu.o iommu_dev.o devices-msm8x60-iommu.o
obj-$(CONFIG_MSM_PROC_COMM) += proc_comm.o clock-pcom.o vreg.o
diff --git a/arch/arm/mach-msm/acpuclock-qsd8x50.c b/arch/arm/mach-msm/acpuclock-qsd8x50.c
new file mode 100644
index 0000000..c726b54
--- /dev/null
+++ b/arch/arm/mach-msm/acpuclock-qsd8x50.c
@@ -0,0 +1,457 @@
+/*
+ * Copyright (c) 2009 Google, Inc.
+ * Copyright (c) 2008 QUALCOMM Incorporated.
+ *
+ * This software is licensed under the terms of the GNU General Public
+ * License version 2, as published by the Free Software Foundation, and
+ * may be copied, distributed, and modified under those terms.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ *
+ */
+
+#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)
+
+struct clkctl_acpu_speed {
+ unsigned acpu_khz;
+ unsigned clk_cfg;
+ unsigned clk_sel;
+ unsigned sc_l_value;
+ unsigned lpj;
+ int vdd;
+};
+
+/* 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 */
+
+struct clkctl_acpu_speed acpu_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
+ */
+struct clkctl_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))
+
+struct clkctl_acpu_speed *acpu_mpll = &acpu_freq_tbl[2];
+
+#ifdef CONFIG_CPU_FREQ_TABLE
+static struct cpufreq_frequency_table freq_table[ARRAY_SIZE(acpu_freq_tbl)];
+
+static void __init acpuclk_init_cpufreq_table(void)
+{
+ int i;
+ int vdd;
+ 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
+
+struct clock_state {
+ struct clkctl_acpu_speed *current_speed;
+ struct mutex lock;
+ uint32_t acpu_switch_time_us;
+ uint32_t max_speed_delta_khz;
+ uint32_t vdd_switch_time_us;
+ unsigned long power_collapse_khz;
+ unsigned long wait_for_irq_khz;
+ struct regulator *regulator;
+};
+
+static struct clock_state drv_state = { 0 };
+
+static DEFINE_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
+
+static void scpll_power_down(void)
+{
+ uint32_t val;
+
+ /* 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();
+}
+
+static void scpll_set_freq(uint32_t lval)
+{
+ uint32_t val, 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... */
+static void select_clock(unsigned src, unsigned config)
+{
+ uint32_t val;
+
+ if (src == SRC_RAW) {
+ uint32_t sel = readl(SPSS_CLK_SEL_ADDR);
+ unsigned shift = (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);
+}
+
+static int acpuclk_set_vdd_level(int vdd)
+{
+ 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
+ * to its maximum frequency at its default voltage.
+ */
+ return 0;
+ }
+ pr_info("acpuclk_set_vdd_level got regulator\n");
+ }
+ vdd *= 1000; /* mV -> uV */
+ return regulator_set_voltage(drv_state.regulator, vdd, vdd);
+}
+
+int acpuclk_set_rate(unsigned long rate, int for_power_collapse)
+{
+ struct clkctl_acpu_speed *cur, *next;
+ unsigned long flags;
+
+ 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)
+ return 0;
+
+ 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);
+ }
+
+ return 0;
+}
+
+static unsigned __init acpuclk_find_speed(void)
+{
+ uint32_t sel, val;
+
+ sel = readl(SPSS_CLK_SEL_ADDR);
+ switch ((sel & 6) >> 1) {
+ case 1:
+ val = readl(SCPLL_FSM_CTL_EXT_ADDR);
+ val = (val >> 3) & 0x3f;
+ return val * 38400;
+ case 2:
+ return 128000;
+ default:
+ pr_err("acpu_find_speed: failed\n");
+ BUG();
+ return 0;
+ }
+}
+
+#define PCOM_MODEM_PLL 0
+static int pll_request(unsigned id, unsigned on)
+{
+ on = !!on;
+ return msm_proc_comm(PCOM_CLKCTL_RPC_PLL_REQUEST, &id, &on);
+}
+
+static void __init acpuclk_init(void)
+{
+ struct clkctl_acpu_speed *speed;
+ unsigned init_khz;
+
+ init_khz = acpuclk_find_speed();
+
+ /* request the modem pll, and then drop it. We don't want to keep a
+ * ref to it, but we do want to make sure that it is initialized at
+ * this point. The ARM9 will ensure that the MPLL is always on
+ * once it is fully booted, but it may not be up by the time we get
+ * to here. So, our pll_request for it will block until the mpll is
+ * actually up. We want it up because we will want to use it as a
+ * temporary step during frequency scaling. */
+ 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
+ * for all versions of Scorpion at the moment.
+ */
+ 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
+ * going to step over to the standby clock and make sure
+ * we select the right frequency on SCPLL and then
+ * step back to it, to make sure we're sane here.
+ */
+ 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 __init msm_acpu_clock_init(struct msm_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();
+}
diff --git a/arch/arm/mach-msm/board-mahimahi.c b/arch/arm/mach-msm/board-mahimahi.c
index ef3ebf2..aedb136 100644
--- a/arch/arm/mach-msm/board-mahimahi.c
+++ b/arch/arm/mach-msm/board-mahimahi.c
@@ -48,8 +48,32 @@ static struct platform_device *devices[] __initdata = {
&msm_device_nand,
};
+static struct msm_acpu_clock_platform_data mahimahi_clock_data = {
+ .acpu_switch_time_us = 20,
+ .max_speed_delta_khz = 256000,
+ .vdd_switch_time_us = 62,
+ .power_collapse_khz = 245000,
+ .wait_for_irq_khz = 245000,
+ .mpll_khz = 245000
+};
+
+static struct msm_acpu_clock_platform_data mahimahi_cdma_clock_data = {
+ .acpu_switch_time_us = 20,
+ .max_speed_delta_khz = 256000,
+ .vdd_switch_time_us = 62,
+ .power_collapse_khz = 235930,
+ .wait_for_irq_khz = 235930,
+ .mpll_khz = 235930
+};
+
+
static void __init mahimahi_init(void)
{
+ if (is_cdma_version(system_rev))
+ msm_acpu_clock_init(&mahimahi_cdma_clock_data);
+ else
+ msm_acpu_clock_init(&mahimahi_clock_data);
+
platform_add_devices(devices, ARRAY_SIZE(devices));
}
diff --git a/arch/arm/mach-msm/include/mach/board.h b/arch/arm/mach-msm/include/mach/board.h
index 6abf4a6..44efaf5 100644
--- a/arch/arm/mach-msm/include/mach/board.h
+++ b/arch/arm/mach-msm/include/mach/board.h
@@ -27,6 +27,7 @@ struct msm_acpu_clock_platform_data
uint32_t acpu_switch_time_us;
uint32_t max_speed_delta_khz;
uint32_t vdd_switch_time_us;
+ unsigned long mpll_khz;
unsigned long power_collapse_khz;
unsigned long wait_for_irq_khz;
};
--
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.
^ permalink raw reply related [flat|nested] 157+ messages in thread* [PATCH 3/7] msm: qsd8x50: add acpuclock code
@ 2011-01-20 20:32 ` Daniel Walker
0 siblings, 0 replies; 157+ messages in thread
From: Daniel Walker @ 2011-01-20 20:32 UTC (permalink / raw)
To: linux-arm-kernel
This adds acpuclock-qsd8x50.c from Google. This provides control
over the cpu frequency for qsd8x50 SoCs.
Signed-off-by: Daniel Walker <dwalker@codeaurora.org>
---
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
diff --git a/arch/arm/mach-msm/Makefile b/arch/arm/mach-msm/Makefile
index 94195c1..9fd3a35 100644
--- a/arch/arm/mach-msm/Makefile
+++ b/arch/arm/mach-msm/Makefile
@@ -1,6 +1,5 @@
obj-y += io.o idle.o timer.o
ifndef CONFIG_ARCH_MSM8X60
-obj-y += acpuclock-arm11.o
obj-y += dma.o
endif
@@ -11,6 +10,8 @@ ifndef CONFIG_ARCH_MSM8X60
obj-y += irq.o
endif
endif
+obj-$(CONFIG_ARCH_MSM_ARM11) += acpuclock-arm11.o
+obj-$(CONFIG_ARCH_QSD8X50) += acpuclock-qsd8x50.o
obj-$(CONFIG_ARCH_MSM8X60) += clock-dummy.o iommu.o iommu_dev.o devices-msm8x60-iommu.o
obj-$(CONFIG_MSM_PROC_COMM) += proc_comm.o clock-pcom.o vreg.o
diff --git a/arch/arm/mach-msm/acpuclock-qsd8x50.c b/arch/arm/mach-msm/acpuclock-qsd8x50.c
new file mode 100644
index 0000000..c726b54
--- /dev/null
+++ b/arch/arm/mach-msm/acpuclock-qsd8x50.c
@@ -0,0 +1,457 @@
+/*
+ * Copyright (c) 2009 Google, Inc.
+ * Copyright (c) 2008 QUALCOMM Incorporated.
+ *
+ * This software is licensed under the terms of the GNU General Public
+ * License version 2, as published by the Free Software Foundation, and
+ * may be copied, distributed, and modified under those terms.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ *
+ */
+
+#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)
+
+struct clkctl_acpu_speed {
+ unsigned acpu_khz;
+ unsigned clk_cfg;
+ unsigned clk_sel;
+ unsigned sc_l_value;
+ unsigned lpj;
+ int vdd;
+};
+
+/* 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 */
+
+struct clkctl_acpu_speed acpu_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
+ */
+struct clkctl_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))
+
+struct clkctl_acpu_speed *acpu_mpll = &acpu_freq_tbl[2];
+
+#ifdef CONFIG_CPU_FREQ_TABLE
+static struct cpufreq_frequency_table freq_table[ARRAY_SIZE(acpu_freq_tbl)];
+
+static void __init acpuclk_init_cpufreq_table(void)
+{
+ int i;
+ int vdd;
+ 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
+
+struct clock_state {
+ struct clkctl_acpu_speed *current_speed;
+ struct mutex lock;
+ uint32_t acpu_switch_time_us;
+ uint32_t max_speed_delta_khz;
+ uint32_t vdd_switch_time_us;
+ unsigned long power_collapse_khz;
+ unsigned long wait_for_irq_khz;
+ struct regulator *regulator;
+};
+
+static struct clock_state drv_state = { 0 };
+
+static DEFINE_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
+
+static void scpll_power_down(void)
+{
+ uint32_t val;
+
+ /* 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();
+}
+
+static void scpll_set_freq(uint32_t lval)
+{
+ uint32_t val, 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... */
+static void select_clock(unsigned src, unsigned config)
+{
+ uint32_t val;
+
+ if (src == SRC_RAW) {
+ uint32_t sel = readl(SPSS_CLK_SEL_ADDR);
+ unsigned shift = (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);
+}
+
+static int acpuclk_set_vdd_level(int vdd)
+{
+ 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
+ * to its maximum frequency@its default voltage.
+ */
+ return 0;
+ }
+ pr_info("acpuclk_set_vdd_level got regulator\n");
+ }
+ vdd *= 1000; /* mV -> uV */
+ return regulator_set_voltage(drv_state.regulator, vdd, vdd);
+}
+
+int acpuclk_set_rate(unsigned long rate, int for_power_collapse)
+{
+ struct clkctl_acpu_speed *cur, *next;
+ unsigned long flags;
+
+ 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)
+ return 0;
+
+ 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);
+ }
+
+ return 0;
+}
+
+static unsigned __init acpuclk_find_speed(void)
+{
+ uint32_t sel, val;
+
+ sel = readl(SPSS_CLK_SEL_ADDR);
+ switch ((sel & 6) >> 1) {
+ case 1:
+ val = readl(SCPLL_FSM_CTL_EXT_ADDR);
+ val = (val >> 3) & 0x3f;
+ return val * 38400;
+ case 2:
+ return 128000;
+ default:
+ pr_err("acpu_find_speed: failed\n");
+ BUG();
+ return 0;
+ }
+}
+
+#define PCOM_MODEM_PLL 0
+static int pll_request(unsigned id, unsigned on)
+{
+ on = !!on;
+ return msm_proc_comm(PCOM_CLKCTL_RPC_PLL_REQUEST, &id, &on);
+}
+
+static void __init acpuclk_init(void)
+{
+ struct clkctl_acpu_speed *speed;
+ unsigned init_khz;
+
+ init_khz = acpuclk_find_speed();
+
+ /* request the modem pll, and then drop it. We don't want to keep a
+ * ref to it, but we do want to make sure that it is initialized at
+ * this point. The ARM9 will ensure that the MPLL is always on
+ * once it is fully booted, but it may not be up by the time we get
+ * to here. So, our pll_request for it will block until the mpll is
+ * actually up. We want it up because we will want to use it as a
+ * temporary step during frequency scaling. */
+ 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
+ * for all versions of Scorpion at the moment.
+ */
+ 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
+ * going to step over to the standby clock and make sure
+ * we select the right frequency on SCPLL and then
+ * step back to it, to make sure we're sane here.
+ */
+ 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 __init msm_acpu_clock_init(struct msm_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();
+}
diff --git a/arch/arm/mach-msm/board-mahimahi.c b/arch/arm/mach-msm/board-mahimahi.c
index ef3ebf2..aedb136 100644
--- a/arch/arm/mach-msm/board-mahimahi.c
+++ b/arch/arm/mach-msm/board-mahimahi.c
@@ -48,8 +48,32 @@ static struct platform_device *devices[] __initdata = {
&msm_device_nand,
};
+static struct msm_acpu_clock_platform_data mahimahi_clock_data = {
+ .acpu_switch_time_us = 20,
+ .max_speed_delta_khz = 256000,
+ .vdd_switch_time_us = 62,
+ .power_collapse_khz = 245000,
+ .wait_for_irq_khz = 245000,
+ .mpll_khz = 245000
+};
+
+static struct msm_acpu_clock_platform_data mahimahi_cdma_clock_data = {
+ .acpu_switch_time_us = 20,
+ .max_speed_delta_khz = 256000,
+ .vdd_switch_time_us = 62,
+ .power_collapse_khz = 235930,
+ .wait_for_irq_khz = 235930,
+ .mpll_khz = 235930
+};
+
+
static void __init mahimahi_init(void)
{
+ if (is_cdma_version(system_rev))
+ msm_acpu_clock_init(&mahimahi_cdma_clock_data);
+ else
+ msm_acpu_clock_init(&mahimahi_clock_data);
+
platform_add_devices(devices, ARRAY_SIZE(devices));
}
diff --git a/arch/arm/mach-msm/include/mach/board.h b/arch/arm/mach-msm/include/mach/board.h
index 6abf4a6..44efaf5 100644
--- a/arch/arm/mach-msm/include/mach/board.h
+++ b/arch/arm/mach-msm/include/mach/board.h
@@ -27,6 +27,7 @@ struct msm_acpu_clock_platform_data
uint32_t acpu_switch_time_us;
uint32_t max_speed_delta_khz;
uint32_t vdd_switch_time_us;
+ unsigned long mpll_khz;
unsigned long power_collapse_khz;
unsigned long wait_for_irq_khz;
};
--
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.
^ permalink raw reply related [flat|nested] 157+ messages in thread
* [PATCH 4/7] msm: mahimahi: add mahimahi board file
2011-01-20 20:32 ` Daniel Walker
@ 2011-01-20 20:32 ` Daniel Walker
-1 siblings, 0 replies; 157+ messages in thread
From: Daniel Walker @ 2011-01-20 20:32 UTC (permalink / raw)
To: linux-arm-msm; +Cc: linux-arm-kernel, linux-kernel, davidb, Daniel Walker
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 <dwalker@codeaurora.org>
---
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
diff --git a/arch/arm/mach-msm/Kconfig b/arch/arm/mach-msm/Kconfig
index 5d3d9ad..0bb8173 100644
--- a/arch/arm/mach-msm/Kconfig
+++ b/arch/arm/mach-msm/Kconfig
@@ -27,7 +27,7 @@ config ARCH_MSM7X30
config ARCH_QSD8X50
bool "QSD8X50"
- select MACH_QSD8X50_SURF if !MACH_QSD8X50A_ST1_5
+ select MACH_QSD8X50_SURF if (!MACH_QSD8X50A_ST1_5 && !MACH_MAHIMAHI)
select ARCH_MSM_SCORPION
select MSM_SMD
select MSM_VIC
@@ -88,6 +88,12 @@ config MACH_MSM7X30_SURF
help
Support for the Qualcomm MSM7x30 SURF eval board.
+config MACH_MAHIMAHI
+ depends on ARCH_QSD8X50
+ bool "HTC Passion/Nexus One"
+ help
+ Select this to support an HTC Passion/Nexus One phone.
+
config MACH_QSD8X50_SURF
depends on ARCH_QSD8X50
bool "QSD8x50 SURF"
diff --git a/arch/arm/mach-msm/Makefile b/arch/arm/mach-msm/Makefile
index 9fd3a35..a0ebce4 100644
--- a/arch/arm/mach-msm/Makefile
+++ b/arch/arm/mach-msm/Makefile
@@ -30,6 +30,7 @@ obj-$(CONFIG_MACH_HALIBUT) += board-halibut.o devices-msm7x00.o
obj-$(CONFIG_ARCH_MSM7X30) += board-msm7x30.o devices-msm7x30.o
obj-$(CONFIG_ARCH_QSD8X50) += board-qsd8x50.o devices-qsd8x50.o
obj-$(CONFIG_ARCH_MSM8X60) += board-msm8x60.o
+obj-$(CONFIG_MACH_MAHIMAHI) += board-mahimahi.o
obj-$(CONFIG_ARCH_MSM7X30) += gpiomux-7x30.o gpiomux-v1.o gpiomux.o
obj-$(CONFIG_ARCH_QSD8X50) += gpiomux-8x50.o gpiomux-v1.o gpiomux.o
diff --git a/arch/arm/mach-msm/board-mahimahi.c b/arch/arm/mach-msm/board-mahimahi.c
index aedb136..c1745c7 100644
--- a/arch/arm/mach-msm/board-mahimahi.c
+++ b/arch/arm/mach-msm/board-mahimahi.c
@@ -41,11 +41,7 @@ static uint debug_uart;
module_param_named(debug_uart, debug_uart, uint, 0);
static struct platform_device *devices[] __initdata = {
-#if !defined(CONFIG_MSM_SERIAL_DEBUGGER)
&msm_device_uart1,
-#endif
- &msm_device_uart_dm1,
- &msm_device_nand,
};
static struct msm_acpu_clock_platform_data mahimahi_clock_data = {
@@ -82,28 +78,30 @@ static void __init mahimahi_fixup(struct machine_desc *desc, struct tag *tags,
{
mi->nr_banks = 2;
mi->bank[0].start = PHYS_OFFSET;
- mi->bank[0].node = PHYS_TO_NID(PHYS_OFFSET);
mi->bank[0].size = (219*1024*1024);
mi->bank[1].start = MSM_HIGHMEM_BASE;
- mi->bank[1].node = PHYS_TO_NID(MSM_HIGHMEM_BASE);
mi->bank[1].size = MSM_HIGHMEM_SIZE;
}
static void __init mahimahi_map_io(void)
{
- msm_map_common_io();
- msm_clock_init();
+ msm_map_qsd8x50_io();
+ msm_clock_init(msm_clocks_8x50, msm_num_clocks_8x50);
+}
+
+static void __init mahimahi_init_irq(void)
+{
+ msm_init_irq();
+ msm_init_sirc();
}
extern struct sys_timer msm_timer;
MACHINE_START(MAHIMAHI, "mahimahi")
-#ifdef CONFIG_MSM_DEBUG_UART
-#endif
.boot_params = 0x20000100,
.fixup = mahimahi_fixup,
.map_io = mahimahi_map_io,
- .init_irq = msm_init_irq,
+ .init_irq = mahimahi_init_irq,
.init_machine = mahimahi_init,
.timer = &msm_timer,
MACHINE_END
diff --git a/arch/arm/mach-msm/board-mahimahi.h b/arch/arm/mach-msm/board-mahimahi.h
new file mode 100644
index 0000000..e2a8b14
--- /dev/null
+++ b/arch/arm/mach-msm/board-mahimahi.h
@@ -0,0 +1,147 @@
+/* arch/arm/mach-msm/board-mahimahi.h
+ *
+ * Copyright (C) 2009 HTC Corporation.
+ * Author: Haley Teng <Haley_Teng@htc.com>
+ *
+ * This software is licensed under the terms of the GNU General Public
+ * License version 2, as published by the Free Software Foundation, and
+ * may be copied, distributed, and modified under those terms.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+*/
+
+#ifndef __ARCH_ARM_MACH_MSM_BOARD_MAHIMAHI_H
+#define __ARCH_ARM_MACH_MSM_BOARD_MAHIMAHI_H
+
+#include <mach/board.h>
+
+#define MSM_RAM_CONSOLE_BASE 0x03A00000
+#define MSM_RAM_CONSOLE_SIZE 0x00040000
+
+#define MSM_FB_BASE 0x03B00000
+#define MSM_FB_SIZE 0x00465000
+
+#define MSM_EBI1_BANK0_BASE 0x20000000
+#define MSM_EBI1_BANK0_SIZE 0x0E000000
+
+#define MSM_GPU_MEM_BASE 0x2DB00000
+#define MSM_GPU_MEM_SIZE 0x00500000
+
+#define MSM_EBI1_BANK1_BASE 0x30000000
+#define MSM_EBI1_BANK1_SIZE 0x10000000
+
+#define MSM_PMEM_MDP_BASE 0x30000000
+#define MSM_PMEM_MDP_SIZE 0x02000000
+
+#define MSM_PMEM_ADSP_BASE 0x32000000
+#define MSM_PMEM_ADSP_SIZE 0x02900000
+
+#define MSM_PMEM_CAMERA_BASE 0x34900000
+#define MSM_PMEM_CAMERA_SIZE 0x00800000
+
+#define MSM_HIGHMEM_BASE 0x35100000
+#define MSM_HIGHMEM_SIZE 0x0AF00000
+
+#define MAHIMAHI_GPIO_PS_HOLD 25
+
+#define MAHIMAHI_GPIO_UP_INT_N 35
+#define MAHIMAHI_GPIO_UP_RESET_N 82
+#define MAHIMAHI_GPIO_LS_EN_N 119
+
+#define MAHIMAHI_GPIO_TP_INT_N 92
+#define MAHIMAHI_GPIO_TP_LS_EN 93
+#define MAHIMAHI_GPIO_TP_EN 160
+
+#define MAHIMAHI_GPIO_POWER_KEY 94
+#define MAHIMAHI_GPIO_SDMC_CD_REV0_N 153
+
+#define MAHIMAHI_GPIO_WIFI_SHUTDOWN_N 127
+#define MAHIMAHI_GPIO_WIFI_IRQ 152
+
+#define MAHIMAHI_GPIO_BALL_UP 38
+#define MAHIMAHI_GPIO_BALL_DOWN 37
+#define MAHIMAHI_GPIO_BALL_LEFT 145
+#define MAHIMAHI_GPIO_BALL_RIGHT 21
+
+#define MAHIMAHI_GPIO_BT_UART1_RTS 43
+#define MAHIMAHI_GPIO_BT_UART1_CTS 44
+#define MAHIMAHI_GPIO_BT_UART1_RX 45
+#define MAHIMAHI_GPIO_BT_UART1_TX 46
+#define MAHIMAHI_GPIO_BT_RESET_N 146
+#define MAHIMAHI_GPIO_BT_SHUTDOWN_N 128
+
+#define MAHIMAHI_GPIO_BT_WAKE 57
+#define MAHIMAHI_GPIO_BT_HOST_WAKE 86
+
+#define MAHIMAHI_GPIO_PROXIMITY_INT_N 90
+#define MAHIMAHI_GPIO_PROXIMITY_EN 120
+
+#define MAHIMAHI_GPIO_DS2482_SLP_N 87
+#define MAHIMAHI_GPIO_VIBRATOR_ON 89
+/* Compass */
+#define MAHIMAHI_REV0_GPIO_COMPASS_INT_N 36
+
+#define MAHIMAHI_GPIO_COMPASS_INT_N 153
+#define MAHIMAHI_GPIO_COMPASS_RST_N 107
+#define MAHIMAHI_PROJECT_NAME "mahimahi"
+#define MAHIMAHI_LAYOUTS { \
+ { {-1, 0, 0}, { 0, -1, 0}, {0, 0, 1} }, \
+ { { 0, -1, 0}, { 1, 0, 0}, {0, 0, -1} }, \
+ { { 0, -1, 0}, { 1, 0, 0}, {0, 0, 1} }, \
+ { {-1, 0, 0}, { 0, 0, -1}, {0, 1, 0} } \
+}
+
+/* Audio */
+#define MAHIMAHI_AUD_JACKHP_EN 157
+#define MAHIMAHI_AUD_2V5_EN 158
+#define MAHIMAHI_AUD_MICPATH_SEL 111
+#define MAHIMAHI_AUD_A1026_INT 112
+#define MAHIMAHI_AUD_A1026_WAKEUP 113
+#define MAHIMAHI_AUD_A1026_RESET 129
+#define MAHIMAHI_AUD_A1026_CLK -1
+#define MAHIMAHI_CDMA_XA_AUD_A1026_CLK 105
+/* NOTE: MAHIMAHI_CDMA_XB_AUD_A1026_WAKEUP on CDMA is the same GPIO as
+ * MAHIMAHI_GPIO_BATTERY_CHARGER_CURRENT on UMTS. Also,
+ * MAHIMAHI_CDMA_XB_AUD_A1026_RESET is the same as
+ * GPIO MAHIMAHI_GPIO_35MM_KEY_INT_SHUTDOWN on UMTS.
+ */
+#define MAHIMAHI_CDMA_XB_AUD_A1026_WAKEUP 16
+#define MAHIMAHI_CDMA_XB_AUD_A1026_RESET 19
+#define MAHIMAHI_CDMA_XB_AUD_A1026_CLK -1
+
+/* Bluetooth PCM */
+#define MAHIMAHI_BT_PCM_OUT 68
+#define MAHIMAHI_BT_PCM_IN 69
+#define MAHIMAHI_BT_PCM_SYNC 70
+#define MAHIMAHI_BT_PCM_CLK 71
+/* flash light */
+#define MAHIMAHI_GPIO_FLASHLIGHT_TORCH 58
+#define MAHIMAHI_GPIO_FLASHLIGHT_FLASH 84
+
+#define MAHIMAHI_GPIO_LED_3V3_EN 85
+#define MAHIMAHI_GPIO_LCD_RST_N 29
+
+/* 3.5mm remote control key interrupt shutdown signal */
+#define MAHIMAHI_GPIO_35MM_KEY_INT_SHUTDOWN 19
+
+#define MAHIMAHI_GPIO_DOCK 106
+
+/* speaker amplifier enable pin for mahimahi CDMA version */
+#define MAHIMAHI_CDMA_GPIO_AUD_SPK_AMP_EN 104
+
+#define MAHIMAHI_GPIO_BATTERY_DETECTION 39
+#define MAHIMAHI_GPIO_BATTERY_CHARGER_EN 22
+#define MAHIMAHI_GPIO_BATTERY_CHARGER_CURRENT 16
+
+#define MAHIMAHI_CDMA_GPIO_BT_WAKE 28
+#define MAHIMAHI_CDMA_GPIO_FLASHLIGHT_TORCH 26
+
+#define MAHIMAHI_CDMA_SD_2V85_EN 100
+#define MAHIMAHI_CDMA_JOG_2V6_EN 150
+
+#define is_cdma_version(rev) (((rev) & 0xF0) == 0xC0)
+
+#endif /* __ARCH_ARM_MACH_MSM_BOARD_MAHIMAHI_H */
--
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.
^ permalink raw reply related [flat|nested] 157+ messages in thread* [PATCH 4/7] msm: mahimahi: add mahimahi board file
@ 2011-01-20 20:32 ` Daniel Walker
0 siblings, 0 replies; 157+ messages in thread
From: Daniel Walker @ 2011-01-20 20:32 UTC (permalink / raw)
To: linux-arm-kernel
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 <dwalker@codeaurora.org>
---
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
diff --git a/arch/arm/mach-msm/Kconfig b/arch/arm/mach-msm/Kconfig
index 5d3d9ad..0bb8173 100644
--- a/arch/arm/mach-msm/Kconfig
+++ b/arch/arm/mach-msm/Kconfig
@@ -27,7 +27,7 @@ config ARCH_MSM7X30
config ARCH_QSD8X50
bool "QSD8X50"
- select MACH_QSD8X50_SURF if !MACH_QSD8X50A_ST1_5
+ select MACH_QSD8X50_SURF if (!MACH_QSD8X50A_ST1_5 && !MACH_MAHIMAHI)
select ARCH_MSM_SCORPION
select MSM_SMD
select MSM_VIC
@@ -88,6 +88,12 @@ config MACH_MSM7X30_SURF
help
Support for the Qualcomm MSM7x30 SURF eval board.
+config MACH_MAHIMAHI
+ depends on ARCH_QSD8X50
+ bool "HTC Passion/Nexus One"
+ help
+ Select this to support an HTC Passion/Nexus One phone.
+
config MACH_QSD8X50_SURF
depends on ARCH_QSD8X50
bool "QSD8x50 SURF"
diff --git a/arch/arm/mach-msm/Makefile b/arch/arm/mach-msm/Makefile
index 9fd3a35..a0ebce4 100644
--- a/arch/arm/mach-msm/Makefile
+++ b/arch/arm/mach-msm/Makefile
@@ -30,6 +30,7 @@ obj-$(CONFIG_MACH_HALIBUT) += board-halibut.o devices-msm7x00.o
obj-$(CONFIG_ARCH_MSM7X30) += board-msm7x30.o devices-msm7x30.o
obj-$(CONFIG_ARCH_QSD8X50) += board-qsd8x50.o devices-qsd8x50.o
obj-$(CONFIG_ARCH_MSM8X60) += board-msm8x60.o
+obj-$(CONFIG_MACH_MAHIMAHI) += board-mahimahi.o
obj-$(CONFIG_ARCH_MSM7X30) += gpiomux-7x30.o gpiomux-v1.o gpiomux.o
obj-$(CONFIG_ARCH_QSD8X50) += gpiomux-8x50.o gpiomux-v1.o gpiomux.o
diff --git a/arch/arm/mach-msm/board-mahimahi.c b/arch/arm/mach-msm/board-mahimahi.c
index aedb136..c1745c7 100644
--- a/arch/arm/mach-msm/board-mahimahi.c
+++ b/arch/arm/mach-msm/board-mahimahi.c
@@ -41,11 +41,7 @@ static uint debug_uart;
module_param_named(debug_uart, debug_uart, uint, 0);
static struct platform_device *devices[] __initdata = {
-#if !defined(CONFIG_MSM_SERIAL_DEBUGGER)
&msm_device_uart1,
-#endif
- &msm_device_uart_dm1,
- &msm_device_nand,
};
static struct msm_acpu_clock_platform_data mahimahi_clock_data = {
@@ -82,28 +78,30 @@ static void __init mahimahi_fixup(struct machine_desc *desc, struct tag *tags,
{
mi->nr_banks = 2;
mi->bank[0].start = PHYS_OFFSET;
- mi->bank[0].node = PHYS_TO_NID(PHYS_OFFSET);
mi->bank[0].size = (219*1024*1024);
mi->bank[1].start = MSM_HIGHMEM_BASE;
- mi->bank[1].node = PHYS_TO_NID(MSM_HIGHMEM_BASE);
mi->bank[1].size = MSM_HIGHMEM_SIZE;
}
static void __init mahimahi_map_io(void)
{
- msm_map_common_io();
- msm_clock_init();
+ msm_map_qsd8x50_io();
+ msm_clock_init(msm_clocks_8x50, msm_num_clocks_8x50);
+}
+
+static void __init mahimahi_init_irq(void)
+{
+ msm_init_irq();
+ msm_init_sirc();
}
extern struct sys_timer msm_timer;
MACHINE_START(MAHIMAHI, "mahimahi")
-#ifdef CONFIG_MSM_DEBUG_UART
-#endif
.boot_params = 0x20000100,
.fixup = mahimahi_fixup,
.map_io = mahimahi_map_io,
- .init_irq = msm_init_irq,
+ .init_irq = mahimahi_init_irq,
.init_machine = mahimahi_init,
.timer = &msm_timer,
MACHINE_END
diff --git a/arch/arm/mach-msm/board-mahimahi.h b/arch/arm/mach-msm/board-mahimahi.h
new file mode 100644
index 0000000..e2a8b14
--- /dev/null
+++ b/arch/arm/mach-msm/board-mahimahi.h
@@ -0,0 +1,147 @@
+/* arch/arm/mach-msm/board-mahimahi.h
+ *
+ * Copyright (C) 2009 HTC Corporation.
+ * Author: Haley Teng <Haley_Teng@htc.com>
+ *
+ * This software is licensed under the terms of the GNU General Public
+ * License version 2, as published by the Free Software Foundation, and
+ * may be copied, distributed, and modified under those terms.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+*/
+
+#ifndef __ARCH_ARM_MACH_MSM_BOARD_MAHIMAHI_H
+#define __ARCH_ARM_MACH_MSM_BOARD_MAHIMAHI_H
+
+#include <mach/board.h>
+
+#define MSM_RAM_CONSOLE_BASE 0x03A00000
+#define MSM_RAM_CONSOLE_SIZE 0x00040000
+
+#define MSM_FB_BASE 0x03B00000
+#define MSM_FB_SIZE 0x00465000
+
+#define MSM_EBI1_BANK0_BASE 0x20000000
+#define MSM_EBI1_BANK0_SIZE 0x0E000000
+
+#define MSM_GPU_MEM_BASE 0x2DB00000
+#define MSM_GPU_MEM_SIZE 0x00500000
+
+#define MSM_EBI1_BANK1_BASE 0x30000000
+#define MSM_EBI1_BANK1_SIZE 0x10000000
+
+#define MSM_PMEM_MDP_BASE 0x30000000
+#define MSM_PMEM_MDP_SIZE 0x02000000
+
+#define MSM_PMEM_ADSP_BASE 0x32000000
+#define MSM_PMEM_ADSP_SIZE 0x02900000
+
+#define MSM_PMEM_CAMERA_BASE 0x34900000
+#define MSM_PMEM_CAMERA_SIZE 0x00800000
+
+#define MSM_HIGHMEM_BASE 0x35100000
+#define MSM_HIGHMEM_SIZE 0x0AF00000
+
+#define MAHIMAHI_GPIO_PS_HOLD 25
+
+#define MAHIMAHI_GPIO_UP_INT_N 35
+#define MAHIMAHI_GPIO_UP_RESET_N 82
+#define MAHIMAHI_GPIO_LS_EN_N 119
+
+#define MAHIMAHI_GPIO_TP_INT_N 92
+#define MAHIMAHI_GPIO_TP_LS_EN 93
+#define MAHIMAHI_GPIO_TP_EN 160
+
+#define MAHIMAHI_GPIO_POWER_KEY 94
+#define MAHIMAHI_GPIO_SDMC_CD_REV0_N 153
+
+#define MAHIMAHI_GPIO_WIFI_SHUTDOWN_N 127
+#define MAHIMAHI_GPIO_WIFI_IRQ 152
+
+#define MAHIMAHI_GPIO_BALL_UP 38
+#define MAHIMAHI_GPIO_BALL_DOWN 37
+#define MAHIMAHI_GPIO_BALL_LEFT 145
+#define MAHIMAHI_GPIO_BALL_RIGHT 21
+
+#define MAHIMAHI_GPIO_BT_UART1_RTS 43
+#define MAHIMAHI_GPIO_BT_UART1_CTS 44
+#define MAHIMAHI_GPIO_BT_UART1_RX 45
+#define MAHIMAHI_GPIO_BT_UART1_TX 46
+#define MAHIMAHI_GPIO_BT_RESET_N 146
+#define MAHIMAHI_GPIO_BT_SHUTDOWN_N 128
+
+#define MAHIMAHI_GPIO_BT_WAKE 57
+#define MAHIMAHI_GPIO_BT_HOST_WAKE 86
+
+#define MAHIMAHI_GPIO_PROXIMITY_INT_N 90
+#define MAHIMAHI_GPIO_PROXIMITY_EN 120
+
+#define MAHIMAHI_GPIO_DS2482_SLP_N 87
+#define MAHIMAHI_GPIO_VIBRATOR_ON 89
+/* Compass */
+#define MAHIMAHI_REV0_GPIO_COMPASS_INT_N 36
+
+#define MAHIMAHI_GPIO_COMPASS_INT_N 153
+#define MAHIMAHI_GPIO_COMPASS_RST_N 107
+#define MAHIMAHI_PROJECT_NAME "mahimahi"
+#define MAHIMAHI_LAYOUTS { \
+ { {-1, 0, 0}, { 0, -1, 0}, {0, 0, 1} }, \
+ { { 0, -1, 0}, { 1, 0, 0}, {0, 0, -1} }, \
+ { { 0, -1, 0}, { 1, 0, 0}, {0, 0, 1} }, \
+ { {-1, 0, 0}, { 0, 0, -1}, {0, 1, 0} } \
+}
+
+/* Audio */
+#define MAHIMAHI_AUD_JACKHP_EN 157
+#define MAHIMAHI_AUD_2V5_EN 158
+#define MAHIMAHI_AUD_MICPATH_SEL 111
+#define MAHIMAHI_AUD_A1026_INT 112
+#define MAHIMAHI_AUD_A1026_WAKEUP 113
+#define MAHIMAHI_AUD_A1026_RESET 129
+#define MAHIMAHI_AUD_A1026_CLK -1
+#define MAHIMAHI_CDMA_XA_AUD_A1026_CLK 105
+/* NOTE: MAHIMAHI_CDMA_XB_AUD_A1026_WAKEUP on CDMA is the same GPIO as
+ * MAHIMAHI_GPIO_BATTERY_CHARGER_CURRENT on UMTS. Also,
+ * MAHIMAHI_CDMA_XB_AUD_A1026_RESET is the same as
+ * GPIO MAHIMAHI_GPIO_35MM_KEY_INT_SHUTDOWN on UMTS.
+ */
+#define MAHIMAHI_CDMA_XB_AUD_A1026_WAKEUP 16
+#define MAHIMAHI_CDMA_XB_AUD_A1026_RESET 19
+#define MAHIMAHI_CDMA_XB_AUD_A1026_CLK -1
+
+/* Bluetooth PCM */
+#define MAHIMAHI_BT_PCM_OUT 68
+#define MAHIMAHI_BT_PCM_IN 69
+#define MAHIMAHI_BT_PCM_SYNC 70
+#define MAHIMAHI_BT_PCM_CLK 71
+/* flash light */
+#define MAHIMAHI_GPIO_FLASHLIGHT_TORCH 58
+#define MAHIMAHI_GPIO_FLASHLIGHT_FLASH 84
+
+#define MAHIMAHI_GPIO_LED_3V3_EN 85
+#define MAHIMAHI_GPIO_LCD_RST_N 29
+
+/* 3.5mm remote control key interrupt shutdown signal */
+#define MAHIMAHI_GPIO_35MM_KEY_INT_SHUTDOWN 19
+
+#define MAHIMAHI_GPIO_DOCK 106
+
+/* speaker amplifier enable pin for mahimahi CDMA version */
+#define MAHIMAHI_CDMA_GPIO_AUD_SPK_AMP_EN 104
+
+#define MAHIMAHI_GPIO_BATTERY_DETECTION 39
+#define MAHIMAHI_GPIO_BATTERY_CHARGER_EN 22
+#define MAHIMAHI_GPIO_BATTERY_CHARGER_CURRENT 16
+
+#define MAHIMAHI_CDMA_GPIO_BT_WAKE 28
+#define MAHIMAHI_CDMA_GPIO_FLASHLIGHT_TORCH 26
+
+#define MAHIMAHI_CDMA_SD_2V85_EN 100
+#define MAHIMAHI_CDMA_JOG_2V6_EN 150
+
+#define is_cdma_version(rev) (((rev) & 0xF0) == 0xC0)
+
+#endif /* __ARCH_ARM_MACH_MSM_BOARD_MAHIMAHI_H */
--
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.
^ permalink raw reply related [flat|nested] 157+ messages in thread
* [PATCH 5/7] msm: mahimahi: add in mmc support code
2011-01-20 20:32 ` Daniel Walker
@ 2011-01-20 20:32 ` Daniel Walker
-1 siblings, 0 replies; 157+ messages in thread
From: Daniel Walker @ 2011-01-20 20:32 UTC (permalink / raw)
To: linux-arm-msm; +Cc: linux-arm-kernel, linux-kernel, davidb, Daniel Walker
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 <dwalker@codeaurora.org>
---
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
diff --git a/arch/arm/mach-msm/Makefile b/arch/arm/mach-msm/Makefile
index a0ebce4..5012c37 100644
--- a/arch/arm/mach-msm/Makefile
+++ b/arch/arm/mach-msm/Makefile
@@ -31,6 +31,7 @@ obj-$(CONFIG_ARCH_MSM7X30) += board-msm7x30.o devices-msm7x30.o
obj-$(CONFIG_ARCH_QSD8X50) += board-qsd8x50.o devices-qsd8x50.o
obj-$(CONFIG_ARCH_MSM8X60) += board-msm8x60.o
obj-$(CONFIG_MACH_MAHIMAHI) += board-mahimahi.o
+obj-$(CONFIG_MACH_MAHIMAHI) += board-mahimahi-mmc.o
obj-$(CONFIG_ARCH_MSM7X30) += gpiomux-7x30.o gpiomux-v1.o gpiomux.o
obj-$(CONFIG_ARCH_QSD8X50) += gpiomux-8x50.o gpiomux-v1.o gpiomux.o
diff --git a/arch/arm/mach-msm/board-mahimahi-mmc.c b/arch/arm/mach-msm/board-mahimahi-mmc.c
new file mode 100644
index 0000000..991818e
--- /dev/null
+++ b/arch/arm/mach-msm/board-mahimahi-mmc.c
@@ -0,0 +1,206 @@
+/* linux/arch/arm/mach-msm/board-mahimahi-mmc.c
+ *
+ * Copyright (C) 2009 Google, Inc.
+ * Copyright (C) 2009 HTC Corporation
+ *
+ * This software is licensed under the terms of the GNU General Public
+ * License version 2, as published by the Free Software Foundation, and
+ * may be copied, distributed, and modified under those terms.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ *
+ */
+
+#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"
+
+static bool opt_disable_sdcard;
+static int __init mahimahi_disablesdcard_setup(char *str)
+{
+ opt_disable_sdcard = (bool)simple_strtol(str, NULL, 0);
+ return 1;
+}
+
+__setup("board_mahimahi.disable_sdcard=", mahimahi_disablesdcard_setup);
+
+static struct msm_mmc_gpio sdc1_gpio_cfg[] = {
+ {62, "sdc1_clk"},
+ {63, "sdc1_cmd"},
+ {64, "sdc1_dat_3"},
+ {65, "sdc1_dat_2"},
+ {66, "sdc1_dat_1"},
+ {67, "sdc1_dat_0"},
+};
+
+static struct vreg *sdslot_vreg;
+static uint32_t sdslot_vdd = 0xffffffff;
+static uint32_t sdslot_vreg_enabled;
+
+static struct {
+ int mask;
+ int level;
+} 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 },
+};
+
+static uint32_t mahimahi_sdslot_switchvdd(struct device *dev, unsigned int vdd)
+{
+ int i;
+ int ret;
+
+ if (vdd == sdslot_vdd)
+ return 0;
+
+ sdslot_vdd = vdd;
+
+ if (vdd == 0) {
+ vreg_disable(sdslot_vreg);
+ sdslot_vreg_enabled = 0;
+ return 0;
+ }
+
+ 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);
+ return 0;
+ }
+
+ pr_err("Invalid VDD (%d) specified\n", vdd);
+ return 0;
+}
+
+static uint32_t
+mahimahi_cdma_sdslot_switchvdd(struct device *dev, unsigned int vdd)
+{
+ if (!vdd == !sdslot_vdd)
+ return 0;
+
+ /* In CDMA version, the vdd of sdslot is not configurable, and it is
+ * fixed in 2.85V by hardware design.
+ */
+
+ 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;
+
+ return 0;
+}
+
+static unsigned int mahimahi_sdslot_status_rev0(struct device *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)
+
+static struct msm_mmc_gpio_data sdc1_gpio =
+ .gpio = sdc1_gpio_cfg,
+ .size = ARRAY_SIZE(sdc1_gpio_cfg),
+};
+
+static struct msm_mmc_platform_data mahimahi_sdslot_data = {
+ .ocr_mask = MAHIMAHI_MMC_VDD,
+ .translate_vdd = mahimahi_sdslot_switchvdd,
+ .gpio_data = &sdc1_gpio,
+};
+
+int msm_add_sdcc(unsigned int controller, struct msm_mmc_platform_data *plat,
+ unsigned int stat_irq, unsigned long stat_irq_flags);
+
+int __init mahimahi_init_mmc(unsigned int sys_rev, unsigned debug_uart)
+{
+ uint32_t id;
+
+ if (debug_uart) {
+ pr_info("%s: sdcard disabled due to debug uart\n", __func__);
+ goto done;
+ }
+ if (opt_disable_sdcard) {
+ pr_info("%s: sdcard disabled on cmdline\n", __func__);
+ goto done;
+ }
+
+ sdslot_vreg_enabled = 0;
+
+ if (is_cdma_version(sys_rev)) {
+ /* In the CDMA version, sdslot is supplied by a gpio. */
+ int rc = 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);
+ return rc;
+ }
+ 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))
+ return PTR_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:
+ return 0;
+}
--
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.
^ permalink raw reply related [flat|nested] 157+ messages in thread* [PATCH 5/7] msm: mahimahi: add in mmc support code
@ 2011-01-20 20:32 ` Daniel Walker
0 siblings, 0 replies; 157+ messages in thread
From: Daniel Walker @ 2011-01-20 20:32 UTC (permalink / raw)
To: linux-arm-kernel
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 <dwalker@codeaurora.org>
---
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
diff --git a/arch/arm/mach-msm/Makefile b/arch/arm/mach-msm/Makefile
index a0ebce4..5012c37 100644
--- a/arch/arm/mach-msm/Makefile
+++ b/arch/arm/mach-msm/Makefile
@@ -31,6 +31,7 @@ obj-$(CONFIG_ARCH_MSM7X30) += board-msm7x30.o devices-msm7x30.o
obj-$(CONFIG_ARCH_QSD8X50) += board-qsd8x50.o devices-qsd8x50.o
obj-$(CONFIG_ARCH_MSM8X60) += board-msm8x60.o
obj-$(CONFIG_MACH_MAHIMAHI) += board-mahimahi.o
+obj-$(CONFIG_MACH_MAHIMAHI) += board-mahimahi-mmc.o
obj-$(CONFIG_ARCH_MSM7X30) += gpiomux-7x30.o gpiomux-v1.o gpiomux.o
obj-$(CONFIG_ARCH_QSD8X50) += gpiomux-8x50.o gpiomux-v1.o gpiomux.o
diff --git a/arch/arm/mach-msm/board-mahimahi-mmc.c b/arch/arm/mach-msm/board-mahimahi-mmc.c
new file mode 100644
index 0000000..991818e
--- /dev/null
+++ b/arch/arm/mach-msm/board-mahimahi-mmc.c
@@ -0,0 +1,206 @@
+/* linux/arch/arm/mach-msm/board-mahimahi-mmc.c
+ *
+ * Copyright (C) 2009 Google, Inc.
+ * Copyright (C) 2009 HTC Corporation
+ *
+ * This software is licensed under the terms of the GNU General Public
+ * License version 2, as published by the Free Software Foundation, and
+ * may be copied, distributed, and modified under those terms.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ *
+ */
+
+#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"
+
+static bool opt_disable_sdcard;
+static int __init mahimahi_disablesdcard_setup(char *str)
+{
+ opt_disable_sdcard = (bool)simple_strtol(str, NULL, 0);
+ return 1;
+}
+
+__setup("board_mahimahi.disable_sdcard=", mahimahi_disablesdcard_setup);
+
+static struct msm_mmc_gpio sdc1_gpio_cfg[] = {
+ {62, "sdc1_clk"},
+ {63, "sdc1_cmd"},
+ {64, "sdc1_dat_3"},
+ {65, "sdc1_dat_2"},
+ {66, "sdc1_dat_1"},
+ {67, "sdc1_dat_0"},
+};
+
+static struct vreg *sdslot_vreg;
+static uint32_t sdslot_vdd = 0xffffffff;
+static uint32_t sdslot_vreg_enabled;
+
+static struct {
+ int mask;
+ int level;
+} 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 },
+};
+
+static uint32_t mahimahi_sdslot_switchvdd(struct device *dev, unsigned int vdd)
+{
+ int i;
+ int ret;
+
+ if (vdd == sdslot_vdd)
+ return 0;
+
+ sdslot_vdd = vdd;
+
+ if (vdd == 0) {
+ vreg_disable(sdslot_vreg);
+ sdslot_vreg_enabled = 0;
+ return 0;
+ }
+
+ 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);
+ return 0;
+ }
+
+ pr_err("Invalid VDD (%d) specified\n", vdd);
+ return 0;
+}
+
+static uint32_t
+mahimahi_cdma_sdslot_switchvdd(struct device *dev, unsigned int vdd)
+{
+ if (!vdd == !sdslot_vdd)
+ return 0;
+
+ /* In CDMA version, the vdd of sdslot is not configurable, and it is
+ * fixed in 2.85V by hardware design.
+ */
+
+ 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;
+
+ return 0;
+}
+
+static unsigned int mahimahi_sdslot_status_rev0(struct device *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)
+
+static struct msm_mmc_gpio_data sdc1_gpio =
+ .gpio = sdc1_gpio_cfg,
+ .size = ARRAY_SIZE(sdc1_gpio_cfg),
+};
+
+static struct msm_mmc_platform_data mahimahi_sdslot_data = {
+ .ocr_mask = MAHIMAHI_MMC_VDD,
+ .translate_vdd = mahimahi_sdslot_switchvdd,
+ .gpio_data = &sdc1_gpio,
+};
+
+int msm_add_sdcc(unsigned int controller, struct msm_mmc_platform_data *plat,
+ unsigned int stat_irq, unsigned long stat_irq_flags);
+
+int __init mahimahi_init_mmc(unsigned int sys_rev, unsigned debug_uart)
+{
+ uint32_t id;
+
+ if (debug_uart) {
+ pr_info("%s: sdcard disabled due to debug uart\n", __func__);
+ goto done;
+ }
+ if (opt_disable_sdcard) {
+ pr_info("%s: sdcard disabled on cmdline\n", __func__);
+ goto done;
+ }
+
+ sdslot_vreg_enabled = 0;
+
+ if (is_cdma_version(sys_rev)) {
+ /* In the CDMA version, sdslot is supplied by a gpio. */
+ int rc = 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);
+ return rc;
+ }
+ 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))
+ return PTR_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:
+ return 0;
+}
--
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.
^ permalink raw reply related [flat|nested] 157+ messages in thread
* [PATCH 6/7] msm: mahimahi: add gpio pin muxing code
2011-01-20 20:32 ` Daniel Walker
@ 2011-01-20 20:32 ` Daniel Walker
-1 siblings, 0 replies; 157+ messages in thread
From: Daniel Walker @ 2011-01-20 20:32 UTC (permalink / raw)
To: linux-arm-msm; +Cc: linux-arm-kernel, linux-kernel, davidb, Daniel Walker
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 <dwalker@codeaurora.org>
---
arch/arm/mach-msm/board-mahimahi-mmc.c | 32 ++++++++++++++++++++++++++++++++
1 files changed, 32 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-msm/board-mahimahi-mmc.c b/arch/arm/mach-msm/board-mahimahi-mmc.c
index 991818e..13e45d0 100644
--- a/arch/arm/mach-msm/board-mahimahi-mmc.c
+++ b/arch/arm/mach-msm/board-mahimahi-mmc.c
@@ -54,6 +54,34 @@ static struct msm_mmc_gpio sdc1_gpio_cfg[] = {
{67, "sdc1_dat_0"},
};
+static void config_gpio_table(uint32_t *table, int len)
+{
+ int n;
+ unsigned id;
+ for (n = 0; n < len; n++) {
+ id = table[n];
+ msm_proc_comm(PCOM_RPC_GPIO_TLMM_CONFIG_EX, &id, 0);
+ }
+}
+
+static uint32_t sdcard_on_gpio_table[] = {
+ PCOM_GPIO_CFG(62, 1, GPIO_OUTPUT, GPIO_NO_PULL, GPIO_8MA), /* CLK */
+ PCOM_GPIO_CFG(63, 1, GPIO_OUTPUT, GPIO_PULL_UP, GPIO_8MA), /* CMD */
+ PCOM_GPIO_CFG(64, 1, GPIO_OUTPUT, GPIO_PULL_UP, GPIO_4MA), /* DAT3 */
+ PCOM_GPIO_CFG(65, 1, GPIO_OUTPUT, GPIO_PULL_UP, GPIO_4MA), /* DAT2 */
+ PCOM_GPIO_CFG(66, 1, GPIO_OUTPUT, GPIO_PULL_UP, GPIO_4MA), /* DAT1 */
+ PCOM_GPIO_CFG(67, 1, GPIO_OUTPUT, GPIO_PULL_UP, GPIO_4MA), /* DAT0 */
+};
+
+static uint32_t sdcard_off_gpio_table[] = {
+ PCOM_GPIO_CFG(62, 0, GPIO_OUTPUT, GPIO_NO_PULL, GPIO_4MA), /* CLK */
+ PCOM_GPIO_CFG(63, 0, GPIO_OUTPUT, GPIO_NO_PULL, GPIO_4MA), /* CMD */
+ PCOM_GPIO_CFG(64, 0, GPIO_OUTPUT, GPIO_NO_PULL, GPIO_4MA), /* DAT3 */
+ PCOM_GPIO_CFG(65, 0, GPIO_OUTPUT, GPIO_NO_PULL, GPIO_4MA), /* DAT2 */
+ PCOM_GPIO_CFG(66, 0, GPIO_OUTPUT, GPIO_NO_PULL, GPIO_4MA), /* DAT1 */
+ PCOM_GPIO_CFG(67, 0, GPIO_OUTPUT, GPIO_NO_PULL, GPIO_4MA), /* DAT0 */
+};
+
static struct vreg *sdslot_vreg;
static uint32_t sdslot_vdd = 0xffffffff;
static uint32_t sdslot_vreg_enabled;
@@ -86,6 +114,8 @@ static uint32_t mahimahi_sdslot_switchvdd(struct device *dev, unsigned int vdd)
sdslot_vdd = vdd;
if (vdd == 0) {
+ config_gpio_table(sdcard_off_gpio_table,
+ ARRAY_SIZE(sdcard_off_gpio_table));
vreg_disable(sdslot_vreg);
sdslot_vreg_enabled = 0;
return 0;
@@ -95,6 +125,8 @@ static uint32_t mahimahi_sdslot_switchvdd(struct device *dev, unsigned int vdd)
ret = vreg_enable(sdslot_vreg);
if (ret)
pr_err("Error enabling vreg (%d)\n", ret);
+ config_gpio_table(sdcard_on_gpio_table,
+ ARRAY_SIZE(sdcard_on_gpio_table));
sdslot_vreg_enabled = 1;
}
--
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.
^ permalink raw reply related [flat|nested] 157+ messages in thread* [PATCH 6/7] msm: mahimahi: add gpio pin muxing code
@ 2011-01-20 20:32 ` Daniel Walker
0 siblings, 0 replies; 157+ messages in thread
From: Daniel Walker @ 2011-01-20 20:32 UTC (permalink / raw)
To: linux-arm-kernel
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 <dwalker@codeaurora.org>
---
arch/arm/mach-msm/board-mahimahi-mmc.c | 32 ++++++++++++++++++++++++++++++++
1 files changed, 32 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-msm/board-mahimahi-mmc.c b/arch/arm/mach-msm/board-mahimahi-mmc.c
index 991818e..13e45d0 100644
--- a/arch/arm/mach-msm/board-mahimahi-mmc.c
+++ b/arch/arm/mach-msm/board-mahimahi-mmc.c
@@ -54,6 +54,34 @@ static struct msm_mmc_gpio sdc1_gpio_cfg[] = {
{67, "sdc1_dat_0"},
};
+static void config_gpio_table(uint32_t *table, int len)
+{
+ int n;
+ unsigned id;
+ for (n = 0; n < len; n++) {
+ id = table[n];
+ msm_proc_comm(PCOM_RPC_GPIO_TLMM_CONFIG_EX, &id, 0);
+ }
+}
+
+static uint32_t sdcard_on_gpio_table[] = {
+ PCOM_GPIO_CFG(62, 1, GPIO_OUTPUT, GPIO_NO_PULL, GPIO_8MA), /* CLK */
+ PCOM_GPIO_CFG(63, 1, GPIO_OUTPUT, GPIO_PULL_UP, GPIO_8MA), /* CMD */
+ PCOM_GPIO_CFG(64, 1, GPIO_OUTPUT, GPIO_PULL_UP, GPIO_4MA), /* DAT3 */
+ PCOM_GPIO_CFG(65, 1, GPIO_OUTPUT, GPIO_PULL_UP, GPIO_4MA), /* DAT2 */
+ PCOM_GPIO_CFG(66, 1, GPIO_OUTPUT, GPIO_PULL_UP, GPIO_4MA), /* DAT1 */
+ PCOM_GPIO_CFG(67, 1, GPIO_OUTPUT, GPIO_PULL_UP, GPIO_4MA), /* DAT0 */
+};
+
+static uint32_t sdcard_off_gpio_table[] = {
+ PCOM_GPIO_CFG(62, 0, GPIO_OUTPUT, GPIO_NO_PULL, GPIO_4MA), /* CLK */
+ PCOM_GPIO_CFG(63, 0, GPIO_OUTPUT, GPIO_NO_PULL, GPIO_4MA), /* CMD */
+ PCOM_GPIO_CFG(64, 0, GPIO_OUTPUT, GPIO_NO_PULL, GPIO_4MA), /* DAT3 */
+ PCOM_GPIO_CFG(65, 0, GPIO_OUTPUT, GPIO_NO_PULL, GPIO_4MA), /* DAT2 */
+ PCOM_GPIO_CFG(66, 0, GPIO_OUTPUT, GPIO_NO_PULL, GPIO_4MA), /* DAT1 */
+ PCOM_GPIO_CFG(67, 0, GPIO_OUTPUT, GPIO_NO_PULL, GPIO_4MA), /* DAT0 */
+};
+
static struct vreg *sdslot_vreg;
static uint32_t sdslot_vdd = 0xffffffff;
static uint32_t sdslot_vreg_enabled;
@@ -86,6 +114,8 @@ static uint32_t mahimahi_sdslot_switchvdd(struct device *dev, unsigned int vdd)
sdslot_vdd = vdd;
if (vdd == 0) {
+ config_gpio_table(sdcard_off_gpio_table,
+ ARRAY_SIZE(sdcard_off_gpio_table));
vreg_disable(sdslot_vreg);
sdslot_vreg_enabled = 0;
return 0;
@@ -95,6 +125,8 @@ static uint32_t mahimahi_sdslot_switchvdd(struct device *dev, unsigned int vdd)
ret = vreg_enable(sdslot_vreg);
if (ret)
pr_err("Error enabling vreg (%d)\n", ret);
+ config_gpio_table(sdcard_on_gpio_table,
+ ARRAY_SIZE(sdcard_on_gpio_table));
sdslot_vreg_enabled = 1;
}
--
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.
^ permalink raw reply related [flat|nested] 157+ messages in thread
* [PATCH 7/7] msm: mahimahi: initialize mmc at start up
2011-01-20 20:32 ` Daniel Walker
@ 2011-01-20 20:32 ` Daniel Walker
-1 siblings, 0 replies; 157+ messages in thread
From: Daniel Walker @ 2011-01-20 20:32 UTC (permalink / raw)
To: linux-arm-msm; +Cc: linux-arm-kernel, linux-kernel, davidb, Daniel Walker
MMC should fully function at this point. This adds in the calls
to start the initialization.
Signed-off-by: Daniel Walker <dwalker@codeaurora.org>
---
arch/arm/mach-msm/board-mahimahi.c | 8 ++++++++
1 files changed, 8 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-msm/board-mahimahi.c b/arch/arm/mach-msm/board-mahimahi.c
index c1745c7..e7c70ca 100644
--- a/arch/arm/mach-msm/board-mahimahi.c
+++ b/arch/arm/mach-msm/board-mahimahi.c
@@ -38,6 +38,8 @@
static uint debug_uart;
+int mahimahi_init_mmc(unsigned int sys_rev, unsigned debug_uart);
+
module_param_named(debug_uart, debug_uart, uint, 0);
static struct platform_device *devices[] __initdata = {
@@ -65,11 +67,17 @@ static struct msm_acpu_clock_platform_data mahimahi_cdma_clock_data = {
static void __init mahimahi_init(void)
{
+ int ret;
+
if (is_cdma_version(system_rev))
msm_acpu_clock_init(&mahimahi_cdma_clock_data);
else
msm_acpu_clock_init(&mahimahi_clock_data);
+ ret = mahimahi_init_mmc(system_rev, debug_uart);
+ if (ret != 0)
+ pr_crit("%s: Unable to initialize MMC\n", __func__);
+
platform_add_devices(devices, ARRAY_SIZE(devices));
}
--
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.
^ permalink raw reply related [flat|nested] 157+ messages in thread* [PATCH 7/7] msm: mahimahi: initialize mmc at start up
@ 2011-01-20 20:32 ` Daniel Walker
0 siblings, 0 replies; 157+ messages in thread
From: Daniel Walker @ 2011-01-20 20:32 UTC (permalink / raw)
To: linux-arm-kernel
MMC should fully function at this point. This adds in the calls
to start the initialization.
Signed-off-by: Daniel Walker <dwalker@codeaurora.org>
---
arch/arm/mach-msm/board-mahimahi.c | 8 ++++++++
1 files changed, 8 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-msm/board-mahimahi.c b/arch/arm/mach-msm/board-mahimahi.c
index c1745c7..e7c70ca 100644
--- a/arch/arm/mach-msm/board-mahimahi.c
+++ b/arch/arm/mach-msm/board-mahimahi.c
@@ -38,6 +38,8 @@
static uint debug_uart;
+int mahimahi_init_mmc(unsigned int sys_rev, unsigned debug_uart);
+
module_param_named(debug_uart, debug_uart, uint, 0);
static struct platform_device *devices[] __initdata = {
@@ -65,11 +67,17 @@ static struct msm_acpu_clock_platform_data mahimahi_cdma_clock_data = {
static void __init mahimahi_init(void)
{
+ int ret;
+
if (is_cdma_version(system_rev))
msm_acpu_clock_init(&mahimahi_cdma_clock_data);
else
msm_acpu_clock_init(&mahimahi_clock_data);
+ ret = mahimahi_init_mmc(system_rev, debug_uart);
+ if (ret != 0)
+ pr_crit("%s: Unable to initialize MMC\n", __func__);
+
platform_add_devices(devices, ARRAY_SIZE(devices));
}
--
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.
^ permalink raw reply related [flat|nested] 157+ messages in thread
* Re: [PATCH 0/7] Nexus One Support
2011-01-20 20:32 ` Daniel Walker
(?)
@ 2011-01-21 0:42 ` Dima Zavin
-1 siblings, 0 replies; 157+ messages in thread
From: Dima Zavin @ 2011-01-21 0:42 UTC (permalink / raw)
To: Daniel Walker; +Cc: linux-arm-msm, linux-arm-kernel, linux-kernel, davidb
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 <dwalker@codeaurora.org> 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@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
>
--
To unsubscribe from this list: send the line "unsubscribe linux-arm-msm" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply [flat|nested] 157+ messages in thread
* [PATCH 0/7] Nexus One Support
@ 2011-01-21 0:42 ` Dima Zavin
0 siblings, 0 replies; 157+ messages in thread
From: Dima Zavin @ 2011-01-21 0:42 UTC (permalink / raw)
To: linux-arm-kernel
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 <dwalker@codeaurora.org> 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/
>
^ permalink raw reply [flat|nested] 157+ messages in thread
* Re: [PATCH 0/7] Nexus One Support
@ 2011-01-21 0:42 ` Dima Zavin
0 siblings, 0 replies; 157+ messages in thread
From: Dima Zavin @ 2011-01-21 0:42 UTC (permalink / raw)
To: Daniel Walker; +Cc: linux-arm-msm, linux-arm-kernel, linux-kernel, davidb
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 <dwalker@codeaurora.org> 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@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
>
^ permalink raw reply [flat|nested] 157+ messages in thread
* Re: [PATCH 0/7] Nexus One Support
2011-01-21 0:42 ` Dima Zavin
@ 2011-01-21 0:55 ` Daniel Walker
-1 siblings, 0 replies; 157+ messages in thread
From: Daniel Walker @ 2011-01-21 0:55 UTC (permalink / raw)
To: Dima Zavin; +Cc: linux-arm-msm, linux-arm-kernel, linux-kernel, davidb
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.
^ permalink raw reply [flat|nested] 157+ messages in thread
* [PATCH 0/7] Nexus One Support
@ 2011-01-21 0:55 ` Daniel Walker
0 siblings, 0 replies; 157+ messages in thread
From: Daniel Walker @ 2011-01-21 0:55 UTC (permalink / raw)
To: linux-arm-kernel
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.
^ permalink raw reply [flat|nested] 157+ messages in thread
* Re: [PATCH 0/7] Nexus One Support
2011-01-21 0:55 ` Daniel Walker
@ 2011-01-21 1:41 ` Joe Perches
-1 siblings, 0 replies; 157+ messages in thread
From: Joe Perches @ 2011-01-21 1:41 UTC (permalink / raw)
To: Daniel Walker
Cc: Dima Zavin, linux-arm-msm, linux-arm-kernel, linux-kernel, davidb
On Thu, 2011-01-20 at 16:55 -0800, Daniel Walker wrote:
> 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.
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.
^ permalink raw reply [flat|nested] 157+ messages in thread* [PATCH 0/7] Nexus One Support
@ 2011-01-21 1:41 ` Joe Perches
0 siblings, 0 replies; 157+ messages in thread
From: Joe Perches @ 2011-01-21 1:41 UTC (permalink / raw)
To: linux-arm-kernel
On Thu, 2011-01-20 at 16:55 -0800, Daniel Walker wrote:
> 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.
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.
^ permalink raw reply [flat|nested] 157+ messages in thread* Re: [PATCH 0/7] Nexus One Support
2011-01-21 1:41 ` Joe Perches
@ 2011-01-21 1:58 ` Daniel Walker
-1 siblings, 0 replies; 157+ messages in thread
From: Daniel Walker @ 2011-01-21 1:58 UTC (permalink / raw)
To: Joe Perches
Cc: Dima Zavin, linux-arm-msm, linux-arm-kernel, linux-kernel, davidb
On Thu, 2011-01-20 at 17:41 -0800, Joe Perches wrote:
> On Thu, 2011-01-20 at 16:55 -0800, Daniel Walker wrote:
> > 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.
>
> 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.
^ permalink raw reply [flat|nested] 157+ messages in thread
* [PATCH 0/7] Nexus One Support
@ 2011-01-21 1:58 ` Daniel Walker
0 siblings, 0 replies; 157+ messages in thread
From: Daniel Walker @ 2011-01-21 1:58 UTC (permalink / raw)
To: linux-arm-kernel
On Thu, 2011-01-20 at 17:41 -0800, Joe Perches wrote:
> On Thu, 2011-01-20 at 16:55 -0800, Daniel Walker wrote:
> > 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.
>
> 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.
^ permalink raw reply [flat|nested] 157+ messages in thread
* Re: [PATCH 0/7] Nexus One Support
2011-01-21 1:58 ` Daniel Walker
@ 2011-01-21 2:13 ` Dima Zavin
-1 siblings, 0 replies; 157+ messages in thread
From: Dima Zavin @ 2011-01-21 2:13 UTC (permalink / raw)
To: Daniel Walker
Cc: Joe Perches, linux-arm-msm, linux-arm-kernel, linux-kernel, davidb
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 <dwalker@codeaurora.org> wrote:
> On Thu, 2011-01-20 at 17:41 -0800, Joe Perches wrote:
>> On Thu, 2011-01-20 at 16:55 -0800, Daniel Walker wrote:
>> > 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.
>>
>> 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.
>
>
>
^ permalink raw reply [flat|nested] 157+ messages in thread
* [PATCH 0/7] Nexus One Support
@ 2011-01-21 2:13 ` Dima Zavin
0 siblings, 0 replies; 157+ messages in thread
From: Dima Zavin @ 2011-01-21 2:13 UTC (permalink / raw)
To: linux-arm-kernel
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 <dwalker@codeaurora.org> wrote:
> On Thu, 2011-01-20 at 17:41 -0800, Joe Perches wrote:
>> On Thu, 2011-01-20 at 16:55 -0800, Daniel Walker wrote:
>> > 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.
>>
>> 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.
>
>
>
^ permalink raw reply [flat|nested] 157+ messages in thread
* Re: [PATCH 0/7] Nexus One Support
2011-01-21 2:13 ` Dima Zavin
@ 2011-01-21 15:47 ` Daniel Walker
-1 siblings, 0 replies; 157+ messages in thread
From: Daniel Walker @ 2011-01-21 15:47 UTC (permalink / raw)
To: Dima Zavin
Cc: Joe Perches, linux-arm-msm, linux-arm-kernel, linux-kernel, davidb
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.
^ permalink raw reply [flat|nested] 157+ messages in thread
* [PATCH 0/7] Nexus One Support
@ 2011-01-21 15:47 ` Daniel Walker
0 siblings, 0 replies; 157+ messages in thread
From: Daniel Walker @ 2011-01-21 15:47 UTC (permalink / raw)
To: linux-arm-kernel
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.
^ permalink raw reply [flat|nested] 157+ messages in thread
* Re: [PATCH 0/7] Nexus One Support
2011-01-21 1:58 ` Daniel Walker
@ 2011-01-21 2:25 ` Joe Perches
-1 siblings, 0 replies; 157+ messages in thread
From: Joe Perches @ 2011-01-21 2:25 UTC (permalink / raw)
To: Daniel Walker
Cc: Dima Zavin, linux-arm-msm, linux-arm-kernel, linux-kernel, davidb
On Thu, 2011-01-20 at 17:58 -0800, Daniel Walker wrote:
> On Thu, 2011-01-20 at 17:41 -0800, Joe Perches wrote:
> > On Thu, 2011-01-20 at 16:55 -0800, Daniel Walker wrote:
> > > 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.
> > 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
^ permalink raw reply [flat|nested] 157+ messages in thread
* [PATCH 0/7] Nexus One Support
@ 2011-01-21 2:25 ` Joe Perches
0 siblings, 0 replies; 157+ messages in thread
From: Joe Perches @ 2011-01-21 2:25 UTC (permalink / raw)
To: linux-arm-kernel
On Thu, 2011-01-20 at 17:58 -0800, Daniel Walker wrote:
> On Thu, 2011-01-20 at 17:41 -0800, Joe Perches wrote:
> > On Thu, 2011-01-20 at 16:55 -0800, Daniel Walker wrote:
> > > 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.
> > 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
^ permalink raw reply [flat|nested] 157+ messages in thread
* Re: [PATCH 0/7] Nexus One Support
2011-01-21 2:25 ` Joe Perches
@ 2011-01-21 3:41 ` Theodore Tso
-1 siblings, 0 replies; 157+ messages in thread
From: Theodore Tso @ 2011-01-21 3:41 UTC (permalink / raw)
To: Joe Perches
Cc: Daniel Walker, Dima Zavin, linux-arm-msm, linux-arm-kernel,
linux-kernel, davidb
On Jan 20, 2011, at 9:25 PM, Joe Perches wrote:
>
> 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 <author@original.com>
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
^ permalink raw reply [flat|nested] 157+ messages in thread
* [PATCH 0/7] Nexus One Support
@ 2011-01-21 3:41 ` Theodore Tso
0 siblings, 0 replies; 157+ messages in thread
From: Theodore Tso @ 2011-01-21 3:41 UTC (permalink / raw)
To: linux-arm-kernel
On Jan 20, 2011, at 9:25 PM, Joe Perches wrote:
>
> 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 <author@original.com>
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
^ permalink raw reply [flat|nested] 157+ messages in thread
* Re: [PATCH 0/7] Nexus One Support
2011-01-21 2:25 ` Joe Perches
@ 2011-01-21 15:46 ` Daniel Walker
-1 siblings, 0 replies; 157+ messages in thread
From: Daniel Walker @ 2011-01-21 15:46 UTC (permalink / raw)
To: Joe Perches
Cc: Dima Zavin, linux-arm-msm, linux-arm-kernel, linux-kernel, davidb
On Thu, 2011-01-20 at 18:25 -0800, Joe Perches wrote:
> On Thu, 2011-01-20 at 17:58 -0800, Daniel Walker wrote:
> > On Thu, 2011-01-20 at 17:41 -0800, Joe Perches wrote:
> > > On Thu, 2011-01-20 at 16:55 -0800, Daniel Walker wrote:
> > > > 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.
> > > 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.
^ permalink raw reply [flat|nested] 157+ messages in thread
* [PATCH 0/7] Nexus One Support
@ 2011-01-21 15:46 ` Daniel Walker
0 siblings, 0 replies; 157+ messages in thread
From: Daniel Walker @ 2011-01-21 15:46 UTC (permalink / raw)
To: linux-arm-kernel
On Thu, 2011-01-20 at 18:25 -0800, Joe Perches wrote:
> On Thu, 2011-01-20 at 17:58 -0800, Daniel Walker wrote:
> > On Thu, 2011-01-20 at 17:41 -0800, Joe Perches wrote:
> > > On Thu, 2011-01-20 at 16:55 -0800, Daniel Walker wrote:
> > > > 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.
> > > 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.
^ permalink raw reply [flat|nested] 157+ messages in thread
* Re: [PATCH 0/7] Nexus One Support
2011-01-21 15:46 ` Daniel Walker
@ 2011-01-21 17:48 ` Jesse Barnes
-1 siblings, 0 replies; 157+ messages in thread
From: Jesse Barnes @ 2011-01-21 17:48 UTC (permalink / raw)
To: Daniel Walker
Cc: Joe Perches, Dima Zavin, linux-arm-msm, linux-arm-kernel,
linux-kernel, davidb
On Fri, 21 Jan 2011 07:46:41 -0800
Daniel Walker <dwalker@codeaurora.org> 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
^ permalink raw reply [flat|nested] 157+ messages in thread
* [PATCH 0/7] Nexus One Support
@ 2011-01-21 17:48 ` Jesse Barnes
0 siblings, 0 replies; 157+ messages in thread
From: Jesse Barnes @ 2011-01-21 17:48 UTC (permalink / raw)
To: linux-arm-kernel
On Fri, 21 Jan 2011 07:46:41 -0800
Daniel Walker <dwalker@codeaurora.org> 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
^ permalink raw reply [flat|nested] 157+ messages in thread
* Re: [PATCH 0/7] Nexus One Support
2011-01-21 17:48 ` Jesse Barnes
@ 2011-01-21 17:56 ` Daniel Walker
-1 siblings, 0 replies; 157+ messages in thread
From: Daniel Walker @ 2011-01-21 17:56 UTC (permalink / raw)
To: Jesse Barnes
Cc: Joe Perches, Dima Zavin, linux-arm-msm, linux-arm-kernel,
linux-kernel, davidb
On Fri, 2011-01-21 at 09:48 -0800, Jesse Barnes wrote:
> On Fri, 21 Jan 2011 07:46:41 -0800
> Daniel Walker <dwalker@codeaurora.org> 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.
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.
^ permalink raw reply [flat|nested] 157+ messages in thread
* [PATCH 0/7] Nexus One Support
@ 2011-01-21 17:56 ` Daniel Walker
0 siblings, 0 replies; 157+ messages in thread
From: Daniel Walker @ 2011-01-21 17:56 UTC (permalink / raw)
To: linux-arm-kernel
On Fri, 2011-01-21 at 09:48 -0800, Jesse Barnes wrote:
> On Fri, 21 Jan 2011 07:46:41 -0800
> Daniel Walker <dwalker@codeaurora.org> 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.
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.
^ permalink raw reply [flat|nested] 157+ messages in thread
* Re: [PATCH 0/7] Nexus One Support
2011-01-21 17:56 ` Daniel Walker
@ 2011-01-21 17:59 ` Christoph Hellwig
-1 siblings, 0 replies; 157+ messages in thread
From: Christoph Hellwig @ 2011-01-21 17:59 UTC (permalink / raw)
To: Daniel Walker
Cc: Jesse Barnes, Joe Perches, Dima Zavin, linux-arm-msm,
linux-arm-kernel, linux-kernel, davidb
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.
^ permalink raw reply [flat|nested] 157+ messages in thread
* [PATCH 0/7] Nexus One Support
@ 2011-01-21 17:59 ` Christoph Hellwig
0 siblings, 0 replies; 157+ messages in thread
From: Christoph Hellwig @ 2011-01-21 17:59 UTC (permalink / raw)
To: linux-arm-kernel
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.
^ permalink raw reply [flat|nested] 157+ messages in thread
* Re: [PATCH 0/7] Nexus One Support
2011-01-21 17:48 ` Jesse Barnes
(?)
@ 2011-01-21 17:56 ` Jesse Barnes
-1 siblings, 0 replies; 157+ messages in thread
From: Jesse Barnes @ 2011-01-21 17:56 UTC (permalink / raw)
Cc: Daniel Walker, Joe Perches, Dima Zavin, linux-arm-msm,
linux-arm-kernel, linux-kernel, davidb
On Fri, 21 Jan 2011 09:48:27 -0800
Jesse Barnes <jbarnes@virtuousgeek.org> wrote:
> On Fri, 21 Jan 2011 07:46:41 -0800
> Daniel Walker <dwalker@codeaurora.org> 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.
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
^ permalink raw reply [flat|nested] 157+ messages in thread
* [PATCH 0/7] Nexus One Support
@ 2011-01-21 17:56 ` Jesse Barnes
0 siblings, 0 replies; 157+ messages in thread
From: Jesse Barnes @ 2011-01-21 17:56 UTC (permalink / raw)
To: linux-arm-kernel
On Fri, 21 Jan 2011 09:48:27 -0800
Jesse Barnes <jbarnes@virtuousgeek.org> wrote:
> On Fri, 21 Jan 2011 07:46:41 -0800
> Daniel Walker <dwalker@codeaurora.org> 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.
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
^ permalink raw reply [flat|nested] 157+ messages in thread
* Re: [PATCH 0/7] Nexus One Support
@ 2011-01-21 17:56 ` Jesse Barnes
0 siblings, 0 replies; 157+ messages in thread
From: Jesse Barnes @ 2011-01-21 17:56 UTC (permalink / raw)
Cc: Daniel Walker, Joe Perches, Dima Zavin, linux-arm-msm,
linux-arm-kernel, linux-kernel, davidb
On Fri, 21 Jan 2011 09:48:27 -0800
Jesse Barnes <jbarnes@virtuousgeek.org> wrote:
> On Fri, 21 Jan 2011 07:46:41 -0800
> Daniel Walker <dwalker@codeaurora.org> 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.
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
^ permalink raw reply [flat|nested] 157+ messages in thread
* Re: [PATCH 0/7] Nexus One Support
2011-01-21 17:56 ` Jesse Barnes
@ 2011-01-21 18:00 ` Daniel Walker
-1 siblings, 0 replies; 157+ messages in thread
From: Daniel Walker @ 2011-01-21 18:00 UTC (permalink / raw)
To: Jesse Barnes
Cc: Joe Perches, Dima Zavin, linux-arm-msm, linux-arm-kernel,
linux-kernel, davidb
On Fri, 2011-01-21 at 09:56 -0800, Jesse Barnes wrote:
> On Fri, 21 Jan 2011 09:48:27 -0800
> Jesse Barnes <jbarnes@virtuousgeek.org> wrote:
>
> > On Fri, 21 Jan 2011 07:46:41 -0800
> > Daniel Walker <dwalker@codeaurora.org> 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.
>
> 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.
^ permalink raw reply [flat|nested] 157+ messages in thread
* [PATCH 0/7] Nexus One Support
@ 2011-01-21 18:00 ` Daniel Walker
0 siblings, 0 replies; 157+ messages in thread
From: Daniel Walker @ 2011-01-21 18:00 UTC (permalink / raw)
To: linux-arm-kernel
On Fri, 2011-01-21 at 09:56 -0800, Jesse Barnes wrote:
> On Fri, 21 Jan 2011 09:48:27 -0800
> Jesse Barnes <jbarnes@virtuousgeek.org> wrote:
>
> > On Fri, 21 Jan 2011 07:46:41 -0800
> > Daniel Walker <dwalker@codeaurora.org> 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.
>
> 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.
^ permalink raw reply [flat|nested] 157+ messages in thread
* Re: [PATCH 0/7] Nexus One Support
2011-01-21 18:00 ` Daniel Walker
@ 2011-01-21 18:04 ` Jesse Barnes
-1 siblings, 0 replies; 157+ messages in thread
From: Jesse Barnes @ 2011-01-21 18:04 UTC (permalink / raw)
To: Daniel Walker
Cc: Joe Perches, Dima Zavin, linux-arm-msm, linux-arm-kernel,
linux-kernel, davidb
On Fri, 21 Jan 2011 10:00:28 -0800
Daniel Walker <dwalker@codeaurora.org> wrote:
> On Fri, 2011-01-21 at 09:56 -0800, Jesse Barnes wrote:
> > On Fri, 21 Jan 2011 09:48:27 -0800
> > Jesse Barnes <jbarnes@virtuousgeek.org> wrote:
> >
> > > On Fri, 21 Jan 2011 07:46:41 -0800
> > > Daniel Walker <dwalker@codeaurora.org> 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.
> >
> > 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
^ permalink raw reply [flat|nested] 157+ messages in thread
* [PATCH 0/7] Nexus One Support
@ 2011-01-21 18:04 ` Jesse Barnes
0 siblings, 0 replies; 157+ messages in thread
From: Jesse Barnes @ 2011-01-21 18:04 UTC (permalink / raw)
To: linux-arm-kernel
On Fri, 21 Jan 2011 10:00:28 -0800
Daniel Walker <dwalker@codeaurora.org> wrote:
> On Fri, 2011-01-21 at 09:56 -0800, Jesse Barnes wrote:
> > On Fri, 21 Jan 2011 09:48:27 -0800
> > Jesse Barnes <jbarnes@virtuousgeek.org> wrote:
> >
> > > On Fri, 21 Jan 2011 07:46:41 -0800
> > > Daniel Walker <dwalker@codeaurora.org> 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.
> >
> > 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
^ permalink raw reply [flat|nested] 157+ messages in thread
* Re: [PATCH 0/7] Nexus One Support
2011-01-21 18:04 ` Jesse Barnes
@ 2011-01-21 18:18 ` Daniel Walker
-1 siblings, 0 replies; 157+ messages in thread
From: Daniel Walker @ 2011-01-21 18:18 UTC (permalink / raw)
To: Jesse Barnes
Cc: Joe Perches, Dima Zavin, linux-arm-msm, linux-arm-kernel,
linux-kernel, davidb
On Fri, 2011-01-21 at 10:04 -0800, Jesse Barnes wrote:
> On Fri, 21 Jan 2011 10:00:28 -0800
> Daniel Walker <dwalker@codeaurora.org> wrote:
>
> > On Fri, 2011-01-21 at 09:56 -0800, Jesse Barnes wrote:
> > > On Fri, 21 Jan 2011 09:48:27 -0800
> > > Jesse Barnes <jbarnes@virtuousgeek.org> wrote:
> > >
> > > > On Fri, 21 Jan 2011 07:46:41 -0800
> > > > Daniel Walker <dwalker@codeaurora.org> 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.
> > >
> > > 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.
^ permalink raw reply [flat|nested] 157+ messages in thread
* [PATCH 0/7] Nexus One Support
@ 2011-01-21 18:18 ` Daniel Walker
0 siblings, 0 replies; 157+ messages in thread
From: Daniel Walker @ 2011-01-21 18:18 UTC (permalink / raw)
To: linux-arm-kernel
On Fri, 2011-01-21 at 10:04 -0800, Jesse Barnes wrote:
> On Fri, 21 Jan 2011 10:00:28 -0800
> Daniel Walker <dwalker@codeaurora.org> wrote:
>
> > On Fri, 2011-01-21 at 09:56 -0800, Jesse Barnes wrote:
> > > On Fri, 21 Jan 2011 09:48:27 -0800
> > > Jesse Barnes <jbarnes@virtuousgeek.org> wrote:
> > >
> > > > On Fri, 21 Jan 2011 07:46:41 -0800
> > > > Daniel Walker <dwalker@codeaurora.org> 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.
> > >
> > > 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.
^ permalink raw reply [flat|nested] 157+ messages in thread
* Re: [PATCH 0/7] Nexus One Support
2011-01-21 18:18 ` Daniel Walker
@ 2011-01-21 18:27 ` Jesse Barnes
-1 siblings, 0 replies; 157+ messages in thread
From: Jesse Barnes @ 2011-01-21 18:27 UTC (permalink / raw)
To: Daniel Walker
Cc: Joe Perches, Dima Zavin, linux-arm-msm, linux-arm-kernel,
linux-kernel, davidb
On Fri, 21 Jan 2011 10:18:02 -0800
Daniel Walker <dwalker@codeaurora.org> wrote:
> On Fri, 2011-01-21 at 10:04 -0800, Jesse Barnes wrote:
> > On Fri, 21 Jan 2011 10:00:28 -0800
> > Daniel Walker <dwalker@codeaurora.org> wrote:
> >
> > > On Fri, 2011-01-21 at 09:56 -0800, Jesse Barnes wrote:
> > > > On Fri, 21 Jan 2011 09:48:27 -0800
> > > > Jesse Barnes <jbarnes@virtuousgeek.org> wrote:
> > > >
> > > > > On Fri, 21 Jan 2011 07:46:41 -0800
> > > > > Daniel Walker <dwalker@codeaurora.org> 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.
> > > >
> > > > 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
^ permalink raw reply [flat|nested] 157+ messages in thread* [PATCH 0/7] Nexus One Support
@ 2011-01-21 18:27 ` Jesse Barnes
0 siblings, 0 replies; 157+ messages in thread
From: Jesse Barnes @ 2011-01-21 18:27 UTC (permalink / raw)
To: linux-arm-kernel
On Fri, 21 Jan 2011 10:18:02 -0800
Daniel Walker <dwalker@codeaurora.org> wrote:
> On Fri, 2011-01-21 at 10:04 -0800, Jesse Barnes wrote:
> > On Fri, 21 Jan 2011 10:00:28 -0800
> > Daniel Walker <dwalker@codeaurora.org> wrote:
> >
> > > On Fri, 2011-01-21 at 09:56 -0800, Jesse Barnes wrote:
> > > > On Fri, 21 Jan 2011 09:48:27 -0800
> > > > Jesse Barnes <jbarnes@virtuousgeek.org> wrote:
> > > >
> > > > > On Fri, 21 Jan 2011 07:46:41 -0800
> > > > > Daniel Walker <dwalker@codeaurora.org> 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.
> > > >
> > > > 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
^ permalink raw reply [flat|nested] 157+ messages in thread* Re: [PATCH 0/7] Nexus One Support
2011-01-21 18:27 ` Jesse Barnes
@ 2011-01-21 18:35 ` Daniel Walker
-1 siblings, 0 replies; 157+ messages in thread
From: Daniel Walker @ 2011-01-21 18:35 UTC (permalink / raw)
To: Jesse Barnes
Cc: Joe Perches, Dima Zavin, linux-arm-msm, linux-arm-kernel,
linux-kernel, davidb
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.
^ permalink raw reply [flat|nested] 157+ messages in thread* [PATCH 0/7] Nexus One Support
@ 2011-01-21 18:35 ` Daniel Walker
0 siblings, 0 replies; 157+ messages in thread
From: Daniel Walker @ 2011-01-21 18:35 UTC (permalink / raw)
To: linux-arm-kernel
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.
^ permalink raw reply [flat|nested] 157+ messages in thread
* Re: [PATCH 0/7] Nexus One Support
2011-01-21 18:18 ` Daniel Walker
@ 2011-01-21 20:44 ` Dima Zavin
-1 siblings, 0 replies; 157+ messages in thread
From: Dima Zavin @ 2011-01-21 20:44 UTC (permalink / raw)
To: Daniel Walker
Cc: Jesse Barnes, Joe Perches, linux-arm-msm, linux-arm-kernel,
linux-kernel, davidb
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 <arve@android.com>
6 Brian Swetland <swetland@google.com>
14 Dima Zavin <dima@android.com>
2 Haley Teng <Haley_Teng@htc.com>
1 Iliyan Malchev <malchev@google.com>
5 Mike Chan <mike@android.com>
Your commit is a:
git checkout <branch> -- <file> ; git add ; git commit;
--Dima
On Fri, Jan 21, 2011 at 10:18 AM, Daniel Walker <dwalker@codeaurora.org> wrote:
> On Fri, 2011-01-21 at 10:04 -0800, Jesse Barnes wrote:
>> On Fri, 21 Jan 2011 10:00:28 -0800
>> Daniel Walker <dwalker@codeaurora.org> wrote:
>>
>> > On Fri, 2011-01-21 at 09:56 -0800, Jesse Barnes wrote:
>> > > On Fri, 21 Jan 2011 09:48:27 -0800
>> > > Jesse Barnes <jbarnes@virtuousgeek.org> wrote:
>> > >
>> > > > On Fri, 21 Jan 2011 07:46:41 -0800
>> > > > Daniel Walker <dwalker@codeaurora.org> 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.
>> > >
>> > > 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.
>
>
>
^ permalink raw reply [flat|nested] 157+ messages in thread* [PATCH 0/7] Nexus One Support
@ 2011-01-21 20:44 ` Dima Zavin
0 siblings, 0 replies; 157+ messages in thread
From: Dima Zavin @ 2011-01-21 20:44 UTC (permalink / raw)
To: linux-arm-kernel
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 <arve@android.com>
6 Brian Swetland <swetland@google.com>
14 Dima Zavin <dima@android.com>
2 Haley Teng <Haley_Teng@htc.com>
1 Iliyan Malchev <malchev@google.com>
5 Mike Chan <mike@android.com>
Your commit is a:
git checkout <branch> -- <file> ; git add ; git commit;
--Dima
On Fri, Jan 21, 2011 at 10:18 AM, Daniel Walker <dwalker@codeaurora.org> wrote:
> On Fri, 2011-01-21 at 10:04 -0800, Jesse Barnes wrote:
>> On Fri, 21 Jan 2011 10:00:28 -0800
>> Daniel Walker <dwalker@codeaurora.org> wrote:
>>
>> > On Fri, 2011-01-21 at 09:56 -0800, Jesse Barnes wrote:
>> > > On Fri, 21 Jan 2011 09:48:27 -0800
>> > > Jesse Barnes <jbarnes@virtuousgeek.org> wrote:
>> > >
>> > > > On Fri, 21 Jan 2011 07:46:41 -0800
>> > > > Daniel Walker <dwalker@codeaurora.org> 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.
>> > >
>> > > 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.
>
>
>
^ permalink raw reply [flat|nested] 157+ messages in thread* Re: [PATCH 0/7] Nexus One Support
2011-01-21 20:44 ` Dima Zavin
(?)
@ 2011-01-21 20:49 ` Daniel Walker
-1 siblings, 0 replies; 157+ messages in thread
From: Daniel Walker @ 2011-01-21 20:49 UTC (permalink / raw)
To: Dima Zavin
Cc: Jesse Barnes, Joe Perches, linux-arm-msm, linux-arm-kernel,
linux-kernel, davidb
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 <arve@android.com>
> 6 Brian Swetland <swetland@google.com>
> 14 Dima Zavin <dima@android.com>
> 2 Haley Teng <Haley_Teng@htc.com>
> 1 Iliyan Malchev <malchev@google.com>
> 5 Mike Chan <mike@android.com>
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.
--
To unsubscribe from this list: send the line "unsubscribe linux-arm-msm" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply [flat|nested] 157+ messages in thread
* [PATCH 0/7] Nexus One Support
@ 2011-01-21 20:49 ` Daniel Walker
0 siblings, 0 replies; 157+ messages in thread
From: Daniel Walker @ 2011-01-21 20:49 UTC (permalink / raw)
To: linux-arm-kernel
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 <arve@android.com>
> 6 Brian Swetland <swetland@google.com>
> 14 Dima Zavin <dima@android.com>
> 2 Haley Teng <Haley_Teng@htc.com>
> 1 Iliyan Malchev <malchev@google.com>
> 5 Mike Chan <mike@android.com>
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.
^ permalink raw reply [flat|nested] 157+ messages in thread
* Re: [PATCH 0/7] Nexus One Support
@ 2011-01-21 20:49 ` Daniel Walker
0 siblings, 0 replies; 157+ messages in thread
From: Daniel Walker @ 2011-01-21 20:49 UTC (permalink / raw)
To: Dima Zavin
Cc: Jesse Barnes, Joe Perches, linux-arm-msm, linux-arm-kernel,
linux-kernel, davidb
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 <arve@android.com>
> 6 Brian Swetland <swetland@google.com>
> 14 Dima Zavin <dima@android.com>
> 2 Haley Teng <Haley_Teng@htc.com>
> 1 Iliyan Malchev <malchev@google.com>
> 5 Mike Chan <mike@android.com>
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.
^ permalink raw reply [flat|nested] 157+ messages in thread
* Re: [PATCH 0/7] Nexus One Support
2011-01-21 20:49 ` Daniel Walker
(?)
@ 2011-01-21 21:01 ` Jesse Barnes
-1 siblings, 0 replies; 157+ messages in thread
From: Jesse Barnes @ 2011-01-21 21:01 UTC (permalink / raw)
To: Daniel Walker
Cc: Dima Zavin, Joe Perches, linux-arm-msm, linux-arm-kernel,
linux-kernel, davidb
On Fri, 21 Jan 2011 12:49:55 -0800
Daniel Walker <dwalker@codeaurora.org> wrote:
> 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 <arve@android.com>
> > 6 Brian Swetland <swetland@google.com>
> > 14 Dima Zavin <dima@android.com>
> > 2 Haley Teng <Haley_Teng@htc.com>
> > 1 Iliyan Malchev <malchev@google.com>
> > 5 Mike Chan <mike@android.com>
>
> 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.
--
Jesse Barnes, Intel Open Source Technology Center
--
To unsubscribe from this list: send the line "unsubscribe linux-arm-msm" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply [flat|nested] 157+ messages in thread
* [PATCH 0/7] Nexus One Support
@ 2011-01-21 21:01 ` Jesse Barnes
0 siblings, 0 replies; 157+ messages in thread
From: Jesse Barnes @ 2011-01-21 21:01 UTC (permalink / raw)
To: linux-arm-kernel
On Fri, 21 Jan 2011 12:49:55 -0800
Daniel Walker <dwalker@codeaurora.org> wrote:
> 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 <arve@android.com>
> > 6 Brian Swetland <swetland@google.com>
> > 14 Dima Zavin <dima@android.com>
> > 2 Haley Teng <Haley_Teng@htc.com>
> > 1 Iliyan Malchev <malchev@google.com>
> > 5 Mike Chan <mike@android.com>
>
> 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.
--
Jesse Barnes, Intel Open Source Technology Center
^ permalink raw reply [flat|nested] 157+ messages in thread
* Re: [PATCH 0/7] Nexus One Support
@ 2011-01-21 21:01 ` Jesse Barnes
0 siblings, 0 replies; 157+ messages in thread
From: Jesse Barnes @ 2011-01-21 21:01 UTC (permalink / raw)
To: Daniel Walker
Cc: Dima Zavin, Joe Perches, linux-arm-msm, linux-arm-kernel,
linux-kernel, davidb
On Fri, 21 Jan 2011 12:49:55 -0800
Daniel Walker <dwalker@codeaurora.org> wrote:
> 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 <arve@android.com>
> > 6 Brian Swetland <swetland@google.com>
> > 14 Dima Zavin <dima@android.com>
> > 2 Haley Teng <Haley_Teng@htc.com>
> > 1 Iliyan Malchev <malchev@google.com>
> > 5 Mike Chan <mike@android.com>
>
> 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.
--
Jesse Barnes, Intel Open Source Technology Center
^ permalink raw reply [flat|nested] 157+ messages in thread
* Re: [PATCH 0/7] Nexus One Support
2011-01-21 21:01 ` Jesse Barnes
@ 2011-01-21 21:26 ` Daniel Walker
-1 siblings, 0 replies; 157+ messages in thread
From: Daniel Walker @ 2011-01-21 21:26 UTC (permalink / raw)
To: Jesse Barnes
Cc: Dima Zavin, Joe Perches, linux-arm-msm, linux-arm-kernel,
linux-kernel, davidb
On Fri, 2011-01-21 at 13:01 -0800, Jesse Barnes wrote:
> On Fri, 21 Jan 2011 12:49:55 -0800
> Daniel Walker <dwalker@codeaurora.org> wrote:
>
> > 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 <arve@android.com>
> > > 6 Brian Swetland <swetland@google.com>
> > > 14 Dima Zavin <dima@android.com>
> > > 2 Haley Teng <Haley_Teng@htc.com>
> > > 1 Iliyan Malchev <malchev@google.com>
> > > 5 Mike Chan <mike@android.com>
> >
> > 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.
^ permalink raw reply [flat|nested] 157+ messages in thread
* [PATCH 0/7] Nexus One Support
@ 2011-01-21 21:26 ` Daniel Walker
0 siblings, 0 replies; 157+ messages in thread
From: Daniel Walker @ 2011-01-21 21:26 UTC (permalink / raw)
To: linux-arm-kernel
On Fri, 2011-01-21 at 13:01 -0800, Jesse Barnes wrote:
> On Fri, 21 Jan 2011 12:49:55 -0800
> Daniel Walker <dwalker@codeaurora.org> wrote:
>
> > 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 <arve@android.com>
> > > 6 Brian Swetland <swetland@google.com>
> > > 14 Dima Zavin <dima@android.com>
> > > 2 Haley Teng <Haley_Teng@htc.com>
> > > 1 Iliyan Malchev <malchev@google.com>
> > > 5 Mike Chan <mike@android.com>
> >
> > 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.
^ permalink raw reply [flat|nested] 157+ messages in thread
* Re: [PATCH 0/7] Nexus One Support
2011-01-21 21:26 ` Daniel Walker
(?)
@ 2011-01-21 21:42 ` Dima Zavin
-1 siblings, 0 replies; 157+ messages in thread
From: Dima Zavin @ 2011-01-21 21:42 UTC (permalink / raw)
To: Daniel Walker
Cc: Jesse Barnes, Joe Perches, linux-arm-msm, linux-arm-kernel,
linux-kernel, davidb
On Fri, Jan 21, 2011 at 1:26 PM, Daniel Walker <dwalker@codeaurora.org> wrote:
> On Fri, 2011-01-21 at 13:01 -0800, Jesse Barnes wrote:
>> On Fri, 21 Jan 2011 12:49:55 -0800
>> Daniel Walker <dwalker@codeaurora.org> wrote:
>>
>> > 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 <arve@android.com>
>> > > 6 Brian Swetland <swetland@google.com>
>> > > 14 Dima Zavin <dima@android.com>
>> > > 2 Haley Teng <Haley_Teng@htc.com>
>> > > 1 Iliyan Malchev <malchev@google.com>
>> > > 5 Mike Chan <mike@android.com>
>> >
>> > 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 ?
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
--
To unsubscribe from this list: send the line "unsubscribe linux-arm-msm" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply [flat|nested] 157+ messages in thread
* [PATCH 0/7] Nexus One Support
@ 2011-01-21 21:42 ` Dima Zavin
0 siblings, 0 replies; 157+ messages in thread
From: Dima Zavin @ 2011-01-21 21:42 UTC (permalink / raw)
To: linux-arm-kernel
On Fri, Jan 21, 2011 at 1:26 PM, Daniel Walker <dwalker@codeaurora.org> wrote:
> On Fri, 2011-01-21 at 13:01 -0800, Jesse Barnes wrote:
>> On Fri, 21 Jan 2011 12:49:55 -0800
>> Daniel Walker <dwalker@codeaurora.org> wrote:
>>
>> > 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 <arve@android.com>
>> > > ? ? ? 6 Brian Swetland <swetland@google.com>
>> > > ? ? ?14 Dima Zavin <dima@android.com>
>> > > ? ? ? 2 Haley Teng <Haley_Teng@htc.com>
>> > > ? ? ? 1 Iliyan Malchev <malchev@google.com>
>> > > ? ? ? 5 Mike Chan <mike@android.com>
>> >
>> > 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 ?
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
^ permalink raw reply [flat|nested] 157+ messages in thread
* Re: [PATCH 0/7] Nexus One Support
@ 2011-01-21 21:42 ` Dima Zavin
0 siblings, 0 replies; 157+ messages in thread
From: Dima Zavin @ 2011-01-21 21:42 UTC (permalink / raw)
To: Daniel Walker
Cc: Jesse Barnes, Joe Perches, linux-arm-msm, linux-arm-kernel,
linux-kernel, davidb
On Fri, Jan 21, 2011 at 1:26 PM, Daniel Walker <dwalker@codeaurora.org> wrote:
> On Fri, 2011-01-21 at 13:01 -0800, Jesse Barnes wrote:
>> On Fri, 21 Jan 2011 12:49:55 -0800
>> Daniel Walker <dwalker@codeaurora.org> wrote:
>>
>> > 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 <arve@android.com>
>> > > 6 Brian Swetland <swetland@google.com>
>> > > 14 Dima Zavin <dima@android.com>
>> > > 2 Haley Teng <Haley_Teng@htc.com>
>> > > 1 Iliyan Malchev <malchev@google.com>
>> > > 5 Mike Chan <mike@android.com>
>> >
>> > 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 ?
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
^ permalink raw reply [flat|nested] 157+ messages in thread
* Re: [PATCH 0/7] Nexus One Support
2011-01-21 21:42 ` Dima Zavin
@ 2011-01-22 13:58 ` David Woodhouse
-1 siblings, 0 replies; 157+ messages in thread
From: David Woodhouse @ 2011-01-22 13:58 UTC (permalink / raw)
To: Dima Zavin
Cc: Daniel Walker, Jesse Barnes, Joe Perches, linux-arm-msm,
linux-arm-kernel, linux-kernel, davidb
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@intel.com Intel Corporation
^ permalink raw reply [flat|nested] 157+ messages in thread
* [PATCH 0/7] Nexus One Support
@ 2011-01-22 13:58 ` David Woodhouse
0 siblings, 0 replies; 157+ messages in thread
From: David Woodhouse @ 2011-01-22 13:58 UTC (permalink / raw)
To: linux-arm-kernel
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
^ permalink raw reply [flat|nested] 157+ messages in thread
* Re: [PATCH 0/7] Nexus One Support
2011-01-21 20:49 ` Daniel Walker
(?)
@ 2011-01-21 21:02 ` Joe Perches
-1 siblings, 0 replies; 157+ messages in thread
From: Joe Perches @ 2011-01-21 21:02 UTC (permalink / raw)
To: Daniel Walker
Cc: Dima Zavin, Jesse Barnes, linux-arm-msm, linux-arm-kernel,
linux-kernel, davidb
On Fri, 2011-01-21 at 12:49 -0800, Daniel Walker wrote:
> 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 <arve@android.com>
> > 6 Brian Swetland <swetland@google.com>
> > 14 Dima Zavin <dima@android.com>
> > 2 Haley Teng <Haley_Teng@htc.com>
> > 1 Iliyan Malchev <malchev@google.com>
> > 5 Mike Chan <mike@android.com>
> 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
--
To unsubscribe from this list: send the line "unsubscribe linux-arm-msm" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply [flat|nested] 157+ messages in thread
* [PATCH 0/7] Nexus One Support
@ 2011-01-21 21:02 ` Joe Perches
0 siblings, 0 replies; 157+ messages in thread
From: Joe Perches @ 2011-01-21 21:02 UTC (permalink / raw)
To: linux-arm-kernel
On Fri, 2011-01-21 at 12:49 -0800, Daniel Walker wrote:
> 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 <arve@android.com>
> > 6 Brian Swetland <swetland@google.com>
> > 14 Dima Zavin <dima@android.com>
> > 2 Haley Teng <Haley_Teng@htc.com>
> > 1 Iliyan Malchev <malchev@google.com>
> > 5 Mike Chan <mike@android.com>
> 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
^ permalink raw reply [flat|nested] 157+ messages in thread
* Re: [PATCH 0/7] Nexus One Support
@ 2011-01-21 21:02 ` Joe Perches
0 siblings, 0 replies; 157+ messages in thread
From: Joe Perches @ 2011-01-21 21:02 UTC (permalink / raw)
To: Daniel Walker
Cc: Dima Zavin, Jesse Barnes, linux-arm-msm, linux-arm-kernel,
linux-kernel, davidb
On Fri, 2011-01-21 at 12:49 -0800, Daniel Walker wrote:
> 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 <arve@android.com>
> > 6 Brian Swetland <swetland@google.com>
> > 14 Dima Zavin <dima@android.com>
> > 2 Haley Teng <Haley_Teng@htc.com>
> > 1 Iliyan Malchev <malchev@google.com>
> > 5 Mike Chan <mike@android.com>
> 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
^ permalink raw reply [flat|nested] 157+ messages in thread
* Re: [PATCH 0/7] Nexus One Support
2011-01-21 21:02 ` Joe Perches
(?)
@ 2011-01-21 21:24 ` Daniel Walker
-1 siblings, 0 replies; 157+ messages in thread
From: Daniel Walker @ 2011-01-21 21:24 UTC (permalink / raw)
To: Joe Perches
Cc: Dima Zavin, Jesse Barnes, linux-arm-msm, linux-arm-kernel,
linux-kernel, davidb
On Fri, 2011-01-21 at 13:02 -0800, Joe Perches wrote:
> On Fri, 2011-01-21 at 12:49 -0800, Daniel Walker wrote:
> > 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 <arve@android.com>
> > > 6 Brian Swetland <swetland@google.com>
> > > 14 Dima Zavin <dima@android.com>
> > > 2 Haley Teng <Haley_Teng@htc.com>
> > > 1 Iliyan Malchev <malchev@google.com>
> > > 5 Mike Chan <mike@android.com>
> > 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.
--
To unsubscribe from this list: send the line "unsubscribe linux-arm-msm" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply [flat|nested] 157+ messages in thread
* [PATCH 0/7] Nexus One Support
@ 2011-01-21 21:24 ` Daniel Walker
0 siblings, 0 replies; 157+ messages in thread
From: Daniel Walker @ 2011-01-21 21:24 UTC (permalink / raw)
To: linux-arm-kernel
On Fri, 2011-01-21 at 13:02 -0800, Joe Perches wrote:
> On Fri, 2011-01-21 at 12:49 -0800, Daniel Walker wrote:
> > 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 <arve@android.com>
> > > 6 Brian Swetland <swetland@google.com>
> > > 14 Dima Zavin <dima@android.com>
> > > 2 Haley Teng <Haley_Teng@htc.com>
> > > 1 Iliyan Malchev <malchev@google.com>
> > > 5 Mike Chan <mike@android.com>
> > 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.
^ permalink raw reply [flat|nested] 157+ messages in thread
* Re: [PATCH 0/7] Nexus One Support
@ 2011-01-21 21:24 ` Daniel Walker
0 siblings, 0 replies; 157+ messages in thread
From: Daniel Walker @ 2011-01-21 21:24 UTC (permalink / raw)
To: Joe Perches
Cc: Dima Zavin, Jesse Barnes, linux-arm-msm, linux-arm-kernel,
linux-kernel, davidb
On Fri, 2011-01-21 at 13:02 -0800, Joe Perches wrote:
> On Fri, 2011-01-21 at 12:49 -0800, Daniel Walker wrote:
> > 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 <arve@android.com>
> > > 6 Brian Swetland <swetland@google.com>
> > > 14 Dima Zavin <dima@android.com>
> > > 2 Haley Teng <Haley_Teng@htc.com>
> > > 1 Iliyan Malchev <malchev@google.com>
> > > 5 Mike Chan <mike@android.com>
> > 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.
^ permalink raw reply [flat|nested] 157+ messages in thread
* Re: [PATCH 0/7] Nexus One Support
2011-01-21 21:24 ` Daniel Walker
(?)
@ 2011-01-22 11:18 ` Pekka Enberg
-1 siblings, 0 replies; 157+ messages in thread
From: Pekka Enberg @ 2011-01-22 11:18 UTC (permalink / raw)
To: Daniel Walker
Cc: Joe Perches, Dima Zavin, Jesse Barnes, linux-arm-msm,
linux-arm-kernel, linux-kernel, davidb
Hi Daniel,
On Fri, Jan 21, 2011 at 11:24 PM, Daniel Walker <dwalker@codeaurora.org> wrote:
> On Fri, 2011-01-21 at 13:02 -0800, Joe Perches wrote:
>> On Fri, 2011-01-21 at 12:49 -0800, Daniel Walker wrote:
>> > 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 <arve@android.com>
>> > > 6 Brian Swetland <swetland@google.com>
>> > > 14 Dima Zavin <dima@android.com>
>> > > 2 Haley Teng <Haley_Teng@htc.com>
>> > > 1 Iliyan Malchev <malchev@google.com>
>> > > 5 Mike Chan <mike@android.com>
>> > 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
--
To unsubscribe from this list: send the line "unsubscribe linux-arm-msm" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply [flat|nested] 157+ messages in thread* [PATCH 0/7] Nexus One Support
@ 2011-01-22 11:18 ` Pekka Enberg
0 siblings, 0 replies; 157+ messages in thread
From: Pekka Enberg @ 2011-01-22 11:18 UTC (permalink / raw)
To: linux-arm-kernel
Hi Daniel,
On Fri, Jan 21, 2011 at 11:24 PM, Daniel Walker <dwalker@codeaurora.org> wrote:
> On Fri, 2011-01-21 at 13:02 -0800, Joe Perches wrote:
>> On Fri, 2011-01-21 at 12:49 -0800, Daniel Walker wrote:
>> > 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 <arve@android.com>
>> > > ? ? ? 6 Brian Swetland <swetland@google.com>
>> > > ? ? ?14 Dima Zavin <dima@android.com>
>> > > ? ? ? 2 Haley Teng <Haley_Teng@htc.com>
>> > > ? ? ? 1 Iliyan Malchev <malchev@google.com>
>> > > ? ? ? 5 Mike Chan <mike@android.com>
>> > 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
^ permalink raw reply [flat|nested] 157+ messages in thread* Re: [PATCH 0/7] Nexus One Support
@ 2011-01-22 11:18 ` Pekka Enberg
0 siblings, 0 replies; 157+ messages in thread
From: Pekka Enberg @ 2011-01-22 11:18 UTC (permalink / raw)
To: Daniel Walker
Cc: Joe Perches, Dima Zavin, Jesse Barnes, linux-arm-msm,
linux-arm-kernel, linux-kernel, davidb
Hi Daniel,
On Fri, Jan 21, 2011 at 11:24 PM, Daniel Walker <dwalker@codeaurora.org> wrote:
> On Fri, 2011-01-21 at 13:02 -0800, Joe Perches wrote:
>> On Fri, 2011-01-21 at 12:49 -0800, Daniel Walker wrote:
>> > 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 <arve@android.com>
>> > > 6 Brian Swetland <swetland@google.com>
>> > > 14 Dima Zavin <dima@android.com>
>> > > 2 Haley Teng <Haley_Teng@htc.com>
>> > > 1 Iliyan Malchev <malchev@google.com>
>> > > 5 Mike Chan <mike@android.com>
>> > 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
^ permalink raw reply [flat|nested] 157+ messages in thread* Re: [PATCH 0/7] Nexus One Support
2011-01-22 11:18 ` Pekka Enberg
@ 2011-01-22 12:20 ` Russell King - ARM Linux
-1 siblings, 0 replies; 157+ messages in thread
From: Russell King - ARM Linux @ 2011-01-22 12:20 UTC (permalink / raw)
To: Pekka Enberg
Cc: Daniel Walker, linux-arm-msm, linux-kernel, Jesse Barnes,
Dima Zavin, Joe Perches, davidb, linux-arm-kernel
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).
^ permalink raw reply [flat|nested] 157+ messages in thread
* [PATCH 0/7] Nexus One Support
@ 2011-01-22 12:20 ` Russell King - ARM Linux
0 siblings, 0 replies; 157+ messages in thread
From: Russell King - ARM Linux @ 2011-01-22 12:20 UTC (permalink / raw)
To: linux-arm-kernel
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).
^ permalink raw reply [flat|nested] 157+ messages in thread
* Re: [PATCH 0/7] Nexus One Support
2011-01-22 12:20 ` Russell King - ARM Linux
(?)
@ 2011-01-22 18:06 ` Dima Zavin
-1 siblings, 0 replies; 157+ messages in thread
From: Dima Zavin @ 2011-01-22 18:06 UTC (permalink / raw)
To: Russell King - ARM Linux
Cc: Pekka Enberg, Daniel Walker, linux-arm-msm, linux-kernel,
Jesse Barnes, Joe Perches, davidb, linux-arm-kernel
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
<linux@arm.linux.org.uk> wrote:
> 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).
>
--
To unsubscribe from this list: send the line "unsubscribe linux-arm-msm" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply [flat|nested] 157+ messages in thread
* [PATCH 0/7] Nexus One Support
@ 2011-01-22 18:06 ` Dima Zavin
0 siblings, 0 replies; 157+ messages in thread
From: Dima Zavin @ 2011-01-22 18:06 UTC (permalink / raw)
To: linux-arm-kernel
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
<linux@arm.linux.org.uk> wrote:
> 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).
>
^ permalink raw reply [flat|nested] 157+ messages in thread
* Re: [PATCH 0/7] Nexus One Support
@ 2011-01-22 18:06 ` Dima Zavin
0 siblings, 0 replies; 157+ messages in thread
From: Dima Zavin @ 2011-01-22 18:06 UTC (permalink / raw)
To: Russell King - ARM Linux
Cc: Pekka Enberg, Daniel Walker, linux-arm-msm, linux-kernel,
Jesse Barnes, Joe Perches, davidb, linux-arm-kernel
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
<linux@arm.linux.org.uk> wrote:
> 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).
>
^ permalink raw reply [flat|nested] 157+ messages in thread
* Re: [PATCH 0/7] Nexus One Support
2011-01-22 18:06 ` Dima Zavin
(?)
@ 2011-01-22 18:49 ` Russell King - ARM Linux
-1 siblings, 0 replies; 157+ messages in thread
From: Russell King - ARM Linux @ 2011-01-22 18:49 UTC (permalink / raw)
To: Dima Zavin
Cc: Pekka Enberg, Daniel Walker, linux-arm-msm, linux-kernel,
Jesse Barnes, Joe Perches, davidb, linux-arm-kernel
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 <dima@android.com>, 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 <dima@android.com>
| committer Arve Hjønnevåg <arve@android.com>
|
| [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 <dima@android.com>
|
| [ARM] msm: mahimahi: Expand memory available to kernel to 219MB
|
| Change-Id: I59e69ce4209d16ce9804d3fa81814c9d0bda9a03
| Signed-off-by: Dima Zavin <dima@android.com>
|
| [ARM] msm: mahimahi: Read bluetooth address from ATAG and export in sysfs.
|
| Signed-off-by: Nick Pelly <npelly@google.com>
... 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.
--
To unsubscribe from this list: send the line "unsubscribe linux-arm-msm" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply [flat|nested] 157+ messages in thread
* [PATCH 0/7] Nexus One Support
@ 2011-01-22 18:49 ` Russell King - ARM Linux
0 siblings, 0 replies; 157+ messages in thread
From: Russell King - ARM Linux @ 2011-01-22 18:49 UTC (permalink / raw)
To: linux-arm-kernel
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 <dima@android.com>, 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 <dima@android.com>
| committer Arve Hj?nnev?g <arve@android.com>
|
| [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 <dima@android.com>
|
| [ARM] msm: mahimahi: Expand memory available to kernel to 219MB
|
| Change-Id: I59e69ce4209d16ce9804d3fa81814c9d0bda9a03
| Signed-off-by: Dima Zavin <dima@android.com>
|
| [ARM] msm: mahimahi: Read bluetooth address from ATAG and export in sysfs.
|
| Signed-off-by: Nick Pelly <npelly@google.com>
... 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.
^ permalink raw reply [flat|nested] 157+ messages in thread
* Re: [PATCH 0/7] Nexus One Support
@ 2011-01-22 18:49 ` Russell King - ARM Linux
0 siblings, 0 replies; 157+ messages in thread
From: Russell King - ARM Linux @ 2011-01-22 18:49 UTC (permalink / raw)
To: Dima Zavin
Cc: Pekka Enberg, Daniel Walker, linux-arm-msm, linux-kernel,
Jesse Barnes, Joe Perches, davidb, linux-arm-kernel
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 <dima@android.com>, 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 <dima@android.com>
| committer Arve Hjønnevåg <arve@android.com>
|
| [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 <dima@android.com>
|
| [ARM] msm: mahimahi: Expand memory available to kernel to 219MB
|
| Change-Id: I59e69ce4209d16ce9804d3fa81814c9d0bda9a03
| Signed-off-by: Dima Zavin <dima@android.com>
|
| [ARM] msm: mahimahi: Read bluetooth address from ATAG and export in sysfs.
|
| Signed-off-by: Nick Pelly <npelly@google.com>
... 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.
^ permalink raw reply [flat|nested] 157+ messages in thread
* Re: [PATCH 0/7] Nexus One Support
2011-01-22 18:49 ` Russell King - ARM Linux
@ 2011-01-22 20:50 ` Christoph Hellwig
-1 siblings, 0 replies; 157+ messages in thread
From: Christoph Hellwig @ 2011-01-22 20:50 UTC (permalink / raw)
To: Russell King - ARM Linux
Cc: Dima Zavin, Pekka Enberg, Daniel Walker, linux-arm-msm,
linux-kernel, Jesse Barnes, Joe Perches, davidb,
linux-arm-kernel
On Sat, Jan 22, 2011 at 06:49:09PM +0000, Russell King - ARM Linux wrote:
> http://android.git.kernel.org/?p=kernel/msm.git;a=commit;h=37431502c4
> 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 <dmitriyz@google.com>."
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.
^ permalink raw reply [flat|nested] 157+ messages in thread
* [PATCH 0/7] Nexus One Support
@ 2011-01-22 20:50 ` Christoph Hellwig
0 siblings, 0 replies; 157+ messages in thread
From: Christoph Hellwig @ 2011-01-22 20:50 UTC (permalink / raw)
To: linux-arm-kernel
On Sat, Jan 22, 2011 at 06:49:09PM +0000, Russell King - ARM Linux wrote:
> http://android.git.kernel.org/?p=kernel/msm.git;a=commit;h=37431502c4
> 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 <dmitriyz@google.com>."
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.
^ permalink raw reply [flat|nested] 157+ messages in thread
* Re: [PATCH 0/7] Nexus One Support
2011-01-22 12:20 ` Russell King - ARM Linux
@ 2011-01-22 19:22 ` Brian Swetland
-1 siblings, 0 replies; 157+ messages in thread
From: Brian Swetland @ 2011-01-22 19:22 UTC (permalink / raw)
To: Russell King - ARM Linux
Cc: Pekka Enberg, Daniel Walker, linux-arm-msm, linux-kernel,
Jesse Barnes, Dima Zavin, Joe Perches, davidb, linux-arm-kernel
On Sat, Jan 22, 2011 at 4:20 AM, Russell King - ARM Linux
<linux@arm.linux.org.uk> 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 <au@example.com> or Main Author <main@example.com>
Committer: Awesome Upstreamer <au@example.com>
Subject: arm: msm8k: acpu clock management
... summary of the patch ...
Original-Author: Joe Firmware Guy <joe@oem.com>
Original-Author: Kernel Droid <droid@android.com>
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
^ permalink raw reply [flat|nested] 157+ messages in thread
* [PATCH 0/7] Nexus One Support
@ 2011-01-22 19:22 ` Brian Swetland
0 siblings, 0 replies; 157+ messages in thread
From: Brian Swetland @ 2011-01-22 19:22 UTC (permalink / raw)
To: linux-arm-kernel
On Sat, Jan 22, 2011 at 4:20 AM, Russell King - ARM Linux
<linux@arm.linux.org.uk> 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 <au@example.com> or Main Author <main@example.com>
Committer: Awesome Upstreamer <au@example.com>
Subject: arm: msm8k: acpu clock management
... summary of the patch ...
Original-Author: Joe Firmware Guy <joe@oem.com>
Original-Author: Kernel Droid <droid@android.com>
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
^ permalink raw reply [flat|nested] 157+ messages in thread
* Re: [PATCH 0/7] Nexus One Support
2011-01-22 19:22 ` Brian Swetland
@ 2011-01-22 19:49 ` Nicolas Pitre
-1 siblings, 0 replies; 157+ messages in thread
From: Nicolas Pitre @ 2011-01-22 19:49 UTC (permalink / raw)
To: Brian Swetland
Cc: Russell King - ARM Linux, Pekka Enberg, Daniel Walker,
linux-arm-msm, lkml, Jesse Barnes, Dima Zavin, Joe Perches,
davidb, linux-arm-kernel
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 <au@example.com> or Main Author <main@example.com>
> Committer: Awesome Upstreamer <au@example.com>
> Subject: arm: msm8k: acpu clock management
>
> ... summary of the patch ...
>
> Original-Author: Joe Firmware Guy <joe@oem.com>
> Original-Author: Kernel Droid <droid@android.com>
> 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
^ permalink raw reply [flat|nested] 157+ messages in thread
* [PATCH 0/7] Nexus One Support
@ 2011-01-22 19:49 ` Nicolas Pitre
0 siblings, 0 replies; 157+ messages in thread
From: Nicolas Pitre @ 2011-01-22 19:49 UTC (permalink / raw)
To: linux-arm-kernel
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 <au@example.com> or Main Author <main@example.com>
> Committer: Awesome Upstreamer <au@example.com>
> Subject: arm: msm8k: acpu clock management
>
> ... summary of the patch ...
>
> Original-Author: Joe Firmware Guy <joe@oem.com>
> Original-Author: Kernel Droid <droid@android.com>
> 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
^ permalink raw reply [flat|nested] 157+ messages in thread
* Re: [PATCH 0/7] Nexus One Support
2011-01-22 19:49 ` Nicolas Pitre
(?)
@ 2011-01-22 19:59 ` Brian Swetland
-1 siblings, 0 replies; 157+ messages in thread
From: Brian Swetland @ 2011-01-22 19:59 UTC (permalink / raw)
To: Nicolas Pitre
Cc: Russell King - ARM Linux, Pekka Enberg, Daniel Walker,
linux-arm-msm, lkml, Jesse Barnes, Dima Zavin, Joe Perches,
davidb, linux-arm-kernel
On Sat, Jan 22, 2011 at 11:49 AM, Nicolas Pitre <nico@fluxnic.net> wrote:
> 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?
Something like:
Based on code written by:
<list of names>
is absolutely fine by me. Including patch counts, etc, is not essential.
>> What would be useful would be a reasonable convention for
>> acknowledging multiple authors, perhaps something along the lines of:
>>
>> Author: Awesome Upstreamer <au@example.com> or Main Author <main@example.com>
>> Committer: Awesome Upstreamer <au@example.com>
>> Subject: arm: msm8k: acpu clock management
>>
>> ... summary of the patch ...
>>
>> Original-Author: Joe Firmware Guy <joe@oem.com>
>> Original-Author: Kernel Droid <droid@android.com>
>> 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
--
To unsubscribe from this list: send the line "unsubscribe linux-arm-msm" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply [flat|nested] 157+ messages in thread
* [PATCH 0/7] Nexus One Support
@ 2011-01-22 19:59 ` Brian Swetland
0 siblings, 0 replies; 157+ messages in thread
From: Brian Swetland @ 2011-01-22 19:59 UTC (permalink / raw)
To: linux-arm-kernel
On Sat, Jan 22, 2011 at 11:49 AM, Nicolas Pitre <nico@fluxnic.net> wrote:
> 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?
Something like:
Based on code written by:
<list of names>
is absolutely fine by me. Including patch counts, etc, is not essential.
>> What would be useful would be a reasonable convention for
>> acknowledging multiple authors, perhaps something along the lines of:
>>
>> Author: Awesome Upstreamer <au@example.com> ?or ?Main Author <main@example.com>
>> Committer: Awesome Upstreamer <au@example.com>
>> Subject: arm: msm8k: acpu clock management
>>
>> ... summary of the patch ...
>>
>> Original-Author: Joe Firmware Guy <joe@oem.com>
>> Original-Author: Kernel Droid <droid@android.com>
>> 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
^ permalink raw reply [flat|nested] 157+ messages in thread
* Re: [PATCH 0/7] Nexus One Support
@ 2011-01-22 19:59 ` Brian Swetland
0 siblings, 0 replies; 157+ messages in thread
From: Brian Swetland @ 2011-01-22 19:59 UTC (permalink / raw)
To: Nicolas Pitre
Cc: Russell King - ARM Linux, Pekka Enberg, Daniel Walker,
linux-arm-msm, lkml, Jesse Barnes, Dima Zavin, Joe Perches,
davidb, linux-arm-kernel
On Sat, Jan 22, 2011 at 11:49 AM, Nicolas Pitre <nico@fluxnic.net> wrote:
> 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?
Something like:
Based on code written by:
<list of names>
is absolutely fine by me. Including patch counts, etc, is not essential.
>> What would be useful would be a reasonable convention for
>> acknowledging multiple authors, perhaps something along the lines of:
>>
>> Author: Awesome Upstreamer <au@example.com> or Main Author <main@example.com>
>> Committer: Awesome Upstreamer <au@example.com>
>> Subject: arm: msm8k: acpu clock management
>>
>> ... summary of the patch ...
>>
>> Original-Author: Joe Firmware Guy <joe@oem.com>
>> Original-Author: Kernel Droid <droid@android.com>
>> 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
^ permalink raw reply [flat|nested] 157+ messages in thread
* Re: [PATCH 0/7] Nexus One Support
2011-01-22 19:22 ` Brian Swetland
@ 2011-01-22 20:53 ` Christoph Hellwig
-1 siblings, 0 replies; 157+ messages in thread
From: Christoph Hellwig @ 2011-01-22 20:53 UTC (permalink / raw)
To: Brian Swetland
Cc: Russell King - ARM Linux, Pekka Enberg, Daniel Walker,
linux-arm-msm, linux-kernel, Jesse Barnes, Dima Zavin,
Joe Perches, davidb, linux-arm-kernel
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.
^ permalink raw reply [flat|nested] 157+ messages in thread
* [PATCH 0/7] Nexus One Support
@ 2011-01-22 20:53 ` Christoph Hellwig
0 siblings, 0 replies; 157+ messages in thread
From: Christoph Hellwig @ 2011-01-22 20:53 UTC (permalink / raw)
To: linux-arm-kernel
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.
^ permalink raw reply [flat|nested] 157+ messages in thread
* Re: [PATCH 0/7] Nexus One Support
2011-01-22 19:22 ` Brian Swetland
@ 2011-01-22 21:04 ` Russell King - ARM Linux
-1 siblings, 0 replies; 157+ messages in thread
From: Russell King - ARM Linux @ 2011-01-22 21:04 UTC (permalink / raw)
To: Brian Swetland
Cc: Pekka Enberg, Daniel Walker, linux-arm-msm, linux-kernel,
Jesse Barnes, Dima Zavin, Joe Perches, davidb, linux-arm-kernel
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.
^ permalink raw reply [flat|nested] 157+ messages in thread
* [PATCH 0/7] Nexus One Support
@ 2011-01-22 21:04 ` Russell King - ARM Linux
0 siblings, 0 replies; 157+ messages in thread
From: Russell King - ARM Linux @ 2011-01-22 21:04 UTC (permalink / raw)
To: linux-arm-kernel
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.
^ permalink raw reply [flat|nested] 157+ messages in thread
* Re: [PATCH 0/7] Nexus One Support
2011-01-22 21:04 ` Russell King - ARM Linux
@ 2011-01-22 21:57 ` Alan Cox
-1 siblings, 0 replies; 157+ messages in thread
From: Alan Cox @ 2011-01-22 21:57 UTC (permalink / raw)
To: Russell King - ARM Linux
Cc: Brian Swetland, Pekka Enberg, Daniel Walker, linux-arm-msm,
linux-kernel, Jesse Barnes, Dima Zavin, Joe Perches, davidb,
linux-arm-kernel
On Sat, 22 Jan 2011 21:04:05 +0000
Russell King - ARM Linux <linux@arm.linux.org.uk> wrote:
> 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.
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
^ permalink raw reply [flat|nested] 157+ messages in thread
* [PATCH 0/7] Nexus One Support
@ 2011-01-22 21:57 ` Alan Cox
0 siblings, 0 replies; 157+ messages in thread
From: Alan Cox @ 2011-01-22 21:57 UTC (permalink / raw)
To: linux-arm-kernel
On Sat, 22 Jan 2011 21:04:05 +0000
Russell King - ARM Linux <linux@arm.linux.org.uk> wrote:
> 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.
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
^ permalink raw reply [flat|nested] 157+ messages in thread
* Re: [PATCH 0/7] Nexus One Support
2011-01-22 19:22 ` Brian Swetland
@ 2011-01-23 2:38 ` David Woodhouse
-1 siblings, 0 replies; 157+ messages in thread
From: David Woodhouse @ 2011-01-23 2:38 UTC (permalink / raw)
To: Brian Swetland
Cc: Russell King - ARM Linux, Pekka Enberg, Daniel Walker,
linux-arm-msm, linux-kernel, Jesse Barnes, Dima Zavin,
Joe Perches, davidb, linux-arm-kernel
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 <au@example.com> or Main Author <main@example.com>
> Committer: Awesome Upstreamer <au@example.com>
> Subject: arm: msm8k: acpu clock management
>
> ... summary of the patch ...
>
> Original-Author: Joe Firmware Guy <joe@oem.com>
> Original-Author: Kernel Droid <droid@android.com>
> 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@intel.com Intel Corporation
^ permalink raw reply [flat|nested] 157+ messages in thread
* [PATCH 0/7] Nexus One Support
@ 2011-01-23 2:38 ` David Woodhouse
0 siblings, 0 replies; 157+ messages in thread
From: David Woodhouse @ 2011-01-23 2:38 UTC (permalink / raw)
To: linux-arm-kernel
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 <au@example.com> or Main Author <main@example.com>
> Committer: Awesome Upstreamer <au@example.com>
> Subject: arm: msm8k: acpu clock management
>
> ... summary of the patch ...
>
> Original-Author: Joe Firmware Guy <joe@oem.com>
> Original-Author: Kernel Droid <droid@android.com>
> 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
^ permalink raw reply [flat|nested] 157+ messages in thread
* Re: [PATCH 0/7] Nexus One Support
2011-01-22 12:20 ` Russell King - ARM Linux
@ 2011-01-22 20:41 ` Christoph Hellwig
-1 siblings, 0 replies; 157+ messages in thread
From: Christoph Hellwig @ 2011-01-22 20:41 UTC (permalink / raw)
To: Russell King - ARM Linux
Cc: Pekka Enberg, Daniel Walker, linux-arm-msm, linux-kernel,
Jesse Barnes, Dima Zavin, Joe Perches, davidb, linux-arm-kernel
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.
^ permalink raw reply [flat|nested] 157+ messages in thread
* [PATCH 0/7] Nexus One Support
@ 2011-01-22 20:41 ` Christoph Hellwig
0 siblings, 0 replies; 157+ messages in thread
From: Christoph Hellwig @ 2011-01-22 20:41 UTC (permalink / raw)
To: linux-arm-kernel
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.
^ permalink raw reply [flat|nested] 157+ messages in thread
* Re: [PATCH 0/7] Nexus One Support
2011-01-21 20:49 ` Daniel Walker
(?)
@ 2011-01-21 21:05 ` Pekka Enberg
-1 siblings, 0 replies; 157+ messages in thread
From: Pekka Enberg @ 2011-01-21 21:05 UTC (permalink / raw)
To: Daniel Walker
Cc: Dima Zavin, Jesse Barnes, Joe Perches, linux-arm-msm,
linux-arm-kernel, linux-kernel, davidb
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 <arve@android.com>
>> 6 Brian Swetland <swetland@google.com>
>> 14 Dima Zavin <dima@android.com>
>> 2 Haley Teng <Haley_Teng@htc.com>
>> 1 Iliyan Malchev <malchev@google.com>
>> 5 Mike Chan <mike@android.com>
On Fri, Jan 21, 2011 at 10:49 PM, Daniel Walker <dwalker@codeaurora.org> wrote:
> 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?
Pekka
--
To unsubscribe from this list: send the line "unsubscribe linux-arm-msm" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply [flat|nested] 157+ messages in thread* [PATCH 0/7] Nexus One Support
@ 2011-01-21 21:05 ` Pekka Enberg
0 siblings, 0 replies; 157+ messages in thread
From: Pekka Enberg @ 2011-01-21 21:05 UTC (permalink / raw)
To: linux-arm-kernel
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 <arve@android.com>
>> ? ? ? 6 Brian Swetland <swetland@google.com>
>> ? ? ?14 Dima Zavin <dima@android.com>
>> ? ? ? 2 Haley Teng <Haley_Teng@htc.com>
>> ? ? ? 1 Iliyan Malchev <malchev@google.com>
>> ? ? ? 5 Mike Chan <mike@android.com>
On Fri, Jan 21, 2011 at 10:49 PM, Daniel Walker <dwalker@codeaurora.org> wrote:
> 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?
Pekka
^ permalink raw reply [flat|nested] 157+ messages in thread* Re: [PATCH 0/7] Nexus One Support
@ 2011-01-21 21:05 ` Pekka Enberg
0 siblings, 0 replies; 157+ messages in thread
From: Pekka Enberg @ 2011-01-21 21:05 UTC (permalink / raw)
To: Daniel Walker
Cc: Dima Zavin, Jesse Barnes, Joe Perches, linux-arm-msm,
linux-arm-kernel, linux-kernel, davidb
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 <arve@android.com>
>> 6 Brian Swetland <swetland@google.com>
>> 14 Dima Zavin <dima@android.com>
>> 2 Haley Teng <Haley_Teng@htc.com>
>> 1 Iliyan Malchev <malchev@google.com>
>> 5 Mike Chan <mike@android.com>
On Fri, Jan 21, 2011 at 10:49 PM, Daniel Walker <dwalker@codeaurora.org> wrote:
> 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?
Pekka
^ permalink raw reply [flat|nested] 157+ messages in thread* Re: [PATCH 0/7] Nexus One Support
2011-01-21 21:05 ` Pekka Enberg
@ 2011-01-21 21:17 ` Joe Perches
-1 siblings, 0 replies; 157+ messages in thread
From: Joe Perches @ 2011-01-21 21:17 UTC (permalink / raw)
To: Pekka Enberg
Cc: Daniel Walker, Dima Zavin, Jesse Barnes, linux-arm-msm,
linux-arm-kernel, linux-kernel, davidb
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
^ permalink raw reply [flat|nested] 157+ messages in thread
* [PATCH 0/7] Nexus One Support
@ 2011-01-21 21:17 ` Joe Perches
0 siblings, 0 replies; 157+ messages in thread
From: Joe Perches @ 2011-01-21 21:17 UTC (permalink / raw)
To: linux-arm-kernel
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
^ permalink raw reply [flat|nested] 157+ messages in thread
* Re: [PATCH 0/7] Nexus One Support
2011-01-21 21:05 ` Pekka Enberg
@ 2011-01-21 23:49 ` Ted Ts'o
-1 siblings, 0 replies; 157+ messages in thread
From: Ted Ts'o @ 2011-01-21 23:49 UTC (permalink / raw)
To: Pekka Enberg
Cc: Daniel Walker, Dima Zavin, Jesse Barnes, Joe Perches,
linux-arm-msm, linux-arm-kernel, linux-kernel, davidb
On Fri, Jan 21, 2011 at 11:05:54PM +0200, Pekka Enberg wrote:
>
> On Fri, Jan 21, 2011 at 10:49 PM, Daniel Walker <dwalker@codeaurora.org> wrote:
> > 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
^ permalink raw reply [flat|nested] 157+ messages in thread
* [PATCH 0/7] Nexus One Support
@ 2011-01-21 23:49 ` Ted Ts'o
0 siblings, 0 replies; 157+ messages in thread
From: Ted Ts'o @ 2011-01-21 23:49 UTC (permalink / raw)
To: linux-arm-kernel
On Fri, Jan 21, 2011 at 11:05:54PM +0200, Pekka Enberg wrote:
>
> On Fri, Jan 21, 2011 at 10:49 PM, Daniel Walker <dwalker@codeaurora.org> wrote:
> > 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
^ permalink raw reply [flat|nested] 157+ messages in thread
* Re: [PATCH 0/7] Nexus One Support
2011-01-21 23:49 ` Ted Ts'o
@ 2011-01-22 0:03 ` Daniel Walker
-1 siblings, 0 replies; 157+ messages in thread
From: Daniel Walker @ 2011-01-22 0:03 UTC (permalink / raw)
To: Ted Ts'o
Cc: Pekka Enberg, Dima Zavin, Jesse Barnes, Joe Perches,
linux-arm-msm, linux-arm-kernel, linux-kernel, davidb
On Fri, 2011-01-21 at 18:49 -0500, Ted Ts'o wrote:
> On Fri, Jan 21, 2011 at 11:05:54PM +0200, Pekka Enberg wrote:
> >
> > On Fri, Jan 21, 2011 at 10:49 PM, Daniel Walker <dwalker@codeaurora.org> wrote:
> > > 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.
right, but it wasn't a cherrypick which was explain in the thread. So
there's no wrongs 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.
^ permalink raw reply [flat|nested] 157+ messages in thread
* [PATCH 0/7] Nexus One Support
@ 2011-01-22 0:03 ` Daniel Walker
0 siblings, 0 replies; 157+ messages in thread
From: Daniel Walker @ 2011-01-22 0:03 UTC (permalink / raw)
To: linux-arm-kernel
On Fri, 2011-01-21 at 18:49 -0500, Ted Ts'o wrote:
> On Fri, Jan 21, 2011 at 11:05:54PM +0200, Pekka Enberg wrote:
> >
> > On Fri, Jan 21, 2011 at 10:49 PM, Daniel Walker <dwalker@codeaurora.org> wrote:
> > > 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.
right, but it wasn't a cherrypick which was explain in the thread. So
there's no wrongs 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.
^ permalink raw reply [flat|nested] 157+ messages in thread
* Re: [PATCH 0/7] Nexus One Support
2011-01-22 0:03 ` Daniel Walker
@ 2011-01-22 1:58 ` Steven Rostedt
-1 siblings, 0 replies; 157+ messages in thread
From: Steven Rostedt @ 2011-01-22 1:58 UTC (permalink / raw)
To: Daniel Walker
Cc: Ted Ts'o, Pekka Enberg, Dima Zavin, Jesse Barnes,
Joe Perches, linux-arm-msm, linux-arm-kernel, linux-kernel,
davidb
On Fri, Jan 21, 2011 at 04:03:13PM -0800, Daniel Walker wrote:
>
> right, but it wasn't a cherrypick which was explain in the thread. So
> there's no wrongs here ..
I'm sorry Daniel, but you are absolutely wrong!
Did you come up with the logic of this code, or did you take someone
else's code and just massage it until it worked?
If you took someone else's code, where are their Signed-off-by's?
Just look at what I did recently with Lai's rt-mutex clean up patch. I
ported it to the PREEMPT_RT (-rt) patch set. That port took me a week to
do. I had to add a bunch of code to make it work. When it was finished,
did I claim author of it? No! I left Lai as the author and simply added:
[ Ported to the -rt patch set by Steven Rostedt ]
Take a look at the changes.
Here's the patch I started with:
https://patchwork.kernel.org/patch/477841/
Here's what I ended with (all my changes)
https://patchwork.kernel.org/patch/470171/
Do a diff of the two. There was a lot of work going into that. But I did
not come up with change to the algorithm that Lai did, so I kept him as
author. I just added my insert in the change log and added my own SoB
(including his).
If I repaint a Picasso, can I call it a Rostedt?
-- Steve
^ permalink raw reply [flat|nested] 157+ messages in thread
* [PATCH 0/7] Nexus One Support
@ 2011-01-22 1:58 ` Steven Rostedt
0 siblings, 0 replies; 157+ messages in thread
From: Steven Rostedt @ 2011-01-22 1:58 UTC (permalink / raw)
To: linux-arm-kernel
On Fri, Jan 21, 2011 at 04:03:13PM -0800, Daniel Walker wrote:
>
> right, but it wasn't a cherrypick which was explain in the thread. So
> there's no wrongs here ..
I'm sorry Daniel, but you are absolutely wrong!
Did you come up with the logic of this code, or did you take someone
else's code and just massage it until it worked?
If you took someone else's code, where are their Signed-off-by's?
Just look at what I did recently with Lai's rt-mutex clean up patch. I
ported it to the PREEMPT_RT (-rt) patch set. That port took me a week to
do. I had to add a bunch of code to make it work. When it was finished,
did I claim author of it? No! I left Lai as the author and simply added:
[ Ported to the -rt patch set by Steven Rostedt ]
Take a look at the changes.
Here's the patch I started with:
https://patchwork.kernel.org/patch/477841/
Here's what I ended with (all my changes)
https://patchwork.kernel.org/patch/470171/
Do a diff of the two. There was a lot of work going into that. But I did
not come up with change to the algorithm that Lai did, so I kept him as
author. I just added my insert in the change log and added my own SoB
(including his).
If I repaint a Picasso, can I call it a Rostedt?
-- Steve
^ permalink raw reply [flat|nested] 157+ messages in thread
* Re: [PATCH 0/7] Nexus One Support
2011-01-22 1:58 ` Steven Rostedt
@ 2011-01-22 2:13 ` Daniel Walker
-1 siblings, 0 replies; 157+ messages in thread
From: Daniel Walker @ 2011-01-22 2:13 UTC (permalink / raw)
To: Steven Rostedt
Cc: Ted Ts'o, Pekka Enberg, Dima Zavin, Jesse Barnes,
Joe Perches, linux-arm-msm, linux-arm-kernel, linux-kernel,
davidb
On Fri, 2011-01-21 at 20:58 -0500, Steven Rostedt wrote:
> On Fri, Jan 21, 2011 at 04:03:13PM -0800, Daniel Walker wrote:
> >
> > right, but it wasn't a cherrypick which was explain in the thread. So
> > there's no wrongs here ..
>
> I'm sorry Daniel, but you are absolutely wrong!
This thread is getting way out of hand .. I think you really don't
understand what has happened here.. That's fine tho, if you don't like
what I've done then NAK, I'm not going to argue with any you.
Daniel
--
Sent by an consultant of the Qualcomm Innovation Center, Inc.
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora
Forum.
^ permalink raw reply [flat|nested] 157+ messages in thread
* [PATCH 0/7] Nexus One Support
@ 2011-01-22 2:13 ` Daniel Walker
0 siblings, 0 replies; 157+ messages in thread
From: Daniel Walker @ 2011-01-22 2:13 UTC (permalink / raw)
To: linux-arm-kernel
On Fri, 2011-01-21 at 20:58 -0500, Steven Rostedt wrote:
> On Fri, Jan 21, 2011 at 04:03:13PM -0800, Daniel Walker wrote:
> >
> > right, but it wasn't a cherrypick which was explain in the thread. So
> > there's no wrongs here ..
>
> I'm sorry Daniel, but you are absolutely wrong!
This thread is getting way out of hand .. I think you really don't
understand what has happened here.. That's fine tho, if you don't like
what I've done then NAK, I'm not going to argue with any you.
Daniel
--
Sent by an consultant of the Qualcomm Innovation Center, Inc.
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora
Forum.
^ permalink raw reply [flat|nested] 157+ messages in thread
* Re: [PATCH 0/7] Nexus One Support
2011-01-22 2:13 ` Daniel Walker
@ 2011-01-22 2:32 ` Steven Rostedt
-1 siblings, 0 replies; 157+ messages in thread
From: Steven Rostedt @ 2011-01-22 2:32 UTC (permalink / raw)
To: Daniel Walker
Cc: Ted Ts'o, Pekka Enberg, Dima Zavin, Jesse Barnes,
Joe Perches, linux-arm-msm, linux-arm-kernel, linux-kernel,
davidb
On Fri, 2011-01-21 at 18:13 -0800, Daniel Walker wrote:
> On Fri, 2011-01-21 at 20:58 -0500, Steven Rostedt wrote:
> > On Fri, Jan 21, 2011 at 04:03:13PM -0800, Daniel Walker wrote:
> > >
> > > right, but it wasn't a cherrypick which was explain in the thread. So
> > > there's no wrongs here ..
> >
> > I'm sorry Daniel, but you are absolutely wrong!
>
> This thread is getting way out of hand .. I think you really don't
> understand what has happened here.. That's fine tho, if you don't like
> what I've done then NAK, I'm not going to argue with any you.
Sorry for coming off a bit strong, but I've known you for a while, and
that is usually the best way to get you to understand.
I don't want to argue, but instead teach you that there is a process of
getting code into the kernel, and a etiquette (not to mention legal) way
of doing things.
If you take code from someone else, look at it, and make it work, or do
whatever changes to it. You must keep some form of authorship with the
original author. If you rewrote it completely so that it doesn't look
anything like what the original code was, then sure, its yours. But then
the copyright would belong to you.
But you stated that the copyright was not yours but googles. You are not
employed by google are you? The major problem I have with these patches
is that you got code from somewhere else but had no Signed-off-bys from
anyone. This is where legal comes in.
How do you know this code was attained legally? Can you take sole
responsibility that the code was not stolen from non GPL code? The only
tag line in a change log that matters is that Signed-off-by. Its the one
with (sorta) legal powers. This is saying that you verify that this code
was given to you through legal means. Either that you wrote the code
yourself and are not under any contract to keep it from becoming GPL, or
you took it from someone that gave you their own Signed-off-by that you
can trust.
The biggest problem with your patch set is that it is missing the
necessary Signed-off-bys. Also, the only Signed-off-by that you can
write is your own. Someone can give you their Signed-off-by and you can
add it. There's been patches that I would not accept until the author
gave me (usually publicly) their Signed-off-by.
If you had those, I would not have written the email that I wrote.
-- Steve
^ permalink raw reply [flat|nested] 157+ messages in thread
* [PATCH 0/7] Nexus One Support
@ 2011-01-22 2:32 ` Steven Rostedt
0 siblings, 0 replies; 157+ messages in thread
From: Steven Rostedt @ 2011-01-22 2:32 UTC (permalink / raw)
To: linux-arm-kernel
On Fri, 2011-01-21 at 18:13 -0800, Daniel Walker wrote:
> On Fri, 2011-01-21 at 20:58 -0500, Steven Rostedt wrote:
> > On Fri, Jan 21, 2011 at 04:03:13PM -0800, Daniel Walker wrote:
> > >
> > > right, but it wasn't a cherrypick which was explain in the thread. So
> > > there's no wrongs here ..
> >
> > I'm sorry Daniel, but you are absolutely wrong!
>
> This thread is getting way out of hand .. I think you really don't
> understand what has happened here.. That's fine tho, if you don't like
> what I've done then NAK, I'm not going to argue with any you.
Sorry for coming off a bit strong, but I've known you for a while, and
that is usually the best way to get you to understand.
I don't want to argue, but instead teach you that there is a process of
getting code into the kernel, and a etiquette (not to mention legal) way
of doing things.
If you take code from someone else, look at it, and make it work, or do
whatever changes to it. You must keep some form of authorship with the
original author. If you rewrote it completely so that it doesn't look
anything like what the original code was, then sure, its yours. But then
the copyright would belong to you.
But you stated that the copyright was not yours but googles. You are not
employed by google are you? The major problem I have with these patches
is that you got code from somewhere else but had no Signed-off-bys from
anyone. This is where legal comes in.
How do you know this code was attained legally? Can you take sole
responsibility that the code was not stolen from non GPL code? The only
tag line in a change log that matters is that Signed-off-by. Its the one
with (sorta) legal powers. This is saying that you verify that this code
was given to you through legal means. Either that you wrote the code
yourself and are not under any contract to keep it from becoming GPL, or
you took it from someone that gave you their own Signed-off-by that you
can trust.
The biggest problem with your patch set is that it is missing the
necessary Signed-off-bys. Also, the only Signed-off-by that you can
write is your own. Someone can give you their Signed-off-by and you can
add it. There's been patches that I would not accept until the author
gave me (usually publicly) their Signed-off-by.
If you had those, I would not have written the email that I wrote.
-- Steve
^ permalink raw reply [flat|nested] 157+ messages in thread
* Re: [PATCH 0/7] Nexus One Support
2011-01-22 0:03 ` Daniel Walker
@ 2011-01-22 2:31 ` Ted Ts'o
-1 siblings, 0 replies; 157+ messages in thread
From: Ted Ts'o @ 2011-01-22 2:31 UTC (permalink / raw)
To: Daniel Walker
Cc: Pekka Enberg, Dima Zavin, Jesse Barnes, Joe Perches,
linux-arm-msm, linux-arm-kernel, linux-kernel, davidb
On Fri, Jan 21, 2011 at 04:03:13PM -0800, Daniel Walker wrote:
>
> right, but it wasn't a cherrypick which was explain in the thread. So
> there's no wrongs here ..
I said the *equivalent* of a cherry-pick. And in general, if I'm
taking things from another git tree, I'll try to preserve the commit
structure as much as possible, preserve the Author: information, as
well as reference the original git tree and commit id's, and of
course, keep the signed-off-by's. That's true even if I need to do
fairly significant work to port it to the current tree.
In some cases, of course, that might not be possible. But in general,
it's much better to err on the side of including authorship than not.
Note the big uproar that happened when the code from BSD wireless
drivers were imported in without due care for attribution. In the
case of pulling commits from another Linux kernel source tree, there
isn't even the excuse of needing to port from a completely different
OS's infrastructure.
If there is a desire to keep the git tree bisectable, and the order in
which things were checked in don't allow for tree bisectability, sure,
that might be a reason to collapse commits together; but even then,
I'd probably choose one of the Author's of the two original commits as
the Author field, instead of substituting my name in.
Best regards,
- Ted
^ permalink raw reply [flat|nested] 157+ messages in thread
* [PATCH 0/7] Nexus One Support
@ 2011-01-22 2:31 ` Ted Ts'o
0 siblings, 0 replies; 157+ messages in thread
From: Ted Ts'o @ 2011-01-22 2:31 UTC (permalink / raw)
To: linux-arm-kernel
On Fri, Jan 21, 2011 at 04:03:13PM -0800, Daniel Walker wrote:
>
> right, but it wasn't a cherrypick which was explain in the thread. So
> there's no wrongs here ..
I said the *equivalent* of a cherry-pick. And in general, if I'm
taking things from another git tree, I'll try to preserve the commit
structure as much as possible, preserve the Author: information, as
well as reference the original git tree and commit id's, and of
course, keep the signed-off-by's. That's true even if I need to do
fairly significant work to port it to the current tree.
In some cases, of course, that might not be possible. But in general,
it's much better to err on the side of including authorship than not.
Note the big uproar that happened when the code from BSD wireless
drivers were imported in without due care for attribution. In the
case of pulling commits from another Linux kernel source tree, there
isn't even the excuse of needing to port from a completely different
OS's infrastructure.
If there is a desire to keep the git tree bisectable, and the order in
which things were checked in don't allow for tree bisectability, sure,
that might be a reason to collapse commits together; but even then,
I'd probably choose one of the Author's of the two original commits as
the Author field, instead of substituting my name in.
Best regards,
- Ted
^ permalink raw reply [flat|nested] 157+ messages in thread
* Re: [PATCH 0/7] Nexus One Support
2011-01-21 23:49 ` Ted Ts'o
@ 2011-01-22 8:19 ` Pekka Enberg
-1 siblings, 0 replies; 157+ messages in thread
From: Pekka Enberg @ 2011-01-22 8:19 UTC (permalink / raw)
To: Ted Ts'o
Cc: Daniel Walker, Dima Zavin, Jesse Barnes, Joe Perches,
linux-arm-msm, linux-arm-kernel, linux-kernel, davidb
Hi Ted,
On Fri, Jan 21, 2011 at 10:49 PM, Daniel Walker <dwalker@codeaurora.org> wrote:
> > > I'll add this list into the commit text ..
On Fri, Jan 21, 2011 at 11:05:54PM +0200, Pekka Enberg wrote:
> > So why is everyone bitching at Daniel when he's doing something the
> > Android folks should have done themselves a long time ago?
On Fri, 2011-01-21 at 18:49 -0500, Ted Ts'o wrote:
> 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.)
Sure, it would have been nicer for everyone involved if Daniel would
have kept the original patches and added new patches to clean it up on
top of that to preserve the history. However, I don't understand the
harsh comments when this looks like a honest mistake! And I especially
don't understand the almost hostile attitude of the Android developers
who have been sitting on these patches for over a year now AFAICT.
Pekka
^ permalink raw reply [flat|nested] 157+ messages in thread
* [PATCH 0/7] Nexus One Support
@ 2011-01-22 8:19 ` Pekka Enberg
0 siblings, 0 replies; 157+ messages in thread
From: Pekka Enberg @ 2011-01-22 8:19 UTC (permalink / raw)
To: linux-arm-kernel
Hi Ted,
On Fri, Jan 21, 2011 at 10:49 PM, Daniel Walker <dwalker@codeaurora.org> wrote:
> > > I'll add this list into the commit text ..
On Fri, Jan 21, 2011 at 11:05:54PM +0200, Pekka Enberg wrote:
> > So why is everyone bitching at Daniel when he's doing something the
> > Android folks should have done themselves a long time ago?
On Fri, 2011-01-21 at 18:49 -0500, Ted Ts'o wrote:
> 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.)
Sure, it would have been nicer for everyone involved if Daniel would
have kept the original patches and added new patches to clean it up on
top of that to preserve the history. However, I don't understand the
harsh comments when this looks like a honest mistake! And I especially
don't understand the almost hostile attitude of the Android developers
who have been sitting on these patches for over a year now AFAICT.
Pekka
^ permalink raw reply [flat|nested] 157+ messages in thread
* Re: [PATCH 0/7] Nexus One Support
2011-01-22 8:19 ` Pekka Enberg
(?)
@ 2011-01-22 10:35 ` Dima Zavin
-1 siblings, 0 replies; 157+ messages in thread
From: Dima Zavin @ 2011-01-22 10:35 UTC (permalink / raw)
To: Pekka Enberg
Cc: Ted Ts'o, Daniel Walker, Jesse Barnes, Joe Perches,
linux-arm-msm, linux-arm-kernel, linux-kernel, davidb
On Sat, Jan 22, 2011 at 12:19 AM, Pekka Enberg <penberg@kernel.org> wrote:
> Hi Ted,
>
> On Fri, Jan 21, 2011 at 10:49 PM, Daniel Walker <dwalker@codeaurora.org> wrote:
>> > > I'll add this list into the commit text ..
>
> On Fri, Jan 21, 2011 at 11:05:54PM +0200, Pekka Enberg wrote:
>> > So why is everyone bitching at Daniel when he's doing something the
>> > Android folks should have done themselves a long time ago?
>
> On Fri, 2011-01-21 at 18:49 -0500, Ted Ts'o wrote:
>> 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.)
>
> Sure, it would have been nicer for everyone involved if Daniel would
> have kept the original patches and added new patches to clean it up on
> top of that to preserve the history. However, I don't understand the
> harsh comments when this looks like a honest mistake! And I especially
> don't understand the almost hostile attitude of the Android developers
There's absolutely no hostility. I stated from the very beginning that
I appreciate the voluntary effort by a 3rd party to upstream the board
files. I only asked that proper authorship be attributed, which is
standard linux kernel patch submission procedure when the committer
did not originate the code.
> who have been sitting on these patches for over a year now AFAICT.
Even if that were true, that does not somehow revoke the original
author/contributor list.
--Dima
--
To unsubscribe from this list: send the line "unsubscribe linux-arm-msm" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply [flat|nested] 157+ messages in thread
* [PATCH 0/7] Nexus One Support
@ 2011-01-22 10:35 ` Dima Zavin
0 siblings, 0 replies; 157+ messages in thread
From: Dima Zavin @ 2011-01-22 10:35 UTC (permalink / raw)
To: linux-arm-kernel
On Sat, Jan 22, 2011 at 12:19 AM, Pekka Enberg <penberg@kernel.org> wrote:
> Hi Ted,
>
> On Fri, Jan 21, 2011 at 10:49 PM, Daniel Walker <dwalker@codeaurora.org> wrote:
>> > > I'll add this list into the commit text ..
>
> On Fri, Jan 21, 2011 at 11:05:54PM +0200, Pekka Enberg wrote:
>> > So why is everyone bitching at Daniel when he's doing something the
>> > Android folks should have done themselves a long time ago?
>
> On Fri, 2011-01-21 at 18:49 -0500, Ted Ts'o wrote:
>> 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.)
>
> Sure, it would have been nicer for everyone involved if Daniel would
> have kept the original patches and added new patches to clean it up on
> top of that to preserve the history. However, I don't understand the
> harsh comments when this looks like a honest mistake! And I especially
> don't understand the almost hostile attitude of the Android developers
There's absolutely no hostility. I stated from the very beginning that
I appreciate the voluntary effort by a 3rd party to upstream the board
files. I only asked that proper authorship be attributed, which is
standard linux kernel patch submission procedure when the committer
did not originate the code.
> who have been sitting on these patches for over a year now AFAICT.
Even if that were true, that does not somehow revoke the original
author/contributor list.
--Dima
^ permalink raw reply [flat|nested] 157+ messages in thread
* Re: [PATCH 0/7] Nexus One Support
@ 2011-01-22 10:35 ` Dima Zavin
0 siblings, 0 replies; 157+ messages in thread
From: Dima Zavin @ 2011-01-22 10:35 UTC (permalink / raw)
To: Pekka Enberg
Cc: Ted Ts'o, Daniel Walker, Jesse Barnes, Joe Perches,
linux-arm-msm, linux-arm-kernel, linux-kernel, davidb
On Sat, Jan 22, 2011 at 12:19 AM, Pekka Enberg <penberg@kernel.org> wrote:
> Hi Ted,
>
> On Fri, Jan 21, 2011 at 10:49 PM, Daniel Walker <dwalker@codeaurora.org> wrote:
>> > > I'll add this list into the commit text ..
>
> On Fri, Jan 21, 2011 at 11:05:54PM +0200, Pekka Enberg wrote:
>> > So why is everyone bitching at Daniel when he's doing something the
>> > Android folks should have done themselves a long time ago?
>
> On Fri, 2011-01-21 at 18:49 -0500, Ted Ts'o wrote:
>> 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.)
>
> Sure, it would have been nicer for everyone involved if Daniel would
> have kept the original patches and added new patches to clean it up on
> top of that to preserve the history. However, I don't understand the
> harsh comments when this looks like a honest mistake! And I especially
> don't understand the almost hostile attitude of the Android developers
There's absolutely no hostility. I stated from the very beginning that
I appreciate the voluntary effort by a 3rd party to upstream the board
files. I only asked that proper authorship be attributed, which is
standard linux kernel patch submission procedure when the committer
did not originate the code.
> who have been sitting on these patches for over a year now AFAICT.
Even if that were true, that does not somehow revoke the original
author/contributor list.
--Dima
^ permalink raw reply [flat|nested] 157+ messages in thread
* Re: [PATCH 0/7] Nexus One Support
2011-01-22 10:35 ` Dima Zavin
(?)
@ 2011-01-22 10:45 ` Anca Emanuel
-1 siblings, 0 replies; 157+ messages in thread
From: Anca Emanuel @ 2011-01-22 10:45 UTC (permalink / raw)
To: Dima Zavin
Cc: Pekka Enberg, Ted Ts'o, Daniel Walker, Jesse Barnes,
Joe Perches, linux-arm-msm, linux-arm-kernel, linux-kernel,
davidb
On Sat, Jan 22, 2011 at 12:35 PM, Dima Zavin <dmitriyz@google.com> wrote:
> On Sat, Jan 22, 2011 at 12:19 AM, Pekka Enberg <penberg@kernel.org> wrote:
>> Hi Ted,
>>
>> On Fri, Jan 21, 2011 at 10:49 PM, Daniel Walker <dwalker@codeaurora.org> wrote:
>>> > > I'll add this list into the commit text ..
>>
>> On Fri, Jan 21, 2011 at 11:05:54PM +0200, Pekka Enberg wrote:
>>> > So why is everyone bitching at Daniel when he's doing something the
>>> > Android folks should have done themselves a long time ago?
>>
>> On Fri, 2011-01-21 at 18:49 -0500, Ted Ts'o wrote:
>>> 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.)
>>
>> Sure, it would have been nicer for everyone involved if Daniel would
>> have kept the original patches and added new patches to clean it up on
>> top of that to preserve the history. However, I don't understand the
>> harsh comments when this looks like a honest mistake! And I especially
>> don't understand the almost hostile attitude of the Android developers
>
> There's absolutely no hostility. I stated from the very beginning that
> I appreciate the voluntary effort by a 3rd party to upstream the board
> files. I only asked that proper authorship be attributed, which is
> standard linux kernel patch submission procedure when the committer
> did not originate the code.
>
>> who have been sitting on these patches for over a year now AFAICT.
>
> Even if that were true, that does not somehow revoke the original
> author/contributor list.
>
> --Dima
> --
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
>
Can you show how to import history ? Until then, a line like From:
x@y.x I think will be fine.
And maybe an link to https://review.source.android.com/'some review'
--
To unsubscribe from this list: send the line "unsubscribe linux-arm-msm" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply [flat|nested] 157+ messages in thread
* [PATCH 0/7] Nexus One Support
@ 2011-01-22 10:45 ` Anca Emanuel
0 siblings, 0 replies; 157+ messages in thread
From: Anca Emanuel @ 2011-01-22 10:45 UTC (permalink / raw)
To: linux-arm-kernel
On Sat, Jan 22, 2011 at 12:35 PM, Dima Zavin <dmitriyz@google.com> wrote:
> On Sat, Jan 22, 2011 at 12:19 AM, Pekka Enberg <penberg@kernel.org> wrote:
>> Hi Ted,
>>
>> On Fri, Jan 21, 2011 at 10:49 PM, Daniel Walker <dwalker@codeaurora.org> wrote:
>>> > > I'll add this list into the commit text ..
>>
>> On Fri, Jan 21, 2011 at 11:05:54PM +0200, Pekka Enberg wrote:
>>> > So why is everyone bitching at Daniel when he's doing something the
>>> > Android folks should have done themselves a long time ago?
>>
>> On Fri, 2011-01-21 at 18:49 -0500, Ted Ts'o wrote:
>>> 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.)
>>
>> Sure, it would have been nicer for everyone involved if Daniel would
>> have kept the original patches and added new patches to clean it up on
>> top of that to preserve the history. However, I don't understand the
>> harsh comments when this looks like a honest mistake! And I especially
>> don't understand the almost hostile attitude of the Android developers
>
> There's absolutely no hostility. I stated from the very beginning that
> I appreciate the voluntary effort by a 3rd party to upstream the board
> files. I only asked that proper authorship be attributed, which is
> standard linux kernel patch submission procedure when the committer
> did not originate the code.
>
>> who have been sitting on these patches for over a year now AFAICT.
>
> Even if that were true, that does not somehow revoke the original
> author/contributor list.
>
> --Dima
> --
> 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/
>
Can you show how to import history ? Until then, a line like From:
x at y.x I think will be fine.
And maybe an link to https://review.source.android.com/'some review'
^ permalink raw reply [flat|nested] 157+ messages in thread
* Re: [PATCH 0/7] Nexus One Support
@ 2011-01-22 10:45 ` Anca Emanuel
0 siblings, 0 replies; 157+ messages in thread
From: Anca Emanuel @ 2011-01-22 10:45 UTC (permalink / raw)
To: Dima Zavin
Cc: Pekka Enberg, Ted Ts'o, Daniel Walker, Jesse Barnes,
Joe Perches, linux-arm-msm, linux-arm-kernel, linux-kernel,
davidb
On Sat, Jan 22, 2011 at 12:35 PM, Dima Zavin <dmitriyz@google.com> wrote:
> On Sat, Jan 22, 2011 at 12:19 AM, Pekka Enberg <penberg@kernel.org> wrote:
>> Hi Ted,
>>
>> On Fri, Jan 21, 2011 at 10:49 PM, Daniel Walker <dwalker@codeaurora.org> wrote:
>>> > > I'll add this list into the commit text ..
>>
>> On Fri, Jan 21, 2011 at 11:05:54PM +0200, Pekka Enberg wrote:
>>> > So why is everyone bitching at Daniel when he's doing something the
>>> > Android folks should have done themselves a long time ago?
>>
>> On Fri, 2011-01-21 at 18:49 -0500, Ted Ts'o wrote:
>>> 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.)
>>
>> Sure, it would have been nicer for everyone involved if Daniel would
>> have kept the original patches and added new patches to clean it up on
>> top of that to preserve the history. However, I don't understand the
>> harsh comments when this looks like a honest mistake! And I especially
>> don't understand the almost hostile attitude of the Android developers
>
> There's absolutely no hostility. I stated from the very beginning that
> I appreciate the voluntary effort by a 3rd party to upstream the board
> files. I only asked that proper authorship be attributed, which is
> standard linux kernel patch submission procedure when the committer
> did not originate the code.
>
>> who have been sitting on these patches for over a year now AFAICT.
>
> Even if that were true, that does not somehow revoke the original
> author/contributor list.
>
> --Dima
> --
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
>
Can you show how to import history ? Until then, a line like From:
x@y.x I think will be fine.
And maybe an link to https://review.source.android.com/'some review'
^ permalink raw reply [flat|nested] 157+ messages in thread
* Re: [PATCH 0/7] Nexus One Support
2011-01-22 10:45 ` Anca Emanuel
@ 2011-01-22 11:03 ` Pekka Enberg
-1 siblings, 0 replies; 157+ messages in thread
From: Pekka Enberg @ 2011-01-22 11:03 UTC (permalink / raw)
To: Anca Emanuel
Cc: Dima Zavin, Ted Ts'o, Daniel Walker, Jesse Barnes,
Joe Perches, linux-arm-msm, linux-arm-kernel, linux-kernel,
davidb
On Sat, Jan 22, 2011 at 12:45 PM, Anca Emanuel <anca.emanuel@gmail.com> wrote:
> Can you show how to import history ? Until then, a line like From:
> x@y.x I think will be fine.
> And maybe an link to https://review.source.android.com/'some review'
The best solution is to keep the original patches as-is and rebase
Daniel's cleanups on top of those.
^ permalink raw reply [flat|nested] 157+ messages in thread
* Re: [PATCH 0/7] Nexus One Support
2011-01-22 10:35 ` Dima Zavin
@ 2011-01-22 11:15 ` Pekka Enberg
-1 siblings, 0 replies; 157+ messages in thread
From: Pekka Enberg @ 2011-01-22 11:15 UTC (permalink / raw)
To: Dima Zavin
Cc: Ted Ts'o, Daniel Walker, Jesse Barnes, Joe Perches,
linux-arm-msm, linux-arm-kernel, linux-kernel, davidb
Hi Dima!
On Sat, Jan 22, 2011 at 12:35 PM, Dima Zavin <dmitriyz@google.com> wrote:
> There's absolutely no hostility. I stated from the very beginning that
> I appreciate the voluntary effort by a 3rd party to upstream the board
> files. I only asked that proper authorship be attributed, which is
> standard linux kernel patch submission procedure when the committer
> did not originate the code.
OK, that's great! It's poorly reflected in this discussion thread, though.
>> who have been sitting on these patches for over a year now AFAICT.
>
> Even if that were true, that does not somehow revoke the original
> author/contributor list.
No, it does not. But it does make me much more sympathetic towards
Daniel's efforts even though authorship info is misappropriated. It's
not as if he changed copyrights or anything malicious like that so I
do think people are making this into a bigger thing than it really is.
Anyway, I hope Daniel has the time to rebase his patches on top of
your original ones so history is preserved and we can get this stuff
merged.
Pekka
^ permalink raw reply [flat|nested] 157+ messages in thread* [PATCH 0/7] Nexus One Support
@ 2011-01-22 11:15 ` Pekka Enberg
0 siblings, 0 replies; 157+ messages in thread
From: Pekka Enberg @ 2011-01-22 11:15 UTC (permalink / raw)
To: linux-arm-kernel
Hi Dima!
On Sat, Jan 22, 2011 at 12:35 PM, Dima Zavin <dmitriyz@google.com> wrote:
> There's absolutely no hostility. I stated from the very beginning that
> I appreciate the voluntary effort by a 3rd party to upstream the board
> files. I only asked that proper authorship be attributed, which is
> standard linux kernel patch submission procedure when the committer
> did not originate the code.
OK, that's great! It's poorly reflected in this discussion thread, though.
>> who have been sitting on these patches for over a year now AFAICT.
>
> Even if that were true, that does not somehow revoke the original
> author/contributor list.
No, it does not. But it does make me much more sympathetic towards
Daniel's efforts even though authorship info is misappropriated. It's
not as if he changed copyrights or anything malicious like that so I
do think people are making this into a bigger thing than it really is.
Anyway, I hope Daniel has the time to rebase his patches on top of
your original ones so history is preserved and we can get this stuff
merged.
Pekka
^ permalink raw reply [flat|nested] 157+ messages in thread* Re: [PATCH 0/7] Nexus One Support
2011-01-22 11:15 ` Pekka Enberg
@ 2011-01-22 17:28 ` Thomas Gleixner
-1 siblings, 0 replies; 157+ messages in thread
From: Thomas Gleixner @ 2011-01-22 17:28 UTC (permalink / raw)
To: Pekka Enberg
Cc: Dima Zavin, Ted Ts'o, Daniel Walker, Jesse Barnes,
Joe Perches, linux-arm-msm, linux-arm-kernel, linux-kernel,
davidb
On Sat, 22 Jan 2011, Pekka Enberg wrote:
> Hi Dima!
>
> On Sat, Jan 22, 2011 at 12:35 PM, Dima Zavin <dmitriyz@google.com> wrote:
> > There's absolutely no hostility. I stated from the very beginning that
> > I appreciate the voluntary effort by a 3rd party to upstream the board
> > files. I only asked that proper authorship be attributed, which is
> > standard linux kernel patch submission procedure when the committer
> > did not originate the code.
>
> OK, that's great! It's poorly reflected in this discussion thread, though.
>
> >> who have been sitting on these patches for over a year now AFAICT.
> >
> > Even if that were true, that does not somehow revoke the original
> > author/contributor list.
>
> No, it does not. But it does make me much more sympathetic towards
> Daniel's efforts even though authorship info is misappropriated. It's
> not as if he changed copyrights or anything malicious like that so I
> do think people are making this into a bigger thing than it really is.
>
> Anyway, I hope Daniel has the time to rebase his patches on top of
> your original ones so history is preserved and we can get this stuff
> merged.
Crap. There is no history which has remotely to do anything with
Daniel patches, which are btw. very sensible and well done.
Patch 1/7 is extracted from one large dump (f5ee31ab10c1) in the
android tree, which has:
9 files changed, 1445 insertions(+), 45 deletions(-)
versus Daniels patch:
1 files changed, 42 insertions(+), 0 deletions(-)
Patch 2/7 is properly assigned to the original author.
Patch 3/7 is extracted from another large dump (37431502c4) in the
android tree which has:
11 files changed, 5336 insertions(+), 6 deletions(-)
versus Daniels patch:
4 files changed, 484 insertions(+), 1 deletions(-)
And if you look at the above 37431502c4 commit then you'll notice that
the author is Dima Zavin <dima@android.com>, 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.
How the f*ck should Daniel attribute the authorship from that shit
pile? And the person who "authored" that mega commit is now
complaining.
I stoppped looking at this point as the whole "so well done" android
tree is a huge stinking pile of sh*t! Not only code wise, also the
history is completely useless due to these mega commits which have no
reference at all.
The only thing what Daniel missed is to add in the change log of his
patches:
Extracted from: git-url branch commit ID
or:
Based on: git-url branch commit ID
That's oversight and not a malicious crime and easy to repair.
The people who make a lot of noise about this including you did not
even bother to look at the patches and the originating mess, which is
in no way suitable to go near mainline in any form.
I really appreciate the well structured effort which Daniel is putting
into this. An effort which should have been done in the first place by
those who cry murder now.
Thanks,
tglx
^ permalink raw reply [flat|nested] 157+ messages in thread* [PATCH 0/7] Nexus One Support
@ 2011-01-22 17:28 ` Thomas Gleixner
0 siblings, 0 replies; 157+ messages in thread
From: Thomas Gleixner @ 2011-01-22 17:28 UTC (permalink / raw)
To: linux-arm-kernel
On Sat, 22 Jan 2011, Pekka Enberg wrote:
> Hi Dima!
>
> On Sat, Jan 22, 2011 at 12:35 PM, Dima Zavin <dmitriyz@google.com> wrote:
> > There's absolutely no hostility. I stated from the very beginning that
> > I appreciate the voluntary effort by a 3rd party to upstream the board
> > files. I only asked that proper authorship be attributed, which is
> > standard linux kernel patch submission procedure when the committer
> > did not originate the code.
>
> OK, that's great! It's poorly reflected in this discussion thread, though.
>
> >> who have been sitting on these patches for over a year now AFAICT.
> >
> > Even if that were true, that does not somehow revoke the original
> > author/contributor list.
>
> No, it does not. But it does make me much more sympathetic towards
> Daniel's efforts even though authorship info is misappropriated. It's
> not as if he changed copyrights or anything malicious like that so I
> do think people are making this into a bigger thing than it really is.
>
> Anyway, I hope Daniel has the time to rebase his patches on top of
> your original ones so history is preserved and we can get this stuff
> merged.
Crap. There is no history which has remotely to do anything with
Daniel patches, which are btw. very sensible and well done.
Patch 1/7 is extracted from one large dump (f5ee31ab10c1) in the
android tree, which has:
9 files changed, 1445 insertions(+), 45 deletions(-)
versus Daniels patch:
1 files changed, 42 insertions(+), 0 deletions(-)
Patch 2/7 is properly assigned to the original author.
Patch 3/7 is extracted from another large dump (37431502c4) in the
android tree which has:
11 files changed, 5336 insertions(+), 6 deletions(-)
versus Daniels patch:
4 files changed, 484 insertions(+), 1 deletions(-)
And if you look at the above 37431502c4 commit then you'll notice that
the author is Dima Zavin <dima@android.com>, 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.
How the f*ck should Daniel attribute the authorship from that shit
pile? And the person who "authored" that mega commit is now
complaining.
I stoppped looking at this point as the whole "so well done" android
tree is a huge stinking pile of sh*t! Not only code wise, also the
history is completely useless due to these mega commits which have no
reference at all.
The only thing what Daniel missed is to add in the change log of his
patches:
Extracted from: git-url branch commit ID
or:
Based on: git-url branch commit ID
That's oversight and not a malicious crime and easy to repair.
The people who make a lot of noise about this including you did not
even bother to look at the patches and the originating mess, which is
in no way suitable to go near mainline in any form.
I really appreciate the well structured effort which Daniel is putting
into this. An effort which should have been done in the first place by
those who cry murder now.
Thanks,
tglx
^ permalink raw reply [flat|nested] 157+ messages in thread* Re: [PATCH 0/7] Nexus One Support
2011-01-22 17:28 ` Thomas Gleixner
(?)
@ 2011-01-22 18:07 ` Denis 'GNUtoo' Carikli
-1 siblings, 0 replies; 157+ messages in thread
From: Denis 'GNUtoo' Carikli @ 2011-01-22 18:07 UTC (permalink / raw)
To: Thomas Gleixner
Cc: Daniel Walker, Ted Ts'o, linux-arm-msm, linux-kernel,
Jesse Barnes, Pekka Enberg, Dima Zavin, Joe Perches, davidb,
linux-arm-kernel
On Sat, 2011-01-22 at 18:28 +0100, Thomas Gleixner wrote:
> I really appreciate the well structured effort which Daniel is putting
> into this.
Me too.
I've an issue similar to the problem mentioned in this thread:
I own a board which came,by default with a 2.6.27 kernel.
A developer of the company that produced and sell the board ported the
board to the 2.6.30 kernel during his spare time(if I remember well)
The patch is publicly available in their svn tree in the form of a
standard unified diff patch(not a git patch)
Is that the proper format for the commit message:
mx31: add support for the bugbase 1.3 from buglabs
This work was based on bug-linux-2.6.30.patch that can be found
in buglabs's svn here:
svn://bugcamp.net/bug/branches/izzy/experimental
Signed-off-by: Denis 'GNUtoo' Carikli <GNUtoo@no-log.org>
The work I did was porting forward the board initialization code and the
serial port support from 2.6.30 to linux-next.
I debugged(with md in uboot to get the printk buffer) the fact that the
serial didn't work,and removed unneeded code to make it work.
I've not submitted yet the work because of this thread,
thanks to Russell King's response I think I'll submit it.
Here's another commit I made and that went into mainline:
commit 9df86e2e702c6d5547aced7f241addd2d698bb11
Author: Denis 'GNUtoo' Carikli <GNUtoo@no-log.org>
Date: Fri Aug 27 23:48:19 2010 +0200
wl1251: Fix queue stopping/waking for TX path
This patch was adapted from 06f7bc7db79fabe6b2ec16eff0f59e4acc21eb72
(from linus's linux-2.6 tree of kernel.org)
here's the original message:
The queue stopping/waking functionality was broken in a way that
could
cause huge latencies in TX transfers and even cause the TX to stall
in the
right circumstances. Correct these problems.
Signed-off-by: Denis 'GNUtoo' Carikli <GNUtoo@no-log.org>
Acked-by: Kalle Valo <kvalo@adurom.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
In this commit I was told not to put the original sign-off, authors
etc...
This is because it would have been confusing and misleading:
It would have appeared like if the commit got Ack,Sign-off etc... by the
people involved in the original commit.
Denis.
^ permalink raw reply [flat|nested] 157+ messages in thread* [PATCH 0/7] Nexus One Support
@ 2011-01-22 18:07 ` Denis 'GNUtoo' Carikli
0 siblings, 0 replies; 157+ messages in thread
From: Denis 'GNUtoo' Carikli @ 2011-01-22 18:07 UTC (permalink / raw)
To: linux-arm-kernel
On Sat, 2011-01-22 at 18:28 +0100, Thomas Gleixner wrote:
> I really appreciate the well structured effort which Daniel is putting
> into this.
Me too.
I've an issue similar to the problem mentioned in this thread:
I own a board which came,by default with a 2.6.27 kernel.
A developer of the company that produced and sell the board ported the
board to the 2.6.30 kernel during his spare time(if I remember well)
The patch is publicly available in their svn tree in the form of a
standard unified diff patch(not a git patch)
Is that the proper format for the commit message:
mx31: add support for the bugbase 1.3 from buglabs
This work was based on bug-linux-2.6.30.patch that can be found
in buglabs's svn here:
svn://bugcamp.net/bug/branches/izzy/experimental
Signed-off-by: Denis 'GNUtoo' Carikli <GNUtoo@no-log.org>
The work I did was porting forward the board initialization code and the
serial port support from 2.6.30 to linux-next.
I debugged(with md in uboot to get the printk buffer) the fact that the
serial didn't work,and removed unneeded code to make it work.
I've not submitted yet the work because of this thread,
thanks to Russell King's response I think I'll submit it.
Here's another commit I made and that went into mainline:
commit 9df86e2e702c6d5547aced7f241addd2d698bb11
Author: Denis 'GNUtoo' Carikli <GNUtoo@no-log.org>
Date: Fri Aug 27 23:48:19 2010 +0200
wl1251: Fix queue stopping/waking for TX path
This patch was adapted from 06f7bc7db79fabe6b2ec16eff0f59e4acc21eb72
(from linus's linux-2.6 tree of kernel.org)
here's the original message:
The queue stopping/waking functionality was broken in a way that
could
cause huge latencies in TX transfers and even cause the TX to stall
in the
right circumstances. Correct these problems.
Signed-off-by: Denis 'GNUtoo' Carikli <GNUtoo@no-log.org>
Acked-by: Kalle Valo <kvalo@adurom.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
In this commit I was told not to put the original sign-off, authors
etc...
This is because it would have been confusing and misleading:
It would have appeared like if the commit got Ack,Sign-off etc... by the
people involved in the original commit.
Denis.
^ permalink raw reply [flat|nested] 157+ messages in thread* Re: [PATCH 0/7] Nexus One Support
@ 2011-01-22 18:07 ` Denis 'GNUtoo' Carikli
0 siblings, 0 replies; 157+ messages in thread
From: Denis 'GNUtoo' Carikli @ 2011-01-22 18:07 UTC (permalink / raw)
To: Thomas Gleixner
Cc: Pekka Enberg, Dima Zavin, Ted Ts'o, Daniel Walker,
Jesse Barnes, Joe Perches, linux-arm-msm, linux-arm-kernel,
linux-kernel, davidb
On Sat, 2011-01-22 at 18:28 +0100, Thomas Gleixner wrote:
> I really appreciate the well structured effort which Daniel is putting
> into this.
Me too.
I've an issue similar to the problem mentioned in this thread:
I own a board which came,by default with a 2.6.27 kernel.
A developer of the company that produced and sell the board ported the
board to the 2.6.30 kernel during his spare time(if I remember well)
The patch is publicly available in their svn tree in the form of a
standard unified diff patch(not a git patch)
Is that the proper format for the commit message:
mx31: add support for the bugbase 1.3 from buglabs
This work was based on bug-linux-2.6.30.patch that can be found
in buglabs's svn here:
svn://bugcamp.net/bug/branches/izzy/experimental
Signed-off-by: Denis 'GNUtoo' Carikli <GNUtoo@no-log.org>
The work I did was porting forward the board initialization code and the
serial port support from 2.6.30 to linux-next.
I debugged(with md in uboot to get the printk buffer) the fact that the
serial didn't work,and removed unneeded code to make it work.
I've not submitted yet the work because of this thread,
thanks to Russell King's response I think I'll submit it.
Here's another commit I made and that went into mainline:
commit 9df86e2e702c6d5547aced7f241addd2d698bb11
Author: Denis 'GNUtoo' Carikli <GNUtoo@no-log.org>
Date: Fri Aug 27 23:48:19 2010 +0200
wl1251: Fix queue stopping/waking for TX path
This patch was adapted from 06f7bc7db79fabe6b2ec16eff0f59e4acc21eb72
(from linus's linux-2.6 tree of kernel.org)
here's the original message:
The queue stopping/waking functionality was broken in a way that
could
cause huge latencies in TX transfers and even cause the TX to stall
in the
right circumstances. Correct these problems.
Signed-off-by: Denis 'GNUtoo' Carikli <GNUtoo@no-log.org>
Acked-by: Kalle Valo <kvalo@adurom.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
In this commit I was told not to put the original sign-off, authors
etc...
This is because it would have been confusing and misleading:
It would have appeared like if the commit got Ack,Sign-off etc... by the
people involved in the original commit.
Denis.
^ permalink raw reply [flat|nested] 157+ messages in thread* Re: [PATCH 0/7] Nexus One Support
2011-01-22 18:07 ` Denis 'GNUtoo' Carikli
(?)
@ 2011-01-22 18:15 ` Dima Zavin
-1 siblings, 0 replies; 157+ messages in thread
From: Dima Zavin @ 2011-01-22 18:15 UTC (permalink / raw)
To: Denis 'GNUtoo' Carikli
Cc: Thomas Gleixner, Pekka Enberg, Ted Ts'o, Daniel Walker,
Jesse Barnes, Joe Perches, linux-arm-msm, linux-arm-kernel,
linux-kernel, davidb
Denis,
Your approach would have been fine as well. Some mechanism to point
out where the original lives like pasting a link saying 'Original code
can be found in <url>" or "Based on the code as found in <url>" as you
did would have also been enough as well.
--Dima
On Sat, Jan 22, 2011 at 10:07 AM, Denis 'GNUtoo' Carikli
<GNUtoo@no-log.org> wrote:
> On Sat, 2011-01-22 at 18:28 +0100, Thomas Gleixner wrote:
>> I really appreciate the well structured effort which Daniel is putting
>> into this.
> Me too.
>
>
> I've an issue similar to the problem mentioned in this thread:
> I own a board which came,by default with a 2.6.27 kernel.
> A developer of the company that produced and sell the board ported the
> board to the 2.6.30 kernel during his spare time(if I remember well)
> The patch is publicly available in their svn tree in the form of a
> standard unified diff patch(not a git patch)
>
> Is that the proper format for the commit message:
> mx31: add support for the bugbase 1.3 from buglabs
>
> This work was based on bug-linux-2.6.30.patch that can be found
> in buglabs's svn here:
> svn://bugcamp.net/bug/branches/izzy/experimental
>
> Signed-off-by: Denis 'GNUtoo' Carikli <GNUtoo@no-log.org>
>
> The work I did was porting forward the board initialization code and the
> serial port support from 2.6.30 to linux-next.
> I debugged(with md in uboot to get the printk buffer) the fact that the
> serial didn't work,and removed unneeded code to make it work.
>
> I've not submitted yet the work because of this thread,
> thanks to Russell King's response I think I'll submit it.
>
>
> Here's another commit I made and that went into mainline:
> commit 9df86e2e702c6d5547aced7f241addd2d698bb11
> Author: Denis 'GNUtoo' Carikli <GNUtoo@no-log.org>
> Date: Fri Aug 27 23:48:19 2010 +0200
>
> wl1251: Fix queue stopping/waking for TX path
>
> This patch was adapted from 06f7bc7db79fabe6b2ec16eff0f59e4acc21eb72
> (from linus's linux-2.6 tree of kernel.org)
>
> here's the original message:
> The queue stopping/waking functionality was broken in a way that
> could
> cause huge latencies in TX transfers and even cause the TX to stall
> in the
> right circumstances. Correct these problems.
>
> Signed-off-by: Denis 'GNUtoo' Carikli <GNUtoo@no-log.org>
> Acked-by: Kalle Valo <kvalo@adurom.com>
> Signed-off-by: John W. Linville <linville@tuxdriver.com>
>
> In this commit I was told not to put the original sign-off, authors
> etc...
> This is because it would have been confusing and misleading:
> It would have appeared like if the commit got Ack,Sign-off etc... by the
> people involved in the original commit.
>
> Denis.
>
>
>
--
To unsubscribe from this list: send the line "unsubscribe linux-arm-msm" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply [flat|nested] 157+ messages in thread
* [PATCH 0/7] Nexus One Support
@ 2011-01-22 18:15 ` Dima Zavin
0 siblings, 0 replies; 157+ messages in thread
From: Dima Zavin @ 2011-01-22 18:15 UTC (permalink / raw)
To: linux-arm-kernel
Denis,
Your approach would have been fine as well. Some mechanism to point
out where the original lives like pasting a link saying 'Original code
can be found in <url>" or "Based on the code as found in <url>" as you
did would have also been enough as well.
--Dima
On Sat, Jan 22, 2011 at 10:07 AM, Denis 'GNUtoo' Carikli
<GNUtoo@no-log.org> wrote:
> On Sat, 2011-01-22 at 18:28 +0100, Thomas Gleixner wrote:
>> I really appreciate the well structured effort which Daniel is putting
>> into this.
> Me too.
>
>
> I've an issue similar to the problem mentioned in this thread:
> I own a board which came,by default with a 2.6.27 kernel.
> A developer of the company that produced and sell the board ported the
> board to the 2.6.30 kernel during his spare time(if I remember well)
> The patch is publicly available in their svn tree in the form of a
> standard unified diff patch(not a git patch)
>
> Is that the proper format for the commit message:
> ? ?mx31: add support for the bugbase 1.3 from buglabs
>
> ? ?This work was based on bug-linux-2.6.30.patch that can be found
> ? ? ?in buglabs's svn here:
> ? ? ?svn://bugcamp.net/bug/branches/izzy/experimental
>
> ? ?Signed-off-by: Denis 'GNUtoo' Carikli <GNUtoo@no-log.org>
>
> The work I did was porting forward the board initialization code and the
> serial port support from 2.6.30 to linux-next.
> I debugged(with md in uboot to get the printk buffer) the fact that the
> serial didn't work,and removed unneeded code to make it work.
>
> I've not submitted yet the work because of this thread,
> thanks to Russell King's response I think I'll submit it.
>
>
> Here's another commit I made and that went into mainline:
> commit 9df86e2e702c6d5547aced7f241addd2d698bb11
> Author: Denis 'GNUtoo' Carikli <GNUtoo@no-log.org>
> Date: ? Fri Aug 27 23:48:19 2010 +0200
>
> wl1251: Fix queue stopping/waking for TX path
>
> This patch was adapted from 06f7bc7db79fabe6b2ec16eff0f59e4acc21eb72
> (from linus's linux-2.6 tree of kernel.org)
>
> here's the original message:
> ? ?The queue stopping/waking functionality was broken in a way that
> could
> ? ?cause huge latencies in TX transfers and even cause the TX to stall
> in the
> ? ?right circumstances. Correct these problems.
>
> Signed-off-by: Denis 'GNUtoo' Carikli <GNUtoo@no-log.org>
> Acked-by: Kalle Valo <kvalo@adurom.com>
> Signed-off-by: John W. Linville <linville@tuxdriver.com>
>
> In this commit I was told not to put the original sign-off, authors
> etc...
> This is because it would have been confusing and misleading:
> It would have appeared like if the commit got Ack,Sign-off etc... by the
> people involved in the original commit.
>
> Denis.
>
>
>
^ permalink raw reply [flat|nested] 157+ messages in thread
* Re: [PATCH 0/7] Nexus One Support
@ 2011-01-22 18:15 ` Dima Zavin
0 siblings, 0 replies; 157+ messages in thread
From: Dima Zavin @ 2011-01-22 18:15 UTC (permalink / raw)
To: Denis 'GNUtoo' Carikli
Cc: Thomas Gleixner, Pekka Enberg, Ted Ts'o, Daniel Walker,
Jesse Barnes, Joe Perches, linux-arm-msm, linux-arm-kernel,
linux-kernel, davidb
Denis,
Your approach would have been fine as well. Some mechanism to point
out where the original lives like pasting a link saying 'Original code
can be found in <url>" or "Based on the code as found in <url>" as you
did would have also been enough as well.
--Dima
On Sat, Jan 22, 2011 at 10:07 AM, Denis 'GNUtoo' Carikli
<GNUtoo@no-log.org> wrote:
> On Sat, 2011-01-22 at 18:28 +0100, Thomas Gleixner wrote:
>> I really appreciate the well structured effort which Daniel is putting
>> into this.
> Me too.
>
>
> I've an issue similar to the problem mentioned in this thread:
> I own a board which came,by default with a 2.6.27 kernel.
> A developer of the company that produced and sell the board ported the
> board to the 2.6.30 kernel during his spare time(if I remember well)
> The patch is publicly available in their svn tree in the form of a
> standard unified diff patch(not a git patch)
>
> Is that the proper format for the commit message:
> mx31: add support for the bugbase 1.3 from buglabs
>
> This work was based on bug-linux-2.6.30.patch that can be found
> in buglabs's svn here:
> svn://bugcamp.net/bug/branches/izzy/experimental
>
> Signed-off-by: Denis 'GNUtoo' Carikli <GNUtoo@no-log.org>
>
> The work I did was porting forward the board initialization code and the
> serial port support from 2.6.30 to linux-next.
> I debugged(with md in uboot to get the printk buffer) the fact that the
> serial didn't work,and removed unneeded code to make it work.
>
> I've not submitted yet the work because of this thread,
> thanks to Russell King's response I think I'll submit it.
>
>
> Here's another commit I made and that went into mainline:
> commit 9df86e2e702c6d5547aced7f241addd2d698bb11
> Author: Denis 'GNUtoo' Carikli <GNUtoo@no-log.org>
> Date: Fri Aug 27 23:48:19 2010 +0200
>
> wl1251: Fix queue stopping/waking for TX path
>
> This patch was adapted from 06f7bc7db79fabe6b2ec16eff0f59e4acc21eb72
> (from linus's linux-2.6 tree of kernel.org)
>
> here's the original message:
> The queue stopping/waking functionality was broken in a way that
> could
> cause huge latencies in TX transfers and even cause the TX to stall
> in the
> right circumstances. Correct these problems.
>
> Signed-off-by: Denis 'GNUtoo' Carikli <GNUtoo@no-log.org>
> Acked-by: Kalle Valo <kvalo@adurom.com>
> Signed-off-by: John W. Linville <linville@tuxdriver.com>
>
> In this commit I was told not to put the original sign-off, authors
> etc...
> This is because it would have been confusing and misleading:
> It would have appeared like if the commit got Ack,Sign-off etc... by the
> people involved in the original commit.
>
> Denis.
>
>
>
^ permalink raw reply [flat|nested] 157+ messages in thread
* Re: [PATCH 0/7] Nexus One Support
2011-01-22 8:19 ` Pekka Enberg
@ 2011-01-22 20:55 ` Christoph Hellwig
-1 siblings, 0 replies; 157+ messages in thread
From: Christoph Hellwig @ 2011-01-22 20:55 UTC (permalink / raw)
To: Pekka Enberg
Cc: Ted Ts'o, Daniel Walker, Dima Zavin, Jesse Barnes,
Joe Perches, linux-arm-msm, linux-arm-kernel, linux-kernel,
davidb
On Sat, Jan 22, 2011 at 10:19:58AM +0200, Pekka Enberg wrote:
> Sure, it would have been nicer for everyone involved if Daniel would
> have kept the original patches and added new patches to clean it up on
> top of that to preserve the history.
No, it would be a complete fucking mess that way. We tell people to
submit standalone and well formed patches all the time. Why would it
make any difference just because they were also commited to a shitty git
tree somewhere else?
^ permalink raw reply [flat|nested] 157+ messages in thread
* [PATCH 0/7] Nexus One Support
@ 2011-01-22 20:55 ` Christoph Hellwig
0 siblings, 0 replies; 157+ messages in thread
From: Christoph Hellwig @ 2011-01-22 20:55 UTC (permalink / raw)
To: linux-arm-kernel
On Sat, Jan 22, 2011 at 10:19:58AM +0200, Pekka Enberg wrote:
> Sure, it would have been nicer for everyone involved if Daniel would
> have kept the original patches and added new patches to clean it up on
> top of that to preserve the history.
No, it would be a complete fucking mess that way. We tell people to
submit standalone and well formed patches all the time. Why would it
make any difference just because they were also commited to a shitty git
tree somewhere else?
^ permalink raw reply [flat|nested] 157+ messages in thread
* Re: [PATCH 0/7] Nexus One Support
2011-01-22 20:55 ` Christoph Hellwig
(?)
@ 2011-01-22 21:56 ` Pekka Enberg
-1 siblings, 0 replies; 157+ messages in thread
From: Pekka Enberg @ 2011-01-22 21:56 UTC (permalink / raw)
To: Christoph Hellwig
Cc: Ted Ts'o, Daniel Walker, Dima Zavin, Jesse Barnes,
Joe Perches, linux-arm-msm, linux-arm-kernel, linux-kernel,
davidb
Hi Christoph!
On Sat, Jan 22, 2011 at 10:19:58AM +0200, Pekka Enberg wrote:
>> Sure, it would have been nicer for everyone involved if Daniel would
>> have kept the original patches and added new patches to clean it up on
>> top of that to preserve the history.
On Sat, Jan 22, 2011 at 10:55 PM, Christoph Hellwig <hch@infradead.org> wrote:
> No, it would be a complete fucking mess that way. We tell people to
> submit standalone and well formed patches all the time. Why would it
> make any difference just because they were also commited to a shitty git
> tree somewhere else?
We also tell people to submit crap into tree all the time - it's
called staging! We also merge full history from time to time like in
the case of btrfs.
Usually even "shitty git trees" have value in the history for people
who're interested why the code is the way it is. But as people who
actually looked at the patches, it doesn't apply here.
Pekka
--
To unsubscribe from this list: send the line "unsubscribe linux-arm-msm" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply [flat|nested] 157+ messages in thread* [PATCH 0/7] Nexus One Support
@ 2011-01-22 21:56 ` Pekka Enberg
0 siblings, 0 replies; 157+ messages in thread
From: Pekka Enberg @ 2011-01-22 21:56 UTC (permalink / raw)
To: linux-arm-kernel
Hi Christoph!
On Sat, Jan 22, 2011 at 10:19:58AM +0200, Pekka Enberg wrote:
>> Sure, it would have been nicer for everyone involved if Daniel would
>> have kept the original patches and added new patches to clean it up on
>> top of that to preserve the history.
On Sat, Jan 22, 2011 at 10:55 PM, Christoph Hellwig <hch@infradead.org> wrote:
> No, it would be a complete fucking mess that way. ?We tell people to
> submit standalone and well formed patches all the time. ?Why would it
> make any difference just because they were also commited to a shitty git
> tree somewhere else?
We also tell people to submit crap into tree all the time - it's
called staging! We also merge full history from time to time like in
the case of btrfs.
Usually even "shitty git trees" have value in the history for people
who're interested why the code is the way it is. But as people who
actually looked at the patches, it doesn't apply here.
Pekka
^ permalink raw reply [flat|nested] 157+ messages in thread* Re: [PATCH 0/7] Nexus One Support
@ 2011-01-22 21:56 ` Pekka Enberg
0 siblings, 0 replies; 157+ messages in thread
From: Pekka Enberg @ 2011-01-22 21:56 UTC (permalink / raw)
To: Christoph Hellwig
Cc: Ted Ts'o, Daniel Walker, Dima Zavin, Jesse Barnes,
Joe Perches, linux-arm-msm, linux-arm-kernel, linux-kernel,
davidb
Hi Christoph!
On Sat, Jan 22, 2011 at 10:19:58AM +0200, Pekka Enberg wrote:
>> Sure, it would have been nicer for everyone involved if Daniel would
>> have kept the original patches and added new patches to clean it up on
>> top of that to preserve the history.
On Sat, Jan 22, 2011 at 10:55 PM, Christoph Hellwig <hch@infradead.org> wrote:
> No, it would be a complete fucking mess that way. We tell people to
> submit standalone and well formed patches all the time. Why would it
> make any difference just because they were also commited to a shitty git
> tree somewhere else?
We also tell people to submit crap into tree all the time - it's
called staging! We also merge full history from time to time like in
the case of btrfs.
Usually even "shitty git trees" have value in the history for people
who're interested why the code is the way it is. But as people who
actually looked at the patches, it doesn't apply here.
Pekka
^ permalink raw reply [flat|nested] 157+ messages in thread* Re: [PATCH 0/7] Nexus One Support
2011-01-22 21:56 ` Pekka Enberg
@ 2011-01-22 21:58 ` Christoph Hellwig
-1 siblings, 0 replies; 157+ messages in thread
From: Christoph Hellwig @ 2011-01-22 21:58 UTC (permalink / raw)
To: Pekka Enberg
Cc: Christoph Hellwig, Ted Ts'o, Daniel Walker, Dima Zavin,
Jesse Barnes, Joe Perches, linux-arm-msm, linux-arm-kernel,
linux-kernel, davidb
On Sat, Jan 22, 2011 at 11:56:14PM +0200, Pekka Enberg wrote:
> We also tell people to submit crap into tree all the time - it's
> called staging!
Which is totally unrelated to this flameware. Also if crap goes into
staging it doesn't go with years of useless version history.
>We also merge full history from time to time like in
> the case of btrfs.
We do it something, but only for projects that actually follow the Linux
commit guidelines.
> Usually even "shitty git trees" have value in the history for people
> who're interested why the code is the way it is. But as people who
> actually looked at the patches, it doesn't apply here.
Thomas posted how the android tree commits looks. How about getting a
clue before posting more useless noise in this thread?
^ permalink raw reply [flat|nested] 157+ messages in thread
* [PATCH 0/7] Nexus One Support
@ 2011-01-22 21:58 ` Christoph Hellwig
0 siblings, 0 replies; 157+ messages in thread
From: Christoph Hellwig @ 2011-01-22 21:58 UTC (permalink / raw)
To: linux-arm-kernel
On Sat, Jan 22, 2011 at 11:56:14PM +0200, Pekka Enberg wrote:
> We also tell people to submit crap into tree all the time - it's
> called staging!
Which is totally unrelated to this flameware. Also if crap goes into
staging it doesn't go with years of useless version history.
>We also merge full history from time to time like in
> the case of btrfs.
We do it something, but only for projects that actually follow the Linux
commit guidelines.
> Usually even "shitty git trees" have value in the history for people
> who're interested why the code is the way it is. But as people who
> actually looked at the patches, it doesn't apply here.
Thomas posted how the android tree commits looks. How about getting a
clue before posting more useless noise in this thread?
^ permalink raw reply [flat|nested] 157+ messages in thread
* Re: [PATCH 0/7] Nexus One Support
2011-01-22 21:58 ` Christoph Hellwig
(?)
@ 2011-01-22 22:13 ` Pekka Enberg
-1 siblings, 0 replies; 157+ messages in thread
From: Pekka Enberg @ 2011-01-22 22:13 UTC (permalink / raw)
To: Christoph Hellwig
Cc: Ted Ts'o, Daniel Walker, Dima Zavin, Jesse Barnes,
Joe Perches, linux-arm-msm, linux-arm-kernel, linux-kernel,
davidb
On Sat, Jan 22, 2011 at 11:58 PM, Christoph Hellwig <hch@infradead.org> wrote:
>> Usually even "shitty git trees" have value in the history for people
>> who're interested why the code is the way it is. But as people who
>> actually looked at the patches, it doesn't apply here.
>
> Thomas posted how the android tree commits looks. How about getting a
> clue before posting more useless noise in this thread?
Oh, don't you even try to "pull a Christoph" on me! I did see Thomas'
and Russell's comments about the quality of the tree which is why I
said "it doesn't apply here" (that the history is useless).
--
To unsubscribe from this list: send the line "unsubscribe linux-arm-msm" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply [flat|nested] 157+ messages in thread
* [PATCH 0/7] Nexus One Support
@ 2011-01-22 22:13 ` Pekka Enberg
0 siblings, 0 replies; 157+ messages in thread
From: Pekka Enberg @ 2011-01-22 22:13 UTC (permalink / raw)
To: linux-arm-kernel
On Sat, Jan 22, 2011 at 11:58 PM, Christoph Hellwig <hch@infradead.org> wrote:
>> Usually even "shitty git trees" have value in the history for people
>> who're interested why the code is the way it is. But as people who
>> actually looked at the patches, it doesn't apply here.
>
> Thomas posted how the android tree commits looks. ?How about getting a
> clue before posting more useless noise in this thread?
Oh, don't you even try to "pull a Christoph" on me! I did see Thomas'
and Russell's comments about the quality of the tree which is why I
said "it doesn't apply here" (that the history is useless).
^ permalink raw reply [flat|nested] 157+ messages in thread
* Re: [PATCH 0/7] Nexus One Support
@ 2011-01-22 22:13 ` Pekka Enberg
0 siblings, 0 replies; 157+ messages in thread
From: Pekka Enberg @ 2011-01-22 22:13 UTC (permalink / raw)
To: Christoph Hellwig
Cc: Ted Ts'o, Daniel Walker, Dima Zavin, Jesse Barnes,
Joe Perches, linux-arm-msm, linux-arm-kernel, linux-kernel,
davidb
On Sat, Jan 22, 2011 at 11:58 PM, Christoph Hellwig <hch@infradead.org> wrote:
>> Usually even "shitty git trees" have value in the history for people
>> who're interested why the code is the way it is. But as people who
>> actually looked at the patches, it doesn't apply here.
>
> Thomas posted how the android tree commits looks. How about getting a
> clue before posting more useless noise in this thread?
Oh, don't you even try to "pull a Christoph" on me! I did see Thomas'
and Russell's comments about the quality of the tree which is why I
said "it doesn't apply here" (that the history is useless).
^ permalink raw reply [flat|nested] 157+ messages in thread
* Re: [PATCH 0/7] Nexus One Support
2011-01-20 20:32 ` Daniel Walker
@ 2011-02-04 13:36 ` Pavel Machek
-1 siblings, 0 replies; 157+ messages in thread
From: Pavel Machek @ 2011-02-04 13:36 UTC (permalink / raw)
To: Daniel Walker; +Cc: linux-arm-msm, linux-arm-kernel, linux-kernel, davidb
On Thu 2011-01-20 12:32:38, Daniel Walker 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.
> 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
Even you call the machine Nexus One... can you be a tiny bit more
consistent with it?
--
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
^ permalink raw reply [flat|nested] 157+ messages in thread
* [PATCH 0/7] Nexus One Support
@ 2011-02-04 13:36 ` Pavel Machek
0 siblings, 0 replies; 157+ messages in thread
From: Pavel Machek @ 2011-02-04 13:36 UTC (permalink / raw)
To: linux-arm-kernel
On Thu 2011-01-20 12:32:38, Daniel Walker 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.
> 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
Even you call the machine Nexus One... can you be a tiny bit more
consistent with it?
--
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
^ permalink raw reply [flat|nested] 157+ messages in thread
* Re: [PATCH 0/7] Nexus One Support
2011-02-04 13:36 ` Pavel Machek
(?)
@ 2011-02-07 17:36 ` Daniel Walker
-1 siblings, 0 replies; 157+ messages in thread
From: Daniel Walker @ 2011-02-07 17:36 UTC (permalink / raw)
To: Pavel Machek; +Cc: linux-arm-msm, davidb, linux-kernel, linux-arm-kernel
On Fri, 2011-02-04 at 14:36 +0100, Pavel Machek wrote:
> On Thu 2011-01-20 12:32:38, Daniel Walker 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.
>
> > 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
>
> Even you call the machine Nexus One... can you be a tiny bit more
> consistent with it?
I tried to call it Nexus One in this release note cause no one knows
what a "mahimahi" is .. I would like to call it Nexus One all over, but
I can't because Google uses the name mahimahi..
Daniel
--
Sent by a consultant of the Qualcomm Innovation Center, Inc.
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum.
^ permalink raw reply [flat|nested] 157+ messages in thread
* [PATCH 0/7] Nexus One Support
@ 2011-02-07 17:36 ` Daniel Walker
0 siblings, 0 replies; 157+ messages in thread
From: Daniel Walker @ 2011-02-07 17:36 UTC (permalink / raw)
To: linux-arm-kernel
On Fri, 2011-02-04 at 14:36 +0100, Pavel Machek wrote:
> On Thu 2011-01-20 12:32:38, Daniel Walker 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.
>
> > 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
>
> Even you call the machine Nexus One... can you be a tiny bit more
> consistent with it?
I tried to call it Nexus One in this release note cause no one knows
what a "mahimahi" is .. I would like to call it Nexus One all over, but
I can't because Google uses the name mahimahi..
Daniel
--
Sent by a consultant of the Qualcomm Innovation Center, Inc.
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum.
^ permalink raw reply [flat|nested] 157+ messages in thread
* Re: [PATCH 0/7] Nexus One Support
@ 2011-02-07 17:36 ` Daniel Walker
0 siblings, 0 replies; 157+ messages in thread
From: Daniel Walker @ 2011-02-07 17:36 UTC (permalink / raw)
To: Pavel Machek; +Cc: linux-arm-msm, linux-arm-kernel, linux-kernel, davidb
On Fri, 2011-02-04 at 14:36 +0100, Pavel Machek wrote:
> On Thu 2011-01-20 12:32:38, Daniel Walker 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.
>
> > 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
>
> Even you call the machine Nexus One... can you be a tiny bit more
> consistent with it?
I tried to call it Nexus One in this release note cause no one knows
what a "mahimahi" is .. I would like to call it Nexus One all over, but
I can't because Google uses the name mahimahi..
Daniel
--
Sent by a consultant of the Qualcomm Innovation Center, Inc.
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum.
^ permalink raw reply [flat|nested] 157+ messages in thread