* [PATCH V9 0/2] media: i2c: Add support for DW9768 VCM
@ 2020-06-30 6:22 Dongchun Zhu
2020-06-30 6:22 ` [PATCH V9 1/2] media: dt-bindings: media: i2c: Document DW9768 bindings Dongchun Zhu
` (2 more replies)
0 siblings, 3 replies; 11+ messages in thread
From: Dongchun Zhu @ 2020-06-30 6:22 UTC (permalink / raw)
To: linus.walleij, bgolaszewski, mchehab, andriy.shevchenko, robh+dt,
mark.rutland, sakari.ailus, drinkcat, tfiga, matthias.bgg,
bingbu.cao
Cc: devicetree, srv_heupstream, shengnan.wang, sj.huang,
linux-mediatek, dongchun.zhu, louis.kuo, linux-arm-kernel,
linux-media
Hello,
This series adds DT bindings and V4L2 sub-device driver for Dongwoon's DW9768,
which is a 10-bit DAC with 100mA output current sink capability.
The driver is designed for linear control of voice coil motor(VCM).
It creates a V4L2 sub-device and provides control to set the desired focus.
It controls the position with 10-bit DAC data D[9:0] and seperates
two 8-bit registers to control the VCM position as belows.
DAC_MSB: D[9:8](ADDR: 0x03):
+---+---+---+---+---+---+---+---+
|---|---|---|---|---|---|D09|D08|
+---+---+---+---+---+---+---+---+
DAC_LSB: D[7:0](ADDR: 0x04):
+---+---+---+---+---+---+---+---+
|D07|D06|D05|D04|D03|D02|D01|D00|
+---+---+---+---+---+---+---+---+
This driver supports:
- set DW9768 to standby mode once suspend and turn it back to active if resume
- set the desired focus via V4L2_CID_FOCUS_ABSOLUTE ctrl
Previous versions of this patch-set can be found here:
v8: https://lore.kernel.org/linux-media/20200616125531.31671-1-dongchun.zhu@mediatek.com/
v7: https://lore.kernel.org/linux-media/20200605105412.18813-1-dongchun.zhu@mediatek.com/
v6: https://lore.kernel.org/linux-media/20200518132731.20855-1-dongchun.zhu@mediatek.com/
v5: https://lore.kernel.org/linux-media/20200502161727.30463-1-dongchun.zhu@mediatek.com/
v4: https://lore.kernel.org/linux-media/20200330123634.363-1-dongchun.zhu@mediatek.com/
v3: https://lore.kernel.org/linux-media/20200228155958.20657-1-dongchun.zhu@mediatek.com/
v2: https://lore.kernel.org/linux-media/20190905072142.14606-1-dongchun.zhu@mediatek.com/
v1: https://lore.kernel.org/linux-media/20190708100641.2702-1-dongchun.zhu@mediatek.com/
Mainly changes of v9 are addressing comments from Tomasz.
Compared to v8:
- Refine dw9768_cal_move_delay() to return the value in a standard unit
- Refine err_power_off error handler section in probe()
- Use pm_runtime_status_suspended() in remove()
Please review.
Thanks.
Dongchun Zhu (2):
media: dt-bindings: media: i2c: Document DW9768 bindings
media: i2c: dw9768: Add DW9768 VCM driver
.../bindings/media/i2c/dongwoon,dw9768.yaml | 100 ++++
MAINTAINERS | 8 +
drivers/media/i2c/Kconfig | 12 +
drivers/media/i2c/Makefile | 1 +
drivers/media/i2c/dw9768.c | 554 +++++++++++++++++++++
5 files changed, 675 insertions(+)
create mode 100644 Documentation/devicetree/bindings/media/i2c/dongwoon,dw9768.yaml
create mode 100644 drivers/media/i2c/dw9768.c
--
2.9.2
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply [flat|nested] 11+ messages in thread* [PATCH V9 1/2] media: dt-bindings: media: i2c: Document DW9768 bindings 2020-06-30 6:22 [PATCH V9 0/2] media: i2c: Add support for DW9768 VCM Dongchun Zhu @ 2020-06-30 6:22 ` Dongchun Zhu 2020-06-30 6:22 ` [PATCH V9 2/2] media: i2c: dw9768: Add DW9768 VCM driver Dongchun Zhu 2020-07-01 9:16 ` [PATCH V9 0/2] media: i2c: Add support for DW9768 VCM Sakari Ailus 2 siblings, 0 replies; 11+ messages in thread From: Dongchun Zhu @ 2020-06-30 6:22 UTC (permalink / raw) To: linus.walleij, bgolaszewski, mchehab, andriy.shevchenko, robh+dt, mark.rutland, sakari.ailus, drinkcat, tfiga, matthias.bgg, bingbu.cao Cc: devicetree, srv_heupstream, shengnan.wang, sj.huang, linux-mediatek, dongchun.zhu, louis.kuo, linux-arm-kernel, linux-media Add DeviceTree Binding Documentation for Dongwoon Anatech DW9768 voice coil actuator. Reviewed-by: Rob Herring <robh@kernel.org> Signed-off-by: Dongchun Zhu <dongchun.zhu@mediatek.com> --- .../bindings/media/i2c/dongwoon,dw9768.yaml | 100 +++++++++++++++++++++ MAINTAINERS | 7 ++ 2 files changed, 107 insertions(+) create mode 100644 Documentation/devicetree/bindings/media/i2c/dongwoon,dw9768.yaml diff --git a/Documentation/devicetree/bindings/media/i2c/dongwoon,dw9768.yaml b/Documentation/devicetree/bindings/media/i2c/dongwoon,dw9768.yaml new file mode 100644 index 0000000..cb96e95 --- /dev/null +++ b/Documentation/devicetree/bindings/media/i2c/dongwoon,dw9768.yaml @@ -0,0 +1,100 @@ +# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause) +# Copyright (c) 2020 MediaTek Inc. +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/media/i2c/dongwoon,dw9768.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Dongwoon Anatech DW9768 Voice Coil Motor (VCM) Lens Device Tree Bindings + +maintainers: + - Dongchun Zhu <dongchun.zhu@mediatek.com> + +description: |- + The Dongwoon DW9768 is a single 10-bit digital-to-analog (DAC) converter + with 100 mA output current sink capability. VCM current is controlled with + a linear mode driver. The DAC is controlled via a 2-wire (I2C-compatible) + serial interface that operates at clock rates up to 1MHz. This chip + integrates Advanced Actuator Control (AAC) technology and is intended for + driving voice coil lenses in camera modules. + +properties: + compatible: + enum: + - dongwoon,dw9768 # for DW9768 VCM + - giantec,gt9769 # for GT9769 VCM + + reg: + maxItems: 1 + + vin-supply: + description: + Definition of the regulator used as Digital I/O voltage supply. + + vdd-supply: + description: + Definition of the regulator used as Digital core voltage supply. + + dongwoon,aac-mode: + description: + Indication of AAC mode select. + allOf: + - $ref: "/schemas/types.yaml#/definitions/uint32" + - enum: + - 1 # AAC2 mode(operation time# 0.48 x Tvib) + - 2 # AAC3 mode(operation time# 0.70 x Tvib) + - 3 # AAC4 mode(operation time# 0.75 x Tvib) + - 5 # AAC8 mode(operation time# 1.13 x Tvib) + default: 2 + + dongwoon,aac-timing: + description: + Number of AAC Timing count that controlled by one 6-bit period of + vibration register AACT[5:0], the unit of which is 100 us. + allOf: + - $ref: "/schemas/types.yaml#/definitions/uint32" + - default: 0x20 + minimum: 0x00 + maximum: 0x3f + + dongwoon,clock-presc: + description: + Indication of VCM internal clock dividing rate select, as one multiple + factor to calculate VCM ring periodic time Tvib. + allOf: + - $ref: "/schemas/types.yaml#/definitions/uint32" + - enum: + - 0 # Dividing Rate - 2 + - 1 # Dividing Rate - 1 + - 2 # Dividing Rate - 1/2 + - 3 # Dividing Rate - 1/4 + - 4 # Dividing Rate - 8 + - 5 # Dividing Rate - 4 + default: 1 + +required: + - compatible + - reg + - vin-supply + - vdd-supply + +additionalProperties: false + +examples: + - | + + i2c { + #address-cells = <1>; + #size-cells = <0>; + + dw9768: camera-lens@c { + compatible = "dongwoon,dw9768"; + reg = <0x0c>; + + vin-supply = <&mt6358_vcamio_reg>; + vdd-supply = <&mt6358_vcama2_reg>; + dongwoon,aac-timing = <0x39>; + }; + }; + +... diff --git a/MAINTAINERS b/MAINTAINERS index 68f21d4..62690c4 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -5215,6 +5215,13 @@ T: git git://linuxtv.org/media_tree.git F: Documentation/devicetree/bindings/media/i2c/dongwoon,dw9714.txt F: drivers/media/i2c/dw9714.c +DONGWOON DW9768 LENS VOICE COIL DRIVER +M: Dongchun Zhu <dongchun.zhu@mediatek.com> +L: linux-media@vger.kernel.org +S: Maintained +T: git git://linuxtv.org/media_tree.git +F: Documentation/devicetree/bindings/media/i2c/dongwoon,dw9768.yaml + DONGWOON DW9807 LENS VOICE COIL DRIVER M: Sakari Ailus <sakari.ailus@linux.intel.com> L: linux-media@vger.kernel.org -- 2.9.2 _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel ^ permalink raw reply related [flat|nested] 11+ messages in thread
* [PATCH V9 2/2] media: i2c: dw9768: Add DW9768 VCM driver 2020-06-30 6:22 [PATCH V9 0/2] media: i2c: Add support for DW9768 VCM Dongchun Zhu 2020-06-30 6:22 ` [PATCH V9 1/2] media: dt-bindings: media: i2c: Document DW9768 bindings Dongchun Zhu @ 2020-06-30 6:22 ` Dongchun Zhu 2020-06-30 16:57 ` Tomasz Figa 2020-07-01 9:16 ` [PATCH V9 0/2] media: i2c: Add support for DW9768 VCM Sakari Ailus 2 siblings, 1 reply; 11+ messages in thread From: Dongchun Zhu @ 2020-06-30 6:22 UTC (permalink / raw) To: linus.walleij, bgolaszewski, mchehab, andriy.shevchenko, robh+dt, mark.rutland, sakari.ailus, drinkcat, tfiga, matthias.bgg, bingbu.cao Cc: devicetree, srv_heupstream, shengnan.wang, sj.huang, linux-mediatek, dongchun.zhu, louis.kuo, linux-arm-kernel, linux-media Add a V4L2 sub-device driver for DW9768 voice coil motor, providing control to set the desired focus via IIC serial interface. Signed-off-by: Dongchun Zhu <dongchun.zhu@mediatek.com> --- MAINTAINERS | 1 + drivers/media/i2c/Kconfig | 12 + drivers/media/i2c/Makefile | 1 + drivers/media/i2c/dw9768.c | 554 +++++++++++++++++++++++++++++++++++++++++++++ 4 files changed, 568 insertions(+) create mode 100644 drivers/media/i2c/dw9768.c diff --git a/MAINTAINERS b/MAINTAINERS index 62690c4..35b3dab 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -5221,6 +5221,7 @@ L: linux-media@vger.kernel.org S: Maintained T: git git://linuxtv.org/media_tree.git F: Documentation/devicetree/bindings/media/i2c/dongwoon,dw9768.yaml +F: drivers/media/i2c/dw9768.c DONGWOON DW9807 LENS VOICE COIL DRIVER M: Sakari Ailus <sakari.ailus@linux.intel.com> diff --git a/drivers/media/i2c/Kconfig b/drivers/media/i2c/Kconfig index da11036..933371f 100644 --- a/drivers/media/i2c/Kconfig +++ b/drivers/media/i2c/Kconfig @@ -1253,6 +1253,18 @@ config VIDEO_DW9714 capability. This is designed for linear control of voice coil motors, controlled via I2C serial interface. +config VIDEO_DW9768 + tristate "DW9768 lens voice coil support" + depends on I2C && VIDEO_V4L2 + select MEDIA_CONTROLLER + select VIDEO_V4L2_SUBDEV_API + select V4L2_FWNODE + help + This is a driver for the DW9768 camera lens voice coil. + DW9768 is a 10 bit DAC with 100mA output current sink + capability. This is designed for linear control of + voice coil motors, controlled via I2C serial interface. + config VIDEO_DW9807_VCM tristate "DW9807 lens voice coil support" depends on I2C && VIDEO_V4L2 diff --git a/drivers/media/i2c/Makefile b/drivers/media/i2c/Makefile index 993acab..33ad435 100644 --- a/drivers/media/i2c/Makefile +++ b/drivers/media/i2c/Makefile @@ -24,6 +24,7 @@ obj-$(CONFIG_VIDEO_SAA6752HS) += saa6752hs.o obj-$(CONFIG_VIDEO_AD5820) += ad5820.o obj-$(CONFIG_VIDEO_AK7375) += ak7375.o obj-$(CONFIG_VIDEO_DW9714) += dw9714.o +obj-$(CONFIG_VIDEO_DW9768) += dw9768.o obj-$(CONFIG_VIDEO_DW9807_VCM) += dw9807-vcm.o obj-$(CONFIG_VIDEO_ADV7170) += adv7170.o obj-$(CONFIG_VIDEO_ADV7175) += adv7175.o diff --git a/drivers/media/i2c/dw9768.c b/drivers/media/i2c/dw9768.c new file mode 100644 index 0000000..45cdd92 --- /dev/null +++ b/drivers/media/i2c/dw9768.c @@ -0,0 +1,554 @@ +// SPDX-License-Identifier: GPL-2.0 +// Copyright (c) 2020 MediaTek Inc. + +#include <linux/delay.h> +#include <linux/i2c.h> +#include <linux/module.h> +#include <linux/pm_runtime.h> +#include <linux/regulator/consumer.h> +#include <media/v4l2-async.h> +#include <media/v4l2-ctrls.h> +#include <media/v4l2-device.h> +#include <media/v4l2-fwnode.h> +#include <media/v4l2-subdev.h> + +#define DW9768_NAME "dw9768" +#define DW9768_MAX_FOCUS_POS (1024 - 1) +/* + * This sets the minimum granularity for the focus positions. + * A value of 1 gives maximum accuracy for a desired focus position + */ +#define DW9768_FOCUS_STEPS 1 + +/* + * Ring control and Power control register + * Bit[1] RING_EN + * 0: Direct mode + * 1: AAC mode (ringing control mode) + * Bit[0] PD + * 0: Normal operation mode + * 1: Power down mode + * DW9768 requires waiting time of Topr after PD reset takes place. + */ +#define DW9768_RING_PD_CONTROL_REG 0x02 +#define DW9768_PD_MODE_OFF 0x00 +#define DW9768_PD_MODE_EN BIT(0) +#define DW9768_AAC_MODE_EN BIT(1) + +/* + * DW9768 separates two registers to control the VCM position. + * One for MSB value, another is LSB value. + * DAC_MSB: D[9:8] (ADD: 0x03) + * DAC_LSB: D[7:0] (ADD: 0x04) + * D[9:0] DAC data input: positive output current = D[9:0] / 1023 * 100[mA] + */ +#define DW9768_MSB_ADDR 0x03 +#define DW9768_LSB_ADDR 0x04 +#define DW9768_STATUS_ADDR 0x05 + +/* + * AAC mode control & prescale register + * Bit[7:5] Namely AC[2:0], decide the VCM mode and operation time. + * 001 AAC2 0.48 x Tvib + * 010 AAC3 0.70 x Tvib + * 011 AAC4 0.75 x Tvib + * 101 AAC8 1.13 x Tvib + * Bit[2:0] Namely PRESC[2:0], set the internal clock dividing rate as follow. + * 000 2 + * 001 1 + * 010 1/2 + * 011 1/4 + * 100 8 + * 101 4 + */ +#define DW9768_AAC_PRESC_REG 0x06 +#define DW9768_AAC_MODE_SEL_MASK GENMASK(7, 5) +#define DW9768_CLOCK_PRE_SCALE_SEL_MASK GENMASK(2, 0) + +/* + * VCM period of vibration register + * Bit[5:0] Defined as VCM rising periodic time (Tvib) together with PRESC[2:0] + * Tvib = (6.3ms + AACT[5:0] * 0.1ms) * Dividing Rate + * Dividing Rate is the internal clock dividing rate that is defined at + * PRESCALE register (ADD: 0x06) + */ +#define DW9768_AAC_TIME_REG 0x07 + +/* + * DW9768 requires waiting time (delay time) of t_OPR after power-up, + * or in the case of PD reset taking place. + */ +#define DW9768_T_OPR_US 1000 +#define DW9768_TVIB_MS_BASE10 (64 - 1) +#define DW9768_AAC_MODE_DEFAULT 2 +#define DW9768_AAC_TIME_DEFAULT 0x20 +#define DW9768_CLOCK_PRE_SCALE_DEFAULT 1 + +/* + * This acts as the minimum granularity of lens movement. + * Keep this value power of 2, so the control steps can be + * uniformly adjusted for gradual lens movement, with desired + * number of control steps. + */ +#define DW9768_MOVE_STEPS 16 + +static const char * const dw9768_supply_names[] = { + "vin", /* Digital I/O power */ + "vdd", /* Digital core power */ +}; + +/* dw9768 device structure */ +struct dw9768 { + struct regulator_bulk_data supplies[ARRAY_SIZE(dw9768_supply_names)]; + struct v4l2_ctrl_handler ctrls; + struct v4l2_ctrl *focus; + struct v4l2_subdev sd; + + u32 aac_mode; + u32 aac_timing; + u32 clock_presc; + u32 move_delay_us; +}; + +static inline struct dw9768 *sd_to_dw9768(struct v4l2_subdev *subdev) +{ + return container_of(subdev, struct dw9768, sd); +} + +struct regval_list { + u8 reg_num; + u8 value; +}; + +struct dw9768_aac_mode_ot_multi { + u32 aac_mode_enum; + u32 ot_multi_base100; +}; + +struct dw9768_clk_presc_dividing_rate { + u32 clk_presc_enum; + u32 dividing_rate_base100; +}; + +static const struct dw9768_aac_mode_ot_multi aac_mode_ot_multi[] = { + {1, 48}, + {2, 70}, + {3, 75}, + {5, 113}, +}; + +static const struct dw9768_clk_presc_dividing_rate presc_dividing_rate[] = { + {0, 200}, + {1, 100}, + {2, 50}, + {3, 25}, + {4, 800}, + {5, 400}, +}; + +static u32 dw9768_find_ot_multi(u32 aac_mode_param) +{ + u32 cur_ot_multi_base100 = 70; + unsigned int i; + + for (i = 0; i < ARRAY_SIZE(aac_mode_ot_multi); i++) { + if (aac_mode_ot_multi[i].aac_mode_enum == aac_mode_param) { + cur_ot_multi_base100 = + aac_mode_ot_multi[i].ot_multi_base100; + } + } + + return cur_ot_multi_base100; +} + +static u32 dw9768_find_dividing_rate(u32 presc_param) +{ + u32 cur_clk_dividing_rate_base100 = 100; + unsigned int i; + + for (i = 0; i < ARRAY_SIZE(presc_dividing_rate); i++) { + if (presc_dividing_rate[i].clk_presc_enum == presc_param) { + cur_clk_dividing_rate_base100 = + presc_dividing_rate[i].dividing_rate_base100; + } + } + + return cur_clk_dividing_rate_base100; +} + +/* + * DW9768_AAC_PRESC_REG & DW9768_AAC_TIME_REG determine VCM operation time. + * For current VCM mode: AAC3, Operation Time would be 0.70 x Tvib. + * Tvib = (6.3ms + AACT[5:0] * 0.1MS) * Dividing Rate. + * Below is calculation of the operation delay for each step. + */ +static inline u32 dw9768_cal_move_delay(u32 aac_mode_param, u32 presc_param, + u32 aac_timing_param) +{ + u32 Tvib_us; + u32 ot_multi_base100; + u32 clk_dividing_rate_base100; + + ot_multi_base100 = dw9768_find_ot_multi(aac_mode_param); + + clk_dividing_rate_base100 = dw9768_find_dividing_rate(presc_param); + + Tvib_us = (DW9768_TVIB_MS_BASE10 + aac_timing_param) * + clk_dividing_rate_base100; + + return Tvib_us * ot_multi_base100 / 100; +} + +static int dw9768_mod_reg(struct dw9768 *dw9768, u8 reg, u8 mask, u8 val) +{ + struct i2c_client *client = v4l2_get_subdevdata(&dw9768->sd); + int ret; + + ret = i2c_smbus_read_byte_data(client, reg); + if (ret < 0) + return ret; + + val = ((unsigned char)ret & ~mask) | (val & mask); + + return i2c_smbus_write_byte_data(client, reg, val); +} + +static int dw9768_set_dac(struct dw9768 *dw9768, u16 val) +{ + struct i2c_client *client = v4l2_get_subdevdata(&dw9768->sd); + + /* Write VCM position to registers */ + return i2c_smbus_write_word_swapped(client, DW9768_MSB_ADDR, val); +} + +static int dw9768_init(struct dw9768 *dw9768) +{ + struct i2c_client *client = v4l2_get_subdevdata(&dw9768->sd); + int ret, val; + + /* Reset DW9768_RING_PD_CONTROL_REG to default status 0x00 */ + ret = i2c_smbus_write_byte_data(client, DW9768_RING_PD_CONTROL_REG, + DW9768_PD_MODE_OFF); + if (ret < 0) + return ret; + + /* + * DW9769 requires waiting delay time of t_OPR + * after PD reset takes place. + */ + usleep_range(DW9768_T_OPR_US, DW9768_T_OPR_US + 100); + + /* Set DW9768_RING_PD_CONTROL_REG to DW9768_AAC_MODE_EN(0x01) */ + ret = i2c_smbus_write_byte_data(client, DW9768_RING_PD_CONTROL_REG, + DW9768_AAC_MODE_EN); + if (ret < 0) + return ret; + + /* Set AAC mode */ + ret = dw9768_mod_reg(dw9768, DW9768_AAC_PRESC_REG, + DW9768_AAC_MODE_SEL_MASK, + dw9768->aac_mode << 5); + if (ret < 0) + return ret; + + /* Set clock presc */ + if (dw9768->clock_presc != DW9768_CLOCK_PRE_SCALE_DEFAULT) { + ret = dw9768_mod_reg(dw9768, DW9768_AAC_PRESC_REG, + DW9768_CLOCK_PRE_SCALE_SEL_MASK, + dw9768->clock_presc); + if (ret < 0) + return ret; + } + + /* Set AAC Timing */ + if (dw9768->aac_timing != DW9768_AAC_TIME_DEFAULT) { + ret = i2c_smbus_write_byte_data(client, DW9768_AAC_TIME_REG, + dw9768->aac_timing); + if (ret < 0) + return ret; + } + + for (val = dw9768->focus->val % DW9768_MOVE_STEPS; + val <= dw9768->focus->val; + val += DW9768_MOVE_STEPS) { + ret = dw9768_set_dac(dw9768, val); + if (ret) { + dev_err(&client->dev, "I2C failure: %d", ret); + return ret; + } + usleep_range(dw9768->move_delay_us, + dw9768->move_delay_us + 1000); + } + + return 0; +} + +static int dw9768_release(struct dw9768 *dw9768) +{ + struct i2c_client *client = v4l2_get_subdevdata(&dw9768->sd); + int ret, val; + + val = round_down(dw9768->focus->val, DW9768_MOVE_STEPS); + for ( ; val >= 0; val -= DW9768_MOVE_STEPS) { + ret = dw9768_set_dac(dw9768, val); + if (ret) { + dev_err(&client->dev, "I2C write fail: %d", ret); + return ret; + } + usleep_range(dw9768->move_delay_us, + dw9768->move_delay_us + 1000); + } + + ret = i2c_smbus_write_byte_data(client, DW9768_RING_PD_CONTROL_REG, + DW9768_PD_MODE_EN); + if (ret < 0) + return ret; + + /* + * DW9769 requires waiting delay time of t_OPR + * after PD reset takes place. + */ + usleep_range(DW9768_T_OPR_US, DW9768_T_OPR_US + 100); + + return 0; +} + +static int dw9768_runtime_suspend(struct device *dev) +{ + struct i2c_client *client = to_i2c_client(dev); + struct v4l2_subdev *sd = i2c_get_clientdata(client); + struct dw9768 *dw9768 = sd_to_dw9768(sd); + + dw9768_release(dw9768); + regulator_bulk_disable(ARRAY_SIZE(dw9768_supply_names), + dw9768->supplies); + + return 0; +} + +static int dw9768_runtime_resume(struct device *dev) +{ + struct i2c_client *client = to_i2c_client(dev); + struct v4l2_subdev *sd = i2c_get_clientdata(client); + struct dw9768 *dw9768 = sd_to_dw9768(sd); + int ret; + + ret = regulator_bulk_enable(ARRAY_SIZE(dw9768_supply_names), + dw9768->supplies); + if (ret < 0) { + dev_err(dev, "failed to enable regulators\n"); + return ret; + } + + /* + * The datasheet refers to t_OPR that needs to be waited before sending + * I2C commands after power-up. + */ + usleep_range(DW9768_T_OPR_US, DW9768_T_OPR_US + 100); + + ret = dw9768_init(dw9768); + if (ret < 0) + goto disable_regulator; + + return 0; + +disable_regulator: + regulator_bulk_disable(ARRAY_SIZE(dw9768_supply_names), + dw9768->supplies); + + return ret; +} + +static int dw9768_set_ctrl(struct v4l2_ctrl *ctrl) +{ + struct dw9768 *dw9768 = container_of(ctrl->handler, + struct dw9768, ctrls); + + if (ctrl->id == V4L2_CID_FOCUS_ABSOLUTE) + return dw9768_set_dac(dw9768, ctrl->val); + + return 0; +} + +static const struct v4l2_ctrl_ops dw9768_ctrl_ops = { + .s_ctrl = dw9768_set_ctrl, +}; + +static int dw9768_open(struct v4l2_subdev *sd, struct v4l2_subdev_fh *fh) +{ + int ret; + + ret = pm_runtime_get_sync(sd->dev); + if (ret < 0) { + pm_runtime_put_noidle(sd->dev); + return ret; + } + + return 0; +} + +static int dw9768_close(struct v4l2_subdev *sd, struct v4l2_subdev_fh *fh) +{ + pm_runtime_put(sd->dev); + + return 0; +} + +static const struct v4l2_subdev_internal_ops dw9768_int_ops = { + .open = dw9768_open, + .close = dw9768_close, +}; + +static const struct v4l2_subdev_ops dw9768_ops = { }; + +static int dw9768_init_controls(struct dw9768 *dw9768) +{ + struct v4l2_ctrl_handler *hdl = &dw9768->ctrls; + const struct v4l2_ctrl_ops *ops = &dw9768_ctrl_ops; + + v4l2_ctrl_handler_init(hdl, 1); + + dw9768->focus = v4l2_ctrl_new_std(hdl, ops, V4L2_CID_FOCUS_ABSOLUTE, 0, + DW9768_MAX_FOCUS_POS, + DW9768_FOCUS_STEPS, 0); + + if (hdl->error) + return hdl->error; + + dw9768->sd.ctrl_handler = hdl; + + return 0; +} + +static int dw9768_probe(struct i2c_client *client) +{ + struct device *dev = &client->dev; + struct dw9768 *dw9768; + unsigned int i; + int ret; + + dw9768 = devm_kzalloc(dev, sizeof(*dw9768), GFP_KERNEL); + if (!dw9768) + return -ENOMEM; + + /* Initialize subdev */ + v4l2_i2c_subdev_init(&dw9768->sd, client, &dw9768_ops); + + dw9768->aac_mode = DW9768_AAC_MODE_DEFAULT; + dw9768->aac_timing = DW9768_AAC_TIME_DEFAULT; + dw9768->clock_presc = DW9768_CLOCK_PRE_SCALE_DEFAULT; + + /* Optional indication of AAC mode select */ + fwnode_property_read_u32(dev_fwnode(dev), "dongwoon,aac-mode", + &dw9768->aac_mode); + + /* Optional indication of clock pre-scale select */ + fwnode_property_read_u32(dev_fwnode(dev), "dongwoon,clock-presc", + &dw9768->clock_presc); + + /* Optional indication of AAC Timing */ + fwnode_property_read_u32(dev_fwnode(dev), "dongwoon,aac-timing", + &dw9768->aac_timing); + + dw9768->move_delay_us = dw9768_cal_move_delay(dw9768->aac_mode, + dw9768->clock_presc, + dw9768->aac_timing); + + for (i = 0; i < ARRAY_SIZE(dw9768_supply_names); i++) + dw9768->supplies[i].supply = dw9768_supply_names[i]; + + ret = devm_regulator_bulk_get(dev, ARRAY_SIZE(dw9768_supply_names), + dw9768->supplies); + if (ret) { + dev_err(dev, "failed to get regulators\n"); + return ret; + } + + /* Initialize controls */ + ret = dw9768_init_controls(dw9768); + if (ret) + goto err_free_handler; + + /* Initialize subdev */ + dw9768->sd.flags |= V4L2_SUBDEV_FL_HAS_DEVNODE; + dw9768->sd.internal_ops = &dw9768_int_ops; + + ret = media_entity_pads_init(&dw9768->sd.entity, 0, NULL); + if (ret < 0) + goto err_free_handler; + + dw9768->sd.entity.function = MEDIA_ENT_F_LENS; + + pm_runtime_enable(dev); + if (!pm_runtime_enabled(dev)) { + ret = dw9768_runtime_resume(dev); + if (ret < 0) { + dev_err(dev, "failed to power on: %d\n", ret); + goto err_clean_entity; + } + } + + ret = v4l2_async_register_subdev(&dw9768->sd); + if (ret < 0) { + dev_err(dev, "failed to register V4L2 subdev: %d", ret); + goto err_power_off; + } + + return 0; + +err_power_off: + if (pm_runtime_enabled(dev)) + pm_runtime_disable(dev); + else + dw9768_runtime_suspend(dev); +err_clean_entity: + media_entity_cleanup(&dw9768->sd.entity); +err_free_handler: + v4l2_ctrl_handler_free(&dw9768->ctrls); + + return ret; +} + +static int dw9768_remove(struct i2c_client *client) +{ + struct v4l2_subdev *sd = i2c_get_clientdata(client); + struct dw9768 *dw9768 = sd_to_dw9768(sd); + + v4l2_async_unregister_subdev(&dw9768->sd); + v4l2_ctrl_handler_free(&dw9768->ctrls); + media_entity_cleanup(&dw9768->sd.entity); + pm_runtime_disable(&client->dev); + if (!pm_runtime_status_suspended(&client->dev)) + dw9768_runtime_suspend(&client->dev); + pm_runtime_set_suspended(&client->dev); + + return 0; +} + +static const struct of_device_id dw9768_of_table[] = { + { .compatible = "dongwoon,dw9768" }, + { .compatible = "giantec,gt9769" }, + {} +}; +MODULE_DEVICE_TABLE(of, dw9768_of_table); + +static const struct dev_pm_ops dw9768_pm_ops = { + SET_SYSTEM_SLEEP_PM_OPS(pm_runtime_force_suspend, + pm_runtime_force_resume) + SET_RUNTIME_PM_OPS(dw9768_runtime_suspend, dw9768_runtime_resume, NULL) +}; + +static struct i2c_driver dw9768_i2c_driver = { + .driver = { + .name = DW9768_NAME, + .pm = &dw9768_pm_ops, + .of_match_table = dw9768_of_table, + }, + .probe_new = dw9768_probe, + .remove = dw9768_remove, +}; +module_i2c_driver(dw9768_i2c_driver); + +MODULE_AUTHOR("Dongchun Zhu <dongchun.zhu@mediatek.com>"); +MODULE_DESCRIPTION("DW9768 VCM driver"); +MODULE_LICENSE("GPL v2"); -- 2.9.2 _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel ^ permalink raw reply related [flat|nested] 11+ messages in thread
* Re: [PATCH V9 2/2] media: i2c: dw9768: Add DW9768 VCM driver 2020-06-30 6:22 ` [PATCH V9 2/2] media: i2c: dw9768: Add DW9768 VCM driver Dongchun Zhu @ 2020-06-30 16:57 ` Tomasz Figa 0 siblings, 0 replies; 11+ messages in thread From: Tomasz Figa @ 2020-06-30 16:57 UTC (permalink / raw) To: Dongchun Zhu Cc: mark.rutland, drinkcat, andriy.shevchenko, srv_heupstream, devicetree, linus.walleij, shengnan.wang, louis.kuo, bgolaszewski, sj.huang, robh+dt, linux-mediatek, sakari.ailus, matthias.bgg, bingbu.cao, mchehab, linux-arm-kernel, linux-media On Tue, Jun 30, 2020 at 02:22:11PM +0800, Dongchun Zhu wrote: > Add a V4L2 sub-device driver for DW9768 voice coil motor, > providing control to set the desired focus via IIC serial interface. > > Signed-off-by: Dongchun Zhu <dongchun.zhu@mediatek.com> > --- > MAINTAINERS | 1 + > drivers/media/i2c/Kconfig | 12 + > drivers/media/i2c/Makefile | 1 + > drivers/media/i2c/dw9768.c | 554 +++++++++++++++++++++++++++++++++++++++++++++ > 4 files changed, 568 insertions(+) > create mode 100644 drivers/media/i2c/dw9768.c > Reviewed-by: Tomasz Figa <tfiga@chromium.org> Best regards, Tomasz _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel ^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: [PATCH V9 0/2] media: i2c: Add support for DW9768 VCM 2020-06-30 6:22 [PATCH V9 0/2] media: i2c: Add support for DW9768 VCM Dongchun Zhu 2020-06-30 6:22 ` [PATCH V9 1/2] media: dt-bindings: media: i2c: Document DW9768 bindings Dongchun Zhu 2020-06-30 6:22 ` [PATCH V9 2/2] media: i2c: dw9768: Add DW9768 VCM driver Dongchun Zhu @ 2020-07-01 9:16 ` Sakari Ailus [not found] ` <bf610d1b13c74656b2ffeeb9cc2a96ac@MTKMBS31N1.mediatek.inc> 2 siblings, 1 reply; 11+ messages in thread From: Sakari Ailus @ 2020-07-01 9:16 UTC (permalink / raw) To: Dongchun Zhu Cc: mark.rutland, drinkcat, andriy.shevchenko, srv_heupstream, devicetree, linus.walleij, shengnan.wang, tfiga, bgolaszewski, sj.huang, robh+dt, linux-mediatek, louis.kuo, matthias.bgg, bingbu.cao, mchehab, linux-arm-kernel, linux-media Dongchun, On Tue, Jun 30, 2020 at 02:22:09PM +0800, Dongchun Zhu wrote: > Hello, > > This series adds DT bindings and V4L2 sub-device driver for Dongwoon's DW9768, > which is a 10-bit DAC with 100mA output current sink capability. > > The driver is designed for linear control of voice coil motor(VCM). > It creates a V4L2 sub-device and provides control to set the desired focus. Thanks for the update. There seem to be trailing whitespaces at least in the first patch, and a conflict in MAINTAINERS vs. current media tree master. Could you address these, please? -- Regards, Sakari Ailus _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel ^ permalink raw reply [flat|nested] 11+ messages in thread
[parent not found: <bf610d1b13c74656b2ffeeb9cc2a96ac@MTKMBS31N1.mediatek.inc>]
[parent not found: <20200701134416.GQ16711@paasikivi.fi.intel.com>]
[parent not found: <e55e7b405a084a0298cd839c05b52c79@MTKMBS31N1.mediatek.inc>]
* RE: [PATCH V9 0/2] media: i2c: Add support for DW9768 VCM [not found] ` <e55e7b405a084a0298cd839c05b52c79@MTKMBS31N1.mediatek.inc> @ 2020-07-02 5:10 ` Cao, Bingbu 2020-07-02 5:34 ` Sakari Ailus 1 sibling, 0 replies; 11+ messages in thread From: Cao, Bingbu @ 2020-07-02 5:10 UTC (permalink / raw) To: Dongchun Zhu (朱东春), Sakari Ailus Cc: devicetree, drinkcat, srv_heupstream, linus.walleij, Shengnan Wang (王圣男), andriy.shevchenko, tfiga, bgolaszewski, Sj Huang (黃信璋), robh+dt, matthias.bgg, Louis Kuo (郭德寧), linux-mediatek, mchehab, Erin Lo (羅雅齡), linux-arm-kernel, linux-media Hi, Dongchun I think it need rebase on linuxtv/master. ________________________ BRs, Bingbu Cao From: Dongchun Zhu (朱东春) <Dongchun.Zhu@mediatek.com> Sent: Thursday, July 2, 2020 11:49 AM To: Sakari Ailus <sakari.ailus@linux.intel.com> Cc: linus.walleij@linaro.org; bgolaszewski@baylibre.com; mchehab@kernel.org; andriy.shevchenko@linux.intel.com; robh+dt@kernel.org; drinkcat@chromium.org; tfiga@chromium.org; Erin Lo (羅雅齡) <erin.lo@mediatek.com>; Louis Kuo (郭德寧) <louis.kuo@mediatek.com>; Sj Huang (黃信璋) <sj.huang@mediatek.com>; matthias.bgg@gmail.com; Cao, Bingbu <bingbu.cao@intel.com>; srv_heupstream <srv_heupstream@mediatek.com>; linux-mediatek@lists.infradead.org; linux-arm-kernel@lists.infradead.org; linux-media@vger.kernel.org; devicetree@vger.kernel.org; Shengnan Wang (王圣男) <shengnan.wang@mediatek.com> Subject: RE: [PATCH V9 0/2] media: i2c: Add support for DW9768 VCM Hi Sakari, Sorry to bother you again, but I am so confused about the questions you raised. I just synced mainline: 5.8-rc3 tarball from https://www.kernel.org/, on which I ran the git am <patch> command. The patch-applying process shows no error. -----------------8<------------------- [mtk15013@mtkslt307 linux]$git apply --check media-i2c-Add-support-for-DW9768-VCM.patch [mtk15013@mtkslt307 linux]$git am media-i2c-Add-support-for-DW9768-VCM.patch Applying: media: dt-bindings: media: i2c: Document DW9768 bindings Applying: media: i2c: dw9768: Add DW9768 VCM driver -----------------8<------------------- On the other hand, I also compared dongwoon,dw9768.yaml file with other media device dt-bindings(like imx219.yaml and ov8856.yaml). It seems there are no apparent differences between them. Especially, the sentence '# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)' shall be common. I dunno why here dongwoon,dw9768.yaml reports trailing whitespace warnings while ov8856.yaml is silent. For the patch failed on MAINTAINERS, I am still curious what's wrong. In fact, I locally have run parse-maintainers.pl script to check MAINTAINERS file before submitting patch. The result also reports no errors. -----------------8<------------------- [mtk15013@mtkslt307 linux]$perl scripts/parse-maintainers.pl [mtk15013@mtkslt307 linux]$ls -----------------8<------------------- As to Base64 encoding, I checked each patch file again. They are all encoded in UTF-8. As https://www.base64encode.org/ says, for an example, '77' in ASCII format would be changed to 'T' in Based64-encoded format. This means there shall be messy code if we adpoting Based64-encoded format. But I cannot see garbled messages in the current patches. The DW9768 serials-patch is attached. @Tomasz @Andy @Rob could anyone help try to see whether the patch can be cherry-picked on Linux master branch or not? Patchwork link: https://patchwork.kernel.org/cover/11633291/ Thanks, Dongchun -----Original Message----- From: Sakari Ailus [mailto:sakari.ailus@linux.intel.com] Sent: Wednesday, July 01, 2020 9:44 PM To: Dongchun Zhu (朱东春) Cc: mailto:bgolaszewski@baylibre.com; mailto:mchehab@kernel.org; mailto:andriy.shevchenko@linux.intel.com; mailto:robh+dt@kernel.org; mailto:drinkcat@chromium.org; mailto:tfiga@chromium.org; Erin Lo (羅雅齡); Louis Kuo (郭德寧) Subject: Re: [PATCH V9 0/2] media: i2c: Add support for DW9768 VCM Hi Dongchun, On Wed, Jul 01, 2020 at 12:14:48PM +0000, Dongchun Zhu (朱东春) wrote: > Hello Sakari, > > Thank you for your kindly review : -) > > For the trailing whitespaces, did you mean the message in the cover-letter(0/2 patch)? > I am a little confused about it. In fact, I can't tell the wrong places with my naked eye... > > For the conflict in MAINTAINERS vs. current media tree master, did you mean the file name(dongwoon,dw9768.yaml)? > Do we need to change dt-binding file name from dongwoon,dw9768.yaml to dw9768.yaml? I mean trailing whitespaces. When applying the patch with git am, this is what you get: -----------------8<------------------- $ git am -s /tmp/patchset Applying: media: dt-bindings: media: i2c: Document DW9768 bindings .git/rebase-apply/patch:13: trailing whitespace. # SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause) .git/rebase-apply/patch:14: trailing whitespace. # Copyright (c) 2020 MediaTek Inc. .git/rebase-apply/patch:15: trailing whitespace. %YAML 1.2 .git/rebase-apply/patch:16: trailing whitespace. --- .git/rebase-apply/patch:17: trailing whitespace. $id: http://devicetree.org/schemas/media/i2c/dongwoon,dw9768.yaml# error: patch failed: MAINTAINERS:5215 error: MAINTAINERS: patch does not apply Patch failed at 0001 media: dt-bindings: media: i2c: Document DW9768 bindings hint: Use 'git am --show-current-patch' to see the failed patch When you have resolved this problem, run "git am --continue". If you prefer to skip this patch, run "git am --skip" instead. To restore the original branch and stop patching, run "git am --abort". -----------------8<------------------- Also the patches seem to be base64 encoded, something I haven't seen before. That is likely unrelated though. -- Regards, Sakari Ailus ************* MEDIATEK Confidentiality Notice ******************** The information contained in this e-mail message (including any attachments) may be confidential, proprietary, privileged, or otherwise exempt from disclosure under applicable laws. It is intended to be conveyed only to the designated recipient(s). Any use, dissemination, distribution, printing, retaining or copying of this e-mail (including its attachments) by unintended recipient(s) is strictly prohibited and may be unlawful. If you are not an intended recipient of this e-mail, or believe that you have received this e-mail in error, please notify the sender immediately (by replying to this e-mail), delete any and all copies of this e-mail (including any attachments) from your system, and do not disclose the content of this e-mail to any other person. Thank you! _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel ^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: [PATCH V9 0/2] media: i2c: Add support for DW9768 VCM [not found] ` <e55e7b405a084a0298cd839c05b52c79@MTKMBS31N1.mediatek.inc> 2020-07-02 5:10 ` Cao, Bingbu @ 2020-07-02 5:34 ` Sakari Ailus 2020-07-02 11:06 ` Dongchun Zhu 1 sibling, 1 reply; 11+ messages in thread From: Sakari Ailus @ 2020-07-02 5:34 UTC (permalink / raw) To: Dongchun Zhu (朱东春) Cc: devicetree, drinkcat, srv_heupstream, Shengnan Wang (王圣男), linus.walleij, linux-mediatek, andriy.shevchenko, tfiga, bgolaszewski, Sj Huang (黃信璋), robh+dt, matthias.bgg, Louis Kuo (郭德寧), bingbu.cao, mchehab, Erin Lo (羅雅齡), linux-arm-kernel, linux-media Dongchun, Please don't send HTML e-mail to Linux kernel related mailing lists. On Thu, Jul 02, 2020 at 03:48:56AM +0000, Dongchun Zhu (朱东春) wrote: > Hi Sakari, > > Sorry to bother you again, but I am so confused about the questions you raised. > I just synced mainline: 5.8-rc3 tarball from https://www.kernel.org/, on which I ran the git am <patch> command. > The patch-applying process shows no error. > -----------------8<------------------- > [mtk15013@mtkslt307 linux]$git apply --check media-i2c-Add-support-for-DW9768-VCM.patch > [mtk15013@mtkslt307 linux]$git am media-i2c-Add-support-for-DW9768-VCM.patch > Applying: media: dt-bindings: media: i2c: Document DW9768 bindings > Applying: media: i2c: dw9768: Add DW9768 VCM driver > -----------------8<------------------- > > On the other hand, I also compared dongwoon,dw9768.yaml file with other media device dt-bindings(like imx219.yaml and ov8856.yaml). > It seems there are no apparent differences between them. > Especially, the sentence '# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)' shall be common. > I dunno why here dongwoon,dw9768.yaml reports trailing whitespace warnings while ov8856.yaml is silent. > > For the patch failed on MAINTAINERS, I am still curious what's wrong. > In fact, I locally have run parse-maintainers.pl script to check MAINTAINERS file before submitting patch. > The result also reports no errors. > -----------------8<------------------- > [mtk15013@mtkslt307 linux]$perl scripts/parse-maintainers.pl > [mtk15013@mtkslt307 linux]$ls > -----------------8<------------------- > > As to Base64 encoding, I checked each patch file again. They are all encoded in UTF-8. > As https://www.base64encode.org/ says, for an example, '77' in ASCII format would be changed to 'T' in Based64-encoded format. > This means there shall be messy code if we adpoting Based64-encoded format. > But I cannot see garbled messages in the current patches. > > The DW9768 serials-patch is attached. > @Tomasz @Andy @Rob could anyone help try to see whether the patch can be cherry-picked on Linux master branch or not? > Patchwork link: > https://patchwork.kernel.org/cover/11633291/ Both of the patches appear to contain only ASCII characters. I did some research on this. It seems that the base64 encoded message body does have carriage returns, in both cases. Git am does not attempt to remove them in that case, but Patchwork does. Hence the files are fine if you download them from Patchwork --- where the mbox files have neither carriage returns nor base64 encoding. What does the file command say about the patch files produced by git format-patch? My guess is that something in between your local computer and LMML (and other mail servers) base64 encodes the message body. But where are the carriage returns added? Nevertheless they seem to be added before the base64 conversion. I think this is also a git issue, but something that is very hard to encounter. ... > ************* MEDIATEK Confidentiality Notice ******************** > The information contained in this e-mail message (including any > attachments) may be confidential, proprietary, privileged, or otherwise > exempt from disclosure under applicable laws. It is intended to be > conveyed only to the designated recipient(s). Any use, dissemination, > distribution, printing, retaining or copying of this e-mail (including its > attachments) by unintended recipient(s) is strictly prohibited and may > be unlawful. If you are not an intended recipient of this e-mail, or believe > that you have received this e-mail in error, please notify the sender > immediately (by replying to this e-mail), delete any and all copies of > this e-mail (including any attachments) from your system, and do not > disclose the content of this e-mail to any other person. Thank you! Did you mean this? -- Kind regards, Sakari Ailus _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel ^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: [PATCH V9 0/2] media: i2c: Add support for DW9768 VCM 2020-07-02 5:34 ` Sakari Ailus @ 2020-07-02 11:06 ` Dongchun Zhu 2020-07-30 16:39 ` Sakari Ailus 0 siblings, 1 reply; 11+ messages in thread From: Dongchun Zhu @ 2020-07-02 11:06 UTC (permalink / raw) To: Sakari Ailus Cc: devicetree, drinkcat, srv_heupstream, Shengnan Wang (王圣男), linus.walleij, linux-mediatek, andriy.shevchenko, tfiga, bgolaszewski, Sj Huang (黃信璋), robh+dt, matthias.bgg, dongchun.zhu, Louis Kuo (郭德寧), bingbu.cao, mchehab, Erin Lo (羅雅齡), linux-arm-kernel, linux-media Hi Sakari, Sorry I just sent email using outlook where default format is HTML, now I use evolution, one Linux mail client that I used to send upstream patch previously. On Thu, 2020-07-02 at 08:34 +0300, Sakari Ailus wrote: > Dongchun, > > Please don't send HTML e-mail to Linux kernel related mailing lists. > > On Thu, Jul 02, 2020 at 03:48:56AM +0000, Dongchun Zhu (朱东春) wrote: > > Hi Sakari, > > > > Sorry to bother you again, but I am so confused about the questions you raised. > > I just synced mainline: 5.8-rc3 tarball from https://www.kernel.org/, on which I ran the git am <patch> command. > > The patch-applying process shows no error. > > -----------------8<------------------- > > [mtk15013@mtkslt307 linux]$git apply --check media-i2c-Add-support-for-DW9768-VCM.patch > > [mtk15013@mtkslt307 linux]$git am media-i2c-Add-support-for-DW9768-VCM.patch > > Applying: media: dt-bindings: media: i2c: Document DW9768 bindings > > Applying: media: i2c: dw9768: Add DW9768 VCM driver > > -----------------8<------------------- > > > > On the other hand, I also compared dongwoon,dw9768.yaml file with other media device dt-bindings(like imx219.yaml and ov8856.yaml). > > It seems there are no apparent differences between them. > > Especially, the sentence '# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)' shall be common. > > I dunno why here dongwoon,dw9768.yaml reports trailing whitespace warnings while ov8856.yaml is silent. > > > > For the patch failed on MAINTAINERS, I am still curious what's wrong. > > In fact, I locally have run parse-maintainers.pl script to check MAINTAINERS file before submitting patch. > > The result also reports no errors. > > -----------------8<------------------- > > [mtk15013@mtkslt307 linux]$perl scripts/parse-maintainers.pl > > [mtk15013@mtkslt307 linux]$ls > > -----------------8<------------------- > > > > As to Base64 encoding, I checked each patch file again. They are all encoded in UTF-8. > > As https://www.base64encode.org/ says, for an example, '77' in ASCII format would be changed to 'T' in Based64-encoded format. > > This means there shall be messy code if we adpoting Based64-encoded format. > > But I cannot see garbled messages in the current patches. > > > > The DW9768 serials-patch is attached. > > @Tomasz @Andy @Rob could anyone help try to see whether the patch can be cherry-picked on Linux master branch or not? > > Patchwork link: > > https://patchwork.kernel.org/cover/11633291/ > > Both of the patches appear to contain only ASCII characters. > > I did some research on this. It seems that the base64 encoded message body > does have carriage returns, in both cases. Git am does not attempt to > remove them in that case, but Patchwork does. Hence the files are fine if > you download them from Patchwork --- where the mbox files have neither > carriage returns nor base64 encoding. > > What does the file command say about the patch files produced by git > format-patch? My guess is that something in between your local computer and > LMML (and other mail servers) base64 encodes the message body. But where > are the carriage returns added? Nevertheless they seem to be added before > the base64 conversion. > Hm... I used the file command to check the diff patch generated from git format-patch and that downloaded from Patchwork, they are both ASCII text. In fact, we could also open the diff patch with notepad++ tool, if the EOL conversion is UNIX/OSX Format, end-of-line character would be LF. For the DW9768 patch, when we click the toolbar button "Show All Characters", there is no carriage return(CR) at the end of each line, but LF instead for all EOLs. > I think this is also a git issue, but something that is very hard to > encounter. > > ... > > > ************* MEDIATEK Confidentiality Notice ******************** > > The information contained in this e-mail message (including any > > attachments) may be confidential, proprietary, privileged, or otherwise > > exempt from disclosure under applicable laws. It is intended to be > > conveyed only to the designated recipient(s). Any use, dissemination, > > distribution, printing, retaining or copying of this e-mail (including its > > attachments) by unintended recipient(s) is strictly prohibited and may > > be unlawful. If you are not an intended recipient of this e-mail, or believe > > that you have received this e-mail in error, please notify the sender > > immediately (by replying to this e-mail), delete any and all copies of > > this e-mail (including any attachments) from your system, and do not > > disclose the content of this e-mail to any other person. Thank you! > > Did you mean this? > This is auto-generated by some mechanism when sending email to the address belong to an external organization. It mainly serves as a reminder, please don't care too much : -) _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel ^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: [PATCH V9 0/2] media: i2c: Add support for DW9768 VCM 2020-07-02 11:06 ` Dongchun Zhu @ 2020-07-30 16:39 ` Sakari Ailus 2020-07-31 2:44 ` [SPAM]Re: " Dongchun Zhu 0 siblings, 1 reply; 11+ messages in thread From: Sakari Ailus @ 2020-07-30 16:39 UTC (permalink / raw) To: Dongchun Zhu Cc: devicetree, drinkcat, srv_heupstream, Shengnan Wang (王圣男), linus.walleij, linux-mediatek, andriy.shevchenko, tfiga, bgolaszewski, Sj Huang (黃信璋), robh+dt, matthias.bgg, Louis Kuo (郭德寧), bingbu.cao, mchehab, Erin Lo (羅雅齡), linux-arm-kernel, linux-media Dongchun, On Thu, Jul 02, 2020 at 07:06:05PM +0800, Dongchun Zhu wrote: > Hi Sakari, > > Sorry I just sent email using outlook where default format is HTML, now > I use evolution, one Linux mail client that I used to send upstream > patch previously. > > On Thu, 2020-07-02 at 08:34 +0300, Sakari Ailus wrote: > > Dongchun, > > > > Please don't send HTML e-mail to Linux kernel related mailing lists. > > > > On Thu, Jul 02, 2020 at 03:48:56AM +0000, Dongchun Zhu (朱东春) wrote: > > > Hi Sakari, > > > > > > Sorry to bother you again, but I am so confused about the questions you raised. > > > I just synced mainline: 5.8-rc3 tarball from https://www.kernel.org/, on which I ran the git am <patch> command. > > > The patch-applying process shows no error. > > > -----------------8<------------------- > > > [mtk15013@mtkslt307 linux]$git apply --check media-i2c-Add-support-for-DW9768-VCM.patch > > > [mtk15013@mtkslt307 linux]$git am media-i2c-Add-support-for-DW9768-VCM.patch > > > Applying: media: dt-bindings: media: i2c: Document DW9768 bindings > > > Applying: media: i2c: dw9768: Add DW9768 VCM driver > > > -----------------8<------------------- > > > > > > On the other hand, I also compared dongwoon,dw9768.yaml file with other media device dt-bindings(like imx219.yaml and ov8856.yaml). > > > It seems there are no apparent differences between them. > > > Especially, the sentence '# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)' shall be common. > > > I dunno why here dongwoon,dw9768.yaml reports trailing whitespace warnings while ov8856.yaml is silent. > > > > > > For the patch failed on MAINTAINERS, I am still curious what's wrong. > > > In fact, I locally have run parse-maintainers.pl script to check MAINTAINERS file before submitting patch. > > > The result also reports no errors. > > > -----------------8<------------------- > > > [mtk15013@mtkslt307 linux]$perl scripts/parse-maintainers.pl > > > [mtk15013@mtkslt307 linux]$ls > > > -----------------8<------------------- > > > > > > As to Base64 encoding, I checked each patch file again. They are all encoded in UTF-8. > > > As https://www.base64encode.org/ says, for an example, '77' in ASCII format would be changed to 'T' in Based64-encoded format. > > > This means there shall be messy code if we adpoting Based64-encoded format. > > > But I cannot see garbled messages in the current patches. > > > > > > The DW9768 serials-patch is attached. > > > @Tomasz @Andy @Rob could anyone help try to see whether the patch can be cherry-picked on Linux master branch or not? > > > Patchwork link: > > > https://patchwork.kernel.org/cover/11633291/ > > > > Both of the patches appear to contain only ASCII characters. > > > > I did some research on this. It seems that the base64 encoded message body > > does have carriage returns, in both cases. Git am does not attempt to > > remove them in that case, but Patchwork does. Hence the files are fine if > > you download them from Patchwork --- where the mbox files have neither > > carriage returns nor base64 encoding. > > > > What does the file command say about the patch files produced by git > > format-patch? My guess is that something in between your local computer and > > LMML (and other mail servers) base64 encodes the message body. But where > > are the carriage returns added? Nevertheless they seem to be added before > > the base64 conversion. > > > > Hm... I used the file command to check the diff patch generated from git > format-patch and that downloaded from Patchwork, they are both ASCII > text. That's because Patchwork appears to be removing the carriage returns. git does not if the content is base64 encoded. Your e-mail setup simply appears to be broken. I'd suggest trying to send the patches encoded in base64 as a workaround. git send-email uses sendemail.transferEncoding configuration option for this. -- Sakari Ailus _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel ^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: [SPAM]Re: [PATCH V9 0/2] media: i2c: Add support for DW9768 VCM 2020-07-30 16:39 ` Sakari Ailus @ 2020-07-31 2:44 ` Dongchun Zhu 2020-07-31 13:04 ` Sakari Ailus 0 siblings, 1 reply; 11+ messages in thread From: Dongchun Zhu @ 2020-07-31 2:44 UTC (permalink / raw) To: Sakari Ailus Cc: devicetree, drinkcat, srv_heupstream, Shengnan Wang (王圣男), linus.walleij, linux-mediatek, andriy.shevchenko, tfiga, bgolaszewski, Sj Huang (黃信璋), robh+dt, matthias.bgg, Louis Kuo (郭德寧), bingbu.cao, mchehab, Erin Lo (羅雅齡), linux-arm-kernel, linux-media Hi Sakari, On Thu, 2020-07-30 at 19:39 +0300, Sakari Ailus wrote: > Dongchun, > > On Thu, Jul 02, 2020 at 07:06:05PM +0800, Dongchun Zhu wrote: > > Hi Sakari, > > > > Sorry I just sent email using outlook where default format is HTML, now > > I use evolution, one Linux mail client that I used to send upstream > > patch previously. > > > > On Thu, 2020-07-02 at 08:34 +0300, Sakari Ailus wrote: > > > Dongchun, > > > > > > Please don't send HTML e-mail to Linux kernel related mailing lists. > > > > > > On Thu, Jul 02, 2020 at 03:48:56AM +0000, Dongchun Zhu (朱东春) wrote: > > > > Hi Sakari, > > > > > > > > Sorry to bother you again, but I am so confused about the questions you raised. > > > > I just synced mainline: 5.8-rc3 tarball from https://www.kernel.org/, on which I ran the git am <patch> command. > > > > The patch-applying process shows no error. > > > > -----------------8<------------------- > > > > [mtk15013@mtkslt307 linux]$git apply --check media-i2c-Add-support-for-DW9768-VCM.patch > > > > [mtk15013@mtkslt307 linux]$git am media-i2c-Add-support-for-DW9768-VCM.patch > > > > Applying: media: dt-bindings: media: i2c: Document DW9768 bindings > > > > Applying: media: i2c: dw9768: Add DW9768 VCM driver > > > > -----------------8<------------------- > > > > > > > > On the other hand, I also compared dongwoon,dw9768.yaml file with other media device dt-bindings(like imx219.yaml and ov8856.yaml). > > > > It seems there are no apparent differences between them. > > > > Especially, the sentence '# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)' shall be common. > > > > I dunno why here dongwoon,dw9768.yaml reports trailing whitespace warnings while ov8856.yaml is silent. > > > > > > > > For the patch failed on MAINTAINERS, I am still curious what's wrong. > > > > In fact, I locally have run parse-maintainers.pl script to check MAINTAINERS file before submitting patch. > > > > The result also reports no errors. > > > > -----------------8<------------------- > > > > [mtk15013@mtkslt307 linux]$perl scripts/parse-maintainers.pl > > > > [mtk15013@mtkslt307 linux]$ls > > > > -----------------8<------------------- > > > > > > > > As to Base64 encoding, I checked each patch file again. They are all encoded in UTF-8. > > > > As https://www.base64encode.org/ says, for an example, '77' in ASCII format would be changed to 'T' in Based64-encoded format. > > > > This means there shall be messy code if we adpoting Based64-encoded format. > > > > But I cannot see garbled messages in the current patches. > > > > > > > > The DW9768 serials-patch is attached. > > > > @Tomasz @Andy @Rob could anyone help try to see whether the patch can be cherry-picked on Linux master branch or not? > > > > Patchwork link: > > > > https://patchwork.kernel.org/cover/11633291/ > > > > > > Both of the patches appear to contain only ASCII characters. > > > > > > I did some research on this. It seems that the base64 encoded message body > > > does have carriage returns, in both cases. Git am does not attempt to > > > remove them in that case, but Patchwork does. Hence the files are fine if > > > you download them from Patchwork --- where the mbox files have neither > > > carriage returns nor base64 encoding. > > > > > > What does the file command say about the patch files produced by git > > > format-patch? My guess is that something in between your local computer and > > > LMML (and other mail servers) base64 encodes the message body. But where > > > are the carriage returns added? Nevertheless they seem to be added before > > > the base64 conversion. > > > > > > > Hm... I used the file command to check the diff patch generated from git > > format-patch and that downloaded from Patchwork, they are both ASCII > > text. > > That's because Patchwork appears to be removing the carriage returns. git > does not if the content is base64 encoded. > > Your e-mail setup simply appears to be broken. I'd suggest trying to send > the patches encoded in base64 as a workaround. git send-email uses > sendemail.transferEncoding configuration option for this. > I checked my local git configuration by using "git config --list", it seems the "sendemail.transferEncoding" configuration variable is not set, also "git send-email --transfer-encoding" is not set when submitting patch. From my understanding, if both the option "--transfer-encoding=xxx" and the configuration value "sendemail.transferEncoding" are unspecified, the transfer encoding to be used to send the message over SMTP may be "auto". Did you mean doing an experiment by enabling "base64" config for transfer encoding as below? "git config --global sendemail.transferEncoding base64" or "git send-email --transfer-encoding=base64" _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel ^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: [SPAM]Re: [PATCH V9 0/2] media: i2c: Add support for DW9768 VCM 2020-07-31 2:44 ` [SPAM]Re: " Dongchun Zhu @ 2020-07-31 13:04 ` Sakari Ailus 0 siblings, 0 replies; 11+ messages in thread From: Sakari Ailus @ 2020-07-31 13:04 UTC (permalink / raw) To: Dongchun Zhu Cc: devicetree, drinkcat, srv_heupstream, Shengnan Wang (王圣男), linus.walleij, linux-mediatek, andriy.shevchenko, tfiga, bgolaszewski, Sj Huang (黃信璋), robh+dt, matthias.bgg, Louis Kuo (郭德寧), bingbu.cao, mchehab, Erin Lo (羅雅齡), linux-arm-kernel, linux-media Dongchun, On Fri, Jul 31, 2020 at 10:44:42AM +0800, Dongchun Zhu wrote: > Hi Sakari, > > On Thu, 2020-07-30 at 19:39 +0300, Sakari Ailus wrote: > > Dongchun, > > > > On Thu, Jul 02, 2020 at 07:06:05PM +0800, Dongchun Zhu wrote: > > > Hi Sakari, > > > > > > Sorry I just sent email using outlook where default format is HTML, now > > > I use evolution, one Linux mail client that I used to send upstream > > > patch previously. > > > > > > On Thu, 2020-07-02 at 08:34 +0300, Sakari Ailus wrote: > > > > Dongchun, > > > > > > > > Please don't send HTML e-mail to Linux kernel related mailing lists. > > > > > > > > On Thu, Jul 02, 2020 at 03:48:56AM +0000, Dongchun Zhu (朱东春) wrote: > > > > > Hi Sakari, > > > > > > > > > > Sorry to bother you again, but I am so confused about the questions you raised. > > > > > I just synced mainline: 5.8-rc3 tarball from https://www.kernel.org/, on which I ran the git am <patch> command. > > > > > The patch-applying process shows no error. > > > > > -----------------8<------------------- > > > > > [mtk15013@mtkslt307 linux]$git apply --check media-i2c-Add-support-for-DW9768-VCM.patch > > > > > [mtk15013@mtkslt307 linux]$git am media-i2c-Add-support-for-DW9768-VCM.patch > > > > > Applying: media: dt-bindings: media: i2c: Document DW9768 bindings > > > > > Applying: media: i2c: dw9768: Add DW9768 VCM driver > > > > > -----------------8<------------------- > > > > > > > > > > On the other hand, I also compared dongwoon,dw9768.yaml file with other media device dt-bindings(like imx219.yaml and ov8856.yaml). > > > > > It seems there are no apparent differences between them. > > > > > Especially, the sentence '# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)' shall be common. > > > > > I dunno why here dongwoon,dw9768.yaml reports trailing whitespace warnings while ov8856.yaml is silent. > > > > > > > > > > For the patch failed on MAINTAINERS, I am still curious what's wrong. > > > > > In fact, I locally have run parse-maintainers.pl script to check MAINTAINERS file before submitting patch. > > > > > The result also reports no errors. > > > > > -----------------8<------------------- > > > > > [mtk15013@mtkslt307 linux]$perl scripts/parse-maintainers.pl > > > > > [mtk15013@mtkslt307 linux]$ls > > > > > -----------------8<------------------- > > > > > > > > > > As to Base64 encoding, I checked each patch file again. They are all encoded in UTF-8. > > > > > As https://www.base64encode.org/ says, for an example, '77' in ASCII format would be changed to 'T' in Based64-encoded format. > > > > > This means there shall be messy code if we adpoting Based64-encoded format. > > > > > But I cannot see garbled messages in the current patches. > > > > > > > > > > The DW9768 serials-patch is attached. > > > > > @Tomasz @Andy @Rob could anyone help try to see whether the patch can be cherry-picked on Linux master branch or not? > > > > > Patchwork link: > > > > > https://patchwork.kernel.org/cover/11633291/ > > > > > > > > Both of the patches appear to contain only ASCII characters. > > > > > > > > I did some research on this. It seems that the base64 encoded message body > > > > does have carriage returns, in both cases. Git am does not attempt to > > > > remove them in that case, but Patchwork does. Hence the files are fine if > > > > you download them from Patchwork --- where the mbox files have neither > > > > carriage returns nor base64 encoding. > > > > > > > > What does the file command say about the patch files produced by git > > > > format-patch? My guess is that something in between your local computer and > > > > LMML (and other mail servers) base64 encodes the message body. But where > > > > are the carriage returns added? Nevertheless they seem to be added before > > > > the base64 conversion. > > > > > > > > > > Hm... I used the file command to check the diff patch generated from git > > > format-patch and that downloaded from Patchwork, they are both ASCII > > > text. > > > > That's because Patchwork appears to be removing the carriage returns. git > > does not if the content is base64 encoded. > > > > Your e-mail setup simply appears to be broken. I'd suggest trying to send > > the patches encoded in base64 as a workaround. git send-email uses > > sendemail.transferEncoding configuration option for this. > > > > I checked my local git configuration by using "git config --list", it > seems the "sendemail.transferEncoding" configuration variable is not > set, also "git send-email --transfer-encoding" is not set when > submitting patch. > > From my understanding, if both the option "--transfer-encoding=xxx" and > the configuration value "sendemail.transferEncoding" are unspecified, > the transfer encoding to be used to send the message over SMTP may be > "auto". > > Did you mean doing an experiment by enabling "base64" config for > transfer encoding as below? > "git config --global sendemail.transferEncoding base64" or > "git send-email --transfer-encoding=base64" Please try that. Alternatively you could try having your mail servers fixed. -- Kind regards, Sakari Ailus _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel ^ permalink raw reply [flat|nested] 11+ messages in thread
end of thread, other threads:[~2020-07-31 13:07 UTC | newest]
Thread overview: 11+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2020-06-30 6:22 [PATCH V9 0/2] media: i2c: Add support for DW9768 VCM Dongchun Zhu
2020-06-30 6:22 ` [PATCH V9 1/2] media: dt-bindings: media: i2c: Document DW9768 bindings Dongchun Zhu
2020-06-30 6:22 ` [PATCH V9 2/2] media: i2c: dw9768: Add DW9768 VCM driver Dongchun Zhu
2020-06-30 16:57 ` Tomasz Figa
2020-07-01 9:16 ` [PATCH V9 0/2] media: i2c: Add support for DW9768 VCM Sakari Ailus
[not found] ` <bf610d1b13c74656b2ffeeb9cc2a96ac@MTKMBS31N1.mediatek.inc>
[not found] ` <20200701134416.GQ16711@paasikivi.fi.intel.com>
[not found] ` <e55e7b405a084a0298cd839c05b52c79@MTKMBS31N1.mediatek.inc>
2020-07-02 5:10 ` Cao, Bingbu
2020-07-02 5:34 ` Sakari Ailus
2020-07-02 11:06 ` Dongchun Zhu
2020-07-30 16:39 ` Sakari Ailus
2020-07-31 2:44 ` [SPAM]Re: " Dongchun Zhu
2020-07-31 13:04 ` Sakari Ailus
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for NNTP newsgroup(s).