* [PATCH v2 0/5] ARM: OMAP: dead code removal
From: Nicolae Rosia @ 2016-11-04 14:02 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1478000206-10855-1-git-send-email-Nicolae_Rosia@mentor.com>
Hi,
I have identified some dead code which can be removed.
v2:
- Added details on each commit on how the code ended up unused.
Nicolae Rosia (5):
ARM: OMAP4: kill omap4_pmic_init and omap4_pmic_get_config
ARM: OMAP3: kill omap3_pmic_get_config and twl_{get,set}_voltage
ARM: OMAP3: kill omap3_pmic_init
ARM: OMAP2: kill omap2_pmic_init
ARM: OMAP: kill omap_pmic_init
arch/arm/mach-omap2/twl-common.c | 483 ---------------------------------------
arch/arm/mach-omap2/twl-common.h | 24 --
2 files changed, 507 deletions(-)
--
2.5.5
^ permalink raw reply
* [PATCH v2 1/5] ARM: OMAP4: kill omap4_pmic_init and omap4_pmic_get_config
From: Nicolae Rosia @ 2016-11-04 14:02 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1478268138-7044-1-git-send-email-Nicolae_Rosia@mentor.com>
Last user of these functions was deleted in commit
b42b91 ("ARM: OMAP2+: Remove board-omap4panda.c") during DT transition.
Signed-off-by: Nicolae Rosia <Nicolae_Rosia@mentor.com>
---
arch/arm/mach-omap2/twl-common.c | 312 +--------------------------------------
arch/arm/mach-omap2/twl-common.h | 7 -
2 files changed, 1 insertion(+), 318 deletions(-)
diff --git a/arch/arm/mach-omap2/twl-common.c b/arch/arm/mach-omap2/twl-common.c
index a72738e..06a7521 100644
--- a/arch/arm/mach-omap2/twl-common.c
+++ b/arch/arm/mach-omap2/twl-common.c
@@ -39,7 +39,7 @@ static struct i2c_board_info __initdata pmic_i2c_board_info = {
.flags = I2C_CLIENT_WAKE,
};
-#if defined(CONFIG_ARCH_OMAP3) || defined(CONFIG_ARCH_OMAP4)
+#if defined(CONFIG_ARCH_OMAP3)
static int twl_set_voltage(void *data, int target_uV)
{
struct voltagedomain *voltdm = (struct voltagedomain *)data;
@@ -66,25 +66,6 @@ void __init omap_pmic_init(int bus, u32 clkrate,
omap_register_i2c_bus(bus, clkrate, &pmic_i2c_board_info, 1);
}
-#ifdef CONFIG_ARCH_OMAP4
-void __init omap4_pmic_init(const char *pmic_type,
- struct twl4030_platform_data *pmic_data,
- struct i2c_board_info *devices, int nr_devices)
-{
- /* PMIC part*/
- unsigned int irq;
-
- omap_mux_init_signal("sys_nirq1", OMAP_PIN_INPUT_PULLUP | OMAP_PIN_OFF_WAKEUPENABLE);
- omap_mux_init_signal("fref_clk0_out.sys_drm_msecure", OMAP_PIN_OUTPUT);
- irq = omap4_xlate_irq(7 + OMAP44XX_IRQ_GIC_START);
- omap_pmic_init(1, 400, pmic_type, irq, pmic_data);
-
- /* Register additional devices on i2c1 bus if needed */
- if (devices)
- i2c_register_board_info(1, devices, nr_devices);
-}
-#endif
-
void __init omap_pmic_late_init(void)
{
/* Init the OMAP TWL parameters (if PMIC has been registerd) */
@@ -241,297 +222,6 @@ void __init omap3_pmic_get_config(struct twl4030_platform_data *pmic_data,
}
#endif /* CONFIG_ARCH_OMAP3 */
-#if defined(CONFIG_ARCH_OMAP4)
-static struct twl4030_usb_data omap4_usb_pdata = {
-};
-
-static struct regulator_consumer_supply omap4_vdda_hdmi_dac_supplies[] = {
- REGULATOR_SUPPLY("vdda_hdmi_dac", "omapdss_hdmi"),
-};
-
-static struct regulator_init_data omap4_vdac_idata = {
- .constraints = {
- .min_uV = 1800000,
- .max_uV = 1800000,
- .valid_modes_mask = REGULATOR_MODE_NORMAL
- | REGULATOR_MODE_STANDBY,
- .valid_ops_mask = REGULATOR_CHANGE_MODE
- | REGULATOR_CHANGE_STATUS,
- },
- .num_consumer_supplies = ARRAY_SIZE(omap4_vdda_hdmi_dac_supplies),
- .consumer_supplies = omap4_vdda_hdmi_dac_supplies,
- .supply_regulator = "V2V1",
-};
-
-static struct regulator_init_data omap4_vaux2_idata = {
- .constraints = {
- .min_uV = 1200000,
- .max_uV = 2800000,
- .apply_uV = true,
- .valid_modes_mask = REGULATOR_MODE_NORMAL
- | REGULATOR_MODE_STANDBY,
- .valid_ops_mask = REGULATOR_CHANGE_VOLTAGE
- | REGULATOR_CHANGE_MODE
- | REGULATOR_CHANGE_STATUS,
- },
-};
-
-static struct regulator_init_data omap4_vaux3_idata = {
- .constraints = {
- .min_uV = 1000000,
- .max_uV = 3000000,
- .apply_uV = true,
- .valid_modes_mask = REGULATOR_MODE_NORMAL
- | REGULATOR_MODE_STANDBY,
- .valid_ops_mask = REGULATOR_CHANGE_VOLTAGE
- | REGULATOR_CHANGE_MODE
- | REGULATOR_CHANGE_STATUS,
- },
-};
-
-static struct regulator_consumer_supply omap4_vmmc_supply[] = {
- REGULATOR_SUPPLY("vmmc", "omap_hsmmc.0"),
-};
-
-/* VMMC1 for MMC1 card */
-static struct regulator_init_data omap4_vmmc_idata = {
- .constraints = {
- .min_uV = 1200000,
- .max_uV = 3000000,
- .apply_uV = true,
- .valid_modes_mask = REGULATOR_MODE_NORMAL
- | REGULATOR_MODE_STANDBY,
- .valid_ops_mask = REGULATOR_CHANGE_VOLTAGE
- | REGULATOR_CHANGE_MODE
- | REGULATOR_CHANGE_STATUS,
- },
- .num_consumer_supplies = ARRAY_SIZE(omap4_vmmc_supply),
- .consumer_supplies = omap4_vmmc_supply,
-};
-
-static struct regulator_init_data omap4_vpp_idata = {
- .constraints = {
- .min_uV = 1800000,
- .max_uV = 2500000,
- .apply_uV = true,
- .valid_modes_mask = REGULATOR_MODE_NORMAL
- | REGULATOR_MODE_STANDBY,
- .valid_ops_mask = REGULATOR_CHANGE_VOLTAGE
- | REGULATOR_CHANGE_MODE
- | REGULATOR_CHANGE_STATUS,
- },
-};
-
-static struct regulator_init_data omap4_vana_idata = {
- .constraints = {
- .min_uV = 2100000,
- .max_uV = 2100000,
- .valid_modes_mask = REGULATOR_MODE_NORMAL
- | REGULATOR_MODE_STANDBY,
- .valid_ops_mask = REGULATOR_CHANGE_MODE
- | REGULATOR_CHANGE_STATUS,
- },
-};
-
-static struct regulator_consumer_supply omap4_vcxio_supply[] = {
- REGULATOR_SUPPLY("vdds_dsi", "omapdss_dss"),
- REGULATOR_SUPPLY("vdds_dsi", "omapdss_dsi.0"),
- REGULATOR_SUPPLY("vdds_dsi", "omapdss_dsi.1"),
-};
-
-static struct regulator_init_data omap4_vcxio_idata = {
- .constraints = {
- .min_uV = 1800000,
- .max_uV = 1800000,
- .valid_modes_mask = REGULATOR_MODE_NORMAL
- | REGULATOR_MODE_STANDBY,
- .valid_ops_mask = REGULATOR_CHANGE_MODE
- | REGULATOR_CHANGE_STATUS,
- .always_on = true,
- },
- .num_consumer_supplies = ARRAY_SIZE(omap4_vcxio_supply),
- .consumer_supplies = omap4_vcxio_supply,
- .supply_regulator = "V2V1",
-};
-
-static struct regulator_init_data omap4_vusb_idata = {
- .constraints = {
- .min_uV = 3300000,
- .max_uV = 3300000,
- .valid_modes_mask = REGULATOR_MODE_NORMAL
- | REGULATOR_MODE_STANDBY,
- .valid_ops_mask = REGULATOR_CHANGE_MODE
- | REGULATOR_CHANGE_STATUS,
- },
-};
-
-static struct regulator_init_data omap4_clk32kg_idata = {
- .constraints = {
- .valid_ops_mask = REGULATOR_CHANGE_STATUS,
- },
-};
-
-static struct regulator_consumer_supply omap4_vdd1_supply[] = {
- REGULATOR_SUPPLY("vcc", "cpu0"),
-};
-
-static struct regulator_consumer_supply omap4_vdd2_supply[] = {
- REGULATOR_SUPPLY("vcc", "iva.0"),
-};
-
-static struct regulator_consumer_supply omap4_vdd3_supply[] = {
- REGULATOR_SUPPLY("vcc", "l3_main.0"),
-};
-
-static struct regulator_init_data omap4_vdd1 = {
- .constraints = {
- .name = "vdd_mpu",
- .min_uV = 500000,
- .max_uV = 1500000,
- .valid_modes_mask = REGULATOR_MODE_NORMAL,
- .valid_ops_mask = REGULATOR_CHANGE_VOLTAGE,
- },
- .num_consumer_supplies = ARRAY_SIZE(omap4_vdd1_supply),
- .consumer_supplies = omap4_vdd1_supply,
-};
-
-static struct regulator_init_data omap4_vdd2 = {
- .constraints = {
- .name = "vdd_iva",
- .min_uV = 500000,
- .max_uV = 1500000,
- .valid_modes_mask = REGULATOR_MODE_NORMAL,
- .valid_ops_mask = REGULATOR_CHANGE_VOLTAGE,
- },
- .num_consumer_supplies = ARRAY_SIZE(omap4_vdd2_supply),
- .consumer_supplies = omap4_vdd2_supply,
-};
-
-static struct regulator_init_data omap4_vdd3 = {
- .constraints = {
- .name = "vdd_core",
- .min_uV = 500000,
- .max_uV = 1500000,
- .valid_modes_mask = REGULATOR_MODE_NORMAL,
- .valid_ops_mask = REGULATOR_CHANGE_VOLTAGE,
- },
- .num_consumer_supplies = ARRAY_SIZE(omap4_vdd3_supply),
- .consumer_supplies = omap4_vdd3_supply,
-};
-
-
-static struct twl_regulator_driver_data omap4_vdd1_drvdata = {
- .get_voltage = twl_get_voltage,
- .set_voltage = twl_set_voltage,
-};
-
-static struct twl_regulator_driver_data omap4_vdd2_drvdata = {
- .get_voltage = twl_get_voltage,
- .set_voltage = twl_set_voltage,
-};
-
-static struct twl_regulator_driver_data omap4_vdd3_drvdata = {
- .get_voltage = twl_get_voltage,
- .set_voltage = twl_set_voltage,
-};
-
-static struct regulator_consumer_supply omap4_v1v8_supply[] = {
- REGULATOR_SUPPLY("vio", "1-004b"),
-};
-
-static struct regulator_init_data omap4_v1v8_idata = {
- .constraints = {
- .min_uV = 1800000,
- .max_uV = 1800000,
- .valid_modes_mask = REGULATOR_MODE_NORMAL
- | REGULATOR_MODE_STANDBY,
- .valid_ops_mask = REGULATOR_CHANGE_MODE
- | REGULATOR_CHANGE_STATUS,
- .always_on = true,
- },
- .num_consumer_supplies = ARRAY_SIZE(omap4_v1v8_supply),
- .consumer_supplies = omap4_v1v8_supply,
-};
-
-static struct regulator_consumer_supply omap4_v2v1_supply[] = {
- REGULATOR_SUPPLY("v2v1", "1-004b"),
-};
-
-static struct regulator_init_data omap4_v2v1_idata = {
- .constraints = {
- .min_uV = 2100000,
- .max_uV = 2100000,
- .valid_modes_mask = REGULATOR_MODE_NORMAL
- | REGULATOR_MODE_STANDBY,
- .valid_ops_mask = REGULATOR_CHANGE_MODE
- | REGULATOR_CHANGE_STATUS,
- },
- .num_consumer_supplies = ARRAY_SIZE(omap4_v2v1_supply),
- .consumer_supplies = omap4_v2v1_supply,
-};
-
-void __init omap4_pmic_get_config(struct twl4030_platform_data *pmic_data,
- u32 pdata_flags, u32 regulators_flags)
-{
- if (!pmic_data->vdd1) {
- omap4_vdd1.driver_data = &omap4_vdd1_drvdata;
- omap4_vdd1_drvdata.data = voltdm_lookup("mpu");
- pmic_data->vdd1 = &omap4_vdd1;
- }
-
- if (!pmic_data->vdd2) {
- omap4_vdd2.driver_data = &omap4_vdd2_drvdata;
- omap4_vdd2_drvdata.data = voltdm_lookup("iva");
- pmic_data->vdd2 = &omap4_vdd2;
- }
-
- if (!pmic_data->vdd3) {
- omap4_vdd3.driver_data = &omap4_vdd3_drvdata;
- omap4_vdd3_drvdata.data = voltdm_lookup("core");
- pmic_data->vdd3 = &omap4_vdd3;
- }
-
- /* Common platform data configurations */
- if (pdata_flags & TWL_COMMON_PDATA_USB && !pmic_data->usb)
- pmic_data->usb = &omap4_usb_pdata;
-
- /* Common regulator configurations */
- if (regulators_flags & TWL_COMMON_REGULATOR_VDAC && !pmic_data->vdac)
- pmic_data->vdac = &omap4_vdac_idata;
-
- if (regulators_flags & TWL_COMMON_REGULATOR_VAUX2 && !pmic_data->vaux2)
- pmic_data->vaux2 = &omap4_vaux2_idata;
-
- if (regulators_flags & TWL_COMMON_REGULATOR_VAUX3 && !pmic_data->vaux3)
- pmic_data->vaux3 = &omap4_vaux3_idata;
-
- if (regulators_flags & TWL_COMMON_REGULATOR_VMMC && !pmic_data->vmmc)
- pmic_data->vmmc = &omap4_vmmc_idata;
-
- if (regulators_flags & TWL_COMMON_REGULATOR_VPP && !pmic_data->vpp)
- pmic_data->vpp = &omap4_vpp_idata;
-
- if (regulators_flags & TWL_COMMON_REGULATOR_VANA && !pmic_data->vana)
- pmic_data->vana = &omap4_vana_idata;
-
- if (regulators_flags & TWL_COMMON_REGULATOR_VCXIO && !pmic_data->vcxio)
- pmic_data->vcxio = &omap4_vcxio_idata;
-
- if (regulators_flags & TWL_COMMON_REGULATOR_VUSB && !pmic_data->vusb)
- pmic_data->vusb = &omap4_vusb_idata;
-
- if (regulators_flags & TWL_COMMON_REGULATOR_CLK32KG &&
- !pmic_data->clk32kg)
- pmic_data->clk32kg = &omap4_clk32kg_idata;
-
- if (regulators_flags & TWL_COMMON_REGULATOR_V1V8 && !pmic_data->v1v8)
- pmic_data->v1v8 = &omap4_v1v8_idata;
-
- if (regulators_flags & TWL_COMMON_REGULATOR_V2V1 && !pmic_data->v2v1)
- pmic_data->v2v1 = &omap4_v2v1_idata;
-}
-#endif /* CONFIG_ARCH_OMAP4 */
-
#if IS_ENABLED(CONFIG_SND_OMAP_SOC_OMAP_TWL4030)
#include <linux/platform_data/omap-twl4030.h>
diff --git a/arch/arm/mach-omap2/twl-common.h b/arch/arm/mach-omap2/twl-common.h
index 24b65d0..8e46ca3 100644
--- a/arch/arm/mach-omap2/twl-common.h
+++ b/arch/arm/mach-omap2/twl-common.h
@@ -51,16 +51,9 @@ static inline void omap3_pmic_init(const char *pmic_type,
omap_pmic_init(1, 2600, pmic_type, 7 + OMAP_INTC_START, pmic_data);
}
-void omap4_pmic_init(const char *pmic_type,
- struct twl4030_platform_data *pmic_data,
- struct i2c_board_info *devices, int nr_devices);
-
void omap3_pmic_get_config(struct twl4030_platform_data *pmic_data,
u32 pdata_flags, u32 regulators_flags);
-void omap4_pmic_get_config(struct twl4030_platform_data *pmic_data,
- u32 pdata_flags, u32 regulators_flags);
-
void omap_twl4030_audio_init(char *card_name, struct omap_tw4030_pdata *pdata);
#endif /* __OMAP_PMIC_COMMON__ */
--
2.5.5
^ permalink raw reply related
* [PATCH v2 2/5] ARM: OMAP3: kill omap3_pmic_get_config and twl_{get, set}_voltage
From: Nicolae Rosia @ 2016-11-04 14:02 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1478268138-7044-1-git-send-email-Nicolae_Rosia@mentor.com>
Last user of these functions was removed in commit
e92fc4 ("ARM: OMAP2+: Drop legacy board file for LDP") during
legacy board file removal.
Signed-off-by: Nicolae Rosia <Nicolae_Rosia@mentor.com>
---
arch/arm/mach-omap2/twl-common.c | 160 ---------------------------------------
arch/arm/mach-omap2/twl-common.h | 3 -
2 files changed, 163 deletions(-)
diff --git a/arch/arm/mach-omap2/twl-common.c b/arch/arm/mach-omap2/twl-common.c
index 06a7521..cf3d81b 100644
--- a/arch/arm/mach-omap2/twl-common.c
+++ b/arch/arm/mach-omap2/twl-common.c
@@ -39,20 +39,6 @@ static struct i2c_board_info __initdata pmic_i2c_board_info = {
.flags = I2C_CLIENT_WAKE,
};
-#if defined(CONFIG_ARCH_OMAP3)
-static int twl_set_voltage(void *data, int target_uV)
-{
- struct voltagedomain *voltdm = (struct voltagedomain *)data;
- return voltdm_scale(voltdm, target_uV);
-}
-
-static int twl_get_voltage(void *data)
-{
- struct voltagedomain *voltdm = (struct voltagedomain *)data;
- return voltdm_get_voltage(voltdm);
-}
-#endif
-
void __init omap_pmic_init(int bus, u32 clkrate,
const char *pmic_type, int pmic_irq,
struct twl4030_platform_data *pmic_data)
@@ -76,152 +62,6 @@ void __init omap_pmic_late_init(void)
omap4_twl_init();
}
-#if defined(CONFIG_ARCH_OMAP3)
-static struct twl4030_usb_data omap3_usb_pdata = {
- .usb_mode = T2_USB_MODE_ULPI,
-};
-
-static int omap3_batt_table[] = {
-/* 0 C */
-30800, 29500, 28300, 27100,
-26000, 24900, 23900, 22900, 22000, 21100, 20300, 19400, 18700, 17900,
-17200, 16500, 15900, 15300, 14700, 14100, 13600, 13100, 12600, 12100,
-11600, 11200, 10800, 10400, 10000, 9630, 9280, 8950, 8620, 8310,
-8020, 7730, 7460, 7200, 6950, 6710, 6470, 6250, 6040, 5830,
-5640, 5450, 5260, 5090, 4920, 4760, 4600, 4450, 4310, 4170,
-4040, 3910, 3790, 3670, 3550
-};
-
-static struct twl4030_bci_platform_data omap3_bci_pdata = {
- .battery_tmp_tbl = omap3_batt_table,
- .tblsize = ARRAY_SIZE(omap3_batt_table),
-};
-
-static struct twl4030_madc_platform_data omap3_madc_pdata = {
- .irq_line = 1,
-};
-
-static struct twl4030_codec_data omap3_codec;
-
-static struct twl4030_audio_data omap3_audio_pdata = {
- .audio_mclk = 26000000,
- .codec = &omap3_codec,
-};
-
-static struct regulator_consumer_supply omap3_vdda_dac_supplies[] = {
- REGULATOR_SUPPLY("vdda_dac", "omapdss_venc"),
-};
-
-static struct regulator_init_data omap3_vdac_idata = {
- .constraints = {
- .min_uV = 1800000,
- .max_uV = 1800000,
- .valid_modes_mask = REGULATOR_MODE_NORMAL
- | REGULATOR_MODE_STANDBY,
- .valid_ops_mask = REGULATOR_CHANGE_MODE
- | REGULATOR_CHANGE_STATUS,
- },
- .num_consumer_supplies = ARRAY_SIZE(omap3_vdda_dac_supplies),
- .consumer_supplies = omap3_vdda_dac_supplies,
-};
-
-static struct regulator_consumer_supply omap3_vpll2_supplies[] = {
- REGULATOR_SUPPLY("vdds_dsi", "omapdss"),
- REGULATOR_SUPPLY("vdds_dsi", "omapdss_dpi.0"),
- REGULATOR_SUPPLY("vdds_dsi", "omapdss_dsi.0"),
-};
-
-static struct regulator_init_data omap3_vpll2_idata = {
- .constraints = {
- .min_uV = 1800000,
- .max_uV = 1800000,
- .valid_modes_mask = REGULATOR_MODE_NORMAL
- | REGULATOR_MODE_STANDBY,
- .valid_ops_mask = REGULATOR_CHANGE_MODE
- | REGULATOR_CHANGE_STATUS,
- },
- .num_consumer_supplies = ARRAY_SIZE(omap3_vpll2_supplies),
- .consumer_supplies = omap3_vpll2_supplies,
-};
-
-static struct regulator_consumer_supply omap3_vdd1_supply[] = {
- REGULATOR_SUPPLY("vcc", "cpu0"),
-};
-
-static struct regulator_consumer_supply omap3_vdd2_supply[] = {
- REGULATOR_SUPPLY("vcc", "l3_main.0"),
-};
-
-static struct regulator_init_data omap3_vdd1 = {
- .constraints = {
- .name = "vdd_mpu_iva",
- .min_uV = 600000,
- .max_uV = 1450000,
- .valid_modes_mask = REGULATOR_MODE_NORMAL,
- .valid_ops_mask = REGULATOR_CHANGE_VOLTAGE,
- },
- .num_consumer_supplies = ARRAY_SIZE(omap3_vdd1_supply),
- .consumer_supplies = omap3_vdd1_supply,
-};
-
-static struct regulator_init_data omap3_vdd2 = {
- .constraints = {
- .name = "vdd_core",
- .min_uV = 600000,
- .max_uV = 1450000,
- .valid_modes_mask = REGULATOR_MODE_NORMAL,
- .valid_ops_mask = REGULATOR_CHANGE_VOLTAGE,
- },
- .num_consumer_supplies = ARRAY_SIZE(omap3_vdd2_supply),
- .consumer_supplies = omap3_vdd2_supply,
-};
-
-static struct twl_regulator_driver_data omap3_vdd1_drvdata = {
- .get_voltage = twl_get_voltage,
- .set_voltage = twl_set_voltage,
-};
-
-static struct twl_regulator_driver_data omap3_vdd2_drvdata = {
- .get_voltage = twl_get_voltage,
- .set_voltage = twl_set_voltage,
-};
-
-void __init omap3_pmic_get_config(struct twl4030_platform_data *pmic_data,
- u32 pdata_flags, u32 regulators_flags)
-{
- if (!pmic_data->vdd1) {
- omap3_vdd1.driver_data = &omap3_vdd1_drvdata;
- omap3_vdd1_drvdata.data = voltdm_lookup("mpu_iva");
- pmic_data->vdd1 = &omap3_vdd1;
- }
- if (!pmic_data->vdd2) {
- omap3_vdd2.driver_data = &omap3_vdd2_drvdata;
- omap3_vdd2_drvdata.data = voltdm_lookup("core");
- pmic_data->vdd2 = &omap3_vdd2;
- }
-
- /* Common platform data configurations */
- if (pdata_flags & TWL_COMMON_PDATA_USB && !pmic_data->usb)
- pmic_data->usb = &omap3_usb_pdata;
-
- if (pdata_flags & TWL_COMMON_PDATA_BCI && !pmic_data->bci)
- pmic_data->bci = &omap3_bci_pdata;
-
- if (pdata_flags & TWL_COMMON_PDATA_MADC && !pmic_data->madc)
- pmic_data->madc = &omap3_madc_pdata;
-
- if (pdata_flags & TWL_COMMON_PDATA_AUDIO && !pmic_data->audio)
- pmic_data->audio = &omap3_audio_pdata;
-
- /* Common regulator configurations */
- if (regulators_flags & TWL_COMMON_REGULATOR_VDAC && !pmic_data->vdac)
- pmic_data->vdac = &omap3_vdac_idata;
-
- if (regulators_flags & TWL_COMMON_REGULATOR_VPLL2 && !pmic_data->vpll2)
- pmic_data->vpll2 = &omap3_vpll2_idata;
-}
-#endif /* CONFIG_ARCH_OMAP3 */
-
#if IS_ENABLED(CONFIG_SND_OMAP_SOC_OMAP_TWL4030)
#include <linux/platform_data/omap-twl4030.h>
diff --git a/arch/arm/mach-omap2/twl-common.h b/arch/arm/mach-omap2/twl-common.h
index 8e46ca3..048f6b2 100644
--- a/arch/arm/mach-omap2/twl-common.h
+++ b/arch/arm/mach-omap2/twl-common.h
@@ -51,9 +51,6 @@ static inline void omap3_pmic_init(const char *pmic_type,
omap_pmic_init(1, 2600, pmic_type, 7 + OMAP_INTC_START, pmic_data);
}
-void omap3_pmic_get_config(struct twl4030_platform_data *pmic_data,
- u32 pdata_flags, u32 regulators_flags);
-
void omap_twl4030_audio_init(char *card_name, struct omap_tw4030_pdata *pdata);
#endif /* __OMAP_PMIC_COMMON__ */
--
2.5.5
^ permalink raw reply related
* [PATCH v2 3/5] ARM: OMAP3: kill omap3_pmic_init
From: Nicolae Rosia @ 2016-11-04 14:02 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1478268138-7044-1-git-send-email-Nicolae_Rosia@mentor.com>
Last user of this function was removed in commit
e92fc4 ("ARM: OMAP2+: Drop legacy board file for LDP") during
legacy board file removal.
Signed-off-by: Nicolae Rosia <Nicolae_Rosia@mentor.com>
---
arch/arm/mach-omap2/twl-common.h | 6 ------
1 file changed, 6 deletions(-)
diff --git a/arch/arm/mach-omap2/twl-common.h b/arch/arm/mach-omap2/twl-common.h
index 048f6b2..397722d 100644
--- a/arch/arm/mach-omap2/twl-common.h
+++ b/arch/arm/mach-omap2/twl-common.h
@@ -45,12 +45,6 @@ static inline void omap2_pmic_init(const char *pmic_type,
omap_pmic_init(2, 2600, pmic_type, 7 + OMAP_INTC_START, pmic_data);
}
-static inline void omap3_pmic_init(const char *pmic_type,
- struct twl4030_platform_data *pmic_data)
-{
- omap_pmic_init(1, 2600, pmic_type, 7 + OMAP_INTC_START, pmic_data);
-}
-
void omap_twl4030_audio_init(char *card_name, struct omap_tw4030_pdata *pdata);
#endif /* __OMAP_PMIC_COMMON__ */
--
2.5.5
^ permalink raw reply related
* [PATCH v2 4/5] ARM: OMAP2: kill omap2_pmic_init
From: Nicolae Rosia @ 2016-11-04 14:02 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1478268138-7044-1-git-send-email-Nicolae_Rosia@mentor.com>
Last call of function was removed with commit
bfd46a ("ARM: OMAP: Fix i2c init for twl4030")
Signed-off-by: Nicolae Rosia <Nicolae_Rosia@mentor.com>
---
arch/arm/mach-omap2/twl-common.h | 6 ------
1 file changed, 6 deletions(-)
diff --git a/arch/arm/mach-omap2/twl-common.h b/arch/arm/mach-omap2/twl-common.h
index 397722d..5579bd6 100644
--- a/arch/arm/mach-omap2/twl-common.h
+++ b/arch/arm/mach-omap2/twl-common.h
@@ -39,12 +39,6 @@ void omap_pmic_init(int bus, u32 clkrate, const char *pmic_type, int pmic_irq,
struct twl4030_platform_data *pmic_data);
void omap_pmic_late_init(void);
-static inline void omap2_pmic_init(const char *pmic_type,
- struct twl4030_platform_data *pmic_data)
-{
- omap_pmic_init(2, 2600, pmic_type, 7 + OMAP_INTC_START, pmic_data);
-}
-
void omap_twl4030_audio_init(char *card_name, struct omap_tw4030_pdata *pdata);
#endif /* __OMAP_PMIC_COMMON__ */
--
2.5.5
^ permalink raw reply related
* [PATCH v2 5/5] ARM: OMAP: kill omap_pmic_init
From: Nicolae Rosia @ 2016-11-04 14:02 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1478268138-7044-1-git-send-email-Nicolae_Rosia@mentor.com>
Last user of this function was removed in commit
9b714 ("ARM: OMAP2+: Drop legacy board file for n900") during
legacy board file removal.
Signed-off-by: Nicolae Rosia <Nicolae_Rosia@mentor.com>
---
arch/arm/mach-omap2/twl-common.c | 13 -------------
arch/arm/mach-omap2/twl-common.h | 2 --
2 files changed, 15 deletions(-)
diff --git a/arch/arm/mach-omap2/twl-common.c b/arch/arm/mach-omap2/twl-common.c
index cf3d81b..876772c 100644
--- a/arch/arm/mach-omap2/twl-common.c
+++ b/arch/arm/mach-omap2/twl-common.c
@@ -39,19 +39,6 @@ static struct i2c_board_info __initdata pmic_i2c_board_info = {
.flags = I2C_CLIENT_WAKE,
};
-void __init omap_pmic_init(int bus, u32 clkrate,
- const char *pmic_type, int pmic_irq,
- struct twl4030_platform_data *pmic_data)
-{
- omap_mux_init_signal("sys_nirq", OMAP_PIN_INPUT_PULLUP | OMAP_PIN_OFF_WAKEUPENABLE);
- strlcpy(pmic_i2c_board_info.type, pmic_type,
- sizeof(pmic_i2c_board_info.type));
- pmic_i2c_board_info.irq = pmic_irq;
- pmic_i2c_board_info.platform_data = pmic_data;
-
- omap_register_i2c_bus(bus, clkrate, &pmic_i2c_board_info, 1);
-}
-
void __init omap_pmic_late_init(void)
{
/* Init the OMAP TWL parameters (if PMIC has been registerd) */
diff --git a/arch/arm/mach-omap2/twl-common.h b/arch/arm/mach-omap2/twl-common.h
index 5579bd6..44713bb 100644
--- a/arch/arm/mach-omap2/twl-common.h
+++ b/arch/arm/mach-omap2/twl-common.h
@@ -35,8 +35,6 @@ struct twl6040_platform_data;
struct omap_tw4030_pdata;
struct i2c_board_info;
-void omap_pmic_init(int bus, u32 clkrate, const char *pmic_type, int pmic_irq,
- struct twl4030_platform_data *pmic_data);
void omap_pmic_late_init(void);
void omap_twl4030_audio_init(char *card_name, struct omap_tw4030_pdata *pdata);
--
2.5.5
^ permalink raw reply related
* [RFC v2 8/8] iommu/arm-smmu: implement add_reserved_regions callback
From: Robin Murphy @ 2016-11-04 14:16 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1478258646-3117-9-git-send-email-eric.auger@redhat.com>
On 04/11/16 11:24, Eric Auger wrote:
> The function populates the list of reserved regions with the
> PCI host bridge windows and the MSI IOVA range.
>
> At the moment an arbitray MSI IOVA window is set at 0x8000000
> of size 1MB.
>
> Signed-off-by: Eric Auger <eric.auger@redhat.com>
>
> ---
>
> RFC v1 -> v2: use defines for MSI IOVA base and length
> ---
> drivers/iommu/arm-smmu.c | 66 ++++++++++++++++++++++++++++++++++++++++++++++++
> 1 file changed, 66 insertions(+)
>
> diff --git a/drivers/iommu/arm-smmu.c b/drivers/iommu/arm-smmu.c
> index c841eb7..c07ea41 100644
> --- a/drivers/iommu/arm-smmu.c
> +++ b/drivers/iommu/arm-smmu.c
> @@ -278,6 +278,9 @@ enum arm_smmu_s2cr_privcfg {
>
> #define FSYNR0_WNR (1 << 4)
>
> +#define MSI_IOVA_BASE 0x8000000
> +#define MSI_IOVA_LENGTH 0x100000
> +
> static int force_stage;
> module_param(force_stage, int, S_IRUGO);
> MODULE_PARM_DESC(force_stage,
> @@ -1533,6 +1536,68 @@ static int arm_smmu_of_xlate(struct device *dev, struct of_phandle_args *args)
> return iommu_fwspec_add_ids(dev, &fwid, 1);
> }
>
> +static int add_pci_window_reserved_regions(struct iommu_domain *domain,
> + struct pci_dev *dev)
> +{
> + struct pci_host_bridge *bridge = pci_find_host_bridge(dev->bus);
> + struct iommu_reserved_region *region;
> + struct resource_entry *window;
> + phys_addr_t start;
> + size_t length;
> +
> + resource_list_for_each_entry(window, &bridge->windows) {
> + if (resource_type(window->res) != IORESOURCE_MEM &&
> + resource_type(window->res) != IORESOURCE_IO)
> + continue;
> +
> + start = window->res->start - window->offset;
> + length = window->res->end - window->res->start + 1;
> +
> + iommu_reserved_region_for_each(region, domain) {
> + if (region->start == start && region->length == length)
> + continue;
> + }
> + region = kzalloc(sizeof(*region), GFP_KERNEL);
> + if (!region)
> + return -ENOMEM;
> +
> + region->start = start;
> + region->length = length;
> +
> + list_add_tail(®ion->list, &domain->reserved_regions);
> + }
> + return 0;
> +}
Per the previous observation, let's just convert
iova_reserve_pci_windows() into a public iommu_dma_get_dm_regions()
callback...
> +static int arm_smmu_add_reserved_regions(struct iommu_domain *domain,
> + struct device *device)
> +{
> + struct iommu_reserved_region *region;
> + int ret = 0;
> +
> + /* An arbitrary 1MB region starting at 0x8000000 is reserved for MSIs */
> + if (!domain->iova_cookie) {
> +
> + region = kzalloc(sizeof(*region), GFP_KERNEL);
> + if (!region)
> + return -ENOMEM;
> +
> + region->start = MSI_IOVA_BASE;
> + region->length = MSI_IOVA_LENGTH;
> + list_add_tail(®ion->list, &domain->reserved_regions);
> +
> + ret = iommu_get_dma_msi_region_cookie(domain,
> + region->start, region->length);
> + if (ret)
> + return ret;
...and stick this bit in there as well. Then we only need to add code to
individual IOMMU drivers if there are also regions which bypass
translation at the IOMMU itself (if someone does ever integrate an SMMU
with an upstream/parallel ITS, x86-style, I think we'd need to describe
that with a DT property on the SMMU, so it would have to be the SMMU
driver's responsibility).
Robin.
> + }
> +
> + if (dev_is_pci(device))
> + ret = add_pci_window_reserved_regions(domain,
> + to_pci_dev(device));
> + return ret;
> +}
> +
> static struct iommu_ops arm_smmu_ops = {
> .capable = arm_smmu_capable,
> .domain_alloc = arm_smmu_domain_alloc,
> @@ -1548,6 +1613,7 @@ static int arm_smmu_of_xlate(struct device *dev, struct of_phandle_args *args)
> .domain_get_attr = arm_smmu_domain_get_attr,
> .domain_set_attr = arm_smmu_domain_set_attr,
> .of_xlate = arm_smmu_of_xlate,
> + .add_reserved_regions = arm_smmu_add_reserved_regions,
> .pgsize_bitmap = -1UL, /* Restricted during device attach */
> };
>
>
^ permalink raw reply
* [PATCH v3] iommu: arm-smmu: Set SMTNMB_TLBEN in ACR to enable caching of bypass entries
From: Robin Murphy @ 2016-11-04 14:19 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1478253323-9231-1-git-send-email-nipun.gupta@nxp.com>
On 04/11/16 09:55, Nipun Gupta wrote:
> The SMTNMB_TLBEN in the Auxiliary Configuration Register (ACR) provides an
> option to enable the updation of TLB in case of bypass transactions due to
> no stream match in the stream match table. This reduces the latencies of
> the subsequent transactions with the same stream-id which bypasses the SMMU.
> This provides a significant performance benefit for certain networking
> workloads.
>
> With this change substantial performance improvement of ~9% is observed with
> DPDK l3fwd application (http://dpdk.org/doc/guides/sample_app_ug/l3_forward.html)
> on NXP's LS2088a platform.
Reviewed-by: Robin Murphy <robin.murphy@arm.com>
> Signed-off-by: Nipun Gupta <nipun.gupta@nxp.com>
> ---
> Changes for v2:
> - Incorporated Robin's comments on v1 related to
> Setting SMTNMB_TLBEN in ACR only for MMU-500 as ACR is implementation dependent
> Code comments and Naming convention
> Changes for v3:
> - Added correct patch version
>
> drivers/iommu/arm-smmu.c | 25 ++++++++++++++++---------
> 1 file changed, 16 insertions(+), 9 deletions(-)
>
> diff --git a/drivers/iommu/arm-smmu.c b/drivers/iommu/arm-smmu.c
> index ce2a9d4..05901be 100644
> --- a/drivers/iommu/arm-smmu.c
> +++ b/drivers/iommu/arm-smmu.c
> @@ -247,6 +247,7 @@ enum arm_smmu_s2cr_privcfg {
> #define ARM_MMU500_ACTLR_CPRE (1 << 1)
>
> #define ARM_MMU500_ACR_CACHE_LOCK (1 << 26)
> +#define ARM_MMU500_ACR_SMTNMB_TLBEN (1 << 8)
>
> #define CB_PAR_F (1 << 0)
>
> @@ -1569,16 +1570,22 @@ static void arm_smmu_device_reset(struct arm_smmu_device *smmu)
> for (i = 0; i < smmu->num_mapping_groups; ++i)
> arm_smmu_write_sme(smmu, i);
>
> - /*
> - * Before clearing ARM_MMU500_ACTLR_CPRE, need to
> - * clear CACHE_LOCK bit of ACR first. And, CACHE_LOCK
> - * bit is only present in MMU-500r2 onwards.
> - */
> - reg = readl_relaxed(gr0_base + ARM_SMMU_GR0_ID7);
> - major = (reg >> ID7_MAJOR_SHIFT) & ID7_MAJOR_MASK;
> - if ((smmu->model == ARM_MMU500) && (major >= 2)) {
> + if (smmu->model == ARM_MMU500) {
> + /*
> + * Before clearing ARM_MMU500_ACTLR_CPRE, need to
> + * clear CACHE_LOCK bit of ACR first. And, CACHE_LOCK
> + * bit is only present in MMU-500r2 onwards.
> + */
> + reg = readl_relaxed(gr0_base + ARM_SMMU_GR0_ID7);
> + major = (reg >> ID7_MAJOR_SHIFT) & ID7_MAJOR_MASK;
> reg = readl_relaxed(gr0_base + ARM_SMMU_GR0_sACR);
> - reg &= ~ARM_MMU500_ACR_CACHE_LOCK;
> + if (major >= 2)
> + reg &= ~ARM_MMU500_ACR_CACHE_LOCK;
> + /*
> + * Allow unmatched Stream IDs to allocate bypass
> + * TLB entries for reduced latency.
> + */
> + reg |= ARM_MMU500_ACR_SMTNMB_TLBEN;
> writel_relaxed(reg, gr0_base + ARM_SMMU_GR0_sACR);
> }
>
>
^ permalink raw reply
* [GIT PULL] STM32 DT changes for v4.10 #1
From: Alexandre Torgue @ 2016-11-04 14:31 UTC (permalink / raw)
To: linux-arm-kernel
Hi Olof, Arnd and Kevin,
Please consider this first round of STM32 DT updates for v4.10:
The following changes since commit 1001354ca34179f3db924eb66672442a173147dc:
Linux 4.9-rc1 (2016-10-15 12:17:50 -0700)
are available in the git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/atorgue/stm32.git
tags/stm32-dt-for-v4.10-1
for you to fetch changes up to f6dbbff4f0af1a5c0d6eaf414572b5eff7a73a8b:
ARM: dts: stm32f429: add LSI and LSE clocks (2016-11-04 15:08:08 +0100)
----------------------------------------------------------------
STM32 DT updates for v4.10, round 1.
Highlights:
----------
- Add LSI and LSE clocks support for STM32F429
- Add GPIO IRQ support for STM32F429
- Declare push button as GPIO keys on STM32F429 boards
- Add DMA supports on USART1 & USART3 on STM32F429
- Add Ethernet fixes
----------------------------------------------------------------
Alexandre TORGUE (5):
ARM: DT: STM32: add dma for usart3 on F429
ARM: DT: stm32: move dma translation to board files
ARM: dts: stm32f429: Align Ethernet node with new bindings properties
ARM: dts: stm32f429: Fix Ethernet node on Eval Board
ARM: dts: stm32f429: remove Ethernet wake on Lan support
Gabriel Fernandez (1):
ARM: dts: stm32f429: add LSI and LSE clocks
Gerald Baeza (1):
ARM: DT: STM32: add dma for usart1 on F429
Maxime Coquelin (2):
ARM: dts: Add GPIO irq support to STM32F429
ARM: dts: Declare push button as GPIO key on stm32f429 boards
arch/arm/boot/dts/stm32429i-eval.dts | 29 ++++++++++++++++++++++---
arch/arm/boot/dts/stm32f429-disco.dts | 13 ++++++++++++
arch/arm/boot/dts/stm32f429.dtsi | 40
+++++++++++++++++++++++++++--------
arch/arm/boot/dts/stm32f469-disco.dts | 4 ++++
4 files changed, 74 insertions(+), 12 deletions(-)
^ permalink raw reply
* [PATCH 4/9] pinctrl: meson: allow gpio to request irq
From: Linus Walleij @ 2016-11-04 14:40 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <7hk2cvrtxt.fsf@baylibre.com>
On Wed, Oct 26, 2016 at 5:50 PM, Kevin Hilman <khilman@baylibre.com> wrote:
>> Yes they are all wrong. They should all be using irq_find_mapping().
>
> So, dumb question from someone trying (but having a hard time) to follow
> and understand the rationale...
>
> If it's wrong enough to completely reject, why are changes still being
> merged that are doing it so wrong? (e.g. like this one[1], just merged
> for v4.9)
It's a bug.
It's that problem that Wolfram brought up in a recent lecture
about maintainer scaling: if noone but the subsystem maintainer
reviews the code, things like this will happen.
I need more review...
> [1] 0eb9f683336d pinctrl: Add IRQ support to STM32 gpios
> https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/drivers/pinctrl/stm32/pinctrl-stm32.c?id=0eb9f683336d7eb99a3b75987620417c574ffb57
Alexandre, Maxime: can you please make a patch for the STM32
driver that remove the semantic dependence for .to_irq() to be called
before an interrupt can be used? It should be possible to use
the irqs directly from the irqchip.
Yours,
Linus Walleij
^ permalink raw reply
* [PATCH] ARM: sun8i: sina33: Enable USB gadget
From: Maxime Ripard @ 2016-11-04 14:44 UTC (permalink / raw)
To: linux-arm-kernel
The micro-USB on the SinA33 has a somewhat interesting design in the sense
that it has a micro USB connector, but the VBUS is (supposed to be)
controlled through an (unpopulated) jumper.
Obviously, that doesn't work really well, and only the peripheral mode
really works. Still enable it.
Signed-off-by: Maxime Ripard <maxime.ripard@free-electrons.com>
---
arch/arm/boot/dts/sun8i-a33-sinlinx-sina33.dts | 5 +++++
1 file changed, 5 insertions(+)
diff --git a/arch/arm/boot/dts/sun8i-a33-sinlinx-sina33.dts b/arch/arm/boot/dts/sun8i-a33-sinlinx-sina33.dts
index fa8024072025..1c0d98cbd334 100644
--- a/arch/arm/boot/dts/sun8i-a33-sinlinx-sina33.dts
+++ b/arch/arm/boot/dts/sun8i-a33-sinlinx-sina33.dts
@@ -247,6 +247,11 @@
status = "okay";
};
+&usb_otg {
+ dr_mode = "peripheral";
+ status = "okay";
+};
+
&usbphy {
status = "okay";
usb1_vbus-supply = <®_vcc5v0>; /* USB1 VBUS is always on */
--
2.10.1
^ permalink raw reply related
* [PATCH] simplefb: Separate clk / regulator get and enable steps
From: Hans de Goede @ 2016-11-04 14:45 UTC (permalink / raw)
To: linux-arm-kernel
Currently when a simplefb needs both clocks and regulators and one
of the regulators returns -EPROBE_DEFER when we try to get it, we end
up disabling the clocks. This causes the screen to go blank; and in some
cases my cause hardware state to be lost resulting in the framebuffer not
working at all.
This commit splits the get and enable steps and only enables
clocks and regulators after successfully getting all of them,
fixing the disabling of the clocks which were left enabled by
the firmware setting up the simplefb.
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
---
drivers/video/fbdev/simplefb.c | 56 ++++++++++++++++++++++++++++++------------
1 file changed, 40 insertions(+), 16 deletions(-)
diff --git a/drivers/video/fbdev/simplefb.c b/drivers/video/fbdev/simplefb.c
index 61f799a..a3c44ec 100644
--- a/drivers/video/fbdev/simplefb.c
+++ b/drivers/video/fbdev/simplefb.c
@@ -180,10 +180,12 @@ static int simplefb_parse_pd(struct platform_device *pdev,
struct simplefb_par {
u32 palette[PSEUDO_PALETTE_SIZE];
#if defined CONFIG_OF && defined CONFIG_COMMON_CLK
+ bool clks_enabled;
unsigned int clk_count;
struct clk **clks;
#endif
#if defined CONFIG_OF && defined CONFIG_REGULATOR
+ bool regulators_enabled;
u32 regulator_count;
struct regulator **regulators;
#endif
@@ -208,12 +210,12 @@ struct simplefb_par {
* the fb probe will not help us much either. So just complain and carry on,
* and hope that the user actually gets a working fb at the end of things.
*/
-static int simplefb_clocks_init(struct simplefb_par *par,
- struct platform_device *pdev)
+static int simplefb_clocks_get(struct simplefb_par *par,
+ struct platform_device *pdev)
{
struct device_node *np = pdev->dev.of_node;
struct clk *clock;
- int i, ret;
+ int i;
if (dev_get_platdata(&pdev->dev) || !np)
return 0;
@@ -244,6 +246,14 @@ static int simplefb_clocks_init(struct simplefb_par *par,
par->clks[i] = clock;
}
+ return 0;
+}
+
+static void simplefb_clocks_enable(struct simplefb_par *par,
+ struct platform_device *pdev)
+{
+ int i, ret;
+
for (i = 0; i < par->clk_count; i++) {
if (par->clks[i]) {
ret = clk_prepare_enable(par->clks[i]);
@@ -256,8 +266,7 @@ static int simplefb_clocks_init(struct simplefb_par *par,
}
}
}
-
- return 0;
+ par->clks_enabled = true;
}
static void simplefb_clocks_destroy(struct simplefb_par *par)
@@ -269,7 +278,8 @@ static void simplefb_clocks_destroy(struct simplefb_par *par)
for (i = 0; i < par->clk_count; i++) {
if (par->clks[i]) {
- clk_disable_unprepare(par->clks[i]);
+ if (par->clks_enabled)
+ clk_disable_unprepare(par->clks[i]);
clk_put(par->clks[i]);
}
}
@@ -277,8 +287,10 @@ static void simplefb_clocks_destroy(struct simplefb_par *par)
kfree(par->clks);
}
#else
-static int simplefb_clocks_init(struct simplefb_par *par,
+static int simplefb_clocks_get(struct simplefb_par *par,
struct platform_device *pdev) { return 0; }
+static void simplefb_clocks_enable(struct simplefb_par *par,
+ struct platform_device *pdev) { }
static void simplefb_clocks_destroy(struct simplefb_par *par) { }
#endif
@@ -305,14 +317,14 @@ static void simplefb_clocks_destroy(struct simplefb_par *par) { }
* the fb probe will not help us much either. So just complain and carry on,
* and hope that the user actually gets a working fb at the end of things.
*/
-static int simplefb_regulators_init(struct simplefb_par *par,
- struct platform_device *pdev)
+static int simplefb_regulators_get(struct simplefb_par *par,
+ struct platform_device *pdev)
{
struct device_node *np = pdev->dev.of_node;
struct property *prop;
struct regulator *regulator;
const char *p;
- int count = 0, i = 0, ret;
+ int count = 0, i = 0;
if (dev_get_platdata(&pdev->dev) || !np)
return 0;
@@ -354,6 +366,14 @@ static int simplefb_regulators_init(struct simplefb_par *par,
}
par->regulator_count = i;
+ return 0;
+}
+
+static void simplefb_regulators_enable(struct simplefb_par *par,
+ struct platform_device *pdev)
+{
+ int i, ret;
+
/* Enable all the regulators */
for (i = 0; i < par->regulator_count; i++) {
ret = regulator_enable(par->regulators[i]);
@@ -365,15 +385,14 @@ static int simplefb_regulators_init(struct simplefb_par *par,
par->regulators[i] = NULL;
}
}
-
- return 0;
+ par->regulators_enabled = true;
}
static void simplefb_regulators_destroy(struct simplefb_par *par)
{
int i;
- if (!par->regulators)
+ if (!par->regulators || !par->regulators_enabled)
return;
for (i = 0; i < par->regulator_count; i++)
@@ -381,8 +400,10 @@ static void simplefb_regulators_destroy(struct simplefb_par *par)
regulator_disable(par->regulators[i]);
}
#else
-static int simplefb_regulators_init(struct simplefb_par *par,
+static int simplefb_regulators_get(struct simplefb_par *par,
struct platform_device *pdev) { return 0; }
+static void simplefb_regulators_enable(struct simplefb_par *par,
+ struct platform_device *pdev) { }
static void simplefb_regulators_destroy(struct simplefb_par *par) { }
#endif
@@ -453,14 +474,17 @@ static int simplefb_probe(struct platform_device *pdev)
}
info->pseudo_palette = par->palette;
- ret = simplefb_clocks_init(par, pdev);
+ ret = simplefb_clocks_get(par, pdev);
if (ret < 0)
goto error_unmap;
- ret = simplefb_regulators_init(par, pdev);
+ ret = simplefb_regulators_get(par, pdev);
if (ret < 0)
goto error_clocks;
+ simplefb_clocks_enable(par, pdev);
+ simplefb_regulators_enable(par, pdev);
+
dev_info(&pdev->dev, "framebuffer at 0x%lx, 0x%x bytes, mapped to 0x%p\n",
info->fix.smem_start, info->fix.smem_len,
info->screen_base);
--
2.9.3
^ permalink raw reply related
* [PATCHv6] support for AD5820 camera auto-focus coil
From: Tony Lindgren @ 2016-11-04 14:49 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161104074533.GB3679@amd>
* Pavel Machek <pavel@ucw.cz> [161104 00:45]:
> Hi!
>
> > > > I have to admit I mostly use an N9.
> > >
> > > Well, if you compare that to development on PC, I prefer PC.
> > >
> > > Even arm development boards are usually easier, as they don't need too
> > > complex userspace, and do have working serial ports.
> > >
> > > But I do have a serial adapter for N900 now (thanks, sre), so my main
> > > problem now is that N900 takes a lot of time to boot into usable
> > > state.
> >
> > Yeah... I just upgraded my Debian installation (armel over NFS) a few major
> > numbers and I find it a lot slower than it used to do. I presume that's
> > mostly because of systemd...
>
> I'm not sure if systemd is to blame. (I'm booting into full GUI...)
>
> And yes, I noticed the slowdown in Debian 7 -> 8 transition, so I'm
> basically staying at Debian 7 as far as I can.
Maybe it's the armel vs armhf causing the slowdown?
Regards,
Tony
^ permalink raw reply
* [PATCH v2 2/2] power: bq27xxx_battery: add poll interval property query
From: Tony Lindgren @ 2016-11-04 14:58 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161104070955.GA3679@amd>
* Pavel Machek <pavel@ucw.cz> [161104 00:10]:
> On Thu 2016-11-03 22:00:56, Matt Ranostay wrote:
> Do you actually have hardware with more than one bq27xxx?
I can at least see the twl4030 battery/charger features
being used together with some bq device to monitor the
battery state. Not sure if that counts as multiple
instances here though :)
Regards,
Tony
^ permalink raw reply
* [PATCH 4/9] pinctrl: meson: allow gpio to request irq
From: Linus Walleij @ 2016-11-04 15:03 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1477564941.2482.240.camel@baylibre.com>
On Thu, Oct 27, 2016 at 12:42 PM, Jerome Brunet <jbrunet@baylibre.com> wrote:
> Ressource issue : When you create an irq mapping, in case of hierarchic
> domain, it calls the "alloc" function of the domain, which will
> eventually call the "alloc" function of the parent domain ... until you
> reach the "root" domain (here the gic).
(...)
> We are looking to create mapping "on-demand" to make the best use of
> the little number of interrupts we have. To catch request of drivers,
> like gpio-keys, which use gpio_to_irq, it looks the only viable place
> is the to_irq callback (at the moment).
>
> Drivers using gpio_to_irq in their probe function expect that this will
> give them the corresponding virq, so create the mapping if need be.
OK what I need to know is the following:
If this was not a gpio chip, just some random hierarchical irqchip
or mux from drivers/irqchip, where would you make the translation?
The answer to that question applies equally to any GPIO controller
that also provides an irqchip. .to_irq() is not the place to do the
translation.
I looked around and for example irq-s3c24xx.c seems to do this
in the irqdomain xlate() callback, which should only be called
when the interrupt is resolved for a consumer.
If that is the code that you partitioned over to drivers/irqchip,
then maybe this is a sign that this code should not be there
at all, but instead inside this gpiochip driver, or atleast accessible
by it so that your gpiochip driver has direct access to the
irqdomain it is using.
> However, I now get why you don't want that, it seems we have 2 types of
> platforms in the kernel right now:
>
> 1. The one creating the mapping in the to_irq callback. It might be
> because they just copy/paste from another driver doing it, or they may
> have a good reason for it (like I think we do)
>
> 2. the one which call gpio_to_irq in interrupt handlers. Honestly I did
> not know that one could that, but they are in the mainline too, and
> probably have a good reason for doing it.
They are probably all bad or legacy. None of this works with a
irqchip from DT like this:
foo: gpio at 0 {
#gpio-cells = <2>;
gpio-controller;
interrupt-cells = <2>;
interrupt-controller;
}
bar: bar at 1 {
interrupt-parent = <&foo>;
interrupt = <4>;
};
Here notice that bar is NOT doing gpios = <&foo 4>;
which is what you would do to get a GPIO and then call
.to_irq() on it. It just uses it as an interrupt controller.
This MUST work, or you cannot put interrupt-controller;
as a keyword on the gpiochip.
> irq_find_mapping looks safe in interrupt handler, I does not seem to
> sleep (please correct me if I'm wrong).
> irq_create_mapping definitely isn't, because of the irq_domain mutex.
Yep.
> We probably got into this situation because it wasn't clear enough
> whether to_irq was fast or slow (at least it took me a few mails to
> understand this ...)
I don't know either. It's just supposed to be a quick helper
to find the corresponding interrupt for a GPIO, it is not supposed
to have semantic side-effects.
> The two platform groups are most likely exclusive so nobody is sleeping
> in irq, everybody is happy. As a maintainer, I understand that you
> can't allow a dangerous situation like this to continue.
It's a mess allright. I need everyone's help to fix the mess.
> To fix the situation we could add a few things in the gpio subsys:
> - Make it clear that to_irq is fast (like you just did)
Sure patches accepted.
> - add a new callback (to_irq_slow ? provide_irq ? something else) which
> would be allowed to sleep and create mappings.
> - in gpio_to_irq function keeps calling to_irq like it does but also
> call to_irq_slow only if we are not in an interrupt context and a
> mapping could not be found. We could maybe use "in_interrupt()" for
> this ?
None of them should be allowed to create mappings because of the
explanation above: gpiochips and irqchips need to be
orthogonal.
> This way, we could keep the existing drivers working as they are (even
> if they are wrong) and slowly fix things up.
It doesn't seem to help with anything.
Instead go back to what I described above: if it was just
two irqchips: forget the fact that one of them is a GPIO chip
for a while, just two irqchips.
How does one irqchip map to another one?
That is what needs to happen, solely using the irqchip
infrastructure, NOT using .to_irq().
> Sorry, it was kind of long explanation but I hope things are more clear
> now.
I think I understand... famous last words.
>> I just misunderstand it as the global GPIO number, that is
>> not OK.
>
> Ok. Just to be clear, you are ok with the function
> "meson_gpio_to_hwirq" which just does this translation, right ?
That seems all right, the problem is relying on gpio_to_irq()
being called for the interrupts to work.
Yours,
Linus Walleij
^ permalink raw reply
* [PATCH 10/13] ARM: dts: exynos: replace to "max-frequecy" instead of "clock-freq-min-max"
From: Krzysztof Kozlowski @ 2016-11-04 15:04 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <4066252.a1W9ejEKHX@phil>
On Fri, Nov 04, 2016 at 12:19:49PM +0100, Heiko Stuebner wrote:
> Hi Jaehoon,
>
> Am Freitag, 4. November 2016, 19:21:30 CET schrieb Jaehoon Chung:
> > On 11/04/2016 03:41 AM, Krzysztof Kozlowski wrote:
> > > On Thu, Nov 03, 2016 at 03:21:32PM +0900, Jaehoon Chung wrote:
> > >> In drivers/mmc/core/host.c, there is "max-frequency" property.
> > >> It should be same behavior. So Use the "max-frequency" instead of
> > >> "clock-freq-min-max".
> > >>
> > >> Signed-off-by: Jaehoon Chung <jh80.chung@samsung.com>
> > >> ---
> > >>
> > >> arch/arm/boot/dts/exynos3250-artik5-eval.dts | 2 +-
> > >> arch/arm/boot/dts/exynos3250-artik5.dtsi | 2 +-
> > >> arch/arm/boot/dts/exynos3250-monk.dts | 2 +-
> > >> arch/arm/boot/dts/exynos3250-rinato.dts | 2 +-
> > >> 4 files changed, 4 insertions(+), 4 deletions(-)
> > >
> > > This looks totally independent to rest of patches so it can be applied
> > > separately without any functional impact (except lack of minimum
> > > frequency). Is that correct?
> >
> > You're right. I will split the patches. And will resend.
> > Thanks!
>
> I think what Krzysztof was asking was just if he can simply pick up this patch
> alone, as it does not require any of the previous changes.
>
> Same is true for the Rockchip patches I guess, so we could just take them
> individually into samsung/rockchip dts branches.
Yes, I wanted to get exactly this information. I couldn't find it in
cover letter.
Best regards,
Krzysztof
^ permalink raw reply
* [PATCH V3 0/8] IOMMU probe deferral support
From: Sricharan @ 2016-11-04 15:16 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <421e2b14-0231-d376-02a0-097423120b3d@arm.com>
Hi Robin,
>>>Yikes, on second look, that definitely shouldn't be happening.
>>>Everything below is probably the resulting fallout.
>>
>>[ 40.206703] vfio-pci 0000:08:00.0: Failed to setup iommu ops
>>
>>I think the above print which says "failed to setup iommu_ops"
>>because the call ops->add_device failed in of_pci_iommu_configure
>>is the reason for the failure, in my case i simply do not get this even with
>>your scripts. ops->add_device succeeds in the rebind as well. So still
>>checking what could be happening in your case.
>
>I was looking at your code base from [1].The ops->add_device
>callback from of_pci_iommu_configure on the rebind is the
>one which is causing the failure. But not able to spot out
>from code which point is causing the failure. It would be very helpful
>if i can know which is the return value from the add_device callback
>or point inside add_device callback which fails in your setup.
>
>
>[1] git://linux-arm.org/linux-rm iommu/misc
With little more try, i saw an issue where i had an failure
similar to what you reported. The issue happens when multiple
devices fall in to same group due to matching sids. I ended up
doing a fix like below and it would be nice to verify if it is the same
that we are seeing in your setup and if the fix makes a difference ?
From: Sricharan R <sricharan@codeaurora.org>
Date: Fri, 4 Nov 2016 20:28:49 +0530
Subject: [PATCH] iommu/arm-smmu: Fix group's reference counting
iommu_group_get_for_dev which gets called in the add_device
callback, increases the reference count of the iommu_group,
so we do an iommu_group_put after that. iommu_group_get_for_dev
inturn calls device_group callback and in the case of arm-smmu
we call generic_device_group/pci_device_group which takes
care of increasing the group's reference. But when we return
an already existing group(when multiple devices have same group)
the reference is not incremented, resulting in issues when the
remove_device callback for the devices is invoked.
Fixing the same here.
Signed-off-by: Sricharan R <sricharan@codeaurora.org>
---
drivers/iommu/arm-smmu.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/drivers/iommu/arm-smmu.c b/drivers/iommu/arm-smmu.c
index 71ce4b6..a1d0b3c 100644
--- a/drivers/iommu/arm-smmu.c
+++ b/drivers/iommu/arm-smmu.c
@@ -1516,8 +1516,10 @@ static struct iommu_group *arm_smmu_device_group(struct device *dev)
group = smmu->s2crs[idx].group;
}
- if (group)
+ if (group) {
+ iommu_group_get_by_id(iommu_group_id(group));
return group;
+ }
if (dev_is_pci(dev))
group = pci_device_group(dev);
--
1.8.2.1
^ permalink raw reply related
* [PATCH 1/2] arm64: hugetlb: remove the wrong pmd check in find_num_contig()
From: Catalin Marinas @ 2016-11-04 15:48 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161104025216.GA19810@sha-win-210.asiapac.arm.com>
On Fri, Nov 04, 2016 at 10:52:17AM +0800, Huang Shijie wrote:
> On Thu, Nov 03, 2016 at 06:16:16PM -0600, Catalin Marinas wrote:
> > On Thu, Nov 03, 2016 at 10:27:38AM +0800, Huang Shijie wrote:
> > > diff --git a/arch/arm64/mm/hugetlbpage.c b/arch/arm64/mm/hugetlbpage.c
> > > index 2e49bd2..4811ef1 100644
> > > --- a/arch/arm64/mm/hugetlbpage.c
> > > +++ b/arch/arm64/mm/hugetlbpage.c
> > > @@ -61,10 +61,6 @@ static int find_num_contig(struct mm_struct *mm, unsigned long addr,
> > > return 1;
> > > }
> > > pmd = pmd_offset(pud, addr);
> > > - if (!pmd_present(*pmd)) {
> > > - VM_BUG_ON(!pmd_present(*pmd));
> > > - return 1;
> > > - }
> > > if ((pte_t *)pmd == ptep) {
> > > *pgsize = PMD_SIZE;
> > > return CONT_PMDS;
> >
> > BTW, for the !pud_present() and !pgd_present() cases, shouldn't
> > find_num_contig() actually return 0? These are more likely real bugs, so
> > no point in setting the huge pte.
>
> The kernel will not call the find_num_contig() if the PGD/PUD are empty.
> Please see the code in the hugetlb_fault().
>
> ------------------------------------------------------
> ptep = huge_pte_offset(mm, address);
> if (ptep) {
> ...............................
> } else {
> ptep = huge_pte_alloc(mm, address, huge_page_size(h));
> if (!ptep)
> return VM_FAULT_OOM;
> }
> ------------------------------------------------------
Exactly. So what is the reason for returning 1 if !pgd_present()? Would
removing the checks entirely or adding BUG() be a better option?
--
Catalin
^ permalink raw reply
* [RFC PATCH v2 8/8] arm64: Wire up and expose the new compat vDSO
From: Catalin Marinas @ 2016-11-04 15:50 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161027163058.12156-9-kevin.brodsky@arm.com>
On Thu, Oct 27, 2016 at 05:30:58PM +0100, Kevin Brodsky wrote:
> * The vDSO page replaces the vector page. The vDSO provides its own
> sigreturn trampolines, replacing those in the vector page, but the
> kuser helpers are gone. As a result enabling the compat vDSO will
> break userspace programs relying on the kuser helpers.
I think vDSO and vectors page should not exclude each other. If you want
to disable the vectors page, let's make it an independent config option
like the KUSER_HELPERS in arch/arm64/mm/Kconfig. But I would very much
like to be able to have both the vDSO and the vectors page at the same
time.
--
Catalin
^ permalink raw reply
* [PATCH net-next 0/2] ARM64: Add Internal PHY support for Meson GXL
From: Neil Armstrong @ 2016-11-04 15:51 UTC (permalink / raw)
To: linux-arm-kernel
The Amlogic Meson GXL SoCs have an internal RMII PHY that is muxed with the
external RGMII pins.
In order to support switching between the two PHYs links, extended registers
size for mdio-mux-mmioreg must be added.
The DT related patches submitted as RFC in [3] will be sent in a separate
patchset due to multiple patchsets and DTSI migrations.
Changes since v2 RFC patchset at : [3]
- Change phy Kconfig/Makefile alphabetic order
- GXL dtsi cleanup
Changes since original RFC patchset at : [2]
- Remove meson8b experimental phy switching
- Switch to mdio-mux-mmioreg with extennded size support
- Add internal phy support for S905x and p231
- Add external PHY support for p230
[1] http://lkml.kernel.org/r/1477932286-27482-1-git-send-email-narmstrong at baylibre.com
[2] http://lkml.kernel.org/r/1477060838-14164-1-git-send-email-narmstrong at baylibre.com
[3] http://lkml.kernel.org/r/1477932987-27871-1-git-send-email-narmstrong at baylibre.com
Neil Armstrong (2):
net: mdio-mux-mmioreg: Add support for 16bit and 32bit register sizes
net: phy: Add Meson GXL Internal PHY driver
.../devicetree/bindings/net/mdio-mux-mmioreg.txt | 4 +-
drivers/net/phy/Kconfig | 5 ++
drivers/net/phy/Makefile | 1 +
drivers/net/phy/mdio-mux-mmioreg.c | 60 ++++++++++++----
drivers/net/phy/meson-gxl.c | 81 ++++++++++++++++++++++
5 files changed, 136 insertions(+), 15 deletions(-)
create mode 100644 drivers/net/phy/meson-gxl.c
--
1.9.1
^ permalink raw reply
* [PATCH net-next 1/2] net: mdio-mux-mmioreg: Add support for 16bit and 32bit register sizes
From: Neil Armstrong @ 2016-11-04 15:51 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1478274683-1503-1-git-send-email-narmstrong@baylibre.com>
In order to support PHY switching on Amlogic GXL SoCs, add support for
16bit and 32bit registers sizes.
Reviewed-by: Andrew Lunn <andrew@lunn.ch>
Signed-off-by: Neil Armstrong <narmstrong@baylibre.com>
---
.../devicetree/bindings/net/mdio-mux-mmioreg.txt | 4 +-
drivers/net/phy/mdio-mux-mmioreg.c | 60 +++++++++++++++++-----
2 files changed, 49 insertions(+), 15 deletions(-)
diff --git a/Documentation/devicetree/bindings/net/mdio-mux-mmioreg.txt b/Documentation/devicetree/bindings/net/mdio-mux-mmioreg.txt
index 8516929..065e8bd 100644
--- a/Documentation/devicetree/bindings/net/mdio-mux-mmioreg.txt
+++ b/Documentation/devicetree/bindings/net/mdio-mux-mmioreg.txt
@@ -3,7 +3,7 @@ Properties for an MDIO bus multiplexer controlled by a memory-mapped device
This is a special case of a MDIO bus multiplexer. A memory-mapped device,
like an FPGA, is used to control which child bus is connected. The mdio-mux
node must be a child of the memory-mapped device. The driver currently only
-supports devices with eight-bit registers.
+supports devices with 8, 16 or 32-bit registers.
Required properties in addition to the generic multiplexer properties:
@@ -11,7 +11,7 @@ Required properties in addition to the generic multiplexer properties:
- reg : integer, contains the offset of the register that controls the bus
multiplexer. The size field in the 'reg' property is the size of
- register, and must therefore be 1.
+ register, and must therefore be 1, 2, or 4.
- mux-mask : integer, contains an eight-bit mask that specifies which
bits in the register control the actual bus multiplexer. The
diff --git a/drivers/net/phy/mdio-mux-mmioreg.c b/drivers/net/phy/mdio-mux-mmioreg.c
index d0bed52..6a33646 100644
--- a/drivers/net/phy/mdio-mux-mmioreg.c
+++ b/drivers/net/phy/mdio-mux-mmioreg.c
@@ -21,7 +21,8 @@
struct mdio_mux_mmioreg_state {
void *mux_handle;
phys_addr_t phys;
- uint8_t mask;
+ unsigned int iosize;
+ unsigned int mask;
};
/*
@@ -47,17 +48,47 @@ static int mdio_mux_mmioreg_switch_fn(int current_child, int desired_child,
struct mdio_mux_mmioreg_state *s = data;
if (current_child ^ desired_child) {
- void __iomem *p = ioremap(s->phys, 1);
- uint8_t x, y;
-
+ void __iomem *p = ioremap(s->phys, s->iosize);
if (!p)
return -ENOMEM;
- x = ioread8(p);
- y = (x & ~s->mask) | desired_child;
- if (x != y) {
- iowrite8((x & ~s->mask) | desired_child, p);
- pr_debug("%s: %02x -> %02x\n", __func__, x, y);
+ switch (s->iosize) {
+ case sizeof(uint8_t): {
+ uint8_t x, y;
+
+ x = ioread8(p);
+ y = (x & ~s->mask) | desired_child;
+ if (x != y) {
+ iowrite8((x & ~s->mask) | desired_child, p);
+ pr_debug("%s: %02x -> %02x\n", __func__, x, y);
+ }
+
+ break;
+ }
+ case sizeof(uint16_t): {
+ uint16_t x, y;
+
+ x = ioread16(p);
+ y = (x & ~s->mask) | desired_child;
+ if (x != y) {
+ iowrite16((x & ~s->mask) | desired_child, p);
+ pr_debug("%s: %04x -> %04x\n", __func__, x, y);
+ }
+
+ break;
+ }
+ case sizeof(uint32_t): {
+ uint32_t x, y;
+
+ x = ioread32(p);
+ y = (x & ~s->mask) | desired_child;
+ if (x != y) {
+ iowrite32((x & ~s->mask) | desired_child, p);
+ pr_debug("%s: %08x -> %08x\n", __func__, x, y);
+ }
+
+ break;
+ }
}
iounmap(p);
@@ -88,8 +119,11 @@ static int mdio_mux_mmioreg_probe(struct platform_device *pdev)
}
s->phys = res.start;
- if (resource_size(&res) != sizeof(uint8_t)) {
- dev_err(&pdev->dev, "only 8-bit registers are supported\n");
+ s->iosize = resource_size(&res);
+ if (s->iosize != sizeof(uint8_t) &&
+ s->iosize != sizeof(uint16_t) &&
+ s->iosize != sizeof(uint32_t)) {
+ dev_err(&pdev->dev, "only 8/16/32-bit registers are supported\n");
return -EINVAL;
}
@@ -98,8 +132,8 @@ static int mdio_mux_mmioreg_probe(struct platform_device *pdev)
dev_err(&pdev->dev, "missing or invalid mux-mask property\n");
return -ENODEV;
}
- if (be32_to_cpup(iprop) > 255) {
- dev_err(&pdev->dev, "only 8-bit registers are supported\n");
+ if (be32_to_cpup(iprop) >= BIT(s->iosize * 8)) {
+ dev_err(&pdev->dev, "only 8/16/32-bit registers are supported\n");
return -EINVAL;
}
s->mask = be32_to_cpup(iprop);
--
1.9.1
^ permalink raw reply related
* [PATCH net-next 2/2] net: phy: Add Meson GXL Internal PHY driver
From: Neil Armstrong @ 2016-11-04 15:51 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1478274683-1503-1-git-send-email-narmstrong@baylibre.com>
Add driver for the Internal RMII PHY found in the Amlogic Meson GXL SoCs.
This PHY seems to only implement some standard registers and need some
workarounds to provide autoneg values from vendor registers.
Some magic values are currently used to configure the PHY, and this a
temporary setup until clarification about these registers names and
registers fields are provided by Amlogic.
Signed-off-by: Neil Armstrong <narmstrong@baylibre.com>
---
drivers/net/phy/Kconfig | 5 +++
drivers/net/phy/Makefile | 1 +
drivers/net/phy/meson-gxl.c | 81 +++++++++++++++++++++++++++++++++++++++++++++
3 files changed, 87 insertions(+)
create mode 100644 drivers/net/phy/meson-gxl.c
diff --git a/drivers/net/phy/Kconfig b/drivers/net/phy/Kconfig
index 2651c8d..b48943a 100644
--- a/drivers/net/phy/Kconfig
+++ b/drivers/net/phy/Kconfig
@@ -264,6 +264,11 @@ config MARVELL_PHY
---help---
Currently has a driver for the 88E1011S
+config MESON_GXL_PHY
+ tristate "Amlogic Meson GXL Internal PHY"
+ ---help---
+ Currently has a driver for the Amlogic Meson GXL Internal PHY
+
config MICREL_PHY
tristate "Micrel PHYs"
---help---
diff --git a/drivers/net/phy/Makefile b/drivers/net/phy/Makefile
index e58667d..3cd5af7 100644
--- a/drivers/net/phy/Makefile
+++ b/drivers/net/phy/Makefile
@@ -41,6 +41,7 @@ obj-$(CONFIG_INTEL_XWAY_PHY) += intel-xway.o
obj-$(CONFIG_LSI_ET1011C_PHY) += et1011c.o
obj-$(CONFIG_LXT_PHY) += lxt.o
obj-$(CONFIG_MARVELL_PHY) += marvell.o
+obj-$(CONFIG_MESON_GXL_PHY) += meson-gxl.o
obj-$(CONFIG_MICREL_KS8995MA) += spi_ks8995.o
obj-$(CONFIG_MICREL_PHY) += micrel.o
obj-$(CONFIG_MICROCHIP_PHY) += microchip.o
diff --git a/drivers/net/phy/meson-gxl.c b/drivers/net/phy/meson-gxl.c
new file mode 100644
index 0000000..1ea69b7
--- /dev/null
+++ b/drivers/net/phy/meson-gxl.c
@@ -0,0 +1,81 @@
+/*
+ * Amlogic Meson GXL Internal PHY Driver
+ *
+ * Copyright (C) 2015 Amlogic, Inc. All rights reserved.
+ * Copyright (C) 2016 BayLibre, SAS. All rights reserved.
+ * Author: Neil Armstrong <narmstrong@baylibre.com>
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ *
+ * 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/module.h>
+#include <linux/mii.h>
+#include <linux/ethtool.h>
+#include <linux/phy.h>
+#include <linux/netdevice.h>
+
+static int meson_gxl_config_init(struct phy_device *phydev)
+{
+ /* Enable Analog and DSP register Bank access by */
+ phy_write(phydev, 0x14, 0x0000);
+ phy_write(phydev, 0x14, 0x0400);
+ phy_write(phydev, 0x14, 0x0000);
+ phy_write(phydev, 0x14, 0x0400);
+
+ /* Write Analog register 23 */
+ phy_write(phydev, 0x17, 0x8E0D);
+ phy_write(phydev, 0x14, 0x4417);
+
+ /* Enable fractional PLL */
+ phy_write(phydev, 0x17, 0x0005);
+ phy_write(phydev, 0x14, 0x5C1B);
+
+ /* Program fraction FR_PLL_DIV1 */
+ phy_write(phydev, 0x17, 0x029A);
+ phy_write(phydev, 0x14, 0x5C1D);
+
+ /* Program fraction FR_PLL_DIV1 */
+ phy_write(phydev, 0x17, 0xAAAA);
+ phy_write(phydev, 0x14, 0x5C1C);
+
+ return 0;
+}
+
+static struct phy_driver meson_gxl_phy[] = {
+ {
+ .phy_id = 0x01814400,
+ .phy_id_mask = 0xfffffff0,
+ .name = "Meson GXL Internal PHY",
+ .features = PHY_BASIC_FEATURES,
+ .flags = PHY_IS_INTERNAL,
+ .config_init = meson_gxl_config_init,
+ .config_aneg = genphy_config_aneg,
+ .aneg_done = genphy_aneg_done,
+ .read_status = genphy_read_status,
+ .suspend = genphy_suspend,
+ .resume = genphy_resume,
+ },
+};
+
+static struct mdio_device_id __maybe_unused meson_gxl_tbl[] = {
+ { 0x01814400, 0xfffffff0 },
+ { }
+};
+
+module_phy_driver(meson_gxl_phy);
+
+MODULE_DEVICE_TABLE(mdio, meson_gxl_tbl);
+
+MODULE_DESCRIPTION("Amlogic Meson GXL Internal PHY driver");
+MODULE_AUTHOR("Baoqi wang");
+MODULE_AUTHOR("Neil Armstrong <narmstrong@baylibre.com>");
+MODULE_LICENSE("GPL");
--
1.9.1
^ permalink raw reply related
* [PATCH RFC 0/7] DMA: S3C64XX: Conversion to the new channel request API
From: Sylwester Nawrocki @ 2016-11-04 16:14 UTC (permalink / raw)
To: linux-arm-kernel
This patch series aims to convert the s3c64xx platform to use
the new universal DMA channel request API, i.e. this is only
meaningful for non-dt systems using s3c64xx SoCs.
I'm sending the whole series as RFC since I didn't test it
yet, I'm going to prepare smdk6410 for testing this series.
It would be great if someone else could also test it,
either SPI or sound functionality verification would be
useful.
Then we could queue the first two patches in this series
for v4.10-rc1 and the remaining patches for subsequent
release.
The whole series can be pulled from git repository:
git://linuxtv.org/snawrocki/samsung.git
branch: for-v4.10/dma/pl080-s3c64xx
Thanks.
Sylwester Nawrocki (7):
dma: pl08x: Add support for the DMA slave map
ARM: S3C64XX: Add DMA slave maps for PL080 devices
spi: s3c64xx: Do not use platform_data for DMA parameters
ASoC: samsung: i2s: Do not use platform_data for DMA parameters
ASoC: samsung: pcm: Do not use platform_data for DMA parameters
ARM: S3C64XX: Drop unused DMA fields from struct s3c64xx_spi_csinfo
ARM: S3C64XX: Drop initialization of unused struct s3c_audio_pdata
fields
arch/arm/mach-s3c64xx/dev-audio.c | 19 ------------------
arch/arm/mach-s3c64xx/pl080.c | 32 +++++++++++++++++++++++++++++++
arch/arm/plat-samsung/devs.c | 9 ---------
drivers/dma/amba-pl08x.c | 3 +++
drivers/spi/spi-s3c64xx.c | 21 ++++----------------
include/linux/amba/pl08x.h | 4 ++++
include/linux/platform_data/asoc-s3c.h | 5 -----
include/linux/platform_data/spi-s3c64xx.h | 3 ---
sound/soc/samsung/i2s.c | 14 ++------------
sound/soc/samsung/pcm.c | 14 +++++---------
10 files changed, 50 insertions(+), 74 deletions(-)
--
1.9.1
^ permalink raw reply
* [PATCH RFC 0/7] DMA: S3C64XX: Conversion to the new channel request API
From: Sylwester Nawrocki @ 2016-11-04 16:14 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1478276094-19135-1-git-send-email-s.nawrocki@samsung.com>
This patch series aims to convert the s3c64xx platform to use
the new universal DMA channel request API, i.e. this is only
meaningful for non-dt systems using s3c64xx SoCs.
I'm sending the whole series as RFC since I didn't test it
yet, I'm going to prepare smd6410 for testing this series.
It would be great if someone else could also test it,
either SPI or sound functionality verification would be
useful.
Then we could queue the first two patches in this series
for v4.10-rc1 and the remaining patches for subsequent
release.
The whole series can be pulled from git repository:
git://linuxtv.org/snawrocki/samsung.git
branch: for-v4.10/dma/pl080-s3c64xx
Thanks.
Sylwester Nawrocki (7):
dma: pl08x: Add support for the DMA slave map
ARM: S3C64XX: Add DMA slave maps for PL080 devices
spi: s3c64xx: Do not use platform_data for DMA parameters
ASoC: samsung: i2s: Do not use platform_data for DMA parameters
ASoC: samsung: pcm: Do not use platform_data for DMA parameters
ARM: S3C64XX: Drop unused DMA fields from struct s3c64xx_spi_csinfo
ARM: S3C64XX: Drop initialization of unused struct s3c_audio_pdata
fields
arch/arm/mach-s3c64xx/dev-audio.c | 19 ------------------
arch/arm/mach-s3c64xx/pl080.c | 32 +++++++++++++++++++++++++++++++
arch/arm/plat-samsung/devs.c | 9 ---------
drivers/dma/amba-pl08x.c | 3 +++
drivers/spi/spi-s3c64xx.c | 21 ++++----------------
include/linux/amba/pl08x.h | 4 ++++
include/linux/platform_data/asoc-s3c.h | 5 -----
include/linux/platform_data/spi-s3c64xx.h | 3 ---
sound/soc/samsung/i2s.c | 14 ++------------
sound/soc/samsung/pcm.c | 14 +++++---------
10 files changed, 50 insertions(+), 74 deletions(-)
--
1.9.1
^ permalink raw reply
* [PATCH RFC 1/7] dma: pl08x: Add support for the DMA slave map
From: Sylwester Nawrocki @ 2016-11-04 16:14 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1478276094-19135-1-git-send-email-s.nawrocki@samsung.com>
This patch add support for the new channel request API
introduced in commit a8135d0d79e9d0ad3a4ff494fceeaae83
"dmaengine: core: Introduce new, universal API to request a channel"
Signed-off-by: Sylwester Nawrocki <s.nawrocki@samsung.com>
---
drivers/dma/amba-pl08x.c | 3 +++
include/linux/amba/pl08x.h | 4 ++++
2 files changed, 7 insertions(+)
diff --git a/drivers/dma/amba-pl08x.c b/drivers/dma/amba-pl08x.c
index 939a7c3..d5c75c8 100644
--- a/drivers/dma/amba-pl08x.c
+++ b/drivers/dma/amba-pl08x.c
@@ -2307,6 +2307,9 @@ static int pl08x_probe(struct amba_device *adev, const struct amba_id *id)
ret = -EINVAL;
goto out_no_platdata;
}
+ } else {
+ pl08x->slave.filter.map = pl08x->pd->slave_map;
+ pl08x->slave.filter.mapcnt = pl08x->pd->slave_map_len;
}
/* By default, AHB1 only. If dualmaster, from platform */
diff --git a/include/linux/amba/pl08x.h b/include/linux/amba/pl08x.h
index 27e9ec8..5308eae 100644
--- a/include/linux/amba/pl08x.h
+++ b/include/linux/amba/pl08x.h
@@ -84,6 +84,8 @@ struct pl08x_channel_data {
* running any DMA transfer and multiplexing can be recycled
* @lli_buses: buses which LLIs can be fetched from: PL08X_AHB1 | PL08X_AHB2
* @mem_buses: buses which memory can be accessed from: PL08X_AHB1 | PL08X_AHB2
+ * @slave_map: DMA slave matching table
+ * @slave_map_len: number of elements in @slave_map
*/
struct pl08x_platform_data {
struct pl08x_channel_data *slave_channels;
@@ -93,6 +95,8 @@ struct pl08x_platform_data {
void (*put_xfer_signal)(const struct pl08x_channel_data *, int);
u8 lli_buses;
u8 mem_buses;
+ const struct dma_slave_map *slave_map;
+ int slave_map_len;
};
#ifdef CONFIG_AMBA_PL08X
--
1.9.1
^ permalink raw reply related
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox