[PATCH RFC v2 0/2] max77693-led driver
Those two patches add max77693-led driver with device tree support. Driver is exposed to user space as a V4L2 flash subdevice. This subdevice should be registered by V4L2 driver of the camera device. Changes for v2 are described in patch 2/2, thanks for review to Sylwester. Additionally I have inserted missing description of the patch 1/2. I have also added e-mail recipients according to MAINTENANCE file. Regards Andrzej -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH RFC v2 2/2] media: added max77693-led driver
The patch adds led-flash support to Maxim max77693 chipset.
Device is exposed to user space as a V4L2 subdevice.
It can be controlled via V4L2 controls interface.
Device supports up to two leds which can work in
flash and torch mode. Leds can be triggered externally or
by software.
Signed-off-by: Andrzej Hajda
Reviewed-by: Sylwester Nawrocki
Signed-off-by: Kyungmin Park
---
Changes for v2:
- kzalloc replaced by devm_kzalloc
- corrected cleanup code on probe fail
- simplified clamp routine
- cosmetic changes
---
Documentation/devicetree/bindings/mfd/max77693.txt | 77 +++
drivers/media/i2c/Kconfig |8 +
drivers/media/i2c/Makefile |1 +
drivers/media/i2c/max77693-led.c | 645
drivers/mfd/max77693.c | 55 +-
include/linux/mfd/max77693.h | 33 +-
6 files changed, 799 insertions(+), 20 deletions(-)
create mode 100644 Documentation/devicetree/bindings/mfd/max77693.txt
create mode 100644 drivers/media/i2c/max77693-led.c
diff --git a/Documentation/devicetree/bindings/mfd/max77693.txt
b/Documentation/devicetree/bindings/mfd/max77693.txt
new file mode 100644
index 000..a80397c
--- /dev/null
+++ b/Documentation/devicetree/bindings/mfd/max77693.txt
@@ -0,0 +1,77 @@
+Maxim MAX77693 multi-function device
+
+MAX77686 is a Mulitifunction device with the following submodules:
+- PMIC,
+- Charger,
+- LED,
+- MUIC,
+- HAPTIC.
+
+It is interfaced to host controller using i2c.
+This document describes the bindings for the mfd device and the LED submodule.
+
+Required properties:
+- compatible : Must be "maxim,max77693".
+- reg : Specifies the i2c slave address of PMIC block.
+- interrupts : This i2c device has an IRQ line connected to the main SoC.
+- interrupt-parent : The parent interrupt controller.
+
+Optional properties:
+- wakeup-source : Indicates if the device can wakeup the system from the sleep
+ state.
+
+Optional node:
+- led-flash : The LED submodule device node.
+
+Required properties of "led-flash" node:
+- compatible : Must be "maxim,max77693-led"
+
+Optional properties of "led-flash" node:
+- maxim,iout : Array of four intensities in microamps of the current
+ in order: flash1, flash2, torch1, torch2.
+ Range:
+ flash - 15625 - 100,
+ torch - 15625 - 25.
+- maxim,trigger : Array of flags indicating which trigger can activate given
led
+ in order: flash1, flash2, torch1, torch2.
+ Possible flag values (can be combined):
+ 1 - flash pin of the chip,
+ 2 - torch pin of the chip,
+ 4 - software via I2C command.
+- maxim,trigger-type : Array of trigger types in order: flash, torch.
+ Possible trigger types:
+ 0 - Rising edge of the signal triggers the flash/torch,
+ 1 - Signal level controls duration of the flash/torch.
+- maxim,timeout : Array of timeouts in microseconds after which leds are
+ turned off in order: flash, torch.
+ Range:
+ flash: 62500 - 100,
+ torch: 0 (no timeout) - 15728000.
+- maxim,boost-mode : Array of the flash boost modes in order: flash1, flash2.
+ Possible values:
+ 0 - no boost,
+ 1 - adaptive mode,
+ 2 - fixed mode.
+- maxim,boost-vout : Output voltage of the boost module in milivolts.
+- maxim,low-vsys : Low input voltage level in milivolts. Flash is not fired
+ if chip estimates that system voltage could drop below this level due
+ to flash power consumption.
+
+Example:
+max77693@66 {
+ compatible = "maxim,max77693";
+ reg = <0x66>;
+ interrupt-parent = <&gpx1>;
+ interrupts = <5 0>;
+ wakeup-source;
+ led_flash: led-flash {
+ compatible = "maxim,max77693-led";
+ maxim,iout = <50 50 25 25>;
+ maxim,trigger = <5 5 6 0>;
+ maxim,trigger-type = <0 1>;
+ maxim,timeout = <50 0>;
+ maxim,boost-mode = <1 1>;
+ maxim,boost-vout = <5000>;
+ maxim,low-vsys = <2400>;
+ };
+};
diff --git a/drivers/media/i2c/Kconfig b/drivers/media/i2c/Kconfig
index 7b771ba..b72d4a1 100644
--- a/drivers/media/i2c/Kconfig
+++ b/drivers/media/i2c/Kconfig
@@ -522,6 +522,14 @@ config VIDEO_AS3645A
This is a driver for the AS3645A and LM3555 flash controllers. It has
build in control for flash, torch and indicator LEDs.
+config VIDEO_MAX77693_LED
+ tristate "MAX77693 led-flash driver support"
+ depends on MFD_MAX77693 && VIDEO_V4L2 && MEDIA_CONTROLLER
+ depends on MEDIA_CAMERA_SUPPORT
+ ---help---
+ This i
[PATCH RFC v2 1/2] max77693: added device tree support
max77693 mfd main device uses only wakeup field
from max77693_platform_data. This field is mapped
to wakeup-source property in device tree.
Device tree bindings doc will be added in max77693-led patch.
Signed-off-by: Andrzej Hajda
Reviewed-by: Sylwester Nawrocki
Signed-off-by: Kyungmin Park
---
drivers/mfd/max77693.c | 40 +---
1 file changed, 33 insertions(+), 7 deletions(-)
diff --git a/drivers/mfd/max77693.c b/drivers/mfd/max77693.c
index cc5155e..46223da 100644
--- a/drivers/mfd/max77693.c
+++ b/drivers/mfd/max77693.c
@@ -106,11 +106,30 @@ static const struct regmap_config max77693_regmap_config
= {
.max_register = MAX77693_PMIC_REG_END,
};
+static int max77693_get_platform_data(struct max77693_dev *max77693,
+ struct device *dev)
+{
+ struct device_node *node = dev->of_node;
+ struct max77693_platform_data *pdata = dev->platform_data;
+
+ if (node) {
+ max77693->wakeup = of_property_read_bool(node, "wakeup-source");
+ return 0;
+ }
+
+ if (pdata) {
+ max77693->wakeup = pdata->wakeup;
+ return 0;
+ }
+
+ dev_err(dev, "No platform data found.\n");
+ return -EINVAL;
+}
+
static int max77693_i2c_probe(struct i2c_client *i2c,
const struct i2c_device_id *id)
{
struct max77693_dev *max77693;
- struct max77693_platform_data *pdata = i2c->dev.platform_data;
u8 reg_data;
int ret = 0;
@@ -119,6 +138,10 @@ static int max77693_i2c_probe(struct i2c_client *i2c,
if (max77693 == NULL)
return -ENOMEM;
+ ret = max77693_get_platform_data(max77693, &i2c->dev);
+ if (ret < 0)
+ return ret;
+
max77693->regmap = devm_regmap_init_i2c(i2c, &max77693_regmap_config);
if (IS_ERR(max77693->regmap)) {
ret = PTR_ERR(max77693->regmap);
@@ -133,11 +156,6 @@ static int max77693_i2c_probe(struct i2c_client *i2c,
max77693->irq = i2c->irq;
max77693->type = id->driver_data;
- if (!pdata)
- goto err_regmap;
-
- max77693->wakeup = pdata->wakeup;
-
if (max77693_read_reg(max77693->regmap,
MAX77693_PMIC_REG_PMIC_ID2, ®_data) < 0) {
dev_err(max77693->dev, "device not found on this channel\n");
@@ -177,7 +195,7 @@ static int max77693_i2c_probe(struct i2c_client *i2c,
if (ret < 0)
goto err_mfd;
- device_init_wakeup(max77693->dev, pdata->wakeup);
+ device_init_wakeup(max77693->dev, max77693->wakeup);
return ret;
@@ -233,11 +251,19 @@ static const struct dev_pm_ops max77693_pm = {
.resume = max77693_resume,
};
+#ifdef CONFIG_OF
+static struct of_device_id max77693_dt_match[] = {
+ {.compatible = "maxim,max77693"},
+ {},
+};
+#endif
+
static struct i2c_driver max77693_i2c_driver = {
.driver = {
.name = "max77693",
.owner = THIS_MODULE,
.pm = &max77693_pm,
+ .of_match_table = of_match_ptr(max77693_dt_match),
},
.probe = max77693_i2c_probe,
.remove = max77693_i2c_remove,
--
1.7.10.4
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v3 1/2] max77693: remove device wakeup from driver
On 08/21/2013 06:53 PM, Andrzej Hajda wrote:
> The patch removes wakeup related code from
> the driver and plaftorm data - it is already
> handled by i2c core using I2C_CLIENT_WAKE flag
> from struct i2c_board_info. As a result MFD
> itself do not requires platform data.
>
> Signed-off-by: Andrzej Hajda
> Signed-off-by: Kyungmin Park
> ---
> drivers/mfd/max77693.c | 10 --
> include/linux/mfd/max77693-private.h | 1 -
> include/linux/mfd/max77693.h | 2 --
> 3 files changed, 13 deletions(-)
>
> diff --git a/drivers/mfd/max77693.c b/drivers/mfd/max77693.c
> index 9e60fed..27f5da3 100644
> --- a/drivers/mfd/max77693.c
> +++ b/drivers/mfd/max77693.c
> @@ -110,15 +110,9 @@ static int max77693_i2c_probe(struct i2c_client *i2c,
> const struct i2c_device_id *id)
> {
> struct max77693_dev *max77693;
> - struct max77693_platform_data *pdata = i2c->dev.platform_data;
> u8 reg_data;
> int ret = 0;
>
> - if (!pdata) {
> - dev_err(&i2c->dev, "No platform data found.\n");
> - return -EINVAL;
> - }
> -
> max77693 = devm_kzalloc(&i2c->dev,
> sizeof(struct max77693_dev), GFP_KERNEL);
> if (max77693 == NULL)
> @@ -138,8 +132,6 @@ static int max77693_i2c_probe(struct i2c_client *i2c,
> return ret;
> }
>
> - max77693->wakeup = pdata->wakeup;
> -
> ret = max77693_read_reg(max77693->regmap, MAX77693_PMIC_REG_PMIC_ID2,
> ®_data);
> if (ret < 0) {
> @@ -179,8 +171,6 @@ static int max77693_i2c_probe(struct i2c_client *i2c,
> if (ret < 0)
> goto err_mfd;
>
> - device_init_wakeup(max77693->dev, pdata->wakeup);
> -
> return ret;
>
> err_mfd:
> diff --git a/include/linux/mfd/max77693-private.h
> b/include/linux/mfd/max77693-private.h
> index 244fb0d..3e050b9 100644
> --- a/include/linux/mfd/max77693-private.h
> +++ b/include/linux/mfd/max77693-private.h
> @@ -323,7 +323,6 @@ struct max77693_dev {
>
> int irq;
> int irq_gpio;
> - bool wakeup;
> struct mutex irqlock;
> int irq_masks_cur[MAX77693_IRQ_GROUP_NR];
> int irq_masks_cache[MAX77693_IRQ_GROUP_NR];
> diff --git a/include/linux/mfd/max77693.h b/include/linux/mfd/max77693.h
> index 676f0f3..3f3dc45 100644
> --- a/include/linux/mfd/max77693.h
> +++ b/include/linux/mfd/max77693.h
> @@ -64,8 +64,6 @@ struct max77693_muic_platform_data {
> };
>
> struct max77693_platform_data {
> - int wakeup;
> -
> /* regulator data */
> struct max77693_regulator_data *regulators;
> int num_regulators;
Ping.
Regards
Andrzej
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v3 2/2] max77693: added device tree support
On 08/21/2013 06:53 PM, Andrzej Hajda wrote:
> This patch adds only of_match_table.
> There are no device specific properties.
>
> Signed-off-by: Andrzej Hajda
> Reviewed-by: Sylwester Nawrocki
> Signed-off-by: Kyungmin Park
> ---
> drivers/mfd/max77693.c | 8
> 1 file changed, 8 insertions(+)
>
> diff --git a/drivers/mfd/max77693.c b/drivers/mfd/max77693.c
> index 27f5da3..e0b11a9 100644
> --- a/drivers/mfd/max77693.c
> +++ b/drivers/mfd/max77693.c
> @@ -225,11 +225,19 @@ static const struct dev_pm_ops max77693_pm = {
> .resume = max77693_resume,
> };
>
> +#ifdef CONFIG_OF
> +static struct of_device_id max77693_dt_match[] = {
> + {.compatible = "maxim,max77693"},
> + {},
> +};
> +#endif
> +
> static struct i2c_driver max77693_i2c_driver = {
> .driver = {
> .name = "max77693",
> .owner = THIS_MODULE,
> .pm = &max77693_pm,
> +.of_match_table = of_match_ptr(max77693_dt_match),
> },
> .probe = max77693_i2c_probe,
> .remove = max77693_i2c_remove,
Ping.
Regards
Andrzej
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH v4 2/2] max77693: added device tree support
This patch adds only of_match_table.
There are no device specific properties.
Signed-off-by: Andrzej Hajda
Reviewed-by: Sylwester Nawrocki
Signed-off-by: Kyungmin Park
---
Hi,
Spaces added.
Regards
Andrzej
---
drivers/mfd/max77693.c | 8
1 file changed, 8 insertions(+)
diff --git a/drivers/mfd/max77693.c b/drivers/mfd/max77693.c
index 27f5da3..e0b11a9 100644
--- a/drivers/mfd/max77693.c
+++ b/drivers/mfd/max77693.c
@@ -225,11 +225,19 @@ static const struct dev_pm_ops max77693_pm = {
.resume = max77693_resume,
};
+#ifdef CONFIG_OF
+static struct of_device_id max77693_dt_match[] = {
+ { .compatible = "maxim,max77693" },
+ {},
+};
+#endif
+
static struct i2c_driver max77693_i2c_driver = {
.driver = {
.name = "max77693",
.owner = THIS_MODULE,
.pm = &max77693_pm,
+ .of_match_table = of_match_ptr(max77693_dt_match),
},
.probe = max77693_i2c_probe,
.remove = max77693_i2c_remove,
--
1.8.1.2
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH RFC v2 1/2] max77693: added device tree support
Hi Lee, I have no response from Samuel regarding this patch. Could you take care of it, I can rebase it again if necessary. Regards Andrzej On 07/17/2013 09:45 AM, Andrzej Hajda wrote: > Hi Samuel, > > A while ago I have send rebased patch adding device-tree support for > max77693 as you asked: > https://patchwork.kernel.org/patch/2414341/ > > The patch is still not applied. Is there a reason for that or just an > omission? > > Regards > Andrzej > > On 04/08/2013 05:21 PM, Samuel Ortiz wrote: >> Hi Andrzej, >> >> On Tue, Feb 19, 2013 at 04:36:16PM +0100, Andrzej Hajda wrote: >>> max77693 mfd main device uses only wakeup field >>> from max77693_platform_data. This field is mapped >>> to wakeup-source property in device tree. >>> Device tree bindings doc will be added in max77693-led patch. >>> >>> Signed-off-by: Andrzej Hajda >>> Reviewed-by: Sylwester Nawrocki >>> Signed-off-by: Kyungmin Park >>> --- >>> drivers/mfd/max77693.c | 40 +--- >>> 1 file changed, 33 insertions(+), 7 deletions(-) >> This patch looks good to me, but doesn't apply to mfd-next. Would you mind >> rebasing it ? >> >> Cheers, >> Samuel. >> >> -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH RESEND] max77693: added device tree support
max77693 mfd main device uses only wakeup field
from max77693_platform_data. This field is mapped
to wakeup-source common property in device tree.
Signed-off-by: Andrzej Hajda
Reviewed-by: Sylwester Nawrocki
Signed-off-by: Kyungmin Park
---
Hi Lee,
This is the patch for max77693 DT support rebased onto v3.11-rc5.
Regards
Andrzej
---
Documentation/devicetree/bindings/mfd/max77693.txt | 2 +
drivers/mfd/max77693.c | 50 --
2 files changed, 39 insertions(+), 13 deletions(-)
diff --git a/Documentation/devicetree/bindings/mfd/max77693.txt
b/Documentation/devicetree/bindings/mfd/max77693.txt
index 11921cc..4138ad4 100644
--- a/Documentation/devicetree/bindings/mfd/max77693.txt
+++ b/Documentation/devicetree/bindings/mfd/max77693.txt
@@ -19,6 +19,8 @@ Required properties:
Optional properties:
- regulators : The regulators of max77693 have to be instantiated under subnod
named "regulators" using the following format.
+- wakeup-source : Indicates if the device can wakeup the system from the sleep
+ state.
regulators {
regualtor-compatible = ESAFEOUT1/ESAFEOUT2/CHARGER
diff --git a/drivers/mfd/max77693.c b/drivers/mfd/max77693.c
index 9e60fed..6045706 100644
--- a/drivers/mfd/max77693.c
+++ b/drivers/mfd/max77693.c
@@ -106,29 +106,41 @@ static const struct regmap_config max77693_regmap_config
= {
.max_register = MAX77693_PMIC_REG_END,
};
+static int max77693_get_platform_data(struct max77693_dev *max77693,
+ struct device *dev)
+{
+ struct device_node *node = dev->of_node;
+ struct max77693_platform_data *pdata = dev->platform_data;
+
+ if (node) {
+ max77693->wakeup = of_property_read_bool(node, "wakeup-source");
+ return 0;
+ }
+
+ if (pdata) {
+ max77693->wakeup = pdata->wakeup;
+ return 0;
+ }
+
+ dev_err(dev, "No platform data found.\n");
+ return -EINVAL;
+}
+
static int max77693_i2c_probe(struct i2c_client *i2c,
const struct i2c_device_id *id)
{
struct max77693_dev *max77693;
- struct max77693_platform_data *pdata = i2c->dev.platform_data;
u8 reg_data;
int ret = 0;
- if (!pdata) {
- dev_err(&i2c->dev, "No platform data found.\n");
- return -EINVAL;
- }
-
max77693 = devm_kzalloc(&i2c->dev,
sizeof(struct max77693_dev), GFP_KERNEL);
if (max77693 == NULL)
return -ENOMEM;
- i2c_set_clientdata(i2c, max77693);
- max77693->dev = &i2c->dev;
- max77693->i2c = i2c;
- max77693->irq = i2c->irq;
- max77693->type = id->driver_data;
+ ret = max77693_get_platform_data(max77693, &i2c->dev);
+ if (ret < 0)
+ return ret;
max77693->regmap = devm_regmap_init_i2c(i2c, &max77693_regmap_config);
if (IS_ERR(max77693->regmap)) {
@@ -138,7 +150,11 @@ static int max77693_i2c_probe(struct i2c_client *i2c,
return ret;
}
- max77693->wakeup = pdata->wakeup;
+ i2c_set_clientdata(i2c, max77693);
+ max77693->dev = &i2c->dev;
+ max77693->i2c = i2c;
+ max77693->irq = i2c->irq;
+ max77693->type = id->driver_data;
ret = max77693_read_reg(max77693->regmap, MAX77693_PMIC_REG_PMIC_ID2,
®_data);
@@ -179,7 +195,7 @@ static int max77693_i2c_probe(struct i2c_client *i2c,
if (ret < 0)
goto err_mfd;
- device_init_wakeup(max77693->dev, pdata->wakeup);
+ device_init_wakeup(max77693->dev, max77693->wakeup);
return ret;
@@ -235,11 +251,19 @@ static const struct dev_pm_ops max77693_pm = {
.resume = max77693_resume,
};
+#ifdef CONFIG_OF
+static struct of_device_id max77693_dt_match[] = {
+ {.compatible = "maxim,max77693"},
+ {},
+};
+#endif
+
static struct i2c_driver max77693_i2c_driver = {
.driver = {
.name = "max77693",
.owner = THIS_MODULE,
.pm = &max77693_pm,
+ .of_match_table = of_match_ptr(max77693_dt_match),
},
.probe = max77693_i2c_probe,
.remove = max77693_i2c_remove,
--
1.8.1.2
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH v2] max77693: added device tree support
max77693 mfd main device uses only wakeup field
from max77693_platform_data. This field is mapped
to wakeup-source common property in device tree.
Signed-off-by: Andrzej Hajda
Reviewed-by: Sylwester Nawrocki
Signed-off-by: Kyungmin Park
---
Hi Lee,
Thanks for the review.
Patch corrected according to your suggestion.
Regards
Andrzej
---
v2:
- platform data takes precedence over DT
---
Documentation/devicetree/bindings/mfd/max77693.txt | 2 +
drivers/mfd/max77693.c | 50 --
2 files changed, 39 insertions(+), 13 deletions(-)
diff --git a/Documentation/devicetree/bindings/mfd/max77693.txt
b/Documentation/devicetree/bindings/mfd/max77693.txt
index 11921cc..4138ad4 100644
--- a/Documentation/devicetree/bindings/mfd/max77693.txt
+++ b/Documentation/devicetree/bindings/mfd/max77693.txt
@@ -19,6 +19,8 @@ Required properties:
Optional properties:
- regulators : The regulators of max77693 have to be instantiated under subnod
named "regulators" using the following format.
+- wakeup-source : Indicates if the device can wakeup the system from the sleep
+ state.
regulators {
regualtor-compatible = ESAFEOUT1/ESAFEOUT2/CHARGER
diff --git a/drivers/mfd/max77693.c b/drivers/mfd/max77693.c
index 9e60fed..d85663d 100644
--- a/drivers/mfd/max77693.c
+++ b/drivers/mfd/max77693.c
@@ -106,29 +106,41 @@ static const struct regmap_config max77693_regmap_config
= {
.max_register = MAX77693_PMIC_REG_END,
};
+static int max77693_get_platform_data(struct max77693_dev *max77693,
+ struct device *dev)
+{
+ struct device_node *node = dev->of_node;
+ struct max77693_platform_data *pdata = dev->platform_data;
+
+ if (pdata) {
+ max77693->wakeup = pdata->wakeup;
+ return 0;
+ }
+
+ if (node) {
+ max77693->wakeup = of_property_read_bool(node, "wakeup-source");
+ return 0;
+ }
+
+ dev_err(dev, "No platform data found.\n");
+ return -EINVAL;
+}
+
static int max77693_i2c_probe(struct i2c_client *i2c,
const struct i2c_device_id *id)
{
struct max77693_dev *max77693;
- struct max77693_platform_data *pdata = i2c->dev.platform_data;
u8 reg_data;
int ret = 0;
- if (!pdata) {
- dev_err(&i2c->dev, "No platform data found.\n");
- return -EINVAL;
- }
-
max77693 = devm_kzalloc(&i2c->dev,
sizeof(struct max77693_dev), GFP_KERNEL);
if (max77693 == NULL)
return -ENOMEM;
- i2c_set_clientdata(i2c, max77693);
- max77693->dev = &i2c->dev;
- max77693->i2c = i2c;
- max77693->irq = i2c->irq;
- max77693->type = id->driver_data;
+ ret = max77693_get_platform_data(max77693, &i2c->dev);
+ if (ret < 0)
+ return ret;
max77693->regmap = devm_regmap_init_i2c(i2c, &max77693_regmap_config);
if (IS_ERR(max77693->regmap)) {
@@ -138,7 +150,11 @@ static int max77693_i2c_probe(struct i2c_client *i2c,
return ret;
}
- max77693->wakeup = pdata->wakeup;
+ i2c_set_clientdata(i2c, max77693);
+ max77693->dev = &i2c->dev;
+ max77693->i2c = i2c;
+ max77693->irq = i2c->irq;
+ max77693->type = id->driver_data;
ret = max77693_read_reg(max77693->regmap, MAX77693_PMIC_REG_PMIC_ID2,
®_data);
@@ -179,7 +195,7 @@ static int max77693_i2c_probe(struct i2c_client *i2c,
if (ret < 0)
goto err_mfd;
- device_init_wakeup(max77693->dev, pdata->wakeup);
+ device_init_wakeup(max77693->dev, max77693->wakeup);
return ret;
@@ -235,11 +251,19 @@ static const struct dev_pm_ops max77693_pm = {
.resume = max77693_resume,
};
+#ifdef CONFIG_OF
+static struct of_device_id max77693_dt_match[] = {
+ {.compatible = "maxim,max77693"},
+ {},
+};
+#endif
+
static struct i2c_driver max77693_i2c_driver = {
.driver = {
.name = "max77693",
.owner = THIS_MODULE,
.pm = &max77693_pm,
+ .of_match_table = of_match_ptr(max77693_dt_match),
},
.probe = max77693_i2c_probe,
.remove = max77693_i2c_remove,
--
1.8.1.2
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH RFC v2 1/2] max77693: added device tree support
Hi Samuel, A while ago I have send rebased patch adding device-tree support for max77693 as you asked: https://patchwork.kernel.org/patch/2414341/ The patch is still not applied. Is there a reason for that or just an omission? Regards Andrzej On 04/08/2013 05:21 PM, Samuel Ortiz wrote: > Hi Andrzej, > > On Tue, Feb 19, 2013 at 04:36:16PM +0100, Andrzej Hajda wrote: >> max77693 mfd main device uses only wakeup field >> from max77693_platform_data. This field is mapped >> to wakeup-source property in device tree. >> Device tree bindings doc will be added in max77693-led patch. >> >> Signed-off-by: Andrzej Hajda >> Reviewed-by: Sylwester Nawrocki >> Signed-off-by: Kyungmin Park >> --- >> drivers/mfd/max77693.c | 40 +--- >> 1 file changed, 33 insertions(+), 7 deletions(-) > This patch looks good to me, but doesn't apply to mfd-next. Would you mind > rebasing it ? > > Cheers, > Samuel. > > -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v2] max77693: added device tree support
Hi, Thanks for the review. On 08/19/2013 11:18 PM, Stephen Warren wrote: > On 08/19/2013 05:40 AM, Andrzej Hajda wrote: >> max77693 mfd main device uses only wakeup field >> from max77693_platform_data. This field is mapped >> to wakeup-source common property in device tree. >> diff --git a/Documentation/devicetree/bindings/mfd/max77693.txt >> b/Documentation/devicetree/bindings/mfd/max77693.txt >> Optional properties: >> - regulators : The regulators of max77693 have to be instantiated under >> subnod >>named "regulators" using the following format. >> +- wakeup-source : Indicates if the device can wakeup the system from the >> sleep >> + state. > Does the property mean "can" or "should"? > > "Can" implies that the property means something about the HW. What > exactly does it mean; perhaps that some specific output pin of the chip > has been wired to an input IRQ/GPIO of the SoC or PMIC that (can) wake > up the system? If so, which pin, signal, ...? Also, doesn't this also > depend on the SoC itself supporting its input IRQ/GPIO as a wakeup > source, so isn't some co-ordination required between the SoC and chip, > such that this property doesn't mean "can wakeup the system", but simply > "a signal is routed to the SoC, so perhaps it can wakeup the system". > > "Should" implies policy, which probably shouldn't be represented in > device tree, since DT should describe the HW and not how it should be used. After short digging I have realized that "wakeup-source" property is already parsed by of_i2c_register_devices core function and it should not be parsed again by the driver itself. So I suppose the description of it can be removed from max77693 binding. Do you agree? Anyway I will prepare separate patch removing wakeup related code from probe and related field from max77693 platform_data - i2c_board_info::flag field should be used instead. > > Finally, if there was already a binding for max77693.txt, I don't think > the patch subject "added device tree support" is entirely accurate; this > change to the binding document seems to be more about adding a new > feature than adding DT support to the driver... > This patch really adds DT support to max77693 mfd driver :) The binding file which is already in kernel currently has no related code in the max77693 driver. I will add clarification in the commit message. Regards Andrzej -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH v3 2/2] max77693: added device tree support
This patch adds only of_match_table.
There are no device specific properties.
Signed-off-by: Andrzej Hajda
Reviewed-by: Sylwester Nawrocki
Signed-off-by: Kyungmin Park
---
drivers/mfd/max77693.c | 8
1 file changed, 8 insertions(+)
diff --git a/drivers/mfd/max77693.c b/drivers/mfd/max77693.c
index 27f5da3..e0b11a9 100644
--- a/drivers/mfd/max77693.c
+++ b/drivers/mfd/max77693.c
@@ -225,11 +225,19 @@ static const struct dev_pm_ops max77693_pm = {
.resume = max77693_resume,
};
+#ifdef CONFIG_OF
+static struct of_device_id max77693_dt_match[] = {
+ {.compatible = "maxim,max77693"},
+ {},
+};
+#endif
+
static struct i2c_driver max77693_i2c_driver = {
.driver = {
.name = "max77693",
.owner = THIS_MODULE,
.pm = &max77693_pm,
+ .of_match_table = of_match_ptr(max77693_dt_match),
},
.probe = max77693_i2c_probe,
.remove = max77693_i2c_remove,
--
1.8.1.2
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH v3 0/2] max77693: added device tree support
Hi, The first patch cleans up the driver from unneccesary wakeup handling. The second patch adds device tree support to the driver. Regards Andrzej Andrzej Hajda (2): max77693: remove device wakeup from driver max77693: added device tree support drivers/mfd/max77693.c | 18 -- include/linux/mfd/max77693-private.h | 1 - include/linux/mfd/max77693.h | 2 -- 3 files changed, 8 insertions(+), 13 deletions(-) -- 1.8.1.2 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH v3 1/2] max77693: remove device wakeup from driver
The patch removes wakeup related code from
the driver and plaftorm data - it is already
handled by i2c core using I2C_CLIENT_WAKE flag
from struct i2c_board_info. As a result MFD
itself do not requires platform data.
Signed-off-by: Andrzej Hajda
Signed-off-by: Kyungmin Park
---
drivers/mfd/max77693.c | 10 --
include/linux/mfd/max77693-private.h | 1 -
include/linux/mfd/max77693.h | 2 --
3 files changed, 13 deletions(-)
diff --git a/drivers/mfd/max77693.c b/drivers/mfd/max77693.c
index 9e60fed..27f5da3 100644
--- a/drivers/mfd/max77693.c
+++ b/drivers/mfd/max77693.c
@@ -110,15 +110,9 @@ static int max77693_i2c_probe(struct i2c_client *i2c,
const struct i2c_device_id *id)
{
struct max77693_dev *max77693;
- struct max77693_platform_data *pdata = i2c->dev.platform_data;
u8 reg_data;
int ret = 0;
- if (!pdata) {
- dev_err(&i2c->dev, "No platform data found.\n");
- return -EINVAL;
- }
-
max77693 = devm_kzalloc(&i2c->dev,
sizeof(struct max77693_dev), GFP_KERNEL);
if (max77693 == NULL)
@@ -138,8 +132,6 @@ static int max77693_i2c_probe(struct i2c_client *i2c,
return ret;
}
- max77693->wakeup = pdata->wakeup;
-
ret = max77693_read_reg(max77693->regmap, MAX77693_PMIC_REG_PMIC_ID2,
®_data);
if (ret < 0) {
@@ -179,8 +171,6 @@ static int max77693_i2c_probe(struct i2c_client *i2c,
if (ret < 0)
goto err_mfd;
- device_init_wakeup(max77693->dev, pdata->wakeup);
-
return ret;
err_mfd:
diff --git a/include/linux/mfd/max77693-private.h
b/include/linux/mfd/max77693-private.h
index 244fb0d..3e050b9 100644
--- a/include/linux/mfd/max77693-private.h
+++ b/include/linux/mfd/max77693-private.h
@@ -323,7 +323,6 @@ struct max77693_dev {
int irq;
int irq_gpio;
- bool wakeup;
struct mutex irqlock;
int irq_masks_cur[MAX77693_IRQ_GROUP_NR];
int irq_masks_cache[MAX77693_IRQ_GROUP_NR];
diff --git a/include/linux/mfd/max77693.h b/include/linux/mfd/max77693.h
index 676f0f3..3f3dc45 100644
--- a/include/linux/mfd/max77693.h
+++ b/include/linux/mfd/max77693.h
@@ -64,8 +64,6 @@ struct max77693_muic_platform_data {
};
struct max77693_platform_data {
- int wakeup;
-
/* regulator data */
struct max77693_regulator_data *regulators;
int num_regulators;
--
1.8.1.2
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH] regulator: fixed regulator_bulk_enable unwinding code
Unwinding code disables all successfully enabled regulators.
Error is logged for every failed regulator.
Signed-off-by: Andrzej Hajda
Signed-off-by: Kyungmin Park
---
drivers/regulator/core.c | 10 +++---
1 file changed, 7 insertions(+), 3 deletions(-)
diff --git a/drivers/regulator/core.c b/drivers/regulator/core.c
index 2785843..90af271 100644
--- a/drivers/regulator/core.c
+++ b/drivers/regulator/core.c
@@ -3032,9 +3032,13 @@ int regulator_bulk_enable(int num_consumers,
return 0;
err:
- pr_err("Failed to enable %s: %d\n", consumers[i].supply, ret);
- while (--i >= 0)
- regulator_disable(consumers[i].consumer);
+ for (i = 0; i < num_consumers; i++) {
+ if (consumers[i].ret < 0)
+ pr_err("Failed to enable %s: %d\n", consumers[i].supply,
+ consumers[i].ret);
+ else
+ regulator_disable(consumers[i].consumer);
+ }
return ret;
}
--
1.7.10.4
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH] max77693: added device tree support
max77693 mfd main device uses only wakeup field
from max77693_platform_data. This field is mapped
to wakeup-source common property in device tree.
Signed-off-by: Andrzej Hajda
Reviewed-by: Sylwester Nawrocki
Signed-off-by: Kyungmin Park
---
Hi Samuel,
This is "max77693: added device tree support" patch rebased to mfd-next/master.
I have added Documentation/devicetree/bindings/mfd/max77693.txt.
Thanks for the review.
Regards
Andrzej
Documentation/devicetree/bindings/mfd/max77693.txt | 31
drivers/mfd/max77693.c | 50 +++-
2 files changed, 68 insertions(+), 13 deletions(-)
create mode 100644 Documentation/devicetree/bindings/mfd/max77693.txt
diff --git a/Documentation/devicetree/bindings/mfd/max77693.txt
b/Documentation/devicetree/bindings/mfd/max77693.txt
new file mode 100644
index 000..a7213b7
--- /dev/null
+++ b/Documentation/devicetree/bindings/mfd/max77693.txt
@@ -0,0 +1,31 @@
+Maxim MAX77693 multi-function device
+
+MAX77686 is a Mulitifunction device with the following submodules:
+- PMIC,
+- Charger,
+- LED,
+- MUIC,
+- HAPTIC.
+
+It is interfaced to host controller using i2c.
+This document describes the bindings for the mfd device.
+
+Required properties:
+- compatible : Must be "maxim,max77693".
+- reg : Specifies the i2c slave address of PMIC block.
+- interrupts : This i2c device has an IRQ line connected to the main SoC.
+- interrupt-parent : The parent interrupt controller.
+
+Optional properties:
+- wakeup-source : Indicates if the device can wakeup the system from the sleep
+ state.
+
+Example:
+max77693@66 {
+ compatible = "maxim,max77693";
+ reg = <0x66>;
+ interrupt-parent = <&gpx1>;
+ interrupts = <5 0>;
+ wakeup-source;
+ };
+};
diff --git a/drivers/mfd/max77693.c b/drivers/mfd/max77693.c
index 9e60fed..6045706 100644
--- a/drivers/mfd/max77693.c
+++ b/drivers/mfd/max77693.c
@@ -106,29 +106,41 @@ static const struct regmap_config max77693_regmap_config
= {
.max_register = MAX77693_PMIC_REG_END,
};
+static int max77693_get_platform_data(struct max77693_dev *max77693,
+ struct device *dev)
+{
+ struct device_node *node = dev->of_node;
+ struct max77693_platform_data *pdata = dev->platform_data;
+
+ if (node) {
+ max77693->wakeup = of_property_read_bool(node, "wakeup-source");
+ return 0;
+ }
+
+ if (pdata) {
+ max77693->wakeup = pdata->wakeup;
+ return 0;
+ }
+
+ dev_err(dev, "No platform data found.\n");
+ return -EINVAL;
+}
+
static int max77693_i2c_probe(struct i2c_client *i2c,
const struct i2c_device_id *id)
{
struct max77693_dev *max77693;
- struct max77693_platform_data *pdata = i2c->dev.platform_data;
u8 reg_data;
int ret = 0;
- if (!pdata) {
- dev_err(&i2c->dev, "No platform data found.\n");
- return -EINVAL;
- }
-
max77693 = devm_kzalloc(&i2c->dev,
sizeof(struct max77693_dev), GFP_KERNEL);
if (max77693 == NULL)
return -ENOMEM;
- i2c_set_clientdata(i2c, max77693);
- max77693->dev = &i2c->dev;
- max77693->i2c = i2c;
- max77693->irq = i2c->irq;
- max77693->type = id->driver_data;
+ ret = max77693_get_platform_data(max77693, &i2c->dev);
+ if (ret < 0)
+ return ret;
max77693->regmap = devm_regmap_init_i2c(i2c, &max77693_regmap_config);
if (IS_ERR(max77693->regmap)) {
@@ -138,7 +150,11 @@ static int max77693_i2c_probe(struct i2c_client *i2c,
return ret;
}
- max77693->wakeup = pdata->wakeup;
+ i2c_set_clientdata(i2c, max77693);
+ max77693->dev = &i2c->dev;
+ max77693->i2c = i2c;
+ max77693->irq = i2c->irq;
+ max77693->type = id->driver_data;
ret = max77693_read_reg(max77693->regmap, MAX77693_PMIC_REG_PMIC_ID2,
®_data);
@@ -179,7 +195,7 @@ static int max77693_i2c_probe(struct i2c_client *i2c,
if (ret < 0)
goto err_mfd;
- device_init_wakeup(max77693->dev, pdata->wakeup);
+ device_init_wakeup(max77693->dev, max77693->wakeup);
return ret;
@@ -235,11 +251,19 @@ static const struct dev_pm_ops max77693_pm = {
.resume = max77693_resume,
};
+#ifdef CONFIG_OF
+static struct of_device_id max77693_dt_match[] = {
+ {.compatible = "maxim,max77693"},
+ {},
+};
+#endif
+
static struct i2c_driver max77693_i2c_driver = {
.driver = {
.name = "max77693",
.owner =
Re: [PATCH] drm/exynos: mark exynos_dp_crtc_clock_enable() static
On 18.09.2016 15:58, Baoyou Xie wrote: > We get 1 warning when building kernel with W=1: > drivers/gpu/drm/exynos/exynos_dp.c:46:5: warning: no previous prototype for > 'exynos_dp_crtc_clock_enable' [-Wmissing-prototypes] > > In fact, this function is only used in the file in which it is > declared and don't need a declaration, but can be made static. > So this patch marks it 'static'. > > Signed-off-by: Baoyou Xie Reviewed-by: Andrzej Hajda -- Regards Andrzej
Re: [PATCH v4] ARM: dts: exynos: Enable HDMI for Arndale Octa board
On 08/31/2016 08:08 AM, Milo Kim wrote:
> * GPIO for HDMI hot plug detect
> GPX3_7 is used. The HPD awareness is done when the GPIO is active high.
>
> * Enable HDMI block in Exynos5420
> HDMI VDD and PLL consume 1.0V LDO6 (PVDD_ANAIP_1V0) and HDMI oscillator
> requires 1.8V LDO7 (PVDD_ANAIP_1V8).
>
> * Support HDMI display data channel
> I2C #2 is assigned for the HDMI DDC. It enables the EDID access.
>
> Cc: Kukjin Kim
> Cc: Krzysztof Kozlowski
> Cc: Rob Herring
> Cc: linux-arm-ker...@lists.infradead.org
> Cc: linux-samsung-...@vger.kernel.org
> Cc: linux-kernel@vger.kernel.org
> Signed-off-by: Milo Kim
Reviewed-by: Andrzej Hajda
--
Regards
Andrzej
> ---
> arch/arm/boot/dts/exynos5420-arndale-octa.dts | 13 +
> 1 file changed, 13 insertions(+)
>
> diff --git a/arch/arm/boot/dts/exynos5420-arndale-octa.dts
> b/arch/arm/boot/dts/exynos5420-arndale-octa.dts
> index 39a3b81..d2ad48e 100644
> --- a/arch/arm/boot/dts/exynos5420-arndale-octa.dts
> +++ b/arch/arm/boot/dts/exynos5420-arndale-octa.dts
> @@ -70,6 +70,15 @@
> status = "disabled";
> };
>
> +&hdmi {
> + hpd-gpios = <&gpx3 7 GPIO_ACTIVE_HIGH>;
> + vdd_osc-supply = <&ldo7_reg>;
> + vdd_pll-supply = <&ldo6_reg>;
> + vdd-supply = <&ldo6_reg>;
> + ddc = <&i2c_2>;
> + status = "okay";
> +};
> +
> &hsi2c_4 {
> status = "okay";
>
> @@ -347,6 +356,10 @@
> };
> };
>
> +&i2c_2 {
> + status = "okay";
> +};
> +
> &mmc_0 {
> status = "okay";
> broken-cd;
Re: [PATCH v4 1/3] gpu: drm: exynos_hdmi: Move DDC logic into single function
On 08/31/2016 08:14 AM, Milo Kim wrote: > Paring DT properties and getting the I2C adapter in one function. > > Cc: Inki Dae > Cc: Joonyoung Shim > Cc: Seung-Woo Kim > Cc: Kyungmin Park > Cc: dri-de...@lists.freedesktop.org > Cc: linux-kernel@vger.kernel.org > Signed-off-by: Milo Kim > Reviewed-by: Andrzej Hajda -- Regards Andrzej
Re: [PATCH v4 2/3] gpu: drm: exynos_hdmi: Move PHY logic into single function
On 08/31/2016 08:14 AM, Milo Kim wrote: > Paring DT properties and getting PHY IO (memory mapped or I2C) in one > function. > > Cc: Inki Dae > Cc: Joonyoung Shim > Cc: Seung-Woo Kim > Cc: Kyungmin Park > Cc: dri-de...@lists.freedesktop.org > Cc: linux-kernel@vger.kernel.org > Signed-off-by: Milo Kim Reviewed-by: Andrzej Hajda -- Regards Andrzej
Re: [PATCH RFC] ARM: dts: samsung: add rga-lvds panel in itop elite
Hi,
On 08/30/2016 12:50 AM, Randy Li wrote:
> It is actually a lvds panel connected through a rga-lvds bridge.
> But I really have no idea about what does a port mean in fimd node.
>
> Also how should I configure this panel size? I think the i2c found
> on the panel schematic, but it more likely to be used a touch screen
> touth. Also the touch screen is not supported in currently driver.
>
> Signed-off-by: Randy Li
> ---
> arch/arm/boot/dts/exynos4412-itop-elite.dts | 35
> ++---
> 1 file changed, 32 insertions(+), 3 deletions(-)
>
> diff --git a/arch/arm/boot/dts/exynos4412-itop-elite.dts
> b/arch/arm/boot/dts/exynos4412-itop-elite.dts
> index e1cda54..2d67385 100644
> --- a/arch/arm/boot/dts/exynos4412-itop-elite.dts
> +++ b/arch/arm/boot/dts/exynos4412-itop-elite.dts
> @@ -139,6 +139,20 @@
> assigned-clocks = <&clock CLK_MOUT_CAM0>;
> assigned-clock-parents = <&clock CLK_XUSBXTI>;
> };
> +
> + vcc_sys_lcd: sys-lcd {
> + compatible = "regulator-fixed";
> + regulator-name = "vcc_5v";
> + regulator-min-microvolt = <500>;
> + regulator-max-microvolt = <500>;
> + gpio = <&gpl0 4 GPIO_ACTIVE_HIGH>;
> + };
> +
> + panel: panel {
> + ddc-i2c-bus = <&i2c_3>;
> + power-supply = <&vcc_sys_lcd>;
> + enable-gpios = <&gpl0 2 GPIO_ACTIVE_HIGH>;
> + };
Panel has no compatible string, which driver will handle this node?
Regards
Andrzej
> };
>
> &pinctrl_1 {
> @@ -221,9 +235,6 @@
> };
>
> &pwm {
> - pinctrl-0 = <&pwm1_out>;
> - pinctrl-names = "default";
> - samsung,pwm-outputs = <1>;
> status = "okay";
> };
>
> @@ -239,3 +250,21 @@
> assigned-clock-parents = <&clock CLK_MOUT_MPLL_USER_T>;
> assigned-clock-rates = <0>, <17600>;
> };
> +
> +&i2c_3 {
> + status = "okay";
> +};
> +
> +&fimd {
> + pinctrl-0 = <&lcd_clk &lcd_data24 &pwm1_out>;
> + pinctrl-names = "default";
> + status = "okay";
> + #address-cells = <1>;
> + #size-cells = <0>;
> + port@0 {
> + reg = <0>;
> + rga_lvds: endpoint {
> + remote-endpoint = <&panel>;
> + };
> + };
> +};
Re: [PATCH RFC] ARM: dts: samsung: add rga-lvds panel in itop elite
On 08/31/2016 07:55 PM, ayaka wrote:
>
> On 08/31/2016 08:30 PM, Andrzej Hajda wrote:
>> Hi,
>>
>>
>> On 08/30/2016 12:50 AM, Randy Li wrote:
>>> It is actually a lvds panel connected through a rga-lvds bridge.
>>> But I really have no idea about what does a port mean in fimd node.
>>>
>>> Also how should I configure this panel size? I think the i2c found
>>> on the panel schematic, but it more likely to be used a touch screen
>>> touth. Also the touch screen is not supported in currently driver.
>>>
>>> Signed-off-by: Randy Li
>>> ---
>>> arch/arm/boot/dts/exynos4412-itop-elite.dts | 35
>>> ++---
>>> 1 file changed, 32 insertions(+), 3 deletions(-)
>>>
>>> diff --git a/arch/arm/boot/dts/exynos4412-itop-elite.dts
>>> b/arch/arm/boot/dts/exynos4412-itop-elite.dts
>>> index e1cda54..2d67385 100644
>>> --- a/arch/arm/boot/dts/exynos4412-itop-elite.dts
>>> +++ b/arch/arm/boot/dts/exynos4412-itop-elite.dts
>>> @@ -139,6 +139,20 @@
>>> assigned-clocks = <&clock CLK_MOUT_CAM0>;
>>> assigned-clock-parents = <&clock CLK_XUSBXTI>;
>>> };
>>> +
>>> + vcc_sys_lcd: sys-lcd {
>>> + compatible = "regulator-fixed";
>>> + regulator-name = "vcc_5v";
>>> + regulator-min-microvolt = <500>;
>>> + regulator-max-microvolt = <500>;
>>> + gpio = <&gpl0 4 GPIO_ACTIVE_HIGH>;
>>> + };
>>> +
>>> + panel: panel {
>>> + ddc-i2c-bus = <&i2c_3>;
>>> + power-supply = <&vcc_sys_lcd>;
>>> + enable-gpios = <&gpl0 2 GPIO_ACTIVE_HIGH>;
>>> + };
>> Panel has no compatible string, which driver will handle this node?
> The problem is that, it is panel not supported by kernel.
For simple panel you can take a look at [1][2]. Ie. if the panel needs
only power supply and enable gpio, you just need to add few lines to [2].
[1]: Documentation/devicetree/bindings/display/panel/simple-panel.txt
[2]: drivers/gpu/drm/panel/panel-simple.c
> Is it possible
> to support without adding a new driver for it ? I know there is a
> simple-dpi for MIPI, but what is for parallel video or lvds?
simple-dpi is just parallel output. LVDS is not supported by Exynos4412 but
boards usually have RGB/LVDS bridge for such panels, I have no access to
itop
board schematics, but I suppose it has such bridge. LVDS bridges often
do not
need Linux driver, so from developer point of view LVDS panels with such
bridge
are handled the same way as RGB panels. Example fimd bindings for RGB panels
are in [3].
[3]: arch/arm/boot/dts/exynos4210-universal_c210.dts
>> Regards
>> Andrzej
> The other problem is that I don't how to configure the display-times,
> the datasheet for CLAA070WP03XG only talk about total time, active time
> and blank time for both Horizontal an Vertical time. Does it mean the
> front-porch and sync-len for horizontal and vertical are zero ?
You can look at vendor's code. Or just experiment with different values.
The equation is: total=active+back_porch+blank+front_porch.
So if htotal=864, hactive=800, hblank=64, then hporches are 0.
In case of vtotal=1288, vactive=1200, vblank=8 you have left 80 for porches,
you can try to split them equally for front and back for starters.
Regards
Andrzej
>
> + ports {
> + #address-cells = <1>;
> + #size-cells = <0>;
> + port@3 {
> + reg = <3>;
> + rga_lvds: endpoint {
> + remote-endpoint = <&panel>;
> + };
> + };
> + };
> +
> + panel: panel@0 {
> + compatible = "panel-simple";
> +
> + power-supply = <&vcc_sys_lcd>;
> + enable-gpios = <&gpl0 2 GPIO_ACTIVE_HIGH>;
> + display-timings {
> + timing-0 {
> + clock-frequency = <6677>;
> + hactive = <800>;
> + vactive = <1280>;
> + hfront-porch = <0>;
> + hback-porch = <64>;
> + hsync-len = <0>;
> + vfront-porch = <0>;
> + vback-porch = <8>;
> + vsync-len = <0>;
> + };
> + };
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc"
> in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
>
Re: [PATCH RFC] ARM: dts: samsung: add rga-lvds panel in itop elite
On 09/01/2016 10:24 AM, Ayaka wrote:
>
> 從我的 iPad 傳送
> Thank you
>> Andrzej Hajda 於 2016年9月1日 下午3:04 寫道：
>>
>>> On 08/31/2016 07:55 PM, ayaka wrote:
>>>
>>>> On 08/31/2016 08:30 PM, Andrzej Hajda wrote:
>>>> Hi,
>>>>
>>>>
>>>>> On 08/30/2016 12:50 AM, Randy Li wrote:
>>>>> It is actually a lvds panel connected through a rga-lvds bridge.
>>>>> But I really have no idea about what does a port mean in fimd node.
>>>>>
>>>>> Also how should I configure this panel size? I think the i2c found
>>>>> on the panel schematic, but it more likely to be used a touch screen
>>>>> touth. Also the touch screen is not supported in currently driver.
>>>>>
>>>>> Signed-off-by: Randy Li
>>>>> ---
>>>>> arch/arm/boot/dts/exynos4412-itop-elite.dts | 35
>>>>> ++---
>>>>> 1 file changed, 32 insertions(+), 3 deletions(-)
>>>>>
>>>>> diff --git a/arch/arm/boot/dts/exynos4412-itop-elite.dts
>>>>> b/arch/arm/boot/dts/exynos4412-itop-elite.dts
>>>>> index e1cda54..2d67385 100644
>>>>> --- a/arch/arm/boot/dts/exynos4412-itop-elite.dts
>>>>> +++ b/arch/arm/boot/dts/exynos4412-itop-elite.dts
>>>>> @@ -139,6 +139,20 @@
>>>>> assigned-clocks = <&clock CLK_MOUT_CAM0>;
>>>>> assigned-clock-parents = <&clock CLK_XUSBXTI>;
>>>>> };
>>>>> +
>>>>> +vcc_sys_lcd: sys-lcd {
>>>>> +compatible = "regulator-fixed";
>>>>> +regulator-name = "vcc_5v";
>>>>> +regulator-min-microvolt = <500>;
>>>>> +regulator-max-microvolt = <500>;
>>>>> +gpio = <&gpl0 4 GPIO_ACTIVE_HIGH>;
>>>>> +};
>>>>> +
>>>>> +panel: panel {
>>>>> +ddc-i2c-bus = <&i2c_3>;
>>>>> +power-supply = <&vcc_sys_lcd>;
>>>>> +enable-gpios = <&gpl0 2 GPIO_ACTIVE_HIGH>;
>>>>> +};
>>>> Panel has no compatible string, which driver will handle this node?
>>> The problem is that, it is panel not supported by kernel.
>> For simple panel you can take a look at [1][2]. Ie. if the panel needs
>> only power supply and enable gpio, you just need to add few lines to [2].
> But I still don't know which compatible string I should use, "simple-dpi" ?
Have you looked at [2]?
Or just run command in kernel git tree:
git log -p drivers/gpu/drm/panel/panel-simple.c
To add support for specific panel you add:
1. display mode(s),
2. panel description,
3. panel compatible string.
And then you use this compatible in dts.
To have patches accepted in mainline you should add bindings
for the panel, check history of dri-devel to see how to do it.
>>
>> [1]: Documentation/devicetree/bindings/display/panel/simple-panel.txt
>> [2]: drivers/gpu/drm/panel/panel-simple.c
>>
>>> Is it possible
>>> to support without adding a new driver for it ? I know there is a
>>> simple-dpi for MIPI, but what is for parallel video or lvds?
>> simple-dpi is just parallel output. LVDS is not supported by Exynos4412 but
>> boards usually have RGB/LVDS bridge for such panels, I have no access to
>> itop
>> board schematics, but I suppose it has such bridge. LVDS bridges often
>> do not
>> need Linux driver, so from developer point of view LVDS panels with such
>> bridge
> Yes it is.
>> are handled the same way as RGB panels. Example fimd bindings for RGB panels
>> are in [3].
>>
>> [3]: arch/arm/boot/dts/exynos4210-universal_c210.dts
>>
> Would it appear as a frame buffer device in Linux ? Regard of display
> timings, I could solve it later. If the frame buffer node is created, I could
> know I have a way to test.
Yes, it should, if everything is properly done /dev/fb0 should be available.
Roughly steps to do:
1. add panel definition to drivers/gpu/drm/panel/panel-simple.c.
2. add panel entry and fimd bindings to itop dts.
3. enable exynos dpi, simple panel, drm_framebuffer in .config.
>>>> Regards
>>>> Andrzej
>>> The other problem is that I don't how to configure the display-times,
>>> the datasheet for CLAA070WP03XG only talk about total time, active time
>>> and blank time for both Horizontal an Vertical time. Does i
Re: [PATCH v2 1/4] ARM: dts: exynos: Enable HDMI for Arndale Octa board
Hi Milo,
On 08/24/2016 04:25 AM, Milo Kim wrote:
> * Support HDMI display data channel
> I2C #2 is assigned for the HDMI DDC. It enables the EDID access.
>
> * GPIO for HDMI hot plug detect
> GPX3_7 is used. The HPD awareness is done when the GPIO is active high and
> single ended.
>
> * Enable HDMI block in Exynos5420
> HDMI PLL consumes 1.0V LDO6 (PVDD_ANAIP_1V0) and HDMI oscillator requires
> 1.8V LDO7 (PVDD_ANAIP_1V8).
>
> Cc: Kukjin Kim
> Cc: Krzysztof Kozlowski
> Cc: David Airlie
> Cc: Inki Dae
> Cc: Joonyoung Shim
> Cc: Seung-Woo Kim
> Cc: Kyungmin Park
> Cc: Rob Herring
> Cc: devicet...@vger.kernel.org
> Cc: linux-arm-ker...@lists.infradead.org
> Cc: linux-samsung-...@vger.kernel.org
> Cc: linux-kernel@vger.kernel.org
> Cc: dri-de...@lists.freedesktop.org
> Signed-off-by: Milo Kim
> ---
> arch/arm/boot/dts/exynos5420-arndale-octa.dts | 17 +
> 1 file changed, 17 insertions(+)
>
> diff --git a/arch/arm/boot/dts/exynos5420-arndale-octa.dts
> b/arch/arm/boot/dts/exynos5420-arndale-octa.dts
> index 39a3b81..df362a2 100644
> --- a/arch/arm/boot/dts/exynos5420-arndale-octa.dts
> +++ b/arch/arm/boot/dts/exynos5420-arndale-octa.dts
> @@ -70,6 +70,23 @@
> status = "disabled";
> };
>
> +&i2c_2 {
> + samsung,i2c-slave-addr = <0x50>;
> + status = "okay";
> +
> + hdmiddc@50 {
> + compatible = "samsung,exynos4210-hdmiddc";
> + reg = <0x50>;
> + };
> +};
> +
> +&hdmi {
> + hpd-gpios = <&gpx3 7 GPIO_OPEN_SOURCE>;
> + vdd_osc-supply = <&ldo7_reg>;
> + vdd_pll-supply = <&ldo6_reg>;
> + status = "okay";
Please use ddc property in hdmi node, instead of this legacy binding.
See exynos4210-universal_c210.dts or exynos4412-odroid-common.dtsi for
reference.
Regards
Andrzej
> +};
> +
> &hsi2c_4 {
> status = "okay";
>
Re: [PATCH v2 2/4] ARM: dts: exynos: Use 'hpd-gpios' instead of 'hpd-gpio'
On 08/24/2016 04:25 AM, Milo Kim wrote:
> This patch enables getting a HPD GPIO descriptor quickly.
> The exynos-hdmi driver uses "hpd" for HDMI hot plug detection.
>
> static int hdmi_resources_init(struct hdmi_context *hdata)
> {
> ...
> hdata->hpd_gpio = devm_gpiod_get(dev, "hpd", GPIOD_IN);
> ...
> }
>
> This calls 'of_find_gpio()' and it generates the GPIO consumer ID by referring
> GPIO suffix. So 'hpd-gpios' is preferred on getting a GPIO descriptor.
>
> However, if the device tree uses 'hpd-gpio', then the exynos-hdmi driver
> always retries to get a GPIO descriptor because the first GPIO suffix is not
> 'gpio' but 'gpios'. So you always see the debug message below.
>
> of_get_named_gpiod_flags: can't parse 'hpd-gpios' property of node
> '/soc/hdmi@1453[0]'
>
> Use the preferred property, 'hpd-gpios' instead of 'hpd-gpio'.
>
> Acked-by: Rob Herring
> Cc: Kukjin Kim
> Cc: Krzysztof Kozlowski
> Cc: David Airlie
> Cc: Inki Dae
> Cc: Joonyoung Shim
> Cc: Seung-Woo Kim
> Cc: Kyungmin Park
> Cc: devicet...@vger.kernel.org
> Cc: linux-arm-ker...@lists.infradead.org
> Cc: linux-samsung-...@vger.kernel.org
> Cc: linux-kernel@vger.kernel.org
> Cc: dri-de...@lists.freedesktop.org
> Signed-off-by: Milo Kim
I am not sure if this long Cc list is necessary.
Anyway:
Reviewed-by: Andrzej Hajda
--
Regards
Andrzej
Re: [PATCH v2 3/4] gpu: drm: exynos_hdmi: Use consolidated function on binding DDC DT property
On 08/24/2016 04:25 AM, Milo Kim wrote:
> Handle legacy and raw 'ddc' parsing in single function.
> And it also removes goto condition.
>
> Cc: Kukjin Kim
> Cc: Krzysztof Kozlowski
> Cc: David Airlie
> Cc: Inki Dae
> Cc: Joonyoung Shim
> Cc: Seung-Woo Kim
> Cc: Kyungmin Park
> Cc: Rob Herring
> Cc: devicet...@vger.kernel.org
> Cc: linux-arm-ker...@lists.infradead.org
> Cc: linux-samsung-...@vger.kernel.org
> Cc: linux-kernel@vger.kernel.org
> Cc: dri-de...@lists.freedesktop.org
> Signed-off-by: Milo Kim
> ---
> drivers/gpu/drm/exynos/exynos_hdmi.c | 18 +-
> 1 file changed, 9 insertions(+), 9 deletions(-)
>
> diff --git a/drivers/gpu/drm/exynos/exynos_hdmi.c
> b/drivers/gpu/drm/exynos/exynos_hdmi.c
> index 2275efe..6a636f2 100644
> --- a/drivers/gpu/drm/exynos/exynos_hdmi.c
> +++ b/drivers/gpu/drm/exynos/exynos_hdmi.c
> @@ -1760,7 +1760,7 @@ static const struct component_ops hdmi_component_ops = {
> .unbind = hdmi_unbind,
> };
>
> -static struct device_node *hdmi_legacy_ddc_dt_binding(struct device *dev)
> +static struct device_node *hdmi_ddc_dt_binding(struct device *dev)
> {
> const char *compatible_str = "samsung,exynos4210-hdmiddc";
> struct device_node *np;
> @@ -1769,7 +1769,13 @@ static struct device_node
> *hdmi_legacy_ddc_dt_binding(struct device *dev)
> if (np)
> return of_get_next_parent(np);
>
> - return NULL;
> + np = of_parse_phandle(dev->of_node, "ddc", 0);
> + if (!np)
> + return NULL;
> +
> + of_node_put(dev->of_node);
This is mistake introduced by other patch, of_node_put should be called on
np, after calling of_find_i2c_adapter_by_node. You can fix it in your
patch as well.
I think you can move of_find_i2c_adapter_by_node also to this function and
rename it to sth like hdmi_get_ddc_adapter, this way you will enclose
whole logic
of getting resource into one function.
Regards
Andrzej
> +
> + return np;
> }
>
> static struct device_node *hdmi_legacy_phy_dt_binding(struct device *dev)
> @@ -1811,18 +1817,12 @@ static int hdmi_probe(struct platform_device *pdev)
> return ret;
> }
>
> - ddc_node = hdmi_legacy_ddc_dt_binding(dev);
> - if (ddc_node)
> - goto out_get_ddc_adpt;
> -
> - ddc_node = of_parse_phandle(dev->of_node, "ddc", 0);
> + ddc_node = hdmi_ddc_dt_binding(dev);
> if (!ddc_node) {
> DRM_ERROR("Failed to find ddc node in device tree\n");
> return -ENODEV;
> }
> - of_node_put(dev->of_node);
>
> -out_get_ddc_adpt:
> hdata->ddc_adpt = of_find_i2c_adapter_by_node(ddc_node);
> if (!hdata->ddc_adpt) {
> DRM_ERROR("Failed to get ddc i2c adapter by node\n");
Re: [PATCH v2 4/4] gpu: drm: exynos_hdmi: Use consolidated function on binding PHY DT property
On 08/24/2016 04:25 AM, Milo Kim wrote:
> Handle legacy and raw 'phy' parsing in single function.
> And it also removes goto condition.
>
> Cc: Kukjin Kim
> Cc: Krzysztof Kozlowski
> Cc: David Airlie
> Cc: Inki Dae
> Cc: Joonyoung Shim
> Cc: Seung-Woo Kim
> Cc: Kyungmin Park
> Cc: Rob Herring
> Cc: devicet...@vger.kernel.org
> Cc: linux-arm-ker...@lists.infradead.org
> Cc: linux-samsung-...@vger.kernel.org
> Cc: linux-kernel@vger.kernel.org
> Cc: dri-de...@lists.freedesktop.org
> Signed-off-by: Milo Kim
> ---
> drivers/gpu/drm/exynos/exynos_hdmi.c | 23 ++-
> 1 file changed, 14 insertions(+), 9 deletions(-)
>
> diff --git a/drivers/gpu/drm/exynos/exynos_hdmi.c
> b/drivers/gpu/drm/exynos/exynos_hdmi.c
> index 6a636f2..bb2d6d4 100644
> --- a/drivers/gpu/drm/exynos/exynos_hdmi.c
> +++ b/drivers/gpu/drm/exynos/exynos_hdmi.c
> @@ -1778,11 +1778,22 @@ static struct device_node *hdmi_ddc_dt_binding(struct
> device *dev)
> return np;
> }
>
> -static struct device_node *hdmi_legacy_phy_dt_binding(struct device *dev)
> +static struct device_node *hdmi_phy_dt_binding(struct device *dev)
> {
> const char *compatible_str = "samsung,exynos4212-hdmiphy";
> + struct device_node *np;
> +
> + np = of_find_compatible_node(NULL, NULL, compatible_str);
> + if (np)
> + return np;
> +
> + np = of_parse_phandle(dev->of_node, "phy", 0);
> + if (!np)
> + return NULL;
> +
> + of_node_put(dev->of_node);
Identical issue as in previous patch.
Regards
Andrzej
>
> - return of_find_compatible_node(NULL, NULL, compatible_str);
> + return np;
> }
>
> static int hdmi_probe(struct platform_device *pdev)
> @@ -1829,19 +1840,13 @@ static int hdmi_probe(struct platform_device *pdev)
> return -EPROBE_DEFER;
> }
>
> - phy_node = hdmi_legacy_phy_dt_binding(dev);
> - if (phy_node)
> - goto out_get_phy_port;
> -
> - phy_node = of_parse_phandle(dev->of_node, "phy", 0);
> + phy_node = hdmi_phy_dt_binding(dev);
> if (!phy_node) {
> DRM_ERROR("Failed to find hdmiphy node in device tree\n");
> ret = -ENODEV;
> goto err_ddc;
> }
> - of_node_put(dev->of_node);
>
> -out_get_phy_port:
> if (hdata->drv_data->is_apb_phy) {
> hdata->regs_hdmiphy = of_iomap(phy_node, 0);
> if (!hdata->regs_hdmiphy) {
Re: [PATCH v3 3/5] gpu: drm: exynos_hdmi: Move DDC logic into single function
On 08/24/2016 03:07 PM, Milo Kim wrote:
> Paring DT properties and getting the I2C adapter in one function.
>
> Cc: Kukjin Kim
> Cc: Krzysztof Kozlowski
> Cc: David Airlie
> Cc: Inki Dae
> Cc: Joonyoung Shim
> Cc: Seung-Woo Kim
> Cc: Kyungmin Park
> Cc: Rob Herring
> Cc: devicet...@vger.kernel.org
> Cc: linux-arm-ker...@lists.infradead.org
> Cc: linux-samsung-...@vger.kernel.org
> Cc: linux-kernel@vger.kernel.org
> Cc: dri-de...@lists.freedesktop.org
> Signed-off-by: Milo Kim
> ---
> drivers/gpu/drm/exynos/exynos_hdmi.c | 46
>
> 1 file changed, 25 insertions(+), 21 deletions(-)
>
> diff --git a/drivers/gpu/drm/exynos/exynos_hdmi.c
> b/drivers/gpu/drm/exynos/exynos_hdmi.c
> index 2275efe..8d99b5d 100644
> --- a/drivers/gpu/drm/exynos/exynos_hdmi.c
> +++ b/drivers/gpu/drm/exynos/exynos_hdmi.c
> @@ -1760,16 +1760,34 @@ static const struct component_ops hdmi_component_ops
> = {
> .unbind = hdmi_unbind,
> };
>
> -static struct device_node *hdmi_legacy_ddc_dt_binding(struct device *dev)
> +static int hdmi_get_ddc_adapter(struct hdmi_context *hdata)
> {
> const char *compatible_str = "samsung,exynos4210-hdmiddc";
> struct device_node *np;
> + struct i2c_adapter *adpt;
>
> np = of_find_compatible_node(NULL, NULL, compatible_str);
> if (np)
> - return of_get_next_parent(np);
> + np = of_get_next_parent(np);
> + else
> + np = of_parse_phandle(hdata->dev->of_node, "ddc", 0);
> +
> + if (!np) {
> + DRM_ERROR("Failed to find ddc node in device tree\n");
> + return -ENODEV;
> + }
>
> - return NULL;
> + adpt = of_find_i2c_adapter_by_node(np);
You can put of_node_put here, instead of duplicating it on both
execution paths.
> + if (!adpt) {
> + DRM_ERROR("Failed to get ddc i2c adapter by node\n");
In case of probe deferring DRM_INFO should be enough, or even DRM_DEBUG.
> + of_node_put(np);
> + return -EPROBE_DEFER;
> + }
> +
> + hdata->ddc_adpt = adpt;
> + of_node_put(np);
> +
> + return 0;
> }
>
> static struct device_node *hdmi_legacy_phy_dt_binding(struct device *dev)
> @@ -1781,7 +1799,7 @@ static struct device_node
> *hdmi_legacy_phy_dt_binding(struct device *dev)
>
> static int hdmi_probe(struct platform_device *pdev)
> {
> - struct device_node *ddc_node, *phy_node;
> + struct device_node *phy_node;
> struct device *dev = &pdev->dev;
> struct hdmi_context *hdata;
> struct resource *res;
> @@ -1811,23 +1829,9 @@ static int hdmi_probe(struct platform_device *pdev)
> return ret;
> }
>
> - ddc_node = hdmi_legacy_ddc_dt_binding(dev);
> - if (ddc_node)
> - goto out_get_ddc_adpt;
> -
> - ddc_node = of_parse_phandle(dev->of_node, "ddc", 0);
> - if (!ddc_node) {
> - DRM_ERROR("Failed to find ddc node in device tree\n");
> - return -ENODEV;
> - }
> - of_node_put(dev->of_node);
> -
> -out_get_ddc_adpt:
> - hdata->ddc_adpt = of_find_i2c_adapter_by_node(ddc_node);
> - if (!hdata->ddc_adpt) {
> - DRM_ERROR("Failed to get ddc i2c adapter by node\n");
> - return -EPROBE_DEFER;
> - }
> + ret = hdmi_get_ddc_adapter(hdata);
> + if (ret)
> + return ret;
>
> phy_node = hdmi_legacy_phy_dt_binding(dev);
> if (phy_node)
Re: [PATCH v3 5/5] gpu: drm: exynos_hdmi: Remove duplicate initialization of regulator bulk consumer
On 08/24/2016 03:07 PM, Milo Kim wrote:
> The helper, devm_regulator_bulk_get() initializes the consumer as NULL,
> so this code can be ignored.
>
> Cc: Kukjin Kim
> Cc: Krzysztof Kozlowski
> Cc: David Airlie
> Cc: Inki Dae
> Cc: Joonyoung Shim
> Cc: Seung-Woo Kim
> Cc: Kyungmin Park
> Cc: linux-arm-ker...@lists.infradead.org
> Cc: linux-samsung-...@vger.kernel.org
> Cc: linux-kernel@vger.kernel.org
> Cc: dri-de...@lists.freedesktop.org
> Signed-off-by: Milo Kim
Reviewed-by: Andrzej Hajda
--
Regards
Andrzej
> ---
> drivers/gpu/drm/exynos/exynos_hdmi.c | 5 ++---
> 1 file changed, 2 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/gpu/drm/exynos/exynos_hdmi.c
> b/drivers/gpu/drm/exynos/exynos_hdmi.c
> index 249cb23..4e17877f 100644
> --- a/drivers/gpu/drm/exynos/exynos_hdmi.c
> +++ b/drivers/gpu/drm/exynos/exynos_hdmi.c
> @@ -1669,10 +1669,9 @@ static int hdmi_resources_init(struct hdmi_context
> *hdata)
> if (ret)
> return ret;
>
> - for (i = 0; i < ARRAY_SIZE(supply); ++i) {
> + for (i = 0; i < ARRAY_SIZE(supply); ++i)
> hdata->regul_bulk[i].supply = supply[i];
> - hdata->regul_bulk[i].consumer = NULL;
> - }
> +
> ret = devm_regulator_bulk_get(dev, ARRAY_SIZE(supply),
> hdata->regul_bulk);
> if (ret) {
> if (ret != -EPROBE_DEFER)
Re: [PATCH v6 2/5] drm/vc4: Avoid using vrefresh==0 mode in DSI htotal math.
On 16.08.2017 01:47, Eric Anholt wrote: > The incoming mode might have a missing vrefresh field if it came from > drmModeSetCrtc(), which the kernel is supposed to calculate using > drm_mode_vrefresh(). We could either use that or the adjusted_mode's > original vrefresh value. > > However, we can maintain a more exact vrefresh value (not just the > integer approximation), by scaling by the ratio of our clocks. > > v2: Use math suggested by Andrzej Hajda instead. > v3: Simplify math now that adjusted_mode->clock isn't padded. > > Signed-off-by: Eric Anholt > --- > drivers/gpu/drm/vc4/vc4_dsi.c | 3 ++- > 1 file changed, 2 insertions(+), 1 deletion(-) > > diff --git a/drivers/gpu/drm/vc4/vc4_dsi.c b/drivers/gpu/drm/vc4/vc4_dsi.c > index eb787eed8abe..2516cd3a1d87 100644 > --- a/drivers/gpu/drm/vc4/vc4_dsi.c > +++ b/drivers/gpu/drm/vc4/vc4_dsi.c > @@ -862,7 +862,8 @@ static bool vc4_dsi_encoder_mode_fixup(struct drm_encoder > *encoder, > adjusted_mode->clock = pixel_clock_hz / 1000; > > /* Given the new pixel clock, adjust HFP to keep vrefresh the same. */ > - adjusted_mode->htotal = pixel_clock_hz / (mode->vrefresh * > mode->vtotal); > + adjusted_mode->htotal = (adjusted_mode->clock * mode->htotal / > + mode->clock); Parentheses can be removed. Beside this: Reviewed-by: Andrzej Hajda -- Regards Andrzej > adjusted_mode->hsync_end += adjusted_mode->htotal - mode->htotal; > adjusted_mode->hsync_start += adjusted_mode->htotal - mode->htotal; >
Re: [PATCH 1/7] drm/bridge: Support hotplugging panel-bridge.
On 22.06.2017 11:23, Boris Brezillon wrote: > On Thu, 22 Jun 2017 13:47:43 +0530 > Archit Taneja wrote: > >> On 06/22/2017 01:20 PM, Benjamin Gaignard wrote: >>> 2017-06-20 19:31 GMT+02:00 Eric Anholt : Archit Taneja writes: > On 06/16/2017 08:13 PM, Eric Anholt wrote: >> Archit Taneja writes: >> >>> On 06/16/2017 02:11 AM, Eric Anholt wrote: If the panel-bridge is being set up after the drm_mode_config_reset(), then the connector's state would never get initialized, and we'd dereference the NULL in the hotplug path. We also need to register the connector, so that userspace can get at it. >>> Shouldn't the KMS driver make sure the panel-bridge is set up before >>> drm_mode_config_reset? Is it the case when we're inserting the >>> panel-bridge driver as a module? >>> >>> >>> All the connectors that have been added are registered automatically >>> when drm_dev_register() is called by the KMS driver. Registering a >>> connector in the middle of setting up our driver is prone to race >>> conditions if the userspace decides to use them immediately. >> Yeah, this is fixing initializing panel_bridge at DSI host_attach time, >> which in the case of a panel module that creates the DSI device >> (adv7533-style, like you said I should use as a reference) will be after >> drm_mode_config_reset() and drm_dev_register(). > Okay. In the case of the msm kms driver, we defer probe until the > adv7533 module is inserted, only then we proceed to > drm_mode_config_reset() > and drm_dev_register(). I assumed this was the general practice followed > by > most kms drivers. I.,e the kms driver defers probe until all connector > related modules are inserted, and only then proceed to create a drm > device. The problem, though, is the panel driver needs the MIPI DSI host to exist to call mipi_dsi_device_register_full() during the probe process. The adv7533 driver gets around this by registering the DSI device in the bridge attach step, but drm_panel doesn't have an attach step. >> I'm not sure how we can get around this. We had discussion about this on irc >> recently, but couldn't come up with a good conclusion. We could come up with >> a >> panel_attach() callback to make it similar to bridges, but that's just us >> avoiding >> the real issue. > How about making DSI dev registration fully asynchronous, that is, DSI > devs declared in the DT under the DSI host node will be > registered/attached at probe time, and devs using another control bus > (like the adv7533 controller over i2c) will be registered afterwards. > > That implies moving the drm_brige registration logic outside of the DSI > host ->probe() path. The idea would be to check if all devs connected > to the DSI bus are ready at dsi_host->attach() time. If they are, we > can finally register the XXX -> DSI bridge. If they're not (because > some devs connected to the DSI bus have not been probed yet), then we > do not register the drm_bridge and wait for the next dsi_host->attach() > event. I guess you assumes that dsi-host knows all devs connected to it, thanks to: - subnodes of the host - ie. devices controlled via dsi bus, - graph links from host ports/endpoints - ie. devices controlled by other buses, for example adv7533. I would separate both abstractions to make it more clear: 1. MIPI bus should be registered early - to allow create/bind devices on it, 2. drm_bridge should be registered only if all required sinks (bridges/panels) are registered. First point seems OK, I am not sure about the 2nd one - if used consistently, it would require building pipeline from sink to source. By the way is there any pipeline with two consecutive external bridges in the mainline? Regards Andrzej
Re: [PATCH 1/7] drm/bridge: Support hotplugging panel-bridge.
On 22.06.2017 14:41, Boris Brezillon wrote: > On Thu, 22 Jun 2017 14:29:07 +0200 > Andrzej Hajda wrote: > >> On 22.06.2017 11:23, Boris Brezillon wrote: >>> On Thu, 22 Jun 2017 13:47:43 +0530 >>> Archit Taneja wrote: >>> >>>> On 06/22/2017 01:20 PM, Benjamin Gaignard wrote: >>>>> 2017-06-20 19:31 GMT+02:00 Eric Anholt : >>>>>> Archit Taneja writes: >>>>>> >>>>>>> On 06/16/2017 08:13 PM, Eric Anholt wrote: >>>>>>>> Archit Taneja writes: >>>>>>>> >>>>>>>>> On 06/16/2017 02:11 AM, Eric Anholt wrote: >>>>>>>>>> If the panel-bridge is being set up after the >>>>>>>>>> drm_mode_config_reset(), >>>>>>>>>> then the connector's state would never get initialized, and we'd >>>>>>>>>> dereference the NULL in the hotplug path. We also need to register >>>>>>>>>> the connector, so that userspace can get at it. >>>>>>>>>> >>>>>>>>> Shouldn't the KMS driver make sure the panel-bridge is set up before >>>>>>>>> drm_mode_config_reset? Is it the case when we're inserting the >>>>>>>>> panel-bridge driver as a module? >>>>>>>>> >>>>>>>>> >>>>>>>>> All the connectors that have been added are registered automatically >>>>>>>>> when drm_dev_register() is called by the KMS driver. Registering a >>>>>>>>> connector in the middle of setting up our driver is prone to race >>>>>>>>> conditions if the userspace decides to use them immediately. >>>>>>>> Yeah, this is fixing initializing panel_bridge at DSI host_attach time, >>>>>>>> which in the case of a panel module that creates the DSI device >>>>>>>> (adv7533-style, like you said I should use as a reference) will be >>>>>>>> after >>>>>>>> drm_mode_config_reset() and drm_dev_register(). >>>>>>> Okay. In the case of the msm kms driver, we defer probe until the >>>>>>> adv7533 module is inserted, only then we proceed to >>>>>>> drm_mode_config_reset() >>>>>>> and drm_dev_register(). I assumed this was the general practice >>>>>>> followed by >>>>>>> most kms drivers. I.,e the kms driver defers probe until all connector >>>>>>> related modules are inserted, and only then proceed to create a drm >>>>>>> device. >>>>>> The problem, though, is the panel driver needs the MIPI DSI host to >>>>>> exist to call mipi_dsi_device_register_full() during the probe process. >>>>>> The adv7533 driver gets around this by registering the DSI device in the >>>>>> bridge attach step, but drm_panel doesn't have an attach step. >>>> I'm not sure how we can get around this. We had discussion about this on >>>> irc >>>> recently, but couldn't come up with a good conclusion. We could come up >>>> with a >>>> panel_attach() callback to make it similar to bridges, but that's just us >>>> avoiding >>>> the real issue. >>> How about making DSI dev registration fully asynchronous, that is, DSI >>> devs declared in the DT under the DSI host node will be >>> registered/attached at probe time, and devs using another control bus >>> (like the adv7533 controller over i2c) will be registered afterwards. >>> >>> That implies moving the drm_brige registration logic outside of the DSI >>> host ->probe() path. The idea would be to check if all devs connected >>> to the DSI bus are ready at dsi_host->attach() time. If they are, we >>> can finally register the XXX -> DSI bridge. If they're not (because >>> some devs connected to the DSI bus have not been probed yet), then we >>> do not register the drm_bridge and wait for the next dsi_host->attach() >>> event. >> I guess you assumes that dsi-host knows all devs connected to it, thanks to: >> - subnodes of the host - ie. devices controlled via dsi bus, >> - graph links from host ports/endpoints - ie. devices controlled by >> other buses, for example adv7533. > Yep, but I th
Re: [RESEND PATCH v2 4/5] drm/bridge/analogix: Do not use device's drvdata
On 16.10.2017 12:06, Jeffy Chen wrote: > From: Tomasz Figa > > The driver that instantiates the bridge should own the drvdata, as all > driver model callbacks (probe, remove, shutdown, PM ops, etc.) are also > owned by its driver struct. Moreover, storing two different pointer > types in driver data depending on driver initialization status is barely > a good practice and in fact has led to many bugs in this driver. > > Let's clean up this mess and change Analogix entry points to simply > accept some opaque struct pointer, adjusting their users at the same > time to avoid breaking the compilation. > > Signed-off-by: Tomasz Figa > Signed-off-by: Jeffy Chen Thanks for making it a bit saner. Reviewed-by: Andrzej Hajda -- Regards Andrzej
Re: [PATCH 1/2] media: s5p-mfc: check for firmware allocation before requesting firmware
Hi Shuah,
On 06.10.2017 23:30, Shuah Khan wrote:
> Check if firmware is allocated before requesting firmware instead of
> requesting firmware only to release it if firmware is not allocated.
>
> Signed-off-by: Shuah Khan
> ---
> drivers/media/platform/s5p-mfc/s5p_mfc_ctrl.c | 10 +-
> 1 file changed, 5 insertions(+), 5 deletions(-)
>
> diff --git a/drivers/media/platform/s5p-mfc/s5p_mfc_ctrl.c
> b/drivers/media/platform/s5p-mfc/s5p_mfc_ctrl.c
> index 69ef9c2..f064a0d1 100644
> --- a/drivers/media/platform/s5p-mfc/s5p_mfc_ctrl.c
> +++ b/drivers/media/platform/s5p-mfc/s5p_mfc_ctrl.c
> @@ -55,6 +55,11 @@ int s5p_mfc_load_firmware(struct s5p_mfc_dev *dev)
>* into kernel. */
> mfc_debug_enter();
>
> + if (!dev->fw_buf.virt) {
> + mfc_err("MFC firmware is not allocated\n");
> + return -EINVAL;
> + }
> +
> for (i = MFC_FW_MAX_VERSIONS - 1; i >= 0; i--) {
> if (!dev->variant->fw_name[i])
> continue;
> @@ -75,11 +80,6 @@ int s5p_mfc_load_firmware(struct s5p_mfc_dev *dev)
> release_firmware(fw_blob);
> return -ENOMEM;
> }
> - if (!dev->fw_buf.virt) {
> - mfc_err("MFC firmware is not allocated\n");
> - release_firmware(fw_blob);
> - return -EINVAL;
> - }
Is there any scenario in which dev->fw_buf.virt is null and
s5p_mfc_load_firmware is called?
I suspect this check is not necessary at all.
Regards
Andrzej
> memcpy(dev->fw_buf.virt, fw_blob->data, fw_blob->size);
> wmb();
> release_firmware(fw_blob);
Re: [PATCH 2/2] media: s5p-mfc: fix lock confection - request_firmware() once and keep state
On 06.10.2017 23:30, Shuah Khan wrote:
> Driver calls request_firmware() whenever the device is opened for the
> first time. As the device gets opened and closed, dev->num_inst == 1
> is true several times. This is not necessary since the firmware is saved
> in the fw_buf. s5p_mfc_load_firmware() copies the buffer returned by
> the request_firmware() to dev->fw_buf.
>
> fw_buf sticks around until it gets released from s5p_mfc_remove(), hence
> there is no need to keep requesting firmware and copying it to fw_buf.
>
> This might have been overlooked when changes are made to free fw_buf from
> the device release interface s5p_mfc_release().
>
> Fix s5p_mfc_load_firmware() to call request_firmware() once and keep state.
> Change _probe() to load firmware once fw_buf has been allocated.
>
> s5p_mfc_open() and it continues to call s5p_mfc_load_firmware() and init
> hardware which is the step where firmware is written to the device.
>
> This addresses the mfc_mutex contention due to repeated request_firmware()
> calls from open() in the following circular locking warning:
>
> [ 552.194115] qtdemux0:sink/2710 is trying to acquire lock:
> [ 552.199488] (&dev->mfc_mutex){+.+.}, at: []
> s5p_mfc_mmap+0x28/0xd4 [s5p_mfc]
> [ 552.207459]
>but task is already holding lock:
> [ 552.213264] (&mm->mmap_sem){}, at: []
> vm_mmap_pgoff+0x44/0xb8
> [ 552.220284]
>which lock already depends on the new lock.
>
> [ 552.228429]
>the existing dependency chain (in reverse order) is:
> [ 552.235881]
>-> #2 (&mm->mmap_sem){}:
> [ 552.241259]__might_fault+0x80/0xb0
> [ 552.245331]filldir64+0xc0/0x2f8
> [ 552.249144]call_filldir+0xb0/0x14c
> [ 552.253214]ext4_readdir+0x768/0x90c
> [ 552.257374]iterate_dir+0x74/0x168
> [ 552.261360]SyS_getdents64+0x7c/0x1a0
> [ 552.265608]ret_fast_syscall+0x0/0x28
> [ 552.269850]
>-> #1 (&type->i_mutex_dir_key#2){}:
> [ 552.276180]down_read+0x48/0x90
> [ 552.279904]lookup_slow+0x74/0x178
> [ 552.283889]walk_component+0x1a4/0x2e4
> [ 552.288222]link_path_walk+0x174/0x4a0
> [ 552.292555]path_openat+0x68/0x944
> [ 552.296541]do_filp_open+0x60/0xc4
> [ 552.300528]file_open_name+0xe4/0x114
> [ 552.304772]filp_open+0x28/0x48
> [ 552.308499]kernel_read_file_from_path+0x30/0x78
> [ 552.313700]_request_firmware+0x3ec/0x78c
> [ 552.318291]request_firmware+0x3c/0x54
> [ 552.322642]s5p_mfc_load_firmware+0x54/0x150 [s5p_mfc]
> [ 552.328358]s5p_mfc_open+0x4e4/0x550 [s5p_mfc]
> [ 552.94]v4l2_open+0xa0/0x104 [videodev]
> [ 552.338137]chrdev_open+0xa4/0x18c
> [ 552.342121]do_dentry_open+0x208/0x310
> [ 552.346454]path_openat+0x28c/0x944
> [ 552.350526]do_filp_open+0x60/0xc4
> [ 552.354512]do_sys_open+0x118/0x1c8
> [ 552.358586]ret_fast_syscall+0x0/0x28
> [ 552.362830]
>-> #0 (&dev->mfc_mutex){+.+.}:
>-> #0 (&dev->mfc_mutex){+.+.}:
> [ 552.368379]lock_acquire+0x6c/0x88
> [ 552.372364]__mutex_lock+0x68/0xa34
> [ 552.376437]mutex_lock_interruptible_nested+0x1c/0x24
> [ 552.382086]s5p_mfc_mmap+0x28/0xd4 [s5p_mfc]
> [ 552.386939]v4l2_mmap+0x54/0x88 [videodev]
> [ 552.391601]mmap_region+0x3a8/0x638
> [ 552.395673]do_mmap+0x330/0x3a4
> [ 552.399400]vm_mmap_pgoff+0x90/0xb8
> [ 552.403472]SyS_mmap_pgoff+0x90/0xc0
> [ 552.407632]ret_fast_syscall+0x0/0x28
> [ 552.411876]
>other info that might help us debug this:
>
> [ 552.419848] Chain exists of:
> &dev->mfc_mutex --> &type->i_mutex_dir_key#2 -->
> &mm->mmap_sem
>
> [ 552.431200] Possible unsafe locking scenario:
>
> [ 552.437092]CPU0CPU1
> [ 552.441598]
> [ 552.446104] lock(&mm->mmap_sem);
> [ 552.449484]lock(&type->i_mutex_dir_key#2);
> [ 552.456329]lock(&mm->mmap_sem);
> [ 552.46] lock(&dev->mfc_mutex);
> [ 552.465775]
> *** DEADLOCK ***
I am not 100% but it looks like false positive. Could you describe
scenario when it deadlocks?
>
> Signed-off-by: Shuah Khan
> ---
> drivers/media/platform/s5p-mfc/s5p_mfc.c| 4
> drivers/media/platform/s5p-mfc/s5p_mfc_common.h | 3 +++
> drivers/media/platform/s5p-mfc/s5p_mfc_ctrl.c | 5 +
> 3 files changed, 12 insertions(+)
>
> diff --git a/drivers/media/platform/s5p-mfc/s5p_mfc.c
> b/drivers/media/platform/s5p-mfc/s5p_mfc.c
> index 1afde50..4c253fb 100644
> --- a/drivers/media/platform/s5p-mfc/s5p_mfc.c
> +++ b/drivers/media/platform/s5p-mfc/s5p_mfc.c
> @@ -1315,6 +1315,10 @@ static int s5p_mfc_probe(struct platform_device *pdev)
> goto err_dma;
Re: [PATCH] drm/bridge/synopsys: dsi: add optional pixel clock
On 26.10.2017 18:09, Philippe Cornu wrote:
> The pixel clock is optional. When available, it offers a better
> preciseness for timing computations.
>
> Signed-off-by: Philippe Cornu
> ---
> drivers/gpu/drm/bridge/synopsys/dw-mipi-dsi.c | 24 ++--
> 1 file changed, 18 insertions(+), 6 deletions(-)
>
> diff --git a/drivers/gpu/drm/bridge/synopsys/dw-mipi-dsi.c
> b/drivers/gpu/drm/bridge/synopsys/dw-mipi-dsi.c
> index d9cca4f..8b3787d 100644
> --- a/drivers/gpu/drm/bridge/synopsys/dw-mipi-dsi.c
> +++ b/drivers/gpu/drm/bridge/synopsys/dw-mipi-dsi.c
> @@ -225,6 +225,7 @@ struct dw_mipi_dsi {
> void __iomem *base;
>
> struct clk *pclk;
> + struct clk *px_clk;
>
> unsigned int lane_mbps; /* per lane */
> u32 channel;
> @@ -753,24 +754,28 @@ void dw_mipi_dsi_bridge_mode_set(struct drm_bridge
> *bridge,
> struct dw_mipi_dsi *dsi = bridge_to_dsi(bridge);
> const struct dw_mipi_dsi_phy_ops *phy_ops = dsi->plat_data->phy_ops;
> void *priv_data = dsi->plat_data->priv_data;
> + struct drm_display_mode px_clk_mode = *mode;
> int ret;
>
> clk_prepare_enable(dsi->pclk);
>
> - ret = phy_ops->get_lane_mbps(priv_data, mode, dsi->mode_flags,
> + if (dsi->px_clk)
> + px_clk_mode.clock = clk_get_rate(dsi->px_clk) / 1000;
> +
> + ret = phy_ops->get_lane_mbps(priv_data, &px_clk_mode, dsi->mode_flags,
>dsi->lanes, dsi->format, &dsi->lane_mbps);
Just small suggestion: if pixel clock rate matters, maybe better is to
fix it in adjusted_mode in mode_fixup callback.
> if (ret)
> DRM_DEBUG_DRIVER("Phy get_lane_mbps() failed\n");
>
> pm_runtime_get_sync(dsi->dev);
> dw_mipi_dsi_init(dsi);
> - dw_mipi_dsi_dpi_config(dsi, mode);
> + dw_mipi_dsi_dpi_config(dsi, &px_clk_mode);
> dw_mipi_dsi_packet_handler_config(dsi);
> dw_mipi_dsi_video_mode_config(dsi);
> - dw_mipi_dsi_video_packet_config(dsi, mode);
> + dw_mipi_dsi_video_packet_config(dsi, &px_clk_mode);
> dw_mipi_dsi_command_mode_config(dsi);
> - dw_mipi_dsi_line_timer_config(dsi, mode);
> - dw_mipi_dsi_vertical_timing_config(dsi, mode);
> + dw_mipi_dsi_line_timer_config(dsi, &px_clk_mode);
> + dw_mipi_dsi_vertical_timing_config(dsi, &px_clk_mode);
>
> dw_mipi_dsi_dphy_init(dsi);
> dw_mipi_dsi_dphy_timing_config(dsi);
> @@ -784,7 +789,7 @@ void dw_mipi_dsi_bridge_mode_set(struct drm_bridge
> *bridge,
>
> dw_mipi_dsi_dphy_enable(dsi);
>
> - dw_mipi_dsi_wait_for_two_frames(mode);
> + dw_mipi_dsi_wait_for_two_frames(&px_clk_mode);
>
> /* Switch to cmd mode for panel-bridge pre_enable & panel prepare */
> dw_mipi_dsi_set_mode(dsi, 0);
> @@ -878,6 +883,13 @@ static int dw_mipi_dsi_bridge_attach(struct drm_bridge
> *bridge)
> return ERR_PTR(ret);
> }
>
> + dsi->px_clk = devm_clk_get(dev, "px_clk");
> + if (IS_ERR(dsi->px_clk)) {
> + ret = PTR_ERR(dsi->px_clk);
> + dev_dbg(dev, "Unable to get optional px_clk: %d\n", ret);
> + dsi->px_clk = NULL;
> + }
> +
devm_clk_get is called from bridge::attach callback, do we have
guarantee that in ::detach callback the clock will be removed?
And what if the clock is defined in dts, but it cannot be get due to
other reasons? I guess the code should fail then, ie you should have
different paths for -ENOENT and for other errors.
--
Regards
Andrzej
> /*
>* Note that the reset was not defined in the initial device tree, so
>* we have to be prepared for it not being found.
Re: [PATCH v5 4/9] drm/bridge: analogix_dp: Fix connector & encoder cleanup
On 18.10.2017 14:09, Jeffy Chen wrote:
> Since we are initing connector in the core driver and encoder in the
> plat driver, let's clean them up in the right places.
>
> Signed-off-by: Jeffy Chen
> ---
>
> Changes in v5: None
>
> drivers/gpu/drm/bridge/analogix/analogix_dp_core.c | 2 --
> drivers/gpu/drm/exynos/exynos_dp.c | 7 +--
> drivers/gpu/drm/rockchip/analogix_dp-rockchip.c| 15 ++-
> 3 files changed, 11 insertions(+), 13 deletions(-)
>
> diff --git a/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c
> b/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c
> index 74d274b6d31d..3f910ab36ff6 100644
> --- a/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c
> +++ b/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c
> @@ -1409,7 +1409,6 @@ analogix_dp_bind(struct device *dev, struct drm_device
> *drm_dev,
> ret = analogix_dp_create_bridge(drm_dev, dp);
> if (ret) {
> DRM_ERROR("failed to create bridge (%d)\n", ret);
> - drm_encoder_cleanup(dp->encoder);
> goto err_disable_pm_runtime;
> }
>
> @@ -1432,7 +1431,6 @@ void analogix_dp_unbind(struct analogix_dp_device *dp)
> {
> analogix_dp_bridge_disable(dp->bridge);
> dp->connector.funcs->destroy(&dp->connector);
> - dp->encoder->funcs->destroy(dp->encoder);
>
> if (dp->plat_data->panel) {
> if (drm_panel_unprepare(dp->plat_data->panel))
> diff --git a/drivers/gpu/drm/exynos/exynos_dp.c
> b/drivers/gpu/drm/exynos/exynos_dp.c
> index f7e5b2c405ed..33319a858f3a 100644
> --- a/drivers/gpu/drm/exynos/exynos_dp.c
> +++ b/drivers/gpu/drm/exynos/exynos_dp.c
> @@ -185,8 +185,10 @@ static int exynos_dp_bind(struct device *dev, struct
> device *master, void *data)
> dp->plat_data.encoder = encoder;
>
> dp->adp = analogix_dp_bind(dev, dp->drm_dev, &dp->plat_data);
> - if (IS_ERR(dp->adp))
> + if (IS_ERR(dp->adp)) {
> + dp->encoder.funcs->destroy(&dp->encoder);
> return PTR_ERR(dp->adp);
> + }
>
> return 0;
> }
> @@ -196,7 +198,8 @@ static void exynos_dp_unbind(struct device *dev, struct
> device *master,
> {
> struct exynos_dp_device *dp = dev_get_drvdata(dev);
>
> - return analogix_dp_unbind(dp->adp);
> + analogix_dp_unbind(dp->adp);
> + dp->encoder.funcs->destroy(&dp->encoder);
> }
>
> static const struct component_ops exynos_dp_ops = {
> diff --git a/drivers/gpu/drm/rockchip/analogix_dp-rockchip.c
> b/drivers/gpu/drm/rockchip/analogix_dp-rockchip.c
> index fa0365de31d2..c0fb3f3748f4 100644
> --- a/drivers/gpu/drm/rockchip/analogix_dp-rockchip.c
> +++ b/drivers/gpu/drm/rockchip/analogix_dp-rockchip.c
> @@ -261,13 +261,8 @@ static struct drm_encoder_helper_funcs
> rockchip_dp_encoder_helper_funcs = {
> .atomic_check = rockchip_dp_drm_encoder_atomic_check,
> };
>
> -static void rockchip_dp_drm_encoder_destroy(struct drm_encoder *encoder)
> -{
> - drm_encoder_cleanup(encoder);
> -}
> -
> static struct drm_encoder_funcs rockchip_dp_encoder_funcs = {
> - .destroy = rockchip_dp_drm_encoder_destroy,
> + .destroy = drm_encoder_cleanup,
> };
>
> static int rockchip_dp_of_probe(struct rockchip_dp_device *dp)
> @@ -361,12 +356,13 @@ static int rockchip_dp_bind(struct device *dev, struct
> device *master,
> dp->psr_state = ~EDP_VSC_PSR_STATE_ACTIVE;
> INIT_WORK(&dp->psr_work, analogix_dp_psr_work);
>
> - rockchip_drm_psr_register(&dp->encoder, analogix_dp_psr_set);
> -
> dp->adp = analogix_dp_bind(dev, dp->drm_dev, &dp->plat_data);
> - if (IS_ERR(dp->adp))
> + if (IS_ERR(dp->adp)) {
> + dp->encoder.funcs->destroy(&dp->encoder);
> return PTR_ERR(dp->adp);
> + }
>
> + rockchip_drm_psr_register(&dp->encoder, analogix_dp_psr_set);
You are changing here order of calls: psr_reg after bind, it does not
seem to be related to patch subject.
Anyway psr_register can fail and its result is not checked, but it can
be addressed in separate patch.
So maybe it would be better to leave the order as is, unless there is
reason for change it in one patch, in such case please explain it in
commit message.
Beside this:
Reviewed-by: Andrzej Hajda
--
Regards
Andrzej
> return 0;
> }
>
> @@ -377,6 +373,7 @@ static void rockchip_dp_unbind(struct device *dev, struct
> device *master,
>
> rockchip_drm_psr_unregister(&dp->encoder);
> analogix_dp_unbind(dp->adp);
> + dp->encoder.funcs->destroy(&dp->encoder);
> }
>
> static const struct component_ops rockchip_dp_component_ops = {
Re: [RFC PATCH 1/4] dt-bindings: add bindings for USB physical connector
Hi Laurent,
Thank you for the review.
On 18.10.2017 17:11, Laurent Pinchart wrote:
> Hi Andrzej,
>
> Thank you for the patch.
>
> On Thursday, 28 September 2017 16:07:27 EEST Andrzej Hajda wrote:
>> These bindings allows to describe most known standard USB connectors
>> and it should be possible to extend it if necessary.
>> USB connectors, beside USB can be used to route other protocols,
>> for example UART, Audio, MHL. In such case every device passing data
>> through the connector should have appropriate graph bindings.
>>
>> Signed-off-by: Andrzej Hajda
>> ---
>> There are few things for discussion (IMO):
>> 1. vendor specific connectors, I have added them here, but maybe better is
>>to place them in separate files.
> It's useful to have one vendor-specific compatible string to be used in the
> example. We could split vendor-specific connectors to separate files later if
> needed, but for now I'm fine keeping them here.
>
>> 2. physical connector description - I have split it to three properties:
>>type(a,b,ab,c), max-mode(ls,fs,hs,ss,ss+), size(mini,micro,powered).
>>This tripled is able to describe all USB-standard connectors, but there
>>are also impossible combinations, for example(c, *, micro). Maybe better
>>would be to just enumerate all possible connectors in include file.
> I don't have a strong opinion on this. The three properties are nicely
> descriptive. You might want to list the valid combinations in the bindings
> though.
According to Rob's suggestion in next iteration I will encode USB port
type into compatible ie:
- usb-a-connector,
- usb-b-connector,
- usb-c-connector.
Rob suggested also to encode there speed as well, but I am afraid it
will inflate number of compatibles:
(3 types: a, b, c) x (3 speed modes: hs, ss, ssplus) = 9 combinations
>> 3. Numbering of port/remote nodes, currently only 0 is assigned for
>> Interface Controller. Maybe other functions should be also assigned:
>>HS, SS, CC, SBU, ... whatever. Maybe functions should be described
>>as an additional property of remote node?
> Given that one of the main reasons this binding is needed is to describe MHL
> connection to a USB connector, I think we'll need to define additional
> functions, yes. I'm not sure yet how that should look like though.
Current idea is to encode it in port number.
>
>> ---
>> .../bindings/connector/usb-connector.txt | 49 +++
>> 1 file changed, 49 insertions(+)
>> create mode 100644
>> Documentation/devicetree/bindings/connector/usb-connector.txt
>>
>> diff --git a/Documentation/devicetree/bindings/connector/usb-connector.txt
>> b/Documentation/devicetree/bindings/connector/usb-connector.txt new file
>> mode 100644
>> index ..f3a4e85122d5
>> --- /dev/null
>> +++ b/Documentation/devicetree/bindings/connector/usb-connector.txt
>> @@ -0,0 +1,49 @@
>> +USB Connector
>> +=
>> +
>> +Required properties:
>> +- compatible: "usb-connector"
>> + connectors with vendor specific extensions can add one of additional
>> + compatibles:
>> +"samsung,usb-connector-11pin": 11-pin Samsung micro-USB connector
>> +- type: the USB connector type: "a", "b", "ab", "c"
>> +- max-mode: max USB speed mode supported by the connector:
>> + "ls", "fs", "hs", "ss", "ss+"
>> +
>> +Optional properties:
>> +- label: a symbolic name for the connector
>> +- size: size of the connector, should be specified in case of
>> + non-standard USB connectors: "mini", "micro", "powered"
> "non-standard" sounds like "vendor-specific", while I assume you're talking
> about the size. The USB specification uses the term "standard" for this
> purpose, so it's hard to use another one that would convey the right meaning
> precisely. Maybe "non-standard ('large') USB connector sizes" ?
OK.
And answer for your question from other e-mail:
> One more comment, do I assume correctly that the Samsung 11-pin connector
> carries USB and MHL on different pins ?
Yes, there are three additional pins: MHL_DP, MHL_DN and MHL_ID [1].
[1]:
https://ae01.alicdn.com/kf/HTB1nn.6KVaNXFXXq6xXFXXXc/221542210/HTB1nn.6KVaNXFXXq6xXFXXXc.jpg?size=69211&height=700&width=700&hash=dcababf11610a489d451d7cb0b8ab60e
Thanks
Andrzej
>
>> +Required nodes:
>> +- any data bus to the connector should be modeled using the
>> + OF
[PATCH] perf tools: fix handling read result
The function can return negative value, assigning it to unsigned variable can cause memory corruption. The problem has been detected using proposed semantic patch scripts/coccinelle/tests/unsigned_lesser_than_zero.cocci [1]. [1]: http://permalink.gmane.org/gmane.linux.kernel/2038576 Signed-off-by: Andrzej Hajda --- tools/perf/util/event.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/tools/perf/util/event.c b/tools/perf/util/event.c index cb98b5a..8b10621 100644 --- a/tools/perf/util/event.c +++ b/tools/perf/util/event.c @@ -67,7 +67,8 @@ static int perf_event__get_comm_ids(pid_t pid, char *comm, size_t len, char filename[PATH_MAX]; char bf[4096]; int fd; - size_t size = 0, n; + size_t size = 0; + ssize_t n; char *nl, *name, *tgids, *ppids; *tgid = -1; -- 1.9.1 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC 0/2] drm/dsi: DSI for devices with different control bus
On 09/07/2015 01:46 PM, Archit Taneja wrote:
> Thierry,
>
> On 08/21/2015 11:39 AM, Archit Taneja wrote:
>>
>>
>> On 08/20/2015 05:18 PM, Thierry Reding wrote:
>>> On Thu, Aug 20, 2015 at 09:46:14AM +0530, Archit Taneja wrote:
Hi Thierry, Lucas,
On 08/19/2015 08:32 PM, Thierry Reding wrote:
> On Wed, Aug 19, 2015 at 04:52:24PM +0200, Lucas Stach wrote:
>> Am Mittwoch, den 19.08.2015, 16:34 +0200 schrieb Thierry Reding:
>>> On Wed, Aug 19, 2015 at 04:17:08PM +0200, Lucas Stach wrote:
Hi Thierry, Archit,
>> [...]
> Perhaps a better way would be to invert this relationship.
> According to
> your proposal we'd have to have DT like this:
>
> i2c@... {
> ...
>
> dsi-device@... {
> ...
> dsi-bus = <&dsi>;
> ...
> };
>
> ...
> };
>
> dsi@... {
> ...
> };
>
> Inversing the relationship would become something like this:
>
> i2c@... {
> ...
> };
>
> dsi@... {
> ...
>
> peripheral@... {
> ...
> i2c-bus = <&i2c>;
> ...
> };
>
> ...
> };
>
> Both of those aren't fundamentally different, and they both have
> the
> disavantage of lacking ways to transport configuration data that
> the
> other bus needs to instantiate the dummy device (such as the reg
> property for example, denoting the I2C slave address or the DSI
> VC).
>
> So how about we create two devices in the device tree and fuse
> them at
> the driver level:
>
> i2c@... {
> ...
>
> i2cdsi: dsi-device@... {
> ...
> };
>
> ...
> };
>
> dsi@... {
> ...
>
> peripheral@... {
> ...
> control = <&i2cdsi>;
> ...
> };
>
> ...
> };
>
> This way we'll get both an I2C device and a DSI device that we
> can fully
> describe using the standard device tree bindings. At driver time
> we can
> get the I2C device from the phandle in the control property of
> the DSI
> device and use it to execute I2C transactions.
>
I don't really like to see that you are inventing yet-another-way to
handle devices connected to multiple buses.
Devicetree is structured along the control buses, even if the
devices
are connected to multiple buses, in the DT they are always
children of
the bus that is used to control their registers from the CPUs
perspective. So a DSI encoder that is controlled through i2c is
clearly
a child of the i2c master controller and only of that one.
>>>
>>> I think that's a flawed interpretation of what's going on here. The
>>> device in fact has two interfaces: one is I2C, the other is DSI.
>>> In my
>>> opinion that's reason enough to represent it as two logical devices.
>>>
>> Does it really have 2 control interfaces that are used at the same
>> time?
>> Or is the DSI connection a passive data bus if the register control
>> happens through i2c?
>
> The interfaces may not be used at the same time, and the DSI interface
> may even be crippled, but the device is still addressable from the DSI
> host controller, if for nothing else than for routing the video stream.
>
If you need to model connections between devices that are not
reflected
through the control bus hierarchy you should really consider
using the
standardized of-graph bindings.
(Documentation/devicetree/bindings/graph.txt)
>>>
>>> The problem is that the original proposal would instantiate a dummy
>>> device, so it wouldn't be represented in DT at all. So unless you
>>> do add
>>> two logical devices to DT (one for each bus interface), you don't
>>> have
>>> anything to glue together with an OF graph.
>>>
>> I see that the having dummy device is the least desirable solution.
>> But
>> if there is only one control bus to the device I think it should be
>> one
>> device sitting beneath the control bus.
>>
>> You can then use of-graph to model the data path between the DSI
>> encoder
>> and device.
>
> But you will be needing a device below the DSI
[PATCH v2 14/38] clk: vt8500: fix sign of possible PLL values
With unsigned values underflow in loops can occur resulting in
theoretically infinite loops.
The problem has been detected using proposed semantic patch
scripts/coccinelle/tests/unsigned_lesser_than_zero.cocci [1].
[1]: http://permalink.gmane.org/gmane.linux.kernel/2038576
Signed-off-by: Andrzej Hajda
---
Hi Stephen,
This is modified version according to your request, ie only problematic
variables have changed type.
I still think that 1st version is better, but of course it is up to you.
Regards
Andrzej
drivers/clk/clk-vt8500.c | 9 ++---
1 file changed, 6 insertions(+), 3 deletions(-)
diff --git a/drivers/clk/clk-vt8500.c b/drivers/clk/clk-vt8500.c
index 37e9288..98c4492 100644
--- a/drivers/clk/clk-vt8500.c
+++ b/drivers/clk/clk-vt8500.c
@@ -384,7 +384,8 @@ static void vt8500_find_pll_bits(unsigned long rate,
unsigned long parent_rate,
static void wm8650_find_pll_bits(unsigned long rate, unsigned long parent_rate,
u32 *multiplier, u32 *divisor1, u32 *divisor2)
{
- u32 mul, div1, div2;
+ u32 mul, div1;
+ int div2;
u32 best_mul, best_div1, best_div2;
unsigned long tclk, rate_err, best_err;
@@ -452,7 +453,8 @@ static u32 wm8750_get_filter(u32 parent_rate, u32 divisor1)
static void wm8750_find_pll_bits(unsigned long rate, unsigned long parent_rate,
u32 *filter, u32 *multiplier, u32 *divisor1,
u32 *divisor2)
{
- u32 mul, div1, div2;
+ u32 mul;
+ int div1, div2;
u32 best_mul, best_div1, best_div2;
unsigned long tclk, rate_err, best_err;
@@ -496,7 +498,8 @@ static void wm8750_find_pll_bits(unsigned long rate,
unsigned long parent_rate,
static void wm8850_find_pll_bits(unsigned long rate, unsigned long parent_rate,
u32 *multiplier, u32 *divisor1, u32 *divisor2)
{
- u32 mul, div1, div2;
+ u32 mul;
+ int div1, div2;
u32 best_mul, best_div1, best_div2;
unsigned long tclk, rate_err, best_err;
--
1.9.1
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 14/19] sony-laptop: fix handling sony_nc_hotkeys_decode result
On 10/03/2015 06:39 PM, Darren Hart wrote:
> On Thu, Sep 24, 2015 at 04:00:22PM +0200, Andrzej Hajda wrote:
>> The function can return negative value.
>>
>> The problem has been detected using proposed semantic patch
>> scripts/coccinelle/tests/assign_signed_to_unsigned.cocci [1].
>>
>> [1]: http://permalink.gmane.org/gmane.linux.kernel/2046107
>>
>> Signed-off-by: Andrzej Hajda
> Sorry for the delay Andrsej, and thank you for your patch. Given my delay,
> I've
> made a couple of changes myself rather than asking you to resubmit. Please
> review and let me know if you have any concerns.
Looks OK. Thanks for fixing.
Regards
Andrzej
>
> First, The description above is incomplete and relies on context from the URL
> to fully explain the problem you are fixing. In the future, please ensure the
> commit message is self-sufficient.
>
> I have changed the message to read:
>
> sony-laptop: Fix handling sony_nc_hotkeys_decode result
>
> sony_nv_hotkeys_decode can return a negative value. real_ev is a u32
> variable.
> The check for real_ev > 0 is incorrect.
>
> Use an intermediate ret variable.
>
> The problem has been detected using proposed semantic patch
> scripts/coccinelle/tests/assign_signed_to_unsigned.cocci [1].
>
> [1]: http://permalink.gmane.org/gmane.linux.kernel/2046107
>
> Signed-off-by: Andrzej Hajda
> [dvhart: clarify commit msg, drop superfluous else block]
> Signed-off-by: Darren Hart
>
> See below for an additional change.
>
>> ---
>> Hi,
>>
>> To avoid problems with too many mail recipients I have sent whole
>> patchset only to LKML. Anyway patches have no dependencies.
>>
>> Regards
>> Andrzej
>> ---
>> drivers/platform/x86/sony-laptop.c | 12
>> 1 file changed, 8 insertions(+), 4 deletions(-)
>>
>> diff --git a/drivers/platform/x86/sony-laptop.c
>> b/drivers/platform/x86/sony-laptop.c
>> index aeb80d1..d8a2115 100644
>> --- a/drivers/platform/x86/sony-laptop.c
>> +++ b/drivers/platform/x86/sony-laptop.c
>> @@ -1204,6 +1204,8 @@ static void sony_nc_notify(struct acpi_device *device,
>> u32 event)
>> {
>> u32 real_ev = event;
>> u8 ev_type = 0;
>> +int ret;
>> +
>> dprintk("sony_nc_notify, event: 0x%.2x\n", event);
>>
>> if (event >= 0x90) {
>> @@ -1225,13 +1227,15 @@ static void sony_nc_notify(struct acpi_device
>> *device, u32 event)
>> case 0x0100:
>> case 0x0127:
>> ev_type = HOTKEY;
>> -real_ev = sony_nc_hotkeys_decode(event, handle);
>> +ret = sony_nc_hotkeys_decode(event, handle);
>>
>> -if (real_ev > 0)
>> -sony_laptop_report_input_event(real_ev);
>> -else
>> +if (ret > 0) {
>> +sony_laptop_report_input_event(ret);
>> +real_ev = ret;
>> +} else {
>> /* restore the original event for reporting */
>> real_ev = event;
>> +}
> This 4 line else block is superfluous. real_ev is initialized to event and
> only changed here if ret > 0. Therefore, there is no need to set real_ev to
> event again. I have simply dropped the else block
>
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 2/2] arm64: dts: exynos: Remove unneeded DSI and DECON address/size cells in Exynos5433
On 20.06.2018 21:34, Krzysztof Kozlowski wrote: > On Tue, Jun 19, 2018 at 09:59:04AM +0200, Krzysztof Kozlowski wrote: >> On 19 June 2018 at 09:26, Marek Szyprowski wrote: >>> Hi Krzysztof, >>> >>> On 2018-06-18 19:42, Krzysztof Kozlowski wrote: The decon, decon_tv and dsi nodes have only one child port so address/size mappings are not necessary. This fixes DTC warnings like: Warning (graph_child_address): /soc/decon@1380/ports: graph node has single child node 'port@0', #address-cells/#size-cells are not necessary Signed-off-by: Krzysztof Kozlowski >>> Works fine with current Exynos DRM Decon/MIC/DSI drivers. >>> >>> Tested-by: Marek Szyprowski >> Thanks for review and testing! > I have second thoughs whether this patch is correct. AFAIU, the drivers > get the remote endpoints by reg==0 (for example the > of_graph_get_remote_node() in exynos_dsi_parse_dt()). If the port shall > be ignored, then reg==-1 should be passed. All this is about purity, DECON bindings says explicitly that there should be a port with reg=0. So your patch and DTC warnings are incorrect from bindings PoV. On the other side graph bindings are too bloated ( so many lines to describe one connection ) so I am happy if there are shrinking attempts :) Functionally nothing changes, of graph helpers assume reg=0 if it is not present in port/endpoint node. And regarding real issues, DECON could have more ports, possible candidates: - GSCALER0/1/2, - GSD/DSD - interconnect between GSCALERs and DECONs, - SMIES - image enhancer (not implemented), - MIC0/1 - image enhancers, - DSIM0/1 - DSI encoders, - HDMI - HDMI encoder. But since all these connections can be configured dynamically, and more importantly are inside specific SoC I dont think they need of_graphs. In fact I think current of graph is also not necessary, but this is different story, removal is on my long TODO list :) Regards Andrzej > > Best regards, > Krzysztof > > -- > To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" > in > the body of a message to majord...@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html > > >
Re: [PATCH] i2c: exynos5: Describe the hardware variant for readability
On 19-Jul-18 04:54, Krzysztof Kozlowski wrote:
> The driver supports multiple hardware variants of Exynos I2C controller
> which differ in FIFO depth, handling of interrupts and bus recovery in
> HSI2C_MASTER_ST_LOSE state.
>
> The difference in variant was a single bit set for Exynos7 variants and
> implicit lack of this bit for other variants.
>
> Make each variant explicit which also fixes the GCC warning about
> documentation:
>
> drivers/i2c/busses/i2c-exynos5.c:223: warning: Function parameter or
> member 'hw' not described in 'exynos_hsi2c_variant'
>
> No change in functionality.
>
> Signed-off-by: Krzysztof Kozlowski
Maybe changing it to "bool is_exynos7" or sth like that would make it
little more readable, matter of taste. Anyway:
Reviewed-by: Andrzej Hajda
Regards
Andrzej
> ---
> drivers/i2c/busses/i2c-exynos5.c | 22 ++
> 1 file changed, 14 insertions(+), 8 deletions(-)
>
> diff --git a/drivers/i2c/busses/i2c-exynos5.c
> b/drivers/i2c/busses/i2c-exynos5.c
> index de82ad8ff534..c1ce2299a76e 100644
> --- a/drivers/i2c/busses/i2c-exynos5.c
> +++ b/drivers/i2c/busses/i2c-exynos5.c
> @@ -176,7 +176,10 @@
>
> #define EXYNOS5_I2C_TIMEOUT (msecs_to_jiffies(100))
>
> -#define HSI2C_EXYNOS7BIT(0)
> +enum i2c_type_exynos {
> + I2C_TYPE_EXYNOS5,
> + I2C_TYPE_EXYNOS7,
> +};
>
> struct exynos5_i2c {
> struct i2c_adapter adap;
> @@ -212,27 +215,30 @@ struct exynos5_i2c {
> /**
>* struct exynos_hsi2c_variant - platform specific HSI2C driver data
>* @fifo_depth: the fifo depth supported by the HSI2C module
> + * @hw: the hardware variant of Exynos I2C controller
>*
>* Specifies platform specific configuration of HSI2C module.
>* Note: A structure for driver specific platform data is used for future
>* expansion of its usage.
>*/
> struct exynos_hsi2c_variant {
> - unsigned intfifo_depth;
> - unsigned inthw;
> + unsigned intfifo_depth;
> + enum i2c_type_exynoshw;
> };
>
> static const struct exynos_hsi2c_variant exynos5250_hsi2c_data = {
> .fifo_depth = 64,
> + .hw = I2C_TYPE_EXYNOS5,
> };
>
> static const struct exynos_hsi2c_variant exynos5260_hsi2c_data = {
> .fifo_depth = 16,
> + .hw = I2C_TYPE_EXYNOS5,
> };
>
> static const struct exynos_hsi2c_variant exynos7_hsi2c_data = {
> .fifo_depth = 16,
> - .hw = HSI2C_EXYNOS7,
> + .hw = I2C_TYPE_EXYNOS7,
> };
>
> static const struct of_device_id exynos5_i2c_match[] = {
> @@ -300,7 +306,7 @@ static int exynos5_i2c_set_timing(struct exynos5_i2c
> *i2c, bool hs_timings)
>*/
> t_ftl_cycle = (readl(i2c->regs + HSI2C_CONF) >> 16) & 0x7;
> temp = clkin / op_clk - 8 - t_ftl_cycle;
> - if (i2c->variant->hw != HSI2C_EXYNOS7)
> + if (i2c->variant->hw != I2C_TYPE_EXYNOS7)
> temp -= t_ftl_cycle;
> div = temp / 512;
> clk_cycle = temp / (div + 1) - 2;
> @@ -424,7 +430,7 @@ static irqreturn_t exynos5_i2c_irq(int irqno, void
> *dev_id)
> writel(int_status, i2c->regs + HSI2C_INT_STATUS);
>
> /* handle interrupt related to the transfer status */
> - if (i2c->variant->hw == HSI2C_EXYNOS7) {
> + if (i2c->variant->hw == I2C_TYPE_EXYNOS7) {
> if (int_status & HSI2C_INT_TRANS_DONE) {
> i2c->trans_done = 1;
> i2c->state = 0;
> @@ -571,7 +577,7 @@ static void exynos5_i2c_bus_check(struct exynos5_i2c *i2c)
> {
> unsigned long timeout;
>
> - if (i2c->variant->hw != HSI2C_EXYNOS7)
> + if (i2c->variant->hw != I2C_TYPE_EXYNOS7)
> return;
>
> /*
> @@ -612,7 +618,7 @@ static void exynos5_i2c_message_start(struct exynos5_i2c
> *i2c, int stop)
> unsigned long flags;
> unsigned short trig_lvl;
>
> - if (i2c->variant->hw == HSI2C_EXYNOS7)
> + if (i2c->variant->hw == I2C_TYPE_EXYNOS7)
> int_en |= HSI2C_INT_I2C_TRANS;
> else
> int_en |= HSI2C_INT_I2C;
Re: [PATCH v3 1/9] drm/exynos: rename "bridge_node" to "mic_bridge_node"
On 24.07.2018 09:49, Inki Dae wrote:
> Hi,
>
> 2018년 06월 19일 17:19에 Maciej Purski 이(가) 쓴 글:
>> When adding support for peripheral out bridges, the "bridge" name
>> becomes imprecise as it refers to a different device than the
>> "out_bridge".
> Could you give me more details? I'm afriad that I don't understand what you
> say.
The problem is that MIC is an input bridge and now we will have also
output bridge (Toshiba DSI/LVDS converter).
So we will have to distinguish them.
>
> And in case of Exynos5433 SoC, SMIES(Samsung Mobile Image Enhancement System)
> can be located between DECON and MIPI-DSI devices also.
> Therefore, having specific name isn't reasonable.
So probably in_bridge would be a better name. I will rephrase message
and bridge name.
Regars
Andrzej
>
> Thanks,
> Inki Dae
>
>> Signed-off-by: Maciej Purski
>> ---
>> drivers/gpu/drm/exynos/exynos_drm_dsi.c | 16
>> 1 file changed, 8 insertions(+), 8 deletions(-)
>>
>> diff --git a/drivers/gpu/drm/exynos/exynos_drm_dsi.c
>> b/drivers/gpu/drm/exynos/exynos_drm_dsi.c
>> index eae44fd..9599e6b 100644
>> --- a/drivers/gpu/drm/exynos/exynos_drm_dsi.c
>> +++ b/drivers/gpu/drm/exynos/exynos_drm_dsi.c
>> @@ -279,7 +279,7 @@ struct exynos_dsi {
>> struct list_head transfer_list;
>>
>> const struct exynos_dsi_driver_data *driver_data;
>> -struct device_node *bridge_node;
>> +struct device_node *mic_bridge_node;
>> };
>>
>> #define host_to_dsi(host) container_of(host, struct exynos_dsi, dsi_host)
>> @@ -1631,7 +1631,7 @@ static int exynos_dsi_parse_dt(struct exynos_dsi *dsi)
>> if (ret < 0)
>> return ret;
>>
>> -dsi->bridge_node = of_graph_get_remote_node(node, DSI_PORT_IN, 0);
>> +dsi->mic_bridge_node = of_graph_get_remote_node(node, DSI_PORT_IN, 0);
>>
>> return 0;
>> }
>> @@ -1642,7 +1642,7 @@ static int exynos_dsi_bind(struct device *dev, struct
>> device *master,
>> struct drm_encoder *encoder = dev_get_drvdata(dev);
>> struct exynos_dsi *dsi = encoder_to_dsi(encoder);
>> struct drm_device *drm_dev = data;
>> -struct drm_bridge *bridge;
>> +struct drm_bridge *mic_bridge;
>> int ret;
>>
>> drm_encoder_init(drm_dev, encoder, &exynos_dsi_encoder_funcs,
>> @@ -1661,10 +1661,10 @@ static int exynos_dsi_bind(struct device *dev,
>> struct device *master,
>> return ret;
>> }
>>
>> -if (dsi->bridge_node) {
>> -bridge = of_drm_find_bridge(dsi->bridge_node);
>> -if (bridge)
>> -drm_bridge_attach(encoder, bridge, NULL);
>> +if (dsi->mic_bridge_node) {
>> +mic_bridge = of_drm_find_bridge(dsi->mic_bridge_node);
>> +if (mic_bridge)
>> +drm_bridge_attach(encoder, mic_bridge, NULL);
>> }
>>
>> return mipi_dsi_host_register(&dsi->dsi_host);
>> @@ -1783,7 +1783,7 @@ static int exynos_dsi_remove(struct platform_device
>> *pdev)
>> {
>> struct exynos_dsi *dsi = platform_get_drvdata(pdev);
>>
>> -of_node_put(dsi->bridge_node);
>> +of_node_put(dsi->mic_bridge_node);
>>
>> pm_runtime_disable(&pdev->dev);
>>
>>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc"
> in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
>
Re: [PATCH] drm/bridge/synopsys: dsi: use common mipi_dsi_create_packet()
On 24.01.2018 10:51, Philippe CORNU wrote: > Hi Brian, > > On 01/23/2018 10:15 PM, Brian Norris wrote: >> Hi Philippe, >> >> On Thu, Jan 18, 2018 at 11:40:48AM +, Philippe CORNU wrote: >>> On 01/11/2018 12:16 PM, Philippe CORNU wrote: To be honest, I do not really like the memcpy here too and I agree with you regarding the BE issue. My first "stm" driver (ie. before using this "freescale/rockchip" dw-mipi-dsi driver with the memcpy) used the "exact" same code as the Tegra dsi tegra_dsi_writesl() function with the 2 loops. https://elixir.free-electrons.com/linux/v4.14/source/drivers/gpu/drm/tegra/dsi.c#L1248 IMHO, it is better than memcpy... I added these 3 "documentation" lines, maybe we may reuse them or something similar... /* * Write 8-bit payload data into the 32-bit payload data register. * ex: payload data "0x01, 0x02, 0x03, 0x04, 0x05, 0x06" will become * "0x04030201 0x0605" 32-bit writes */ Not sure it helps to fix the BE issue but we may add a TODO stating that "this loop has not been tested on BE"... What is your opinion? >> I'm sorry, I don't think I noticed your reply here. I'm trying to unbury >> some email, but that's sometimes a losing battle... >> >> That code actually does look correct, and it's perhaps marginally >> better-looking in my opinion. It's up to you if you want to propose >> another patch :) At this point, it's only a matter of nice code, not >> correctness I believe. >> >>> As your patch has been merged, I have few short questions and for each >>> related new patch, I would like to know if you prefer that I implement >>> it or if you prefer to do it by yourself, it's really like you want, on >>> my side, no problem to make them all, some or none, I don't want us to >>> implement these in parallel :-) >>> >>> * Do you have any opinion regarding Tegra-like loops vs the memcpy? (see >>> my comment above) If you think the Tegra-like loops is a better approach >>> than memcpy, there is a small patch to write. >> My opinion is above. >> > I do not know yet if I will send a patch but several reasons may push me > to do it: > * Andrzej proposed a nicer code in his last review so it means the > actual code with memcpy's is "not so nice" (even if it works fine) I was not against memcpy, I have just suggested to abstract the code out to some helper function. Regarding memcpy vs loop I would prefer memcpy - simpler code, but it is looks less important that abstracting out. Regards Andrzej > * Several dsi drivers use the Tegra-like loops (Tegra, intel,... ) and > in vc4/exynos/mtk drivers memcpy is not used, msm uses memcpy... well, > not sure it is then a good argument, different solutions for different hw... > * Coming cadence dsi bridge driver uses Tegra-like loops. > * I think my read function will also have Tegra-like loops, if it is the > case, it could be nice to have something homogeneous... > > Anyway, it is not an important point : ) > >>> * Returned value with number of bytes received/transferred: there is a >>> small patch to write >> I don't think I followed that one very well. I'm not sure my opinion >> really matters, as long as you get someone else to agree. I do not plan >> to write any such patch in the near term. >> >>> * Regarding read operations: I propose to add a TODO + DRM_WARN in case >>> someone want to use the API for read operations. Note that I plan to >>> implement the read feature but I do not know yet when and maybe Rockchip >>> people already have something ~ready? >> The warning would be nice to do now, regardless. >> >> Rockchip folks wrote up something for read support here [1], but it's >> based on a semi-forked version of the driver (we're trying to clean up >> the divergence, but it's not there yet). Perhaps it would provide useful >> fodder for your work. I don't think Rockchip is immediately working on >> upstreaming this particular patch, so it's totally fair to handle it >> yourself. It's got the GPL sign-off ;) >> >> Brian >> >> [1] >> https://chromium-review.googlesource.com/c/chromiumos/third_party/kernel/+/863347 >> > Very good information, I will have a look, > many thanks > Philippe :-)
Re: [PATCH v1 1/2] drm/bridge/synopsys: dsi: Fix dsi_host_transfer() return value
On 24.01.2018 19:37, Brian Norris wrote: > Hi Philippe, > > On Wed, Jan 24, 2018 at 01:33:54PM +, Philippe CORNU wrote: >> On 01/23/2018 10:38 PM, Brian Norris wrote: >>> Hi Philippe, >>> >>> On Tue, Jan 23, 2018 at 6:26 AM, Philippe Cornu >>> wrote: The dw_mipi_dsi_host_transfer() must return the number of bytes transmitted/received on success instead of 0. >>> I'm a little confused. As of the latest drm-misc-next I'm looking at, >>> this still has conflicting documentation. >>> >>> For ->transfer(): >>> >>> On success it shall return the number of bytes >>> * transmitted for write packets or the number of bytes received for read >>> * packets. >>> >>> While mipi_dsi_generic_read() says: >>> >>> * Return: The number of bytes successfully read or a negative error code >>> on >>> * failure. >>> >>> But it just returns the value that ->transfer() returns. >>> >> Not sure to follow you here: mipi_dsi_generic_read() will trig a dsi >> generic read so it has to return "the number of bytes received for read >> packets" as explained for the ->transfer() function... so it looks >> "coherent"... >> >> But maybe you want to point out something different? > Actually, reading back what I wrote, I'm not sure it made sense. I think > *I* was confusing "supporting TX only" with "supporting TX and RX". I > believe the documentation isn't conflicting, but your current patch is a > little misleading. > > With your current patch, you're returning the 'mipi_dsi_packet::size', > which is the sum of both TX and RX. I did not found docs saying mipi_dsi_packet::size is a sum of tx and rx. tx and rx packets are two different packets, so they do not sum up. But thanks for bringing it up, it shows docs are incomplete/misleading. > Since we only support TX right now, > I suppose that actually is fine (because 'rx_len == 0'). But if we start > supporting RX too, then this field is not the right one to return. > > Anyway, maybe this patch was fine as it was. But when you get RX > support, this will have to be something like: > > if (msg->rx_len) > return msg->rx_len; > else > return packet.size; > > BTW, does anyone actually care about seeing the number of TX bytes > returned? That seems weird, because I wouldn't expect you'd get a good > result from a partial TX (dunno about partial RX). And I also see that > there are other drivers that get this all wrong too. See > mtk_dsi_host_transfer(), which only returns 0 for TX and 'recv_cnt' for > RX. As far as I remember MIPI DSI standard does not allow partial TX, it is all-or-nothing operation. > > So all-in-all, maybe my problem isn't that the documentation is > conflicting, exactly, but that the requirements are somewhat odd, such > that either implementations get it wrong (2 of 3 that I've looked at!), > or they have to write somewhat odd special-casing. mipi_dsi_host_ops::transfer in case of write sends only tx packet, in case of read it sends tx packets and receives rx packet, so it can be confusing what it should return in case of read. IMO changing mipi_dsi_host_ops::transfer to always return number of bytes RECEIVED or error should make it clearer and simpler. +CC Thierry Regards Andrzej > >>> So I'm not sure whether the documentation is still wrong, or if the >>> implementation is. >>> >>> Anyway, I guess maybe that isn't super-critical to *this* patch, since >>> we don't have RX support yet... >>> >> The main reason why I want to "fix" this is because I do not want to >> explain to our customers (writing dsi panel drivers) why we have a >> different returned value compare to other platforms : ) > Brian > ___ > dri-devel mailing list > dri-de...@lists.freedesktop.org > https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v3 0/6] Introduce new mode validation callbacks
On 12.05.2017 09:32, Daniel Vetter wrote:
> On Thu, May 11, 2017 at 10:05:56AM +0100, Jose Abreu wrote:
>> This series is a follow up from the discussion at [1]. We start by
>> introducing crtc->mode_valid(), encoder->mode_valid() and
>> bridge->mode_valid() callbacks which will be used in followup
>> patches and also by cleaning the documentation a little bit.
>>
>> We proceed by introducing new helpers to call this new callbacks
>> at 2/6.
>>
>> At 3/6 a helper function is introduced that calls all mode_valid()
>> from a set of bridges.
>>
>> Next, at 4/6 we modify the connector probe helper so that only modes
>> which are supported by a given bridge+encoder+crtc combination are
>> probbed.
>>
>> At 5/6 we call all the mode_valid() callbacks for a given pipeline,
>> except the connector->mode_valid one, so that the mode is validated.
>> This is done before calling mode_fixup().
>>
>> Finally, at 6/6 we use the new crtc->mode_valid() callback in arcpgu
>> and remove the atomic_check() callback.
>>
>> [1] https://patchwork.kernel.org/patch/9702233/
>>
>> Jose Abreu (6):
>> drm: Add crtc/encoder/bridge->mode_valid() callbacks
>> drm: Add drm_{crtc/encoder/connector}_mode_valid()
>> drm: Introduce drm_bridge_mode_valid()
>> drm: Use new mode_valid() helpers in connector probe helper
>> drm: Use mode_valid() in atomic modeset
>> drm: arc: Use crtc->mode_valid() callback
>>
>> Cc: Carlos Palminha
>> Cc: Alexey Brodkin
>> Cc: Ville Syrjälä
>> Cc: Daniel Vetter
>> Cc: Dave Airlie
>> Cc: Andrzej Hajda
>> Cc: Archit Taneja
> Commented with an entire patch on patch 1, patches 2-5 are all
>
> Reviewed-by: Daniel Vetter
>
> But I think some more acks/r-bs would be really good, since this is quite
> a bit change in the helper infrastructure. But otherwise ready for merging
> imo. Can you pls also review my proposal for patch 1?
>
> Thanks, Daniel
As the patchset improves many things, I would like to point here that
there are still issues with mode probing at least in case of panels.
Panels in general does not provide discrete list of supported modes, but
they provide list of supported mode ranges (named display_timings), at
the moment this is only addressed in drm_panel_funcs::get_timings, but
drm core does not use it at all.
Currently most of the panel drivers advertises only fixed list of
arbitrary chosen modes, and if bridge/connector/encoder/crtc does not
support it pipeline does not work, even if slightly different
configuration could work. Of course there are workarounds but maybe it
would be good to replace drm_connector::modes with drm_connector::timings.
This way set of valid timings of the whole pipeline will be intersection
of sets of valid timings of every component of the pipeline - quite
straightforward and simple construct.
As this is just an idea which came to me during patchset review, it is
not backed by any code, but maybe it can be interesting for quick
brainstorm.
Regards
Andrzej
>
>> drivers/gpu/drm/arc/arcpgu_crtc.c | 39 ++
>> drivers/gpu/drm/drm_atomic_helper.c| 76 +++-
>> drivers/gpu/drm/drm_bridge.c | 33 +
>> drivers/gpu/drm/drm_crtc_helper_internal.h | 13
>> drivers/gpu/drm/drm_probe_helper.c | 103 ++-
>> include/drm/drm_bridge.h | 22 ++
>> include/drm/drm_modeset_helper_vtables.h | 110
>> ++---
>> 7 files changed, 348 insertions(+), 48 deletions(-)
>>
>> --
>> 1.9.1
>>
>>
Re: [PATCH v3 2/6] drm: Add drm_{crtc/encoder/connector}_mode_valid()
On 11.05.2017 11:05, Jose Abreu wrote:
> Add a new helper to call crtc->mode_valid, connector->mode_valid
> and encoder->mode_valid callbacks.
>
> Suggested-by: Ville Syrjälä
> Signed-off-by: Jose Abreu
> Cc: Carlos Palminha
> Cc: Alexey Brodkin
> Cc: Ville Syrjälä
> Cc: Daniel Vetter
> Cc: Dave Airlie
> Cc: Andrzej Hajda
> Cc: Archit Taneja
> ---
> Changes v2->v3:
> - Move helpers to drm_probe_helper.c (Daniel)
> - Squeeze patches that introduce the helpers into a single
> one (Daniel)
>
> drivers/gpu/drm/drm_crtc_helper_internal.h | 13 ++
> drivers/gpu/drm/drm_probe_helper.c | 38
> ++
> 2 files changed, 51 insertions(+)
>
> diff --git a/drivers/gpu/drm/drm_crtc_helper_internal.h
> b/drivers/gpu/drm/drm_crtc_helper_internal.h
> index 28295e5..97dfe20 100644
> --- a/drivers/gpu/drm/drm_crtc_helper_internal.h
> +++ b/drivers/gpu/drm/drm_crtc_helper_internal.h
> @@ -26,7 +26,11 @@
> * implementation details and are not exported to drivers.
> */
>
> +#include
> +#include
> #include
> +#include
> +#include
>
> /* drm_fb_helper.c */
> #ifdef CONFIG_DRM_FBDEV_EMULATION
> @@ -62,4 +66,13 @@ static inline int drm_dp_aux_register_devnode(struct
> drm_dp_aux *aux)
> static inline void drm_dp_aux_unregister_devnode(struct drm_dp_aux *aux)
> {
> }
> +
> +/* drm_probe_helper.c */
> +enum drm_mode_status drm_crtc_mode_valid(struct drm_crtc *crtc,
> + const struct drm_display_mode *mode);
> +enum drm_mode_status drm_encoder_mode_valid(struct drm_encoder *encoder,
> + const struct drm_display_mode
> *mode);
> +enum drm_mode_status drm_connector_mode_valid(struct drm_connector
> *connector,
> + struct drm_display_mode *mode);
> +
> #endif
> diff --git a/drivers/gpu/drm/drm_probe_helper.c
> b/drivers/gpu/drm/drm_probe_helper.c
> index 1b0c14a..f01abdc 100644
> --- a/drivers/gpu/drm/drm_probe_helper.c
> +++ b/drivers/gpu/drm/drm_probe_helper.c
> @@ -38,6 +38,9 @@
> #include
> #include
> #include
> +#include
> +
> +#include "drm_crtc_helper_internal.h"
>
> /**
> * DOC: output probing helper overview
> @@ -113,6 +116,41 @@ static int drm_helper_probe_add_cmdline_mode(struct
> drm_connector *connector)
> return 1;
> }
>
> +enum drm_mode_status drm_crtc_mode_valid(struct drm_crtc *crtc,
> + const struct drm_display_mode *mode)
> +{
> + const struct drm_crtc_helper_funcs *crtc_funcs = crtc->helper_private;
> +
> + if (!crtc_funcs || !crtc_funcs->mode_valid)
> + return MODE_OK;
> +
> + return crtc_funcs->mode_valid(crtc, mode);
> +}
> +
> +enum drm_mode_status drm_encoder_mode_valid(struct drm_encoder *encoder,
> + const struct drm_display_mode *mode)
> +{
> + const struct drm_encoder_helper_funcs *encoder_funcs =
> + encoder->helper_private;
> +
> + if (!encoder_funcs || !encoder_funcs->mode_valid)
> + return MODE_OK;
> +
> + return encoder_funcs->mode_valid(encoder, mode);
> +}
> +
> +enum drm_mode_status drm_connector_mode_valid(struct drm_connector
> *connector,
> + struct drm_display_mode *mode)
> +{
> + const struct drm_connector_helper_funcs *connector_funcs =
> + connector->helper_private;
> +
> + if (!connector_funcs || !connector_funcs->mode_valid)
> + return MODE_OK;
> +
> + return connector_funcs->mode_valid(connector, mode);
> +}
> +
"Copy/Paste" as the main generic programming technique in C :)
I guess clever/scary macro wouldn't be an option.
Anyway:
Reviewed-by: Andrzej Hajda
--
Regards
Andrzej
> #define DRM_OUTPUT_POLL_PERIOD (10*HZ)
> /**
> * drm_kms_helper_poll_enable - re-enable output polling.
Re: [PATCH v3 4/6] drm: Use new mode_valid() helpers in connector probe helper
On 11.05.2017 11:06, Jose Abreu wrote:
> This changes the connector probe helper function to use the new
> encoder->mode_valid(), bridge->mode_valid() and crtc->mode_valid()
> helper callbacks to validate the modes.
>
> The new callbacks are optional so the behaviour remains the same
> if they are not implemented. If they are, then the code loops
> through all the connector's encodersXbridgesXcrtcs and calls the
> callback.
>
> If at least a valid encoderXbridgeXcrtc combination is found which
> accepts the mode then the function returns MODE_OK.
>
> Signed-off-by: Jose Abreu
> Cc: Carlos Palminha
> Cc: Alexey Brodkin
> Cc: Ville Syrjälä
> Cc: Daniel Vetter
> Cc: Dave Airlie
> Cc: Andrzej Hajda
> Cc: Archit Taneja
> ---
>
> Changes v2->v3:
> - Call also bridge->mode_valid (Daniel)
> Changes v1->v2:
> - Use new helpers suggested by Ville
> - Change documentation (Daniel)
>
> drivers/gpu/drm/drm_probe_helper.c | 65
> --
> 1 file changed, 62 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/gpu/drm/drm_probe_helper.c
> b/drivers/gpu/drm/drm_probe_helper.c
> index f01abdc..84d660e 100644
> --- a/drivers/gpu/drm/drm_probe_helper.c
> +++ b/drivers/gpu/drm/drm_probe_helper.c
> @@ -83,6 +83,61 @@
> return MODE_OK;
> }
>
> +static enum drm_mode_status
> +drm_mode_validate_connector(struct drm_connector *connector,
> + struct drm_display_mode *mode)
> +{
> + struct drm_device *dev = connector->dev;
> + uint32_t *ids = connector->encoder_ids;
> + enum drm_mode_status ret = MODE_OK;
> + unsigned int i;
> +
> + /* Step 1: Validate against connector */
> + ret = drm_connector_mode_valid(connector, mode);
> + if (ret != MODE_OK)
> + return ret;
> +
> + /* Step 2: Validate against encoders and crtcs */
> + for (i = 0; i < DRM_CONNECTOR_MAX_ENCODER; i++) {
> + struct drm_encoder *encoder = drm_encoder_find(dev, ids[i]);
> + struct drm_crtc *crtc;
> +
> + if (!encoder)
> + continue;
> +
> + ret = drm_encoder_mode_valid(encoder, mode);
> + if (ret != MODE_OK) {
> + /* No point in continuing for crtc check as this encoder
> + * will not accept the mode anyway. If all encoders
> + * reject the mode then, at exit, ret will not be
> + * MODE_OK. */
> + continue;
> + }
> +
> + ret = drm_bridge_mode_valid(encoder->bridge, mode);
> + if (ret != MODE_OK) {
> + /* There is also no point in continuing for crtc check
> + * here. */
> + continue;
> + }
Maybe it is a bikeshedding, but wouldn't be better to call
drm_bridge_mode_valid from drm_encoder_mode_valid, in general call all
bridge related stuff from corresponding encoder stuff?
This is more question about role of encoder->bridge, should it be
treated as encoder's extension, or as 1st class citizen in drm?
Another concern is about order of calls, it is from sink to source, to
keep it consistent bridge should be called before encoder, am I right?
Beside this:
Reviewed-by: Andrzej Hajda
--
Regards
Andrzej
> +
> + drm_for_each_crtc(crtc, dev) {
> + if (!drm_encoder_crtc_ok(encoder, crtc))
> + continue;
> +
> + ret = drm_crtc_mode_valid(crtc, mode);
> + if (ret == MODE_OK) {
> + /* If we get to this point there is at least
> + * one combination of encoder+crtc that works
> + * for this mode. Lets return now. */
> + return ret;
> + }
> + }
> + }
> +
> + return ret;
> +}
> +
> static int drm_helper_probe_add_cmdline_mode(struct drm_connector *connector)
> {
> struct drm_cmdline_mode *cmdline_mode;
> @@ -322,7 +377,11 @@ void drm_kms_helper_poll_enable(struct drm_device *dev)
> *- drm_mode_validate_flag() checks the modes against basic connector
> * capabilities (interlace_allowed,doublescan_allowed,stereo_allowed)
> *- the optional &drm_connector_helper_funcs.mode_valid helper can
> perform
> - * driver and/or hardware specific checks
> + * driver and/or sink specific checks
> + *- the optional &drm_crtc_helper_funcs.mode_valid,
> + * &drm_bridge_funcs
Re: [PATCH v3 5/6] drm: Use mode_valid() in atomic modeset
On 11.05.2017 11:06, Jose Abreu wrote: > This patches makes use of the new mode_valid() callbacks introduced > previously to validate the full video pipeline when modesetting. > > This calls the encoder->mode_valid(), bridge->mode_valid() and > crtc->mode_valid() so that we can make sure that the mode will > be accepted in every components. > > Signed-off-by: Jose Abreu > Cc: Carlos Palminha > Cc: Alexey Brodkin > Cc: Ville Syrjälä > Cc: Daniel Vetter > Cc: Dave Airlie > Cc: Andrzej Hajda > Cc: Archit Taneja Reviewed-by: Andrzej Hajda -- Regards Andrzej
Re: [PATCH v3 6/6] drm: arc: Use crtc->mode_valid() callback
On 11.05.2017 11:06, Jose Abreu wrote: > Now that we have a callback to check if crtc supports a given mode > we can use it in arcpgu so that we restrict the number of probbed > modes to the ones we can actually display. > > This is specially useful because arcpgu crtc is responsible to set > a clock value in the commit() stage but unfortunatelly this clock > does not support all the needed ranges. > > Also, remove the atomic_check() callback as mode_valid() callback > will be called before. > > Signed-off-by: Jose Abreu > Cc: Carlos Palminha > Cc: Alexey Brodkin > Cc: Ville Syrjälä > Cc: Daniel Vetter > Cc: Dave Airlie > Cc: Andrzej Hajda > Cc: Archit Taneja Reviewed-by: Andrzej Hajda -- Regards Andrzej
Re: [PATCH v3 4/6] drm: Use new mode_valid() helpers in connector probe helper
On 15.05.2017 11:30, Daniel Vetter wrote:
> On Mon, May 15, 2017 at 10:39:35AM +0200, Andrzej Hajda wrote:
>> On 11.05.2017 11:06, Jose Abreu wrote:
>>> This changes the connector probe helper function to use the new
>>> encoder->mode_valid(), bridge->mode_valid() and crtc->mode_valid()
>>> helper callbacks to validate the modes.
>>>
>>> The new callbacks are optional so the behaviour remains the same
>>> if they are not implemented. If they are, then the code loops
>>> through all the connector's encodersXbridgesXcrtcs and calls the
>>> callback.
>>>
>>> If at least a valid encoderXbridgeXcrtc combination is found which
>>> accepts the mode then the function returns MODE_OK.
>>>
>>> Signed-off-by: Jose Abreu
>>> Cc: Carlos Palminha
>>> Cc: Alexey Brodkin
>>> Cc: Ville Syrjälä
>>> Cc: Daniel Vetter
>>> Cc: Dave Airlie
>>> Cc: Andrzej Hajda
>>> Cc: Archit Taneja
>>> ---
>>>
>>> Changes v2->v3:
>>> - Call also bridge->mode_valid (Daniel)
>>> Changes v1->v2:
>>> - Use new helpers suggested by Ville
>>> - Change documentation (Daniel)
>>>
>>> drivers/gpu/drm/drm_probe_helper.c | 65
>>> --
>>> 1 file changed, 62 insertions(+), 3 deletions(-)
>>>
>>> diff --git a/drivers/gpu/drm/drm_probe_helper.c
>>> b/drivers/gpu/drm/drm_probe_helper.c
>>> index f01abdc..84d660e 100644
>>> --- a/drivers/gpu/drm/drm_probe_helper.c
>>> +++ b/drivers/gpu/drm/drm_probe_helper.c
>>> @@ -83,6 +83,61 @@
>>> return MODE_OK;
>>> }
>>>
>>> +static enum drm_mode_status
>>> +drm_mode_validate_connector(struct drm_connector *connector,
>>> + struct drm_display_mode *mode)
>>> +{
>>> + struct drm_device *dev = connector->dev;
>>> + uint32_t *ids = connector->encoder_ids;
>>> + enum drm_mode_status ret = MODE_OK;
>>> + unsigned int i;
>>> +
>>> + /* Step 1: Validate against connector */
>>> + ret = drm_connector_mode_valid(connector, mode);
>>> + if (ret != MODE_OK)
>>> + return ret;
>>> +
>>> + /* Step 2: Validate against encoders and crtcs */
>>> + for (i = 0; i < DRM_CONNECTOR_MAX_ENCODER; i++) {
>>> + struct drm_encoder *encoder = drm_encoder_find(dev, ids[i]);
>>> + struct drm_crtc *crtc;
>>> +
>>> + if (!encoder)
>>> + continue;
>>> +
>>> + ret = drm_encoder_mode_valid(encoder, mode);
>>> + if (ret != MODE_OK) {
>>> + /* No point in continuing for crtc check as this encoder
>>> +* will not accept the mode anyway. If all encoders
>>> +* reject the mode then, at exit, ret will not be
>>> +* MODE_OK. */
>>> + continue;
>>> + }
>>> +
>>> + ret = drm_bridge_mode_valid(encoder->bridge, mode);
>>> + if (ret != MODE_OK) {
>>> + /* There is also no point in continuing for crtc check
>>> +* here. */
>>> + continue;
>>> + }
>> Maybe it is a bikeshedding, but wouldn't be better to call
>> drm_bridge_mode_valid from drm_encoder_mode_valid, in general call all
>> bridge related stuff from corresponding encoder stuff?
>> This is more question about role of encoder->bridge, should it be
>> treated as encoder's extension, or as 1st class citizen in drm?
>>
>> Another concern is about order of calls, it is from sink to source, to
>> keep it consistent bridge should be called before encoder, am I right?
> For the atomic_check stuff (where we do change the passed-in mode) this
> would be correct, and calling order and layering would matter. But this
> just validates the mode in turn with everything, not taking any
> cross-component constraint or other configuration-dependent constraints
> into account. Hence it doesn't matter in which order we call stuff.
>
> Note that the passed-in mode is const, so you can't escape. And v3 of
> patch 1 now has added wording that you're not allowed to look at anything
> else dynamie either.
>
> Does that address your concern?
Yes, I know it practically does not matter. I have mistakenly written
"B
Re: [PATCH v2 1/2] drm/bridge/synopsys: dsi: use common mipi_dsi_create_packet()
On 11.01.2018 14:51, Philippe CORNU wrote:
> Hi Brian & All *DSI DRM experts*,
>
> 1) Re-reading this patch, I realize that the returned value of
> dw_mipi_dsi_host_transfer() is not correct: we should return the number
> of transfered/received bytes...
>
> so I think there are two solutions: fix this in this serie or add a TODO
> for later (both solutions are fine to me :-)
>
>
> 2) Digging more into the drm code, the function
> mipi_dsi_device_transfer() in drm_mipi_dsi.c is called in the same file
> by the 3 following functions: mipi_dsi_shutdown_peripheral(),
> mipi_dsi_turn_on_peripheral() &
> mipi_dsi_set_maximum_return_packet_size(). All these 3 functions are
> expecting "Return: 0 on success or a negative error code on failure."
> that is not in line with the transfer function.
>
> So then, we can change the documentation in this file and have instead
> "* Return: The number of bytes transmitted on success or a negative
> error code on failure." as for mipi_dsi_generic_write()...
> Or we can change the source code of these 3 functions to match with the
> documentation "Return: 0 on success...".
>
> note: Hopefully, "users" of these 3 functions test the sign of the
> return value (or do not use it).
>
> Does anyone have a preferred solutions?
All three functions performs single operation which can succeed only in
one way, nobody is interested in the number of bytes send to achieve the
result. So IMO the result should be 0 or error.
And mipi_dsi_device_transfer() is a different beast, it returns number
of written/read bytes, which can vary (more specifically, only number of
read bytes can vary :) ).
Regards
Andrzej
>
> Many thanks
> Philippe :-)
>
> On 01/09/2018 09:32 PM, Brian Norris wrote:
>> This takes care of 2 TODOs in this driver, by using the common DSI
>> packet-marshalling code instead of our custom short/long write code.
>> This both saves us some duplicated code and gets us free support for
>> command types that weren't already part of our switch block (e.g.,
>> MIPI_DSI_GENERIC_LONG_WRITE).
>>
>> The code logic stays mostly intact, except that it becomes unnecessary
>> to split the short/long write functions, and we have to copy data a bit
>> more.
>>
>> Along the way, I noticed that loop bounds were a little odd:
>>
>> while (DIV_ROUND_UP(len, pld_data_bytes))
>>
>> This really was just supposed to be 'len != 0', so I made that more
>> clear.
>>
>> Tested on RK3399 with some pending refactoring patches by Nickey Yang,
>> to make the Rockchip DSI driver wrap this common driver.
>>
>> Signed-off-by: Brian Norris
>> Reviewed-by: Philippe Cornu
>> Tested-by: Philippe Cornu
>> ---
>> v2:
>> * remove "dcs" naming, since these commands handle generic DSI too, not
>> just DCS (thanks Philippe)
>> * add Philippe's {Tested,Reviewed}-by
>> ---
>> drivers/gpu/drm/bridge/synopsys/dw-mipi-dsi.c | 78
>> ++-
>> 1 file changed, 16 insertions(+), 62 deletions(-)
>>
>> diff --git a/drivers/gpu/drm/bridge/synopsys/dw-mipi-dsi.c
>> b/drivers/gpu/drm/bridge/synopsys/dw-mipi-dsi.c
>> index d9cca4fd66ec..ed91e32ee43a 100644
>> --- a/drivers/gpu/drm/bridge/synopsys/dw-mipi-dsi.c
>> +++ b/drivers/gpu/drm/bridge/synopsys/dw-mipi-dsi.c
>> @@ -136,10 +136,6 @@
>> GEN_SW_0P_TX_LP)
>>
>> #define DSI_GEN_HDR0x6c
>> -/* TODO These 2 defines will be reworked thanks to mipi_dsi_create_packet()
>> */
>> -#define GEN_HDATA(data) (((data) & 0x) << 8)
>> -#define GEN_HTYPE(type) (((type) & 0xff) << 0)
>> -
>> #define DSI_GEN_PLD_DATA 0x70
>>
>> #define DSI_CMD_PKT_STATUS 0x74
>> @@ -359,44 +355,15 @@ static int dw_mipi_dsi_gen_pkt_hdr_write(struct
>> dw_mipi_dsi *dsi, u32 hdr_val)
>> return 0;
>> }
>>
>> -static int dw_mipi_dsi_dcs_short_write(struct dw_mipi_dsi *dsi,
>> - const struct mipi_dsi_msg *msg)
>> -{
>> -const u8 *tx_buf = msg->tx_buf;
>> -u16 data = 0;
>> -u32 val;
>> -
>> -if (msg->tx_len > 0)
>> -data |= tx_buf[0];
>> -if (msg->tx_len > 1)
>> -data |= tx_buf[1] << 8;
>> -
>> -if (msg->tx_len > 2) {
>> -dev_err(dsi->dev, "too long tx buf length %zu for short
>> write\n",
>> -msg->tx_len);
>> -return -EINVAL;
>> -}
>> -
>> -val = GEN_HDATA(data) | GEN_HTYPE(msg->type);
>> -return dw_mipi_dsi_gen_pkt_hdr_write(dsi, val);
>> -}
>> -
>> -static int dw_mipi_dsi_dcs_long_write(struct dw_mipi_dsi *dsi,
>> - const struct mipi_dsi_msg *msg)
>> +static int dw_mipi_dsi_write(struct dw_mipi_dsi *dsi,
>> + const struct mipi_dsi_packet *packet)
>> {
>> -const u8 *tx_buf = msg->tx_buf;
>> -int len = msg->tx_len, pld_data_bytes = sizeof(u32), ret;
>> -u32 hdr_val = GEN_HDATA(msg->tx_len) | GEN_HTYPE(msg->type);
>>
[RFC PATCH v2 1/5] dt-bindings: add bindings for USB physical connector
These bindings allow to describe most known standard USB connectors
and it should be possible to extend it if necessary.
USB connectors, beside USB can be used to route other protocols,
for example UART, Audio, MHL. In such case every device passing data
through the connector should have appropriate graph bindings.
Signed-off-by: Andrzej Hajda
---
v2:
- moved connector type(A,B,C) to compatible string (Rob),
- renamed size property to type (Rob),
- changed type description to be less confusing (Laurent),
- removed vendor specific compatibles (implied by graph port number),
- added requirement of connector being a child of IC (Rob),
- removed max-mode (subtly suggested by Rob, it should be detected anyway
by USB Controller in runtime, downside is that device is not able to
report its real capabilities, maybe better would be to make it optional(?)),
- assigned port numbers to data buses (Rob).
Regards
Andrzej
Signed-off-by: Andrzej Hajda
---
.../bindings/connector/usb-connector.txt | 48 ++
1 file changed, 48 insertions(+)
create mode 100644
Documentation/devicetree/bindings/connector/usb-connector.txt
diff --git a/Documentation/devicetree/bindings/connector/usb-connector.txt
b/Documentation/devicetree/bindings/connector/usb-connector.txt
new file mode 100644
index ..02020f5d760a
--- /dev/null
+++ b/Documentation/devicetree/bindings/connector/usb-connector.txt
@@ -0,0 +1,48 @@
+USB Connector
+=
+
+USB connector node represents physical USB connector. It should be
+a child of USB interface controller.
+
+Required properties:
+- compatible: describes type of the connector, must be one of:
+"usb-a-connector", "usb-b-connector", "usb-c-connector",
+
+Optional properties:
+- label: symbolic name for the connector
+- type: size of the connector, should be specified in case of USB-A, USB-B
+ non-standard (large) connector sizes: "mini", "micro"
+
+Required nodes:
+- any data bus to the connector should be modeled using the OF graph bindings
+ specified in bindings/graph.txt, unless the bus is between parent node and
+ the connector. Since single connector can have multpile data buses every bus
+ has assigned OF graph port number as follows:
+0: High Speed (HS), present in all connectors,
+1: Super Speed (SS), present in SS capable connectors,
+2: Sideband use (SBU), present in USB-C,
+3: Mobile High-Definition Link (MHL), present in 11-pin Samsung micro-USB
+
+Example
+---
+
+muic_max77843@66 {
+ ...
+ musb_con: connector {
+ compatible = "usb-b-connector";
+ label = "micro-USB";
+ type = "micro";
+
+ ports {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ port@3 {
+ reg = <3>;
+ musb_con_mhl_in: endpoint {
+ remote-endpoint = <&mhl_out>;
+ };
+ };
+ };
+ };
+};
--
2.15.1
[RFC PATCH v2 2/5] arm64: dts: exynos: add micro-USB connector node to TM2 platforms
Since USB connector bindings are available we can describe it on TM2(e).
Signed-off-by: Andrzej Hajda
---
arch/arm64/boot/dts/exynos/exynos5433-tm2-common.dtsi | 6 ++
1 file changed, 6 insertions(+)
diff --git a/arch/arm64/boot/dts/exynos/exynos5433-tm2-common.dtsi
b/arch/arm64/boot/dts/exynos/exynos5433-tm2-common.dtsi
index a1e93d91a3ed..e5a6a2303060 100644
--- a/arch/arm64/boot/dts/exynos/exynos5433-tm2-common.dtsi
+++ b/arch/arm64/boot/dts/exynos/exynos5433-tm2-common.dtsi
@@ -798,6 +798,12 @@
muic: max77843-muic {
compatible = "maxim,max77843-muic";
+
+ musb_con: musb_connector {
+ compatible = "usb-b-connector";
+ label = "micro-USB";
+ type = "micro";
+ };
};
regulators {
--
2.15.1
[RFC PATCH v2 0/5] dt-bindings: add bindings for USB physical connector
Hi, This patchset introduces USB physical connector bindings, together with working example. I have added comments in relevant patches to describe possible issues. In v2 I have addressed comments by Rob and Laurent, thanks Changes are described in patches. Regards Andrzej Andrzej Hajda (4): dt-bindings: add bindings for USB physical connector arm64: dts: exynos: add micro-USB connector node to TM2 platforms arm64: dts: exynos: add OF graph between MHL and USB connector extcon: add possibility to get extcon device by OF node Maciej Purski (1): drm/bridge/sii8620: use micro-USB cable detection logic to detect MHL .../bindings/connector/usb-connector.txt | 48 +++ .../boot/dts/exynos/exynos5433-tm2-common.dtsi | 37 - drivers/extcon/extcon.c| 44 +++--- drivers/gpu/drm/bridge/sil-sii8620.c | 97 +- include/linux/extcon.h | 6 ++ 5 files changed, 216 insertions(+), 16 deletions(-) create mode 100644 Documentation/devicetree/bindings/connector/usb-connector.txt -- 2.15.1
[RFC PATCH v2 4/5] extcon: add possibility to get extcon device by OF node
Since extcon property is not allowed in DT, extcon subsystem requires
another way to get extcon device. Lets try the simplest approach - get
edev by of_node.
Signed-off-by: Andrzej Hajda
Acked-by: Chanwoo Choi
---
v2: changed label to follow local convention (Chanwoo)
---
drivers/extcon/extcon.c | 44 ++--
include/linux/extcon.h | 6 ++
2 files changed, 40 insertions(+), 10 deletions(-)
diff --git a/drivers/extcon/extcon.c b/drivers/extcon/extcon.c
index cb38c2747684..c4972c4cb3bd 100644
--- a/drivers/extcon/extcon.c
+++ b/drivers/extcon/extcon.c
@@ -1336,6 +1336,28 @@ void extcon_dev_unregister(struct extcon_dev *edev)
EXPORT_SYMBOL_GPL(extcon_dev_unregister);
#ifdef CONFIG_OF
+
+/*
+ * extcon_get_edev_by_of_node - Get the extcon device from devicetree.
+ * @node : OF node identyfying edev
+ *
+ * Return the pointer of extcon device if success or ERR_PTR(err) if fail.
+ */
+struct extcon_dev *extcon_get_edev_by_of_node(struct device_node *node)
+{
+ struct extcon_dev *edev;
+
+ mutex_lock(&extcon_dev_list_lock);
+ list_for_each_entry(edev, &extcon_dev_list, entry)
+ if (edev->dev.parent && edev->dev.parent->of_node == node)
+ goto out;
+ edev = ERR_PTR(-EPROBE_DEFER);
+out:
+ mutex_unlock(&extcon_dev_list_lock);
+
+ return edev;
+}
+
/*
* extcon_get_edev_by_phandle - Get the extcon device from devicetree.
* @dev: the instance to the given device
@@ -1363,25 +1385,27 @@ struct extcon_dev *extcon_get_edev_by_phandle(struct
device *dev, int index)
return ERR_PTR(-ENODEV);
}
- mutex_lock(&extcon_dev_list_lock);
- list_for_each_entry(edev, &extcon_dev_list, entry) {
- if (edev->dev.parent && edev->dev.parent->of_node == node) {
- mutex_unlock(&extcon_dev_list_lock);
- of_node_put(node);
- return edev;
- }
- }
- mutex_unlock(&extcon_dev_list_lock);
+ edev = extcon_get_edev_by_of_node(node);
of_node_put(node);
- return ERR_PTR(-EPROBE_DEFER);
+ return edev;
}
+
#else
+
+struct extcon_dev *extcon_get_edev_by_of_node(struct device_node *node)
+{
+ return ERR_PTR(-ENOSYS);
+}
+
struct extcon_dev *extcon_get_edev_by_phandle(struct device *dev, int index)
{
return ERR_PTR(-ENOSYS);
}
+
#endif /* CONFIG_OF */
+
+EXPORT_SYMBOL_GPL(extcon_get_edev_by_of_node);
EXPORT_SYMBOL_GPL(extcon_get_edev_by_phandle);
/**
diff --git a/include/linux/extcon.h b/include/linux/extcon.h
index 6d94e82c8ad9..b47e0c7f01fe 100644
--- a/include/linux/extcon.h
+++ b/include/linux/extcon.h
@@ -230,6 +230,7 @@ extern void devm_extcon_unregister_notifier_all(struct
device *dev,
* Following APIs get the extcon_dev from devicetree or by through extcon name.
*/
extern struct extcon_dev *extcon_get_extcon_dev(const char *extcon_name);
+extern struct extcon_dev *extcon_get_edev_by_of_node(struct device_node *node);
extern struct extcon_dev *extcon_get_edev_by_phandle(struct device *dev,
int index);
@@ -283,6 +284,11 @@ static inline struct extcon_dev
*extcon_get_extcon_dev(const char *extcon_name)
return ERR_PTR(-ENODEV);
}
+static inline struct extcon_dev *extcon_get_edev_by_of_node(struct device_node
*node)
+{
+ return ERR_PTR(-ENODEV);
+}
+
static inline struct extcon_dev *extcon_get_edev_by_phandle(struct device *dev,
int index)
{
--
2.15.1
[RFC PATCH v2 5/5] drm/bridge/sii8620: use micro-USB cable detection logic to detect MHL
From: Maciej Purski
Currently MHL chip must be turned on permanently to detect MHL cable. It
duplicates micro-USB controller's (MUIC) functionality and consumes
unnecessary power. Lets use extcon attached to MUIC to enable MHL chip
only if it detects MHL cable.
Signed-off-by: Maciej Purski
Signed-off-by: Andrzej Hajda
---
This is rework of the patch by Maciej with following changes:
- use micro-USB port bindings to get extcon, instead of extcon property,
- fixed remove sequence,
- fixed extcon get state logic.
Code finding extcon node is hacky IMO, I guess ultimately it should be done
via some framework (maybe even extcon), or at least via helper, I hope it
can stay as is until the proper solution will be merged.
Signed-off-by: Andrzej Hajda
---
drivers/gpu/drm/bridge/sil-sii8620.c | 97 ++--
1 file changed, 94 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/bridge/sil-sii8620.c
b/drivers/gpu/drm/bridge/sil-sii8620.c
index 9e785b8e0ea2..565cc352ca81 100644
--- a/drivers/gpu/drm/bridge/sil-sii8620.c
+++ b/drivers/gpu/drm/bridge/sil-sii8620.c
@@ -17,6 +17,7 @@
#include
#include
+#include
#include
#include
#include
@@ -25,6 +26,7 @@
#include
#include
#include
+#include
#include
#include
@@ -81,6 +83,10 @@ struct sii8620 {
struct edid *edid;
unsigned int gen2_write_burst:1;
enum sii8620_mt_state mt_state;
+ struct extcon_dev *extcon;
+ struct notifier_block extcon_nb;
+ struct work_struct extcon_wq;
+ int cable_state;
struct list_head mt_queue;
struct {
int r_size;
@@ -2175,6 +2181,77 @@ static void sii8620_init_rcp_input_dev(struct sii8620
*ctx)
ctx->rc_dev = rc_dev;
}
+static void sii8620_cable_out(struct sii8620 *ctx)
+{
+ disable_irq(to_i2c_client(ctx->dev)->irq);
+ sii8620_hw_off(ctx);
+}
+
+static void sii8620_extcon_work(struct work_struct *work)
+{
+ struct sii8620 *ctx =
+ container_of(work, struct sii8620, extcon_wq);
+ int state = extcon_get_state(ctx->extcon, EXTCON_DISP_MHL);
+
+ if (state == ctx->cable_state)
+ return;
+
+ ctx->cable_state = state;
+
+ if (state > 0)
+ sii8620_cable_in(ctx);
+ else
+ sii8620_cable_out(ctx);
+}
+
+static int sii8620_extcon_notifier(struct notifier_block *self,
+ unsigned long event, void *ptr)
+{
+ struct sii8620 *ctx =
+ container_of(self, struct sii8620, extcon_nb);
+
+ schedule_work(&ctx->extcon_wq);
+
+ return NOTIFY_DONE;
+}
+
+static int sii8620_extcon_init(struct sii8620 *ctx)
+{
+ struct extcon_dev *edev;
+ struct device_node *musb, *muic;
+ int ret;
+
+ /* get micro-USB connector node */
+ musb = of_graph_get_remote_node(ctx->dev->of_node, 1, -1);
+ /* next get micro-USB Interface Controller node */
+ muic = of_get_next_parent(musb);
+
+ if (!muic) {
+ dev_info(ctx->dev, "no extcon found, switching to 'always on'
mode\n");
+ return 0;
+ }
+
+ edev = extcon_get_edev_by_of_node(muic);
+ of_node_put(muic);
+ if (IS_ERR(edev)) {
+ if (PTR_ERR(edev) == -EPROBE_DEFER)
+ return -EPROBE_DEFER;
+ dev_err(ctx->dev, "Invalid or missing extcon\n");
+ return PTR_ERR(edev);
+ }
+
+ ctx->extcon = edev;
+ ctx->extcon_nb.notifier_call = sii8620_extcon_notifier;
+ INIT_WORK(&ctx->extcon_wq, sii8620_extcon_work);
+ ret = extcon_register_notifier(edev, EXTCON_DISP_MHL, &ctx->extcon_nb);
+ if (ret) {
+ dev_err(ctx->dev, "failed to register notifier for MHL\n");
+ return ret;
+ }
+
+ return 0;
+}
+
static inline struct sii8620 *bridge_to_sii8620(struct drm_bridge *bridge)
{
return container_of(bridge, struct sii8620, bridge);
@@ -2307,13 +2384,20 @@ static int sii8620_probe(struct i2c_client *client,
if (ret)
return ret;
+ ret = sii8620_extcon_init(ctx);
+ if (ret < 0) {
+ dev_err(ctx->dev, "failed to initialize EXTCON\n");
+ return ret;
+ }
+
i2c_set_clientdata(client, ctx);
ctx->bridge.funcs = &sii8620_bridge_funcs;
ctx->bridge.of_node = dev->of_node;
drm_bridge_add(&ctx->bridge);
- sii8620_cable_in(ctx);
+ if (!ctx->extcon)
+ sii8620_cable_in(ctx);
return 0;
}
@@ -2322,8 +2406,15 @@ static int sii8620_remove(struct i2c_client *client)
{
struct sii8620 *ctx = i2c_get_clientdata(client);
- disable_irq(to_i2c_client(ctx->dev)->irq);
- sii8620_hw_off(ctx);
+ if (ctx->extcon) {
+
[RFC PATCH v2 3/5] arm64: dts: exynos: add OF graph between MHL and USB connector
OF graph describes MHL data lanes between MHL and respective USB
connector.
Signed-off-by: Andrzej Hajda
---
.../boot/dts/exynos/exynos5433-tm2-common.dtsi | 31 +++---
1 file changed, 28 insertions(+), 3 deletions(-)
diff --git a/arch/arm64/boot/dts/exynos/exynos5433-tm2-common.dtsi
b/arch/arm64/boot/dts/exynos/exynos5433-tm2-common.dtsi
index e5a6a2303060..427ff861b441 100644
--- a/arch/arm64/boot/dts/exynos/exynos5433-tm2-common.dtsi
+++ b/arch/arm64/boot/dts/exynos/exynos5433-tm2-common.dtsi
@@ -779,9 +779,22 @@
clocks = <&pmu_system_controller 0>;
clock-names = "xtal";
- port {
- mhl_to_hdmi: endpoint {
- remote-endpoint = <&hdmi_to_mhl>;
+ ports {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ port@0 {
+ reg = <0>;
+ mhl_to_hdmi: endpoint {
+ remote-endpoint = <&hdmi_to_mhl>;
+ };
+ };
+
+ port@1 {
+ reg = <1>;
+ mhl_to_musb_con: endpoint {
+ remote-endpoint = <&musb_con_to_mhl>;
+ };
};
};
};
@@ -803,6 +816,18 @@
compatible = "usb-b-connector";
label = "micro-USB";
type = "micro";
+
+ ports {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ port@3 {
+ musb_con_to_mhl: endpoint {
+ remote-endpoint =
<&mhl_to_musb_con>;
+ };
+ };
+ };
+ };
};
};
--
2.15.1
[PATCH 2/2] arm64: dts: exynos: add OF graph between USB-PHY and MUIC
OF graph describes USB data lanes between USB-PHY and respective MUIC.
Since graph is present and DWC driver can use it to get extcon, obsolete
extcon property can be removed.
Signed-off-by: Andrzej Hajda
---
arch/arm64/boot/dts/exynos/exynos5433-tm2-common.dtsi | 18 +-
1 file changed, 17 insertions(+), 1 deletion(-)
diff --git a/arch/arm64/boot/dts/exynos/exynos5433-tm2-common.dtsi
b/arch/arm64/boot/dts/exynos/exynos5433-tm2-common.dtsi
index 427ff861b441..b20b42659206 100644
--- a/arch/arm64/boot/dts/exynos/exynos5433-tm2-common.dtsi
+++ b/arch/arm64/boot/dts/exynos/exynos5433-tm2-common.dtsi
@@ -828,6 +828,17 @@
};
};
};
+
+ ports {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ port@0 {
+ reg = <0>;
+ muic_to_usb: endpoint {
+ remote-endpoint =
<&usb_to_muic>;
+ };
+ };
};
};
@@ -1242,12 +1253,17 @@
&usbdrd_dwc3 {
dr_mode = "otg";
- extcon = <&muic>;
};
&usbdrd30_phy {
vbus-supply = <&safeout1_reg>;
status = "okay";
+
+ port {
+ usb_to_muic: endpoint {
+ remote-endpoint = <&muic_to_usb>;
+ };
+ };
};
&xxti {
--
2.15.1
[PATCH 1/2] USB: dwc3: get extcon device by OF graph bindings
extcon device is used to detect host/device connection. Since extcon
OF property is deprecated, alternative method should be added.
This method uses OF graph bindings to locate extcon.
Signed-off-by: Andrzej Hajda
---
Hi all,
This patch implements alternative method to get extcon from DWC3.
The code works but is hacky, as DWC3 must traverse different DT nodes
to get extcon, in case of TM2 it is USB-PHY and MUIC, but other
platforms can have different paths.
I would be glad if it can be merged as is for now, but additional work
must be done to make it generic.
I guess on DT binding side it is OK. So the problem should be addressed
in the code.
My rough idea is to implement kind of extcon aliases/forwarder mechanism,
ie. USB-PHY will expect on its output remote port extcon, and it should register
extcon-forwarder pointing to this extcon. This way DWC3 can look for the extcon
on its PHY phandle, and it will receive via forwarding mechanism extcon
exposed by MUIC.
As I said this is rough idea for discussion, other propositions are welcome.
Regards
Andrzej
---
drivers/usb/dwc3/drd.c | 41 -
1 file changed, 28 insertions(+), 13 deletions(-)
diff --git a/drivers/usb/dwc3/drd.c b/drivers/usb/dwc3/drd.c
index cc8ab9a8e9d2..eee2eca3d513 100644
--- a/drivers/usb/dwc3/drd.c
+++ b/drivers/usb/dwc3/drd.c
@@ -8,6 +8,7 @@
*/
#include
+#include
#include "debug.h"
#include "core.h"
@@ -38,24 +39,38 @@ static int dwc3_drd_notifier(struct notifier_block *nb,
return NOTIFY_DONE;
}
+struct extcon_dev *dwc3_get_extcon(struct dwc3 *dwc)
+{
+ struct device *dev = dwc->dev;
+ struct device_node *np_phy, *np_conn;
+ struct extcon_dev *edev;
+
+ if (of_property_read_bool(dev->of_node, "extcon"))
+ return extcon_get_edev_by_phandle(dwc->dev, 0);
+
+ np_phy = of_parse_phandle(dev->of_node, "phys", 0);
+ np_conn = of_graph_get_remote_node(np_phy, -1, -1);
+ edev = extcon_get_edev_by_of_node(np_conn);
+ of_node_put(np_conn);
+ of_node_put(np_phy);
+
+ return edev;
+}
+
int dwc3_drd_init(struct dwc3 *dwc)
{
int ret;
- if (dwc->dev->of_node) {
- if (of_property_read_bool(dwc->dev->of_node, "extcon"))
- dwc->edev = extcon_get_edev_by_phandle(dwc->dev, 0);
-
- if (IS_ERR(dwc->edev))
- return PTR_ERR(dwc->edev);
+ dwc->edev = dwc3_get_extcon(dwc);
+ if (IS_ERR(dwc->edev))
+ return PTR_ERR(dwc->edev);
- dwc->edev_nb.notifier_call = dwc3_drd_notifier;
- ret = extcon_register_notifier(dwc->edev, EXTCON_USB_HOST,
- &dwc->edev_nb);
- if (ret < 0) {
- dev_err(dwc->dev, "couldn't register cable notifier\n");
- return ret;
- }
+ dwc->edev_nb.notifier_call = dwc3_drd_notifier;
+ ret = extcon_register_notifier(dwc->edev, EXTCON_USB_HOST,
+ &dwc->edev_nb);
+ if (ret < 0) {
+ dev_err(dwc->dev, "couldn't register cable notifier\n");
+ return ret;
}
dwc3_drd_update(dwc);
--
2.15.1
[PATCH 0/2] USB: dwc3: get extcon device by OF graph bindings
Hi, This small patchset tries to address issue with broken DT extcon property in case of USB controller - DWC3. It exposes similar problem as in proposed USB connector bindings[1] - extcon device is required by devices not always connected directly to extcon device. Here we have: DWC3 -> USB-PHY -> MUIC -> USB-connector ^ MHL-bridge-^ More details and proposition of generic solution in first patch [1]: https://marc.info/?i=20180131134435.12216-1-a.hajda%40samsung.com Regards Andrzej Andrzej Hajda (2): USB: dwc3: get extcon device by OF graph bindings arm64: dts: exynos: add OF graph between USB-PHY and MUIC .../boot/dts/exynos/exynos5433-tm2-common.dtsi | 18 +- drivers/usb/dwc3/drd.c | 41 +++--- 2 files changed, 45 insertions(+), 14 deletions(-) -- 2.15.1
Re: [PATCH 2/2] arm64: dts: exynos: add OF graph between USB-PHY and MUIC
On 01.02.2018 08:50, Krzysztof Kozlowski wrote:
> On Wed, Jan 31, 2018 at 4:57 PM, Andrzej Hajda wrote:
>> OF graph describes USB data lanes between USB-PHY and respective MUIC.
>> Since graph is present and DWC driver can use it to get extcon, obsolete
>> extcon property can be removed.
>>
>> Signed-off-by: Andrzej Hajda
>> ---
>> arch/arm64/boot/dts/exynos/exynos5433-tm2-common.dtsi | 18
>> +-
>> 1 file changed, 17 insertions(+), 1 deletion(-)
>>
>> diff --git a/arch/arm64/boot/dts/exynos/exynos5433-tm2-common.dtsi
>> b/arch/arm64/boot/dts/exynos/exynos5433-tm2-common.dtsi
>> index 427ff861b441..b20b42659206 100644
>> --- a/arch/arm64/boot/dts/exynos/exynos5433-tm2-common.dtsi
>> +++ b/arch/arm64/boot/dts/exynos/exynos5433-tm2-common.dtsi
>> @@ -828,6 +828,17 @@
>> };
>> };
>> };
>> +
>> + ports {
>> + #address-cells = <1>;
>> + #size-cells = <0>;
>> +
>> + port@0 {
>> + reg = <0>;
>> + muic_to_usb: endpoint {
>> + remote-endpoint =
>> <&usb_to_muic>;
>> + };
>> + };
>> };
>> };
>>
>> @@ -1242,12 +1253,17 @@
>>
>> &usbdrd_dwc3 {
>> dr_mode = "otg";
>> - extcon = <&muic>;
> Look ok for me.
>
> Does this depend on #1 patch for DWC?
Yes, it depends. #1 adds code to find extcon using graph, without it
dwc3 won't be able to work in dual-role mode.
Alternatively, I could split this patch into two parts:
2a. adding graph bindings.
2b. removing extcon property.
In such case only 2b depends on #1.
Regards
Andrzej
>
> Best regards,
> Krzysztof
>
>
>
Re: [PATCH] drm/bridge/synopsis: stop clobbering drvdata
On 09.01.2018 14:37, Laurent Pinchart wrote:
> Hi Philippe,
>
> On Tuesday, 9 January 2018 15:01:02 EET Philippe CORNU wrote:
>> Hi Archit, Andrzej & Laurent,
>>
>> Regarding this patch from Brian, I think it could be nice to merge it
>> (1xAcked-by, 2xReviewed-by).
>>
>> Could you please have a look?
>>
>> Only the small "typo" in the headline needs to be changed.
>>
>> Many thanks,
> I've just replied to Brian in this mail thread. Sorry for the delay, it
> slipped through the cracks. Thank you for pinging me.
I have just pushed the patch to drm-misc-next. I am sorry, if you wanted
to polish it more, from the thread it looked it can be merged as is.
Regards
Andrzej
>> On 11/28/2017 10:34 AM, Philippe CORNU wrote:
>>
>>> Hi Brian,
>>>
>>> On 11/28/2017 02:05 AM, Brian Norris wrote:
>>>
Bridge drivers/helpers shouldn't be clobbering the drvdata, since a
parent driver might need to own this. Instead, let's return our
'dw_mipi_dsi' object and have callers pass that back to us for removal.
>>>
>>> And many thanks for this cleanup.
>>> (please update the headline with "synopsys")
>>>
>>> Successfully tested on stm.
>>>
>>> Acked-by: Philippe Cornu
>>>
>>> Many thanks,
>>> Philippe :-)
>>>
Signed-off-by: Brian Norris
---
drivers/gpu/drm/bridge/synopsys/dw-mipi-dsi.c | 36
++-
drivers/gpu/drm/stm/dw_mipi_dsi-stm.c | 14 +++
include/drm/bridge/dw_mipi_dsi.h | 17 -
3 files changed, 33 insertions(+), 34 deletions(-)
diff --git a/drivers/gpu/drm/bridge/synopsys/dw-mipi-dsi.c
b/drivers/gpu/drm/bridge/synopsys/dw-mipi-dsi.c
index d9cca4fd66ec..c39c7dce20ed 100644
--- a/drivers/gpu/drm/bridge/synopsys/dw-mipi-dsi.c
+++ b/drivers/gpu/drm/bridge/synopsys/dw-mipi-dsi.c
@@ -922,8 +922,6 @@ __dw_mipi_dsi_probe(struct platform_device *pdev,
dsi->bridge.of_node = pdev->dev.of_node;
#endif
-dev_set_drvdata(dev, dsi);
-
return dsi;
}
@@ -935,23 +933,16 @@ static void __dw_mipi_dsi_remove(struct
dw_mipi_dsi *dsi)
/*
* Probe/remove API, used from platforms based on the DRM bridge API.
*/
-int dw_mipi_dsi_probe(struct platform_device *pdev,
- const struct dw_mipi_dsi_plat_data *plat_data)
+struct dw_mipi_dsi *
+dw_mipi_dsi_probe(struct platform_device *pdev,
+ const struct dw_mipi_dsi_plat_data *plat_data)
{
-struct dw_mipi_dsi *dsi;
-
-dsi = __dw_mipi_dsi_probe(pdev, plat_data);
-if (IS_ERR(dsi))
-return PTR_ERR(dsi);
-
-return 0;
+return __dw_mipi_dsi_probe(pdev, plat_data);
}
EXPORT_SYMBOL_GPL(dw_mipi_dsi_probe);
-void dw_mipi_dsi_remove(struct platform_device *pdev)
+void dw_mipi_dsi_remove(struct dw_mipi_dsi *dsi)
{
-struct dw_mipi_dsi *dsi = platform_get_drvdata(pdev);
-
mipi_dsi_host_unregister(&dsi->dsi_host);
__dw_mipi_dsi_remove(dsi);
@@ -961,31 +952,30 @@ EXPORT_SYMBOL_GPL(dw_mipi_dsi_remove);
/*
* Bind/unbind API, used from platforms based on the component
framework.
*/
-int dw_mipi_dsi_bind(struct platform_device *pdev, struct drm_encoder
*encoder,
- const struct dw_mipi_dsi_plat_data *plat_data)
+struct dw_mipi_dsi *
+dw_mipi_dsi_bind(struct platform_device *pdev, struct drm_encoder
*encoder,
+ const struct dw_mipi_dsi_plat_data *plat_data)
{
struct dw_mipi_dsi *dsi;
int ret;
dsi = __dw_mipi_dsi_probe(pdev, plat_data);
if (IS_ERR(dsi))
-return PTR_ERR(dsi);
+return dsi;
ret = drm_bridge_attach(encoder, &dsi->bridge, NULL);
if (ret) {
-dw_mipi_dsi_remove(pdev);
+dw_mipi_dsi_remove(dsi);
DRM_ERROR("Failed to initialize bridge with drm\n");
-return ret;
+return ERR_PTR(ret);
}
-return 0;
+return dsi;
}
EXPORT_SYMBOL_GPL(dw_mipi_dsi_bind);
-void dw_mipi_dsi_unbind(struct device *dev)
+void dw_mipi_dsi_unbind(struct dw_mipi_dsi *dsi)
{
-struct dw_mipi_dsi *dsi = dev_get_drvdata(dev);
-
__dw_mipi_dsi_remove(dsi);
}
EXPORT_SYMBOL_GPL(dw_mipi_dsi_unbind);
diff --git a/drivers/gpu/drm/stm/dw_mipi_dsi-stm.c
b/drivers/gpu/drm/stm/dw_mipi_dsi-stm.c
index e5b6310240fe..7ed0ef7f6ec2 100644
--- a/drivers/gpu/drm/stm/dw_mipi_dsi-stm.c
+++ b/drivers/gpu/drm/stm/dw_mipi_dsi-stm.c
@@ -66,6 +66,7 @@ enum dsi_color {
struct dw_mipi_dsi_stm {
void __iomem *base;
struct clk *pllref_clk;
+struct dw_mipi_dsi *dsi;
};
static inline void dsi_write(struct dw_mipi_dsi_st
Re: [PATCH v2 2/2] drm/bridge/synopsys: dsi: handle endianness correctly in dw_mipi_dsi_write()
On 09.01.2018 21:32, Brian Norris wrote:
> We're filling the "remainder" word with little-endian data, then writing
> it out to IO registers with endian-correcting writel(). That probably
> won't work on big-endian systems.
>
> Let's mark the "remainder" variable as LE32 (since we fill it with
> memcpy()) and do the swapping explicitly.
>
> Some of this function could be done more easily without memcpy(), but
> the unaligned "remainder" case is a little hard to do without
> potentially overrunning 'tx_buf', so I just applied the same solution in
> all cases (memcpy() + le32_to_cpu()).
>
> Tested only on a little-endian system.
>
> Signed-off-by: Brian Norris
> ---
> drivers/gpu/drm/bridge/synopsys/dw-mipi-dsi.c | 18 +-
> 1 file changed, 9 insertions(+), 9 deletions(-)
>
> diff --git a/drivers/gpu/drm/bridge/synopsys/dw-mipi-dsi.c
> b/drivers/gpu/drm/bridge/synopsys/dw-mipi-dsi.c
> index ed91e32ee43a..90f13df6f106 100644
> --- a/drivers/gpu/drm/bridge/synopsys/dw-mipi-dsi.c
> +++ b/drivers/gpu/drm/bridge/synopsys/dw-mipi-dsi.c
> @@ -360,18 +360,18 @@ static int dw_mipi_dsi_write(struct dw_mipi_dsi *dsi,
> {
> const u8 *tx_buf = packet->payload;
> int len = packet->payload_length, pld_data_bytes = sizeof(u32), ret;
> - u32 remainder;
> + __le32 word;
> u32 val;
>
> while (len) {
> if (len < pld_data_bytes) {
> - remainder = 0;
> - memcpy(&remainder, tx_buf, len);
> - dsi_write(dsi, DSI_GEN_PLD_DATA, remainder);
> + word = 0;
> + memcpy(&word, tx_buf, len);
> + dsi_write(dsi, DSI_GEN_PLD_DATA, le32_to_cpu(word));
> len = 0;
> } else {
> - memcpy(&remainder, tx_buf, pld_data_bytes);
> - dsi_write(dsi, DSI_GEN_PLD_DATA, remainder);
> + memcpy(&word, tx_buf, pld_data_bytes);
> + dsi_write(dsi, DSI_GEN_PLD_DATA, le32_to_cpu(word));
> tx_buf += pld_data_bytes;
> len -= pld_data_bytes;
> }
> @@ -386,9 +386,9 @@ static int dw_mipi_dsi_write(struct dw_mipi_dsi *dsi,
> }
> }
>
> - remainder = 0;
> - memcpy(&remainder, packet->header, sizeof(packet->header));
> - return dw_mipi_dsi_gen_pkt_hdr_write(dsi, remainder);
> + word = 0;
> + memcpy(&word, packet->header, sizeof(packet->header));
> + return dw_mipi_dsi_gen_pkt_hdr_write(dsi, le32_to_cpu(word));
You could create and use appropriate helper, lets say:
u32 le_to_cpup(const u8 *p, int count)
{
__le32 r = 0;
memcpy(&r, p, count);
return le32_to_cpu(r);
}
With or without this change:
Reviewed-by: Andrzej Hajda
--
Regards
Andrzej
> }
>
> static ssize_t dw_mipi_dsi_host_transfer(struct mipi_dsi_host *host,
Re: [PATCH] drm/dsi: Fix improper use of mipi_dsi_device_transfer() return value
On 12.01.2018 15:48, Philippe Cornu wrote:
> The function mipi_dsi_device_transfer() returns the number of transmitted
> or received bytes on success or a negative error code on failure.
>
> The functions mipi_dsi_shutdown_peripheral(), mipi_dsi_turn_on_peripheral() &
> mipi_dsi_set_maximum_return_packet_size() use improperly this returned
> value in case of success: 0 should be returned instead of the number of
> transmitted bytes.
>
> Signed-off-by: Philippe Cornu
I guess, the best would be to create and use some helper similar to
PTR_ERR_OR_ZERO,
but this is also OK.
Reviewed-by: Andrzej Hajda
--
Regards
Andrzej
> ---
> drivers/gpu/drm/drm_mipi_dsi.c | 9 ++---
> 1 file changed, 6 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/gpu/drm/drm_mipi_dsi.c b/drivers/gpu/drm/drm_mipi_dsi.c
> index 4b47226b90d4..bc73b7f5b9fc 100644
> --- a/drivers/gpu/drm/drm_mipi_dsi.c
> +++ b/drivers/gpu/drm/drm_mipi_dsi.c
> @@ -498,8 +498,9 @@ int mipi_dsi_shutdown_peripheral(struct mipi_dsi_device
> *dsi)
> .tx_buf = (u8 [2]) { 0, 0 },
> .tx_len = 2,
> };
> + int ret = mipi_dsi_device_transfer(dsi, &msg);
>
> - return mipi_dsi_device_transfer(dsi, &msg);
> + return (ret < 0) ? ret : 0;
> }
> EXPORT_SYMBOL(mipi_dsi_shutdown_peripheral);
>
> @@ -517,8 +518,9 @@ int mipi_dsi_turn_on_peripheral(struct mipi_dsi_device
> *dsi)
> .tx_buf = (u8 [2]) { 0, 0 },
> .tx_len = 2,
> };
> + int ret = mipi_dsi_device_transfer(dsi, &msg);
>
> - return mipi_dsi_device_transfer(dsi, &msg);
> + return (ret < 0) ? ret : 0;
> }
> EXPORT_SYMBOL(mipi_dsi_turn_on_peripheral);
>
> @@ -541,8 +543,9 @@ int mipi_dsi_set_maximum_return_packet_size(struct
> mipi_dsi_device *dsi,
> .tx_len = sizeof(tx),
> .tx_buf = tx,
> };
> + int ret = mipi_dsi_device_transfer(dsi, &msg);
>
> - return mipi_dsi_device_transfer(dsi, &msg);
> + return (ret < 0) ? ret : 0;
> }
> EXPORT_SYMBOL(mipi_dsi_set_maximum_return_packet_size);
>
Re: [PATCH v2] drm/bridge/synopsys: dsi: add optional pixel clock
On 12.01.2018 17:25, Philippe Cornu wrote:
> The pixel clock is optional. When available, it offers a better
> preciseness for timing computations and allows to reduce the extra dsi
> bandwidth in burst mode (from ~20% to ~10-12%, hw platform dependent).
>
> Signed-off-by: Philippe Cornu
> ---
> Changes in v2: Improve px_clk probing in case of ENOENT dt returned value
> (thanks to Philipp Zabel & Andrzej Hajda comments)
>
> drivers/gpu/drm/bridge/synopsys/dw-mipi-dsi.c | 26 --
> 1 file changed, 20 insertions(+), 6 deletions(-)
>
> diff --git a/drivers/gpu/drm/bridge/synopsys/dw-mipi-dsi.c
> b/drivers/gpu/drm/bridge/synopsys/dw-mipi-dsi.c
> index c39c7dce20ed..62fcff881b98 100644
> --- a/drivers/gpu/drm/bridge/synopsys/dw-mipi-dsi.c
> +++ b/drivers/gpu/drm/bridge/synopsys/dw-mipi-dsi.c
> @@ -225,6 +225,7 @@ struct dw_mipi_dsi {
> void __iomem *base;
>
> struct clk *pclk;
> + struct clk *px_clk;
>
> unsigned int lane_mbps; /* per lane */
> u32 channel;
> @@ -753,24 +754,28 @@ void dw_mipi_dsi_bridge_mode_set(struct drm_bridge
> *bridge,
> struct dw_mipi_dsi *dsi = bridge_to_dsi(bridge);
> const struct dw_mipi_dsi_phy_ops *phy_ops = dsi->plat_data->phy_ops;
> void *priv_data = dsi->plat_data->priv_data;
> + struct drm_display_mode px_clk_mode = *mode;
> int ret;
>
> clk_prepare_enable(dsi->pclk);
>
> - ret = phy_ops->get_lane_mbps(priv_data, mode, dsi->mode_flags,
> + if (dsi->px_clk)
> + px_clk_mode.clock = clk_get_rate(dsi->px_clk) / 1000;
> +
> + ret = phy_ops->get_lane_mbps(priv_data, &px_clk_mode, dsi->mode_flags,
>dsi->lanes, dsi->format, &dsi->lane_mbps);
> if (ret)
> DRM_DEBUG_DRIVER("Phy get_lane_mbps() failed\n");
>
> pm_runtime_get_sync(dsi->dev);
> dw_mipi_dsi_init(dsi);
> - dw_mipi_dsi_dpi_config(dsi, mode);
> + dw_mipi_dsi_dpi_config(dsi, &px_clk_mode);
> dw_mipi_dsi_packet_handler_config(dsi);
> dw_mipi_dsi_video_mode_config(dsi);
> - dw_mipi_dsi_video_packet_config(dsi, mode);
> + dw_mipi_dsi_video_packet_config(dsi, &px_clk_mode);
> dw_mipi_dsi_command_mode_config(dsi);
> - dw_mipi_dsi_line_timer_config(dsi, mode);
> - dw_mipi_dsi_vertical_timing_config(dsi, mode);
> + dw_mipi_dsi_line_timer_config(dsi, &px_clk_mode);
> + dw_mipi_dsi_vertical_timing_config(dsi, &px_clk_mode);
>
> dw_mipi_dsi_dphy_init(dsi);
> dw_mipi_dsi_dphy_timing_config(dsi);
> @@ -784,7 +789,7 @@ void dw_mipi_dsi_bridge_mode_set(struct drm_bridge
> *bridge,
>
> dw_mipi_dsi_dphy_enable(dsi);
>
> - dw_mipi_dsi_wait_for_two_frames(mode);
> + dw_mipi_dsi_wait_for_two_frames(&px_clk_mode);
>
> /* Switch to cmd mode for panel-bridge pre_enable & panel prepare */
> dw_mipi_dsi_set_mode(dsi, 0);
> @@ -878,6 +883,15 @@ __dw_mipi_dsi_probe(struct platform_device *pdev,
> return ERR_PTR(ret);
> }
>
> + dsi->px_clk = devm_clk_get(dev, "px_clk");
> + if (PTR_ERR(dsi->px_clk) == -ENOENT) {
> + dsi->px_clk = NULL;
> + } else if (IS_ERR(dsi->px_clk)) {
> + ret = PTR_ERR(dsi->px_clk);
> + dev_err(dev, "Unable to get optional px_clk: %d\n", ret);
> + dsi->px_clk = NULL;
> + }
> +
As I understand on fail you just log an error and continue?
The code could be slightly simplified, for example:
dsi->px_clk = devm_clk_get(dev, "px_clk");
if (IS_ERR(dsi->px_clk)) {
ret = PTR_ERR(dsi->px_clk);
if (ret != ENOENT)
dev_err(dev, "Unable to get optional px_clk: %d\n", ret);
dsi->px_clk = NULL;
}
With or without this change:
Reviewed-by: Andrzej Hajda
--
Regards
Andrzej
> /*
>* Note that the reset was not defined in the initial device tree, so
>* we have to be prepared for it not being found.
Re: [PATCH v2] drm/bridge/synopsys: dsi: add optional pixel clock
On 15.01.2018 15:40, Philippe CORNU wrote:
> Hi Andrzej,
>
> On 01/15/2018 02:52 PM, Andrzej Hajda wrote:
>> On 12.01.2018 17:25, Philippe Cornu wrote:
>>> The pixel clock is optional. When available, it offers a better
>>> preciseness for timing computations and allows to reduce the extra dsi
>>> bandwidth in burst mode (from ~20% to ~10-12%, hw platform dependent).
>>>
>>> Signed-off-by: Philippe Cornu
>>> ---
>>> Changes in v2: Improve px_clk probing in case of ENOENT dt returned value
>>> (thanks to Philipp Zabel & Andrzej Hajda comments)
>>>
>>> drivers/gpu/drm/bridge/synopsys/dw-mipi-dsi.c | 26
>>> --
>>> 1 file changed, 20 insertions(+), 6 deletions(-)
>>>
>>> diff --git a/drivers/gpu/drm/bridge/synopsys/dw-mipi-dsi.c
>>> b/drivers/gpu/drm/bridge/synopsys/dw-mipi-dsi.c
>>> index c39c7dce20ed..62fcff881b98 100644
>>> --- a/drivers/gpu/drm/bridge/synopsys/dw-mipi-dsi.c
>>> +++ b/drivers/gpu/drm/bridge/synopsys/dw-mipi-dsi.c
>>> @@ -225,6 +225,7 @@ struct dw_mipi_dsi {
>>> void __iomem *base;
>>>
>>> struct clk *pclk;
>>> + struct clk *px_clk;
>>>
>>> unsigned int lane_mbps; /* per lane */
>>> u32 channel;
>>> @@ -753,24 +754,28 @@ void dw_mipi_dsi_bridge_mode_set(struct drm_bridge
>>> *bridge,
>>> struct dw_mipi_dsi *dsi = bridge_to_dsi(bridge);
>>> const struct dw_mipi_dsi_phy_ops *phy_ops = dsi->plat_data->phy_ops;
>>> void *priv_data = dsi->plat_data->priv_data;
>>> + struct drm_display_mode px_clk_mode = *mode;
>>> int ret;
>>>
>>> clk_prepare_enable(dsi->pclk);
>>>
>>> - ret = phy_ops->get_lane_mbps(priv_data, mode, dsi->mode_flags,
>>> + if (dsi->px_clk)
>>> + px_clk_mode.clock = clk_get_rate(dsi->px_clk) / 1000;
>>> +
>>> + ret = phy_ops->get_lane_mbps(priv_data, &px_clk_mode, dsi->mode_flags,
>>> dsi->lanes, dsi->format, &dsi->lane_mbps);
>>> if (ret)
>>> DRM_DEBUG_DRIVER("Phy get_lane_mbps() failed\n");
>>>
>>> pm_runtime_get_sync(dsi->dev);
>>> dw_mipi_dsi_init(dsi);
>>> - dw_mipi_dsi_dpi_config(dsi, mode);
>>> + dw_mipi_dsi_dpi_config(dsi, &px_clk_mode);
>>> dw_mipi_dsi_packet_handler_config(dsi);
>>> dw_mipi_dsi_video_mode_config(dsi);
>>> - dw_mipi_dsi_video_packet_config(dsi, mode);
>>> + dw_mipi_dsi_video_packet_config(dsi, &px_clk_mode);
>>> dw_mipi_dsi_command_mode_config(dsi);
>>> - dw_mipi_dsi_line_timer_config(dsi, mode);
>>> - dw_mipi_dsi_vertical_timing_config(dsi, mode);
>>> + dw_mipi_dsi_line_timer_config(dsi, &px_clk_mode);
>>> + dw_mipi_dsi_vertical_timing_config(dsi, &px_clk_mode);
>>>
>>> dw_mipi_dsi_dphy_init(dsi);
>>> dw_mipi_dsi_dphy_timing_config(dsi);
>>> @@ -784,7 +789,7 @@ void dw_mipi_dsi_bridge_mode_set(struct drm_bridge
>>> *bridge,
>>>
>>> dw_mipi_dsi_dphy_enable(dsi);
>>>
>>> - dw_mipi_dsi_wait_for_two_frames(mode);
>>> + dw_mipi_dsi_wait_for_two_frames(&px_clk_mode);
>>>
>>> /* Switch to cmd mode for panel-bridge pre_enable & panel prepare */
>>> dw_mipi_dsi_set_mode(dsi, 0);
>>> @@ -878,6 +883,15 @@ __dw_mipi_dsi_probe(struct platform_device *pdev,
>>> return ERR_PTR(ret);
>>> }
>>>
>>> + dsi->px_clk = devm_clk_get(dev, "px_clk");
>>> + if (PTR_ERR(dsi->px_clk) == -ENOENT) {
>>> + dsi->px_clk = NULL;
>>> + } else if (IS_ERR(dsi->px_clk)) {
>>> + ret = PTR_ERR(dsi->px_clk);
>>> + dev_err(dev, "Unable to get optional px_clk: %d\n", ret);
>>> + dsi->px_clk = NULL;
>>> + }
>>> +
>> As I understand on fail you just log an error and continue?
>> The code could be slightly simplified, for example:
>> dsi->px_clk = devm_clk_get(dev, "px_clk");
>> if (IS_ERR(dsi->px_clk)) {
>> ret = PTR_ERR(dsi->px_clk);
>> if (ret != ENOENT)
>> dev_err(dev, "Unable to get optional px_clk: %d\n", ret);
>> dsi->px_clk = NULL;
>> }
>>
>> With or without this change:
>>
Re: [PATCH v5 1/6] dt-bindings: add bindings for USB physical connector
On 09.03.2018 11:24, Roger Quadros wrote: > Hi, > > On 27/02/18 09:11, Andrzej Hajda wrote: >> These bindings allow to describe most known standard USB connectors >> and it should be possible to extend it if necessary. >> USB connectors, beside USB can be used to route other protocols, >> for example UART, Audio, MHL. In such case every device passing data >> through the connector should have appropriate graph bindings. >> >> Signed-off-by: Andrzej Hajda >> --- >> v4: >> - improved 'type' description (Rob), >> - improved description of 2nd example (Rob). >> v3: >> - removed MHL port (samsung connector will have separate bindings), >> - added 2nd example for USB-C, >> - improved formatting. >> v2: >> - moved connector type(A,B,C) to compatible string (Rob), >> - renamed size property to type (Rob), >> - changed type description to be less confusing (Laurent), >> - removed vendor specific compatibles (implied by graph port number), >> - added requirement of connector being a child of IC (Rob), >> - removed max-mode (subtly suggested by Rob, it should be detected anyway >> by USB Controller in runtime, downside is that device is not able to >> report its real capabilities, maybe better would be to make it >> optional(?)), >> - assigned port numbers to data buses (Rob). >> >> Regards >> Andrzej >> --- >> .../bindings/connector/usb-connector.txt | 75 >> ++ >> 1 file changed, 75 insertions(+) >> create mode 100644 >> Documentation/devicetree/bindings/connector/usb-connector.txt >> >> diff --git a/Documentation/devicetree/bindings/connector/usb-connector.txt >> b/Documentation/devicetree/bindings/connector/usb-connector.txt >> new file mode 100644 >> index ..e1463f14af38 >> --- /dev/null >> +++ b/Documentation/devicetree/bindings/connector/usb-connector.txt >> @@ -0,0 +1,75 @@ >> +USB Connector >> += >> + >> +USB connector node represents physical USB connector. It should be >> +a child of USB interface controller. >> + >> +Required properties: >> +- compatible: describes type of the connector, must be one of: >> +"usb-a-connector", >> +"usb-b-connector", >> +"usb-c-connector". > compatible should be just "usb-connector" > > Type should be a property > > type: type of usb connector "A", "B", "AB", "C" > AB is for dual-role connectors. I have proposed such property (and size also) in my first RFC [1]. Rod did not like it :) [1]: https://marc.info/?l=devicetree&m=150660411515233&w=2 > > micro super-speed and high-speed connectors are different. How do you > differentiate that? I am aware of it, and property differentiating it was also in my earlier iterations. If there will be need to differentiate such connectors, adding property max-speed or max-mode would do the thing. > >> + >> +Optional properties: >> +- label: symbolic name for the connector, > Why do you need label? We can't maintain consistency as people will put > creative names there. > Device/bus driver could generate a valid label. It follows convention for other connectors: HDMI, DVI, > >> +- type: size of the connector, should be specified in case of USB-A, USB-B >> + non-fullsize connectors: "mini", "micro". > type is misleading. Type is usually A/B/C. It should be size here instead. As you can see in discussion for previous iterations it follows convention already established for other connectors. > > size: size of the connector if not standard size. "mini", "micro" > > If not specified it is treated as standard sized connector. > e.g. for Type-C there is no mini/micro. so size doesn't have to be specificed Few lines above it is described: should be specified in case of USB-A, USB-B non-fullsize connectors. > > What about Type-C connector? >> + >> +Required nodes: >> +- any data bus to the connector should be modeled using the OF graph >> bindings > s/modeled/modelled >> + specified in bindings/graph.txt, unless the bus is between parent node and >> + the connector. Since single connector can have multpile data buses every >> bus > s/multpile/multiple OK, I will fix both typos. > >> + has assigned OF graph port number as follows: >> +0: High Speed (HS), present in all connectors, >> +1: Super Speed (SS), present in SS capable connectors, >> +2: Sideband use (SBU), present in USB-C. >
Re: [PATCH v5 1/6] dt-bindings: add bindings for USB physical connector
On 12.03.2018 08:02, Andrzej Hajda wrote: > On 09.03.2018 11:24, Roger Quadros wrote: >> Hi, >> >> On 27/02/18 09:11, Andrzej Hajda wrote: >>> These bindings allow to describe most known standard USB connectors >>> and it should be possible to extend it if necessary. >>> USB connectors, beside USB can be used to route other protocols, >>> for example UART, Audio, MHL. In such case every device passing data >>> through the connector should have appropriate graph bindings. >>> >>> Signed-off-by: Andrzej Hajda >>> --- >>> v4: >>> - improved 'type' description (Rob), >>> - improved description of 2nd example (Rob). >>> v3: >>> - removed MHL port (samsung connector will have separate bindings), >>> - added 2nd example for USB-C, >>> - improved formatting. >>> v2: >>> - moved connector type(A,B,C) to compatible string (Rob), >>> - renamed size property to type (Rob), >>> - changed type description to be less confusing (Laurent), >>> - removed vendor specific compatibles (implied by graph port number), >>> - added requirement of connector being a child of IC (Rob), >>> - removed max-mode (subtly suggested by Rob, it should be detected anyway >>> by USB Controller in runtime, downside is that device is not able to >>> report its real capabilities, maybe better would be to make it >>> optional(?)), >>> - assigned port numbers to data buses (Rob). >>> >>> Regards >>> Andrzej >>> --- >>> .../bindings/connector/usb-connector.txt | 75 >>> ++ >>> 1 file changed, 75 insertions(+) >>> create mode 100644 >>> Documentation/devicetree/bindings/connector/usb-connector.txt >>> >>> diff --git a/Documentation/devicetree/bindings/connector/usb-connector.txt >>> b/Documentation/devicetree/bindings/connector/usb-connector.txt >>> new file mode 100644 >>> index ..e1463f14af38 >>> --- /dev/null >>> +++ b/Documentation/devicetree/bindings/connector/usb-connector.txt >>> @@ -0,0 +1,75 @@ >>> +USB Connector >>> += >>> + >>> +USB connector node represents physical USB connector. It should be >>> +a child of USB interface controller. >>> + >>> +Required properties: >>> +- compatible: describes type of the connector, must be one of: >>> +"usb-a-connector", >>> +"usb-b-connector", >>> +"usb-c-connector". >> compatible should be just "usb-connector" >> >> Type should be a property >> >> type: type of usb connector "A", "B", "AB", "C" >> AB is for dual-role connectors. > I have proposed such property (and size also) in my first RFC [1]. Rod > did not like it :) Ups, ugly typo, I meant Rob, of course. Regards Andrzej > > [1]: https://marc.info/?l=devicetree&m=150660411515233&w=2 > > >> micro super-speed and high-speed connectors are different. How do you >> differentiate that? > I am aware of it, and property differentiating it was also in my earlier > iterations. > If there will be need to differentiate such connectors, adding property > max-speed or max-mode would do the thing. > >>> + >>> +Optional properties: >>> +- label: symbolic name for the connector, >> Why do you need label? We can't maintain consistency as people will put >> creative names there. >> Device/bus driver could generate a valid label. > It follows convention for other connectors: HDMI, DVI, > >>> +- type: size of the connector, should be specified in case of USB-A, USB-B >>> + non-fullsize connectors: "mini", "micro". >> type is misleading. Type is usually A/B/C. It should be size here instead. > As you can see in discussion for previous iterations it follows > convention already established for other connectors. > >> size: size of the connector if not standard size. "mini", "micro" >> >> If not specified it is treated as standard sized connector. >> e.g. for Type-C there is no mini/micro. so size doesn't have to be specificed > Few lines above it is described: should be specified in case of USB-A, > USB-B non-fullsize connectors. > >> What about Type-C connector? >>> + >>> +Required nodes: >>> +- any data bus to the connector should be modeled using the OF graph >>> bindings >> s/modeled/modelled
Re: [PATCH v2 2/3] drm: bridge: Add LVDS decoder driver
On 09.03.2018 14:51, Jacopo Mondi wrote:
> Add transparent LVDS decoder driver.
>
> A transparent LVDS decoder is a DRM bridge device that does not require
> any configuration and converts LVDS input to digital CMOS/TTL parallel
> data output.
Neither code, neither bindings are LVDS specific, this is driver for any
bridge w/o configuration.
I am not sure how many bridges does not need configuration, usually
they need to be powered at least.
I guess in many cases power line is always on, but this is board
specific not device specific.
Looking at previous version of the patchset it looks little bit as a
hack, and certainly it will be a hack in case of R-Car Gen3 V3M Eagle,
which I guess you want to use it.
> Signed-off-by: Jacopo Mondi
> ---
> drivers/gpu/drm/bridge/Kconfig| 8 +++
> drivers/gpu/drm/bridge/Makefile | 1 +
> drivers/gpu/drm/bridge/lvds-decoder.c | 129
> ++
> 3 files changed, 138 insertions(+)
> create mode 100644 drivers/gpu/drm/bridge/lvds-decoder.c
>
> diff --git a/drivers/gpu/drm/bridge/Kconfig b/drivers/gpu/drm/bridge/Kconfig
> index 3b99d5a..e52a5af 100644
> --- a/drivers/gpu/drm/bridge/Kconfig
> +++ b/drivers/gpu/drm/bridge/Kconfig
> @@ -32,6 +32,14 @@ config DRM_DUMB_VGA_DAC
> help
> Support for RGB to VGA DAC based bridges
>
> +config DRM_LVDS_DECODER
> + tristate "Transparent LVDS to parallel decoder support"
> + depends on OF
> + select DRM_PANEL_BRIDGE
> + help
> + Support for transparent LVDS to parallel decoders that don't require
> + any configuration.
> +
> config DRM_LVDS_ENCODER
> tristate "Transparent parallel to LVDS encoder support"
> depends on OF
> diff --git a/drivers/gpu/drm/bridge/Makefile b/drivers/gpu/drm/bridge/Makefile
> index 373eb28..edc2332 100644
> --- a/drivers/gpu/drm/bridge/Makefile
> +++ b/drivers/gpu/drm/bridge/Makefile
> @@ -1,6 +1,7 @@
> # SPDX-License-Identifier: GPL-2.0
> obj-$(CONFIG_DRM_ANALOGIX_ANX78XX) += analogix-anx78xx.o
> obj-$(CONFIG_DRM_DUMB_VGA_DAC) += dumb-vga-dac.o
> +obj-$(CONFIG_DRM_LVDS_DECODER) += lvds-decoder.o
> obj-$(CONFIG_DRM_LVDS_ENCODER) += lvds-encoder.o
> obj-$(CONFIG_DRM_MEGACHIPS_STDP_GE_B850V3_FW) +=
> megachips-stdp-ge-b850v3-fw.o
> obj-$(CONFIG_DRM_NXP_PTN3460) += nxp-ptn3460.o
> diff --git a/drivers/gpu/drm/bridge/lvds-decoder.c
> b/drivers/gpu/drm/bridge/lvds-decoder.c
> new file mode 100644
> index 000..319f4d5
> --- /dev/null
> +++ b/drivers/gpu/drm/bridge/lvds-decoder.c
> @@ -0,0 +1,129 @@
> +// SPDX-License-Identifier: GPL-2.0
> +/*
> + * LVDS to parallel data DRM bridge driver.
> + *
> + * Copyright (C) 2018 Jacopo Mondi
> + */
> +
> +#include
> +#include
> +#include
> +
> +#include
> +
> +struct lvds_decoder {
> + struct device *dev;
> +
> + struct drm_bridge bridge;
> + struct drm_bridge *next;
> + struct drm_encoder *bridge_encoder;
Unused field.
Regards
Andrzej
> +};
> +
> +static inline struct lvds_decoder *to_lvds_decoder(struct drm_bridge *bridge)
> +{
> + return container_of(bridge, struct lvds_decoder, bridge);
> +}
> +
> +static int lvds_decoder_attach(struct drm_bridge *bridge)
> +{
> + struct lvds_decoder *lvds = to_lvds_decoder(bridge);
> +
> + return drm_bridge_attach(bridge->encoder, lvds->next, bridge);
> +}
> +
> +struct drm_bridge_funcs lvds_dec_bridge_func = {
> + .attach = lvds_decoder_attach,
> +};
> +
> +static int lvds_decoder_parse_dt(struct lvds_decoder *lvds)
> +{
> + struct device_node *lvds_output;
> + struct device_node *remote;
> + int ret = 0;
> +
> + lvds_output = of_graph_get_endpoint_by_regs(lvds->dev->of_node, 1, -1);
> + if (!lvds_output) {
> + dev_err(lvds->dev, "Missing endpoint in Port@1\n");
> + return -ENODEV;
> + }
> +
> + remote = of_graph_get_remote_port_parent(lvds_output);
> + if (!remote) {
> + dev_err(lvds->dev, "Endpoint in Port@1 unconnected\n");
> + ret = -ENODEV;
> + goto error_put_lvds_node;
> + }
> +
> + if (!of_device_is_available(remote)) {
> + dev_err(lvds->dev, "Port@1 remote endpoint is disabled\n");
> + ret = -ENODEV;
> + goto error_put_remote_node;
> + }
> +
> + lvds->next = of_drm_find_bridge(remote);
> + if (!lvds->next)
> + ret = -EPROBE_DEFER;
> +
> +error_put_remote_node:
> + of_node_put(remote);
> +error_put_lvds_node:
> + of_node_put(lvds_output);
> +
> + return ret;
> +}
> +
> +static int lvds_decoder_probe(struct platform_device *pdev)
> +{
> + struct lvds_decoder *lvds;
> + int ret;
> +
> + lvds = devm_kzalloc(&pdev->dev, sizeof(*lvds), GFP_KERNEL);
> + if (!lvds)
> + return -ENOMEM;
> +
> + lvds->dev = &pdev->dev;
> + platform_set_drvdata(pdev, lvds);
> +
> + ret = lvds_decoder_parse_dt(lvds);
> + if (ret)
> + return ret;
> +
> + lvds->bridge.d
Re: [PATCH v2 0/3] drm: Add LVDS decoder bridge
On 09.03.2018 14:51, Jacopo Mondi wrote: > Hello, >after some discussion on the proposed bindings for generic lvds decoder and > Thine THC63LVD1024, I decided to drop the THC63 specific part and just live > with > a transparent decoder that does not support any configuration from DT. > > Dropping THC63 support to avoid discussion on how to better implement support > for a DRM bridge with 2 input ports and focus on LVDS mode propagation through > bridges as explained in v1 cover letter (for DRM people: please see [1] as why > I find difficult to implement support for bridges with multiple input > endpoints) > > Same base branch as v1, with same patches for V3M Eagle applied on top. > git://jmondi.org/linux v3m/v4.16-rc3/base > > Thanks >j > > v1 -> v2: > - Drop support for THC63LVD1024 > > [1] I had a quick at how to model a DRM bridge with multiple input > ports, and I see a blocker in how DRM identifies and matches bridges using > the devices node in place of the endpoint nodes. > > As THC63LVD1024 supports up to 2 LVDS inputs and 2 LVDS outputs, I see only > a few ways to support that: > 1) register 2 drm bridges from the same driver (one for each input/output > pair) > but they would both be matches on the same device node when the preceding > bridge calls "of_drm_find_bridge()". > 2) register a single bridge with multiple "next bridges", but when the bridge > gets attached I don't see a way on how to identify on which next bridge > "drm_bridge_attach()" on, as it depends on the endpoint the current bridge > has been attached on first, and we don't have that information. > 3) Register more instances of the same chip in DTS, one for each input/output > pair. They gonna share supplies and gpios, and I don't like that. > > I had a quick look at the currently in mainline bridges and none of them has > multiple input endpoints, except for HDMI audio endpoint, which I haven't > found > in use in any DTS. I guess the problem has been already debated and maybe > solved > in the past, so feel free to point me to other sources. I think this is is a step in wrong direction, IMHO. Your previous patchset was quite OK, at least bindings, IMHO. Few things needed only polishing. Here we have unmanaged/transparent bridge, which is totally different, what happened to regulators and gpios from previous iteration. I do not have schematics of the board, but I guess respective pins of the bridge must be connected somehow. I think the problem you want to avoid (double bridge) should not be a problem at all. I suppose the most important is to have correct bindings - as they need to be stable. If you really must to do hacks better is to put them into driver. Regards Andrzej > > Jacopo Mondi (3): > dt-bindings: display: bridge: Document LVDS to parallel decoder > drm: bridge: Add LVDS decoder driver > arm64: dts: renesas: Add LVDS decoder to R-Car V3M Eagle > > .../bindings/display/bridge/lvds-decoder.txt | 42 ++ > arch/arm64/boot/dts/renesas/r8a77970-eagle.dts | 31 +++- > drivers/gpu/drm/bridge/Kconfig | 8 ++ > drivers/gpu/drm/bridge/Makefile| 1 + > drivers/gpu/drm/bridge/lvds-decoder.c | 157 > + > 5 files changed, 237 insertions(+), 2 deletions(-) > create mode 100644 > Documentation/devicetree/bindings/display/bridge/lvds-decoder.txt > create mode 100644 drivers/gpu/drm/bridge/lvds-decoder.c > > -- > 2.7.4 > > > >
Re: [PATCH v2 0/3] drm: Add LVDS decoder bridge
On 12.03.2018 13:30, jacopo mondi wrote: > Hi Andrzej, > > On Mon, Mar 12, 2018 at 10:07:27AM +0100, Andrzej Hajda wrote: >> On 09.03.2018 14:51, Jacopo Mondi wrote: >>> Hello, >>>after some discussion on the proposed bindings for generic lvds decoder >>> and >>> Thine THC63LVD1024, I decided to drop the THC63 specific part and just live >>> with >>> a transparent decoder that does not support any configuration from DT. >>> >>> Dropping THC63 support to avoid discussion on how to better implement >>> support >>> for a DRM bridge with 2 input ports and focus on LVDS mode propagation >>> through >>> bridges as explained in v1 cover letter (for DRM people: please see [1] as >>> why >>> I find difficult to implement support for bridges with multiple input >>> endpoints) >>> >>> Same base branch as v1, with same patches for V3M Eagle applied on top. >>> git://jmondi.org/linux v3m/v4.16-rc3/base >>> >>> Thanks >>>j >>> >>> v1 -> v2: >>> - Drop support for THC63LVD1024 >>> >>> [1] I had a quick at how to model a DRM bridge with multiple input >>> ports, and I see a blocker in how DRM identifies and matches bridges using >>> the devices node in place of the endpoint nodes. >>> >>> As THC63LVD1024 supports up to 2 LVDS inputs and 2 LVDS outputs, I see only >>> a few ways to support that: >>> 1) register 2 drm bridges from the same driver (one for each input/output >>> pair) >>> but they would both be matches on the same device node when the >>> preceding >>> bridge calls "of_drm_find_bridge()". >>> 2) register a single bridge with multiple "next bridges", but when the >>> bridge >>> gets attached I don't see a way on how to identify on which next bridge >>> "drm_bridge_attach()" on, as it depends on the endpoint the current >>> bridge >>> has been attached on first, and we don't have that information. >>> 3) Register more instances of the same chip in DTS, one for each >>> input/output >>> pair. They gonna share supplies and gpios, and I don't like that. >>> >>> I had a quick look at the currently in mainline bridges and none of them has >>> multiple input endpoints, except for HDMI audio endpoint, which I haven't >>> found >>> in use in any DTS. I guess the problem has been already debated and maybe >>> solved >>> in the past, so feel free to point me to other sources. >> I think this is is a step in wrong direction, IMHO. Your previous >> patchset was quite OK, at least bindings, IMHO. Few things needed only >> polishing. >> Here we have unmanaged/transparent bridge, which is totally different, >> what happened to regulators and gpios from previous iteration. >> I do not have schematics of the board, but I guess respective pins of >> the bridge must be connected somehow. >> I think the problem you want to avoid (double bridge) should not be a >> problem at all. >> I suppose the most important is to have correct bindings - as they need >> to be stable. >> If you really must to do hacks better is to put them into driver. >> > I understand. The "transparent bridge" is of no actual use, but I don't see > how the "double bridge" thing is not an issue if I were to develop > support for the actual Thine chip. What is exactly your configuration: single/dual input, single/dual output? Current bindings suggests single/single, am I right? In such case you do not need to implement dual link functionality in the driver - since you even do not have possibility to test it. But the bindings should support all modes of operation, or at least should be easy to extend them in the future with backward compatibility. > > Please see my reply from yesterday to Archit. I still think having two > bridges is somehow an issue... Yes, I agree. But do we have such case? If no - no problem ATM :), if yes - lets try to implement it and see where is the problem, as Archit already suggested it would be just a matter of assigning bridge to port node, instead of device node. > > While we clarify that, would it be fine an initial driver version for > the actualt Thine chip with a single input support[1]? I would ditch this > transparent bridge and resume working on a THC63LVD1024 driver from > comments received on v1. I think, yes: driver with only single input, and full or extend-able bindings. > > Thanks > j > >
Re: [PATCH v5 0/6] dt-bindings: add bindings for USB physical connector
Hi Rob, Chanwoo, Krzysztof, On 27.02.2018 08:11, Andrzej Hajda wrote: > Hi, > > Thanks for reviews of previous iterations. > > This patchset introduces USB physical connector bindings, together with > working example. > I have removed RFC prefix - the patchset seems to be heading > to a happy end :) > > v5: fixed extra parenthesis in dts, renamed extcon function. > v4: improved binding descriptions, added missing reg in dts. > v3: Separate binding for Samsung 11-pin connector, added full-blown USB-C > example. > v2: I have addressed comments by Rob and Laurent, thanks > > Changes in datail are described in the patches. > > Regards > Andrzej > > > Andrzej Hajda (5): > dt-bindings: add bindings for USB physical connector > dt-bindings: add bindings for Samsung micro-USB 11-pin connector > arm64: dts: exynos: add micro-USB connector node to TM2 platforms > arm64: dts: exynos: add OF graph between MHL and USB connector > extcon: add possibility to get extcon device by OF node > > Maciej Purski (1): > drm/bridge/sii8620: use micro-USB cable detection logic to detect MHL It looks like all patches received R-B or acks (I forgot add Krzysztof's acks for dts part). Now I have a question how to merge them. The only functional dependency is between bridge and extcon, and from the formal PoV bindings should be merged 1st. I can merge it: 1. All patches via drm-misc tree. 2. All patches except dts via drm-misc, and Krzysztof will merge dts via samsung-soc tree. Is it OK, for all? Better ideas? Regards Andrzej > > .../connector/samsung,usb-connector-11pin.txt | 49 +++ > .../bindings/connector/usb-connector.txt | 75 + > .../boot/dts/exynos/exynos5433-tm2-common.dtsi | 38 - > drivers/extcon/extcon.c| 44 +++--- > drivers/gpu/drm/bridge/sil-sii8620.c | 97 > +- > include/linux/extcon.h | 6 ++ > 6 files changed, 293 insertions(+), 16 deletions(-) > create mode 100644 > Documentation/devicetree/bindings/connector/samsung,usb-connector-11pin.txt > create mode 100644 > Documentation/devicetree/bindings/connector/usb-connector.txt >
Re: [PATCH v5 0/6] dt-bindings: add bindings for USB physical connector
Hi Chanwoo, Archit, On 07.03.2018 05:48, Chanwoo Choi wrote: > On 2018년 03월 07일 11:12, Chanwoo Choi wrote: >> Hi Rob and Andrzej, >> >> On 2018년 03월 06일 21:53, Andrzej Hajda wrote: >>> Hi Rob, Chanwoo, Krzysztof, >>> >>> >>> On 27.02.2018 08:11, Andrzej Hajda wrote: >>>> Hi, >>>> >>>> Thanks for reviews of previous iterations. >>>> >>>> This patchset introduces USB physical connector bindings, together with >>>> working example. >>>> I have removed RFC prefix - the patchset seems to be heading >>>> to a happy end :) >>>> >>>> v5: fixed extra parenthesis in dts, renamed extcon function. >>>> v4: improved binding descriptions, added missing reg in dts. >>>> v3: Separate binding for Samsung 11-pin connector, added full-blown USB-C >>>> example. >>>> v2: I have addressed comments by Rob and Laurent, thanks >>>> >>>> Changes in datail are described in the patches. >>>> >>>> Regards >>>> Andrzej >>>> >>>> >>>> Andrzej Hajda (5): >>>> dt-bindings: add bindings for USB physical connector >>>> dt-bindings: add bindings for Samsung micro-USB 11-pin connector >>>> arm64: dts: exynos: add micro-USB connector node to TM2 platforms >>>> arm64: dts: exynos: add OF graph between MHL and USB connector >>>> extcon: add possibility to get extcon device by OF node >>>> >>>> Maciej Purski (1): >>>> drm/bridge/sii8620: use micro-USB cable detection logic to detect MHL >>> It looks like all patches received R-B or acks (I forgot add Krzysztof's >>> acks for dts part). >>> Now I have a question how to merge them. >>> The only functional dependency is between bridge and extcon, and from >>> the formal PoV bindings should be merged 1st. >>> I can merge it: >>> 1. All patches via drm-misc tree. >>> 2. All patches except dts via drm-misc, and Krzysztof will merge dts via >>> samsung-soc tree. >>> >>> Is it OK, for all? Better ideas? >> Krzysztof picked the dts patches. I'll make the immutable branch based on >> v4.16-rc1 >> and apply them except for dts patchs. And I'll send the immutable branch to >> Rob and Andrzej. >> >> > I made the immutable branch[1] as following: If you agree, I'll send pull > request. > [1] > https://git.kernel.org/pub/scm/linux/kernel/git/chanwoo/extcon.git/log/?h=ib-extcon-drm-dt-v4.17 > > Or you can make the immutable branch and send pull request to Rob and me. > It seems you took v5 instead of v6 version of extcon patch. Beside it I am OK with your immutable branch, Archit is it OK to do it this way in drm-misc? Regards Andrzej
Re: [PATCH v5 0/6] dt-bindings: add bindings for USB physical connector
On 07.03.2018 12:22, Krzysztof Kozlowski wrote: > On Wed, Mar 7, 2018 at 12:13 PM, Andrzej Hajda wrote: >> Hi Chanwoo, Archit, >> >> On 07.03.2018 05:48, Chanwoo Choi wrote: >>> On 2018년 03월 07일 11:12, Chanwoo Choi wrote: >>>> Hi Rob and Andrzej, >>>> >>>> On 2018년 03월 06일 21:53, Andrzej Hajda wrote: >>>>> Hi Rob, Chanwoo, Krzysztof, >>>>> >>>>> >>>>> On 27.02.2018 08:11, Andrzej Hajda wrote: >>>>>> Hi, >>>>>> >>>>>> Thanks for reviews of previous iterations. >>>>>> >>>>>> This patchset introduces USB physical connector bindings, together with >>>>>> working example. >>>>>> I have removed RFC prefix - the patchset seems to be heading >>>>>> to a happy end :) >>>>>> >>>>>> v5: fixed extra parenthesis in dts, renamed extcon function. >>>>>> v4: improved binding descriptions, added missing reg in dts. >>>>>> v3: Separate binding for Samsung 11-pin connector, added full-blown USB-C >>>>>> example. >>>>>> v2: I have addressed comments by Rob and Laurent, thanks >>>>>> >>>>>> Changes in datail are described in the patches. >>>>>> >>>>>> Regards >>>>>> Andrzej >>>>>> >>>>>> >>>>>> Andrzej Hajda (5): >>>>>> dt-bindings: add bindings for USB physical connector >>>>>> dt-bindings: add bindings for Samsung micro-USB 11-pin connector >>>>>> arm64: dts: exynos: add micro-USB connector node to TM2 platforms >>>>>> arm64: dts: exynos: add OF graph between MHL and USB connector >>>>>> extcon: add possibility to get extcon device by OF node >>>>>> >>>>>> Maciej Purski (1): >>>>>> drm/bridge/sii8620: use micro-USB cable detection logic to detect MHL >>>>> It looks like all patches received R-B or acks (I forgot add Krzysztof's >>>>> acks for dts part). >>>>> Now I have a question how to merge them. >>>>> The only functional dependency is between bridge and extcon, and from >>>>> the formal PoV bindings should be merged 1st. >>>>> I can merge it: >>>>> 1. All patches via drm-misc tree. >>>>> 2. All patches except dts via drm-misc, and Krzysztof will merge dts via >>>>> samsung-soc tree. >>>>> >>>>> Is it OK, for all? Better ideas? >>>> Krzysztof picked the dts patches. I'll make the immutable branch based on >>>> v4.16-rc1 >>>> and apply them except for dts patchs. And I'll send the immutable branch >>>> to Rob and Andrzej. >>>> >>>> >>> I made the immutable branch[1] as following: If you agree, I'll send pull >>> request. >>> [1] >>> https://git.kernel.org/pub/scm/linux/kernel/git/chanwoo/extcon.git/log/?h=ib-extcon-drm-dt-v4.17 >>> >>> Or you can make the immutable branch and send pull request to Rob and me. >>> >> It seems you took v5 instead of v6 version of extcon patch. > I also took v5: > https://patchwork.kernel.org/patch/10244407/ > https://patchwork.kernel.org/patch/10244431/ > > There was no v6 in samsung-soc patchwork. Is it a problem for DTS? No, v6 was only typo fix in comment, and only extcon patch has v6. Regards Andrzej > > BR, > Krzysztof > > >
Re: [PATCH v6 1/3] dt-bindings: display: bridge: Document THC63LVD1024 LVDS decoder
On 27.03.2018 08:15, Vladimir Zapolskiy wrote:
> Hi Jacopo,
>
> On 03/27/2018 01:22 AM, Rob Herring wrote:
>> On Tue, Mar 20, 2018 at 02:43:33PM +0200, Laurent Pinchart wrote:
>>> Hi Jacopo,
>>>
>>> (CC'ing Rob)
>>>
>>> Thank you for the patch.
>>>
>>> On Friday, 16 March 2018 17:16:37 EET Jacopo Mondi wrote:
>>>> Document Thine THC63LVD1024 LVDS decoder device tree bindings.
>>>>
>>>> Signed-off-by: Jacopo Mondi
>>>> Reviewed-by: Andrzej Hajda
>>>> Reviewed-by: Niklas Söderlund
>>>> ---
>>>> .../bindings/display/bridge/thine,thc63lvd1024.txt | 66
>>>> +++
>>>> 1 file changed, 66 insertions(+)
>>>> create mode 100644
>>>> Documentation/devicetree/bindings/display/bridge/thine,thc63lvd1024.txt
>>>>
>>>> diff --git
>>>> a/Documentation/devicetree/bindings/display/bridge/thine,thc63lvd1024.txt
>>>> b/Documentation/devicetree/bindings/display/bridge/thine,thc63lvd1024.txt
>>>> new file mode 100644
>>>> index 000..8225c6a
>>>> --- /dev/null
>>>> +++
>>>> b/Documentation/devicetree/bindings/display/bridge/thine,thc63lvd1024.txt
>>>> @@ -0,0 +1,66 @@
>>>> +Thine Electronics THC63LVD1024 LVDS decoder
>>>> +---
>>>> +
>>>> +The THC63LVD1024 is a dual link LVDS receiver designed to convert LVDS
>>>> streams
>>>> +to parallel data outputs. The chip supports single/dual input/output
>>>> modes,
>>>> +handling up to two two input LVDS stream and up to two digital CMOS/TTL
>>>> outputs.
>>>> +
>>>> +Single or dual operation modes, output data mapping and DDR output modes
>>>> are
>>>> +configured through input signals and the chip does not expose any control
>>>> bus.
>>>> +
>>>> +Required properties:
>>>> +- compatible: Shall be "thine,thc63lvd1024"
>>>> +
>>>> +Optional properties:
>>>> +- vcc-supply: Power supply for TTL output and digital circuitry
>>>> +- cvcc-supply: Power supply for TTL CLOCKOUT signal
>>>> +- lvcc-supply: Power supply for LVDS inputs
>>>> +- pvcc-supply: Power supply for PLL circuitry
>>> As explained in a comment to one of the previous versions of this series,
>>> I'm
>>> tempted to make vcc-supply mandatory and drop the three other power
>>> supplies
>>> for now, as I believe there's very little chance they will be connected to
>>> separately controllable regulators (all supplies use the same voltage). In
>>> the
>>> very unlikely event that this occurs in design we need to support in the
>>> future, the cvcc, lvcc and pvcc supplies can be added later as optional
>>> without breaking backward compatibility.
>> I'm okay with that.
>>
>>> Apart from that,
>>>
>>> Reviewed-by: Laurent Pinchart
>>>
>>>> +- pdwn-gpios: Power down GPIO signal. Active low
>> powerdown-gpios is the semi-standard name.
>>
> right, I've also noticed it. If possible please avoid shortenings in
> property names.
It is not shortening, it just follow pin name from decoder's datasheet.
>
>>>> +- oe-gpios: Output enable GPIO signal. Active high
>>>> +
> And this one is also a not ever met property name, please consider to
> rename it to 'enable-gpios', for instance display panels define it.
Again, it follows datasheet naming scheme. Has something changed in DT
conventions?
Regards
Andrzej
>
>>>> +The THC63LVD1024 video port connections are modeled according
>>>> +to OF graph bindings specified by
>>>> Documentation/devicetree/bindings/graph.txt
> [snip]
>
>>>> +
>>>> + port@2{
>>>> + reg = <2>;
>>>> +
>>>> + lvds_dec_out_2: endpoint {
>>>> + remote-endpoint = <&adv7511_in>;
>>>> + };
>>>> +
> Drop a surplus empty line above.
>
>>>> + };
>>>> +
> Drop a surplus empty line above.
>
>>>> + };
>>>> + };
> --
> With best wishes,
> Vladimir
>
>
>
Re: [PATCH v6 2/3] drm: bridge: Add thc63lvd1024 LVDS decoder driver
On 27.03.2018 08:24, Vladimir Zapolskiy wrote:
> Hi Jacopo,
>
> On 03/16/2018 05:16 PM, Jacopo Mondi wrote:
>> Add DRM bridge driver for Thine THC63LVD1024 LVDS to digital parallel
>> output converter.
>>
>> Signed-off-by: Jacopo Mondi
>> Reviewed-by: Andrzej Hajda
>> Reviewed-by: Niklas Söderlund
>> ---
>> drivers/gpu/drm/bridge/Kconfig| 6 +
>> drivers/gpu/drm/bridge/Makefile | 1 +
>> drivers/gpu/drm/bridge/thc63lvd1024.c | 255
>> ++
>> 3 files changed, 262 insertions(+)
>> create mode 100644 drivers/gpu/drm/bridge/thc63lvd1024.c
>>
>> diff --git a/drivers/gpu/drm/bridge/Kconfig b/drivers/gpu/drm/bridge/Kconfig
>> index 3b99d5a..5815a20 100644
>> --- a/drivers/gpu/drm/bridge/Kconfig
>> +++ b/drivers/gpu/drm/bridge/Kconfig
>> @@ -92,6 +92,12 @@ config DRM_SII9234
>>It is an I2C driver, that detects connection of MHL bridge
>>and starts encapsulation of HDMI signal.
>>
>> +config DRM_THINE_THC63LVD1024
>> +tristate "Thine THC63LVD1024 LVDS decoder bridge"
>> +depends on OF
>> +---help---
>> + Thine THC63LVD1024 LVDS/parallel converter driver.
>> +
>> config DRM_TOSHIBA_TC358767
>> tristate "Toshiba TC358767 eDP bridge"
>> depends on OF
>> diff --git a/drivers/gpu/drm/bridge/Makefile
>> b/drivers/gpu/drm/bridge/Makefile
>> index 373eb28..fd90b16 100644
>> --- a/drivers/gpu/drm/bridge/Makefile
>> +++ b/drivers/gpu/drm/bridge/Makefile
>> @@ -8,6 +8,7 @@ obj-$(CONFIG_DRM_PARADE_PS8622) += parade-ps8622.o
>> obj-$(CONFIG_DRM_SIL_SII8620) += sil-sii8620.o
>> obj-$(CONFIG_DRM_SII902X) += sii902x.o
>> obj-$(CONFIG_DRM_SII9234) += sii9234.o
>> +obj-$(CONFIG_DRM_THINE_THC63LVD1024) += thc63lvd1024.o
>> obj-$(CONFIG_DRM_TOSHIBA_TC358767) += tc358767.o
>> obj-$(CONFIG_DRM_ANALOGIX_DP) += analogix/
>> obj-$(CONFIG_DRM_I2C_ADV7511) += adv7511/
>> diff --git a/drivers/gpu/drm/bridge/thc63lvd1024.c
>> b/drivers/gpu/drm/bridge/thc63lvd1024.c
>> new file mode 100644
>> index 000..02a54c2
>> --- /dev/null
>> +++ b/drivers/gpu/drm/bridge/thc63lvd1024.c
>> @@ -0,0 +1,255 @@
>> +// SPDX-License-Identifier: GPL-2.0
>> +/*
>> + * THC63LVD1024 LVDS to parallel data DRM bridge driver.
>> + *
>> + * Copyright (C) 2018 Jacopo Mondi
>> + */
>> +
>> +#include
>> +#include
>> +#include
>> +
>> +#include
>> +#include
>> +#include
>> +
>> +enum {
>> +THC63_LVDS_IN0,
>> +THC63_LVDS_IN1,
>> +THC63_DIGITAL_OUT0,
>> +THC63_DIGITAL_OUT1,
>> +};
>> +
>> +static const char * const thc63_reg_names[] = {
>> +"vcc", "lvcc", "pvcc", "cvcc",
>> +};
>> +
>> +struct thc63_dev {
>> +struct device *dev;
>> +
>> +struct regulator *vccs[ARRAY_SIZE(thc63_reg_names)];
>> +
>> +struct gpio_desc *pdwn;
>> +struct gpio_desc *oe;
>> +
>> +struct drm_bridge bridge;
>> +struct drm_bridge *next;
>> +};
>> +
>> +static inline struct thc63_dev *to_thc63(struct drm_bridge *bridge)
>> +{
>> +return container_of(bridge, struct thc63_dev, bridge);
>> +}
>> +
>> +static int thc63_attach(struct drm_bridge *bridge)
>> +{
>> +struct thc63_dev *thc63 = to_thc63(bridge);
>> +
>> +return drm_bridge_attach(bridge->encoder, thc63->next, bridge);
>> +}
>> +
>> +static void thc63_enable(struct drm_bridge *bridge)
>> +{
>> +struct thc63_dev *thc63 = to_thc63(bridge);
>> +struct regulator *vcc;
>> +int i;
> unsigned int i;
Why? You are introducing silly bug this way, see few lines below.
>
>> +
>> +for (i = 0; i < ARRAY_SIZE(thc63->vccs); i++) {
>> +vcc = thc63->vccs[i];
>> +if (!vcc)
>> +continue;
>> +
>> +if (regulator_enable(vcc))
>> +goto error_vcc_enable;
>> +}
>> +
>> +if (thc63->pdwn)
>> +gpiod_set_value(thc63->pdwn, 0);
>> +
>> +if (thc63->oe)
>> +gpiod_set_value(thc63->oe, 1);
>> +
>> +return;
>> +
>> +error_vcc_enable:
>> +dev_err(thc63->dev, "Failed to enable regulator %s\n",
>> +thc63_reg_names[i]);
>> +
>> +for (i = i - 1; i >= 0; i--) {
Here, the loo
Re: [PATCH v6 2/3] drm: bridge: Add thc63lvd1024 LVDS decoder driver
On 27.03.2018 09:36, Geert Uytterhoeven wrote:
> Hi Andrzej,
>
> On Tue, Mar 27, 2018 at 9:28 AM, Andrzej Hajda wrote:
>>>> --- /dev/null
>>>> +++ b/drivers/gpu/drm/bridge/thc63lvd1024.c
>>>> +static void thc63_enable(struct drm_bridge *bridge)
>>>> +{
>>>> +struct thc63_dev *thc63 = to_thc63(bridge);
>>>> +struct regulator *vcc;
>>>> +int i;
>>> unsigned int i;
>> Why? You are introducing silly bug this way, see few lines below.
>>
>>>> +
>>>> +for (i = 0; i < ARRAY_SIZE(thc63->vccs); i++) {
>>>> +vcc = thc63->vccs[i];
>>>> +if (!vcc)
>>>> +continue;
>>>> +
>>>> +if (regulator_enable(vcc))
>>>> +goto error_vcc_enable;
>>>> +}
>>>> +
>>>> +if (thc63->pdwn)
>>>> +gpiod_set_value(thc63->pdwn, 0);
>>>> +
>>>> +if (thc63->oe)
>>>> +gpiod_set_value(thc63->oe, 1);
>>>> +
>>>> +return;
>>>> +
>>>> +error_vcc_enable:
>>>> +dev_err(thc63->dev, "Failed to enable regulator %s\n",
>>>> +thc63_reg_names[i]);
>>>> +
>>>> +for (i = i - 1; i >= 0; i--) {
>> Here, the loop will not end if you define i unsigned.
> True.
>
>> I know one can change the loop, to make it working with unsigned. But
>> this clearly shows that using unsigned is more risky.
>> What are advantages of unsigned vs int in this case. Are there some
>> guidelines/discussions about it?
> Some people consider signed integers harmful, as they may be converted
> silently by the compiler to the "larger" unsigned type when needed.
Wow, it sounds crazy, shall we expect gigantic patchsets, converting all
occurrences of int to "unsigned int" ? :)
I know both types have their pros and cons and can behave unexpectedly
in corner cases, but I do not see why unsigned should be preferred over
signed in general, or in this particular case.
I guess there were somewhere discussion about it, could you point me to
it if possible, to avoid unnecessary noise in this thread.
Regards
Andrzej
>
> Gr{oetje,eeting}s,
>
> Geert
>
Re: drivers/gpu/drm/bridge/sil-sii8620.c:2405: undefined reference to `extcon_unregister_notifier'
Hi Chanwoo,
It looks like something went wrong, sii8620 patch was merged without
extcon dependencies.
Could you look at it?
Regards
Andrzej
On 06.04.2018 11:52, kbuild test robot wrote:
> tree: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git
> master
> head: 38c23685b273cfb4ccf31a199feccce3bdcb5d83
> commit: 688838442147d9dd94c2ef7c2c31a35cf150c5fa drm/bridge/sii8620: use
> micro-USB cable detection logic to detect MHL
> date: 4 weeks ago
> config: i386-randconfig-x0-04061534 (attached as .config)
> compiler: gcc-5 (Debian 5.5.0-3) 5.4.1 20171010
> reproduce:
> git checkout 688838442147d9dd94c2ef7c2c31a35cf150c5fa
> # save the attached .config to linux build tree
> make ARCH=i386
>
> All errors (new ones prefixed by >>):
>
>drivers/gpu/drm/bridge/sil-sii8620.o: In function `sii8620_remove':
>>> drivers/gpu/drm/bridge/sil-sii8620.c:2405: undefined reference to
>>> `extcon_unregister_notifier'
>drivers/gpu/drm/bridge/sil-sii8620.o: In function `sii8620_extcon_init':
>>> drivers/gpu/drm/bridge/sil-sii8620.c:2229: undefined reference to
>>> `extcon_find_edev_by_node'
>>> drivers/gpu/drm/bridge/sil-sii8620.c:2241: undefined reference to
>>> `extcon_register_notifier'
>drivers/gpu/drm/bridge/sil-sii8620.o: In function `sii8620_extcon_work':
>>> drivers/gpu/drm/bridge/sil-sii8620.c:2189: undefined reference to
>>> `extcon_get_state'
> vim +2405 drivers/gpu/drm/bridge/sil-sii8620.c
>
> 2212
> 2213static int sii8620_extcon_init(struct sii8620 *ctx)
> 2214{
> 2215struct extcon_dev *edev;
> 2216struct device_node *musb, *muic;
> 2217int ret;
> 2218
> 2219/* get micro-USB connector node */
> 2220musb = of_graph_get_remote_node(ctx->dev->of_node, 1,
> -1);
> 2221/* next get micro-USB Interface Controller node */
> muic = of_get_next_parent(musb);
> 2223
> 2224if (!muic) {
> 2225dev_info(ctx->dev, "no extcon found, switching
> to 'always on' mode\n");
> 2226return 0;
> 2227}
> 2228
>> 2229 edev = extcon_find_edev_by_node(muic);
> 2230of_node_put(muic);
> 2231if (IS_ERR(edev)) {
> 2232if (PTR_ERR(edev) == -EPROBE_DEFER)
> 2233return -EPROBE_DEFER;
> 2234dev_err(ctx->dev, "Invalid or missing
> extcon\n");
> 2235return PTR_ERR(edev);
> 2236}
> 2237
> 2238ctx->extcon = edev;
> 2239ctx->extcon_nb.notifier_call = sii8620_extcon_notifier;
> 2240INIT_WORK(&ctx->extcon_wq, sii8620_extcon_work);
>> 2241 ret = extcon_register_notifier(edev, EXTCON_DISP_MHL,
>> &ctx->extcon_nb);
> 2242if (ret) {
> 2243dev_err(ctx->dev, "failed to register notifier
> for MHL\n");
> 2244return ret;
> 2245}
> 2246
> 2247return 0;
> 2248}
> 2249
> 2250static inline struct sii8620 *bridge_to_sii8620(struct
> drm_bridge *bridge)
> 2251{
> 2252return container_of(bridge, struct sii8620, bridge);
> 2253}
> 2254
> 2255static int sii8620_attach(struct drm_bridge *bridge)
> 2256{
> 2257struct sii8620 *ctx = bridge_to_sii8620(bridge);
> 2258
> 2259sii8620_init_rcp_input_dev(ctx);
> 2260
> 2261return sii8620_clear_error(ctx);
> 2262}
> 2263
> 2264static void sii8620_detach(struct drm_bridge *bridge)
> 2265{
> 2266struct sii8620 *ctx = bridge_to_sii8620(bridge);
> 2267
> 2268rc_unregister_device(ctx->rc_dev);
> 2269}
> 2270
> 2271static enum drm_mode_status sii8620_mode_valid(struct
> drm_bridge *bridge,
> 2272 const struct
> drm_display_mode *mode)
> 2273{
> 2274struct sii8620 *ctx = bridge_to_sii8620(bridge);
> 2275bool can_pack = ctx->devcap[MHL_DCAP_VID_LINK_MODE] &
> 2276MHL_DCAP_VID_LINK_PPIXEL;
> 2277unsigned int max_pclk = sii8620_is_mhl3(ctx) ?
> MHL3_MAX_LCLK :
> 2278
> MHL1_MAX_LCLK;
> 2279max_pclk /= can_pack ? 2 : 3;
> 2280
> 2281return (mode->clock > max_pclk) ? MODE_CLOCK_HIGH :
> MODE_OK;
> 2282}
> 2283
> 2284static bool sii8620_mode_fixup(struct drm_bridge *bridge,
> 228
Re: drivers/gpu/drm/bridge/sil-sii8620.c:2405: undefined reference to `extcon_unregister_notifier'
On 06.04.2018 12:34, Chanwoo Choi wrote:
> Hi Andrzej,
>
> On 2018년 04월 06일 19:14, Andrzej Hajda wrote:
>> Hi Chanwoo,
>>
>> It looks like something went wrong, sii8620 patch was merged without
>> extcon dependencies.
>> Could you look at it?
> If add the 'select EXTCON' to sii8620's Kconfig, it will be solved.
> Is there other solution?
I wonder if 'imply EXTCON' wouldn't be better, I will prepare patch for it.
Regards
Andrzej
>
>> Regards
>> Andrzej
>>
>> On 06.04.2018 11:52, kbuild test robot wrote:
>>> tree: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git
>>> master
>>> head: 38c23685b273cfb4ccf31a199feccce3bdcb5d83
>>> commit: 688838442147d9dd94c2ef7c2c31a35cf150c5fa drm/bridge/sii8620: use
>>> micro-USB cable detection logic to detect MHL
>>> date: 4 weeks ago
>>> config: i386-randconfig-x0-04061534 (attached as .config)
>>> compiler: gcc-5 (Debian 5.5.0-3) 5.4.1 20171010
>>> reproduce:
>>> git checkout 688838442147d9dd94c2ef7c2c31a35cf150c5fa
>>> # save the attached .config to linux build tree
>>> make ARCH=i386
>>>
>>> All errors (new ones prefixed by >>):
>>>
>>>drivers/gpu/drm/bridge/sil-sii8620.o: In function `sii8620_remove':
>>>>> drivers/gpu/drm/bridge/sil-sii8620.c:2405: undefined reference to
>>>>> `extcon_unregister_notifier'
>>>drivers/gpu/drm/bridge/sil-sii8620.o: In function `sii8620_extcon_init':
>>>>> drivers/gpu/drm/bridge/sil-sii8620.c:2229: undefined reference to
>>>>> `extcon_find_edev_by_node'
>>>>> drivers/gpu/drm/bridge/sil-sii8620.c:2241: undefined reference to
>>>>> `extcon_register_notifier'
>>>drivers/gpu/drm/bridge/sil-sii8620.o: In function `sii8620_extcon_work':
>>>>> drivers/gpu/drm/bridge/sil-sii8620.c:2189: undefined reference to
>>>>> `extcon_get_state'
>>> vim +2405 drivers/gpu/drm/bridge/sil-sii8620.c
>>>
>>> 2212
>>> 2213 static int sii8620_extcon_init(struct sii8620 *ctx)
>>> 2214 {
>>> 2215 struct extcon_dev *edev;
>>> 2216 struct device_node *musb, *muic;
>>> 2217 int ret;
>>> 2218
>>> 2219 /* get micro-USB connector node */
>>> 2220 musb = of_graph_get_remote_node(ctx->dev->of_node, 1,
>>> -1);
>>> 2221 /* next get micro-USB Interface Controller node */
>>> muic = of_get_next_parent(musb);
>>> 2223
>>> 2224 if (!muic) {
>>> 2225 dev_info(ctx->dev, "no extcon found, switching
>>> to 'always on' mode\n");
>>> 2226 return 0;
>>> 2227 }
>>> 2228
>>>> 2229 edev = extcon_find_edev_by_node(muic);
>>> 2230 of_node_put(muic);
>>> 2231 if (IS_ERR(edev)) {
>>> 2232 if (PTR_ERR(edev) == -EPROBE_DEFER)
>>> 2233 return -EPROBE_DEFER;
>>> 2234 dev_err(ctx->dev, "Invalid or missing
>>> extcon\n");
>>> 2235 return PTR_ERR(edev);
>>> 2236 }
>>> 2237
>>> 2238 ctx->extcon = edev;
>>> 2239 ctx->extcon_nb.notifier_call = sii8620_extcon_notifier;
>>> 2240 INIT_WORK(&ctx->extcon_wq, sii8620_extcon_work);
>>>> 2241 ret = extcon_register_notifier(edev, EXTCON_DISP_MHL,
>>>> &ctx->extcon_nb);
>>> 2242 if (ret) {
>>> 2243 dev_err(ctx->dev, "failed to register notifier
>>> for MHL\n");
>>> 2244 return ret;
>>> 2245 }
>>> 2246
>>> 2247 return 0;
>>> 2248 }
>>> 2249
>>> 2250 static inline struct sii8620 *bridge_to_sii8620(struct
>>> drm_bridge *bridge)
>>> 2251 {
>>> 2252 return container_of(bridge, struct sii8620, bridge);
>>> 2253 }
>>> 2254
>>> 2255 static int sii8620_attach(struct drm_bridge *bridge)
>>> 2256 {
>>
Re: [PATCH v6 23/30] drm/rockchip: analogix_dp: Do not call Analogix code before bind
On 05.04.2018 11:49, Enric Balletbo i Serra wrote:
> From: Tomasz Figa
>
> Driver callbacks, such as system suspend or resume can be called any
> time, specifically they can be called before the component bind
> callback. Let's use dp->adp pointer as a safeguard and skip calling
> Analogix entry points if it is an ERR_PTR().
>From purity PoV I would store either 0 either valid pointer in dp->adp,
but functionally it should be the same.
Reviewed-by: Andrzej Hajda
--
Regards
Andrzej
>
> Signed-off-by: Tomasz Figa
> Signed-off-by: Thierry Escande
> Signed-off-by: Enric Balletbo i Serra
> Tested-by: Marek Szyprowski
> ---
>
> drivers/gpu/drm/rockchip/analogix_dp-rockchip.c | 9 +
> 1 file changed, 9 insertions(+)
>
> diff --git a/drivers/gpu/drm/rockchip/analogix_dp-rockchip.c
> b/drivers/gpu/drm/rockchip/analogix_dp-rockchip.c
> index 23317a2269e1..6d45d62466b3 100644
> --- a/drivers/gpu/drm/rockchip/analogix_dp-rockchip.c
> +++ b/drivers/gpu/drm/rockchip/analogix_dp-rockchip.c
> @@ -368,6 +368,8 @@ static void rockchip_dp_unbind(struct device *dev, struct
> device *master,
> analogix_dp_unbind(dp->adp);
> rockchip_drm_psr_unregister(&dp->encoder);
> dp->encoder.funcs->destroy(&dp->encoder);
> +
> + dp->adp = ERR_PTR(-ENODEV);
> }
>
> static const struct component_ops rockchip_dp_component_ops = {
> @@ -391,6 +393,7 @@ static int rockchip_dp_probe(struct platform_device *pdev)
> return -ENOMEM;
>
> dp->dev = dev;
> + dp->adp = ERR_PTR(-ENODEV);
> dp->plat_data.panel = panel;
>
> ret = rockchip_dp_of_probe(dp);
> @@ -414,6 +417,9 @@ static int rockchip_dp_suspend(struct device *dev)
> {
> struct rockchip_dp_device *dp = dev_get_drvdata(dev);
>
> + if (IS_ERR(dp->adp))
> + return 0;
> +
> return analogix_dp_suspend(dp->adp);
> }
>
> @@ -421,6 +427,9 @@ static int rockchip_dp_resume(struct device *dev)
> {
> struct rockchip_dp_device *dp = dev_get_drvdata(dev);
>
> + if (IS_ERR(dp->adp))
> + return 0;
> +
> return analogix_dp_resume(dp->adp);
> }
> #endif
Re: [PATCH 1/3] dt-bindings: display: bridge: Document THC63LVD1024 LVDS decoder
On 08.03.2018 16:24, Jacopo Mondi wrote:
> Document Thine THC63LVD1024 LVDS decoder.
>
> Signed-off-by: Jacopo Mondi
> ---
> .../bindings/display/bridge/thine,thc63lvd1024.txt | 59
> ++
> 1 file changed, 59 insertions(+)
> create mode 100644
> Documentation/devicetree/bindings/display/bridge/thine,thc63lvd1024.txt
>
> diff --git
> a/Documentation/devicetree/bindings/display/bridge/thine,thc63lvd1024.txt
> b/Documentation/devicetree/bindings/display/bridge/thine,thc63lvd1024.txt
> new file mode 100644
> index 000..53b6453
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/display/bridge/thine,thc63lvd1024.txt
> @@ -0,0 +1,59 @@
> +THine Electronics THC63LVD1024 LVDS receiver
> +
> +
> +The THC63LVD1024 is an LVDS receiver designed to convert multiple LVDS
> streams
> +to digital CMOS/TTL parallel data.
You say multiple streams, but bindings describe only one stream.
> +
> +Required properties:
> +- compatible: Shall be one of the following:
> + "thine,thc63lvd1024",
> + "lvds-decoder"
> +
> +Optional properties:
> +- supply-vcc: Power supply for TTL output and digital circuitry
> +- supply-cvcc: Power supply for TTL CLOCKOUT signal
> +- supply-lvcc: Power supply for LVDS inputs
> +- supply-pvcc: Power supply for PLL circuitry
> +- pwnd-gpio: Power down GPIO signal. Active low.
Specs [1] uses "/PDWN" name for the pin, moreover gpios suffix is preferred.
Another issue I see is two possibly contradicting conventions:
1. Properties should be named according to specs - so here it should be
named pdwn-gpios.
2. The bindings tries to be generic for lvds decoders, in such case
probably preferred name should be more generic, maybe power-gpios.
Personally I would prefer 1, in such case generic lvds-decoder driver
should look for gpio names according to compatible string.
[1]: http://www.thine.co.jp/files/topics/179_ext_12_0.pdf
> +- oe-gpio: Output enable GPIO signal. Active high.
oe-gpios
> +
> +The THC63LVD1024 has two video ports, whose connections are modeled according
> +to OF graph bindings specified by Documentation/devicetree/bindings/graph.txt
> +
> +- Port@0: LVDS input port
> +- Port@1: Digital CMOS/TTL parallel output
According to specs it has two lvds input and two parallel output ports,
maybe it would be good to describe all here.
Regards
Andrzej
> +
> +Example:
> +---
> +
> + lvds_decoder: decoder-0 {
> + compatible = "thine,thc63lvd1024";
> +
> + vcc-supply = <®_lvds_vcc>;
> + lvcc-supply = <®_lvds_lvcc>;
> +
> + pwdn-gpio = <&gpio4 15 GPIO_ACTIVE_LOW>;
> +
> + ports {
> + #address-cells = <1>;
> + #size-cells = <0>;
> +
> + port@0 {
> + reg = <0>;
> +
> + lvds_dec_in: endpoint {
> + remote-endpoint = <&lvds_out>;
> + };
> + };
> +
> + port@1{
> + reg = <1>;
> +
> + lvds_dec_out: endpoint {
> + remote-endpoint = <&adv7511_in>;
> + };
> +
> + };
> +
> + };
> + };
Re: [PATCH v5 0/6] dt-bindings: add bindings for USB physical connector
Hi Chanwoo, On 08.03.2018 02:52, Chanwoo Choi wrote: > Hi Andrzej, Archit, > > On 2018년 03월 07일 20:13, Andrzej Hajda wrote: >> Hi Chanwoo, Archit, >> >> On 07.03.2018 05:48, Chanwoo Choi wrote: >>> On 2018년 03월 07일 11:12, Chanwoo Choi wrote: >>>> Hi Rob and Andrzej, >>>> >>>> On 2018년 03월 06일 21:53, Andrzej Hajda wrote: >>>>> Hi Rob, Chanwoo, Krzysztof, >>>>> >>>>> >>>>> On 27.02.2018 08:11, Andrzej Hajda wrote: >>>>>> Hi, >>>>>> >>>>>> Thanks for reviews of previous iterations. >>>>>> >>>>>> This patchset introduces USB physical connector bindings, together with >>>>>> working example. >>>>>> I have removed RFC prefix - the patchset seems to be heading >>>>>> to a happy end :) >>>>>> >>>>>> v5: fixed extra parenthesis in dts, renamed extcon function. >>>>>> v4: improved binding descriptions, added missing reg in dts. >>>>>> v3: Separate binding for Samsung 11-pin connector, added full-blown USB-C >>>>>> example. >>>>>> v2: I have addressed comments by Rob and Laurent, thanks >>>>>> >>>>>> Changes in datail are described in the patches. >>>>>> >>>>>> Regards >>>>>> Andrzej >>>>>> >>>>>> >>>>>> Andrzej Hajda (5): >>>>>> dt-bindings: add bindings for USB physical connector >>>>>> dt-bindings: add bindings for Samsung micro-USB 11-pin connector >>>>>> arm64: dts: exynos: add micro-USB connector node to TM2 platforms >>>>>> arm64: dts: exynos: add OF graph between MHL and USB connector >>>>>> extcon: add possibility to get extcon device by OF node >>>>>> >>>>>> Maciej Purski (1): >>>>>> drm/bridge/sii8620: use micro-USB cable detection logic to detect MHL >>>>> It looks like all patches received R-B or acks (I forgot add Krzysztof's >>>>> acks for dts part). >>>>> Now I have a question how to merge them. >>>>> The only functional dependency is between bridge and extcon, and from >>>>> the formal PoV bindings should be merged 1st. >>>>> I can merge it: >>>>> 1. All patches via drm-misc tree. >>>>> 2. All patches except dts via drm-misc, and Krzysztof will merge dts via >>>>> samsung-soc tree. >>>>> >>>>> Is it OK, for all? Better ideas? >>>> Krzysztof picked the dts patches. I'll make the immutable branch based on >>>> v4.16-rc1 >>>> and apply them except for dts patchs. And I'll send the immutable branch >>>> to Rob and Andrzej. >>>> >>>> >>> I made the immutable branch[1] as following: If you agree, I'll send pull >>> request. >>> [1] >>> https://git.kernel.org/pub/scm/linux/kernel/git/chanwoo/extcon.git/log/?h=ib-extcon-drm-dt-v4.17 >>> >>> Or you can make the immutable branch and send pull request to Rob and me. >>> >> It seems you took v5 instead of v6 version of extcon patch. > My mistake. I picked v6 and made the new immutable branch. > After Archit confirm it, I'll send pull request. > Lets just queue all patches (except dts) via extcon branch (thanks Daniel for advice), without making immutable branch. It seems to be a simplest acceptable approach. You can add my ack to sii8620 bridge patch (as bridge maintainer), to fulfill process requirements. Regards Andrzej
Re: [PATCH v3 1/3] dt-bindings: display: bridge: Document THC63LVD1024 LVDS decoder
On 13.03.2018 15:30, Jacopo Mondi wrote:
> Document Thine THC63LVD1024 LVDS decoder device tree bindings.
>
> Signed-off-by: Jacopo Mondi
> ---
> .../bindings/display/bridge/thine,thc63lvd1024.txt | 63
> ++
> 1 file changed, 63 insertions(+)
> create mode 100644
> Documentation/devicetree/bindings/display/bridge/thine,thc63lvd1024.txt
>
> diff --git
> a/Documentation/devicetree/bindings/display/bridge/thine,thc63lvd1024.txt
> b/Documentation/devicetree/bindings/display/bridge/thine,thc63lvd1024.txt
> new file mode 100644
> index 000..5b5afcd
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/display/bridge/thine,thc63lvd1024.txt
> @@ -0,0 +1,63 @@
> +Thine Electronics THC63LVD1024 LVDS decoder
> +---
> +
> +The THC63LVD1024 is a dual link LVDS receiver designed to convert LVDS
> streams
> +to parallel data outputs. The chip supports single/dual input/output modes,
> +handling up to two two input LVDS stream and up to two digital CMOS/TTL
> outputs.
> +
> +Required properties:
> +- compatible: Shall be "thine,thc63lvd1024",
> +
> +Optional properties:
> +- vcc-supply: Power supply for TTL output and digital circuitry
> +- cvcc-supply: Power supply for TTL CLOCKOUT signal
> +- lvcc-supply: Power supply for LVDS inputs
> +- pvcc-supply: Power supply for PLL circuitry
I wonder if it wouldn't be better to make them required (at least VCC) -
it is closer to reality.
> +- pwnd-gpios: Power down GPIO signal. Active low.
As I said before, specs[1] says about "/PDWN" pin. Is it your typo, or
different docs?
Moreover there are already bindings for THC63LVDM83D with the same
dichotomy [2].
Out of curiosity I have googled for "pwnd pin" and it looks like some
vendors use this form.
For me both forms are quite misleading: power down signal, active low,
why they couldn't call it just 'enable, active high'.
[1]: http://www.thine.co.jp/files/topics/179_ext_12_0.pdf
[2]:
https://elixir.bootlin.com/linux/v4.16-rc5/source/Documentation/devicetree/bindings/display/bridge/thine,thc63lvdm83d.txt
> +- oe-gpios: Output enable GPIO signal. Active high.
> +
> +The THC63LVD1024 video port connections are modeled according
> +to OF graph bindings specified by Documentation/devicetree/bindings/graph.txt
> +
> +Required video port nodes:
> +- Port@0: First LVDS input port
> +- Port@2: First digital CMOS/TTL parallel output
> +
> +Optional video port nodes:
> +- Port@1: Second LVDS input port
> +- Port@3: Second digital CMOS/TTL parallel output
> +
> +Example:
> +
> +
> + thc63lvd1024: lvds-decoder {
> + compatible = "thine,thc63lvd1024";
> +
> + vcc-supply = <®_lvds_vcc>;
> + lvcc-supply = <®_lvds_lvcc>;
> +
> + pwdn-gpio = <&gpio4 15 GPIO_ACTIVE_LOW>;
And here another variation :), should be pdwn-gpios.
> +
> + ports {
> + #address-cells = <1>;
> + #size-cells = <0>;
> +
> + port@0 {
> + reg = <0>;
> +
> + lvds_dec_in_0: endpoint {
> + remote-endpoint = <&lvds_out>;
> + };
> + };
> +
> + port@2{
> + reg = <2>;
> +
> + lvds_dec_out_2: endpoint {
> + remote-endpoint = <&adv7511_in>;
> + };
> +
> + };
> +
> + };
> + };
Re: [PATCH v3 2/3] drm: bridge: Add thc63lvd1024 LVDS decoder driver
On 13.03.2018 15:30, Jacopo Mondi wrote:
> Add DRM bridge driver for Thine THC63LVD1024 LVDS to digital parallel
> output decoder.
IMO converter suits here better, but it is just suggestion.
>
> Signed-off-by: Jacopo Mondi
> ---
> drivers/gpu/drm/bridge/Kconfig| 7 +
> drivers/gpu/drm/bridge/Makefile | 1 +
> drivers/gpu/drm/bridge/thc63lvd1024.c | 241
> ++
> 3 files changed, 249 insertions(+)
> create mode 100644 drivers/gpu/drm/bridge/thc63lvd1024.c
>
> diff --git a/drivers/gpu/drm/bridge/Kconfig b/drivers/gpu/drm/bridge/Kconfig
> index 3b99d5a..facf6bd 100644
> --- a/drivers/gpu/drm/bridge/Kconfig
> +++ b/drivers/gpu/drm/bridge/Kconfig
> @@ -92,6 +92,13 @@ config DRM_SII9234
> It is an I2C driver, that detects connection of MHL bridge
> and starts encapsulation of HDMI signal.
>
> +config DRM_THINE_THC63LVD1024
> + tristate "Thine THC63LVD1024 LVDS decoder bridge"
> + depends on OF
> + select DRM_PANEL_BRIDGE
You don't use PANEL_BRIDGE, it should be possible to drop the select.
> + ---help---
> + Thine THC63LVD1024 LVDS decoder bridge driver.
Decoder to what?
Maybe it would be better to say it is LVDS/parallel or LVDS/RGB
converter or bridge.
> +
> config DRM_TOSHIBA_TC358767
> tristate "Toshiba TC358767 eDP bridge"
> depends on OF
> diff --git a/drivers/gpu/drm/bridge/Makefile b/drivers/gpu/drm/bridge/Makefile
> index 373eb28..fd90b16 100644
> --- a/drivers/gpu/drm/bridge/Makefile
> +++ b/drivers/gpu/drm/bridge/Makefile
> @@ -8,6 +8,7 @@ obj-$(CONFIG_DRM_PARADE_PS8622) += parade-ps8622.o
> obj-$(CONFIG_DRM_SIL_SII8620) += sil-sii8620.o
> obj-$(CONFIG_DRM_SII902X) += sii902x.o
> obj-$(CONFIG_DRM_SII9234) += sii9234.o
> +obj-$(CONFIG_DRM_THINE_THC63LVD1024) += thc63lvd1024.o
> obj-$(CONFIG_DRM_TOSHIBA_TC358767) += tc358767.o
> obj-$(CONFIG_DRM_ANALOGIX_DP) += analogix/
> obj-$(CONFIG_DRM_I2C_ADV7511) += adv7511/
> diff --git a/drivers/gpu/drm/bridge/thc63lvd1024.c
> b/drivers/gpu/drm/bridge/thc63lvd1024.c
> new file mode 100644
> index 000..4b059c0
> --- /dev/null
> +++ b/drivers/gpu/drm/bridge/thc63lvd1024.c
> @@ -0,0 +1,241 @@
> +// SPDX-License-Identifier: GPL-2.0
> +/*
> + * THC63LVD1024 LVDS to parallel data DRM bridge driver.
> + *
> + * Copyright (C) 2018 Jacopo Mondi
> + */
> +
> +#include
> +#include
> +#include
> +
> +#include
> +#include
> +#include
> +
> +static const char * const thc63_reg_names[] = {
> + "vcc", "lvcc", "pvcc", "cvcc", };
> +
> +struct thc63_dev {
> + struct device *dev;
> +
> + struct regulator *vccs[ARRAY_SIZE(thc63_reg_names)];
> +
> + struct gpio_desc *pwdn;
> + struct gpio_desc *oe;
> +
> + struct drm_bridge bridge;
> + struct drm_bridge *next;
> +};
> +
> +static inline struct thc63_dev *to_thc63(struct drm_bridge *bridge)
> +{
> + return container_of(bridge, struct thc63_dev, bridge);
> +}
> +
> +static int thc63_attach(struct drm_bridge *bridge)
> +{
> + struct thc63_dev *thc63 = to_thc63(bridge);
> +
> + return drm_bridge_attach(bridge->encoder, thc63->next, bridge);
> +}
> +
> +static void thc63_enable(struct drm_bridge *bridge)
> +{
> + struct thc63_dev *thc63 = to_thc63(bridge);
> + struct regulator *vcc;
> + unsigned int i;
> + int ret;
> +
> + for (i = 0; i < ARRAY_SIZE(thc63->vccs); i++) {
> + vcc = thc63->vccs[i];
> + if (vcc) {
> + ret = regulator_enable(vcc);
> + if (ret)
> + goto error_vcc_enable;
> + }
> + }
> +
> + if (thc63->pwdn)
> + gpiod_set_value(thc63->pwdn, 0);
> +
> + if (thc63->oe)
> + gpiod_set_value(thc63->oe, 1);
> +
> + return;
> +
> +error_vcc_enable:
> + dev_err(thc63->dev, "Failed to enable regulator %u\n", i);
> +}
> +
> +static void thc63_disable(struct drm_bridge *bridge)
> +{
> + struct thc63_dev *thc63 = to_thc63(bridge);
> + struct regulator *vcc;
> + unsigned int i;
> + int ret;
> +
> + for (i = 0; i < ARRAY_SIZE(thc63->vccs); i++) {
> + vcc = thc63->vccs[i];
> + if (vcc) {
> + ret = regulator_disable(vcc);
> + if (ret)
> + goto error_vcc_disable;
I think in disable path you can report an error and continue - should be
safer.
> + }
> + }
> +
> + if (thc63->pwdn)
> + gpiod_set_value(thc63->pwdn, 1);
> +
> + if (thc63->oe)
> + gpiod_set_value(thc63->oe, 0);
Usually disable uses reverse order. Ie first disable oe, then, pwdn,
then regulators, also in reverse order.
Looks more reasonable.
> +
> + return;
> +
> +error_vcc_disable:
> + dev_err(thc63->dev, "Failed to disable regulator %u\n", i);
> +}
> +
> +struct drm_bridge_funcs thc63_bridge_func = {
> + .attach = thc63_attach,
> + .enable = thc63_enable,
> + .disable = th
Re: [PATCH v3 17/25] dt-bindings: panel: Add Bananapi S070WV20-CT16 ICN6211 MIPI-DSI to RGB bridge
On 18.11.2018 19:20, Jagan Teki wrote: > On Tue, Nov 13, 2018 at 1:26 PM Andrzej Hajda wrote: >> On 10.11.2018 08:32, Jagan Teki wrote: >>> On Wed, Nov 7, 2018 at 2:41 PM Andrzej Hajda wrote: >>>> On 06.11.2018 19:08, Jagan Teki wrote: >>>>> On Wed, Oct 31, 2018 at 2:45 PM Andrzej Hajda wrote: >>>>>> On 31.10.2018 09:58, Chen-Yu Tsai wrote: >>>>>>> On Wed, Oct 31, 2018 at 4:53 PM Andrzej Hajda >>>>>>> wrote: >>>>>>>> On 26.10.2018 16:43, Jagan Teki wrote: >>>>>>>>> Bananapi S070WV20-CT16 ICN6211 is 800x480, 4-lane MIPI-DSI to RGB >>>>>>>>> bridge panel, which is available on same PCB with 24-bit RGB >>>>>>>>> interface. >>>>>>>>> >>>>>>>>> So, this patch adds DSI specific binding details on existing >>>>>>>>> dt-bindings file. >>>>>>>>> >>>>>>>>> Signed-off-by: Jagan Teki >>>>>>>>> --- >>>>>>>>> Changes for v3: >>>>>>>>> - Use existing binding doc and update dsi details >>>>>>>>> Changes for v2: >>>>>>>>> - none >>>>>>>>> >>>>>>>>> .../display/panel/bananapi,s070wv20-ct16.txt | 31 >>>>>>>>> +-- >>>>>>>>> 1 file changed, 29 insertions(+), 2 deletions(-) >>>>>>>>> >>>>>>>>> diff --git >>>>>>>>> a/Documentation/devicetree/bindings/display/panel/bananapi,s070wv20-ct16.txt >>>>>>>>> >>>>>>>>> b/Documentation/devicetree/bindings/display/panel/bananapi,s070wv20-ct16.txt >>>>>>>>> index 35bc0c839f49..b7855dc7c66f 100644 >>>>>>>>> --- >>>>>>>>> a/Documentation/devicetree/bindings/display/panel/bananapi,s070wv20-ct16.txt >>>>>>>>> +++ >>>>>>>>> b/Documentation/devicetree/bindings/display/panel/bananapi,s070wv20-ct16.txt >>>>>>>>> @@ -1,12 +1,39 @@ >>>>>>>>> Banana Pi 7" (S070WV20-CT16) TFT LCD Panel >>>>>>>>> >>>>>>>>> +S070WV20-CT16 is 7" 800x480 panel connected through a 24-bit RGB >>>>>>>>> interface. >>>>>>>>> + >>>>>>>>> +Depending on the variant, the PCB attached to the panel module either >>>>>>>>> +supports DSI, or DSI + 24-bit RGB. DSI is converted to 24-bit RGB via >>>>>>>>> +an onboard ICN6211 MIPI DSI - RGB bridge chip, then fed to the panel >>>>>>>>> +itself >>>>>>>> As I understand this is display board, which contains 'pure' RGB panel >>>>>>>> S070WV20-CT16 and optionally ICN6211 DSI->RGB bridge. >>>>>>>> These are separate devices, just connected by vendor to simplify its >>>>>>>> assembly. Why don't you create then bridge driver for ICN6211 and RGB >>>>>>>> panel driver for S070WV20-CT16 - it looks more generic. >>>>>>>> Then you can describe both in dts and voila. >>>>>>>> Creating drivers for every combo of devices (panel + bridge), just >>>>>>>> because some vendor sells them together seems incorrect - we have >>>>>>>> devicetree for it. >>>>>>> Rob suggested this, and also the opposite: using the same >>>>>>> "bananapi,s070wv20-ct16" >>>>>>> compatible string for both types of connections, and have the driver >>>>>>> deal with >>>>>>> detecting the bus type. >>>>>>> >>>>>>> The thing about the bridge chip is that there's no available datasheet >>>>>>> that >>>>>>> describes all the parts of the init sequence, in fact none at all. I >>>>>>> managed >>>>>>> to work out some bits, but the others remain a mystery and must be >>>>>>> hard-coded >>>>>>> to match the panel. That would work against having a generic bridge >>>>>>> driver. >>>>>> But it is common for many chips - 1st version of
[PATCH] component: do not stop components lookup after first fail
Currently showing content of /sys/kernel/debug/device_component/*
works partially, in case one of the components is not available this and
all remaining components have status not-registered, but the problem
is only with the first one.
Allowing to finish lookup for other components in case one is missing
solves the issue.
Signed-off-by: Andrzej Hajda
---
drivers/base/component.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/base/component.c b/drivers/base/component.c
index e8d676fad0c9..e9572b37d5cf 100644
--- a/drivers/base/component.c
+++ b/drivers/base/component.c
@@ -179,7 +179,7 @@ static int find_components(struct master *master)
c = find_component(master, mc->compare, mc->data);
if (!c) {
ret = -ENXIO;
- break;
+ continue;
}
dev_dbg(master->dev, "found component %s, duplicate %u\n",
dev_name(c->dev), !!c->master);
--
2.17.1
[PATCH] PM / core: refactor PM_OPS initializers
With current implementation of PM_OPS initializers users should annotate
all PM callbacks with __maybe_unused attribute to prevent compiler from
complaining in case respective option is not enabled. Using ternary
operator with IS_ENABLED(symbol) as a condition allows to avoid marking
these functions with __maybe_unused.
Solution was tested successfully with multiple versions of gcc since
4.9.4 up to 7.2.1. No functional changes has been observed and callbacks
were compiled out if not used, as before.
Signed-off-by: Andrzej Hajda
---
include/linux/pm.h | 61 ++
1 file changed, 24 insertions(+), 37 deletions(-)
diff --git a/include/linux/pm.h b/include/linux/pm.h
index e723b78d8357..59f333922c15 100644
--- a/include/linux/pm.h
+++ b/include/linux/pm.h
@@ -313,50 +313,37 @@ struct dev_pm_ops {
int (*runtime_idle)(struct device *dev);
};
-#ifdef CONFIG_PM_SLEEP
+#define PM_SLEEP_PTR(ptr) (IS_ENABLED(CONFIG_PM_SLEEP) ? (ptr) : NULL)
+#define PM_PTR(ptr) (IS_ENABLED(CONFIG_PM) ? (ptr) : NULL)
+
#define SET_SYSTEM_SLEEP_PM_OPS(suspend_fn, resume_fn) \
- .suspend = suspend_fn, \
- .resume = resume_fn, \
- .freeze = suspend_fn, \
- .thaw = resume_fn, \
- .poweroff = suspend_fn, \
- .restore = resume_fn,
-#else
-#define SET_SYSTEM_SLEEP_PM_OPS(suspend_fn, resume_fn)
-#endif
+ .suspend = PM_SLEEP_PTR(suspend_fn), \
+ .resume = PM_SLEEP_PTR(resume_fn), \
+ .freeze = PM_SLEEP_PTR(suspend_fn), \
+ .thaw = PM_SLEEP_PTR(resume_fn), \
+ .poweroff = PM_SLEEP_PTR(suspend_fn), \
+ .restore = PM_SLEEP_PTR(resume_fn),
-#ifdef CONFIG_PM_SLEEP
#define SET_LATE_SYSTEM_SLEEP_PM_OPS(suspend_fn, resume_fn) \
- .suspend_late = suspend_fn, \
- .resume_early = resume_fn, \
- .freeze_late = suspend_fn, \
- .thaw_early = resume_fn, \
- .poweroff_late = suspend_fn, \
- .restore_early = resume_fn,
-#else
-#define SET_LATE_SYSTEM_SLEEP_PM_OPS(suspend_fn, resume_fn)
-#endif
+ .suspend_late = PM_SLEEP_PTR(suspend_fn), \
+ .resume_early = PM_SLEEP_PTR(resume_fn), \
+ .freeze_late = PM_SLEEP_PTR(suspend_fn), \
+ .thaw_early = PM_SLEEP_PTR(resume_fn), \
+ .poweroff_late = PM_SLEEP_PTR(suspend_fn), \
+ .restore_early = PM_SLEEP_PTR(resume_fn),
-#ifdef CONFIG_PM_SLEEP
#define SET_NOIRQ_SYSTEM_SLEEP_PM_OPS(suspend_fn, resume_fn) \
- .suspend_noirq = suspend_fn, \
- .resume_noirq = resume_fn, \
- .freeze_noirq = suspend_fn, \
- .thaw_noirq = resume_fn, \
- .poweroff_noirq = suspend_fn, \
- .restore_noirq = resume_fn,
-#else
-#define SET_NOIRQ_SYSTEM_SLEEP_PM_OPS(suspend_fn, resume_fn)
-#endif
+ .suspend_noirq = PM_SLEEP_PTR(suspend_fn), \
+ .resume_noirq = PM_SLEEP_PTR(resume_fn), \
+ .freeze_noirq = PM_SLEEP_PTR(suspend_fn), \
+ .thaw_noirq = PM_SLEEP_PTR(resume_fn), \
+ .poweroff_noirq = PM_SLEEP_PTR(suspend_fn), \
+ .restore_noirq = PM_SLEEP_PTR(resume_fn),
-#ifdef CONFIG_PM
#define SET_RUNTIME_PM_OPS(suspend_fn, resume_fn, idle_fn) \
- .runtime_suspend = suspend_fn, \
- .runtime_resume = resume_fn, \
- .runtime_idle = idle_fn,
-#else
-#define SET_RUNTIME_PM_OPS(suspend_fn, resume_fn, idle_fn)
-#endif
+ .runtime_suspend = PM_PTR(suspend_fn), \
+ .runtime_resume = PM_PTR(resume_fn), \
+ .runtime_idle = PM_PTR(idle_fn),
/*
* Use this if you want to use the same suspend and resume callbacks for
suspend
--
2.17.0
Re: [PATCH 1/2] USB: dwc3: get extcon device by OF graph bindings
On 31.01.2018 16:57, Andrzej Hajda wrote:
> extcon device is used to detect host/device connection. Since extcon
> OF property is deprecated, alternative method should be added.
> This method uses OF graph bindings to locate extcon.
>
> Signed-off-by: Andrzej Hajda
Ping, 3.5 months passed.
Regards
Andrzej
> ---
> Hi all,
>
> This patch implements alternative method to get extcon from DWC3.
> The code works but is hacky, as DWC3 must traverse different DT nodes
> to get extcon, in case of TM2 it is USB-PHY and MUIC, but other
> platforms can have different paths.
> I would be glad if it can be merged as is for now, but additional work
> must be done to make it generic.
> I guess on DT binding side it is OK. So the problem should be addressed
> in the code.
> My rough idea is to implement kind of extcon aliases/forwarder mechanism,
> ie. USB-PHY will expect on its output remote port extcon, and it should
> register
> extcon-forwarder pointing to this extcon. This way DWC3 can look for the
> extcon
> on its PHY phandle, and it will receive via forwarding mechanism extcon
> exposed by MUIC.
> As I said this is rough idea for discussion, other propositions are welcome.
>
> Regards
> Andrzej
> ---
> drivers/usb/dwc3/drd.c | 41 -
> 1 file changed, 28 insertions(+), 13 deletions(-)
>
> diff --git a/drivers/usb/dwc3/drd.c b/drivers/usb/dwc3/drd.c
> index cc8ab9a8e9d2..eee2eca3d513 100644
> --- a/drivers/usb/dwc3/drd.c
> +++ b/drivers/usb/dwc3/drd.c
> @@ -8,6 +8,7 @@
> */
>
> #include
> +#include
>
> #include "debug.h"
> #include "core.h"
> @@ -38,24 +39,38 @@ static int dwc3_drd_notifier(struct notifier_block *nb,
> return NOTIFY_DONE;
> }
>
> +struct extcon_dev *dwc3_get_extcon(struct dwc3 *dwc)
> +{
> + struct device *dev = dwc->dev;
> + struct device_node *np_phy, *np_conn;
> + struct extcon_dev *edev;
> +
> + if (of_property_read_bool(dev->of_node, "extcon"))
> + return extcon_get_edev_by_phandle(dwc->dev, 0);
> +
> + np_phy = of_parse_phandle(dev->of_node, "phys", 0);
> + np_conn = of_graph_get_remote_node(np_phy, -1, -1);
> + edev = extcon_get_edev_by_of_node(np_conn);
> + of_node_put(np_conn);
> + of_node_put(np_phy);
> +
> + return edev;
> +}
> +
> int dwc3_drd_init(struct dwc3 *dwc)
> {
> int ret;
>
> - if (dwc->dev->of_node) {
> - if (of_property_read_bool(dwc->dev->of_node, "extcon"))
> - dwc->edev = extcon_get_edev_by_phandle(dwc->dev, 0);
> -
> - if (IS_ERR(dwc->edev))
> - return PTR_ERR(dwc->edev);
> + dwc->edev = dwc3_get_extcon(dwc);
> + if (IS_ERR(dwc->edev))
> + return PTR_ERR(dwc->edev);
>
> - dwc->edev_nb.notifier_call = dwc3_drd_notifier;
> - ret = extcon_register_notifier(dwc->edev, EXTCON_USB_HOST,
> -&dwc->edev_nb);
> - if (ret < 0) {
> - dev_err(dwc->dev, "couldn't register cable notifier\n");
> - return ret;
> - }
> + dwc->edev_nb.notifier_call = dwc3_drd_notifier;
> + ret = extcon_register_notifier(dwc->edev, EXTCON_USB_HOST,
> +&dwc->edev_nb);
> + if (ret < 0) {
> + dev_err(dwc->dev, "couldn't register cable notifier\n");
> + return ret;
> }
>
> dwc3_drd_update(dwc);
Re: [PATCH v2 2/2] drm/bridge: sii902x: add optional power supplies
On 14.05.2018 11:38, Philippe CORNU wrote:
> Hi Laurent, Archit, Andrzej & Yannick,
>
> Do you have any comments on this v2 driver part?
> (more details regarding v1/v2 differences in the cover letter
> https://www.spinics.net/lists/dri-devel/msg174137.html)
>
> Thank you,
> Philippe :-)
>
>
> On 04/25/2018 09:53 AM, Philippe Cornu wrote:
>> Add the optional power supplies using the description found in
>> "SiI9022A/SiI9024A HDMI Transmitter Data Sheet (August 2016)".
>>
>> The sii902x input IOs are not "io safe" so it is important to
>> enable/disable voltage regulators during probe/remove phases to
>> avoid damages.
What exactly does it mean? Ie I understand that the chip has some
limitations, but why enabling/disabling regulators in probe/remove
should solve it?
Regards
Andrzej
>>
>> Signed-off-by: Philippe Cornu
>> ---
>> drivers/gpu/drm/bridge/sii902x.c | 38
>> ++
>> 1 file changed, 34 insertions(+), 4 deletions(-)
>>
>> diff --git a/drivers/gpu/drm/bridge/sii902x.c
>> b/drivers/gpu/drm/bridge/sii902x.c
>> index 60373d7eb220..c367d7b91ade 100644
>> --- a/drivers/gpu/drm/bridge/sii902x.c
>> +++ b/drivers/gpu/drm/bridge/sii902x.c
>> @@ -24,6 +24,7 @@
>> #include
>> #include
>> #include
>> +#include
>>
>> #include
>> #include
>> @@ -86,6 +87,7 @@ struct sii902x {
>> struct drm_bridge bridge;
>> struct drm_connector connector;
>> struct gpio_desc *reset_gpio;
>> +struct regulator_bulk_data supplies[2];
>> };
>>
>> static inline struct sii902x *bridge_to_sii902x(struct drm_bridge *bridge)
>> @@ -392,23 +394,42 @@ static int sii902x_probe(struct i2c_client *client,
>> return PTR_ERR(sii902x->reset_gpio);
>> }
>>
>> +sii902x->supplies[0].supply = "iovcc";
>> +sii902x->supplies[1].supply = "vcc12";
>> +ret = devm_regulator_bulk_get(dev, ARRAY_SIZE(sii902x->supplies),
>> + sii902x->supplies);
>> +if (ret) {
>> +dev_err(dev, "Failed to get power supplies: %d\n", ret);
>> +return ret;
>> +}
>> +
>> +ret = regulator_bulk_enable(ARRAY_SIZE(sii902x->supplies),
>> +sii902x->supplies);
>> +if (ret) {
>> +dev_err(dev, "Failed to enable power supplies: %d\n", ret);
>> +return ret;
>> +}
>> +
>> +usleep_range(1, 2);
>> +
>> sii902x_reset(sii902x);
>>
>> ret = regmap_write(sii902x->regmap, SII902X_REG_TPI_RQB, 0x0);
>> if (ret)
>> -return ret;
>> +goto err_disable_regulator;
>>
>> ret = regmap_bulk_read(sii902x->regmap, SII902X_REG_CHIPID(0),
>> &chipid, 4);
>> if (ret) {
>> dev_err(dev, "regmap_read failed %d\n", ret);
>> -return ret;
>> +goto err_disable_regulator;
>> }
>>
>> if (chipid[0] != 0xb0) {
>> dev_err(dev, "Invalid chipid: %02x (expecting 0xb0)\n",
>> chipid[0]);
>> -return -EINVAL;
>> +ret = -EINVAL;
>> +goto err_disable_regulator;
>> }
>>
>> /* Clear all pending interrupts */
>> @@ -424,7 +445,7 @@ static int sii902x_probe(struct i2c_client *client,
>> IRQF_ONESHOT, dev_name(dev),
>> sii902x);
>> if (ret)
>> -return ret;
>> +goto err_disable_regulator;
>> }
>>
>> sii902x->bridge.funcs = &sii902x_bridge_funcs;
>> @@ -434,6 +455,12 @@ static int sii902x_probe(struct i2c_client *client,
>> i2c_set_clientdata(client, sii902x);
>>
>> return 0;
>> +
>> +err_disable_regulator:
>> +regulator_bulk_disable(ARRAY_SIZE(sii902x->supplies),
>> + sii902x->supplies);
>> +
>> +return ret;
>> }
>>
>> static int sii902x_remove(struct i2c_client *client)
>> @@ -443,6 +470,9 @@ static int sii902x_remove(struct i2c_client *client)
>>
>> drm_bridge_remove(&sii902x->bridge);
>>
>> +regulator_bulk_disable(ARRAY_SIZE(sii902x->supplies),
>> + sii902x->supplies);
>> +
>> return 0;
>> }
>>
Re: [PATCH] PM / core: refactor PM_OPS initializers
On 14.05.2018 10:21, Andrzej Hajda wrote:
> With current implementation of PM_OPS initializers users should annotate
> all PM callbacks with __maybe_unused attribute to prevent compiler from
> complaining in case respective option is not enabled. Using ternary
> operator with IS_ENABLED(symbol) as a condition allows to avoid marking
> these functions with __maybe_unused.
> Solution was tested successfully with multiple versions of gcc since
> 4.9.4 up to 7.2.1. No functional changes has been observed and callbacks
> were compiled out if not used, as before.
The kernel does not compile with the patch applied if the driver defines
PM callback inside "#ifdef CONFIG_PM(_SLEEP)" - initializers assume that
callbacks are defined, even if they are not used.
So if the idea is OK I should figure it out how to make proper
transition, any ideas welcome :)
Regards
Andrzej
>
> Signed-off-by: Andrzej Hajda
> ---
> include/linux/pm.h | 61 ++
> 1 file changed, 24 insertions(+), 37 deletions(-)
>
> diff --git a/include/linux/pm.h b/include/linux/pm.h
> index e723b78d8357..59f333922c15 100644
> --- a/include/linux/pm.h
> +++ b/include/linux/pm.h
> @@ -313,50 +313,37 @@ struct dev_pm_ops {
> int (*runtime_idle)(struct device *dev);
> };
>
> -#ifdef CONFIG_PM_SLEEP
> +#define PM_SLEEP_PTR(ptr) (IS_ENABLED(CONFIG_PM_SLEEP) ? (ptr) : NULL)
> +#define PM_PTR(ptr) (IS_ENABLED(CONFIG_PM) ? (ptr) : NULL)
> +
> #define SET_SYSTEM_SLEEP_PM_OPS(suspend_fn, resume_fn) \
> - .suspend = suspend_fn, \
> - .resume = resume_fn, \
> - .freeze = suspend_fn, \
> - .thaw = resume_fn, \
> - .poweroff = suspend_fn, \
> - .restore = resume_fn,
> -#else
> -#define SET_SYSTEM_SLEEP_PM_OPS(suspend_fn, resume_fn)
> -#endif
> + .suspend = PM_SLEEP_PTR(suspend_fn), \
> + .resume = PM_SLEEP_PTR(resume_fn), \
> + .freeze = PM_SLEEP_PTR(suspend_fn), \
> + .thaw = PM_SLEEP_PTR(resume_fn), \
> + .poweroff = PM_SLEEP_PTR(suspend_fn), \
> + .restore = PM_SLEEP_PTR(resume_fn),
>
> -#ifdef CONFIG_PM_SLEEP
> #define SET_LATE_SYSTEM_SLEEP_PM_OPS(suspend_fn, resume_fn) \
> - .suspend_late = suspend_fn, \
> - .resume_early = resume_fn, \
> - .freeze_late = suspend_fn, \
> - .thaw_early = resume_fn, \
> - .poweroff_late = suspend_fn, \
> - .restore_early = resume_fn,
> -#else
> -#define SET_LATE_SYSTEM_SLEEP_PM_OPS(suspend_fn, resume_fn)
> -#endif
> + .suspend_late = PM_SLEEP_PTR(suspend_fn), \
> + .resume_early = PM_SLEEP_PTR(resume_fn), \
> + .freeze_late = PM_SLEEP_PTR(suspend_fn), \
> + .thaw_early = PM_SLEEP_PTR(resume_fn), \
> + .poweroff_late = PM_SLEEP_PTR(suspend_fn), \
> + .restore_early = PM_SLEEP_PTR(resume_fn),
>
> -#ifdef CONFIG_PM_SLEEP
> #define SET_NOIRQ_SYSTEM_SLEEP_PM_OPS(suspend_fn, resume_fn) \
> - .suspend_noirq = suspend_fn, \
> - .resume_noirq = resume_fn, \
> - .freeze_noirq = suspend_fn, \
> - .thaw_noirq = resume_fn, \
> - .poweroff_noirq = suspend_fn, \
> - .restore_noirq = resume_fn,
> -#else
> -#define SET_NOIRQ_SYSTEM_SLEEP_PM_OPS(suspend_fn, resume_fn)
> -#endif
> + .suspend_noirq = PM_SLEEP_PTR(suspend_fn), \
> + .resume_noirq = PM_SLEEP_PTR(resume_fn), \
> + .freeze_noirq = PM_SLEEP_PTR(suspend_fn), \
> + .thaw_noirq = PM_SLEEP_PTR(resume_fn), \
> + .poweroff_noirq = PM_SLEEP_PTR(suspend_fn), \
> + .restore_noirq = PM_SLEEP_PTR(resume_fn),
>
> -#ifdef CONFIG_PM
> #define SET_RUNTIME_PM_OPS(suspend_fn, resume_fn, idle_fn) \
> - .runtime_suspend = suspend_fn, \
> - .runtime_resume = resume_fn, \
> - .runtime_idle = idle_fn,
> -#else
> -#define SET_RUNTIME_PM_OPS(suspend_fn, resume_fn, idle_fn)
> -#endif
> + .runtime_suspend = PM_PTR(suspend_fn), \
> + .runtime_resume = PM_PTR(resume_fn), \
> + .runtime_idle = PM_PTR(idle_fn),
>
> /*
> * Use this if you want to use the same suspend and resume callbacks for
> suspend
Re: [PATCH 2/2] arm64: dts: exynos: Remove unneeded DSI and DECON address/size cells in Exynos5433
On 18.06.2018 19:42, Krzysztof Kozlowski wrote:
> The decon, decon_tv and dsi nodes have only one child port so
> address/size mappings are not necessary. This fixes DTC warnings like:
>
> Warning (graph_child_address): /soc/decon@1380/ports:
> graph node has single child node 'port@0', #address-cells/#size-cells
> are not necessary
DECON nodes according to documentation have only one port so it is OK.
DSI has two ports, but since on all Exynos platforms DSI panels/bridges
are subnodes of ExynosDSI the 2nd port is not used.
So if there will be a platform with DSI panel/bridge controlled via I2C,
it should be reverted., but this is theoretical problem.
>
> Signed-off-by: Krzysztof Kozlowski
Reviewed-by: Andrzej Hajda
--
Regards
Andrzej
> ---
> arch/arm64/boot/dts/exynos/exynos5433-tm2-common.dtsi | 6 +-
> arch/arm64/boot/dts/exynos/exynos5433.dtsi| 12 ++--
> 2 files changed, 3 insertions(+), 15 deletions(-)
>
> diff --git a/arch/arm64/boot/dts/exynos/exynos5433-tm2-common.dtsi
> b/arch/arm64/boot/dts/exynos/exynos5433-tm2-common.dtsi
> index a1e3194b7483..0a15ee513f5c 100644
> --- a/arch/arm64/boot/dts/exynos/exynos5433-tm2-common.dtsi
> +++ b/arch/arm64/boot/dts/exynos/exynos5433-tm2-common.dtsi
> @@ -321,11 +321,7 @@
> status = "okay";
>
> ports {
> - #address-cells = <1>;
> - #size-cells = <0>;
> -
> - port@0 {
> - reg = <0>;
> + port {
> tv_to_hdmi: endpoint {
> remote-endpoint = <&hdmi_to_tv>;
> };
> diff --git a/arch/arm64/boot/dts/exynos/exynos5433.dtsi
> b/arch/arm64/boot/dts/exynos/exynos5433.dtsi
> index 3a9b4c4b9c63..e4367fd39120 100644
> --- a/arch/arm64/boot/dts/exynos/exynos5433.dtsi
> +++ b/arch/arm64/boot/dts/exynos/exynos5433.dtsi
> @@ -850,11 +850,7 @@
> iommu-names = "m0", "m1";
>
> ports {
> - #address-cells = <1>;
> - #size-cells = <0>;
> -
> - port@0 {
> - reg = <0>;
> + port {
> decon_to_mic: endpoint {
> remote-endpoint =
> <&mic_to_decon>;
> @@ -914,11 +910,7 @@
> #size-cells = <0>;
>
> ports {
> - #address-cells = <1>;
> - #size-cells = <0>;
> -
> - port@0 {
> - reg = <0>;
> + port {
> dsi_to_mic: endpoint {
> remote-endpoint = <&mic_to_dsi>;
> };
Re: [RFC PATCH linux-next] USB: dwc3: dwc3_get_extcon() can be static
On 17.05.2018 18:06, kbuild test robot wrote:
> Fixes: 5f0b74e54890 ("USB: dwc3: get extcon device by OF graph bindings")
> Signed-off-by: kbuild test robot
It should be static of course, my bad.
Reviewed-by: Andrzej Hajda
--
Regards
Andrzej
> ---
> drd.c |2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/usb/dwc3/drd.c b/drivers/usb/dwc3/drd.c
> index 2706824..218371f 100644
> --- a/drivers/usb/dwc3/drd.c
> +++ b/drivers/usb/dwc3/drd.c
> @@ -440,7 +440,7 @@ static int dwc3_drd_notifier(struct notifier_block *nb,
> return NOTIFY_DONE;
> }
>
> -struct extcon_dev *dwc3_get_extcon(struct dwc3 *dwc)
> +static struct extcon_dev *dwc3_get_extcon(struct dwc3 *dwc)
> {
> struct device *dev = dwc->dev;
> struct device_node *np_phy, *np_conn;
>
>
>
Re: [RFC PATCH linux-next] USB: dwc3: dwc3_get_extcon() can be static
On 18.05.2018 09:38, Roger Quadros wrote:
> On 18/05/18 08:39, Andrzej Hajda wrote:
>> On 17.05.2018 18:06, kbuild test robot wrote:
>>> Fixes: 5f0b74e54890 ("USB: dwc3: get extcon device by OF graph bindings")
>>> Signed-off-by: kbuild test robot
>> It should be static of course, my bad.
>>
>> Reviewed-by: Andrzej Hajda
> I don't think we accept patches from robots, yet :)
What do you mean by 'we'? In case of whole kernel it is not true:
$ git log --author='kbuild test robot '
--oneline | wc -l
183
Regards
Andrzej
>
>> --
>> Regards
>> Andrzej
>>
>>> ---
>>> drd.c |2 +-
>>> 1 file changed, 1 insertion(+), 1 deletion(-)
>>>
>>> diff --git a/drivers/usb/dwc3/drd.c b/drivers/usb/dwc3/drd.c
>>> index 2706824..218371f 100644
>>> --- a/drivers/usb/dwc3/drd.c
>>> +++ b/drivers/usb/dwc3/drd.c
>>> @@ -440,7 +440,7 @@ static int dwc3_drd_notifier(struct notifier_block *nb,
>>> return NOTIFY_DONE;
>>> }
>>>
>>> -struct extcon_dev *dwc3_get_extcon(struct dwc3 *dwc)
>>> +static struct extcon_dev *dwc3_get_extcon(struct dwc3 *dwc)
>>> {
>>> struct device *dev = dwc->dev;
>>> struct device_node *np_phy, *np_conn;
>>>
>>>
>>>
>> --
>> To unsubscribe from this list: send the line "unsubscribe linux-usb" in
>> the body of a message to majord...@vger.kernel.org
>> More majordomo info at http://vger.kernel.org/majordomo-info.html
>>
Re: [PATCH RFC v2 1/8] drm/bridge: dw-hdmi: Add SCDC and TMDS Scrambling support
play_mode *mode)
> {
> - u8 inv_val;
> + u8 inv_val, bytes;
> + struct drm_hdmi_info *hdmi_info = &hdmi->connector.display_info.hdmi;
> struct hdmi_vmode *vmode = &hdmi->hdmi_data.video_mode;
> int hblank, vblank, h_de_hs, v_de_vs, hsync_len, vsync_len;
> unsigned int vdisplay;
> @@ -1513,7 +1554,9 @@ static void hdmi_av_composer(struct dw_hdmi *hdmi,
> dev_dbg(hdmi->dev, "final pixclk = %d\n", vmode->mpixelclock);
>
> /* Set up HDMI_FC_INVIDCONF */
> - inv_val = (hdmi->hdmi_data.hdcp_enable ?
> + inv_val = (hdmi->hdmi_data.hdcp_enable ||
> +vmode->mpixelclock > HDMI14_MAX_TMDSCLK ||
> +hdmi_info->scdc.scrambling.low_rates ?
> HDMI_FC_INVIDCONF_HDCP_KEEPOUT_ACTIVE :
> HDMI_FC_INVIDCONF_HDCP_KEEPOUT_INACTIVE);
>
> @@ -1562,6 +1605,45 @@ static void hdmi_av_composer(struct dw_hdmi *hdmi,
> vsync_len /= 2;
> }
>
> + /* Scrambling Control */
> + if (hdmi_info->scdc.supported) {
> + if (vmode->mpixelclock > HDMI14_MAX_TMDSCLK ||
> + hdmi_info->scdc.scrambling.low_rates) {
> + /*
> + * HDMI2.0 Specifies the following procedure:
> + * After the Source Device has determined that
> + * SCDC_Present is set (=1), the Source Device should
> + * write the accurate Version of the Source Device
> + * to the Source Version field in the SCDCS.
> + * Source Devices compliant shall set the
> + * Source Version = 1.
> + */
> + drm_scdc_readb(&hdmi->i2c->adap, SCDC_SINK_VERSION,
> +&bytes);
> + drm_scdc_writeb(&hdmi->i2c->adap, SCDC_SOURCE_VERSION,
> + min_t(u8, bytes, SCDC_MIN_SOURCE_VERSION));
> +
> + /* Enabled Scrambling in the Sink */
> + drm_scdc_set_scrambling(&hdmi->i2c->adap, 1);
> +
> + /*
> + * To activate the scrambler feature, you must ensure
> + * that the quasi-static configuration bit
> + * fc_invidconf.HDCP_keepout is set at configuration
> + * time, before the required mc_swrstzreq.tmdsswrst_req
> + * reset request is issued.
> + */
> + hdmi_writeb(hdmi, (u8)~HDMI_MC_SWRSTZ_TMDSSWRST_REQ,
Are you sure you need casting to u8?
> + HDMI_MC_SWRSTZ);
> + hdmi_writeb(hdmi, 1, HDMI_FC_SCRAMBLER_CTRL);
> + } else {
> + hdmi_writeb(hdmi, 0, HDMI_FC_SCRAMBLER_CTRL);
> + hdmi_writeb(hdmi, (u8)~HDMI_MC_SWRSTZ_TMDSSWRST_REQ,
> + HDMI_MC_SWRSTZ);
> + drm_scdc_set_scrambling(&hdmi->i2c->adap, 0);
> + }
> + }
> +
> /* Set up horizontal active pixel width */
> hdmi_writeb(hdmi, mode->hdisplay >> 8, HDMI_FC_INHACTV1);
> hdmi_writeb(hdmi, mode->hdisplay, HDMI_FC_INHACTV0);
> diff --git a/drivers/gpu/drm/bridge/synopsys/dw-hdmi.h
> b/drivers/gpu/drm/bridge/synopsys/dw-hdmi.h
> index 9d90eb9c46e5..3f3c616eba97 100644
> --- a/drivers/gpu/drm/bridge/synopsys/dw-hdmi.h
> +++ b/drivers/gpu/drm/bridge/synopsys/dw-hdmi.h
> @@ -255,6 +255,7 @@
> #define HDMI_FC_MASK2 0x10DA
> #define HDMI_FC_POL20x10DB
> #define HDMI_FC_PRCONF 0x10E0
> +#define HDMI_FC_SCRAMBLER_CTRL 0x10E1
>
> #define HDMI_FC_GMD_STAT0x1100
> #define HDMI_FC_GMD_EN 0x1101
> diff --git a/include/drm/bridge/dw_hdmi.h b/include/drm/bridge/dw_hdmi.h
> index 9c56412bb2cf..7a02744ce0bc 100644
> --- a/include/drm/bridge/dw_hdmi.h
> +++ b/include/drm/bridge/dw_hdmi.h
> @@ -157,6 +157,7 @@ void dw_hdmi_setup_rx_sense(struct dw_hdmi *hdmi, bool
> hpd, bool rx_sense);
> void dw_hdmi_set_sample_rate(struct dw_hdmi *hdmi, unsigned int rate);
> void dw_hdmi_audio_enable(struct dw_hdmi *hdmi);
> void dw_hdmi_audio_disable(struct dw_hdmi *hdmi);
> +void dw_hdmi_set_high_tmds_clock_ratio(struct dw_hdmi *hdmi);
>
> /* PHY configuration */
> void dw_hdmi_phy_i2c_set_addr(struct dw_hdmi *hdmi, u8 address);
Reviewed-by: Andrzej Hajda
--
Regards
Andrzej
Re: [PATCH RFC v2 2/8] drm/meson: add HDMI div40 TMDS mode
On 30.11.2018 14:42, Neil Armstrong wrote:
> Add support for TMDS Clock > 3.4GHz for HDMI2.0 display modes.
>
> Signed-off-by: Neil Armstrong
> ---
> drivers/gpu/drm/meson/meson_dw_hdmi.c | 24
> 1 file changed, 20 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/gpu/drm/meson/meson_dw_hdmi.c
> b/drivers/gpu/drm/meson/meson_dw_hdmi.c
> index 807111ebfdd9..b8775102b100 100644
> --- a/drivers/gpu/drm/meson/meson_dw_hdmi.c
> +++ b/drivers/gpu/drm/meson/meson_dw_hdmi.c
> @@ -365,7 +365,8 @@ static int dw_hdmi_phy_init(struct dw_hdmi *hdmi, void
> *data,
> unsigned int wr_clk =
> readl_relaxed(priv->io_base + _REG(VPU_HDMI_SETTING));
>
> - DRM_DEBUG_DRIVER("%d:\"%s\"\n", mode->base.id, mode->name);
> + DRM_DEBUG_DRIVER("%d:\"%s\" div%d\n", mode->base.id, mode->name,
> + mode->clock > 34 ? 40 : 10);
>
> /* Enable clocks */
> regmap_update_bits(priv->hhi, HHI_HDMI_CLK_CNTL, 0x, 0x100);
> @@ -385,9 +386,17 @@ static int dw_hdmi_phy_init(struct dw_hdmi *hdmi, void
> *data,
> /* Enable normal output to PHY */
> dw_hdmi_top_write(dw_hdmi, HDMITX_TOP_BIST_CNTL, BIT(12));
>
> - /* TMDS pattern setup (TOFIX pattern for 4k2k scrambling) */
> - dw_hdmi_top_write(dw_hdmi, HDMITX_TOP_TMDS_CLK_PTTN_01, 0x001f001f);
> - dw_hdmi_top_write(dw_hdmi, HDMITX_TOP_TMDS_CLK_PTTN_23, 0x001f001f);
> + /* TMDS pattern setup (TOFIX Handle the YUV420 case) */
> + if (mode->clock > 34) {
> + dw_hdmi_top_write(dw_hdmi, HDMITX_TOP_TMDS_CLK_PTTN_01, 0);
> + dw_hdmi_top_write(dw_hdmi, HDMITX_TOP_TMDS_CLK_PTTN_23,
> + 0x03ff03ff);
> + } else {
> + dw_hdmi_top_write(dw_hdmi, HDMITX_TOP_TMDS_CLK_PTTN_01,
> + 0x001f001f);
> + dw_hdmi_top_write(dw_hdmi, HDMITX_TOP_TMDS_CLK_PTTN_23,
> + 0x001f001f);
> + }
>
> /* Load TMDS pattern */
> dw_hdmi_top_write(dw_hdmi, HDMITX_TOP_TMDS_CLK_PTTN_CNTL, 0x1);
> @@ -413,6 +422,8 @@ static int dw_hdmi_phy_init(struct dw_hdmi *hdmi, void
> *data,
> /* Disable clock, fifo, fifo_wr */
> regmap_update_bits(priv->hhi, HHI_HDMI_PHY_CNTL1, 0xf, 0);
>
> + dw_hdmi_set_high_tmds_clock_ratio(hdmi);
> +
> msleep(100);
>
> /* Reset PHY 3 times in a row */
> @@ -562,6 +573,11 @@ dw_hdmi_mode_valid(struct drm_connector *connector,
> mode->vdisplay, mode->vsync_start,
> mode->vsync_end, mode->vtotal, mode->type, mode->flags);
>
> + /* If sink max TMDS clock < 340MHz, we reject the HDMI2.0 modes */
> + if (mode->clock > 34 &&
> + connector->display_info.max_tmds_clock < 34)
> + return MODE_BAD;
> +
Why not just:
if (mode->clock > connector->display_info.max_tmds_clock)
return MODE_BAD;
Regards
Andrzej
> /* Check against non-VIC supported modes */
> if (!vic) {
> status = meson_venc_hdmi_supported_mode(mode);
Re: [PATCH RFC v2 3/8] drm/meson: add support for HDMI2.0 2160p modes
On 30.11.2018 14:42, Neil Armstrong wrote:
> Now we support the TMDS Clock > 3.4GHz and support the SCDC Control
> operation in the DW-HDMI Controller, we can enable support for the
> HDMI2.0 3840x2160@60/50 RGB444 display modes.
>
> Signed-off-by: Neil Armstrong
> ---
> drivers/gpu/drm/meson/meson_venc.c | 2 ++
> 1 file changed, 2 insertions(+)
>
> diff --git a/drivers/gpu/drm/meson/meson_venc.c
> b/drivers/gpu/drm/meson/meson_venc.c
> index 0ba04f6813e6..66d73a932d19 100644
> --- a/drivers/gpu/drm/meson/meson_venc.c
> +++ b/drivers/gpu/drm/meson/meson_venc.c
> @@ -848,6 +848,8 @@ struct meson_hdmi_venc_vic_mode {
> { 93, &meson_hdmi_encp_mode_2160p24 },
> { 94, &meson_hdmi_encp_mode_2160p25 },
> { 95, &meson_hdmi_encp_mode_2160p30 },
> + { 96, &meson_hdmi_encp_mode_2160p25 },
> + { 97, &meson_hdmi_encp_mode_2160p30 },
> { 0, NULL}, /* sentinel */
> };
>
Reviewed-by: Andrzej Hajda
--
Regards
Andrzej
Re: [PATCH RFC v2 4/8] drm/bridge: dw-hdmi: add support for YUV420 output
On 30.11.2018 14:42, Neil Armstrong wrote: > In order to support the HDMI2.0 YUV420 display modes, this patch > adds support for the YUV420 TMDS Clock divided by 2 and the controller > passthrough mode. > > YUV420 Synopsys PHY support will need some specific configuration table > to support theses modes. > > This patch is based on work from Zheng Yang in > the Rockchip Linux 4.4 BSP at [1] > > [1] https://github.com/rockchip-linux/kernel/tree/release-4.4 > > Cc: Zheng Yang > Signed-off-by: Neil Armstrong Reviewed-by: Andrzej Hajda -- Regards Andrzej
